From mmn@hethane.se Sat Sep 1 02:43:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1880621F84DE for ; Sat, 1 Sep 2012 02:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhIgn4dKxp7h for ; Sat, 1 Sep 2012 02:43:14 -0700 (PDT) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1A73721F84D4 for ; Sat, 1 Sep 2012 02:43:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 01 Sep 2012 11:43:09 +0200 From: Mikael Nordfeldth To: In-Reply-To: <1346468242.11151.YahooMailNeo@web31801.mail.mud.yahoo.com> References: <010901cd846c$95d74560$c185d020$@packetizer.com> <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com> <017001cd849e$cbdd9c90$6398d5b0$@packetizer.com> <028a01cd854f$c29a86f0$47cf94d0$@packetizer.com> <050232F8-4175-4698-95D7-17E4B35B1210@ve7jtb.com> <079201cd87df$a70ac4d0$f5204e70$@packetizer.com> <1346468242.11151.YahooMailNeo@web31801.mail.mud.yahoo.com> Message-ID: <86c033e390790aadf8d5da540f7f9e41@hethane.se> X-Sender: mmn@hethane.se User-Agent: Roundcube Webmail/0.7.1 Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 09:43:15 -0000 01.09.2012 04:57 skrev William Mills: > I'm in favor of mentioning legacy applications using XML and > referring to the original spec there, just to make it clear that > there > is an installed base. StatusNet and Diaspora are heavy users of Webfinger and seem to only support the XML version to date and the leading federated social web standards draft OStatus currently suggests all remote servers to support an application/xrd+xml SN: http://gitorious.org/statusnet/mainline/blobs/master/actions/hostmeta.php OS: http://ostatus.org/sites/default/files/ostatus-1.0-draft-2-specification.html D*: https://github.com/diaspora/diaspora/wiki/Diaspora%27s-federation-protocol Also, it is my belief XML is simply more extensible with its splendid namespacing in the case where an application may wish to deliver alternative, marked data from host-meta to avoid several requests. As mentioned previously in this thread, there's less adoption-trouble if the requirement to support both XRD and JRD is put on the server. Any reliably accessible server out there should reasonably be able to support both just because in its simplest form, host-meta is dead simple to convert. As a sidenote I do appreciate having a separate extension for the content-type. I.e. host-meta.json for json data, as it allows for static file structure and does not require dynamic interpretation of headers. Which definitely simplifes adoption. -- Mikael Nordfeldth http://blog.mmn-o.se/ mmn@hethane.se From mmn@hethane.se Sat Sep 1 02:59:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E675321F84F5 for ; Sat, 1 Sep 2012 02:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, HELO_EQ_SE=0.35, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZm8bin2UV+s for ; Sat, 1 Sep 2012 02:59:48 -0700 (PDT) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id 17EA121F84E4 for ; Sat, 1 Sep 2012 02:59:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sat, 01 Sep 2012 11:59:45 +0200 From: Mikael Nordfeldth To: In-Reply-To: <079201cd87df$a70ac4d0$f5204e70$@packetizer.com> References: "\"<010901cd846c$95d74560$c185d020$@packetizer.com> <1346084277.68046.YahooMailNeo@web31802.mail.mud.yahoo.com> <017001cd849e$cbdd9c90$6398d5b0$@packetizer.com> " " <028a01cd854f$c29a86f0$47cf94d0$@packetizer.com> <050232F8-4175-4698-95D7-17E4B35B1210@ve7jtb.com> <079201cd87df$a70ac4d0$f5204e70$@packetizer.com> Message-ID: <5ef59d28f16adb623743f72f242bb0e9@hethane.se> X-Sender: mmn@hethane.se User-Agent: Roundcube Webmail/0.7.1 Subject: Re: [apps-discuss] =?utf-8?q?Proposed_changes_to_WebFinger_regarding_?= =?utf-8?q?XML_vs=09JSON?= X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 09:59:49 -0000 01.09.2012 03:18 skrev Paul E. Jones: > I believe the group is leaning toward not having the appendix and > merely > indicating that JSON is the only format that is mandatory to > implement. > I’ll try to re-word it in that way. In all examples, I will use > host-meta.json. I do think it would be useful to discuss content > negotiation. I’ll mention that and provide an example. Host-meta > should > support content negotiation, in my opinion. However, since XML might > not be > implemented, a client may get nothing. It is important to remember that content-negotiation requires a more dynamic handling of server request. The Webfinger requests, in my view, MUST be fully compliant with a webserver that has _only_ static file fetching. My personal dream scenario is where 'host-meta' supports content-negotiation but 'host-meta.json' and 'host-meta.xml' could be used as fallbacks. > Making JSON the only MTI format does still give me a feeling of > uneasiness > since, as you note, every implementation right now is XML. This will > definitely break that. However, the push has been pretty strong to > go in > this direction. My own personal preference still remains that > servers > implement both, since it’s so darn simple to do. Despite all the "+1" messages "sent from my iPhone", I think support for the XML content-type is stronger than this mailing list currently portrays. The arguments for simple adoption are perfectly valid, though I only see them being an issue for client-side adoption. Server-side applications should have no problem supporting both XML and JSON, thus not at all impeding on adoptionability. > That said, we would still have a problem with existing servers if > they do > not support JSON and a client expected all servers support JSON. > Would > people feel ok with saying that servers should support both XRD and > JRD? Or > is the preference really JRD is MUST and XRD is MAY? I am totally in favor of this because, as you mentioned it is "darn simple to do". Using XRD also _greatly_ improves the integration of well-established implementations of user-centric communications networks like XMPP. If one had to implement a JSON parser in every XMPP server out there, it would be a heck of a lot more impeding on adoption than simply having a MUST support for both JRD and XRD server-side. I'm not saying XMPP currently implements Webfinger on any widely used deployment, only that it is a very likely future adoption. And would be much tougher if there was a risk you got zero data from a lookup. -- Mikael Nordfeldth http://blog.mmn-o.se/ mmn@hethane.se From alexey.melnikov@isode.com Sat Sep 1 14:39:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C50911E812F for ; Sat, 1 Sep 2012 14:39:00 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7O1WUp7B2Fx for ; Sat, 1 Sep 2012 14:38:59 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 49CCE11E8145 for ; Sat, 1 Sep 2012 14:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1346535537; d=isode.com; s=selector; i=@isode.com; bh=QwwByme4fm1l1qVupkBoPArAlzKlE1GEesO2K2Zjh5s=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=kbHK4CrqW/LwnZKu4SKq7ShsOSM31kBHh4WCPDDKf+zOeEiKjzCyLP7MvdtoD867L4vZeQ U/8QFTRsF+R18kSGjKJ57ea5TNdh8nJoJcwuXrLFp4TdFk3rlWUIyeJQ2dxdVqINe/YX4H md/fxGGRexH0pxXYpFUkl2dhEW5DASs=; Received: from [172.20.10.2] ((unknown) [212.183.128.234]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 1 Sep 2012 22:38:55 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <50426FFB.3010205@isode.com> Date: Sat, 01 Sep 2012 21:28:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Apps Discuss References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 21:39:00 -0000 On 31/08/2012 06:42, Barry Leiba wrote: > The IESG discussed draft-ietf-appsawg-http-forwarded-07 on this week's > teleconference (Thursday). The IESG evaluation record can be found > here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/ > > Stephen Farrell holds the main objections, but several other ADs agree > with him or with variants of his position. The main two points are > these: > (1) This is NOT a good thing to standardize, and we shouldn't. > (2) This causes a serious privacy exposure, so *if* we do standardize > it, we have to address that. > > After the telechat, Stephen switched his ballot from DISCUSS to > ABSTAIN. There are two other ABSTAIN positions. There also remain > three DISCUSS positions. The document cannot progress unless all > three of those DISCUSS positions are cleared *and* at least one of > them moves to NO OBJECTION (well, *and* that assumes that both ADs who > are on vacation come back and ballot NO OBJECTION as well). Just to explain to people less familiar with IETF process: the ABSTAIN position is basically "I have a philosophical disagreement with the editors/WG about this document and nothing you can do can change my mind. However I am not blocking the document from being published". ABSTAINs are somewhat better than DISCUSSes (because they don't need to be addressed, although editors should try to improve text in order to possible address expressed concerns), unless there are too many of them. > In short, this document is in serious trouble. > > To continue discussion, the IESG intends to have a teleconference with > the document authors, and perhaps with other proponents. If anyone > would like to actively participate in that discussion, please contact > me off list, and we'll see if we can add you -- we do need to keep it > small. Then we'll see if we have a way forward. From mnot@mnot.net Sun Sep 2 03:10:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C1A21F8966 for ; Sun, 2 Sep 2012 03:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.228 X-Spam-Level: X-Spam-Status: No, score=-105.228 tagged_above=-999 required=5 tests=[AWL=-2.629, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7ViBP7MmTDr for ; Sun, 2 Sep 2012 03:10:33 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 465C221F8957 for ; Sun, 2 Sep 2012 03:10:32 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E6CBF22E1F4; Sun, 2 Sep 2012 06:10:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: Date: Sun, 2 Sep 2012 20:10:22 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <1972D7F2-E7C1-4066-BC83-904D68C733F3@mnot.net> References: To: Barry Leiba X-Mailer: Apple Mail (2.1486) Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 10:10:34 -0000 So, are we going to discourage use of the Received header in SMTP now? On 31/08/2012, at 3:42 PM, Barry Leiba wrote: > The IESG discussed draft-ietf-appsawg-http-forwarded-07 on this week's > teleconference (Thursday). The IESG evaluation record can be found > here: = http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/ >=20 > Stephen Farrell holds the main objections, but several other ADs agree > with him or with variants of his position. The main two points are > these: > (1) This is NOT a good thing to standardize, and we shouldn't. > (2) This causes a serious privacy exposure, so *if* we do standardize > it, we have to address that. >=20 > After the telechat, Stephen switched his ballot from DISCUSS to > ABSTAIN. There are two other ABSTAIN positions. There also remain > three DISCUSS positions. The document cannot progress unless all > three of those DISCUSS positions are cleared *and* at least one of > them moves to NO OBJECTION (well, *and* that assumes that both ADs who > are on vacation come back and ballot NO OBJECTION as well). >=20 > In short, this document is in serious trouble. >=20 > To continue discussion, the IESG intends to have a teleconference with > the document authors, and perhaps with other proponents. If anyone > would like to actively participate in that discussion, please contact > me off list, and we'll see if we can add you -- we do need to keep it > small. Then we'll see if we have a way forward. >=20 > Barry > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From ned.freed@mrochek.com Sun Sep 2 09:57:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D8621F84C2 for ; Sun, 2 Sep 2012 09:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNAW4q1HHTQq for ; Sun, 2 Sep 2012 09:57:16 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id BC8A721F84BF for ; Sun, 2 Sep 2012 09:57:16 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJRY9MWJZ40073CC@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 2 Sep 2012 09:52:12 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Sun, 2 Sep 2012 09:52:07 -0700 (PDT) Message-id: <01OJRY9JYK8G0006TF@mauve.mrochek.com> Date: Sun, 02 Sep 2012 09:18:36 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 02 Sep 2012 20:10:22 +1000" <1972D7F2-E7C1-4066-BC83-904D68C733F3@mnot.net> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <1972D7F2-E7C1-4066-BC83-904D68C733F3@mnot.net> To: Mark Nottingham Cc: Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 16:57:17 -0000 > So, are we going to discourage use of the Received header in SMTP now? I have to agree with Mark here - the semantics of this field are similar to Received: in email, and as such have similar utility as well as privacy concerns (or perhaps non-concerns). However, there's actually a closer analogy in the case of email submission. When this is done through a proxy, it is in many cases essential that client identity information be passed through so that appropriate security checks cna be made. There is presently no standarized mechanism for this, and what happens in practice is that RFPs are written requiring one of the various ad-hoc mechanisms out there, e.g., Postfix's XCLIENT command. It's pretty much the same situation as exists with X-Forwarded-For, X-Forwarded-By, and X-Forwarded-Proto. (And yes, you'd be correct in thinking that I beieve that standards action is needed in this area.) And this in turn points to a particularly pernicious form of magical thinking the IETF often engages in that I have to say I find to be particularly annoying: The notion that both the presence and absence of a standard for something are imbued with special powers. In this particular case it's the apparent belief that someone is going to say, "The IETF hasn't standardized this so it must be a bad idea so let's not do it." The reality, of course, is that all the lack of a standard for this has done is created an interoperability mess. And by not having a clear set of rules for doing it as well as a specification that details the security implications, the present situation is far more likely to have caused security problems than prevented them. As for the IESG comments themselves, most these folks seem to have missed the OPTIONAL nature of this field. Of course a proxy that is being operated in whole or in part for purposes of providing client anonymity MUST NOT insert it! If we really need to make such an obvious statement, then let's please just make it: Put something like this in the security considerations: The entire purpose of a proxy inserting "Forwarded" field is to expose client identification to the server that would otherwise be unavailable. As such, proxies that wish to provide client anonymity MUST NOT insert a "Forwarded" field. Ned From paul.hoffman@vpnc.org Sun Sep 2 11:06:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1B121F84DF for ; Sun, 2 Sep 2012 11:06:13 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uy3HxYuMe4mP for ; Sun, 2 Sep 2012 11:06:12 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD5E21F84AE for ; Sun, 2 Sep 2012 11:06:12 -0700 (PDT) Received: from [165.227.249.211] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q82I63pj077585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Sep 2012 11:06:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Paul Hoffman In-Reply-To: <01OJRY9JYK8G0006TF@mauve.mrochek.com> Date: Sun, 2 Sep 2012 11:06:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1972D7F2-E7C1-4066-BC83-904D68C733F3@mnot.net> <01OJRY9JYK8G0006TF@mauve.mrochek.com> To: Apps Discuss X-Mailer: Apple Mail (2.1486) Cc: Barry Leiba Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 18:06:13 -0000 On Sep 2, 2012, at 9:18 AM, Ned Freed wrote: > As for the IESG comments themselves, most these folks seem to have = missed the > OPTIONAL nature of this field. Of course a proxy that is being = operated in > whole or in part for purposes of providing client anonymity MUST NOT = insert it! There are three outstanding DISCUSS comments, and at least one seems = predicated not on that but on the lack of description for the value of = this field. Adrian Farrel says: =3D=3D=3D=3D=3D I think it is unfortunate that this document does not give any explanation of why it is desirable to expose the information that is lost during proxying and which the proposed extensions make available. It is normal for work in the IETF to be presented along with some motivations based on utility. While it is quite clear that the proposed mechanism would work to provide the function described, it is a mystery why any proxy would implement it or consider the extension valuable. =3D=3D=3D=3D=3D One or two paragraphs in the Introduction should suffice. > If we really need to make such an obvious statement, then let's please = just > make it: Put something like this in the security considerations: >=20 > The entire purpose of a proxy inserting "Forwarded" field is to = expose > client identification to the server that would otherwise be = unavailable. > As such, proxies that wish to provide client anonymity MUST NOT > insert a "Forwarded" field. +1 --Paul Hoffman= From ned.freed@mrochek.com Sun Sep 2 12:13:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E034321F84E6 for ; Sun, 2 Sep 2012 12:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcHT+VbNNJPI for ; Sun, 2 Sep 2012 12:13:43 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3A96921F84A7 for ; Sun, 2 Sep 2012 12:13:43 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJS30TD58G006US5@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 2 Sep 2012 12:08:38 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Sun, 2 Sep 2012 12:08:33 -0700 (PDT) Message-id: <01OJS30QN9SW0006TF@mauve.mrochek.com> Date: Sun, 02 Sep 2012 11:52:12 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 02 Sep 2012 11:06:05 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <1972D7F2-E7C1-4066-BC83-904D68C733F3@mnot.net> <01OJRY9JYK8G0006TF@mauve.mrochek.com> To: Paul Hoffman Cc: Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 19:13:44 -0000 > On Sep 2, 2012, at 9:18 AM, Ned Freed wrote: > > As for the IESG comments themselves, most these folks seem to have missed the > > OPTIONAL nature of this field. Of course a proxy that is being operated in > > whole or in part for purposes of providing client anonymity MUST NOT insert it! > There are three outstanding DISCUSS comments, and at least one seems predicated not on that but on the lack of description for the value of this field. Adrian Farrel says: > ===== > I think it is unfortunate that this document does not give any > explanation of why it is desirable to expose the information that is > lost during proxying and which the proposed extensions make available. > It is normal for work in the IETF to be presented along with some > motivations based on utility. While it is quite clear that the proposed > mechanism would work to provide the function described, it is a > mystery why any proxy would implement it or consider the extension > valuable. > ===== > One or two paragraphs in the Introduction should suffice. OK, if Captain Obvious needs to fly to the rescue again, so be it. How about something like: Uses of the information provided by "Forwarded" fields include, but are not limited to: Logging, access control, and rate limits. I'm sure there are more, but these all seem like obvious uses to me. (They definitely are how XCLIENT and similar mechanisms are regularly used in email.) Of course once if we head down this path we may be risking arguments about the appropriateness of using IP addresses or whatever for these purposes, but the reality is they are used that way. Come to think of it, this also provides a response to one of the other IESG comments, which was a request to provide a means of providing only an address prefix rather than an entire address. Consideration of only part of an address is of course entirely appropriate in many cases, but that's really a job for the agent consuming the information. Doing it at the proxy spreads network configuration around unnecessarily and complicates management. Whereas the only real benefit to partial addresses that I see would be in some sort of situation where the proxy and server are separately administered and the proxy trusts the server to the extent of being willing to provide part of an address but not to the extent of providing the whole thing. I'm having difficulty envisioning a real use case of sufficient utility to outweigh the "bad idea" aspects. Ned From paul.hoffman@vpnc.org Sun Sep 2 13:43:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A0721F8498 for ; Sun, 2 Sep 2012 13:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnGiW0uaEnf9 for ; Sun, 2 Sep 2012 13:43:09 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9E58321F847F for ; Sun, 2 Sep 2012 13:42:46 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q82KgeiW045486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Sep 2012 13:42:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Paul Hoffman In-Reply-To: <01OJS30QN9SW0006TF@mauve.mrochek.com> Date: Sun, 2 Sep 2012 13:42:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <03BAF4AA-C350-41D0-BD9D-FC6389873C84@vpnc.org> References: <1972D7F2-E7C1-4066-BC83-904D68C733F3@mnot.net> <01OJRY9JYK8G0006TF@mauve.mrochek.com> <01OJS30QN9SW0006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1486) Cc: Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 20:43:10 -0000 On Sep 2, 2012, at 11:52 AM, Ned Freed wrote: > OK, if Captain Obvious needs to fly to the rescue again, so be it. How = about > something like: >=20 > Uses of the information provided by "Forwarded" fields include, but = are=20 > not limited to: Logging, access control, and rate limits. >=20 Playing the good captain's sidekick, I would propose adding: "The uses = of the "Forwarded" fields described here for HTTP are similar to the = many uses that the "Received" fields in SMTP messages have provided for = decades." --Paul Hoffman= From john-ietf@jck.com Sun Sep 2 14:02:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300C021F84D2 for ; Sun, 2 Sep 2012 14:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqR-MbjYrWmO for ; Sun, 2 Sep 2012 14:02:20 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id A2ED221F84DE for ; Sun, 2 Sep 2012 14:02:20 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1T8HJ7-0007Yd-CR; Sun, 02 Sep 2012 17:02:13 -0400 X-Vipre-Scanned: 04904B6F002C3104904CBC-TDI Date: Sun, 02 Sep 2012 17:02:12 -0400 From: John C Klensin To: Paul Hoffman , Ned Freed Message-ID: In-Reply-To: <03BAF4AA-C350-41D0-BD9D-FC6389873C84@vpnc.org> References: <1972D7F2-E7C1-4066-BC83-904D68C733F3@mnot.net> <01OJRY9JYK8G0006TF@mauve.mrochek.com> <01OJS30QN9SW0006TF@mauve.mrochek.com> <03BAF4AA-C350-41D0-BD9D-FC6389873C84@vpnc.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 21:02:21 -0000 --On Sunday, September 02, 2012 13:42 -0700 Paul Hoffman wrote: >> Uses of the information provided by "Forwarded" fields >> include, but are not limited to: Logging, access control, >> and rate limits. >> > > Playing the good captain's sidekick, I would propose adding: > "The uses of the "Forwarded" fields described here for HTTP > are similar to the many uses that the "Received" fields in > SMTP messages have provided for decades." Paul, Because of some locus of control differences in the way proxies are configured versus the way mail relays are, I think that, beyond a certain point, the analogy is actually debatable. Unless we want to have that debate for some reason, I'd suggest leaving the lily ungilded. john From stephen.farrell@cs.tcd.ie Sun Sep 2 14:29:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1CE21F84DC for ; Sun, 2 Sep 2012 14:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cSFhA-kX5Po for ; Sun, 2 Sep 2012 14:29:02 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 036FC21F84D5 for ; Sun, 2 Sep 2012 14:29:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 167AC17147B; Sun, 2 Sep 2012 22:28:56 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346621335; bh=eJX8b40hA1ZXOu sCmsdd8zIKjmuu9v2MvBWhksn2EIM=; b=NQMlDVqhiLYfYqurTi9EUoCfTXZcVO HZO1L3Jc05HtxOvZJ/0vuy6j6JqYl1WCtTcMOtSH3Kf80VqhWlkyU9I3W3YgFZy9 RxwBMKK7XN/Ng39RiyIHb3DlrCc8RmznHOqBX6bC6y9vr7w7PQXxTGhL93GREhNB UieOIUYHiFgivA8qeN7yfq73sgt+CmVWe4ngP+LoFx/D6rXtJ8ohSbY6iP1vtW1x sgcXD/bdGdO29AS11BKR9ZkSzstEkXanq74Q8ob4lcqSR/UCGiceEp5Uf/W457f/ xEtXfx7a/jaMn28elVFs0Jkpa38T1dlQTOEeK6miHrZFd1syhwFSCc3g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id cTcvDZOvfcWB; Sun, 2 Sep 2012 22:28:55 +0100 (IST) Received: from [10.87.48.9] (unknown [86.41.3.101]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 5F30A171474; Sun, 2 Sep 2012 22:28:52 +0100 (IST) Message-ID: <5043CF94.5090805@cs.tcd.ie> Date: Sun, 02 Sep 2012 22:28:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ned Freed References: <1972D7F2-E7C1-4066-BC83-904D68C733F3@mnot.net> <01OJRY9JYK8G0006TF@mauve.mrochek.com> <01OJS30QN9SW0006TF@mauve.mrochek.com> In-Reply-To: <01OJS30QN9SW0006TF@mauve.mrochek.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Barry Leiba , Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 21:29:08 -0000 On 09/02/2012 11:10 AM, Mark Nottingham wrote: > So, are we going to discourage use of the Received header in SMTP now? Actually I don't agree that XFF and Received are such a close analogy. But I don't think we need to go there. On 09/02/2012 07:52 PM, Ned Freed wrote: > > ... How about > something like: > > Uses of the information provided by "Forwarded" fields include, but are > not limited to: Logging, access control, and rate limits. Other uses that have been mentioned in discussion with the IESG include: - dealing with wrongly localized pages - requests you get for end user identity from law enforcement - IP-based lockout along the lines Wikipedia use If we were really designing a solution for all that then I don't think we'd end up with XFF. But we're being asked to standardise essentially a fixed-up XFF when IMO we'd be better off not doing that but figuring out what is needed (that could be more privacy friendly) and then specifying that. Or else just document what's already in use and how its used. I also reckon that different people have very different opinions as to whether there are privacy issues with this spec. For me that makes it unlikely that we should ask Captain obvious to handle this one:-) S. PS: Since I'm abstaining on this, I'm not blocking it, but I also didn't take a vow of silence:-) From hannes.tschofenig@gmx.net Sun Sep 2 23:42:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE3321F84A6 for ; Sun, 2 Sep 2012 23:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWwKxY0G3mJi for ; Sun, 2 Sep 2012 23:42:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9BDB321F8440 for ; Sun, 2 Sep 2012 23:42:04 -0700 (PDT) Received: (qmail invoked by alias); 03 Sep 2012 06:42:03 -0000 Received: from unknown (EHLO [10.255.131.197]) [194.251.119.201] by mail.gmx.net (mp002) with SMTP; 03 Sep 2012 08:42:03 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/HUIhHlurHvFyYSnyW9XfBgbiHYH3nRNuC/kX7op 7SFVaq1TkWTNzS Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <20120831075430.GA28281@1wt.eu> Date: Mon, 3 Sep 2012 09:41:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Apps Discuss , Barry Leiba Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 06:42:05 -0000 Hi Willy,=20 On Aug 31, 2012, at 10:54 AM, Willy Tarreau wrote: > It's just like saying that we should > forbid eating with forks and knifes in restaurants because some people > might use the knife to kill their noisy neighbour. Everything which is > created has good and bad usages.=20 This is a common response: engineers tell you that they are just = producing tools -- they are not responsible for how they are used (even = though they very well know how these tools are used). Those who deploy = then argue that this is what has been given to them - the industry best = current practice. Nothing can be done to improve the privacy (or = security) of the system.=20 I am trying to figure out what your views are.=20 Are you saying that=20 * there are no privacy requirements that need to be addressed?=20 * you do not understand what those privacy requirements are?=20 * you believe that these privacy requirements are not applicable?=20 Ciao Hannes From hannes.tschofenig@gmx.net Sun Sep 2 23:46:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356B921F84AE for ; Sun, 2 Sep 2012 23:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUCr8WQY3g0m for ; Sun, 2 Sep 2012 23:46:52 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 18FE621F84A6 for ; Sun, 2 Sep 2012 23:46:51 -0700 (PDT) Received: (qmail invoked by alias); 03 Sep 2012 06:46:50 -0000 Received: from unknown (EHLO [10.255.131.197]) [194.251.119.201] by mail.gmx.net (mp029) with SMTP; 03 Sep 2012 08:46:50 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1++gakcgXm+ySvQD3Hg9DqvWAKyKnmfj4rHP8k5fX ogNgQvCpSK/gYC Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <20120831125237.3c978218@hetzer> Date: Mon, 3 Sep 2012 09:46:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8A96C5EA-9E25-4918-880B-EFE42A66B590@gmx.net> References: <20120831062013.GA27979@1wt.eu> <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831125237.3c978218@hetzer> To: Andreas Petersson X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 06:46:53 -0000 Hi Andreas,=20 On Aug 31, 2012, at 1:52 PM, Andreas Petersson wrote: > On Fri, 31 Aug 2012 10:39:54 +0300 > "Tschofenig, Hannes (NSN - FI/Espoo)" = wrote: >=20 >> Eliot,=20 >>=20 >> The reverse proxy story is a way to make this look good and we know = it >> will be used otherwise.=20 >>=20 >> I don't know why aren't acknowledging that there are privacy concerns = as >> well even if they are inconvenient for an engineer. Just adding = fluffy >> and warm text does not make these concerns go away. I think we are >> cheating here.=20 >>=20 >=20 > Have you read the section "Privacy Considerations"? >=20 The privacy consideration section to me reads as follows: "Yes, we have = heard about privacy concerns. This technology has been deployed already. = As such, nothing can be done anymore. Sorry." Ciao Hannes >=20 > /Andreas Petersson > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From hannes.tschofenig@gmx.net Sun Sep 2 23:52:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B819D21F84B9 for ; Sun, 2 Sep 2012 23:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0li11LWfUzx8 for ; Sun, 2 Sep 2012 23:52:32 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9FA1221F84B6 for ; Sun, 2 Sep 2012 23:52:31 -0700 (PDT) Received: (qmail invoked by alias); 03 Sep 2012 06:52:30 -0000 Received: from unknown (EHLO [10.255.131.197]) [194.251.119.201] by mail.gmx.net (mp071) with SMTP; 03 Sep 2012 08:52:30 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+9VKlS5Rm9cIx8Ag1/aaicitr/TxNlLWwUAE3gr1 1r/jZXkZrZ8Gwo Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <5040737D.9000902@cisco.com> Date: Mon, 3 Sep 2012 09:52:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8352173B-F002-4395-86A3-859DA8CE6AF9@gmx.net> References: <20120831062013.GA27979@1wt.eu> <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <5040737D.9000902@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Apps Discuss , Willy Tarreau , Barry Leiba Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 06:52:32 -0000 Hi Eliot,=20 On Aug 31, 2012, at 11:19 AM, Eliot Lear wrote: >=20 > On 8/31/12 9:39 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Eliot,=20 >>=20 >> The reverse proxy story is a way to make this look good and we know = it >> will be used otherwise.=20 >=20 > I think you are concerned that an ill informed national policy might > require the use of this header, such that it exposes PII to = UNAUTHORIZED > people. It's not that you're thinking that enterprise administrators > will have removed their brains and simply would allow this sort of > exposure. Is that correct? If so, I understand and share this = concern, > and it should be documented that this is the wrong lever and can lead = to > serious security problems, if used on an outbound proxy. Yes, that's one concern that I have. It is not that providers do these = types of stuff because they have their brains removed (as you call it) = but there are in their views very valid reasons to do so. Some of these = reasons are driven by the desire to make business. In any case the lack = of transparency, missing consent and missing ability for users to state = their preferences is the problem.=20 Btw, I also like the writeup in http://www.ietf.org/rfc/rfc3238.txt = since it captures some of the concerns quite well.=20 In general, there seems to be the excitement by some group of people = (particularly those who work for network equipment manufacturers) to = develop solutions that do not involve the end point (and consequently = the user) in exchange. Those tend to raise privacy concerns, regardless = of whether it is media recording, media transcoding, "security = features", etc.=20 >=20 > As I understand it, you and Alissa just released a brand new related = RFC > on this topic relating to GEOPRIV, by the way. Congratulations! Thanks.=20 Ciao Hannes >=20 > Eliot > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From hannes.tschofenig@gmx.net Sun Sep 2 23:55:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A6321F84A7 for ; Sun, 2 Sep 2012 23:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh8aPwpAUpMA for ; Sun, 2 Sep 2012 23:55:36 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1DC1321F84A6 for ; Sun, 2 Sep 2012 23:55:35 -0700 (PDT) Received: (qmail invoked by alias); 03 Sep 2012 06:55:34 -0000 Received: from unknown (EHLO [10.255.131.197]) [194.251.119.201] by mail.gmx.net (mp034) with SMTP; 03 Sep 2012 08:55:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18c0zw7/bscy/w7yZ4O7KmK/qMIbTgONtEXxLnjI2 00nnfY2c4ZwoUr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <5040BF9A.80003@gmx.de> Date: Mon, 3 Sep 2012 09:55:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4C939823-DE1E-4B15-8302-5DA5A99FAD77@gmx.net> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <5040ABD7.6040300@cs.tcd.ie> <20120831124940.GB28461@1wt.eu> <5040B615.8020603@cs.tcd.ie> <20120831130855.GC28461@1wt.eu> <5040B910.6070705@cs.tcd.ie> <20120831133221.GD28461@1wt.eu> <5040BF9A.80003@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Apps Discuss , Willy Tarreau , Barry Leiba Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 06:55:37 -0000 Julian, this is the approach the IETF had done with lawful intercept = work.=20 See http://tools.ietf.org/html/rfc2804 On Aug 31, 2012, at 4:43 PM, Julian Reschke wrote: > On 2012-08-31 15:32, Willy Tarreau wrote: >> ... >>> I did. I meant that just because something is deployed is not >>> by itself sufficient reason to standardise (a less buggy version >>> of) that thing. >>=20 >> It's not because it's deployed, It's because there is a real need and >> without any standard, interoperability issues are created. >>=20 >> In turn, I don't see why addressing issues in something which already >> exists should be wrong and discouraged. >> ... >=20 > +1 >=20 > The alternative is to take the draft, publish it elsewhere, and have = the header field name registered anyway. >=20 > Best regards, Julian > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From hannes.tschofenig@gmx.net Mon Sep 3 00:12:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8476B21F84AE for ; Mon, 3 Sep 2012 00:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ndfPVmQg-Su for ; Mon, 3 Sep 2012 00:12:34 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id F12B221F84A2 for ; Mon, 3 Sep 2012 00:12:33 -0700 (PDT) Received: (qmail invoked by alias); 03 Sep 2012 07:12:32 -0000 Received: from unknown (EHLO [10.255.131.197]) [194.251.119.201] by mail.gmx.net (mp024) with SMTP; 03 Sep 2012 09:12:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18dO3ckvyMdvzQ9/Sh/u9urkAOyd6BbrUyiq4qq2x i1q+/Fu4HjeHgG Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <20120831133221.GD28461@1wt.eu> Date: Mon, 3 Sep 2012 10:12:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0EEB896D-E45C-4C1D-9E4E-61D27D645975@gmx.net> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <5040ABD7.6040300@cs.tcd.ie> <20120831124940.GB28461@1wt.eu> <5040B615.8020603@cs.tcd.ie> <20120831130855.GC28461@1wt.eu> <5040B910.6070705@cs.tcd.ie> <20120831133221.GD28461@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Apps Discuss , Barry Leiba Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 07:12:35 -0000 Willy,=20 see the entire discussion from an abstract point of view. When you = design a solution there are different assumptions, preferences and = requirements that get thrown together. The challenge is then to navigate = through this solution space.=20 =46rom what I can tell your approach is as follows:=20 " If solution is deployed=20 then=20 skip other requirements=20 else=20 look at the requirements. "=20 Wouldn't it be useful to also look at some of these requirements that = others are raising? You refer to security laws and those seem to matter = for you but for some reason privacy laws do not count. That's an = interesting way to pick requirements. (I personally prefer to generalize = a bit and not to refer to specific laws.) To illustrate my point let me pick a completely different example. You = work on security and you know that credit cards aren't the world best = authentication mechanism. Following your approach of standardization we = would have to standardize credit cards. They are widely deployed and = users seem to like them as well (because they are easy to use). Still, = wouldn't it be useful to come up with a different mechanism that = fulfills additional requirements (for security and privacy)? One could, = for example, argue that the choice of selecting the "username" to be = also the password wasn't such a great idea. Of course, if you work as a = PCI DSS auditor, then that was clearly the greatest thing ever.=20 Ciao Hannes On Aug 31, 2012, at 4:32 PM, Willy Tarreau wrote: > On Fri, Aug 31, 2012 at 02:16:00PM +0100, Stephen Farrell wrote: >>> All people working on the server side are already convinced about = that, >>> they're all facing the same interoperability issues and they need it >>> for logging purposes (at least). >>=20 >> That last is kinda vague though isn't it? >=20 > How is the need for server-side logging something vague ? It's = mandatory > by law in a number of places (maybe everywhere ?) and is one of the > basic security requirements. Most servers require this also to protect > against abuse. I won't make the insult of presenting what purposes a > server has of its visitor's IP address, we all have such requirements. >=20 >>>> I suspect its really a different document entirely that >>>> documents current XFF implementation and deployment >>>> practices. I reckon that text might be a good bit longer >>>> than the entire current draft. >>>=20 >>> It would not be wise to document wrong practices of non-standard = header >>> fields which do not respect the standardized header field format. = HTTP >>> is crappy enough to avoid adding another exception on top of it. >>=20 >> I don't get how that squares with what you said earlier: >>=20 >> "And I see this draft as an opportunity >> to remind implementors about what to do and what not to do. >> Right now, they're acting blindly, deploying their proxies >> without even knowing that they're sending xff to the whole >> world." >=20 > Right now this is something needed but not documented since not > standardized. Some people even point me to wikipedia to explain > to me what they're trying to achieve! So they tend to use default > settings from the products they use, and there are not two similar > behaviours across products so there is no good nor bad practice. > I have already seen XFF being emitted by outgoing proxies and I > had to explain the admin what to do to avoid this. >=20 >>>> I do get the point but I don't agree that just because a >>>> buggy <> has been deployed means we ought to standardise >>>> <> without those bugs. >>>=20 >>> I don't get your point here, sorry. I read it as "we failed = somewhere, >>> let's not fix it because it already exists" so I assume you meant >>> something else :-/ >>=20 >> I did. I meant that just because something is deployed is not >> by itself sufficient reason to standardise (a less buggy version >> of) that thing. >=20 > It's not because it's deployed, It's because there is a real need and > without any standard, interoperability issues are created. >=20 > In turn, I don't see why addressing issues in something which already > exists should be wrong and discouraged. >=20 > Regards, > Willy >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From fanf2@hermes.cam.ac.uk Mon Sep 3 05:11:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8218421F8512 for ; Mon, 3 Sep 2012 05:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.337 X-Spam-Level: X-Spam-Status: No, score=-6.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XZBvWfl3KUb for ; Mon, 3 Sep 2012 05:11:53 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 3274321F8499 for ; Mon, 3 Sep 2012 05:11:42 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:41209) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1T8VVA-0008BY-ra (Exim 4.72) (return-path ); Mon, 03 Sep 2012 13:11:36 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1T8VVA-00056v-J8 (Exim 4.72) (return-path ); Mon, 03 Sep 2012 13:11:36 +0100 Date: Mon, 3 Sep 2012 13:11:36 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Paul Hoffman In-Reply-To: <03BAF4AA-C350-41D0-BD9D-FC6389873C84@vpnc.org> Message-ID: References: <1972D7F2-E7C1-4066-BC83-904D68C733F3@mnot.net> <01OJRY9JYK8G0006TF@mauve.mrochek.com> <01OJS30QN9SW0006TF@mauve.mrochek.com> <03BAF4AA-C350-41D0-BD9D-FC6389873C84@vpnc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Barry Leiba , Ned Freed , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 12:11:54 -0000 Paul Hoffman wrote: > On Sep 2, 2012, at 11:52 AM, Ned Freed wrote: > > > OK, if Captain Obvious needs to fly to the rescue again, so be it. How about > > something like: > > > > Uses of the information provided by "Forwarded" fields include, but are > > not limited to: Logging, access control, and rate limits. > > Playing the good captain's sidekick, I would propose adding: "The uses > of the "Forwarded" fields described here for HTTP are similar to the > many uses that the "Received" fields in SMTP messages have provided for > decades." I think that's going too far. Received: lines are mosly designed for human consumption, whereas X-Forwarded-For: is for automated use. So spam filters that parse Received: headers have a horrible time of it, and (as Ned implied) MTAs usually use private SMTP extensions for the kind of thing he listed above, not Received: headers. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From barryleiba@gmail.com Mon Sep 3 06:22:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5DB21F8559 for ; Mon, 3 Sep 2012 06:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.016 X-Spam-Level: X-Spam-Status: No, score=-103.016 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8C6s2P1zsHE for ; Mon, 3 Sep 2012 06:22:13 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 71D8C21F8564 for ; Mon, 3 Sep 2012 06:22:13 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6219652vbb.31 for ; Mon, 03 Sep 2012 06:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=uLjC0D+YuMwyKpzTuRUDqwMLtmZi9uNgP6rUPji6MVE=; b=FtVQVnk8dIUhh7O0GnsFcHOoNhKEqMXMn87B0m3t+sfTQSq48tKCCpRpzXCh+U1tYE hs41mvJs4VkNDDytjBIz4sUpl1m4I/IAt3KEeFyvXxp6sDOSduPTlSYpU1HJh10EGUz5 VQ8z3bRKgyjtMJAwc3+Sk6wXA8DvsIXx4TB1GNiU1KBq+73egDopVX+3PkOJ6o1BUSvl w6Eu6y4Z2aNi6pWrL0SPJmbTiNvx1YiXyBS4kjDIFvg3Up96MqOE42EHVZIJvvUFVgNu +DbsfYQ9GoUBPB4U3mW6qCrtegyFtOyX3LyN8sQchQk7dKIOROr9b6LZYmAibei+/AgS NaUA== MIME-Version: 1.0 Received: by 10.221.13.72 with SMTP id pl8mr12384900vcb.5.1346678532402; Mon, 03 Sep 2012 06:22:12 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.58.41 with HTTP; Mon, 3 Sep 2012 06:22:12 -0700 (PDT) In-Reply-To: <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> Date: Mon, 3 Sep 2012 09:22:12 -0400 X-Google-Sender-Auth: 6fZDaJAE2bPfNmBNc9lhUwrV6rE Message-ID: From: Barry Leiba To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 13:22:14 -0000 > Those who deploy then argue that this is what has been given to them - the > industry best current practice. Nothing can be done to improve the privacy > (or security) of the system. OK, so let's start by getting rid of that strawman: This spec does say that this is an optional header field, and does say something about when you might not use it. If someone wants it to say more about that, I'm sure that can happen, but see below. Answering for myself, of course, not Willy: > Are you saying that > * there are no privacy requirements that need to be addressed? > * you do not understand what those privacy requirements are? > * you believe that these privacy requirements are not applicable? I think, as I have said before, that we have two information flows involved here: 1. client -> server 2. client -> *proxy -> server In flow 1, the server already gets all the information that this header field provides, without any use of this header field. In flow 2, the first proxy gets all the information, but subsequent proxies and the server get this same information about the previous proxy. This header field allows (doesn't require, but allows) the proxies to relay the information about the client, along with the client's request, *which the server would have anyway if the proxies were not involved*. Therefore, I think this *does not cause a privacy exposure* in the general case of the proxy that's meant to simply relay the client's request. The fact that the proxies have caused some of that information to be lost has been accidental (and often undesirable). It has not been a *design* of the proxies, not a *reason* that the proxies are there. The *only* case where the situation is otherwise is when the proxy is there *for the purpose* of hiding this information. Where the user *expects* the proxy to provide a privacy shield. I believe that all this document needs to do about this whole situation is a. Describe the privacy aspects of the information passed in this header field. b. Describe the use cases for the protection of that information (privacy shield use). c. Make it clear that when those use cases are applicable, this feature shouldn't be used (or MUST NOT, or whatever). d. Make it clear that because the information can be passed on in other ways, including through this feature, it's important to establish a trust relationship with the proxy whenever a proxy is being used for those use cases. Barry From laurentwalter.goix@telecomitalia.it Mon Sep 3 07:00:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BC821F8598 for ; Mon, 3 Sep 2012 07:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyLn3gu3Jh-D for ; Mon, 3 Sep 2012 07:00:05 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6384421F8550 for ; Mon, 3 Sep 2012 07:00:04 -0700 (PDT) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.245.1; Mon, 3 Sep 2012 15:59:55 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Mon, 3 Sep 2012 15:59:55 +0200 From: Goix Laurent Walter To: "Paul E. Jones" , =?utf-8?B?J+KYriBlbGYgUGF2bGlrIOKYric=?= , 'Peter Saint-Andre' Date: Mon, 3 Sep 2012 15:59:54 +0200 Thread-Topic: [apps-discuss] R: Comment on draft-ietf-appsawg-acct-uri-00.txt Thread-Index: AQHQkPRpqE241VMBhFX0b1E5n3icagGmT2cgAfxtLQICXYfDzwLd38ExAfCD3o0CSm6TWwHz+GlOAlI3tJgCXV8wQQGG1ghXlsR96HCAA/LjgA== Message-ID: References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <1346172875-sup-9676@heahdk.net> <503D04E5.1090506@stpeter.im> <1346176849-sup-3504@heahdk.net> <047b01cd860f$d31f7ce0$795e76a0$@packetizer.com> <079001cd87de$4ba00480$e2e00d80$@packetizer.com> In-Reply-To: <079001cd87de$4ba00480$e2e00d80$@packetizer.com> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: 'apps-discuss' Subject: [apps-discuss] R: R: Comment on draft-ietf-appsawg-acct-uri-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 14:00:06 -0000 SGVsbG8gUGF1bCwNCj4NCj4gV2FsdGVyLA0KPg0KPiA+IEkgYWdyZWUgaXQgaXMgIm1vcmUgb3Ig bGVzcyIgdGhlIHNhbWUgYXQgdGhlIGVuZC4gSG93ZXZlciBJIGV4cGVjdCB0aGF0DQo+ID4gZnJv bSBjdXJyZW50IGltcGxlbWVudGF0aW9ucyBvZiB3ZWJmaW5nZXIsIHZlcnkgbGl0dGxlIGxpbmsg cmVscyBhcmUNCj4gPiBwcm92aWRlZCBpbiB0aGUgaG9zdC1tZXRhIHZzIHJlc291cmNlLXNwZWNp ZmljIGRlc2NyaXB0b3Igc28gcHV0dGluZyBtYW55DQo+ID4gdGVtcGxhdGVzIGluIHRoZSBob3N0 LW1ldGEgYWxyZWFkeSBpcyBub3QgYmVzdCBwcmFjdGljZSB5ZXQgYWZhaWsuDQo+ID4gT2YgY291 cnNlIG5vdGhpbmcgcHJldmVudHMgZnJvbSBjaGFuZ2luZyB0aGlzIGJlaGF2aW91ciBpbiB0aGUg ZnV0dXJlIGJ1dA0KPiA+IGFzIHRoaXMgc2NlbmFyaW8gbWF5IGJlY29tZSBtYWluc3RyZWFtIChJ IGRvIGhvcGUgdGhhdCBpbiBhIGZldyB5ZWFycyB2ZXJ5DQo+ID4gYmlnIHNvY2lhbCBpc2xhbmRz IHdpbGwgd2ViZmluZ2VyIGVhY2ggb3RoZXIpLg0KPiA+DQo+ID4gVGh1cyBJIGFtIHdvbmRlcmlu ZyB3aGV0aGVyIGl0IGNvdWxkIG1ha2Ugc2Vuc2U6DQo+ID4gLSBhZGRpbmcgaXQgYXMgYW4gZXhh bXBsZSBpbiB0aGUgZHJhZnQgY2xhcmlmeWluZyB0aGUgcHJhY3RpY2UgYW5kDQo+ID4gZW1waGFz aXppbmcgdGhlIGluc2VydGlvbiBvZiBhZGRpdGlvbmFsIGxpbmsgcmVsIHRlbXBsYXRlcyBhbHJl YWR5IGluIHRoZQ0KPiA+IGhvc3QtbWV0YQ0KPg0KPiBJIGNvdWxkIGNlcnRhaW5seSBzaG93IGFu IGV4YW1wbGUgc2ltaWxhciB0byB3aGF0IGlzIGluIFJGQyA2NDE1IFNlY3Rpb24gMS4xLA0KPiBw ZXJoYXBzIGFkZGluZyBhZGRpdGlvbmFsIGhvc3Qtd2lkZSBwcm9wZXJ0aWVzIGFuZCBsaW5rIHJl bGF0aW9ucy4gIEhvd2V2ZXIsDQo+IEknbSBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5ICJlbXBo YXNpemluZyB0aGUgaW5zZXJ0aW9uIG9mIGFkZGl0aW9uYWwgbGluaw0KPiByZWwgdGVtcGxhdGVz Ii4gIEhvc3Qtd2lkZSBpbmZvcm1hdGlvbiB1c2VzIGxpbmsgcmVsYXRpb25zLCBub3QgdGVtcGxh dGVzLg0KPiBUZW1wbGF0ZXMgYXJlIHVzZWQgZm9yIHJlc291cmNlLXNwZWNpZmljIGluZm9ybWF0 aW9uLg0KDQpbd2FsdGVyXSB3ZWxsIHRoZSBleGFtcGxlIGNvdWxkIGlsbHVzdHJhdGUgaG93IHRv IGZvbGxvdyBzb21lb25lIG9uIGEgInJlbW90ZSBkb21haW4iLCBzaG93aW5nIHRoZSB3ZWJmaW5n ZXIgcXVlcnkgZnJvbSBzZXJ2ZXIxIHRvIHNlcnZlcjIuIEluIHRoYXQgY2FzZSB0aGUgeHJkL2py ZCBmb3IgdGhlIGhvc3QtbWV0YSBjb3VsZCBzaG93IGEgbGlzdCBvZiBsaW5rIHJlbHMgInR5cGlj YWwiIG9mIHRoaXMgZXhhbXBsZSAoZmVkZXJhdGVkIHNvY2lhbCBuZXR3b3JrcyksIHN1Y2ggYXMg Imh0dHA6Ly93ZWJmaW5nZXIubmV0L3JlbC9hdmF0YXIiLCAiaHR0cDovL3NjaGVtYXMuZ29vZ2xl LmNvbS9nLzIwMTAjdXBkYXRlcy1mcm9tIiwgInNhbG1vbiIsICJodHRwOi8vcG9ydGFibGVjb250 YWN0cy5uZXQvc3BlYy8xLjAiIGFuZCB0aGUgcmVsYXRlZCB0ZW1wbGF0ZXMgKGZvciB0aGUgcHVy cG9zZSBvZiB0aGUgZXhhbXBsZSkgdGhhdCBjb250YWluIGEge3VyaX0gdGVtcGxhdGUgcGFyYW1l dGVyIGluIHRoZSBleGFtcGxlIGl0c2VsZiwNCmUuZy4NCjw/eG1sIHZlcnNpb249JzEuMCcgZW5j b2Rpbmc9J1VURi04Jz8+DQogICA8WFJEIHhtbG5zPSdodHRwOi8vZG9jcy5vYXNpcy1vcGVuLm9y Zy9ucy94cmkveHJkLTEuMCc+DQoNCiAgICAgPCEtLSBSZXNvdXJjZS1zcGVjaWZpYyBJbmZvcm1h dGlvbiAtLT4NCg0KICAgICA8TGluayByZWw9J2h0dHA6Ly93ZWJmaW5nZXIubmV0L3JlbC9hdmF0 YXInDQogICAgICB0ZW1wbGF0ZT0naHR0cDovL2V4YW1wbGUuY29tL2F2YXRhci97dXJpfScgLz4N Cg0KICAgICA8TGluayByZWw9J3NhbG1vbicNCiAgICAgIHRlbXBsYXRlPSdodHRwOi8vZXhhbXBs ZS5jb20vc2FsbW9uL3t1cml9JyAvPg0KDQogICAgIDxMaW5rIHJlbD0naHR0cDovL3BvcnRhYmxl Y29udGFjdHMubmV0L3NwZWMvMS4wJw0KICAgICAgaHJlZj0naHR0cDovL2V4YW1wbGUuY29tL3Bl b3BsZScgLz4NCg0KICAgICA8TGluayByZWw9Imh0dHA6Ly9zY2hlbWFzLmdvb2dsZS5jb20vZy8y MDEwI3VwZGF0ZXMtZnJvbSIgIHRlbXBsYXRlPSJodHRwOi8vZXhhbXBsZS5jb20vYWN0aXZpdHlz dHJlYW1zL3t1cml9L0BzZWxmP2Zvcm1hdD1hdG9tIg0KICAgICAgICB0eXBlPSJhcHBsaWNhdGlv bi9hdG9tK3htbCIgLz4NCg0KICAgPC9YUkQ+DQpBbmQgY29tbWVudGluZyB0aGF0IHRoZXNlIHRl bXBsYXRlcyAoZm9yIHJlc291cmNlLXNwZWNpZmljIGluZm8pIGFsbG93IHRvIGF2b2lkIHF1ZXJ5 aW5nIGVhY2ggc2luZ2xlIHJlc291cmNlIG9uIHNlcnZlciBleGFtcGxlLmNvbSBmb3IgdGhlc2Ug bGluayByZWxzLCB0aHVzIHVzZWZ1bCBmb3IgaW50ZXJjb25uZWN0aW9uIG9mIGxhcmdlIHByb3Zp ZGVycy4NCg0KPg0KPiA+IC0gc3BlY2lmeWluZyBuZXcgdGVtcGxhdGVzIHZhcmlhYmxlIG5hbWVz IHRvIGJlIHVzZWQgaW4gdGVtcGxhdGVzLCBhcyB0aGlzDQo+ID4gc2NlbmFyaW8gbWFrZXMgc3Ry b25nIHVzZSBvZiB0ZW1wbGF0ZXMgYW5kIG1heSBuZWVkIHRvIHJlZmVyZW5jZQ0KPiA+IGFkZGl0 aW9uYWwgaW5mb3JtYXRpb24uIFRoZSBmaXJzdCB0aGF0IGNvbWVzIGludG8gbXkgbWluZCAoYXMg cGVyIHRoZQ0KPiA+IGV4YW1wbGUgaW4gbXkgcHJldmlvdXMgZW1haWwpIGlzIHRoZSBsb2NhbCB1 c2VybmFtZSwgdGhhdCBjb3VsZCBiZQ0KPiA+IGlkZW50aWZpZWQgYXMge3VyaS51c2VycGFydH0s IHt1c2VybmFtZX0gb3IgYW55dGhpbmcgZWxzZS4gTWF5YmUgb3RoZXINCj4gPiBjb3VsZCBhbHNv IG1ha2Ugc2Vuc2UuDQo+DQo+IEkgcmVhbGx5IHRoaW5rIGl0J3MgYSBiYWQgaWRlYSBmb3IgdXMg dG8gaW50cm9kdWNlIG1vcmUgdGVtcGxhdGUgdmFyaWFibGVzLg0KPiBUaGlzIGdldHMgY29tcGxp Y2F0ZWQuICBXZWJGaW5nZXIgd2FzIGRlc2lnbmVkIHRvIG9wZXJhdGUgb24gYSBzaW5nbGUgVVJJ Lg0KPiBTaW5jZSBhIFVSSSBjYW4gY29udGFpbiBhbnkga2luZCBvZiBpbmZvcm1hdGlvbiwgSSB0 aGluayB0aGF0IHNob3VsZCBiZQ0KPiBzdWZmaWNpZW50Lg0KW3dhbHRlcl0gTXkgcHJvcG9zYWwg aXMgYmFzZWQgb24gdGhlIG9ic2VydmF0aW9uIG9mIHRoZSB3ZWJmaW5nZXIgZW5kcG9pbnRzIGFs cmVhZHkgZXhwb3NlZCwgd2hlcmUgdGhlIFVSTCBvZiBtb3N0IHJlc291cmNlLXNwZWNpZmljIGlu Zm9ybWF0aW9uIChsaW5rIHJlbHMpIGlzIGFjdHVhbGx5IGJhc2VkIG9uIGEgcGF0dGVybiwgd2hp Y2ggaXMgY29tbW9uIHRvIGFsbCByZXNvdXJjZXMgdW5kZXIgdGhhdCBkb21haW4sIGJ1dCB3aGlj aCBwYXR0ZXJuIGRvIG5vdCB0eXBpY2FsbHkgaW5jbHVkZXMgdGhlIHdob2xlIGFjY291bnQgVVJJ IGJ1dCBvbmx5IGEgdXNlcm5hbWUgKG9yIHNvbWUgc29ydCBvZiBpZCwgZWcgaW4gY2FzZSBvZiBH KykuDQoNCndhbHRlcg0KPg0KPiBQYXVsDQo+DQoNCg0KUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3Vv aSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBp bmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lIGRl cml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdv cm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1l bnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRp YXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRp c3RydXppb25lLCBHcmF6aWUuDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMg Y29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVu ZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHBy aW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBh bmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWls LCBUaGFua3MuDQoNCg== From afarrel@juniper.net Sun Sep 2 12:45:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A6B21F84D7 for ; Sun, 2 Sep 2012 12:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEsUX0CnX26d for ; Sun, 2 Sep 2012 12:45:25 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 8072621F849A for ; Sun, 2 Sep 2012 12:45:25 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q82JjMdF031563; Sun, 2 Sep 2012 20:45:22 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q82JjKUW031553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Sep 2012 20:45:21 +0100 From: "Adrian Farrel" To: "'Ned Freed'" References: <1972D7F2-E7C1-4066-BC83-904D68C733F3@mnot.net> <01OJRY9JYK8G0006TF@mauve.mrochek.com> <01OJS30QN9SW0006TF@mauve.mrochek.com> In-Reply-To: <01OJS30QN9SW0006TF@mauve.mrochek.com> Date: Sun, 2 Sep 2012 20:45:21 +0100 Message-ID: <002f01cd8943$7d78df20$786a9d60$@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFU1B6Tib1wocR1GyruuKpTjzBBXAKJ0kLDAnewnY0DQpIm9ALs8XSAmA9UooA= Content-Language: en-gb X-Mailman-Approved-At: Mon, 03 Sep 2012 09:15:14 -0700 Cc: 'Barry Leiba' , 'Apps Discuss' Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: afarrel@juniper.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 19:45:26 -0000 Hi Ned, I appreciate the Captain's attempts to fly to the rescue, and for me (i.e. my Discuss) this has started the process of getting what I want to see added to the document. I hope you won't think me too petty (just petty enough) when I say that telling me what the feature will be used for is not the same as telling me that the feature is needed. Hopefully, if this is so very obvious, it will not be hard or painful to explain the use cases a little more fully and note that there are no existing mechanisms that provide the desired function. Cheers, Adrian > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of Ned Freed > Sent: 02 September 2012 19:52 > To: Paul Hoffman > Cc: Barry Leiba; Apps Discuss > Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded > > > On Sep 2, 2012, at 9:18 AM, Ned Freed wrote: > > > > As for the IESG comments themselves, most these folks seem to have missed > the > > > OPTIONAL nature of this field. Of course a proxy that is being operated in > > > whole or in part for purposes of providing client anonymity MUST NOT insert > it! > > > There are three outstanding DISCUSS comments, and at least one seems > predicated not on that but on the lack of description for the value of this field. > Adrian Farrel says: > > ===== > > I think it is unfortunate that this document does not give any > > explanation of why it is desirable to expose the information that is > > lost during proxying and which the proposed extensions make available. > > > It is normal for work in the IETF to be presented along with some > > motivations based on utility. While it is quite clear that the proposed > > mechanism would work to provide the function described, it is a > > mystery why any proxy would implement it or consider the extension > > valuable. > > ===== > > > One or two paragraphs in the Introduction should suffice. > > OK, if Captain Obvious needs to fly to the rescue again, so be it. How about > something like: > > Uses of the information provided by "Forwarded" fields include, but are > not limited to: Logging, access control, and rate limits. > > I'm sure there are more, but these all seem like obvious uses to me. (They > definitely are how XCLIENT and similar mechanisms are regularly used in email.) > > Of course once if we head down this path we may be risking arguments about > the appropriateness of using IP addresses or whatever for these purposes, > but the reality is they are used that way. > > Come to think of it, this also provides a response to one of the other IESG > comments, which was a request to provide a means of providing only an address > prefix rather than an entire address. Consideration of only part of an address > is of course entirely appropriate in many cases, but that's really a job for > the agent consuming the information. Doing it at the proxy spreads network > configuration around unnecessarily and complicates management. > > Whereas the only real benefit to partial addresses that I see would be in some > sort of situation where the proxy and server are separately administered and > the proxy trusts the server to the extent of being willing to provide part of > an address but not to the extent of providing the whole thing. I'm having > difficulty envisioning a real use case of sufficient utility to outweigh the > "bad idea" aspects. > > > Ned > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From miguel.a.garcia@ericsson.com Mon Sep 3 07:41:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C477D21F861F for ; Mon, 3 Sep 2012 07:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.706 X-Spam-Level: X-Spam-Status: No, score=-6.706 tagged_above=-999 required=5 tests=[AWL=0.863, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_ADLTOBFU=0.68] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnL6bPjpo56m for ; Mon, 3 Sep 2012 07:41:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C00B521F8597 for ; Mon, 3 Sep 2012 07:41:32 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-92-5044c19becad Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F9.93.17130.B91C4405; Mon, 3 Sep 2012 16:41:31 +0200 (CEST) Received: from [159.107.24.194] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.1; Mon, 3 Sep 2012 16:41:31 +0200 Message-ID: <5044C19A.3080505@ericsson.com> Date: Mon, 3 Sep 2012 16:41:30 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Enrico Marocco , Alexey Melnikov References: <4F2FA266.8040406@telecomitalia.it> In-Reply-To: <4F2FA266.8040406@telecomitalia.it> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM+Jvre7sgy4BBju/mlnMWF1ksfrlCjaL +Z2n2S1a7nhZnDhykN2B1WPK742sHkuW/GTyONVs6DFr5xMWj5ZzvewBrFFcNimpOZllqUX6 dglcGfv3zGQumGhdcfP6OsYGxk26XYycHBICJhI3LlxkgbDFJC7cW88GYgsJnGKUWHMFqIYL yF7NKPH2cw9zFyMHB6+AtsSppnKQGhYBFYknjZfYQWw2AXOJ1o0bwWxRgUCJdVf/gNm8AoIS J2c+AZsvIpAiseHfTDaQmcwCzYwSp1asYwJJCAtYSPzd0cECMl9IQF9ixdoAEJNTwEDi6jyw McwCthIX5lxngbDlJba/ncMMcaamxOSbS5knMArOQrJtFpKWWUhaFjAyr2IUzk3MzEkvN9dL LcpMLi7Oz9MrTt3ECAzug1t+G+xg3HRf7BCjNAeLkjivnup+fyGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2MvM/j/kzNm/Rn26tJW3QWPXE+4zd3UycP9/6nd1NK3K8l5b88xLf35RkWU4tt uUxhmvxy+zMMrsUI+f98Mc9crW9SPu+rK9Pexszb5Ssi43g3J+5T2h/u8zeL7E7lzJ5RV/tf fXFe89uJC/9t+znp9mTO7z8ZG3/xKb2c+WOK3sSLN82u7ZQocFViKc5INNRiLipOBADvqPtF PAIAAA== X-Mailman-Approved-At: Mon, 03 Sep 2012 09:15:33 -0700 Cc: Geir Arne Sandbakken , "apps-discuss@ietf.org" , Ben Campbell Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-simple-chat-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 14:41:34 -0000 Enrico, Alexey: I am pulling up your original review of draft-ietf-simple-chat back in February, and I will try to address the pending issues. The current version of the draft is 16: http://datatracker.ietf.org/doc/draft-ietf-simple-chat/ See inline comments. On 06/02/2012 10:50, Enrico Marocco wrote: > Document: draft-ietf-simple-chat-13 > Title: Multi-party Chat Using the Message Session Relay Protocol (MSRP) > Reviewers: Alexey Melnicov and Enrico Marocco > Review Date: 2012-02-06 > IETF Last Call Date: 2012-02-06 > > > Summary: This draft is almost ready for publication as a Proposed > Standard, but has a major issue to be taken into consideration and a few > minor issues to be fixed. > > > Major Issue > > The document doesn't describe allowed characters in Nicks and any > normalization that needs to be applied. With respect to the issue of "allowed characters", only UTF-8 s allowed. This draft is an extension to RFC 4975 (MSRP). The ABNF syntax of the Use-Nickname header refers to RFC 4975. Section 9 of RFC 4975 says: "MSRP is a text protocol that uses the UTF-8 [14] transformation format". So, I believe this issue is solved by indirect reference. However, to add a bit more emphasis, we can add the following text: According to RFC 4975, MSRP uses the UTF-8 transformation format. The syntax of the MSRP NICKNAME method and the "Use-Nickname" header field is built upon the MSRP formal syntax using the Augmented Backus-Naur Form (ABNF . With respect to the issue of normalization, I believe this is now solved in version 16. Section 7.1 contains now the following paragraphs: If the policy of the chat room allows the usage of nicknames, any new nickname requested MUST be prepared and compared with nicknames already in use or reserved following the rules defined in Preparation and Comparison of Nicknames [I-D.ietf-precis-nickname]. This mitigates the problem of nickname duplication, but it does not solve a problem whereby users can choose similar (but different) characters to represent two different nicknames. For example, "BOY" and "B0Y" are different nicknames which can mislead users. The former uses the capital letter "O" while the latter uses the number zero "0". In many fonts the letter "O" and the number zero "0" might be quite similar, and difficult to be perceived as different characters. Chat rooms MAY provide a mechanism to mitigate confusable nicknames. > > > Minor Issues > > The document strictly forbids multiple To: headers in the CPIM message, > that could be used for example to send public personal messages (i.e. > messages addressed to some particular individual, but shared with the > entire conference, a-la Twitter). If there's a reason for that, some > explanation would be useful. This was a decision taken by the working group due to the complexity. For example, what happens if one of the recipients is correct, but another one is incorrect or has left the chat room. Should the server process the message to one recipient and not to the other? what would be the error? It was also conflicting with requirements for side conferences, something that was part of the deliverables in XCON. At the end of the day, the endpoint can always send multiple messages, each one with a single To header. To address this issue, I proposed to add the following text in Section 6.2: This version of the specification does not support sending a private message to multiple recipients, i.e., the presence of multiple To headers in the Message/CPIM wrapper of the MSRP SEND request. This is due to added complexity, for example, with the need to determine whether a message was not deliver to some of the intended recipients. Implementations that still want to recreate this function can send a series of single private messages, one private message per intended recipient. The endpoint can correlate this series of messages and create the effect of a private message addressed to multiple recipients. > > Figure 1 seems to imply that MSRP relays are mandatory. Since they are > not -- and the draft is pretty clear about it -- I'd suggest to have > some of MSRP flows in the diagram flow straight from the client to the > switch. Agreed. > > A reference to the SDP mechanism defined in S. 8. would be useful in in > S. 5.2., last paragraph, S. 6.2, last paragraph, and in any other part > that deals with discovering of client capability. > Agreed for section 5.2. The proposed change is as follows: Last paragraph in Section 5.2 starts with: The conference focus of a chat room MUST learn the chat room capabilities of each participant that joins the chat room. This is achieved by the exchange of new 'chatroom' attributes in SDP (see for further details). But I believe the last paragraph of S. 6.2 does not talk about discovering capabilities, so I think the text does not fit there. But I have found a paragraph in S 4 that talks about capability discovery, so I have added the last sentence of the previous paragraph too. > In Section 5.2: > > The conference focus of a chat room MUST learn the chat room > > How can this be achieved? A forward pointer might be missing here. Yes, this is the previously mentioned paragraph. > > capabilities of each participant that joins the chat room. The > conference focus MUST inform the MSRP switch of such support in > order to prevent the MSRP switch from distributing private messages > to participants who do not support private messaging. The recipient > would not be able to render the message as private, and any > potential reply would be sent to the whole chat room. > > 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. In the current version 16, these have been split into two errors: - 424: Malformed nickname - 425: Nickname reserved or already in use We believe this solves the issue. > > > Nits [Only the few that came out in non-nitpicking read] > > S. 3, REQ-3: s/depend no/depend on/ ok. > > S. 4, second paragraph after Figure 2: s/a text/text/ ok > > A few 2119 refuses can be also found in the text, e.g.: > > S. 5.2, sixth paragraph: s/URI must not/URI MUST NOT/ Ok. Thanks for your comments. They will be deployed in a newer version of the document. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From sm@resistor.net Mon Sep 3 14:53:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE2321F8504 for ; Mon, 3 Sep 2012 14:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGnMUMMbKbic for ; Mon, 3 Sep 2012 14:53:35 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 224C121F84FC for ; Mon, 3 Sep 2012 14:53:35 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q83LrTvJ016164 for ; Mon, 3 Sep 2012 14:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346709214; bh=mrM0NTdsb6vfhgHYLM7WrwQ0NqDkWIxiDx+t52og5Vc=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=t6CpKWzMcfKy12GUsgGk8WFCn/JlHyDpFy4fxM7+XL2HccZ89+1DGNdR9mf+BSbkG kqRBnBT/H/f/CtaNr31Rmy/wGJ1c6xD32mmUjoVfJpLFE/Ljo1ip/SVUbKbhAu6kuH ECsylkmRDbDWp0lktVL6lOHjgmoVJFEiJTgLGIWk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1346709214; i=@resistor.net; bh=mrM0NTdsb6vfhgHYLM7WrwQ0NqDkWIxiDx+t52og5Vc=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=KWME3JMza8/KJbnhDuF6BK/4LdbH+DTsHSG8xDr6QdYaQ88xkvKbp/+UFCTPj4bop m4bmCv66hnUs7rQ0BLmB3NxsCxosrNWJvpjuQZJDCG0vw/5yHkYUHlWUvBY9SD3MwJ nCu+MG1thvtStExIVq3hLtTHtaGlL5HNxLNKB/Z0= Message-Id: <6.2.5.6.2.20120903123756.0b481f60@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 03 Sep 2012 14:15:43 -0700 To: Apps Discuss From: SM In-Reply-To: References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 21:53:36 -0000 At 06:22 03-09-2012, Barry Leiba wrote: >Therefore, I think this *does not cause a privacy exposure* in the >general case of the proxy that's meant to simply relay the client's >request. The fact that the proxies have caused some of that >information to be lost has been accidental (and often undesirable). >It has not been a *design* of the proxies, not a *reason* that the >proxies are there. Some design decisions are intentional. There can be side-effects; I'll call them unintentional decisions. The topic under discussion is somewhat similar to what has been argued about for some DNS questions. Although one can question the design, it is easier not to. The "being there" is what I would call "fait accompli". The IETF version is "can of worms". The "fait accompli" is a subject of debate in non-IETF venues. In I* venues one should know better than to ask about that. The simplest form of the discussion is that: (a) There is an X- header field in wide use (b) The X- should be removed and the header field standardized to make the Internet work better. I read the message from Hannes Tschofenig ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06954.html ) as what's the impact of doing that. Once the information has been lost, it is a "fait accompli". The header field could be added to the relevant registry and the specification published as an Informational RFC. Alternatively, the WG could figure out how to make the proposal palatable for the Standards Track. Regards, -sm From stephen.farrell@cs.tcd.ie Mon Sep 3 15:07:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DA821F8574 for ; Mon, 3 Sep 2012 15:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgyLLClpIKmb for ; Mon, 3 Sep 2012 15:07:15 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id D091A21F8569 for ; Mon, 3 Sep 2012 15:07:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1A987171481; Mon, 3 Sep 2012 23:07:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346710032; bh=Gq24cPETVk3Qca ah3nVCx4AF8ZaqnTqosP1U05NjzRI=; b=UiY5UtOhN1BRH8tUHxXc3BMcnE1ula lidpKb5XdEQhHd8H9F2SrvLISBGuEP7sVgqhCy1cPQdtlCTeNGfXkXrRcyda3AV0 hmZ1l5g/8XYMyNvDxLJLK6fZlfX+diC7SKka8lx3LD8gDgkS86pXwS5UUTz85xNV UpBlPNe6jFHicJizPpIiu6A6nmqCn4r6y913KJ4V9aq5wXUmTVyWv1ItQOVMApmu mCWxNnAF9nEJrX+eq/HL/aoD1opvYgPF3JsZ/vHETpn5FwHtmQVJKO359lJcRias cGXYpukoQ04iZ7Er2UUm0Ng2BxMb8mJH5TOpQG9Dh6c/A8tJYM79Mjig== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id YwfURSSMEu9f; Mon, 3 Sep 2012 23:07:12 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.52.14]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 5735E17147F; Mon, 3 Sep 2012 23:07:11 +0100 (IST) Message-ID: <50452A0F.2070404@cs.tcd.ie> Date: Mon, 03 Sep 2012 23:07:11 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Barry Leiba References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 22:07:31 -0000 So just for completeness... On 09/03/2012 02:22 PM, Barry Leiba wrote: > > Therefore, I think this *does not cause a privacy exposure* in the > general case of the proxy that's meant to simply relay the client's > request. The fact that the proxies have caused some of that > information to be lost has been accidental (and often undesirable). > It has not been a *design* of the proxies, not a *reason* that the > proxies are there. > > The *only* case where the situation is otherwise is when the proxy is > there *for the purpose* of hiding this information. Where the user > *expects* the proxy to provide a privacy shield. As Barry knows, he and I disagree about this. I don't think that the user's expectation or lack thereof is relevant to the argument. For almost all users for almost all the time, the user is unaware of what might or might not be going on and we should not design our protocols for only those users who know this header field exists. (For users that do know about such things, the protocol should also do the right thing, but the numbers there are in the noise.) Secondly, we also disagree as to whether there can be a privacy "exposure" here. My argument is that without this header field the proxies closer to the web server and the web server would not know the user agent's IP, and with this header field, they do know that. If knowing the user agent's IP can ever be a privacy issue, and it can, then that's a potential privacy "exposure" for me. S. PS: "exposure" is in quotes because I don't think the terminology there is quite right, but I don't have a better term. From ned.freed@mrochek.com Mon Sep 3 15:08:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A5821F8567 for ; Mon, 3 Sep 2012 15:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yM2N8IFyr5G7 for ; Mon, 3 Sep 2012 15:08:09 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B707221F84B6 for ; Mon, 3 Sep 2012 15:08:07 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJTNECV0WG007XA5@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 3 Sep 2012 15:03:00 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Mon, 3 Sep 2012 15:02:58 -0700 (PDT) Message-id: <01OJTNEBJV620006TF@mauve.mrochek.com> Date: Mon, 03 Sep 2012 14:54:07 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 02 Sep 2012 17:02:12 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <1972D7F2-E7C1-4066-BC83-904D68C733F3@mnot.net> <01OJRY9JYK8G0006TF@mauve.mrochek.com> <01OJS30QN9SW0006TF@mauve.mrochek.com> <03BAF4AA-C350-41D0-BD9D-FC6389873C84@vpnc.org> To: John C Klensin Cc: Barry Leiba , Ned Freed , Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 22:08:10 -0000 > --On Sunday, September 02, 2012 13:42 -0700 Paul Hoffman > wrote: > >> Uses of the information provided by "Forwarded" fields > >> include, but are not limited to: Logging, access control, > >> and rate limits. > >> > > > > Playing the good captain's sidekick, I would propose adding: > > "The uses of the "Forwarded" fields described here for HTTP > > are similar to the many uses that the "Received" fields in > > SMTP messages have provided for decades." > Paul, > Because of some locus of control differences in the way proxies > are configured versus the way mail relays are, I think that, > beyond a certain point, the analogy is actually debatable. > Unless we want to have that debate for some reason, I'd suggest > leaving the lily ungilded. It really depends on what analogy you're trying to draw. I don't think anyone here is saying the semantics of Received: in email and Forwarded: in HTTP are identical. But there is substantial overlap, and it is *absolutely* the case that the privacy unicorn people seem to be hunting here, if real, would also exist with Received:. Which I believe was Mark's point. I'm a little unclear what this says about using Received: as an example though. If there is a need to justify this field by appealing to something that has been standardized and, far from being a security problem in actual deployment, is in fact a significant asset, then so be it. Otherwise I guess I agree with you that the debate is best avoided. Ned From john-ietf@jck.com Mon Sep 3 18:35:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F73D21F8639 for ; Mon, 3 Sep 2012 18:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id At+OJCBwpEJp for ; Mon, 3 Sep 2012 18:35:34 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7110121F8629 for ; Mon, 3 Sep 2012 18:35:31 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1T8i2X-000EMi-Q9; Mon, 03 Sep 2012 21:34:53 -0400 Date: Mon, 03 Sep 2012 21:34:48 -0400 From: John C Klensin To: Ned Freed Message-ID: <703E11A52050B29B0B57AB04@JcK-HP8200.jck.com> In-Reply-To: <01OJTNEBJV620006TF@mauve.mrochek.com> References: <01OJTNEBJV620006TF@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Barry Leiba , Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 01:35:37 -0000 --On Monday, September 03, 2012 14:54 -0700 Ned Freed wrote: >... >> Because of some locus of control differences in the way >> proxies are configured versus the way mail relays are, I >> think that, beyond a certain point, the analogy is actually >> debatable. Unless we want to have that debate for some >> reason, I'd suggest leaving the lily ungilded. > > It really depends on what analogy you're trying to draw. I > don't think anyone here is saying the semantics of Received: > in email and Forwarded: in HTTP are identical. But there is > substantial overlap, and it is *absolutely* the case that the > privacy unicorn people seem to be hunting here, if real, would > also exist with Received:. Which I believe was Mark's point. Ned, Really no disagreement. However, if your suggested text is acceptable, then the document stands perfectly well with that text and without any discussion of "Received:" or any other analogies whether good, bad, or indifferent. So, from my point of view, there is no need to do whatever hairsplitting might be necessary to figure out (and try to reach consensus on) what analogy people are trying to draw. Perhaps more to the point... > I'm a little unclear what this says about using Received: as > an example though. If there is a need to justify this field by > appealing to something that has been standardized and, far > from being a security problem in actual deployment, is in fact > a significant asset, then so be it. Otherwise I guess I agree > with you that the debate is best avoided. So suppose we make the analogy and argue that, if "Received:" is ok, then "Forwarded: is ok too. If I were trying to ride around on a privacy high horse while hunting that unicorn, I'd just say "what was good enough thirty years ago isn't any longer, so the analogy is absolutely useless". And that takes me back to the comments I made last week. It seems to me that there are two possible cases here: (1) "Forwarded" has significant value but needs to be used with care and we have a good idea and rough consensus (independent of the privacy issues) about how it should be defined. or (2) "Forwarded" is positively evil, whether because of privacy issues or otherwise, and we should do nothing to encourage its use. Now, if the first case applies --as I suspect it does-- then, IMO, your text (or something very much like it) is the right fix, with or without appeals to Captain Obvious. For the reasons above, comparisons to "Received:" don't help much, even if we can agree on the nature of the analogy and similarities and differences in trust relationships. If the second case applies but the field is in wide use and likely to remain in wide use no matter what curses the IETF passes around, then it is appropriate to publish as Informational with explanations of the issues included and whatever "don't use this but, if you must, be aware of these considerations" text seems appropriate. john From ned.freed@mrochek.com Mon Sep 3 19:25:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD7C21F863C for ; Mon, 3 Sep 2012 19:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80idWhTijyIo for ; Mon, 3 Sep 2012 19:25:18 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDE521F862A for ; Mon, 3 Sep 2012 19:25:18 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJTWFGDIW0008882@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 3 Sep 2012 19:21:12 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Mon, 3 Sep 2012 19:21:09 -0700 (PDT) Message-id: <01OJTWFEOAZY0006TF@mauve.mrochek.com> Date: Mon, 03 Sep 2012 19:10:44 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 03 Sep 2012 21:34:48 -0400" <703E11A52050B29B0B57AB04@JcK-HP8200.jck.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OJTNEBJV620006TF@mauve.mrochek.com> <703E11A52050B29B0B57AB04@JcK-HP8200.jck.com> To: John C Klensin Cc: Barry Leiba , Ned Freed , Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 02:25:19 -0000 > --On Monday, September 03, 2012 14:54 -0700 Ned Freed > wrote: > >... > >> Because of some locus of control differences in the way > >> proxies are configured versus the way mail relays are, I > >> think that, beyond a certain point, the analogy is actually > >> debatable. Unless we want to have that debate for some > >> reason, I'd suggest leaving the lily ungilded. > > > > It really depends on what analogy you're trying to draw. I > > don't think anyone here is saying the semantics of Received: > > in email and Forwarded: in HTTP are identical. But there is > > substantial overlap, and it is *absolutely* the case that the > > privacy unicorn people seem to be hunting here, if real, would > > also exist with Received:. Which I believe was Mark's point. > Ned, > Really no disagreement. However, if your suggested text is > acceptable, then the document stands perfectly well with that > text and without any discussion of "Received:" or any other > analogies whether good, bad, or indifferent. So, from my point > of view, there is no need to do whatever hairsplitting might be > necessary to figure out (and try to reach consensus on) what > analogy people are trying to draw. > Perhaps more to the point... > > I'm a little unclear what this says about using Received: as > > an example though. If there is a need to justify this field by > > appealing to something that has been standardized and, far > > from being a security problem in actual deployment, is in fact > > a significant asset, then so be it. Otherwise I guess I agree > > with you that the debate is best avoided. > So suppose we make the analogy and argue that, if "Received:" is > ok, then "Forwarded: is ok too. If I were trying to ride around > on a privacy high horse while hunting that unicorn, I'd just say > "what was good enough thirty years ago isn't any longer, so the > analogy is absolutely useless". Fair point. > And that takes me back to the comments I made last week. It > seems to me that there are two possible cases here: > (1) "Forwarded" has significant value but needs to be used with > care and we have a good idea and rough consensus (independent of > the privacy issues) about how it should be defined. > or > (2) "Forwarded" is positively evil, whether because of privacy > issues or otherwise, and we should do nothing to encourage its > use. > Now, if the first case applies --as I suspect it does-- then, > IMO, your text (or something very much like it) is the right > fix, with or without appeals to Captain Obvious. For the > reasons above, comparisons to "Received:" don't help much, even > if we can agree on the nature of the analogy and similarities > and differences in trust relationships. > If the second case applies but the field is in wide use and > likely to remain in wide use no matter what curses the IETF > passes around, then it is appropriate to publish as > Informational with explanations of the issues included and > whatever "don't use this but, if you must, be aware of these > considerations" text seems appropriate. I don't have enough experience with web proxies at scale to assess the situation there directly, but as I noted in my original response, we have a very similar situation in email that has nothing to do with Received: fields and it is causing real problems. I would prefer (1) personally, but I can live with (2). That said, having been through similar processes in the past, I'm worried that if approach (2) is taken we'll just go full circle and end up back where we started once the informational document is at this point. Ned From lear@cisco.com Mon Sep 3 21:51:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AA921F8471 for ; Mon, 3 Sep 2012 21:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+jqLrIYYidJ for ; Mon, 3 Sep 2012 21:51:54 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 0D13121F8413 for ; Mon, 3 Sep 2012 21:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=2109; q=dns/txt; s=iport; t=1346734314; x=1347943914; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=SqWZHblJywWRX46GXlNoGZVwLNOehjFzVgev/+j7Olg=; b=cxaDKhYpgVRFBlaJSz0iCk8/B0ikpP/UvmL66fkiF8bObnqJx109gE6P iQqVjSb/4jZq2OTM2FeDx8hAapeXsKX2MszMNzN0E4QbPc+H12v9y2nbl x5Fo6UiRQPw1PbFXU2HxNni5kD4WTfPN2vfKnguukTmKYUlHGCeROKflK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAG2HRVCQ/khR/2dsb2JhbAA7CoYFtSOBB4IgAQEBBBIBEA8BRQEQCxgCAgUWCwICCQMCAQIBRQYNAQcBAR6Ha5ovjRmSZYEhiXYGhhCBEgOVWY4zgWeCZYFf X-IronPort-AV: E=Sophos;i="4.80,365,1344211200"; d="scan'208";a="7784997" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 04 Sep 2012 04:51:52 +0000 Received: from dhcp-10-61-107-84.cisco.com (dhcp-10-61-107-84.cisco.com [10.61.107.84]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q844ppFd002275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2012 04:51:52 GMT Message-ID: <504588E8.9090200@cisco.com> Date: Tue, 04 Sep 2012 06:51:52 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Ned Freed References: <1972D7F2-E7C1-4066-BC83-904D68C733F3@mnot.net> <01OJRY9JYK8G0006TF@mauve.mrochek.com> <01OJS30QN9SW0006TF@mauve.mrochek.com> <03BAF4AA-C350-41D0-BD9D-FC6389873C84@vpnc.org> <01OJTNEBJV620006TF@mauve.mrochek.com> In-Reply-To: <01OJTNEBJV620006TF@mauve.mrochek.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Barry Leiba , Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 04:51:55 -0000 Ned, On 9/3/12 11:54 PM, Ned Freed wrote: > It really depends on what analogy you're trying to draw. I don't think anyone > here is saying the semantics of Received: in email and Forwarded: in HTTP are > identical. But there is substantial overlap, and it is *absolutely* the case > that the privacy unicorn people seem to be hunting here, if real, would also > exist with Received:. Which I believe was Mark's point. As you state, there's a major difference between Received: headers and THIS, so far as I can tell. Received: headers actually provide a security BENEFIT that is necessary to deal with a vast swathe of spam. We can't do without them because each SMTP server makes use of them (for better or worse) to decide whether a message is authentic. And so there's a tradeoff, and it has been documented since at least RFC-2822 and known about long before then. What's the real benefit here? Not at all clear. First, it's not stated in this draft and 2nd even in this discussion there has been disagreement. I remind you that Willy responded to Hannes stating that he thought the primary use of this draft would be for REVERSE proxies, while your pro forma justification was for regular proxies (I think there are examples of both in the doc). And predictably, I take issue with your "obvious" justification. HTTP already provides other capabilities to do this, and they provide far more useful trace information, like User-agent and cookies, which uniquely identify a client ACROSS IP addresses. So maybe the first thing to do is to make clear what the ACTUAL intended benefit, according to the authors (if no one else) of revealing the IP address is. [By the way, the sort of leakage with cookies is far FAR worse than anything we're talking about - insert animal/barn door analogy, here]. The "privacy unicorn" people know one thing: if an interface is standardized it will be used for purposes that we don't intend or desire, and you really may not like who mandates its use. At the very least that's worth a discussion – in the draft. Eliot From w@1wt.eu Mon Sep 3 23:31:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C8221F8527 for ; Mon, 3 Sep 2012 23:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.443 X-Spam-Level: X-Spam-Status: No, score=-1.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iwm1WqcPtSVF for ; Mon, 3 Sep 2012 23:31:18 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 7912111E808E for ; Mon, 3 Sep 2012 23:31:15 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q846V6N8009333; Tue, 4 Sep 2012 08:31:06 +0200 Date: Tue, 4 Sep 2012 08:31:06 +0200 From: Willy Tarreau To: Hannes Tschofenig Message-ID: <20120904063106.GC9183@1wt.eu> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> User-Agent: Mutt/1.4.2.3i Cc: Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 06:31:19 -0000 Hi Hannes, On Mon, Sep 03, 2012 at 09:41:56AM +0300, Hannes Tschofenig wrote: > Hi Willy, > > On Aug 31, 2012, at 10:54 AM, Willy Tarreau wrote: > > > It's just like saying that we should > > forbid eating with forks and knifes in restaurants because some people > > might use the knife to kill their noisy neighbour. Everything which is > > created has good and bad usages. > > > This is a common response: engineers tell you that they are just producing > tools -- they are not responsible for how they are used (even though they > very well know how these tools are used). Those who deploy then argue that > this is what has been given to them - the industry best current practice. But we're not reinventing anything here, that's the difference. Basically a name was set on something which already exists, and is widely deployed. > Nothing can be done to improve the privacy (or security) of the system. I don't get your point here. > I am trying to figure out what your views are. > > Are you saying that > * there are no privacy requirements that need to be addressed? > * you do not understand what those privacy requirements are? > * you believe that these privacy requirements are not applicable? It's a mix of those. Barry has summarized this very well. What the draft explains is who a device can inform components about information it could not preserve due to its nature. This is the problem with reverse proxies. Most of them cannot work in transparent mode due to operating system limitations, so by nature they are forced to transform the traffic (at least IP:port, sometimes protocol for v6->v4). For whatever is before the device, nothing is changed. The user asked to access service X and it went to the device which is presented to offer this service. This device relies on other servers and has to pass the connection there. But since it cannot pass it unmodified, it adds the missing data as HTTP header fields so that for the server it's just as if the device in question was not there or was more transparent. You see, I'm maintaining a load balancer. The first thing *every* user asks is "what should I do so that I don't lose the client's IP in my requests ?". The device in front of the server clearly is the problem, and the draft aims at solving this exact problem. The problem you're seeing with privacy is something more related to outgoing proxies and a bit different orthogonal. The problem exists only for users who : - know they are using a proxy, and - know how a proxy works, and - expect that the proxy will hide them >From my experience, users 1) don't know what a proxy is, 2) don't know that a proxy is in use, and 3) know for sure that "they leave traces" of their activities when they're going to remote sites. You'll even notice that for most users, their connectivity to the internet is very simple : - their PC - the company's firewall - the remote site. I know some well informed users who deliberately use anonymizing proxies to hide their activities. This clearly means that when users don't know, they know that their activities are visible, and when they care about this, they know how to hide them. The real issue that came years ago with the default setting of X-Forwarded-For on many proxies is that it used to reveal internal network addresses to the outside world at a period where firewalls were starting to be deployed and to hide such information. This is why nowadays it's strongly recommended to disable this header on outgoing proxies. But even if it's provided, at no point the user is betrayed, because no more information than what he provided With its client is seen along the whole chain. Regards, Willy From acooper@cdt.org Tue Sep 4 07:26:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE46B11E809B for ; Tue, 4 Sep 2012 07:26:34 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBRe6b6qefoo for ; Tue, 4 Sep 2012 07:26:34 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 468D611E8097 for ; Tue, 4 Sep 2012 07:26:34 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 4 Sep 2012 10:26:30 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <20120904063106.GC9183@1wt.eu> Date: Tue, 4 Sep 2012 10:26:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1084) Cc: Apps Discuss , Barry Leiba Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 14:26:35 -0000 Hi Willy, On Sep 4, 2012, at 2:31 AM, Willy Tarreau wrote: > The problem you're seeing with privacy is something more related to = outgoing > proxies and a bit different orthogonal. The problem exists only for = users who : > - know they are using a proxy, and > - know how a proxy works, and > - expect that the proxy will hide them >=20 > =46rom my experience, users 1) don't know what a proxy is, 2) don't = know that > a proxy is in use, and 3) know for sure that "they leave traces" of = their > activities when they're going to remote sites. It would be great to see some data in support of claim #3. I think if = you asked most users whether sites to which they give no affirmative = information about themselves nonetheless retain data that can be used to = subpoena information about their identities, they would say no. I'll note that we had a discussion during WGLC of how user expectation = factors in to the privacy impact of this header, and the draft now = contains language in 8.3 that is pretty clear about where it ended up: "Proxies using this extension will preserve the information of a direct connection. This has an end-user privacy impact regardless of whether the end-user or deployer knows or expects that this is the case." Alissa= From w@1wt.eu Tue Sep 4 10:17:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B17B11E80A3 for ; Tue, 4 Sep 2012 10:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coG6vTbpIekK for ; Tue, 4 Sep 2012 10:17:12 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id B84EB11E809A for ; Tue, 4 Sep 2012 10:17:10 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q84HGan7012486; Tue, 4 Sep 2012 19:16:36 +0200 Date: Tue, 4 Sep 2012 19:16:36 +0200 From: Willy Tarreau To: Alissa Cooper Message-ID: <20120904171636.GG11187@1wt.eu> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> User-Agent: Mutt/1.4.2.3i Cc: Apps Discuss , Barry Leiba Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 17:17:13 -0000 Hi Alissa, On Tue, Sep 04, 2012 at 10:26:29AM -0400, Alissa Cooper wrote: > > From my experience, users 1) don't know what a proxy is, 2) don't know that > > a proxy is in use, and 3) know for sure that "they leave traces" of their > > activities when they're going to remote sites. > > It would be great to see some data in support of claim #3. I think if you > asked most users whether sites to which they give no affirmative information > about themselves nonetheless retain data that can be used to subpoena > information about their identities, they would say no. Maybe it's different in other countries, but at least here in France, due to various news reports of people getting caught due to their IP address (or similarly their payment card), people are well aware that they "leave traces" over the net. This is the term I often use from them and it's common knowledge around my relatives, especially non-technies. Years ago, some ISPs even presented their dynamic address attribution as a way to limit address based tracking. So I'm observing that this is something commonly known, but I cannot provide data on this, I could as well ask for data showing the reverse and it would not make more sense. Regards, Willy From ned.freed@mrochek.com Tue Sep 4 10:46:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7831A21F84D3 for ; Tue, 4 Sep 2012 10:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSuVvbunqhL5 for ; Tue, 4 Sep 2012 10:46:32 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE3121F84CD for ; Tue, 4 Sep 2012 10:46:32 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJUSKFJ5KW00866J@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 4 Sep 2012 10:41:29 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=UTF-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Tue, 4 Sep 2012 10:41:25 -0700 (PDT) Message-id: <01OJUSKDXC4Y0006TF@mauve.mrochek.com> Date: Tue, 04 Sep 2012 10:05:50 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 04 Sep 2012 06:51:52 +0200" <504588E8.9090200@cisco.com> References: <1972D7F2-E7C1-4066-BC83-904D68C733F3@mnot.net> <01OJRY9JYK8G0006TF@mauve.mrochek.com> <01OJS30QN9SW0006TF@mauve.mrochek.com> <03BAF4AA-C350-41D0-BD9D-FC6389873C84@vpnc.org> <01OJTNEBJV620006TF@mauve.mrochek.com> <504588E8.9090200@cisco.com> To: Eliot Lear Cc: Barry Leiba , Ned Freed , Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 17:46:33 -0000 > Ned, > On 9/3/12 11:54 PM, Ned Freed wrote: > > It really depends on what analogy you're trying to draw. I don't think anyone > > here is saying the semantics of Received: in email and Forwarded: in HTTP are > > identical. But there is substantial overlap, and it is *absolutely* the case > > that the privacy unicorn people seem to be hunting here, if real, would also > > exist with Received:. Which I believe was Mark's point. > As you state, there's a major difference between Received: headers and > THIS, so far as I can tell. Received: headers actually provide a > security BENEFIT that is necessary to deal with a vast swathe of spam. Actually, Received: headers perform this function quite poorly due to widely varying syntax. (In hindsight I'm baffled as to why we didn't introduce a specific clause for this information instead of relying on comments.) As a result most high end antispam systems that make use of IP addresses get this information through other means, and as I noted in my original response when proxies are involved the solutions that are used are quite close to what is being proposed here for HTTP. > We can't do without them because each SMTP server makes use of them (for > better or worse) to decide whether a message is authentic. Actually, in my experience that's incorrect. Some antispam systems don't make use of client IP addresses at all and SMTP/SUBMIT servers often use IP address information for other purposes than antispam, e.g., rate limiting, internal/external classification, and auditing. > And so > there's a tradeoff, and it has been documented since at least RFC-2822 > and known about long before then. What's the real benefit here? The real benefit is pretty much the same as in SMTP/SUBMIT, which is why the analogy is a hell of a lot better than you seem to think. IP addresses are routinely used for rate limiting, identifying sources of problematic material, auditing, and so on > Not at all clear. I have to say I find this statement nothing short of flabbergasting. Surely you realize that being able to track where stuff comes from is of *critical* inportance is a vast number of applications? Surely you realize that not everything on the web can or sould use some stronger form of authentication and/or tracking? > First, it's not stated in this draft and 2nd even in this > discussion there has been disagreement. I remind you that Willy > responded to Hannes stating that he thought the primary use of this > draft would be for REVERSE proxies, while your pro forma justification > was for regular proxies (I think there are examples of both in the doc). And the relevance of this is .... what, exactly? > And predictably, I take issue with your "obvious" justification. HTTP > already provides other capabilities to do this, and they provide far > more useful trace information, like User-agent and cookies, which > uniquely identify a client ACROSS IP addresses. OK... So you want every web site out there requiring the use of cookies and/or basing its decisions on a field that at best identifies a class of browser/platform and which in my browser at least I can change at will with a pulldown menu. This argument is nothing short of surreal. > So maybe the first > thing to do is to make clear what the ACTUAL intended benefit, according > to the authors (if no one else) of revealing the IP address is. I have already suggested text to do this which, curiously, you haven't seen fit to comment on. I suggest that rather than providing unconstructive criticism like this you instead engage on getting the text into the document that clarifies or addresses the issues that concern you. > [By the > way, the sort of leakage with cookies is far FAR worse than anything > we're talking about - insert animal/barn door analogy, here]. Indeed. So why are you arguing in favor of using this instead of standardizing a less intrusive mechanism that is more than adequate in many cases? > The "privacy unicorn" people know one thing: if an interface is > standardized it will be used for purposes that we don't intend or > desire, and you really may not like who mandates its use. At the very > least that's worth a discussion – in the draft. But they have apparently forgotten that the Internet routes around obstacles. There is a serious problem here that people are going to solve one way or another. The IETF's choices are to either standardize something along with appropriate guidelines as to when it should and should not be used and hope people take note, publish an informational document that's less likely to have the desired impact, or do nothing and just hope it all works out. Of course the third course has consistently proved to work quite well in the past. Oh wait... Ned From acooper@cdt.org Tue Sep 4 10:46:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A1C21E804D for ; Tue, 4 Sep 2012 10:46:41 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iAbDJsovQGE for ; Tue, 4 Sep 2012 10:46:40 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 7378A21E803A for ; Tue, 4 Sep 2012 10:46:40 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 4 Sep 2012 13:46:17 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <20120904171636.GG11187@1wt.eu> Date: Tue, 4 Sep 2012 13:46:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1084) Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 17:46:41 -0000 Perhaps there is data on both sides (e.g., [1]), which may be a good = reason not to base design decisions on our collectively = vague/intuition-based assumptions about users' expectations and = awareness.=20 [1] = http://www.annenbergpublicpolicycenter.org/Downloads/Information_And_Socie= ty/20030701_America_and_Online_Privacy/20030701_online_privacy_report.pdf On Sep 4, 2012, at 1:16 PM, Willy Tarreau wrote: > Hi Alissa, >=20 > On Tue, Sep 04, 2012 at 10:26:29AM -0400, Alissa Cooper wrote: >>> =46rom my experience, users 1) don't know what a proxy is, 2) don't = know that >>> a proxy is in use, and 3) know for sure that "they leave traces" of = their >>> activities when they're going to remote sites. >>=20 >> It would be great to see some data in support of claim #3. I think if = you >> asked most users whether sites to which they give no affirmative = information >> about themselves nonetheless retain data that can be used to subpoena >> information about their identities, they would say no. >=20 > Maybe it's different in other countries, but at least here in France, = due > to various news reports of people getting caught due to their IP = address > (or similarly their payment card), people are well aware that they = "leave > traces" over the net. This is the term I often use from them and it's = common > knowledge around my relatives, especially non-technies. Years ago, = some ISPs=20 > even presented their dynamic address attribution as a way to limit = address > based tracking. So I'm observing that this is something commonly = known, but > I cannot provide data on this, I could as well ask for data showing = the > reverse and it would not make more sense. >=20 > Regards, > Willy >=20 >=20 From w@1wt.eu Tue Sep 4 11:13:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F8B21F8468 for ; Tue, 4 Sep 2012 11:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCOAFjWSCVVA for ; Tue, 4 Sep 2012 11:13:24 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 5018D11E809A for ; Tue, 4 Sep 2012 11:13:24 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q84ID3J1012776; Tue, 4 Sep 2012 20:13:03 +0200 Date: Tue, 4 Sep 2012 20:13:03 +0200 From: Willy Tarreau To: Alissa Cooper Message-ID: <20120904181303.GJ11187@1wt.eu> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> User-Agent: Mutt/1.4.2.3i Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:13:25 -0000 On Tue, Sep 04, 2012 at 01:46:17PM -0400, Alissa Cooper wrote: > Perhaps there is data on both sides (e.g., [1]), which may be a good reason > not to base design decisions on our collectively vague/intuition-based > assumptions about users' expectations and awareness. Please note that nobody was designing based on intuition, but only on technical grounds based on an engineering approach which consists in addressing issues caused by a category of devices which are used on almost every web site nowadays. The issues is just that the presence of these devices cause the client's address to be lost when the absence of the device would have let it pass. Once again, nothing is done to report more information than what was initially provided. The assumption seems to be that such information might be used for wrong purposes once the device is installed, while there is nothing apparently wrong with it being already present in another form before the device is installed. Regards, Willy From lear@cisco.com Tue Sep 4 11:38:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D40521F8690 for ; Tue, 4 Sep 2012 11:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP0LOKuMFjuJ for ; Tue, 4 Sep 2012 11:38:27 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3F221F8688 for ; Tue, 4 Sep 2012 11:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1691; q=dns/txt; s=iport; t=1346783907; x=1347993507; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=9u2DvZVNa+iZDSPVOXB4RWcb6NgtjUbGMjsCMgx+/Po=; b=dihRuTt+XDmsGsG6j16z5CY91WYw8CBEG8LoaDA/o8t5r+FRSGH3/agG iL9tQSVjspMHlgwAWxRnQ+c5O2flvG5cNYyM9XWCfktt7oR8iMoLQIn1S vYH+LT6zJwgnkWW3HE3eTMzJQ+uYtTphnZkHSq/E7i6ylShuCmA/MLckl g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPZJRlCQ/khM/2dsb2JhbABFhgW1HoEHghcKAQEEEgEQVQEQCwMBHRYLAgIJAwIBAgFFBg0BBwEBHodrmmGNGZJtkSmBEgOVWY4zgWeCZQ X-IronPort-AV: E=Sophos;i="4.80,368,1344211200"; d="scan'208,217";a="7796926" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 04 Sep 2012 18:38:26 +0000 Received: from ams3-vpn-dhcp5817.cisco.com (ams3-vpn-dhcp5817.cisco.com [10.61.86.184]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q84IcPhB002035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2012 18:38:25 GMT Message-ID: <50464AA1.4040906@cisco.com> Date: Tue, 04 Sep 2012 20:38:25 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Ned Freed References: <1972D7F2-E7C1-4066-BC83-904D68C733F3@mnot.net> <01OJRY9JYK8G0006TF@mauve.mrochek.com> <01OJS30QN9SW0006TF@mauve.mrochek.com> <03BAF4AA-C350-41D0-BD9D-FC6389873C84@vpnc.org> <01OJTNEBJV620006TF@mauve.mrochek.com> <504588E8.9090200@cisco.com> <01OJUSKDXC4Y0006TF@mauve.mrochek.com> In-Reply-To: <01OJUSKDXC4Y0006TF@mauve.mrochek.com> X-Enigmail-Version: 1.4.4 Content-Type: multipart/alternative; boundary="------------070506010505080006010907" Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:38:28 -0000 This is a multi-part message in MIME format. --------------070506010505080006010907 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Ned, First, we disagree in our experiences and on facts, and my point is *not* to kill the draft, but rather, as I wrote at the beginning, to find the few sentences at the beginning so that the purpose of the feature is clear– and it's *not*, and your logic isn't their logic. And then a clear discussion on privacy implications. And there are privacy implications. Also, there should be some statements about the limitations the approach (like the fact that sessions can and do outlast IP addresses. How hard could this be? Eliot --------------070506010505080006010907 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Ned,

First, we disagree in our experiences and on facts, and my point is not to kill the draft, but rather, as I wrote at the beginning, to find the few sentences at the beginning so that the purpose of the feature is clear– and it's not, and your logic isn't their logic.  And then a clear discussion on privacy implications.  And there are privacy implications.  Also, there should be some statements about the limitations the approach (like the fact that sessions can and do outlast IP addresses.

How hard could this be?

Eliot
--------------070506010505080006010907-- From stephen.farrell@cs.tcd.ie Tue Sep 4 11:38:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BA221F869D for ; Tue, 4 Sep 2012 11:38:43 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANkfKscbjVnH for ; Tue, 4 Sep 2012 11:38:42 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 21E4F21F8699 for ; Tue, 4 Sep 2012 11:38:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E976917147D; Tue, 4 Sep 2012 19:38:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346783919; bh=oiADeCFNK7YT0M jt+d5Gdxm4HdTnu7C+ZMJJiig7tdU=; b=ZrF/hBVmRf5Xx1vocLCCYIXXddWbX8 HK3oGkyAiGcbPfesX88LBVI5LwmEhY7WpbXVh0DTU3XVpKzQ4dwmEvo/pF0gz6gc ler8404iYi/k4Qfs8c38ZXpcf94PtUBv+UAzXizKaKmUKw3937GAk9yvbsvXgdyR EpWhfs6a0F53p57fruG33uScweCElmAmpMHsTaHonhn0V4xkE3T/CFqkxweG5h1R LXlEqJfkKuluuqHxWdpbi77jNGGjcuu6+yML5fWJT2BFtMh/QrBmGm6bPvUBs0gP C3mKpuDLAl4r7Py+x+pc6VGYdgkUjjAS5kwzyRMMoRhRJA7G79Cg8jTg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 9Lh33oG7FiDc; Tue, 4 Sep 2012 19:38:39 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.56.126]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 402BF17147B; Tue, 4 Sep 2012 19:38:38 +0100 (IST) Message-ID: <50464AAD.6060104@cs.tcd.ie> Date: Tue, 04 Sep 2012 19:38:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Willy Tarreau References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> In-Reply-To: <20120904181303.GJ11187@1wt.eu> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:38:43 -0000 On 09/04/2012 07:13 PM, Willy Tarreau wrote: > On Tue, Sep 04, 2012 at 01:46:17PM -0400, Alissa Cooper wrote: >> Perhaps there is data on both sides (e.g., [1]), which may be a good reason >> not to base design decisions on our collectively vague/intuition-based >> assumptions about users' expectations and awareness. > > Please note that nobody was designing based on intuition, but only on > technical grounds based on an engineering approach which consists in > addressing issues caused by a category of devices which are used on > almost every web site nowadays. The issues is just that the presence > of these devices cause the client's address to be lost when the absence of > the device would have let it pass. Once again, nothing is done to report > more information than what was initially provided. > > The assumption seems to be that such information might be used for wrong > purposes once the device is installed, while there is nothing apparently > wrong with it being already present in another form before the device is > installed. So even I don't see any issue with the reverse proxy case where the same operator runs both the web server and front-end. But that's not all this draft supports. Can you comment on the engineering reasons for supporting this in outbound proxies? S > > Regards, > Willy > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From w@1wt.eu Tue Sep 4 11:45:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3701B21F866A for ; Tue, 4 Sep 2012 11:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmiqDDX08G4g for ; Tue, 4 Sep 2012 11:45:38 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 2235E21F854F for ; Tue, 4 Sep 2012 11:45:37 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q84IjYoZ012920; Tue, 4 Sep 2012 20:45:34 +0200 Date: Tue, 4 Sep 2012 20:45:34 +0200 From: Willy Tarreau To: Stephen Farrell Message-ID: <20120904184534.GA12899@1wt.eu> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50464AAD.6060104@cs.tcd.ie> User-Agent: Mutt/1.4.2.3i Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:45:39 -0000 Hi Stephen, On Tue, Sep 04, 2012 at 07:38:37PM +0100, Stephen Farrell wrote: > > > On 09/04/2012 07:13 PM, Willy Tarreau wrote: > > On Tue, Sep 04, 2012 at 01:46:17PM -0400, Alissa Cooper wrote: > >> Perhaps there is data on both sides (e.g., [1]), which may be a good reason > >> not to base design decisions on our collectively vague/intuition-based > >> assumptions about users' expectations and awareness. > > > > Please note that nobody was designing based on intuition, but only on > > technical grounds based on an engineering approach which consists in > > addressing issues caused by a category of devices which are used on > > almost every web site nowadays. The issues is just that the presence > > of these devices cause the client's address to be lost when the absence of > > the device would have let it pass. Once again, nothing is done to report > > more information than what was initially provided. > > > > The assumption seems to be that such information might be used for wrong > > purposes once the device is installed, while there is nothing apparently > > wrong with it being already present in another form before the device is > > installed. > > So even I don't see any issue with the reverse proxy case > where the same operator runs both the web server and > front-end. > > But that's not all this draft supports. Can you comment on > the engineering reasons for supporting this in outbound > proxies? It's simple, sometimes you chain multiple proxies together. So you need for instance that the first proxy (eg: the cache) forwards the IP information to the second one (eg: url filter) so that it can be decided whether the guest network has access to the whole internet or just the company's, or whether the boss' address is filtered or not. Once again, any admin is very careful about disabling XFF on the border proxy. The admin feels dumb even before his users when he sees his internal addresses leak on the net. Probably that one proposal could be to recommend that the feature SHOULD not be enabled by default in implementations so that we're pretty sure that whenever it's done, it's on purpose. This would probably solve most of the issues expressed here with this header. Regards, Willy From cabo@tzi.org Tue Sep 4 11:47:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4EA21F8484 for ; Tue, 4 Sep 2012 11:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o71MGYLPIBUi for ; Tue, 4 Sep 2012 11:47:25 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4904221F8425 for ; Tue, 4 Sep 2012 11:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q84IkA5d007642; Tue, 4 Sep 2012 20:46:10 +0200 (CEST) Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D32FDC50; Tue, 4 Sep 2012 20:46:09 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <50464AAD.6060104@cs.tcd.ie> Date: Tue, 4 Sep 2012 20:46:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <700E38F9-942B-449A-9909-1067CEB1FB4C@tzi.org> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1486) Cc: Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:47:26 -0000 On Sep 4, 2012, at 20:38, Stephen Farrell = wrote: > Can you comment on > the engineering reasons for supporting this in outbound > proxies? I didn't have time to read the whole thread, but isn't a great = discussion for one such reason given in=20 [1] http://en.wikipedia.org/wiki/X-Forwarded-For [2] http://meta.wikimedia.org/wiki/XFF_project which you yourself cited in a previous message in this thread? (I.e., differentiating reputation that may be assigned to the outgoing = IP address of the proxy based on the previous origin of the request?) Gr=FC=DFe, Carsten From lear@cisco.com Tue Sep 4 11:47:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085BF11E809A for ; Tue, 4 Sep 2012 11:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IajuT-1LpDlS for ; Tue, 4 Sep 2012 11:47:52 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2969B11E809B for ; Tue, 4 Sep 2012 11:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=937; q=dns/txt; s=iport; t=1346784472; x=1347994072; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rniQA1PbKCs7ci0/wO9N0Y+hH4VUZsamGZdnHEEjj/4=; b=Wi46abUG9ZwDNFBhdkK7NU9+hVY+t6g9JOeqkNG7g8vhZqydUiPMS2Ob 9xgLCCDUSV3+ycs5bl/urEzMVUtAcmuEAapXtuEtqYnbOQxwdqSTcPK6u N1hDS5NtNG/Po3vSqZB33v8qLJZitegYSxgZUfwrqh3y23i65i7OYMZk7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJpLRlCQ/khR/2dsb2JhbAA7CoYFtR6BB4IgAQEBBBIBEARRARALGAICBRYLAgIJAwIBAgFFBg0BBwEBHodrmmeNGZJtgSGJeIYQgRIDlVmOM4FngmU X-IronPort-AV: E=Sophos;i="4.80,368,1344211200"; d="scan'208";a="76460096" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 04 Sep 2012 18:47:46 +0000 Received: from ams3-vpn-dhcp5817.cisco.com (ams3-vpn-dhcp5817.cisco.com [10.61.86.184]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q84IljQS010153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2012 18:47:45 GMT Message-ID: <50464CD1.7010200@cisco.com> Date: Tue, 04 Sep 2012 20:47:45 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Stephen Farrell References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> In-Reply-To: <50464AAD.6060104@cs.tcd.ie> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:47:53 -0000 Stephen, On 9/4/12 8:38 PM, Stephen Farrell wrote: > So even I don't see any issue with the reverse proxy case > where the same operator runs both the web server and > front-end. > > But that's not all this draft supports. Can you comment on > the engineering reasons for supporting this in outbound > proxies? > The issue here is this: / ------(Q) Host ----------------------> / ------(R) \ -------(S) You want to provide state stickiness for a pair , for instance, you want something to identify , which is what this header provides. doesn't need to be an IP address, by the way. The draft handles that part. Eliot From stephen.farrell@cs.tcd.ie Tue Sep 4 11:50:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D10111E809B for ; Tue, 4 Sep 2012 11:50:08 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj0LVZtGaaB2 for ; Tue, 4 Sep 2012 11:50:07 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A987511E809A for ; Tue, 4 Sep 2012 11:50:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1ADB817147D; Tue, 4 Sep 2012 19:50:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346784606; bh=4za5NpoYUm0O3/ rc48sm8lzzjm5rrEEspBDlNyyofJM=; b=dnmXOKzdczqLh/A/CivcUpkexh9Lrw QrP9MY7lgQSI8dvVSpTMufmoZDs0yV727RDK0flyAF8OLlgcSlcoBNXOc9/2fuy1 bGNLz+pcVERsp5O3pCooVvg55f6RCFQ+yyoaRXmLTRwiZ6C7ljSn026blUWVWHGz oiAr++HnzZ4tTinDPa4Ut+XbZq/St3Gqg2TSPHyLjvSb0urAjkFRY4znbQTImmuj DZOZGPZCQFiBwVggiNemBuGciLtlGvM/gtTnrs1tnQ4k8R9KEVNuHXuGH+3Boewy p/eg9/Yx4bDEmFhheOQem7p4LK/jB/xuvrOrpklEHHyjI7xjRSJZdpYw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Tc8pPl3MORyJ; Tue, 4 Sep 2012 19:50:06 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.56.126]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 378C217147B; Tue, 4 Sep 2012 19:50:06 +0100 (IST) Message-ID: <50464D5D.5010209@cs.tcd.ie> Date: Tue, 04 Sep 2012 19:50:05 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Willy Tarreau References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <20120904184534.GA12899@1wt.eu> In-Reply-To: <20120904184534.GA12899@1wt.eu> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:50:08 -0000 Hi Willy, On 09/04/2012 07:45 PM, Willy Tarreau wrote: > Probably that one proposal could be to recommend that the feature SHOULD > not be enabled by default in implementations so that we're pretty sure > that whenever it's done, it's on purpose. This would probably solve most > of the issues expressed here with this header. That would be a definite improvement, I agree. I'm not sure I agree it solves most issues, but nor am I sure there's any way to solve most issues, given XFF is out there already. S. From stephen.farrell@cs.tcd.ie Tue Sep 4 11:54:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B3E21F869E for ; Tue, 4 Sep 2012 11:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qf0i2yrpn5cH for ; Tue, 4 Sep 2012 11:54:51 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 602A621F846D for ; Tue, 4 Sep 2012 11:54:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B5DDC17147D; Tue, 4 Sep 2012 19:54:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346784890; bh=rKnlbyggE2hiNu cz2jFlcIeT5mDXYfgq3KvQ1zPPCTQ=; b=QeDj9fwO/su2v/dlXfIbj3Jpmb3g9m 8EpUur7OwXikwBv1aVV+l4Dd2/13rDmsICZC4hsmOAz7G68KLZoqB8dgEittldZ1 yM4rGWCVKgIaFxs/Dzi5TI20EFykQNG5SnADPIIrI+lMGdSuGtVWqhW4C7p66Y6P Y4oXs6RwqU8Qg6HZ/r7lOxv0Nxa8HtfwPaXD1FI6Nmabb3rbet+Aa9plwewRWRwf 14vQZSgA9PelS2PnVQty10x97GXWmv4kk0zI9Jd6C9MVBbpBJbPGjh9+xHECdp9/ Jx3RqUtV0Zw0Qwebqm+8yGSkKdUY/XG3CrXm4ffwE4utxk9FG9hgDkAw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id reebeub1FII0; Tue, 4 Sep 2012 19:54:50 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.56.126]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2821317147B; Tue, 4 Sep 2012 19:54:50 +0100 (IST) Message-ID: <50464E79.6060409@cs.tcd.ie> Date: Tue, 04 Sep 2012 19:54:49 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Eliot Lear References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> In-Reply-To: <50464CD1.7010200@cisco.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:54:52 -0000 On 09/04/2012 07:47 PM, Eliot Lear wrote: > Stephen, > > On 9/4/12 8:38 PM, Stephen Farrell wrote: >> So even I don't see any issue with the reverse proxy case >> where the same operator runs both the web server and >> front-end. >> >> But that's not all this draft supports. Can you comment on >> the engineering reasons for supporting this in outbound >> proxies? >> > > The issue here is this: > > > / ------(Q) > Host ----------------------> / ------(R) > > \ -------(S) > > You want to provide state stickiness for a pair , for instance, you > want something to identify , which is what this header provides. > doesn't need to be an IP address, by the way. The draft handles that part. Its not clear to me why it ever needs to be an IP address for (A,S) stickiness. E.g. Encr(k,A-addr||stuff) for some k known only to PROXY (or similar structures) would seem to me to be far better. (Various forms of <> might make sense.) S. > > Eliot > > From stephen.farrell@cs.tcd.ie Tue Sep 4 12:09:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD4B21E8088 for ; Tue, 4 Sep 2012 12:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1NzduHE4qEZ for ; Tue, 4 Sep 2012 12:09:52 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8752C21E8084 for ; Tue, 4 Sep 2012 12:09:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E30A117147E; Tue, 4 Sep 2012 20:09:51 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346785791; bh=GbHlinAoe/PM9B VdFoPquUZszbiPOePmhlFMaULrVe4=; b=Hni+XbDVxE8UMGI5UDlVqhA3wmZfR8 wiGNy8U8vq7Y00bC8EYJC8RFjoLddMGIWY0QNcqhQ15VxHi/52nZvtt8K7MD037B cL2EDQLTUogLlZQ0HSh4a/EPPqZZPP9AYby+s0FJbQPFJG6yeu9QJoATxbgd+49d gn2+gz2F52VeLejR8mw+696nQiFhDHe9YfI4rLQOLLNcMI2m1XyrUKzaOMJCvBi3 hrimzWp9792Kn1Mzmi7Qn+htZLZlnjXO973vDcMX+cqpRAB1/P/EDXCI+87jKqJ1 1YHGFVz0nbX05e6dYBZc4Tuf5KKaqigGUAzULtSLHx7pK0wuT5UQgcYQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Y8cjyanu4v6z; Tue, 4 Sep 2012 20:09:51 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.56.126]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 02A9517147B; Tue, 4 Sep 2012 20:09:50 +0100 (IST) Message-ID: <504651FE.9070904@cs.tcd.ie> Date: Tue, 04 Sep 2012 20:09:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Carsten Bormann References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <700E38F9-942B-449A-9909-1067CEB1FB4C@tzi.org> In-Reply-To: <700E38F9-942B-449A-9909-1067CEB1FB4C@tzi.org> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 19:09:53 -0000 On 09/04/2012 07:46 PM, Carsten Bormann wrote: > On Sep 4, 2012, at 20:38, Stephen Farrell wrote: > >> Can you comment on >> the engineering reasons for supporting this in outbound >> proxies? > > I didn't have time to read the whole thread, but isn't a great discussion for one such reason given in > > [1] http://en.wikipedia.org/wiki/X-Forwarded-For > [2] http://meta.wikimedia.org/wiki/XFF_project > > which you yourself cited in a previous message in this thread? I did. I've not thought through whether I like that or not but its clearly used. (Is that only by wikipedia or more broadly?) > (I.e., differentiating reputation that may be assigned to the outgoing IP address of the proxy based on the previous origin of the request?) Yep. But why put the UA's IP address in there? (See my response to Eliot.) S. > Gre, Carsten > > > From cabo@tzi.org Tue Sep 4 13:42:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F43A21F8501 for ; Tue, 4 Sep 2012 13:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGMYQH+vPHtt for ; Tue, 4 Sep 2012 13:42:48 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB8821F849B for ; Tue, 4 Sep 2012 13:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q84KgCRJ023995; Tue, 4 Sep 2012 22:42:12 +0200 (CEST) Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E0CCDC80; Tue, 4 Sep 2012 22:42:11 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <504651FE.9070904@cs.tcd.ie> Date: Tue, 4 Sep 2012 22:42:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <700E38F9-942B-449A-9909-1067CEB1FB4C@tzi.org> <504651FE.9070904@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1486) Cc: Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:42:49 -0000 On Sep 4, 2012, at 21:09, Stephen Farrell = wrote: > why put the UA's IP address in there If the user has a public address and multiple proxies to choose from, = you need coordination to arrive at the same token for the same user. (If these are private addresses -- and, for multiple proxies, if = coordination is achievable -- I certainly agree that there is no need to = disclose that information. But your scheme loses correlation between "close" addresses, which may = be useful for assigning reputation to entire blocks of addresses. =20 There are well-known schemes for "anonymizing" addresses that keep that = correlation available, say, CryptoPan.) Gr=FC=DFe, Carsten From mnot@mnot.net Tue Sep 4 19:03:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBDC21E80A8 for ; Tue, 4 Sep 2012 19:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqPBIdFkOpIh for ; Tue, 4 Sep 2012 19:03:07 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0664021E80A2 for ; Tue, 4 Sep 2012 19:03:06 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 059DA22E253; Tue, 4 Sep 2012 22:02:57 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: <01OJTNEBJV620006TF@mauve.mrochek.com> Date: Wed, 5 Sep 2012 12:02:53 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1972D7F2-E7C1-4066-BC83-904D68C733F3@mnot.net> <01OJRY9JYK8G0006TF@mauve.mrochek.com> <01OJS30QN9SW0006TF@mauve.mrochek.com> <03BAF4AA-C350-41D0-BD9D-FC6389873C84@vpnc.org> <01OJTNEBJV620006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1486) Cc: Barry Leiba , Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 02:03:07 -0000 On 04/09/2012, at 7:54 AM, Ned Freed wrote: >=20 >> Because of some locus of control differences in the way proxies >> are configured versus the way mail relays are, I think that, >> beyond a certain point, the analogy is actually debatable. >> Unless we want to have that debate for some reason, I'd suggest >> leaving the lily ungilded. >=20 > It really depends on what analogy you're trying to draw. I don't think = anyone > here is saying the semantics of Received: in email and Forwarded: in = HTTP are > identical. But there is substantial overlap, and it is *absolutely* = the case > that the privacy unicorn people seem to be hunting here, if real, = would also > exist with Received:. Which I believe was Mark's point. Indeed. > I'm a little unclear what this says about using Received: as an = example though. > If there is a need to justify this field by appealing to something = that has > been standardized and, far from being a security problem in actual = deployment, > is in fact a significant asset, then so be it. Otherwise I guess I = agree with > you that the debate is best avoided. One further point; I saw it asserted somewhere in this voluminous thread = that Received is used for spam control, whereas X-Forwarded-For (and = presumably Forwarded) are not.=20 In fact, many sites use XFF as one input into their abuse protection = systems; I've worked on a few. This includes data from headers generated = by "reverse" proxies as well as "normal" ones. Cheers, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Sep 4 23:46:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532C721F84B6 for ; Tue, 4 Sep 2012 23:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.499 X-Spam-Level: X-Spam-Status: No, score=-104.499 tagged_above=-999 required=5 tests=[AWL=-1.900, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISp027Xel0zT for ; Tue, 4 Sep 2012 23:46:55 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 82E0721F84FC for ; Tue, 4 Sep 2012 23:46:55 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6E83422E253; Wed, 5 Sep 2012 02:46:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: <1344968905.26501.10.camel@pbryan-wsl.internal.salesforce.com> Date: Wed, 5 Sep 2012 16:46:43 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <3F6373DA-C7AB-4979-9260-B59F21EC3E56@mnot.net> References: <1344968905.26501.10.camel@pbryan-wsl.internal.salesforce.com> To: Paul C. Bryan X-Mailer: Apple Mail (2.1486) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] JSON-Patch: testing objects [#11] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 06:46:56 -0000 I've just incorporated these; see: http://trac.tools.ietf.org/wg/appsawg/trac/changeset/107 Thanks, On 15/08/2012, at 4:28 AM, Paul C. Bryan wrote: > On Sat, 2012-08-11 at 17:21 -0500, Mark Nottingham wrote: >> I've checked in some text that tries to address #11, and ended = clarifying other parts about how "test" works. >>=20 >> Proposed text: >>=20 >> ---8<--- >> 4.6. test >>=20 >> The "test" operation tests that a value at the specified location = in >> the target document is equal to a specified value. The operation >> object contains a "value" member that specifies the value to test >> for. >>=20 >> Here, "equal" means that the target and specified values are = compared >> using the following rules: >>=20 >=20 > Possibly point-out that both values must have the same type in order = to evaluate to equal? In other words, 0 the number and "0" the string = are not equal. >=20 >> o strings: are considered equal if, after unescaping any = sequence(s) >> in either string starting with a reverse solidus, they contain = the >> same number of Unicode characters and their code points are >> position-wise equal. >>=20 >=20 > s/either/both/. Logically makes sense. >=20 >> o numbers: are considered equal if they subtracting one from the >> other results in 0. >>=20 >=20 > s/they //. Logically, makes sense. >=20 >> o arrays: are considered equal if they contain the same number of >> values, and each value can be considered equal to the value at = the >> corresponding position in the other array. >>=20 >> o objects: are considered equal if they contain the same number = of >> members, and each member can be considered equal to a member in >> the other object. Note that ordering of the serialisation of >> object members is not significant. >>=20 >=20 > I would point out that member equality means that the key =3D=3D key = (string) and value =3D=3D value (both values must be of same type and = evaluate equally per this section). >=20 >>=20 >> o literals (false, true and null): are considered equal if they = are >> the same. >>=20 >> Note that this is a logical comparison; e.g., whitespace between = the >> member values of an array is not significant. >> --->8--- >>=20 >> This is obviously going to need some examples (particularly around = comparing numbers and strings, I think), but I wanted to make sure = people were OK with this direction first. >>=20 >> In particular, does escaping strings before comparison make sense? = And, is the technique for comparing numbers adequate? >>=20 >> Regards, >>=20 >>=20 >> -- >> Mark Nottingham >>=20 >> http://www.mnot.net/ >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >>=20 >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Sep 4 23:56:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAB311E80DF for ; Tue, 4 Sep 2012 23:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.228 X-Spam-Level: X-Spam-Status: No, score=-104.228 tagged_above=-999 required=5 tests=[AWL=-1.629, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aVz4MFT2Uax for ; Tue, 4 Sep 2012 23:56:34 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 47D4011E80DE for ; Tue, 4 Sep 2012 23:56:34 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1BC8D22E1F4; Wed, 5 Sep 2012 02:56:26 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: <50335023.2080300@gmx.de> Date: Wed, 5 Sep 2012 16:56:23 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <2CCD45E4-9E06-426C-A795-12C820F9E5FD@mnot.net> References: <50335023.2080300@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1486) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-pointer-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 06:56:35 -0000 Hi Julian, I've incorporated all of these (except the updated ref): http://trac.tools.ietf.org/wg/appsawg/trac/changeset/108 Cheers, On 21/08/2012, at 7:08 PM, Julian Reschke wrote: > Hi. >=20 > first of all: thanks Mark for taking over. >=20 > Below are a few comments...: >=20 >> This specification expresses normative syntax rules using Augmented >> Backus-Naur Form [RFC5234] (ABNF) notation. >=20 > s/[RFC5234] (ABNF)/(ABNF) [RFC5234]/ >=20 >> If a reference token contains '~' (%x7E) or '/' (%x2F) characters, >> they MUST be encoded as '~0' and '~1' respectively. >=20 > I'd prefer this to be a statement of fact, not a requirement. Such as: >=20 > "As the characters '~' (%x7E) and '/' (%x2F) characters have a special = meaning in JSON pointer and thus need to be encoded as'~0' and '~1' = respectively." >=20 >> If the currently referenced value is a JSON object, the new >> referenced value is the object member with the name (after >> unescaping any backslash escape sequences that can occur in a = JSON >> string) identified by the reference token. The member name is >=20 > What unescaping does this refer to? Is this about JSON Pointers = transported inside JSON string values? In that case I think this should = be dropped; it's not relevant here. (JSON Pointer in JSON strings is = first mentioned in the following section). >=20 >> A JSON Pointer can be represented in a JSON string value. Per >> [RFC4627], section 2.5, all instances of quotation mark '"' (%x22), >=20 > s/section/Section/ >=20 >> A JSON Pointer can be represented in a URI fragment identifier. by >> encoding it into octets, using UTF-8 [RFC3629], percent-encoding >> those characters not allowed by the fragment rule in [RFC3986]. >=20 > s/identifier. by/identifier by/ >=20 >> Note that a given media type needs to nominate JSON Pointer as its >> fragment identifier syntax explicitly (usually, in its registration >> [RFC4288]); i.e., just because a document is JSON does not imply = that >> JSON Pointer can be used as its fragment identifier syntax. >=20 > I think it would be good to make it very clear that the current = definition of JSON does NOT define a fragment identifier syntax. >=20 >> [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and >> Registration Procedures", BCP 13, RFC 4288, December = 2005. >=20 > This should reference draft-ietf-appsawg-media-type-regs-14 which is = already in the RFC publication queue. >=20 > Best regards, Julian >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From internet-drafts@ietf.org Wed Sep 5 00:17:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7DE21F8470; Wed, 5 Sep 2012 00:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.223 X-Spam-Level: X-Spam-Status: No, score=-102.223 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqyHT4vJDlYE; Wed, 5 Sep 2012 00:17:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDB921F849D; Wed, 5 Sep 2012 00:17:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120905071732.27614.88368.idtracker@ietfa.amsl.com> Date: Wed, 05 Sep 2012 00:17:32 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:17:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : JSON Pointer Author(s) : Paul C. Bryan Kris Zyp Mark Nottingham Filename : draft-ietf-appsawg-json-pointer-04.txt Pages : 8 Date : 2012-09-05 Abstract: JSON Pointer defines a string syntax for identifying a specific value within a JSON document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-pointer-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Sep 5 00:17:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FBD21E8099; Wed, 5 Sep 2012 00:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VsVf34zYlYE; Wed, 5 Sep 2012 00:17:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E355121E80A2; Wed, 5 Sep 2012 00:17:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120905071741.6194.64551.idtracker@ietfa.amsl.com> Date: Wed, 05 Sep 2012 00:17:41 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:17:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : JSON Patch Author(s) : Paul C. Bryan Mark Nottingham Filename : draft-ietf-appsawg-json-patch-03.txt Pages : 14 Date : 2012-09-05 Abstract: JSON Patch defines the media type "application/json-patch", a JSON document structure for expressing a sequence of operations to apply to a JSON document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-patch-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mnot@mnot.net Wed Sep 5 00:18:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D11A21E809C for ; Wed, 5 Sep 2012 00:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.024 X-Spam-Level: X-Spam-Status: No, score=-104.024 tagged_above=-999 required=5 tests=[AWL=-1.425, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xwibnsYFL-G for ; Wed, 5 Sep 2012 00:18:49 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 974AA21F84AF for ; Wed, 5 Sep 2012 00:18:49 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3E0C422E25B for ; Wed, 5 Sep 2012 03:18:42 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 5 Sep 2012 17:18:39 +1000 To: Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) Subject: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:18:50 -0000 I've just submitted revised json-pointer and json-patch documents, based = upon feedback. As far as I can tell, the only open issue on JSON-Patch is about 'test': http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7 In Vancouver, we said that we'd wait for implementation experience to = see if 'test' is worthwhile. In the meantime, I've found two implementations of json-patch "in the = wild": https://github.com/stefankoegl/python-json-patch https://github.com/bruth/jsonpatch-js Both are somewhat old, and both support 'test'. As such, I'd suggest we let 'test' remain in the spec (I think there are = good arguments for it anyway), and ship it. Make sense? -- Mark Nottingham http://www.mnot.net/ From enrico.marocco@telecomitalia.it Wed Sep 5 02:53:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E60E21F861F for ; Wed, 5 Sep 2012 02:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.719 X-Spam-Level: X-Spam-Status: No, score=-101.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eViKKlLe7Dnq for ; Wed, 5 Sep 2012 02:53:02 -0700 (PDT) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6587921F861D for ; Wed, 5 Sep 2012 02:53:02 -0700 (PDT) Received: from grfhub703rm001.griffon.local (10.19.3.10) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 5 Sep 2012 11:53:00 +0200 Received: from MacLab.local (10.229.8.38) by smtp.telecomitalia.it (10.19.9.236) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 5 Sep 2012 11:52:51 +0200 Message-ID: <504720F3.1080505@telecomitalia.it> Date: Wed, 5 Sep 2012 11:52:51 +0200 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090805010602010103090901" X-TI-Disclaimer: Disclaimer1 Subject: Re: [apps-discuss] Meeting minutes available X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 09:53:03 -0000 --------------ms090805010602010103090901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 8/5/12 9:35 AM, Murray S. Kucherawy wrote: > Please review them and provide any corrections. In particular, there > are a couple of places where "?" appears. If those blanks could be > filled in, we'd appreciate it. Also, if we failed to capture any > important action items, please bring those to our attention. You can get rid of one just by s/Marco \?/Enrico:/. Just noticed, sorry for not pointing this out earlier. Enrico --------------ms090805010602010103090901 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MDUw OTUyNTFaMCMGCSqGSIb3DQEJBDEWBBRmX0wC2uLq5oyWu1y5GJNY4rO4PjBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAkst/Vno0u4AnXXlb4TK6lAfLu80CJcxkBaNvu4yC OfP4bPNy/Fbmgs0tGNU4nKkLwUDix0MMCdPWGLciS9GmeYwGzL6kR1ktlplRbjBpdKbDDXrQ BbMyWvx8MXxDJW1DK3Sz2aUkQ5PBIyDBNHxDZAGwnXjMrMSgdslrcx+W8wFLjggEZod/8PJe z5T+bzxLEibhj7ZGgcQkOFxr1M7Q54Hg2hXKLs/dBy0cXWiqpIScZs6ZVqMTwhQaSbd2EzR0 Gjqv5d0sAFvcgpOKbiKzNMOh1dOu5+RPyRFFBZ+Uq2enP8vXnADj8TfwBloin+jmJ6z/dh7j o6xJES2Gy12pagAAAAAAAA== --------------ms090805010602010103090901-- From julian.reschke@gmx.de Wed Sep 5 05:18:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDF021F84DA for ; Wed, 5 Sep 2012 05:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtwEUQ7ih-fQ for ; Wed, 5 Sep 2012 05:18:11 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 3C58F21F84FD for ; Wed, 5 Sep 2012 05:18:11 -0700 (PDT) Received: (qmail invoked by alias); 05 Sep 2012 12:18:10 -0000 Received: from p54BB3C07.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.60.7] by mail.gmx.net (mp012) with SMTP; 05 Sep 2012 14:18:10 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+WpuokSQCWdryjrJJIA898tFTkCisYVJkO2vG6ko Z1BC6ehHiQWk6b Message-ID: <504742FE.5060201@gmx.de> Date: Wed, 05 Sep 2012 14:18:06 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Mark Nottingham References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps Discuss Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 12:18:12 -0000 On 2012-09-05 09:18, Mark Nottingham wrote: > I've just submitted revised json-pointer and json-patch documents, based upon feedback. > > As far as I can tell, the only open issue on JSON-Patch is about 'test': > http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7 > > In Vancouver, we said that we'd wait for implementation experience to see if 'test' is worthwhile. > > In the meantime, I've found two implementations of json-patch "in the wild": > https://github.com/stefankoegl/python-json-patch > https://github.com/bruth/jsonpatch-js > > Both are somewhat old, and both support 'test'. > > As such, I'd suggest we let 'test' remain in the spec (I think there are good arguments for it anyway), and ship it. > > Make sense? Absolutely. From fgaliegue@gmail.com Wed Sep 5 05:32:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC4521F8672 for ; Wed, 5 Sep 2012 05:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQN7fa2JXuBC for ; Wed, 5 Sep 2012 05:32:05 -0700 (PDT) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id 649FB21F864A for ; Wed, 5 Sep 2012 05:32:05 -0700 (PDT) Received: by vbbfo1 with SMTP id fo1so31419vbb.22 for ; Wed, 05 Sep 2012 05:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=WXH5TmVdsKj+ZqlzIEgKn8plqZB6qVmw72aIwzFMin4=; b=V2LNn5KFYNIB9zLgmrGlrnAPPuNPuSUSKOuKcJVVmJhNH8/ODwYqY5Vw4ZNC3YCPJr lUA/cDeHzxw8CiglmWOuc9q/3xqNBvRPRtIkZWtPZmQ/Mups3pElzEIsqiMzPLIamGhZ maBcur6GHKNk3tEpxuyPhhCcQRcZXHsyo3rnp747nrxuxWoh6nWJzUdvgeBlqtuEP7Oz QQiv3+33ewoit0q5P2yCA5sbtO+1e/kKpqZzFN72QDU2/cWeh/WYeHclGczwaVJzEpfO O91tDqI+mtdwkAQthGPOK/wyS9WdOJ82JLiDAhbgjmp63u2aVU/9B9CxYb8NroneopnN 0vgQ== MIME-Version: 1.0 Received: by 10.220.221.72 with SMTP id ib8mr2325481vcb.25.1346848320795; Wed, 05 Sep 2012 05:32:00 -0700 (PDT) Received: by 10.52.23.103 with HTTP; Wed, 5 Sep 2012 05:32:00 -0700 (PDT) Date: Wed, 5 Sep 2012 14:32:00 +0200 Message-ID: From: Francis Galiegue To: discuss@apps.ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 12:32:06 -0000 Hello everyone, An organization now exists on GitHub which tries and revives JSON Schema. The latest accepted draft has expired for more than a year now, but this doesn't prevent JSON Schema from being used in the wild today -- with varying levels of support and conformance. The main repository of this organization is located here: https://github.com/json-schema/json-schema The goal is to have, in a reasonable time frame, another draft, or set of drafts, suitable for submission. Right now, the organization is still a loosely knit team of people with interests in the subject (my personal interest is validation, I have a Java implementation which already has some users), and this mail is a humble request addressed at seasoned IETF members to ask for guidance as to what should be done to: * write a sane enough draft, or set of drafts, * having it, or them, reviewed and commented. Humbly yours, --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From barryleiba.mailing.lists@gmail.com Wed Sep 5 06:10:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A46321F85B1 for ; Wed, 5 Sep 2012 06:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.823 X-Spam-Level: X-Spam-Status: No, score=-102.823 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qJTKoKsh6Bu for ; Wed, 5 Sep 2012 06:10:01 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2020921F865B for ; Wed, 5 Sep 2012 06:10:00 -0700 (PDT) Received: by lbky2 with SMTP id y2so433157lbk.31 for ; Wed, 05 Sep 2012 06:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ojkCwjnfF2XyI28xvXQJbCZyBtqufsvjztxhZ0swpjM=; b=LQe8708EBd0OUQx3JuuckyKeoYiTtePqOtV25vKVwzGCCaExIMJkcRbfzZ9nFuKhWA dLAhH8fKJn4EouktcTUxf7fG3OqsKVIGJA7f1o/QKtP1/wvOpD1k4yW+9dO6QkdxbLpU GyR8nt35rco2vC0zIjmuehl/P06Wy9gpsGcuR6KW2bsUXR/9BqXf9c7KXBpcaK+CQTz/ dxJ2R29hBmX/wWuISTEpgMVTX+RZ9IUf0iFwFGP1yTRIPLVqmeFXownG0MzvoOhOXCiJ 0DUE1OlJGV6bKbC6DgM2YWCX069f+4Ak0bM7VWY/xuxp8D60p+ovCVCTGnmfhlcwdADC Jigg== MIME-Version: 1.0 Received: by 10.112.30.34 with SMTP id p2mr7788282lbh.85.1346850590580; Wed, 05 Sep 2012 06:09:50 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Wed, 5 Sep 2012 06:09:50 -0700 (PDT) In-Reply-To: <504720F3.1080505@telecomitalia.it> References: <504720F3.1080505@telecomitalia.it> Date: Wed, 5 Sep 2012 09:09:50 -0400 X-Google-Sender-Auth: ZTNHex7K7sceuMhVn0szhNgcyZs Message-ID: From: Barry Leiba To: Enrico Marocco Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Meeting minutes available X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 13:10:02 -0000 > You can get rid of one just by s/Marco \?/Enrico:/. Just noticed, sorry > for not pointing this out earlier. Haha... sorry, that was my fault: I remembered your last name, and mangled it to "Marco" as a given name. :-) My apologies. Barry From lhotka@nic.cz Wed Sep 5 06:32:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A9021F84D3 for ; Wed, 5 Sep 2012 06:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZa1pW56B1aZ for ; Wed, 5 Sep 2012 06:32:24 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5351F21F84D9 for ; Wed, 5 Sep 2012 06:32:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 2B763540246; Wed, 5 Sep 2012 15:32:22 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpYyRRpiS+Ha; Wed, 5 Sep 2012 15:32:15 +0200 (CEST) Received: from localhost (fw.nic.cz [217.31.207.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id B4B535401B9; Wed, 5 Sep 2012 15:32:14 +0200 (CEST) From: Ladislav Lhotka To: Francis Galiegue , discuss@apps.ietf.org In-Reply-To: References: User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Wed, 05 Sep 2012 15:32:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 13:32:25 -0000 Hi, FWIW, my I-D draft-lhotka-yang-json-01 allows for using YANG as a schema (o= r rather data modelling) language for JSON. Lada Francis Galiegue writes: > Hello everyone, > > An organization now exists on GitHub which tries and revives JSON > Schema. The latest accepted draft has expired for more than a year > now, but this doesn't prevent JSON Schema from being used in the wild > today -- with varying levels of support and conformance. > > The main repository of this organization is located here: > > https://github.com/json-schema/json-schema > > The goal is to have, in a reasonable time frame, another draft, or set > of drafts, suitable for submission. > > Right now, the organization is still a loosely knit team of people > with interests in the subject (my personal interest is validation, I > have a Java implementation which already has some users), and this > mail is a humble request addressed at seasoned IETF members to ask for > guidance as to what should be done to: > > * write a sane enough draft, or set of drafts, > * having it, or them, reviewed and commented. > > Humbly yours, > --=20 > Francis Galiegue, fgaliegue@gmail.com > JSON Schema: https://github.com/json-schema > "It seems obvious [...] that at least some 'business intelligence' > tools invest so much intelligence on the business side that they have > nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The > Art of SQL", ISBN 0-596-00894-5) > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From pbryan@anode.ca Wed Sep 5 07:34:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9832D21F8623 for ; Wed, 5 Sep 2012 07:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kJsv8jpNn+Y for ; Wed, 5 Sep 2012 07:34:46 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id F22A321F85A4 for ; Wed, 5 Sep 2012 07:34:45 -0700 (PDT) Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 59072646E for ; Wed, 5 Sep 2012 14:34:45 +0000 (UTC) From: "Paul C. Bryan" To: Apps Discuss In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-eZkR09WgxIat/4+yhQKA" Date: Wed, 05 Sep 2012 07:34:37 -0700 Message-ID: <1346855677.16601.4.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:34:46 -0000 --=-eZkR09WgxIat/4+yhQKA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit +1 On Wed, 2012-09-05 at 17:18 +1000, Mark Nottingham wrote: > I've just submitted revised json-pointer and json-patch documents, based upon feedback. > > As far as I can tell, the only open issue on JSON-Patch is about 'test': > http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7 > > In Vancouver, we said that we'd wait for implementation experience to see if 'test' is worthwhile. > > In the meantime, I've found two implementations of json-patch "in the wild": > https://github.com/stefankoegl/python-json-patch > https://github.com/bruth/jsonpatch-js > > Both are somewhat old, and both support 'test'. > > As such, I'd suggest we let 'test' remain in the spec (I think there are good arguments for it anyway), and ship it. > > Make sense? > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-eZkR09WgxIat/4+yhQKA Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit +1

On Wed, 2012-09-05 at 17:18 +1000, Mark Nottingham wrote: 
I've just submitted revised json-pointer and json-patch documents, based upon feedback.

As far as I can tell, the only open issue on JSON-Patch is about 'test':
  http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7

In Vancouver, we said that we'd wait for implementation experience to see if 'test' is worthwhile.

In the meantime, I've found two implementations of json-patch "in the wild":
  https://github.com/stefankoegl/python-json-patch
  https://github.com/bruth/jsonpatch-js

Both are somewhat old, and both support 'test'.

As such, I'd suggest we let 'test' remain in the spec (I think there are good arguments for it anyway), and ship it.

Make sense?

--
Mark Nottingham   http://www.mnot.net/



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--=-eZkR09WgxIat/4+yhQKA-- From hallam@gmail.com Wed Sep 5 08:37:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B85E21F858F for ; Wed, 5 Sep 2012 08:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSHVzJyYXUfq for ; Wed, 5 Sep 2012 08:37:43 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by ietfa.amsl.com (Postfix) with ESMTP id 02DF321F8587 for ; Wed, 5 Sep 2012 08:37:42 -0700 (PDT) Received: by obbta17 with SMTP id ta17so547229obb.22 for ; Wed, 05 Sep 2012 08:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wMU9/cSI7+p84AbfkOcW9ba5WvkXuwdHbPoYdBaP4ro=; b=qKQ7qcuP1RqaxQ2EiutZsOg5Z1pAdvDsOigJ63eZ71pcBhBWP3kaIIwFegal7koTOS qPLHay0+fXGXUPOr+N02N4bh3EAlWmHF9te8reVoqkmQuQ8nmmHbTxTwGXjkVnNDYsrN 8Th7LXCygi1vhrmaQbyfWJZvO5bFOH7cW1U+44gYeHj25Dleu2qKhDdK/TlgEWsFJNUo NJMkugLZrZClS+6x5q/6PCirwOYeYwRsuWgeTCYMMAeGO7aUWyALRbhuyhIIb3YZWNUY yUzFmBx9qLEsCZvtSZX9QreUXGtpSwx6ZGAvUkaKfKYBjdvi+uDlgX+8GtRi9bs35qhu nluQ== MIME-Version: 1.0 Received: by 10.182.86.200 with SMTP id r8mr6730824obz.98.1346859462259; Wed, 05 Sep 2012 08:37:42 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Wed, 5 Sep 2012 08:37:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Sep 2012 11:37:42 -0400 Message-ID: From: Phillip Hallam-Baker To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:37:46 -0000 I think what is needed here is a mapping between the data structures used in today's mainstream programming languages and JSON. Encoding that mapping in JSON does not interest me at all as it is not a programming language. As far as I am concerned there is C, C#, Java and the rest. The only distinction between those as far as the data model is concerned is whether there is inheritance (C#, Java) or not. There are big differences between Java and C# as far as features are concerned, but they both have essentially the same data model: C types and structures plus single inheritance. The rest divide up into three groups, the good, the bad and the ugly. The 'good' are strongly typed functional languages like F# that are grounded in a data model close enough to C that they can be used for real work. The bad are the legacy languages like Cobol, Fortran, Pascal and a host of toys developed by academics for 'teaching'. People still use them but they don't use them to write JSON Web Services and if they did they would not want a schema so they can be safely ignored. The ugly are the weakly/untyped 'scripting'languages like Perl. These don't 'need' a schema because they don't 'need types. Instead people either learn how to debug their scripts without the benefits of strong typing or they learn to live with the bugs the machine could have caught for them. So rather than develop yet another schema language I would suggest a better approach would be to look at the scheme used in SSL/TLS which has a C-like schema used to describe the protocol exchanges. That is what I am doing at any rate. The only difference being that I don't like the clutter introduced by the semicolons and braces which the C people thought they needed at the time. I prefer an occam/python style with indentation denoting block structure. On Wed, Sep 5, 2012 at 9:32 AM, Ladislav Lhotka wrote: > Hi, > > FWIW, my I-D draft-lhotka-yang-json-01 allows for using YANG as a schema = (or rather data modelling) language for JSON. > > Lada > > Francis Galiegue writes: > >> Hello everyone, >> >> An organization now exists on GitHub which tries and revives JSON >> Schema. The latest accepted draft has expired for more than a year >> now, but this doesn't prevent JSON Schema from being used in the wild >> today -- with varying levels of support and conformance. >> >> The main repository of this organization is located here: >> >> https://github.com/json-schema/json-schema >> >> The goal is to have, in a reasonable time frame, another draft, or set >> of drafts, suitable for submission. >> >> Right now, the organization is still a loosely knit team of people >> with interests in the subject (my personal interest is validation, I >> have a Java implementation which already has some users), and this >> mail is a humble request addressed at seasoned IETF members to ask for >> guidance as to what should be done to: >> >> * write a sane enough draft, or set of drafts, >> * having it, or them, reviewed and commented. >> >> Humbly yours, >> -- >> Francis Galiegue, fgaliegue@gmail.com >> JSON Schema: https://github.com/json-schema >> "It seems obvious [...] that at least some 'business intelligence' >> tools invest so much intelligence on the business side that they have >> nothing left for generating SQL queries" (St=E9phane Faroult, in "The >> Art of SQL", ISBN 0-596-00894-5) >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=20 Website: http://hallambaker.com/ From alexey.melnikov@isode.com Wed Sep 5 08:46:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE78C21F8669 for ; Wed, 5 Sep 2012 08:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.603 X-Spam-Level: X-Spam-Status: No, score=-100.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3GdRzKI5ewY for ; Wed, 5 Sep 2012 08:46:45 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id ECA9921F865E for ; Wed, 5 Sep 2012 08:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1346860003; d=isode.com; s=selector; i=@isode.com; bh=aOM34HNdklaRy3JPyGrMY1VTyMSegKVATjEkipe0QvQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=A8k7iFjZByUpuPClEEr3ipju9lbOV/1G1zbH3t8WCMZJtfB8rOOMAZkyZkwYDMheHi26vz x1c/aFPeO3vknMr0nenhiP/sHXbiO3TS6AblnKIHHtqVeKBucaaYPZHONdH4RH9H9yPxE3 PSEh+TPKdfPYrwOYL5rFJViWvpCENYE=; Received: from [188.28.215.154] (188.28.215.154.threembb.co.uk [188.28.215.154]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 5 Sep 2012 16:46:43 +0100 References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> In-Reply-To: <50464E79.6060409@cs.tcd.ie> Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Wed, 5 Sep 2012 16:47:53 +0100 To: Stephen Farrell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:46:46 -0000 Hi Stephen, On 4 Sep 2012, at 19:54, Stephen Farrell wrote: > On 09/04/2012 07:47 PM, Eliot Lear wrote: >> Stephen, >>=20 >> On 9/4/12 8:38 PM, Stephen Farrell wrote: >>> So even I don't see any issue with the reverse proxy case >>> where the same operator runs both the web server and >>> front-end. >>>=20 >>> But that's not all this draft supports. Can you comment on >>> the engineering reasons for supporting this in outbound >>> proxies? >>>=20 >>=20 >> The issue here is this: >>=20 >>=20 >> / ------(Q) >> Host ----------------------> / ------(= R) >>=20 >> \ -------(S) >>=20 >> You want to provide state stickiness for a pair , for instance, you >> want something to identify , which is what this header provides. >> doesn't need to be an IP address, by the way. The draft handles that par= t. >=20 > Its not clear to me why it ever needs to be an IP address > for (A,S) stickiness. >=20 > E.g. Encr(k,A-addr||stuff) for some k known only to > PROXY (or similar structures) would seem to me to be far > better. (Various forms of <> might make sense.) >=20 I am pretty sure that obfuscated-IP and obfuscated-port are exactly what you= ask for and they were in the document for ages. From jasnell@gmail.com Wed Sep 5 08:47:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BF621F8495 for ; Wed, 5 Sep 2012 08:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0sJM1JHRs3p for ; Wed, 5 Sep 2012 08:47:23 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3177121F8484 for ; Wed, 5 Sep 2012 08:47:23 -0700 (PDT) Received: by wibhm2 with SMTP id hm2so4992932wib.16 for ; Wed, 05 Sep 2012 08:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mvQFKHGRFf0GqkdppxiITkFOwMguqjjMoKPoqinWvh4=; b=Tkl8gMKrs8p04d7q/mSOndhPJ5bMbyPlM8Eb/a35E/PtzFhdrVVW9f6aIFLvWhUlvj kHLWDe8icernzcTHfscbKqJw/b/VUC1Kjlifygkye57acOFlPWB0ktYJAx3gj1aNigzy uUB0qtcofXHWC6GEshMo8TS7+4n+3JcdnY5YtIyZOypk2yfuLY7HXM7gxZQgXu8oeWtA dY3Om8cOCy0TNF8OE1DPRHPsyvsY2crAouZgjw+SuhRpRTVrfZYRMQDHyzJjwI0D5mG8 ZTv1XnfLlv7r7YMwK3jeSv7BEWchhNDacq1HXkKj/PG+6HuS2Jm3UdQNkmjme/mgQztV 0gxg== Received: by 10.180.109.129 with SMTP id hs1mr39168689wib.0.1346860041887; Wed, 05 Sep 2012 08:47:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.58.136 with HTTP; Wed, 5 Sep 2012 08:47:01 -0700 (PDT) In-Reply-To: References: From: James M Snell Date: Wed, 5 Sep 2012 08:47:01 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=e89a8f13ea885bddf404c8f64a4c Cc: Apps Discuss Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:47:29 -0000 --e89a8f13ea885bddf404c8f64a4c Content-Type: text/plain; charset=UTF-8 Three points... 1) Re: test ... I would like to see more detail on why "test" would be used in a patch document. Perhaps just by expanding on the example just a bit. 2) Section 5's discussion of error handling should be expanded a bit. Yes the changes are atomic but a clear example of exactly what that means would be helpful. Example: This json-patch would result in no changes being made to the document at all. [ {"replace": "/a/b/c", "value": 42}, {"test": "/a/b/c", "value": "C"} ] 3) Unless we specifically want to allow for such things, it should be made clear that "test" is not intended to be used as a replacement for other types of http conditionals. For instance, I could imagine someone doing something like... [ {"test": "/foo/last-updated", "value": "2012-12-12T12:12:12Z"}, ("add": "/a/b/c", "value": 42} ] Or... [ {"test": "/@etag", "value": "ABC123"}, ("add": "/a/b/c", "value": 42} ] - James On Wed, Sep 5, 2012 at 12:18 AM, Mark Nottingham wrote: > I've just submitted revised json-pointer and json-patch documents, based > upon feedback. > > As far as I can tell, the only open issue on JSON-Patch is about 'test': > http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7 > > In Vancouver, we said that we'd wait for implementation experience to see > if 'test' is worthwhile. > > In the meantime, I've found two implementations of json-patch "in the > wild": > https://github.com/stefankoegl/python-json-patch > https://github.com/bruth/jsonpatch-js > > Both are somewhat old, and both support 'test'. > > As such, I'd suggest we let 'test' remain in the spec (I think there are > good arguments for it anyway), and ship it. > > Make sense? > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --e89a8f13ea885bddf404c8f64a4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Three points...=C2=A0

1) Re: test ... I would like to see more detail on why &quo= t;test" would be used in a patch document. Perhaps just by expanding o= n the example just a bit.

2) Section 5's discussion of error handling = should be expanded a bit. Yes the changes are atomic but a clear example of= exactly what that means would be helpful.

Example: This json-patch would result in no cha= nges being made to the document at all.

[
= =C2=A0{= "replace": "/a/b/c", "value": 42},
=C2=A0{"test": "/= a/b/c", "value": "C"}
]

3) Unless we specif= ically want to allow for such things, it should be made clear that "te= st" is not intended to be used as a replacement for other types of htt= p conditionals. For instance, I could imagine someone doing something like.= ..

[
=C2=A0{"test": "/foo/last-updated", "val= ue": "2012-12-12T12:12:12Z"},
=C2=A0("add": "/a= /b/c", "value": 42}
]
Or...

[
=C2=A0{"test": "/@etag", "value": "ABC1= 23"},
=C2=A0("add": "/a= /b/c", "value": 42}
]

- James
<= br>
On Wed, Sep 5, 2012 at 12:18 AM, Mark Not= tingham <mnot@mnot.net> wrote:
I've just submitted revised json-pointer= and json-patch documents, based upon feedback.

As far as I can tell, the only open issue on JSON-Patch is about 'test&= #39;:
=C2=A0 http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7

In Vancouver, we said that we'd wait for implementation experience to s= ee if 'test' is worthwhile.

In the meantime, I've found two implementations of json-patch "in = the wild":
=C2=A0 https://github.com/stefankoegl/python-json-patch
=C2=A0 = https://github.com/bruth/jsonpatch-js

Both are somewhat old, and both support 'test'.

As such, I'd suggest we let 'test' remain in the spec (I think = there are good arguments for it anyway), and ship it.

Make sense?

--
Mark Nottingham =C2=A0 h= ttp://www.mnot.net/



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--e89a8f13ea885bddf404c8f64a4c-- From acooper@cdt.org Wed Sep 5 09:12:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937F021F86BB for ; Wed, 5 Sep 2012 09:12:57 -0700 (PDT) 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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPrCIfz49JHg for ; Wed, 5 Sep 2012 09:12:57 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id EAE9321F86C5 for ; Wed, 5 Sep 2012 09:12:56 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 5 Sep 2012 12:12:52 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: Date: Wed, 5 Sep 2012 12:12:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 16:12:57 -0000 Hi Alexey, On Sep 5, 2012, at 11:47 AM, Alexey Melnikov wrote: > I am pretty sure that obfuscated-IP and obfuscated-port are exactly = what you ask for and they were in the document for ages. >=20 Except that there isn't any normative suggestion that the obfuscated = identifiers should be preferred or used by default, or that client = addresses should only be used if there is some address-related = functionality required by the endpoint.=20 Alissa > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From stephen.farrell@cs.tcd.ie Wed Sep 5 09:17:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F7221F8653 for ; Wed, 5 Sep 2012 09:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUKvrdO+lHxk for ; Wed, 5 Sep 2012 09:17:56 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id AA87E21F8648 for ; Wed, 5 Sep 2012 09:17:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 219D017147E; Wed, 5 Sep 2012 17:17:55 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346861874; bh=P2wvscp43Lv7YM SB6BDQtX+VHC6KsezznF8RwLZtLk4=; b=jsiaBvxJgNyg5dnILibMPSx8HQJ0QN SPVgd+iWmrz/YkXdO6tGmtrefpYB1+hm35fcPQoTku6Lm8yN/anQCt2RnXAXqeP9 R5Zz7ksdcxnLDngIMTtQOlem7r2yMmd0jmRrreDn3bf+E05vRgW1A3tOVDCZGysc OO8oIgXEiIrhynX/Hec9qmFk7undDpvB2laVffbENtbASN7MDA1gyakY8BRRDV69 EglR5WsHQflBM5oGPudxN2PQFnF2qRCBihN0upMbM8lYtc1aPqBMBfaIfKXQ5uL7 qKFuvd8xDHn9slmO8bLuqBg5yLIHE1bUG4rDwI4jmTz0/BLwWTi3WtJw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id C8uDOF2VB7OX; Wed, 5 Sep 2012 17:17:54 +0100 (IST) Received: from [IPv6:2001:770:10:203:a174:5461:2593:8b31] (unknown [IPv6:2001:770:10:203:a174:5461:2593:8b31]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 9F809171473; Wed, 5 Sep 2012 17:17:53 +0100 (IST) Message-ID: <50477B31.40508@cs.tcd.ie> Date: Wed, 05 Sep 2012 17:17:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Alexey Melnikov References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 16:17:56 -0000 On 09/05/2012 04:47 PM, Alexey Melnikov wrote: > Hi Stephen, > > On 4 Sep 2012, at 19:54, Stephen Farrell wrote: > >> On 09/04/2012 07:47 PM, Eliot Lear wrote: >>> Stephen, >>> >>> On 9/4/12 8:38 PM, Stephen Farrell wrote: >>>> So even I don't see any issue with the reverse proxy case >>>> where the same operator runs both the web server and >>>> front-end. >>>> >>>> But that's not all this draft supports. Can you comment on >>>> the engineering reasons for supporting this in outbound >>>> proxies? >>>> >>> >>> The issue here is this: >>> >>> >>> / ------(Q) >>> Host ----------------------> / ------(R) >>> >>> \ -------(S) >>> >>> You want to provide state stickiness for a pair , for instance, you >>> want something to identify , which is what this header provides. >>> doesn't need to be an IP address, by the way. The draft handles that part. >> >> Its not clear to me why it ever needs to be an IP address >> for (A,S) stickiness. >> >> E.g. Encr(k,A-addr||stuff) for some k known only to >> PROXY (or similar structures) would seem to me to be far >> better. (Various forms of <> might make sense.) >> > > I am pretty sure that obfuscated-IP and obfuscated-port are exactly what you ask for and they were in the document for ages. Yes, there is an option for that. But it doesn't say when to use it that I recall, nor why. And if that'd work, then as I said above I don't see why the UA's IP address is ever needed for the (A,S) stickiness that Eliot asked about. Which brings me back to not seeing a way in which this document can be fixed without radical surgery, which folks don't seem to be up for doing. (I don't know if Carsten's point about adjacent addresses is a real issue or not btw.) S > > From w@1wt.eu Wed Sep 5 09:18:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61B821F8670 for ; Wed, 5 Sep 2012 09:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7QmOzDCjpdY for ; Wed, 5 Sep 2012 09:18:23 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8C521F8681 for ; Wed, 5 Sep 2012 09:18:22 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q85GI1qG018615; Wed, 5 Sep 2012 18:18:01 +0200 Date: Wed, 5 Sep 2012 18:18:01 +0200 From: Willy Tarreau To: Alissa Cooper Message-ID: <20120905161801.GB18589@1wt.eu> References: <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> User-Agent: Mutt/1.4.2.3i Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 16:18:24 -0000 Hi Alissa, On Wed, Sep 05, 2012 at 12:12:51PM -0400, Alissa Cooper wrote: > Hi Alexey, > > On Sep 5, 2012, at 11:47 AM, Alexey Melnikov wrote: > > > I am pretty sure that obfuscated-IP and obfuscated-port are exactly what > > you ask for and they were in the document for ages. > > > > Except that there isn't any normative suggestion that the obfuscated > identifiers should be preferred or used by default, or that client addresses > should only be used if there is some address-related functionality required > by the endpoint. OK, so now it looks clear that what the draft is missing is indication about what the default behaviour should be in situations where it's not desired to let internal addresses leak outside. Possibly the draft authors can amend it now so that this issue comes to an end ? Regards, Willy From alexey.melnikov@isode.com Wed Sep 5 09:35:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E20321F8652 for ; Wed, 5 Sep 2012 09:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.903 X-Spam-Level: X-Spam-Status: No, score=-100.903 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oa1aSByK5jL for ; Wed, 5 Sep 2012 09:35:16 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id DA15D21F852A for ; Wed, 5 Sep 2012 09:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1346862913; d=isode.com; s=selector; i=@isode.com; bh=PEYAX1hsy9xTAzBRGxDMfv2B0niAVpdXNRlkm61Zo/U=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=APKouhrqpuJTLwdMUf8cjPFu0W63taf/f/HAIMW6N+b/g0SevgMnIO8KHKzfwTXCl35SgW APRiroRKNlm3wgEmJaZmLu1rUEQSyd7PdAb6aQQeT6qxWZT6VLqGRweTP748WazSoYErFQ CnGp4Z27wOJMzHLkI9PUTmj5F3vFhlU=; Received: from [188.28.215.154] (188.28.215.154.threembb.co.uk [188.28.215.154]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 5 Sep 2012 17:35:13 +0100 References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> In-Reply-To: <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Wed, 5 Sep 2012 17:36:20 +0100 To: Alissa Cooper , Stephen Farrell MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 16:35:16 -0000 Hi, On 5 Sep 2012, at 17:12, Alissa Cooper wrote: > Hi Alexey, >=20 > On Sep 5, 2012, at 11:47 AM, Alexey Melnikov wrote: >=20 >> I am pretty sure that obfuscated-IP and obfuscated-port are exactly what y= ou ask for and they were in the document for ages. >>=20 >=20 > Except that there isn't any normative suggestion that the obfuscated ident= ifiers should be preferred or used by default, or that client addresses shou= ld only be used if there is some address-related functionality required by t= he endpoint.=20 Ok, fair point. Text can be added to discuss this. From andreas@sbin.se Wed Sep 5 09:43:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AF621F867A for ; Wed, 5 Sep 2012 09:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6CeybwAhPxb for ; Wed, 5 Sep 2012 09:43:37 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8236F21F8669 for ; Wed, 5 Sep 2012 09:43:36 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q85GgmHS029911; Wed, 5 Sep 2012 16:42:48 GMT Date: Wed, 5 Sep 2012 18:42:46 +0200 From: Andreas Petersson To: Willy Tarreau Message-ID: <20120905184246.0f5e0f4a@hetzer> In-Reply-To: <20120905161801.GB18589@1wt.eu> References: <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> <20120905161801.GB18589@1wt.eu> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 16:43:38 -0000 On Wed, 5 Sep 2012 18:18:01 +0200 Willy Tarreau wrote: > Hi Alissa, > > On Wed, Sep 05, 2012 at 12:12:51PM -0400, Alissa Cooper wrote: > > Hi Alexey, > > > > On Sep 5, 2012, at 11:47 AM, Alexey Melnikov wrote: > > > > > I am pretty sure that obfuscated-IP and obfuscated-port are exactly what > > > you ask for and they were in the document for ages. > > > > > > > Except that there isn't any normative suggestion that the obfuscated > > identifiers should be preferred or used by default, or that client addresses > > should only be used if there is some address-related functionality required > > by the endpoint. > > OK, so now it looks clear that what the draft is missing is indication about > what the default behaviour should be in situations where it's not desired to > let internal addresses leak outside. > > Possibly the draft authors can amend it now so that this issue comes to an end ? It currently states: "A proxy that needs the ability to trace the source of requests, but does not want to leak the information further, can obfuscate the client address." It is also mentioned in "Information Leak". Should we change that "can" to an "is recommended to", or "should"? Or have anyone further suggestion of text that should be added? I'm currently writing an updated version for tomorrows meeting with the IESG. Not sure I will manage to fix this suggestion in this draft. My intention is to submit this new version tonight (CEST). /Andreas From w@1wt.eu Wed Sep 5 09:56:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E967B21F865D for ; Wed, 5 Sep 2012 09:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qbbJiI-37ns for ; Wed, 5 Sep 2012 09:56:06 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0C33721F865B for ; Wed, 5 Sep 2012 09:56:05 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q85Gtb9t018910; Wed, 5 Sep 2012 18:55:37 +0200 Date: Wed, 5 Sep 2012 18:55:37 +0200 From: Willy Tarreau To: Andreas Petersson Message-ID: <20120905165537.GC18589@1wt.eu> References: <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> <20120905161801.GB18589@1wt.eu> <20120905184246.0f5e0f4a@hetzer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120905184246.0f5e0f4a@hetzer> User-Agent: Mutt/1.4.2.3i Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 16:56:07 -0000 Hi Andreas, On Wed, Sep 05, 2012 at 06:42:46PM +0200, Andreas Petersson wrote: > On Wed, 5 Sep 2012 18:18:01 +0200 > Willy Tarreau wrote: > > > Hi Alissa, > > > > On Wed, Sep 05, 2012 at 12:12:51PM -0400, Alissa Cooper wrote: > > > Hi Alexey, > > > > > > On Sep 5, 2012, at 11:47 AM, Alexey Melnikov wrote: > > > > > > > I am pretty sure that obfuscated-IP and obfuscated-port are exactly what > > > > you ask for and they were in the document for ages. > > > > > > > > > > Except that there isn't any normative suggestion that the obfuscated > > > identifiers should be preferred or used by default, or that client addresses > > > should only be used if there is some address-related functionality required > > > by the endpoint. > > > > OK, so now it looks clear that what the draft is missing is indication about > > what the default behaviour should be in situations where it's not desired to > > let internal addresses leak outside. > > > > Possibly the draft authors can amend it now so that this issue comes to an end ? > > It currently states: > "A proxy that needs the ability to trace the source of requests, but > does not want to leak the information further, can obfuscate the > client address." > > It is also mentioned in "Information Leak". > > Should we change that "can" to an "is recommended to", or "should"? > Or have anyone further suggestion of text that should be added? Since Alissa talked about "normative suggestion", I think a SHOULD would be more appropriate to tell the recommended behaviour depending on the use case. Especially I think based on previous discussion with Stephen on this thread that it should be added that forward proxies SHOULD not pass such information in by default unless explicitly configured for this. > I'm currently writing an updated version for tomorrows meeting with > the IESG. Nice. > Not sure I will manage to fix this suggestion in this draft. Maybe not much is needed in fact. If everyone is happy with a SHOULD to disable the feature by default on forward proxies, maybe just a few lines are enough, I don't know. > My intention is to submit this new version tonight (CEST). > > /Andreas Regards, Willy From jasnell@gmail.com Wed Sep 5 10:03:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105CE21F866B for ; Wed, 5 Sep 2012 10:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiMjLCTa8BdJ for ; Wed, 5 Sep 2012 10:03:56 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id B053621F8643 for ; Wed, 5 Sep 2012 10:03:55 -0700 (PDT) Received: by wicr5 with SMTP id r5so4235558wic.13 for ; Wed, 05 Sep 2012 10:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=cOK+DDgPFi76P3B6ojlKm8UCZvrD+yEFFol01tLZzZA=; b=UBTiQoz+4nPIP8qmfCRxuKGrNgDPJb5ZPfuOX/J5IZ6NCmLFn04e2yDyZpQrx/gXJu 2zEbnUsImkb4q/lqpOThWhahgHGttGCKj7hQbXMMm35idqE6+gn3rTxgnr288ZyUtta6 r001e3d4+iSnR45+PrcuKmoLMfmW/zloNI8kbWurpD9Nu0XFU0tOR3V6JxQuedwo3B9j yYAvK6nKDmsOmo434b2TBRWO3ZBpzbbzOlRpBR0+669JpXXHSjzvB5EiWGyOtia+g7RA gFUChxeLOlgDXEvmCwwkBWCVOn9+qmxUrVaCCN7mUK5C7UY5c+vH+eoj4H+oYVZrOZHT 9UbA== Received: by 10.180.109.129 with SMTP id hs1mr39621136wib.0.1346864634708; Wed, 05 Sep 2012 10:03:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.58.136 with HTTP; Wed, 5 Sep 2012 10:03:34 -0700 (PDT) From: James M Snell Date: Wed, 5 Sep 2012 10:03:34 -0700 Message-ID: To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=e89a8f13ea881cc3c604c8f75ccf Subject: [apps-discuss] Json Patch Extended Operations - *Experimental* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 17:03:57 -0000 --e89a8f13ea881cc3c604c8f75ccf Content-Type: text/plain; charset=UTF-8 I've recently been experimenting with the JSON Patch format in a variety of scenarios in order to gain some additional implementation experience. I've found that in a number of cases it can be useful to apply more additional types of test operations. I am considering writing these up as a separate I-D as an extension to Json-Patch but I'm not yet fully convinced that it's something that should be done; so I wanted to solicit some feedback from the group at large. In my experiments, I have toyed around with the following additional test operations: "not" -- aggregate test... all of the contained operations must evaluate to false.. must not contain change operations.. tests only "and" -- aggregate test... all of the contained operations must evaluate to true.. must not contain change operations.. tests only "or" -- aggregate test... any of the contained operations must evaluate to true.. must not contain change operations.. tests only "typeOf" -- tests to ensure that the referenced object is the specified type (using javascript typeof) "contains" -- does the toString value of the referenced object contain the specified value "startsWith"-- does the toString value of the referenced object start with the specified value "endsWith" -- does the toString value of the referenced object end with the specified value "matches" -- does the toString value of the referenced object match the given regular expression "lessThan" -- if the value is numeric or a date, returns true if node value is more than specified value "moreThan" -- if the value is numeric or a date, returns true if node value is more than specified value For example, consider the following hypothetical, extended json-patch [ { "and": [ { "not": [ {"moreThan", "/a/bar", "value": 123}, {"matches", "/a/baz", "/sample/ig"} ] }, {"contains": "/a/foo", "value": "123"}, {"typeOf": "/a/b/version", "value": "number"} ] }, {"add": "/a/b/c", "value": "foo"}, {"replace": "/a/b/version", value: 1} ] In this example, the change operations ("add" and "increment") are only applied if and only if: * The /a/b/version property exists and is a numeric value, * The /a/foo property contains the characters "123" in it's string representation, * The /a/baz property does not match the regular expression /sample/ig, and * The /a/bar property is numeric and is less than or equal to 123 Yes, this adds quite a bit more complexity and yes, it's not yet clear if this is something of value. I'm not arguing that we SHOULD do this, but in a variety of experiments such tests have demonstrated usefulness. Also, I was asked recently whether JSON-Patch could be made to apply changes over a set of properties within a document that match a given criteria. For example, consider the following source JSON document: { "items": [ { "actor": {"displayName": "James" }, "verb": "post", "object": {"objectType": "note", "content": "test 1" }}, { "actor": {"displayName": "Joe" }, "verb": "post", "object": {"objectType": "note", "content": "test 2" }}, { "actor": {"displayName": "Sally" }, "verb": "share", "updated": "2012-12-12T12:12:12Z", "object": {"objectType": "book", "id": "urn:foo:1" }}, ] } Suppose I wish to add a "published" property to all items that currently do not have one... I could accomplish this using a new extended "each" operation... [ { "each": "/items", "apply": [ {"not": [{"test":"/updated"}]}, {"add": "/updated", "value": "2012-12-12T12:12:12Z"} ] } ] This evaluates as: For each member of /items, test to see if the member has an updated property. If not, add it with the value "2012-12-12T12:12:12Z". If /items is a primitive, the "each" operation would fail as an error condition. If /items is an array, then each iterates over each member of the array. If /items is an object, each iterates over each of that's objects member properties. Note, however, that this differs quite a bit from the existing semantics of json-patch. For one, a negative test within the "apply" would not signal an error condition that would halt the entire patch operation. The negative test would simply mean that the modification for that particular element would not be applied. All of the changes within. Again, I'm not yet convinced this is a good idea but experimentation has demonstrated that it's at least a workable approach. I'd very much like to hear from others on whether or not this is something we should or should not attempt to pursue. Thoughts? - James --e89a8f13ea881cc3c604c8f75ccf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've recently been experimenting w= ith the JSON Patch format in a variety of scenarios in order to gain some a= dditional implementation experience. I've found that in a number of cas= es it can be useful to apply more additional types of test operations. I am= considering writing these up as a separate I-D as an extension to Json-Pat= ch but I'm not yet fully convinced that it's something that should = be done; so I wanted to solicit some feedback from the group at large.

In my experiments, I have toyed around with the follow= ing additional test operations:

"not"= =C2=A0 =C2=A0 =C2=A0 -- aggregate test... all of the contained operations = must evaluate to false.. must not contain change operations.. tests only
"and" =C2=A0 =C2=A0 =C2=A0 -- aggregate test... all of th= e contained operations must evaluate to true.. must not contain change oper= ations.. tests only
"or" =C2=A0 =C2=A0 =C2=A0 =C2=A0-- aggregate test... any of = the contained operations must evaluate to true.. must not contain change op= erations.. tests only
"typeOf" =C2=A0 =C2=A0-- tests to= ensure that the referenced object is the specified type (using javascript = typeof)
"contains" =C2=A0-- does the toString value of the reference= d object contain the specified value
"startsWith"-- doe= s the toString value of the referenced object start with the specified valu= e
"endsWith" =C2=A0-- does the toString value of the reference= d object end with the specified value
"matches" =C2=A0 = -- does the toString value of the referenced object match the given regular= expression
"lessThan" =C2=A0-- if the value is numeric or a date, retur= ns true if node value is more than specified value
"moreThan= " =C2=A0-- if the value is numeric or a date, returns true if node val= ue is more than specified value

For example, consider the following hypothetical, exten= ded json-patch

=C2=A0 [
=C2=A0 =C2= =A0 { "and": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "not&= quot;: [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {"moreThan", "= ;/a/bar", "value": 123},
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 {"matches", "/a/baz", "/sample/i= g"}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ]
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {"contains": "/a/foo",= "value": "123"},
=C2=A0 =C2=A0 =C2=A0 =C2=A0= {"typeOf": "/a/b/version", "value": "nu= mber"}
=C2=A0 =C2=A0 =C2=A0 ]
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 {"add": "/a/b/c&quo= t;, "value": "foo"},
=C2=A0 =C2=A0 {"rep= lace": "/a/b/version", value: 1}=C2=A0
=C2=A0 ]

In this example, the change operations ("= add" and "increment") are only applied if and only if:

=C2=A0 * The /a/b/version property exists and is a nume= ric value,
=C2=A0 * The /a/foo property contains the characters &= quot;123" in it's string representation,
=C2=A0 * The /a= /baz property does not match the regular expression /sample/ig, and
=C2=A0 * The /a/bar property is numeric and is less than or equal to 1= 23

Yes, this adds quite a bit more complexity and = yes, it's not yet clear if this is something of value. I'm not argu= ing that we SHOULD do this, but in a variety of experiments such tests have= demonstrated usefulness.

Also, I was asked recently whether JSON-Patch could be = made to apply changes over a set of properties within a document that match= a given criteria. For example, consider the following source JSON document= :

=C2=A0 {
=C2=A0 =C2=A0 "items": [
=C2=A0 =C2=A0 =C2=A0 { "actor": {"displayName"= : "James" },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "verb&quo= t;: "post",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "object&qu= ot;: {"objectType": "note", "content": "= test 1" }},
=C2=A0 =C2=A0 =C2=A0 { "actor": {"displayName"= ;: "Joe" },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "verb"= ;: "post",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "object&quo= t;: {"objectType": "note", "content": "t= est 2" }},
=C2=A0 =C2=A0 =C2=A0 { "actor": {"displayNam= e": "Sally" },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "v= erb": "share",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "u= pdated": "2012-12-12T12:12:12Z",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "object": {"objectType"= ;: "book", "id": "urn:foo:1" }},
<= div>=C2=A0 =C2=A0 ]
=C2=A0 }

Suppose I w= ish to add a "published" property to all items that currently do = not have one... I could accomplish this using a new extended "each&quo= t; operation...
=C2=A0
=C2=A0 [
=C2=A0 =C2=A0 { "each": = "/items",=C2=A0
=C2=A0 =C2=A0 =C2=A0 "apply":= [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {"not": [{"test&quo= t;:"/updated"}]},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {"ad= d": "/updated", "value": "2012-12-12T12:12:12= Z"}
=C2=A0 =C2=A0 =C2=A0 ]
=C2=A0 =C2=A0 }
=C2=A0 ]

This evaluates as: For each member of /items, test t= o see if the member has an updated property. If not, add it with the value = "2012-12-12T12:12:12Z". If /items is a primitive, the "each&= quot; operation would fail as an error condition. If /items is an array, th= en each iterates over each member of the array. If /items is an object, eac= h iterates over each of that's objects member properties.=C2=A0

Note, however, that this differs quite a bit from the e= xisting semantics of json-patch. For one, a negative test within the "= apply" would not signal an error condition that would halt the entire = patch operation. The negative test would simply mean that the modification = for that particular element would not be applied. All of the changes within= .

Again, I'm not yet convinced this is a good idea bu= t experimentation has demonstrated that it's at least a workable approa= ch. I'd very much like to hear from others on whether or not this is so= mething we should or should not attempt to pursue.

Thoughts?

- James

--e89a8f13ea881cc3c604c8f75ccf-- From martin.thomson@gmail.com Wed Sep 5 10:26:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1E421F8687 for ; Wed, 5 Sep 2012 10:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ednCV+uopJYF for ; Wed, 5 Sep 2012 10:26:01 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAAE21F867F for ; Wed, 5 Sep 2012 10:26:01 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so515185wgb.13 for ; Wed, 05 Sep 2012 10:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q9L2LmZAxFqVcc5zqkKrVwBRVYydrz6woQolwjA4kq0=; b=sJrtKBbChqDJNfeTgQ0WL9SXkSTA5dFsR0xEMyWocLORbJH7I8VqvlHQxgxpcZ6N79 EnrgaBQIh3OQ0kU3MYAMdv9w156NkN0iE+hfPYESiGiva7iMHb3G8Y0wCCMPq+Rou1AY Wl4toZXSAqmHoVppvAejeICnFJqTztGEk61B3Kok/21HzRvMhlHZqgi+puAvic/9EBRs Ek1jj6sAMKJtOdvp+7de+ezYYZr+D8iA0YHSOSZnxH2NRHYVr67SgFBCCLVC9F8u5RUG P0WKHnePG+Ukn7iYqP5zAvjTZDu8RSIvTNsDRgB3x15oGCQKBpalLoua9Ffe1hIVfPoc Gnew== MIME-Version: 1.0 Received: by 10.180.86.133 with SMTP id p5mr39686640wiz.17.1346865959006; Wed, 05 Sep 2012 10:25:59 -0700 (PDT) Received: by 10.180.24.70 with HTTP; Wed, 5 Sep 2012 10:25:58 -0700 (PDT) In-Reply-To: <20120905184246.0f5e0f4a@hetzer> References: <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> <20120905161801.GB18589@1wt.eu> <20120905184246.0f5e0f4a@hetzer> Date: Wed, 5 Sep 2012 10:25:58 -0700 Message-ID: From: Martin Thomson To: Andreas Petersson Content-Type: text/plain; charset=UTF-8 Cc: Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 17:26:02 -0000 On 5 September 2012 09:42, Andreas Petersson wrote: > It currently states: > "A proxy that needs the ability to trace the source of requests, but > does not want to leak the information further, can obfuscate the > client address." What process do you recommend for this obfuscation? rot13? It really comes down to what the goal of the obfuscation is. Is it unlinkability? I'd guess that you want the identifier be stable over time, but structured so that the obfuscation is not reversible. That's a tricky thing to get right. From phil.hunt@oracle.com Wed Sep 5 11:13:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B25721F8680 for ; Wed, 5 Sep 2012 11:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNk-RYbk16Vo for ; Wed, 5 Sep 2012 11:13:41 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 173CB21F861E for ; Wed, 5 Sep 2012 11:13:40 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q85IDcfq026691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Sep 2012 18:13:39 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q85IDatD002040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Sep 2012 18:13:37 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q85IDaPN016041; Wed, 5 Sep 2012 13:13:36 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 Sep 2012 11:13:35 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_A1E8ED35-B57C-4663-B245-E41373FDA147" From: Phil Hunt In-Reply-To: Date: Wed, 5 Sep 2012 11:12:48 -0700 Message-Id: <3038652A-9A8F-4527-8264-AD274737451D@oracle.com> References: To: James M Snell X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 18:13:42 -0000 --Apple-Mail=_A1E8ED35-B57C-4663-B245-E41373FDA147 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I was looking at this spec in the context of SCIM PATCH operations. As SCIM is intended for provisioning across domains, it becomes possible = that the full state of a resource in an external domain is not known. = For example, in a replace operation, the existing value is missing, = should the replace convert to an add and so forth. These issues can be = further complicated if the service provider is unable or unwilling to = give detailed error responses for security reasons. Having a "test" (or set of conditions) enables a portion of the state of = a remote entity to be confirmed before the patch is executed and = hopefully keeps error signalling simpler. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-09-05, at 8:47 AM, James M Snell wrote: > Three points...=20 >=20 > 1) Re: test ... I would like to see more detail on why "test" would be = used in a patch document. Perhaps just by expanding on the example just = a bit. >=20 > 2) Section 5's discussion of error handling should be expanded a bit. = Yes the changes are atomic but a clear example of exactly what that = means would be helpful. >=20 > Example: This json-patch would result in no changes being made to the = document at all. >=20 > [ > {"replace": "/a/b/c", "value": 42}, > {"test": "/a/b/c", "value": "C"} > ] >=20 > 3) Unless we specifically want to allow for such things, it should be = made clear that "test" is not intended to be used as a replacement for = other types of http conditionals. For instance, I could imagine someone = doing something like... >=20 > [ > {"test": "/foo/last-updated", "value": "2012-12-12T12:12:12Z"}, > ("add": "/a/b/c", "value": 42} > ] >=20 > Or... >=20 > [ > {"test": "/@etag", "value": "ABC123"}, > ("add": "/a/b/c", "value": 42} > ] >=20 > - James >=20 >=20 > On Wed, Sep 5, 2012 at 12:18 AM, Mark Nottingham = wrote: > I've just submitted revised json-pointer and json-patch documents, = based upon feedback. >=20 > As far as I can tell, the only open issue on JSON-Patch is about = 'test': > http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7 >=20 > In Vancouver, we said that we'd wait for implementation experience to = see if 'test' is worthwhile. >=20 > In the meantime, I've found two implementations of json-patch "in the = wild": > https://github.com/stefankoegl/python-json-patch > https://github.com/bruth/jsonpatch-js >=20 > Both are somewhat old, and both support 'test'. >=20 > As such, I'd suggest we let 'test' remain in the spec (I think there = are good arguments for it anyway), and ship it. >=20 > Make sense? >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_A1E8ED35-B57C-4663-B245-E41373FDA147 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I was = looking at this spec in the context of SCIM PATCH = operations.

As SCIM is intended for provisioning = across domains, it becomes possible that the full state of a resource in = an external domain is not known. For example, in a replace operation, = the existing value is missing, should the replace convert to an add and = so forth.  These issues can be further complicated if the service = provider is unable or unwilling to give detailed error responses for = security reasons.

Having a "test" (or set of = conditions) enables a portion of the state of a remote entity to be = confirmed before the patch is executed and hopefully keeps error = signalling simpler.


On 2012-09-05, at 8:47 AM, James M Snell wrote:

Three points... 

1) Re: test ... I would like to see more detail on why = "test" would be used in a patch document. Perhaps just by expanding on = the example just a bit.

2) Section 5's discussion of error = handling should be expanded a bit. Yes the changes are atomic but a = clear example of exactly what that means would be helpful.

Example: This json-patch would result in = no changes being made to the document at all.

[
 {"replace": "/a/b/c", = "value": 42},
 {"test": "/a/b/c", = "value": "C"}
]

3) Unless we = specifically want to allow for such things, it should be made clear that = "test" is not intended to be used as a replacement for other types of = http conditionals. For instance, I could imagine someone doing something = like...

[
 {"test": "/foo/last-updated", "value": = "2012-12-12T12:12:12Z"},
 ("add": "/a/b/c", = "value": 42}
]

Or...

[
 {"test": "/@etag", "value": = "ABC123"},
 ("add": "/a/b/c", = "value": 42}
]

- = James


On Wed, Sep 5, 2012 = at 12:18 AM, Mark Nottingham <mnot@mnot.net> wrote:
I've just submitted = revised json-pointer and json-patch documents, based upon feedback.

As far as I can tell, the only open issue on JSON-Patch is about = 'test':
  http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7<= br>
In Vancouver, we said that we'd wait for implementation experience to = see if 'test' is worthwhile.

In the meantime, I've found two implementations of json-patch "in the = wild":
  https://github.com/stefankoegl/python-json-patch
=   https://github.com/bruth/jsonpatch-js

Both are somewhat old, and both support 'test'.

As such, I'd suggest we let 'test' remain in the spec (I think there are = good arguments for it anyway), and ship it.

Make sense?

--
Mark Nottingham   http://www.mnot.net/



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

_______________________________________________
apps-discuss mailing = list
apps-discuss@ietf.org
https:/= /www.ietf.org/mailman/listinfo/apps-discuss

= --Apple-Mail=_A1E8ED35-B57C-4663-B245-E41373FDA147-- From jasnell@gmail.com Wed Sep 5 11:43:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A71C21F85B4 for ; Wed, 5 Sep 2012 11:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eic18qsTDCDX for ; Wed, 5 Sep 2012 11:43:12 -0700 (PDT) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9366B21F8686 for ; Wed, 5 Sep 2012 11:43:11 -0700 (PDT) Received: by weyr3 with SMTP id r3so822625wey.22 for ; Wed, 05 Sep 2012 11:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=992epianBsVoW+9IXLYSi2ysZ3SfNYKEbHsFkHKR8sM=; b=Lm+m4H/0n5SB9NbIE8cpCEVFB+OcuzJ1jeC+0lgMZY4zJkPIFyHEeorD3W+i/CB3ut 5kppTLCfXNpI3JVNdhhCBBts1dB7t/B8o7Hrspw/IoMmhU984ZF1KH0QV91GXhOpxkOz bmYQHUfwGByo2kWzYbPK+qlwBwDCgIoupeenOVllNZGRm0//XUdTJjsAiLV1DHGHTm9O J4nid73uY6hm++TV3pwgGpynTn2Gxdmw4ObZqtp0Qyhx8XmFmRPWQja7dSw7yj+GYKe7 bx810gw85xo5x/88dWqaOsWnmaprtBUHyPzvUOA3dZqPldG1wTaRIxzzh27ttKn+PoQB ZnwQ== Received: by 10.180.98.200 with SMTP id ek8mr40123701wib.0.1346870590320; Wed, 05 Sep 2012 11:43:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.58.136 with HTTP; Wed, 5 Sep 2012 11:42:49 -0700 (PDT) In-Reply-To: References: From: James M Snell Date: Wed, 5 Sep 2012 11:42:49 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=f46d0442886018306104c8f8bf1c Cc: Apps Discuss Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 18:43:13 -0000 --f46d0442886018306104c8f8bf1c Content-Type: text/plain; charset=UTF-8 One additional point, I note that with the current "test" operation, the "value" property is assumed to be required. What if all I want to do is test for the presence of a property? {"test":"/a/b/c","value":null} can be used to test that the property is null, but what if I don't care about the specific value? can I do, {"test":"/a/b/c"} ? - James On Wed, Sep 5, 2012 at 8:47 AM, James M Snell wrote: > Three points... > > 1) Re: test ... I would like to see more detail on why "test" would be > used in a patch document. Perhaps just by expanding on the example just a > bit. > > 2) Section 5's discussion of error handling should be expanded a bit. Yes > the changes are atomic but a clear example of exactly what that means would > be helpful. > > Example: This json-patch would result in no changes being made to the > document at all. > > [ > {"replace": "/a/b/c", "value": 42}, > {"test": "/a/b/c", "value": "C"} > ] > > 3) Unless we specifically want to allow for such things, it should be made > clear that "test" is not intended to be used as a replacement for other > types of http conditionals. For instance, I could imagine someone doing > something like... > > [ > {"test": "/foo/last-updated", "value": "2012-12-12T12:12:12Z"}, > ("add": "/a/b/c", "value": 42} > ] > > Or... > > [ > {"test": "/@etag", "value": "ABC123"}, > ("add": "/a/b/c", "value": 42} > ] > > - James > > > On Wed, Sep 5, 2012 at 12:18 AM, Mark Nottingham wrote: > >> I've just submitted revised json-pointer and json-patch documents, based >> upon feedback. >> >> As far as I can tell, the only open issue on JSON-Patch is about 'test': >> http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7 >> >> In Vancouver, we said that we'd wait for implementation experience to see >> if 'test' is worthwhile. >> >> In the meantime, I've found two implementations of json-patch "in the >> wild": >> https://github.com/stefankoegl/python-json-patch >> https://github.com/bruth/jsonpatch-js >> >> Both are somewhat old, and both support 'test'. >> >> As such, I'd suggest we let 'test' remain in the spec (I think there are >> good arguments for it anyway), and ship it. >> >> Make sense? >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > --f46d0442886018306104c8f8bf1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One additional point, I note that with= the current "test" operation, the "value" property is = assumed to be required. What if all I want to do is test for the presence o= f a property? {"test":"/a/b/c","value":null} = can be used to test that the property is null, but what if I don't care= about the specific value? can I do, {"test":"/a/b/c"} = ?

- James

On We= d, Sep 5, 2012 at 8:47 AM, James M Snell <jasnell@gmail.com>= wrote:
Three p= oints...=C2=A0

<= /div>
1) Re: test ... I would like to see mo= re detail on why "test" would be used in a patch document. Perhap= s just by expanding on the example just a bit.

2) Section 5's discussion of error handling = should be expanded a bit. Yes the changes are atomic but a clear example of= exactly what that means would be helpful.

Example: This json-patch would result in no cha= nges being made to the document at all.

[
= =C2=A0{= "replace": "/a/b/c", "value": 42},
=C2=A0{"test": "/= a/b/c", "value": "C"}
]

3) Unless we specif= ically want to allow for such things, it should be made clear that "te= st" is not intended to be used as a replacement for other types of htt= p conditionals. For instance, I could imagine someone doing something like.= ..

[
=C2=A0{"test": "/foo/last-updated", "val= ue": "2012-12-12T12:12:12Z"},
=C2=A0("add": "/a= /b/c", "value": 42}
]
Or...

[
=C2=A0{"test": "/@etag", "value": "ABC1= 23"},
=C2=A0("add": "/a= /b/c", "value": 42}
]

- James
<= div>


On Wed, Sep 5, 201= 2 at 12:18 AM, Mark Nottingham <mnot@mnot.net> wrote:
I've just submitted revised json-pointer= and json-patch documents, based upon feedback.

As far as I can tell, the only open issue on JSON-Patch is about 'test&= #39;:
=C2=A0 http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7

In Vancouver, we said that we'd wait for implementation experience to s= ee if 'test' is worthwhile.

In the meantime, I've found two implementations of json-patch "in = the wild":
=C2=A0 https://github.com/stefankoegl/python-json-patch
=C2=A0 = https://github.com/bruth/jsonpatch-js

Both are somewhat old, and both support 'test'.

As such, I'd suggest we let 'test' remain in the spec (I think = there are good arguments for it anyway), and ship it.

Make sense?

--
Mark Nottingham =C2=A0 h= ttp://www.mnot.net/



_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--f46d0442886018306104c8f8bf1c-- From internet-drafts@ietf.org Wed Sep 5 13:36:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6463B21F86E4; Wed, 5 Sep 2012 13:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.32 X-Spam-Level: X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-DQDTXMZf+e; Wed, 5 Sep 2012 13:36:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBBD21F86C9; Wed, 5 Sep 2012 13:36:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120905203614.26470.9067.idtracker@ietfa.amsl.com> Date: Wed, 05 Sep 2012 13:36:14 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-08.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 20:36:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Forwarded HTTP Extension Author(s) : Andreas Petersson Martin Nilsson Filename : draft-ietf-appsawg-http-forwarded-08.txt Pages : 18 Date : 2012-09-05 Abstract: This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. Given a trusted path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-http-forwarded-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fgaliegue@gmail.com Wed Sep 5 13:43:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD1721F86CF for ; Wed, 5 Sep 2012 13:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imHorHV1jIOu for ; Wed, 5 Sep 2012 13:43:29 -0700 (PDT) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3A121F86C8 for ; Wed, 5 Sep 2012 13:43:17 -0700 (PDT) Received: by vbbfo1 with SMTP id fo1so688775vbb.22 for ; Wed, 05 Sep 2012 13:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zAk2kXmivQlQSiG9ckPB37Ay8kOdt+8i8ROzcIdSBWU=; b=nuBB5/qqL3pSAzih9g/GZSlXLqWiIYonYaAn7P5s9eUzo/CLB1L2dbMW61sqK09hN3 JAqrUatywCUPXOoYnrnfGUMSQkzQiB3H4rKa9WruyT3zdCizm0zO6LSsXWTxyg8z0OPn hkikFKnIpEjFWyJQykB6sbtCnyVisQo4wtnh+GiiSpkxSKu8lOSvX6a78WEn3F/5X0rp qR3OICm5lQ5NKQTzOfRL3lN2mDfDO3clZ6cb3FznyjHTiYZpFO4QFiJUVxS28VvMLilP n7Zvidfs8Q1RKU5WKtouzPNPCiMAhyovKH3g9PRNhVoUjCp9SbBRuID2fUsaHYTBgdlT jqhw== MIME-Version: 1.0 Received: by 10.52.17.75 with SMTP id m11mr16842665vdd.106.1346877796072; Wed, 05 Sep 2012 13:43:16 -0700 (PDT) Received: by 10.52.23.103 with HTTP; Wed, 5 Sep 2012 13:43:15 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Sep 2012 22:43:15 +0200 Message-ID: From: Francis Galiegue To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 20:43:30 -0000 On Wed, Sep 5, 2012 at 5:37 PM, Phillip Hallam-Baker wro= te: > I think what is needed here is a mapping between the data structures > used in today's mainstream programming languages and JSON. > Disagree: JSON is a data format defined by an offical RFC, and this RFC is language neutral. Tying JSON, and JSON Schema, to the structures available in language X, Y or Z would, to my eyes, defeat the purpose not only of JSON Schema, but of JSON itself. --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From andreas@sbin.se Wed Sep 5 13:48:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2BB21F863C for ; Wed, 5 Sep 2012 13:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuOxErOAqIMf for ; Wed, 5 Sep 2012 13:48:47 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0D79E21F851A for ; Wed, 5 Sep 2012 13:48:46 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q85KmG0G031993; Wed, 5 Sep 2012 20:48:16 GMT Date: Wed, 5 Sep 2012 22:48:13 +0200 From: Andreas Petersson To: Martin Thomson Message-ID: <20120905224813.6252fb8d@hetzer> In-Reply-To: References: <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> <20120905161801.GB18589@1wt.eu> <20120905184246.0f5e0f4a@hetzer> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 20:48:47 -0000 On Wed, 5 Sep 2012 10:25:58 -0700 Martin Thomson wrote: > On 5 September 2012 09:42, Andreas Petersson wrote: > > It currently states: > > "A proxy that needs the ability to trace the source of requests, but > > does not want to leak the information further, can obfuscate the > > client address." > > What process do you recommend for this obfuscation? rot13? > > It really comes down to what the goal of the obfuscation is. Is it > unlinkability? I'd guess that you want the identifier be stable over > time, but structured so that the obfuscation is not reversible. > That's a tricky thing to get right. > It is tricky indeed. (the scope in this mail is forwarding proxies) I'm no crypto expert, so I don't want to recommend any thing at all. :-) If you REALLY want to hide your users, don't use this and deal with the other problems that comes up. :-) If the proxy have some sort of concept of sessions, maybe random() is enough, and store the mapping between the client IP address and the token somewhere. That way users will both get a new token relatively often and should not be traceable. If that doesn't work, a static mapping between client IP address<->token (token can still be just random) may be used. The draft however recommends that the token should not be sticky for too long time. You could also use some complete different scheme that happens to fit your environment. I believe that when this is used, the type of the token is in some way negotiated with the receiver of the request. Maybe this draft should hint proxy servers to only forward the client IP address to destinations that the proxy server actively choose? /Andreas From tbray@textuality.com Wed Sep 5 13:53:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1083E21F8685 for ; Wed, 5 Sep 2012 13:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JkNNgzZwISz for ; Wed, 5 Sep 2012 13:53:35 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by ietfa.amsl.com (Postfix) with ESMTP id 5868921F8681 for ; Wed, 5 Sep 2012 13:53:35 -0700 (PDT) Received: by wibhm2 with SMTP id hm2so4512821wib.4 for ; Wed, 05 Sep 2012 13:53:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=5rlrPcWEU0o7ZTMNY5eMnQE2nVx0v+IOQUbe3sxuxOo=; b=Yh7WynhxONoOmOXFJILca5CJGbNfdnUCx58YnCbehPjILA1q9rKd/NlbwRMC4/MTpU xJ347Ff8TcB/qDjXd2a2ECM/O4OypukXkSWJ3fBiYhz7J0JF5UmM3Ip+kHxAFHbcPeJ6 cviDho9yQR6Tp3PSFRLhgUtElU4moDLJDhDyJM31PUWuvDd4XODPYbKyosdS6PZDQ3d3 RWBDz8Xb4qzpkHYP/SXXSOU3tKjiMby/PuZsC+6JvV4JnNukre/+iyxcVgsmvMknIuR6 GWEyYjiL0vz6fm+wHXdm9vyY5m89qPNq9Ut1Txe4iVgD2/zzEMcKwQkTX0Y/416ms5UV rwMg== MIME-Version: 1.0 Received: by 10.216.116.70 with SMTP id f48mr8242378weh.162.1346878414279; Wed, 05 Sep 2012 13:53:34 -0700 (PDT) Received: by 10.195.13.200 with HTTP; Wed, 5 Sep 2012 13:53:34 -0700 (PDT) X-Originating-IP: [24.84.208.217] In-Reply-To: References: Date: Wed, 5 Sep 2012 13:53:34 -0700 Message-ID: From: Tim Bray To: Phillip Hallam-Baker Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlGuevLNz8NhR7n3rRRO6tPBNXNjE2FqR25J+IDCdI7T0w4dwKp3tmkcjo/j8wayB44+/55 Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 20:53:36 -0000 inline On Wed, Sep 5, 2012 at 8:37 AM, Phillip Hallam-Baker wro= te: > I think what is needed here is a mapping between the data structures > used in today's mainstream programming languages and JSON. That varies between unnecessary and impossible. In modern dynamically-typed languages (ruby/python/etc) there=92s no necessity; JSON encodes hashes, lists, and a few primitive types, all of which are built-ins. And then Java-like languages, there=92s just really no good way to model the following, which might be a reasonable protocol element [ { "foo": 1, "bar" : false }, 23, "humpty-dumpty" ] at any level richer than List; so why bother? > The ugly are the weakly/untyped 'scripting'languages like Perl. These > don't 'need' a schema because they don't 'need types. This is humor, I imagine? There are no other languages like Perl, thank goodness. And as noted above, the types in modern dynamically-typed language map with zero friction onto those expressed by JSON. -Tim From cabo@tzi.org Wed Sep 5 13:57:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8788921F86DF for ; Wed, 5 Sep 2012 13:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nAUOBTwD8bP for ; Wed, 5 Sep 2012 13:57:04 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by ietfa.amsl.com (Postfix) with ESMTP id A42FE21F86E8 for ; Wed, 5 Sep 2012 13:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q85KtpVv017902; Wed, 5 Sep 2012 22:55:51 +0200 (CEST) Received: from [192.168.217.105] (p54893AEF.dip.t-dialin.net [84.137.58.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7F5E91B7; Wed, 5 Sep 2012 22:55:50 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 5 Sep 2012 22:55:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> <20120905161801.GB18589@1wt.eu> <20120905184246.0f5e0f4a@hetzer> To: Martin Thomson X-Mailer: Apple Mail (2.1486) Cc: Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 20:57:04 -0000 On Sep 5, 2012, at 19:25, Martin Thomson = wrote: > I'd guess that you want the identifier be stable over > time, but structured so that the obfuscation is not reversible. > That's a tricky thing to get right. If that is your only requirement, there are rather obvious solutions. Apply a keyed MAC (e.g., HMAC) to the address, or use Stephen's scheme. To achieve stability, you just have to keep the key constant (and = secret). If you also want to maintain the distance between different IP addresses = a user might have available (e.g., keep addresses within a subnet = related), there is a body of work on IP address anonymization that = shares this goal. A convenient entry point to that (from the point of view of anonymizing = packet traces) is: http://www.caida.org/projects/predict/anonymization/ "Summary of Anonymization Best Practice Techniques" This also points to places where you can download working, debugged = code. Gr=FC=DFe, Carsten From fgaliegue@gmail.com Wed Sep 5 14:11:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FB521F86A0 for ; Wed, 5 Sep 2012 14:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98q49R6IVRq8 for ; Wed, 5 Sep 2012 14:11:03 -0700 (PDT) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8B14621F857A for ; Wed, 5 Sep 2012 14:11:03 -0700 (PDT) Received: by vbbfo1 with SMTP id fo1so722949vbb.22 for ; Wed, 05 Sep 2012 14:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xvmMRKMlUQLaQNKzrr4mjkNJIhIJlNfpxzQ14cyLOgQ=; b=KhQYvfR1nwtPoqBdtrXeYynAaZMN4ErdlFuTcK6xBG0tna9NxljyOLbiY9rs+9A+sy QVF+D1hQSzzhzjnWU6YDvf8nFK56MDogON6Z57g6+ZjuppAXvQQH7u5Ur/5EhT62gu3c m5N9DS5aq6ahimAFWJ7WOtbyrbyH3tK+ljudsB/jUeB1xHoUmeFmg7OLOzaCf4CyoknF rMgjFY+rK8BUJl/f4v07EorsvK2ncCs4ljfsizscIN5gksXYyEok1ITNN9QXex3iOzms X/ESllIZuYUa1KGBlsIJMzJRiV4U4El/F74bqLncJweYErChPX32qyvt3hk7OkYItx5f dKXA== MIME-Version: 1.0 Received: by 10.52.66.162 with SMTP id g2mr16960426vdt.32.1346879462837; Wed, 05 Sep 2012 14:11:02 -0700 (PDT) Received: by 10.52.23.103 with HTTP; Wed, 5 Sep 2012 14:11:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Sep 2012 23:11:02 +0200 Message-ID: From: Francis Galiegue To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 21:11:05 -0000 On Wed, Sep 5, 2012 at 10:53 PM, Tim Bray wrote: > inline > > On Wed, Sep 5, 2012 at 8:37 AM, Phillip Hallam-Baker w= rote: >> I think what is needed here is a mapping between the data structures >> used in today's mainstream programming languages and JSON. > > That varies between unnecessary and impossible. This may sound lame, but... +1. Especially since you mentioned Java. I have a complete JSON Schema validating implementation written in Java, and _it is more complete with regards to validation purposes than all other implementations out there, including the ones written in JavaScript_. I also know for sure that it is actually being used by other people than myself for validating JSON data as per the currently available, even though dead, JSON Schema draft (http://tools.ietf.org/html/draft-zyp-json-schema-03) And there is WJElement, which is written in... Yes... C! Anyway. JSON Schema will get input, what I was asking in the first place is what was required for a draft, or series thereof, to be submitted. I personally am but one member of the Github organization, and while I am no stranger to writing documentation, I have been aiming this documentation at users, not the IETF... And IETF, as far as I can see, means a process has to be followed. And I'd like insights into the process, along with comments on the existing material! For the recall: https://github.com/json-schema/json-schema. This is a plea from a first-time IETF mailing list poster at this point: I do believe I have the technical grounds right, I am just completely ignorant about the process at hand. And I do believe JSON Schema is the way forward with regards to JSON data processing, and not only validation (which is why I came to JSON Schema in the first place). Thank you for reading, --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From andreas@sbin.se Wed Sep 5 14:19:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1E421F86F1 for ; Wed, 5 Sep 2012 14:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxAYO1LBR9Ey for ; Wed, 5 Sep 2012 14:19:46 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE2A21F85AD for ; Wed, 5 Sep 2012 14:19:46 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q85LJj2g006810 for ; Wed, 5 Sep 2012 21:19:45 GMT Date: Wed, 5 Sep 2012 23:19:43 +0200 From: Andreas Petersson To: apps-discuss@ietf.org Message-ID: <20120905231943.223b04bc@hetzer> In-Reply-To: <504651FE.9070904@cs.tcd.ie> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <700E38F9-942B-449A-9909-1067CEB1FB4C@tzi.org> <504651FE.9070904@cs.tcd.ie> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 21:19:47 -0000 On Tue, 04 Sep 2012 20:09:50 +0100 Stephen Farrell wrote: > (Is that only by wikipedia or > more broadly?) =46rom the top of my head, a (incomplete) list of software that supports XFF: squid, apache httpd, apache traffic server, varnish, nginx, haproxy, cisco cache engine, lighttpd. Google, uses it, lots of phone operators, for sure a lot of sites use it in reverse proxies. I am also pretty sure that lots of sites logs XFF and use it in statistics. Best regards, Andreas From stephen.farrell@cs.tcd.ie Wed Sep 5 14:24:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E158921F8681 for ; Wed, 5 Sep 2012 14:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.882 X-Spam-Level: X-Spam-Status: No, score=-102.882 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8rmNbnMak8O for ; Wed, 5 Sep 2012 14:24:21 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 161E721F8650 for ; Wed, 5 Sep 2012 14:24:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D7ABE17147E; Wed, 5 Sep 2012 22:24:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346880257; bh=AKxOn7Mgp6FzOs +QALj6vMzYS+nlI9PSch68eAJVAew=; b=24s4gaC1t9fTQZC18sCF6FBF5Pm6RJ xQKPUreFeqiFK36Kk7qoMEHb8LNjYrPowB4c81eiu+XmhOOAAL08BQg1wC7v/Nqe oNpG7tQ9QaPMDviwWd3qt6aqJwa4IavJRptf9n2IHe62WbmWh3wDNr79R30XJQb9 RxKK4sRPRMAcLr6egxSRNPBTQOFMyKkpuzQ4hHjE58NsZJoZ6XlwcJCjzao90Epx 5/OxhGQWPjWUkMIpEy4q0Iwc0IGjKsbW+unqdKI7b6YDQvm8E7giFuYJvmFSTx5h NE0KbrcE9le7Dk7mP48VWQR4ugg4YGqu997nprmckFV+cF6VbETpPwug== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id KRHwiiKLYNBv; Wed, 5 Sep 2012 22:24:17 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.17.12]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 605DE171473; Wed, 5 Sep 2012 22:24:17 +0100 (IST) Message-ID: <5047C300.6040305@cs.tcd.ie> Date: Wed, 05 Sep 2012 22:24:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Andreas Petersson References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <700E38F9-942B-449A-9909-1067CEB1FB4C@tzi.org> <504651FE.9070904@cs.tcd.ie> <20120905231943.223b04bc@hetzer> In-Reply-To: <20120905231943.223b04bc@hetzer> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 21:24:22 -0000 On 09/05/2012 10:19 PM, Andreas Petersson wrote: > On Tue, 04 Sep 2012 20:09:50 +0100 > Stephen Farrell wrote: >> (Is that only by wikipedia or >> more broadly?) > >>From the top of my head, a (incomplete) list of software that supports > XFF: > squid, apache httpd, apache traffic server, varnish, > nginx, haproxy, cisco cache engine, lighttpd. > > Google, uses it, lots of phone operators, for sure a lot of sites use > it in reverse proxies. > I am also pretty sure that lots of sites logs XFF and use it in > statistics. Sorry, I mean the wikipedia use-case, which I understand as using XFF to separate the reputation of different end-users behind the same proxy. I was wondering if its only wikipedia that does that or if its more generally done. I wasn't asking who implements XFF (which I think you answered for me before anyway:-). S. > > Best regards, > Andreas > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From wwwrun@rfc-editor.org Wed Sep 5 14:24:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843D321F86F6; Wed, 5 Sep 2012 14:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.985 X-Spam-Level: X-Spam-Status: No, score=-101.985 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsgZ5utyTC+v; Wed, 5 Sep 2012 14:24:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2665C21F86F5; Wed, 5 Sep 2012 14:24:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B3E78B1E007; Wed, 5 Sep 2012 14:22:00 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120905212200.B3E78B1E007@rfc-editor.org> Date: Wed, 5 Sep 2012 14:22:00 -0700 (PDT) Cc: apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 6729 on Indicating Email Handling States in Trace Fields X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 21:24:46 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6729 Title: Indicating Email Handling States in Trace Fields Author: D. Crocker, M. Kucherawy Status: Standards Track Stream: IETF Date: September 2012 Mailbox: dcrocker@bbiw.net, superuser@gmail.com Pages: 12 Characters: 24665 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-appsawg-received-state-04.txt URL: http://www.rfc-editor.org/rfc/rfc6729.txt This document registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queuing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. [STANDARDS-TRACK] This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From sm@resistor.net Wed Sep 5 15:31:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9777E21F86A8 for ; Wed, 5 Sep 2012 15:31:14 -0700 (PDT) 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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UE-SyQi2Y9LL for ; Wed, 5 Sep 2012 15:31:14 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0791721F867F for ; Wed, 5 Sep 2012 15:31:13 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q85MV8bJ023301; Wed, 5 Sep 2012 15:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346884273; bh=KSbJ0erLrnNcwmfv4WG28jMRs4pvV4GDMNnHYWR5GmM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jyJ/sjTwmaj2QUtx4r3H16GAdUA0C/DogtAokYth4CGH26TuEKSQekgxXrY9IXbqe 55POllWdPGRVm4LsvNxXOcQpwHnjLoaWBJwkjDexLGBPyMyJl7Q8ebqGaigX3iWkQ0 Fp7/ey93qxPr/2OMqrYtQ2SOunMydD1Q5nDdU6dc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1346884273; i=@resistor.net; bh=KSbJ0erLrnNcwmfv4WG28jMRs4pvV4GDMNnHYWR5GmM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=X7g8J1YdQtFkTVyVCi55zjOjPakgYcndL9QodYNYoYVLY9yzPbo3RApemRUoy/6US RdSRMLtEdHrNM1VGLbi/HHFWz8b3/IxObve+vs6ctm30al+awvDTxIFojmziFgY2Oq 49DR+AScNYbMKFkVFaqxIj7BqV2M+E519EsbfmE0= Message-Id: <6.2.5.6.2.20120905152123.0b351080@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 05 Sep 2012 15:30:08 -0700 To: Francis Galiegue From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 22:31:14 -0000 Hi Francis, At 14:11 05-09-2012, Francis Galiegue wrote: >plea from a first-time IETF mailing list poster at this point: I do >believe I have the technical grounds right, I am just completely >ignorant about the process at hand. And I do believe JSON Schema is >the way forward with regards to JSON data processing, and not only >validation (which is why I came to JSON Schema in the first place). If you think that something is a good idea, write an I-D. The submission guidelines are at http://www.ietf.org/ietf-ftp/1id-guidelines.html The submission form is at https://datatracker.ietf.org/submit/ You could discuss the I-D on the apps-discuss mailing list. The process is simple; the author puts in the effort to get the I-D through the publication process. You can ask if you need help with the process details. Regards, -sm From ned.freed@mrochek.com Wed Sep 5 16:00:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7FB21F86D5 for ; Wed, 5 Sep 2012 16:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iejo7eGPNw+7 for ; Wed, 5 Sep 2012 16:00:12 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 93CE021F86C3 for ; Wed, 5 Sep 2012 16:00:12 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJWHSQIBA8008GUN@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 5 Sep 2012 15:55:10 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Wed, 5 Sep 2012 15:55:08 -0700 (PDT) Message-id: <01OJWHSPET3Q0006TF@mauve.mrochek.com> Date: Wed, 05 Sep 2012 15:38:57 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 05 Sep 2012 17:36:20 +0100" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> To: Alexey Melnikov Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 23:00:13 -0000 > Hi, > On 5 Sep 2012, at 17:12, Alissa Cooper wrote: > > Hi Alexey, > > > > On Sep 5, 2012, at 11:47 AM, Alexey Melnikov wrote: > > > >> I am pretty sure that obfuscated-IP and obfuscated-port are exactly what you ask for and they were in the document for ages. > >> > > > > Except that there isn't any normative suggestion that the obfuscated identifiers should be preferred or used by default, or that client addresses should only be used if there is some address-related functionality required by the endpoint. > Ok, fair point. Text can be added to discuss this. Agreed. How about adding something like this: Use of obfuscation techniques are appropriate when a need exists to be able to track connections back to the client only in some cases and only with the cooperation of the proxy operator. It also might be appropriate to say something about this being more of a forward proxy thing than a reverse proxy thing, but I'm not sure how to put it. The security considerations also need to say something about information leak from obfuscated identifiers themselves. For example, correlations are possible if the same obfuscated id is always used for a particular IP address. THe security considerations might also want to note the issues inherent in the appearance of RFC 1918 addresses, which are definitely allowed. (Or not - we certain don't make an issue of this in numerous othere places where this happens all the time.) And FWIW, having already explored this space a little, the main problem with obfuscation techniques isn't knowing when to use them but rather figuring out how they will actually be employed in an operational environment. That would be a lot harder to address with text and I suggest not going there. Ned From fgaliegue@gmail.com Wed Sep 5 16:11:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A56921F86CF for ; Wed, 5 Sep 2012 16:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0URwX0RQraO for ; Wed, 5 Sep 2012 16:11:41 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3AF21F86A8 for ; Wed, 5 Sep 2012 16:11:41 -0700 (PDT) Received: by vcbfl15 with SMTP id fl15so2088599vcb.22 for ; Wed, 05 Sep 2012 16:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Vec/Z9phlTXr0aOyTUWpexqhD1oYfsgBPVO9todOtAI=; b=cYLvbOPqeOdJ1AQoOHcUyJCNKdsq0MukMlKjb0DZfMQ+b37Z1NDxEHyWsA5nbCafHW ZLMjDseS517IlVuyNgTEnZ81RBWoFmKskPcYbTGpWny/5PAqwGUgRTEw7N25JcKvzsRt K2g8bLpyT6MBpH403CJnTrLkaATL/Cr1VUDgh6EMYp+QWId3hw8Tr48F1bpO9jyrOHyk hUirOVocmsyB1hX/EV482TJy3IXUWGOxVUAoqD7vPVcvIG0HcmdzpjpNnr/pNayUF6LI p9ZFdXFSLbHk7OEE4Gua714U/awCMlic3oktp7F3K6ajfm/t1lCpS4s9oHg1zwsreDzg 8iBw== MIME-Version: 1.0 Received: by 10.52.27.229 with SMTP id w5mr47188vdg.126.1346886700833; Wed, 05 Sep 2012 16:11:40 -0700 (PDT) Received: by 10.52.23.103 with HTTP; Wed, 5 Sep 2012 16:11:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Sep 2012 01:11:40 +0200 Message-ID: From: Francis Galiegue To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 23:11:42 -0000 On Wed, Sep 5, 2012 at 10:53 PM, Tim Bray wrote: [...] > > And then Java-like languages, there=E2=80=99s just really no good way to = model > the following, which might be a reasonable protocol element > > [ { "foo": 1, "bar" : false }, 23, "humpty-dumpty" ] > > at any level richer than List; so why bother? > Err... http://fasterxml.github.com/jackson-databind/javadoc/2.0.5/com/fasterxml/ja= ckson/databind/JsonNode.html >> The ugly are the weakly/untyped 'scripting'languages like Perl. These >> don't 'need' a schema because they don't 'need types. > > This is humor, I imagine? There are no other languages like Perl, > thank goodness. And as noted above, the types in modern > dynamically-typed language map with zero friction onto those expressed > by JSON. -Tim > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From tbray@textuality.com Wed Sep 5 16:18:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9FF021F86A8 for ; Wed, 5 Sep 2012 16:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S0TBwZYboNH for ; Wed, 5 Sep 2012 16:18:14 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id B1C5621F8686 for ; Wed, 5 Sep 2012 16:18:13 -0700 (PDT) Received: by wgbfm10 with SMTP id fm10so1204890wgb.34 for ; Wed, 05 Sep 2012 16:18:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=KKjtSZRcPMP1K5Ss8EMmOLhj9q88gImtDlbSX51mO+Q=; b=kjWf6lxMFIRfMrpVvmMQHd10mH9+z+mCg9+n4DQi0sMvTtTG7L5fHU3xfhubDUFaVA 8jEMvrt/uUrLRN2fkHPKIvFyDahR5CcYdoB4UEif4Frcp4Zz4YoznaY9/Rrg3xfvZBgA bie6hXiZCtMfza3PjiVYxCoFFs/BurhOj0SdU5Wb5XzObi+Qxm9qOb7e+E5bAF5XnD/V Cz5lps3BMeYmMD0uo5BVeQkpKCJaYesKlByfGbuw7pHc3cKtVfmr6gAcLIsgGl0u3AMO xkoxgY4OHWQADt23vWuOxNVKuBQLnoEK7TgRjdpzWR89xLCGf/GGkeX6MAzvHE3nv4nk /1Tw== MIME-Version: 1.0 Received: by 10.216.23.202 with SMTP id v52mr92408wev.32.1346887092322; Wed, 05 Sep 2012 16:18:12 -0700 (PDT) Received: by 10.195.13.200 with HTTP; Wed, 5 Sep 2012 16:18:12 -0700 (PDT) X-Originating-IP: [24.84.208.217] In-Reply-To: References: Date: Wed, 5 Sep 2012 16:18:12 -0700 Message-ID: From: Tim Bray To: Francis Galiegue Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmFVhrj03bSpi7ccmGCbuaORNb7ROqv9y3hd5T6m10zcsLDSxoqnlay4fUn54Wtsylc00Si Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 23:18:15 -0000 On Wed, Sep 5, 2012 at 4:11 PM, Francis Galiegue wrot= e: >> And then Java-like languages, there=92s just really no good way to model >> the following, which might be a reasonable protocol element >> >> [ { "foo": 1, "bar" : false }, 23, "humpty-dumpty" ] >> >> at any level richer than List; so why bother? > Err... > > http://fasterxml.github.com/jackson-databind/javadoc/2.0.5/com/fasterxml/= jackson/databind/JsonNode.html Sure, but I think Phillip was looking for a mapping into native data structures, not JSON objects. My argument is that this is trivial in Ruby/Python/Javascript, but impractical in Java & friends. -T > > >>> The ugly are the weakly/untyped 'scripting'languages like Perl. These >>> don't 'need' a schema because they don't 'need types. >> >> This is humor, I imagine? There are no other languages like Perl, >> thank goodness. And as noted above, the types in modern >> dynamically-typed language map with zero friction onto those expressed >> by JSON. -Tim >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > -- > Francis Galiegue, fgaliegue@gmail.com > JSON Schema: https://github.com/json-schema > "It seems obvious [...] that at least some 'business intelligence' > tools invest so much intelligence on the business side that they have > nothing left for generating SQL queries" (St=E9phane Faroult, in "The > Art of SQL", ISBN 0-596-00894-5) From hallam@gmail.com Wed Sep 5 16:26:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B07621F86C8 for ; Wed, 5 Sep 2012 16:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edKBmgaWvYhc for ; Wed, 5 Sep 2012 16:26:37 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by ietfa.amsl.com (Postfix) with ESMTP id E27B121F86C1 for ; Wed, 5 Sep 2012 16:26:36 -0700 (PDT) Received: by obbta17 with SMTP id ta17so1531163obb.22 for ; Wed, 05 Sep 2012 16:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GuXFas7Ar0zWj6rSQEBM+Tf9IcyPUzJNxonlHPCwBYQ=; b=h4c5kjV67DLZIcHlbBfykIAnmSK+NZOoFzeLpseLwzXeWXTf8lI6b5CM2gWrNFaZqV bfRLqyU1kJ6pkkgwL17MDGcs4prYk2pkiCYmOpy7lvAkNTvny1dEgXotGSaRi/ud+RNF w2lP7gDOpz0G3piElQKENyFznvEeGlFIl2c0f/pQ0AdQG09/ZfulvvDb+mmK+h3Ro4So 1ol+ORgXzCFxKqezIDdtivMO9mT87hR8nUBSQacpyvbNlvbbBUqhL8+2382AdtSHQ5H6 wRpEqSK8ZffGaf703HzudegfwvHmEUpVVRUe5qtSmaS5pjBEquoFaCW8MJ1ePXSuI9mD wvbw== MIME-Version: 1.0 Received: by 10.182.197.73 with SMTP id is9mr153295obc.32.1346887596075; Wed, 05 Sep 2012 16:26:36 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Wed, 5 Sep 2012 16:26:36 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Sep 2012 19:26:36 -0400 Message-ID: From: Phillip Hallam-Baker To: Tim Bray Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 23:26:37 -0000 On Wed, Sep 5, 2012 at 4:53 PM, Tim Bray wrote: > inline > > On Wed, Sep 5, 2012 at 8:37 AM, Phillip Hallam-Baker w= rote: >> I think what is needed here is a mapping between the data structures >> used in today's mainstream programming languages and JSON. > > That varies between unnecessary and impossible. In modern > dynamically-typed languages (ruby/python/etc) there=92s no necessity; > JSON encodes hashes, lists, and a few primitive types, all of which > are built-ins. I think you are taking your favored approach and gifting it the adjective 'modern'. The advantage of strong static typing is that you can catch errors at compile time rather than run time. Thats not possible with dynamic typing by definition. There are certainly applications where static typing can get in the way of the programmer. But just as a programming language that requires a context sensitive grammar is probably doing something wrong, a protocol that relies on dynamic typing is probably doing something wrong as well. > And then Java-like languages, there=92s just really no good way to model > the following, which might be a reasonable protocol element > > [ { "foo": 1, "bar" : false }, 23, "humpty-dumpty" ] It might be a protocol element but I can't see it being a 'reasonable' one. > at any level richer than List; so why bother? The reason to bother is that standards making is the process of making choices that don't matter. A protocol exchange that can't be described more precisely than List is most likely a confused mess. >> The ugly are the weakly/untyped 'scripting'languages like Perl. These >> don't 'need' a schema because they don't 'need types. > > This is humor, I imagine? There are no other languages like Perl, > thank goodness. And as noted above, the types in modern > dynamically-typed language map with zero friction onto those expressed > by JSON. -Tim I guess which category you put Ruby/Python in depends on how you want to use them. --=20 Website: http://hallambaker.com/ From hallam@gmail.com Wed Sep 5 16:33:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7329F21F86E8 for ; Wed, 5 Sep 2012 16:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqWgZqrCGt5Z for ; Wed, 5 Sep 2012 16:33:47 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by ietfa.amsl.com (Postfix) with ESMTP id B0DDC21F84E1 for ; Wed, 5 Sep 2012 16:33:47 -0700 (PDT) Received: by obbta17 with SMTP id ta17so1541576obb.22 for ; Wed, 05 Sep 2012 16:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ral6hi0RVKG4FQzQyuol9CF/tD7eC2CxNSb1N9LxsBM=; b=Jxq3NUGOi2aMSf8BQRQNokzjiYV6EXEFPeHrRnALgBxWM7bkj61rcfKqg8yHriQ+aH V/C2+I+uG9dekKYjcxGJcR7Ch7QA9oTy6ZiYmWgJ3oJ66pR6ldGYtB4X3K1aCnuWwFZ2 LVHou43/SB5NwTv8uZJZMF1n0/VdKuGQbbLU5r15PlYbqdRQOdPOfoIwLgz7XZuY/G9H KbaoGq5n99WaKZWTQ4evA2hOoVKOBFmfEhnNYL4CdxjwxVLxtkFgJIVA/J9sis+HUzI7 p69wFBtDmn9xMDrzR86TbLxipReSJ2YnC2WL9i3Ml9Cz8TPIyQwkkCl6obs3ygrA1V+L eLdw== MIME-Version: 1.0 Received: by 10.60.172.236 with SMTP id bf12mr177549oec.23.1346888027328; Wed, 05 Sep 2012 16:33:47 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Wed, 5 Sep 2012 16:33:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Sep 2012 19:33:47 -0400 Message-ID: From: Phillip Hallam-Baker To: Tim Bray Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 23:33:48 -0000 On Wed, Sep 5, 2012 at 7:18 PM, Tim Bray wrote: > On Wed, Sep 5, 2012 at 4:11 PM, Francis Galiegue wr= ote: >>> And then Java-like languages, there=92s just really no good way to mode= l >>> the following, which might be a reasonable protocol element >>> >>> [ { "foo": 1, "bar" : false }, 23, "humpty-dumpty" ] >>> >>> at any level richer than List; so why bother? >> Err... >> >> http://fasterxml.github.com/jackson-databind/javadoc/2.0.5/com/fasterxml= /jackson/databind/JsonNode.html > > Sure, but I think Phillip was looking for a mapping into native data > structures, not JSON objects. My argument is that this is trivial in > Ruby/Python/Javascript, but impractical in Java & friends. -T I have a generator for exactly that mapping, albeit for C# rather than Java= . Creating that mapping is precisely the reason I need a schema. That and being able to document the protocol: http://www.ietf.org/id/draft-hallambaker-omnibroker-02.txt The code examples and the text are both generated from the schema. That generator is set up to produce C# but C is only a little bit harder. --=20 Website: http://hallambaker.com/ From pbryan@anode.ca Wed Sep 5 16:43:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF3821F8578 for ; Wed, 5 Sep 2012 16:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WP2qA8TX84vx for ; Wed, 5 Sep 2012 16:43:40 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id E72DE21F856D for ; Wed, 5 Sep 2012 16:43:39 -0700 (PDT) Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 0F86D6488 for ; Wed, 5 Sep 2012 23:43:38 +0000 (UTC) From: "Paul C. Bryan" To: discuss@apps.ietf.org In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-/5VPf9hrLfH8A8CCCAar" Date: Wed, 05 Sep 2012 16:43:34 -0700 Message-ID: <1346888614.16601.23.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 23:43:40 -0000 --=-/5VPf9hrLfH8A8CCCAar Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2012-09-05 at 08:47 -0700, James M Snell wrote: > 3) Unless we specifically want to allow for such things, it should be > made clear that "test" is not intended to be used as a replacement for > other types of http conditionals. The specification currently reads: > The "test" operation tests that a value at the specified location in > the target document is equal to a specified value. I could probably come up with a half dozen ways someone could use this operation outside of its intent. Why should we call this one out specifically? Paul --=-/5VPf9hrLfH8A8CCCAar Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 2012-09-05 at 08:47 -0700, James M Snell wrote:

3) Unless we specifically want to allow for such things, it should be made clear that "test" is not intended to be used as a replacement for other types of http conditionals.

The specification currently reads:

The "test" operation tests that a value at the specified location in the target document is equal to a specified value.

I could probably come up with a half dozen ways someone could use this operation outside of its intent. Why should we call this one out specifically?

Paul
--=-/5VPf9hrLfH8A8CCCAar-- From jasnell@gmail.com Wed Sep 5 16:53:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFEC21F8686 for ; Wed, 5 Sep 2012 16:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXm8o8at+8dK for ; Wed, 5 Sep 2012 16:53:09 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1395F21F86F4 for ; Wed, 5 Sep 2012 16:53:08 -0700 (PDT) Received: by wgbds1 with SMTP id ds1so4241902wgb.4 for ; Wed, 05 Sep 2012 16:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XtqhzEcwQZ4C1XcVlGkjtUh/Wk90VQDbQ14ZzKP8sJw=; b=k3quIOMDMqKFFWhFAkI2iHTcZDNU1CLLHZd3XRZhMkz4GPnN29vA2PehgL5qwsi2fS dAvSApa63yCBY6qUzHI7Q6hSzkE4y/drtVcfq1pygtId6QTOAkYW14YnU3tjPuaZm45b HtG8GW9bszScPsm5eB396fMc7tj00Fgka+rrEPwOtR8sWzGGlJnINf3MMk+dpbyyAFm+ /XDhxYNy7POHWEUObqOuzNZkigkGYHXOSp3roeAmprKgZCLHYq7LerHu30j6pwxvWagm ItYLFdk6cTicgMMCzAukKvW3DyKzac2MpzwRliolwb+B+mLOKjnJGHmppCuw8UX2HywX TFQA== Received: by 10.217.1.79 with SMTP id m57mr110604wes.121.1346889187978; Wed, 05 Sep 2012 16:53:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.58.136 with HTTP; Wed, 5 Sep 2012 16:52:47 -0700 (PDT) In-Reply-To: <1346888614.16601.23.camel@pbryan-wsl.internal.salesforce.com> References: <1346888614.16601.23.camel@pbryan-wsl.internal.salesforce.com> From: James M Snell Date: Wed, 5 Sep 2012 16:52:47 -0700 Message-ID: To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=20cf302077dc99ef5e04c8fd1317 Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 23:53:10 -0000 --20cf302077dc99ef5e04c8fd1317 Content-Type: text/plain; charset=UTF-8 Generally because people seem to be particularly bad about handling things like etags and last modified timestamps... e.g. https://developers.google.com/blogger/docs/3.0/performance#patch Perhaps it's not necessary, but I've learned not to err on the side of common sense. - James On Wed, Sep 5, 2012 at 4:43 PM, Paul C. Bryan wrote: > ** > On Wed, 2012-09-05 at 08:47 -0700, James M Snell wrote: > > 3) Unless we specifically want to allow for such things, it should be > made clear that "test" is not intended to be used as a replacement for > other types of http conditionals. > > > The specification currently reads: > > The "test" operation tests that a value at the specified location in the > target document is equal to a specified value. > > > I could probably come up with a half dozen ways someone could use this > operation outside of its intent. Why should we call this one out > specifically? > > Paul > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --20cf302077dc99ef5e04c8fd1317 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Generally because people seem to be pa= rticularly bad about handling things like etags and last modified timestamp= s... e.g.=C2=A0https://developers.google.com/blogger/docs/3.0/performance= #patch

Perhaps it's not necessary, but I've learned n= ot to err on the side of common sense.

- James
On Wed, Sep 5, 2012 at 4:43 PM, Paul C. Bryan = <= pbryan@anode.ca> wrote:
=20 =20
On Wed, 2012-09-05 at 08:47 -0700, James M Snell wrote:

3) Unless we specifically want to allow for such things, it should be m= ade clear that "test" is not intended to be used as a replacement= for other types of http conditionals.

The specification currently reads:

The "test" operation tests that a value at the specified loca= tion in the target document is equal to a specified value.

I could probably come up with a half dozen ways someone could use this oper= ation outside of its intent. Why should we call this one out specifically? =

Paul

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--20cf302077dc99ef5e04c8fd1317-- From fgaliegue@gmail.com Wed Sep 5 16:58:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382EF21F8682 for ; Wed, 5 Sep 2012 16:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMFe998M04HR for ; Wed, 5 Sep 2012 16:58:44 -0700 (PDT) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8C39F21F8680 for ; Wed, 5 Sep 2012 16:58:44 -0700 (PDT) Received: by vbbfo1 with SMTP id fo1so884147vbb.22 for ; Wed, 05 Sep 2012 16:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=u4bV1dN5sAirDPm9X5/bT0Wlztmvz8D/0/+EjV5n0SE=; b=wAxXN2/FlXgdh4jUZQYIfbHiMx1+CzFD0jftY16SziBqgEtQPDswAw6h2r5sTs43Be gHcI2ivCJNVKpPpPL3RQpy9r6UVCEtAEibAOk/MyjP7yiIER1FVsTn1ee9l4PBrW5Kvd jUiFWAop9widW2/m6uh97E4WTt3hFp61nVNeEckQdGPZOCkrIKOz5QNXCluF8/2VUOF4 xbUhPMCC8PfEMHRHtTyNd3ggm8QhfOMDrHT6WOLV0/W1NJN42HOeofU4dq8cToB1mD4F dCEDk56BC5jRgJBwGnNkOG4v5wHb0PqxdWp1qcNWFUY1pHG4uM3pKL6NHDELzGQ+wIXo M9LA== MIME-Version: 1.0 Received: by 10.52.35.99 with SMTP id g3mr196182vdj.21.1346889523786; Wed, 05 Sep 2012 16:58:43 -0700 (PDT) Received: by 10.52.23.103 with HTTP; Wed, 5 Sep 2012 16:58:43 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Sep 2012 01:58:43 +0200 Message-ID: From: Francis Galiegue To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 23:58:45 -0000 On Thu, Sep 6, 2012 at 1:18 AM, Tim Bray wrote: [...] > > Sure, but I think Phillip was looking for a mapping into native data > structures Yes, and this is territory which JSON Schema must not venture into, imho: JSON is, by virtue, a language-neutral standard, And we should thank it for that ;) --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From pbryan@anode.ca Wed Sep 5 17:06:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC2721F8718 for ; Wed, 5 Sep 2012 17:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeYLE2M4HMOj for ; Wed, 5 Sep 2012 17:06:48 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id E2FE821F8713 for ; Wed, 5 Sep 2012 17:06:47 -0700 (PDT) Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 389C46485 for ; Thu, 6 Sep 2012 00:06:47 +0000 (UTC) From: "Paul C. Bryan" To: apps-discuss@ietf.org In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-4O4WHZtz+W+vV8LlzhxS" Date: Wed, 05 Sep 2012 17:06:45 -0700 Message-ID: <1346890005.16601.45.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Subject: Re: [apps-discuss] Json Patch Extended Operations - *Experimental* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 00:06:49 -0000 --=-4O4WHZtz+W+vV8LlzhxS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I agree that these additional constructs could come in handy under the right circumstances. That said, I see no way to bound the scope, because any addition could be deemed handy under the right circumstances. I wrestled initially with the consequences of adding the test operation when it was first suggested. My notable concern was that it could creep into more than just a simple equality test, perhaps even be pushed to qualify particular operations (as you're suggesting), and ultimately lead toward the need to sport a Turing-complete query syntax! Okay, that's going too far, but hopefully this illustrates the extent of my concern: slippery slope, in for a penny in for a pound, etc. The use case that drove the equality test for me was (quasi-) RESTful: there's a clear need to test equality of the partial state of a JSON document as a precondition of its modification. In the case of HTTP PATCH in particular, this presumes that the patch document is not being applied blindly. Your suggested extended operations definitely go beyond that scope. Paul On Wed, 2012-09-05 at 10:03 -0700, James M Snell wrote: > I've recently been experimenting with the JSON Patch format in a > variety of scenarios in order to gain some additional implementation > experience. I've found that in a number of cases it can be useful to > apply more additional types of test operations. I am considering > writing these up as a separate I-D as an extension to Json-Patch but > I'm not yet fully convinced that it's something that should be done; > so I wanted to solicit some feedback from the group at large. > > > > In my experiments, I have toyed around with the following additional > test operations: > > > "not" -- aggregate test... all of the contained operations must > evaluate to false.. must not contain change operations.. tests only > "and" -- aggregate test... all of the contained operations must > evaluate to true.. must not contain change operations.. tests only > "or" -- aggregate test... any of the contained operations must > evaluate to true.. must not contain change operations.. tests only > "typeOf" -- tests to ensure that the referenced object is the > specified type (using javascript typeof) > "contains" -- does the toString value of the referenced object > contain the specified value > "startsWith"-- does the toString value of the referenced object start > with the specified value > "endsWith" -- does the toString value of the referenced object end > with the specified value > "matches" -- does the toString value of the referenced object match > the given regular expression > "lessThan" -- if the value is numeric or a date, returns true if node > value is more than specified value > "moreThan" -- if the value is numeric or a date, returns true if node > value is more than specified value > > > For example, consider the following hypothetical, extended json-patch > > > [ > { "and": [ > { "not": [ > {"moreThan", "/a/bar", "value": 123}, > {"matches", "/a/baz", "/sample/ig"} > ] > }, > {"contains": "/a/foo", "value": "123"}, > {"typeOf": "/a/b/version", "value": "number"} > ] > }, > {"add": "/a/b/c", "value": "foo"}, > {"replace": "/a/b/version", value: 1} > ] > > > In this example, the change operations ("add" and "increment") are > only applied if and only if: > > > * The /a/b/version property exists and is a numeric value, > * The /a/foo property contains the characters "123" in it's string > representation, > * The /a/baz property does not match the regular > expression /sample/ig, and > * The /a/bar property is numeric and is less than or equal to 123 > > > Yes, this adds quite a bit more complexity and yes, it's not yet clear > if this is something of value. I'm not arguing that we SHOULD do this, > but in a variety of experiments such tests have demonstrated > usefulness. > > > Also, I was asked recently whether JSON-Patch could be made to apply > changes over a set of properties within a document that match a given > criteria. For example, consider the following source JSON document: > > > { > "items": [ > { "actor": {"displayName": "James" }, > "verb": "post", > "object": {"objectType": "note", "content": "test 1" }}, > { "actor": {"displayName": "Joe" }, > "verb": "post", > "object": {"objectType": "note", "content": "test 2" }}, > { "actor": {"displayName": "Sally" }, > "verb": "share", > "updated": "2012-12-12T12:12:12Z", > "object": {"objectType": "book", "id": "urn:foo:1" }}, > ] > } > > > Suppose I wish to add a "published" property to all items that > currently do not have one... I could accomplish this using a new > extended "each" operation... > > [ > { "each": "/items", > "apply": [ > {"not": [{"test":"/updated"}]}, > {"add": "/updated", "value": "2012-12-12T12:12:12Z"} > ] > } > ] > > > This evaluates as: For each member of /items, test to see if the > member has an updated property. If not, add it with the value > "2012-12-12T12:12:12Z". If /items is a primitive, the "each" operation > would fail as an error condition. If /items is an array, then each > iterates over each member of the array. If /items is an object, each > iterates over each of that's objects member properties. > > > Note, however, that this differs quite a bit from the existing > semantics of json-patch. For one, a negative test within the "apply" > would not signal an error condition that would halt the entire patch > operation. The negative test would simply mean that the modification > for that particular element would not be applied. All of the changes > within. > > > Again, I'm not yet convinced this is a good idea but experimentation > has demonstrated that it's at least a workable approach. I'd very much > like to hear from others on whether or not this is something we should > or should not attempt to pursue. > > > Thoughts? > > > - James > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-4O4WHZtz+W+vV8LlzhxS Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit I agree that these additional constructs could come in handy under the right circumstances. That said, I see no way to bound the scope, because any addition could be deemed handy under the right circumstances.

I wrestled initially with the consequences of adding the test operation when it was first suggested. My notable concern was that it could creep into more than just a simple equality test, perhaps even be pushed to qualify particular operations (as you're suggesting), and ultimately lead toward the need to sport a Turing-complete query syntax! Okay, that's going too far, but hopefully this illustrates the extent of my concern: slippery slope, in for a penny in for a pound, etc.

The use case that drove the equality test for me was (quasi-) RESTful: there's a clear need to test equality of the partial state of a JSON document as a precondition of its modification. In the case of HTTP PATCH in particular, this presumes that the patch document is not being applied blindly. Your suggested extended operations definitely go beyond that scope.

Paul

On Wed, 2012-09-05 at 10:03 -0700, James M Snell wrote:
I've recently been experimenting with the JSON Patch format in a variety of scenarios in order to gain some additional implementation experience. I've found that in a number of cases it can be useful to apply more additional types of test operations. I am considering writing these up as a separate I-D as an extension to Json-Patch but I'm not yet fully convinced that it's something that should be done; so I wanted to solicit some feedback from the group at large.


In my experiments, I have toyed around with the following additional test operations:


"not"       -- aggregate test... all of the contained operations must evaluate to false.. must not contain change operations.. tests only
"and"       -- aggregate test... all of the contained operations must evaluate to true.. must not contain change operations.. tests only
"or"        -- aggregate test... any of the contained operations must evaluate to true.. must not contain change operations.. tests only
"typeOf"    -- tests to ensure that the referenced object is the specified type (using javascript typeof)
"contains"  -- does the toString value of the referenced object contain the specified value
"startsWith"-- does the toString value of the referenced object start with the specified value
"endsWith"  -- does the toString value of the referenced object end with the specified value
"matches"   -- does the toString value of the referenced object match the given regular expression
"lessThan"  -- if the value is numeric or a date, returns true if node value is more than specified value
"moreThan"  -- if the value is numeric or a date, returns true if node value is more than specified value


For example, consider the following hypothetical, extended json-patch


  [
    { "and": [
        { "not": [
            {"moreThan", "/a/bar", "value": 123},
            {"matches", "/a/baz", "/sample/ig"}
          ]
        },
        {"contains": "/a/foo", "value": "123"},
        {"typeOf": "/a/b/version", "value": "number"}
      ]
    },
    {"add": "/a/b/c", "value": "foo"},
    {"replace": "/a/b/version", value: 1} 
  ]


In this example, the change operations ("add" and "increment") are only applied if and only if:


  * The /a/b/version property exists and is a numeric value,
  * The /a/foo property contains the characters "123" in it's string representation,
  * The /a/baz property does not match the regular expression /sample/ig, and
  * The /a/bar property is numeric and is less than or equal to 123


Yes, this adds quite a bit more complexity and yes, it's not yet clear if this is something of value. I'm not arguing that we SHOULD do this, but in a variety of experiments such tests have demonstrated usefulness.


Also, I was asked recently whether JSON-Patch could be made to apply changes over a set of properties within a document that match a given criteria. For example, consider the following source JSON document:


  {
    "items": [
      { "actor": {"displayName": "James" },
        "verb": "post",
        "object": {"objectType": "note", "content": "test 1" }},
      { "actor": {"displayName": "Joe" },
        "verb": "post",
        "object": {"objectType": "note", "content": "test 2" }},
      { "actor": {"displayName": "Sally" },
        "verb": "share",
        "updated": "2012-12-12T12:12:12Z",
        "object": {"objectType": "book", "id": "urn:foo:1" }},
    ]
  }


Suppose I wish to add a "published" property to all items that currently do not have one... I could accomplish this using a new extended "each" operation...
 
  [
    { "each": "/items", 
      "apply": [
        {"not": [{"test":"/updated"}]},
        {"add": "/updated", "value": "2012-12-12T12:12:12Z"}
      ]
    }
  ]


This evaluates as: For each member of /items, test to see if the member has an updated property. If not, add it with the value "2012-12-12T12:12:12Z". If /items is a primitive, the "each" operation would fail as an error condition. If /items is an array, then each iterates over each member of the array. If /items is an object, each iterates over each of that's objects member properties. 


Note, however, that this differs quite a bit from the existing semantics of json-patch. For one, a negative test within the "apply" would not signal an error condition that would halt the entire patch operation. The negative test would simply mean that the modification for that particular element would not be applied. All of the changes within.


Again, I'm not yet convinced this is a good idea but experimentation has demonstrated that it's at least a workable approach. I'd very much like to hear from others on whether or not this is something we should or should not attempt to pursue.


Thoughts?


- James 




_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--=-4O4WHZtz+W+vV8LlzhxS-- From jasnell@gmail.com Wed Sep 5 17:11:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9F921F8715 for ; Wed, 5 Sep 2012 17:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKesMWc3dSq0 for ; Wed, 5 Sep 2012 17:11:52 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2D421F8713 for ; Wed, 5 Sep 2012 17:11:51 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so695989wgb.13 for ; Wed, 05 Sep 2012 17:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kvzbJD0P0gShId5yEEGv49ft5xbLdN2/1ra/LV3kgPs=; b=cMJ8YH5UNEkJr2T3cj/1ntJBx2fp7YrT3Doyigh27rjfJkeSc9p6x8oCfchQDBKFJW J8pilreYqCEjZN9xaxHozsQoos13dEO33K6mR2X/VDlifpeNNDFfKMZN8qtqcxgwThhU XRHFXyILj0Z+FsygseekDOwluCH2BTaoEAxgAfcyPcfk9ofJWycWcz/EN8j6/MmyLcV+ 7Ye8LQz7u55GuW0s2gftYnRIZ9Obwdl1xGjpvPBJcOHkz+fQqcn2fpb5owqf4ruFXqf2 IcuPIGDKvZ3xOnohiY5PxiIlyKXsP9Ispv7+xPJSixY9CI+8NXv/08II4TYgg8ZnUgIJ uk5Q== Received: by 10.180.86.106 with SMTP id o10mr580591wiz.22.1346890311253; Wed, 05 Sep 2012 17:11:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.58.136 with HTTP; Wed, 5 Sep 2012 17:11:31 -0700 (PDT) In-Reply-To: <1346890005.16601.45.camel@pbryan-wsl.internal.salesforce.com> References: <1346890005.16601.45.camel@pbryan-wsl.internal.salesforce.com> From: James M Snell Date: Wed, 5 Sep 2012 17:11:31 -0700 Message-ID: To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=f46d041827528dc0a404c8fd5644 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Json Patch Extended Operations - *Experimental* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 00:11:54 -0000 --f46d041827528dc0a404c8fd5644 Content-Type: text/plain; charset=UTF-8 Indeed. It is definitely a slippery slope. At the very least, I think this can demonstrate that *IF* (and it's a big if) an application needs additional support for a broader range of test options, it can be implemented in a way that is generally consistent with the existing json-patch format -- and defined as an extension of json patch albeit with a different media type. For now, then, I'll likely table this and chalk it up as an interesting experiment until and unless there is more of a demonstrated need. On Wed, Sep 5, 2012 at 5:06 PM, Paul C. Bryan wrote: > ** > I agree that these additional constructs could come in handy under the > right circumstances. That said, I see no way to bound the scope, because * > any* addition could be deemed handy under the right circumstances. > > I wrestled initially with the consequences of adding the test operation > when it was first suggested. My notable concern was that it could creep > into more than just a simple equality test, perhaps even be pushed to > qualify particular operations (as you're suggesting), and ultimately lead > toward the need to sport a Turing-complete query syntax! Okay, that's going > too far, but hopefully this illustrates the extent of my concern: slippery > slope, in for a penny in for a pound, etc. > > The use case that drove the equality test for me was (quasi-) RESTful: > there's a clear need to test equality of the partial state of a JSON > document as a precondition of its modification. In the case of HTTP PATCH > in particular, this presumes that the patch document is not being applied > blindly. Your suggested extended operations definitely go beyond that > scope. > > Paul > > > On Wed, 2012-09-05 at 10:03 -0700, James M Snell wrote: > > I've recently been experimenting with the JSON Patch format in a variety > of scenarios in order to gain some additional implementation experience. > I've found that in a number of cases it can be useful to apply more > additional types of test operations. I am considering writing these up as a > separate I-D as an extension to Json-Patch but I'm not yet fully convinced > that it's something that should be done; so I wanted to solicit some > feedback from the group at large. > > > > In my experiments, I have toyed around with the following additional > test operations: > > > > "not" -- aggregate test... all of the contained operations must > evaluate to false.. must not contain change operations.. tests only > > "and" -- aggregate test... all of the contained operations must > evaluate to true.. must not contain change operations.. tests only > > "or" -- aggregate test... any of the contained operations must > evaluate to true.. must not contain change operations.. tests only > > "typeOf" -- tests to ensure that the referenced object is the > specified type (using javascript typeof) > > "contains" -- does the toString value of the referenced object contain > the specified value > > "startsWith"-- does the toString value of the referenced object start > with the specified value > > "endsWith" -- does the toString value of the referenced object end with > the specified value > > "matches" -- does the toString value of the referenced object match the > given regular expression > > "lessThan" -- if the value is numeric or a date, returns true if node > value is more than specified value > > "moreThan" -- if the value is numeric or a date, returns true if node > value is more than specified value > > > > For example, consider the following hypothetical, extended json-patch > > > > [ > > { "and": [ > > { "not": [ > > {"moreThan", "/a/bar", "value": 123}, > > {"matches", "/a/baz", "/sample/ig"} > > ] > > }, > > {"contains": "/a/foo", "value": "123"}, > > {"typeOf": "/a/b/version", "value": "number"} > > ] > > }, > > {"add": "/a/b/c", "value": "foo"}, > > {"replace": "/a/b/version", value: 1} > > ] > > > > In this example, the change operations ("add" and "increment") are only > applied if and only if: > > > > * The /a/b/version property exists and is a numeric value, > > * The /a/foo property contains the characters "123" in it's string > representation, > > * The /a/baz property does not match the regular expression /sample/ig, > and > > * The /a/bar property is numeric and is less than or equal to 123 > > > > Yes, this adds quite a bit more complexity and yes, it's not yet clear > if this is something of value. I'm not arguing that we SHOULD do this, but > in a variety of experiments such tests have demonstrated usefulness. > > > > Also, I was asked recently whether JSON-Patch could be made to apply > changes over a set of properties within a document that match a given > criteria. For example, consider the following source JSON document: > > > > { > > "items": [ > > { "actor": {"displayName": "James" }, > > "verb": "post", > > "object": {"objectType": "note", "content": "test 1" }}, > > { "actor": {"displayName": "Joe" }, > > "verb": "post", > > "object": {"objectType": "note", "content": "test 2" }}, > > { "actor": {"displayName": "Sally" }, > > "verb": "share", > > "updated": "2012-12-12T12:12:12Z", > > "object": {"objectType": "book", "id": "urn:foo:1" }}, > > ] > > } > > > > Suppose I wish to add a "published" property to all items that currently > do not have one... I could accomplish this using a new extended "each" > operation... > > > > [ > > { "each": "/items", > > "apply": [ > > {"not": [{"test":"/updated"}]}, > > {"add": "/updated", "value": "2012-12-12T12:12:12Z"} > > ] > > } > > ] > > > > This evaluates as: For each member of /items, test to see if the member > has an updated property. If not, add it with the value > "2012-12-12T12:12:12Z". If /items is a primitive, the "each" operation > would fail as an error condition. If /items is an array, then each iterates > over each member of the array. If /items is an object, each iterates over > each of that's objects member properties. > > > > Note, however, that this differs quite a bit from the existing semantics > of json-patch. For one, a negative test within the "apply" would not signal > an error condition that would halt the entire patch operation. The negative > test would simply mean that the modification for that particular element > would not be applied. All of the changes within. > > > > Again, I'm not yet convinced this is a good idea but experimentation has > demonstrated that it's at least a workable approach. I'd very much like to > hear from others on whether or not this is something we should or should > not attempt to pursue. > > > > Thoughts? > > > > - James > > > > > > _______________________________________________ > apps-discuss mailing listapps-discuss@ietf.orghttps://www.ietf.org/mailman/listinfo/apps-discuss > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d041827528dc0a404c8fd5644 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Indeed. It is definitely a slippery sl= ope. At the very least, I think this can demonstrate that *IF* (and it'= s a big if) an application needs additional support for a broader range of = test options, it can be implemented in a way that is generally consistent w= ith the existing json-patch format -- and defined as an extension of json p= atch albeit with a different media type. For now, then, I'll likely tab= le this and chalk it up as an interesting experiment until and unless there= is more of a demonstrated need.

On Wed, Sep 5, 2012 at 5:06 PM, Paul = C. Bryan <pbryan@anode.ca> wrote:
=20 =20
I agree that these additional constructs could come in handy under the righ= t circumstances. That said, I see no way to bound the scope, because any= addition could be deemed handy under the right circumstances.

I wrestled initially with the consequences of adding the test operation whe= n it was first suggested. My notable concern was that it could creep into m= ore than just a simple equality test, perhaps even be pushed to qualify par= ticular operations (as you're suggesting), and ultimately lead toward t= he need to sport a Turing-complete query syntax! Okay, that's going too= far, but hopefully this illustrates the extent of my concern: slippery slo= pe, in for a penny in for a pound, etc.

The use case that drove the equality test for me was (quasi-) RESTful: ther= e's a clear need to test equality of the partial state of a JSON docume= nt as a precondition of its modification. In the case of HTTP PATCH in part= icular, this presumes that the patch document is not being applied blindly.= Your suggested extended operations definitely go beyond that scope.

Paul


On Wed, 2012-09-05 at 10:03 -0700, James M Snell wrote:
I've recently been experimenting with the JSON Patch format in a va= riety of scenarios in order to gain some additional implementation experien= ce. I've found that in a number of cases it can be useful to apply more= additional types of test operations. I am considering writing these up as = a separate I-D as an extension to Json-Patch but I'm not yet fully conv= inced that it's something that should be done; so I wanted to solicit s= ome feedback from the group at large.


In my experiments, I have toyed around with the following additional te= st operations:


"not" =C2=A0 =C2=A0 =C2=A0 -- aggregate test... all of the co= ntained operations must evaluate to false.. must not contain change operati= ons.. tests only
"and" =C2=A0 =C2=A0 =C2=A0 -- aggregate test... all of the co= ntained operations must evaluate to true.. must not contain change operatio= ns.. tests only
"or" =C2=A0 =C2=A0 =C2=A0 =C2=A0-- aggregate test... any of t= he contained operations must evaluate to true.. must not contain change ope= rations.. tests only
"typeOf" =C2=A0 =C2=A0-- tests to ensure that the referenced = object is the specified type (using javascript typeof)
"contains" =C2=A0-- does the toString value of the referenced= object contain the specified value
"startsWith"-- does the toString value of the referenced obje= ct start with the specified value
"endsWith" =C2=A0-- does the toString value of the referenced= object end with the specified value
"matches" =C2=A0 -- does the toString value of the referenced= object match the given regular expression
"lessThan" =C2=A0-- if the value is numeric or a date, return= s true if node value is more than specified value
"moreThan" =C2=A0-- if the value is numeric or a date, return= s true if node value is more than specified value


For example, consider the following hypothetical, extended json-patch


=C2=A0 [
=C2=A0 =C2=A0 { "and": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "not": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {"moreThan", "= /a/bar", "value": 123},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {"matches", "/= a/baz", "/sample/ig"}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {"contains": "/a/foo", = "value": "123"},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {"typeOf": "/a/b/version&quo= t;, "value": "number"}
=C2=A0 =C2=A0 =C2=A0 ]
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 {"add": "/a/b/c", "value": = "foo"},
=C2=A0 =C2=A0 {"replace": "/a/b/version", value: 1}= =C2=A0
=C2=A0 ]


In this example, the change operations ("add" and "incre= ment") are only applied if and only if:


=C2=A0 * The /a/b/version property exists and is a numeric value,
=C2=A0 * The /a/foo property contains the characters "123" in= it's string representation,
=C2=A0 * The /a/baz property does not match the regular expression /sam= ple/ig, and
=C2=A0 * The /a/bar property is numeric and is less than or equal to 12= 3


Yes, this adds quite a bit more complexity and yes, it's not yet cl= ear if this is something of value. I'm not arguing that we SHOULD do th= is, but in a variety of experiments such tests have demonstrated usefulness= .


Also, I was asked recently whether JSON-Patch could be made to apply ch= anges over a set of properties within a document that match a given criteri= a. For example, consider the following source JSON document:


=C2=A0 {
=C2=A0 =C2=A0 "items": [
=C2=A0 =C2=A0 =C2=A0 { "actor": {"displayName": &qu= ot;James" },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "verb": "post",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "object": {"objectType"= : "note", "content": "test 1" }},
=C2=A0 =C2=A0 =C2=A0 { "actor": {"displayName": &qu= ot;Joe" },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "verb": "post",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "object": {"objectType"= : "note", "content": "test 2" }},
=C2=A0 =C2=A0 =C2=A0 { "actor": {"displayName": &qu= ot;Sally" },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "verb": "share",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "updated": "2012-12-12T12:12= :12Z",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "object": {"objectType"= : "book", "id": "urn:foo:1" }},
=C2=A0 =C2=A0 ]
=C2=A0 }


Suppose I wish to add a "published" property to all items tha= t currently do not have one... I could accomplish this using a new extended= "each" operation...
=C2=A0
=C2=A0 [
=C2=A0 =C2=A0 { "each": "/items",=C2=A0
=C2=A0 =C2=A0 =C2=A0 "apply": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {"not": [{"test":"= /updated"}]},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {"add": "/updated", &qu= ot;value": "2012-12-12T12:12:12Z"}
=C2=A0 =C2=A0 =C2=A0 ]
=C2=A0 =C2=A0 }
=C2=A0 ]


This evaluates as: For each member of /items, test to see if the member= has an updated property. If not, add it with the value "2012-12-12T12= :12:12Z". If /items is a primitive, the "each" operation wou= ld fail as an error condition. If /items is an array, then each iterates ov= er each member of the array. If /items is an object, each iterates over eac= h of that's objects member properties.=C2=A0


Note, however, that this differs quite a bit from the existing semantic= s of json-patch. For one, a negative test within the "apply" woul= d not signal an error condition that would halt the entire patch operation.= The negative test would simply mean that the modification for that particu= lar element would not be applied. All of the changes within.


Again, I'm not yet convinced this is a good idea but experimentatio= n has demonstrated that it's at least a workable approach. I'd very= much like to hear from others on whether or not this is something we shoul= d or should not attempt to pursue.


Thoughts?


- James 




_______________________________________________
apps-discuss mailing list
apps-discuss@iet=
f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--f46d041827528dc0a404c8fd5644-- From ben@niven-jenkins.co.uk Wed Sep 5 17:12:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4071C21F84F1 for ; Wed, 5 Sep 2012 17:12:25 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2lLUOt+646B for ; Wed, 5 Sep 2012 17:12:24 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7686321F84EF for ; Wed, 5 Sep 2012 17:12:24 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.3]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1T9Phm-0006vn-Pj; Thu, 06 Sep 2012 01:12:23 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <5047C300.6040305@cs.tcd.ie> Date: Thu, 6 Sep 2012 01:12:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <700E38F9-942B-449A-9909-1067CEB1FB4C@tzi.org> <504651FE.9070904@cs.tcd.ie> <20120905231943.223b04bc@hetzer> <5047C300.6040305@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 00:12:25 -0000 Stephen, On 5 Sep 2012, at 22:24, Stephen Farrell wrote: > On 09/05/2012 10:19 PM, Andreas Petersson wrote: >> On Tue, 04 Sep 2012 20:09:50 +0100 >> Stephen Farrell wrote: >>> (Is that only by wikipedia or >>> more broadly?) >>=20 >>> =46rom the top of my head, a (incomplete) list of software that = supports >> XFF: >> squid, apache httpd, apache traffic server, varnish, >> nginx, haproxy, cisco cache engine, lighttpd. >>=20 >> Google, uses it, lots of phone operators, for sure a lot of sites use >> it in reverse proxies. >> I am also pretty sure that lots of sites logs XFF and use it in >> statistics. >=20 > Sorry, I mean the wikipedia use-case, which I understand as > using XFF to separate the reputation of different end-users > behind the same proxy. I was wondering if its only wikipedia > that does that or if its more generally done. I don't know about "more generally" but customers of mine have certainly = raised this use case but I've never dug into it to really understand = what they're using it for because our product enables XFF by default so = once I mention that they go off and implement their use case without = needing anything more from me. The difference with the wikipedia use case is that we build CDN products = which in the context of this thread equates to a high performance = reverse proxy which sits in front of our customers entire website, so = without XFF our customers lose total visibility of all client IPs, = compared to the forward proxy case where an origin server would only = lose visibility of the subset of IPs sat behind a particular forward = proxy. More generally and not specifically in response to your mail, FWIW there = are interoperability issues with XFF in the wild and I think publishing = this document as a standards track RFC is a good thing. Not publishing = it will not improve client privacy as proliferation of XFF will just = continue so we're better off having a document specifying the header and = discussing appropriate use(s) of it and how inappropriate use can lead = to unintended consequences such as privacy leakage etc. If the current = document does not do that adequately then lets wordsmith it so it does. Ben From hallam@gmail.com Wed Sep 5 17:37:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F354A21F8715 for ; Wed, 5 Sep 2012 17:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55vysKuvPvTx for ; Wed, 5 Sep 2012 17:37:09 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5805B21F86A8 for ; Wed, 5 Sep 2012 17:37:09 -0700 (PDT) Received: by obbta17 with SMTP id ta17so1640248obb.22 for ; Wed, 05 Sep 2012 17:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F50zGrhAzbbvlnT1JeMYtnrGuwxhAa+XOlqAogsspac=; b=rapRbeAUnytQd3SlRngv1UtYPlYM6IiGIE3yRoeYQppEoteztbVXO2LK2uYhDXYup6 Kv4wR44pj0agTcroF2lJNaM/UzaJGA6SlvqXdK18Jg5/IoJ9ZUraPr1QnUn8HFrBDPFC OkzsGb3lta8yjfFshkJAWS3gku+elaqgQ9YFKgXlwP362eoLJ10aa/GQ+Kkv+x/dXSJP vcAEAHcDKcTvSxCZUukYTQboyukqSdvZPv+JexbflTleug9l/Bw4saHdQPgTbathf3E0 YQVIjxqYq0JSLD3aIwLBE2VMDhT/BMtCzPV7jPpHdkhxVj6yX36g71W8hPcHKPMiS1kW 7OlA== MIME-Version: 1.0 Received: by 10.60.170.138 with SMTP id am10mr205125oec.115.1346891828463; Wed, 05 Sep 2012 17:37:08 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Wed, 5 Sep 2012 17:37:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Sep 2012 20:37:08 -0400 Message-ID: From: Phillip Hallam-Baker To: Francis Galiegue Content-Type: text/plain; charset=ISO-8859-1 Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 00:37:10 -0000 On Wed, Sep 5, 2012 at 7:58 PM, Francis Galiegue wrote: > On Thu, Sep 6, 2012 at 1:18 AM, Tim Bray wrote: > [...] > >> >> Sure, but I think Phillip was looking for a mapping into native data >> structures > > > Yes, and this is territory which JSON Schema must not venture into, > imho: JSON is, by virtue, a language-neutral standard, And we should > thank it for that ;) That is a non-sequetor, if there is a schema that makes any sense it should define a mapping that can be applied to any well specified language. -- Website: http://hallambaker.com/ From mmorley@mpcm.com Wed Sep 5 18:12:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BB421F8711 for ; Wed, 5 Sep 2012 18:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyFc-CcGNut6 for ; Wed, 5 Sep 2012 18:12:17 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id ADE2421F85C0 for ; Wed, 5 Sep 2012 18:12:16 -0700 (PDT) Received: by qafi29 with SMTP id i29so4688347qaf.10 for ; Wed, 05 Sep 2012 18:12:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=WlrkcCKqFlVkxnehzv2to8o+bETbT2wY/32pLoL0YU8=; b=hDy+QIKE9UFnZ35KhrpryZYFpMViEmZw0IIE7JJfMqVVm2OkSGVc3UE53kGcWfbbm8 ux8va+5n4NFiFwLOeqK5VDgEatN2pNjCBhDqV0B2VJgXxR1a0G3ggJn83QfFgG9mAhKn TZ+qmNLfc7B+dsnvSqxqIUTeUuVbBHwC/Sk+R9jNLD+U4Txb4q9/WN7s3yOq1NLjCeb0 ZlFgdvrV2r9XqjC+dgknPSMBvwEGkzvLefanaeRd4LoNxRSa2E9lr/8nSmWTTnl4NtL+ mFcXnREcfkAvPP0oGGh5ASd5o8vv/+h0nI46qexwvrZtQ+fVltzcpMaawV9gkW9YZwGH Y4Yw== MIME-Version: 1.0 Received: by 10.224.196.135 with SMTP id eg7mr1837557qab.24.1346893936112; Wed, 05 Sep 2012 18:12:16 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.49.30.66 with HTTP; Wed, 5 Sep 2012 18:12:16 -0700 (PDT) In-Reply-To: References: <1346890005.16601.45.camel@pbryan-wsl.internal.salesforce.com> Date: Wed, 5 Sep 2012 21:12:16 -0400 X-Google-Sender-Auth: PL20dVTjbhaoZyNvptM7AShoThQ Message-ID: From: Matthew Morley To: James M Snell Content-Type: multipart/alternative; boundary=20cf3005ddb09cb3b304c8fe2ee2 X-Gm-Message-State: ALoCoQkItNmnmAzazDCnCMPgNma9nvUKgpAXtie+hQPb4JUaXKNDgc1rp+3+e4u4jSoNecwfqWPR Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Json Patch Extended Operations - *Experimental* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 01:13:02 -0000 --20cf3005ddb09cb3b304c8fe2ee2 Content-Type: text/plain; charset=ISO-8859-1 I think that ultimately you will see something like what you posted appearing. But it will be more of a conditional wrapper applying json patches, not something that should live within the json patch structure (or specification). JSON Schema to define matches, JSON Patch to describe the changes, perhaps a conditional reasoning structure would help bind them all into a language agnostic data reasoning set? Joining the crowd late on the patch discussions, looking forward to reading through json patch tonight as I have some questions I need formulate and pose. I'm really partial to the dot notation, but slashes work. :) I developed a system in the past that heavily depended on self contained logic structures in json. It used a quirk rule engine to be very reactive to selective changes inside the object tree. Seeing json patch I now am wondering if I should have been generating that as the both the log and the tool of the change. The biggest value, I feel, in json patch is the ability to reference a deep path from a known point via a string. This provides a method of reasoning not just about the value at the end of a path, but to also use the path itself as an identity token. A system that uses "/a/b/c" to change a value, can also share the path/identity to other processes that want to then react to that change, possibly applying their own changes and triggering further changes. Relationships can be described using the shortest path to related fields, then the path strings appended until you can reason about huge sets of changes from a root point well above the original path itself. Not sure if others are doing work like this, it came about for me from the need to represent complex reactive data relationships in a language agnostic way, and in a very practical sense to implement uniform browser/server interactions. On Wed, Sep 5, 2012 at 8:11 PM, James M Snell wrote: > Indeed. It is definitely a slippery slope. At the very least, I think this > can demonstrate that *IF* (and it's a big if) an application needs > additional support for a broader range of test options, it can be > implemented in a way that is generally consistent with the existing > json-patch format -- and defined as an extension of json patch albeit with > a different media type. For now, then, I'll likely table this and chalk it > up as an interesting experiment until and unless there is more of a > demonstrated need. > > On Wed, Sep 5, 2012 at 5:06 PM, Paul C. Bryan wrote: > >> ** >> I agree that these additional constructs could come in handy under the >> right circumstances. That said, I see no way to bound the scope, because >> *any* addition could be deemed handy under the right circumstances. >> >> I wrestled initially with the consequences of adding the test operation >> when it was first suggested. My notable concern was that it could creep >> into more than just a simple equality test, perhaps even be pushed to >> qualify particular operations (as you're suggesting), and ultimately lead >> toward the need to sport a Turing-complete query syntax! Okay, that's going >> too far, but hopefully this illustrates the extent of my concern: slippery >> slope, in for a penny in for a pound, etc. >> >> The use case that drove the equality test for me was (quasi-) RESTful: >> there's a clear need to test equality of the partial state of a JSON >> document as a precondition of its modification. In the case of HTTP PATCH >> in particular, this presumes that the patch document is not being applied >> blindly. Your suggested extended operations definitely go beyond that >> scope. >> >> Paul >> >> >> On Wed, 2012-09-05 at 10:03 -0700, James M Snell wrote: >> >> I've recently been experimenting with the JSON Patch format in a variety >> of scenarios in order to gain some additional implementation experience. >> I've found that in a number of cases it can be useful to apply more >> additional types of test operations. I am considering writing these up as a >> separate I-D as an extension to Json-Patch but I'm not yet fully convinced >> that it's something that should be done; so I wanted to solicit some >> feedback from the group at large. >> >> >> >> In my experiments, I have toyed around with the following additional >> test operations: >> >> >> >> "not" -- aggregate test... all of the contained operations must >> evaluate to false.. must not contain change operations.. tests only >> >> "and" -- aggregate test... all of the contained operations must >> evaluate to true.. must not contain change operations.. tests only >> >> "or" -- aggregate test... any of the contained operations must >> evaluate to true.. must not contain change operations.. tests only >> >> "typeOf" -- tests to ensure that the referenced object is the >> specified type (using javascript typeof) >> >> "contains" -- does the toString value of the referenced object contain >> the specified value >> >> "startsWith"-- does the toString value of the referenced object start >> with the specified value >> >> "endsWith" -- does the toString value of the referenced object end with >> the specified value >> >> "matches" -- does the toString value of the referenced object match >> the given regular expression >> >> "lessThan" -- if the value is numeric or a date, returns true if node >> value is more than specified value >> >> "moreThan" -- if the value is numeric or a date, returns true if node >> value is more than specified value >> >> >> >> For example, consider the following hypothetical, extended json-patch >> >> >> >> [ >> >> { "and": [ >> >> { "not": [ >> >> {"moreThan", "/a/bar", "value": 123}, >> >> {"matches", "/a/baz", "/sample/ig"} >> >> ] >> >> }, >> >> {"contains": "/a/foo", "value": "123"}, >> >> {"typeOf": "/a/b/version", "value": "number"} >> >> ] >> >> }, >> >> {"add": "/a/b/c", "value": "foo"}, >> >> {"replace": "/a/b/version", value: 1} >> >> ] >> >> >> >> In this example, the change operations ("add" and "increment") are only >> applied if and only if: >> >> >> >> * The /a/b/version property exists and is a numeric value, >> >> * The /a/foo property contains the characters "123" in it's string >> representation, >> >> * The /a/baz property does not match the regular expression >> /sample/ig, and >> >> * The /a/bar property is numeric and is less than or equal to 123 >> >> >> >> Yes, this adds quite a bit more complexity and yes, it's not yet clear >> if this is something of value. I'm not arguing that we SHOULD do this, but >> in a variety of experiments such tests have demonstrated usefulness. >> >> >> >> Also, I was asked recently whether JSON-Patch could be made to apply >> changes over a set of properties within a document that match a given >> criteria. For example, consider the following source JSON document: >> >> >> >> { >> >> "items": [ >> >> { "actor": {"displayName": "James" }, >> >> "verb": "post", >> >> "object": {"objectType": "note", "content": "test 1" }}, >> >> { "actor": {"displayName": "Joe" }, >> >> "verb": "post", >> >> "object": {"objectType": "note", "content": "test 2" }}, >> >> { "actor": {"displayName": "Sally" }, >> >> "verb": "share", >> >> "updated": "2012-12-12T12:12:12Z", >> >> "object": {"objectType": "book", "id": "urn:foo:1" }}, >> >> ] >> >> } >> >> >> >> Suppose I wish to add a "published" property to all items that >> currently do not have one... I could accomplish this using a new extended >> "each" operation... >> >> >> >> [ >> >> { "each": "/items", >> >> "apply": [ >> >> {"not": [{"test":"/updated"}]}, >> >> {"add": "/updated", "value": "2012-12-12T12:12:12Z"} >> >> ] >> >> } >> >> ] >> >> >> >> This evaluates as: For each member of /items, test to see if the member >> has an updated property. If not, add it with the value >> "2012-12-12T12:12:12Z". If /items is a primitive, the "each" operation >> would fail as an error condition. If /items is an array, then each iterates >> over each member of the array. If /items is an object, each iterates over >> each of that's objects member properties. >> >> >> >> Note, however, that this differs quite a bit from the existing >> semantics of json-patch. For one, a negative test within the "apply" would >> not signal an error condition that would halt the entire patch operation. >> The negative test would simply mean that the modification for that >> particular element would not be applied. All of the changes within. >> >> >> >> Again, I'm not yet convinced this is a good idea but experimentation >> has demonstrated that it's at least a workable approach. I'd very much like >> to hear from others on whether or not this is something we should or should >> not attempt to pursue. >> >> >> >> Thoughts? >> >> >> >> - James >> >> >> >> >> >> _______________________________________________ >> apps-discuss mailing listapps-discuss@ietf.orghttps://www.ietf.org/mailman/listinfo/apps-discuss >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- Matthew P. C. Morley --20cf3005ddb09cb3b304c8fe2ee2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that ultimately you will see something like what you posted appeari= ng. But it will be more of a conditional wrapper applying json patches, not= something that should live within the json patch structure (or specificati= on).

JSON Schema to define matches, JSON Patch to describe the changes, perh= aps a conditional reasoning structure would help bind them all into a langu= age agnostic data reasoning set?

Joining the crowd late o= n the patch discussions, looking forward to reading through json patch toni= ght as I have some questions I need formulate and pose. I'm really part= ial to the dot notation, but slashes work. :)

I developed a system in the past that heavily depended = on self contained logic structures in json. It used a quirk rule engine to = be very reactive to selective changes inside the object tree. Seeing json p= atch I now am wondering if I should have been generating that as the both t= he log and the tool of the change.

The biggest value, I feel, in json patch is the ability to reference a = deep path from a known point via a string. This provides a method of reason= ing not just about the value at the end of a path, but to also use the path= itself as an identity token.

A system that uses "/a/b/c" to change a value= , can also share the path/identity to other processes that want to then rea= ct to that change, possibly applying their own changes and triggering furth= er changes. Relationships can be described using the shortest path to relat= ed fields, then the path strings appended until you can reason about huge s= ets of changes from a root point well above the original path itself.

Not sure if others are doing work like this, it came about for me from = the need to represent complex reactive data relationships in a language agn= ostic way, and in a very practical sense to implement uniform browser/serve= r interactions.

On Wed, Sep 5, 2012 at 8:11 PM, James M Snel= l <jasnell@gmail.com> wrote:
Indeed. It is definitely a slippery sl= ope. At the very least, I think this can demonstrate that *IF* (and it'= s a big if) an application needs additional support for a broader range of = test options, it can be implemented in a way that is generally consistent w= ith the existing json-patch format -- and defined as an extension of json p= atch albeit with a different media type. For now, then, I'll likely tab= le this and chalk it up as an interesting experiment until and unless there= is more of a demonstrated need.

On Wed, Sep 5, 2012 at 5:06 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
=20 =20
I agree that these additional constructs could come in handy under the righ= t circumstances. That said, I see no way to bound the scope, because any= addition could be deemed handy under the right circumstances.

I wrestled initially with the consequences of adding the test operation whe= n it was first suggested. My notable concern was that it could creep into m= ore than just a simple equality test, perhaps even be pushed to qualify par= ticular operations (as you're suggesting), and ultimately lead toward t= he need to sport a Turing-complete query syntax! Okay, that's going too= far, but hopefully this illustrates the extent of my concern: slippery slo= pe, in for a penny in for a pound, etc.

The use case that drove the equality test for me was (quasi-) RESTful: ther= e's a clear need to test equality of the partial state of a JSON docume= nt as a precondition of its modification. In the case of HTTP PATCH in part= icular, this presumes that the patch document is not being applied blindly.= Your suggested extended operations definitely go beyond that scope.

Paul


On Wed, 2012-09-05 at 10:03 -0700, James M Snell wrote:
I've recently been experimenting with the JSON Patch format in a va= riety of scenarios in order to gain some additional implementation experien= ce. I've found that in a number of cases it can be useful to apply more= additional types of test operations. I am considering writing these up as = a separate I-D as an extension to Json-Patch but I'm not yet fully conv= inced that it's something that should be done; so I wanted to solicit s= ome feedback from the group at large.


In my experiments, I have toyed around with the following additional te= st operations:


"not" =A0 =A0 =A0 -- aggregate test... all of the contained o= perations must evaluate to false.. must not contain change operations.. tes= ts only
"and" =A0 =A0 =A0 -- aggregate test... all of the contained o= perations must evaluate to true.. must not contain change operations.. test= s only
"or" =A0 =A0 =A0 =A0-- aggregate test... any of the contained= operations must evaluate to true.. must not contain change operations.. te= sts only
"typeOf" =A0 =A0-- tests to ensure that the referenced object= is the specified type (using javascript typeof)
"contains" =A0-- does the toString value of the referenced ob= ject contain the specified value
"startsWith"-- does the toString value of the referenced obje= ct start with the specified value
"endsWith" =A0-- does the toString value of the referenced ob= ject end with the specified value
"matches" =A0 -- does the toString value of the referenced ob= ject match the given regular expression
"lessThan" =A0-- if the value is numeric or a date, returns t= rue if node value is more than specified value
"moreThan" =A0-- if the value is numeric or a date, returns t= rue if node value is more than specified value


For example, consider the following hypothetical, extended json-patch


=A0 [
=A0 =A0 { "and": [
=A0 =A0 =A0 =A0 { "not": [
=A0 =A0 =A0 =A0 =A0 =A0 {"moreThan", "/a/bar", &quo= t;value": 123},
=A0 =A0 =A0 =A0 =A0 =A0 {"matches", "/a/baz", "= ;/sample/ig"}
=A0 =A0 =A0 =A0 =A0 ]
=A0 =A0 =A0 =A0 },
=A0 =A0 =A0 =A0 {"contains": "/a/foo", "value&= quot;: "123"},
=A0 =A0 =A0 =A0 {"typeOf": "/a/b/version", "va= lue": "number"}
=A0 =A0 =A0 ]
=A0 =A0 },
=A0 =A0 {"add": "/a/b/c", "value": "= foo"},
=A0 =A0 {"replace": "/a/b/version", value: 1}=A0
=A0 ]


In this example, the change operations ("add" and "incre= ment") are only applied if and only if:


=A0 * The /a/b/version property exists and is a numeric value,
=A0 * The /a/foo property contains the characters "123" in it= 's string representation,
=A0 * The /a/baz property does not match the regular expression /sample= /ig, and
=A0 * The /a/bar property is numeric and is less than or equal to 123


Yes, this adds quite a bit more complexity and yes, it's not yet cl= ear if this is something of value. I'm not arguing that we SHOULD do th= is, but in a variety of experiments such tests have demonstrated usefulness= .


Also, I was asked recently whether JSON-Patch could be made to apply ch= anges over a set of properties within a document that match a given criteri= a. For example, consider the following source JSON document:


=A0 {
=A0 =A0 "items": [
=A0 =A0 =A0 { "actor": {"displayName": "James&= quot; },
=A0 =A0 =A0 =A0 "verb": "post",
=A0 =A0 =A0 =A0 "object": {"objectType": "note= ", "content": "test 1" }},
=A0 =A0 =A0 { "actor": {"displayName": "Joe&qu= ot; },
=A0 =A0 =A0 =A0 "verb": "post",
=A0 =A0 =A0 =A0 "object": {"objectType": "note= ", "content": "test 2" }},
=A0 =A0 =A0 { "actor": {"displayName": "Sally&= quot; },
=A0 =A0 =A0 =A0 "verb": "share",
=A0 =A0 =A0 =A0 "updated": "2012-12-12T12:12:12Z",
=A0 =A0 =A0 =A0 "object": {"objectType": "book= ", "id": "urn:foo:1" }},
=A0 =A0 ]
=A0 }


Suppose I wish to add a "published" property to all items tha= t currently do not have one... I could accomplish this using a new extended= "each" operation...
=A0
=A0 [
=A0 =A0 { "each": "/items",=A0
=A0 =A0 =A0 "apply": [
=A0 =A0 =A0 =A0 {"not": [{"test":"/updated&quo= t;}]},
=A0 =A0 =A0 =A0 {"add": "/updated", "value&quo= t;: "2012-12-12T12:12:12Z"}
=A0 =A0 =A0 ]
=A0 =A0 }
=A0 ]


This evaluates as: For each member of /items, test to see if the member= has an updated property. If not, add it with the value "2012-12-12T12= :12:12Z". If /items is a primitive, the "each" operation wou= ld fail as an error condition. If /items is an array, then each iterates ov= er each member of the array. If /items is an object, each iterates over eac= h of that's objects member properties.=A0


Note, however, that this differs quite a bit from the existing semantic= s of json-patch. For one, a negative test within the "apply" woul= d not signal an error condition that would halt the entire patch operation.= The negative test would simply mean that the modification for that particu= lar element would not be applied. All of the changes within.


Again, I'm not yet convinced this is a good idea but experimentatio= n has demonstrated that it's at least a workable approach. I'd very= much like to hear from others on whether or not this is something we shoul= d or should not attempt to pursue.


Thoughts?


- James 




_______________________________________________
apps-discuss mailing list
apps-discuss@iet=
f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss




--
Matthew = P. C. Morley
--20cf3005ddb09cb3b304c8fe2ee2-- From alexey.melnikov@isode.com Thu Sep 6 02:27:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7F521F845D for ; Thu, 6 Sep 2012 02:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.607 X-Spam-Level: X-Spam-Status: No, score=-101.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cR8FRhIQUzlS for ; Thu, 6 Sep 2012 02:27:41 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 78CCF21F844A for ; Thu, 6 Sep 2012 02:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1346923660; d=isode.com; s=selector; i=@isode.com; bh=PLt+CXx9raLIQFNLzQ3CqRc7yt7vTKKGOiVZGnDEwjE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=YIcKwgD23HyQ0pW4YKvcKaCnTZgJX6ljCfZSLC1QFogGOwREFZy2MqoVYthUHoPEU2XO2i 4MjRu1A2+DFvQL64zmC3XGgLWHcTaiPoWE1WqdCYyEI6REY2FkXT2dvMZmdruQzZnBb+VU M1gFaeOlBwqNXDuQ0P3Wp3alBaEDIzM=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 6 Sep 2012 10:27:40 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <504776E5.2090705@isode.com> Date: Wed, 05 Sep 2012 16:59:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Hannes Tschofenig References: <20120831062013.GA27979@1wt.eu> <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831125237.3c978218@hetzer> <8A96C5EA-9E25-4918-880B-EFE42A66B590@gmx.net> In-Reply-To: <8A96C5EA-9E25-4918-880B-EFE42A66B590@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 09:27:42 -0000 On 03/09/2012 07:46, Hannes Tschofenig wrote: > Hi Andreas, > > On Aug 31, 2012, at 1:52 PM, Andreas Petersson wrote: >> On Fri, 31 Aug 2012 10:39:54 +0300 >> "Tschofenig, Hannes (NSN - FI/Espoo)" wrote: >> >>> Eliot, >>> >>> The reverse proxy story is a way to make this look good and we know it >>> will be used otherwise. >>> >>> I don't know why aren't acknowledging that there are privacy concerns as >>> well even if they are inconvenient for an engineer. Just adding fluffy >>> and warm text does not make these concerns go away. I think we are >>> cheating here. >>> >> Have you read the section "Privacy Considerations"? >> > The privacy consideration section to me reads as follows: "Yes, we have heard about privacy concerns. This technology has been deployed already. As such, nothing can be done anymore. Sorry." I think you just volunteered to help. From cabo@tzi.org Thu Sep 6 03:45:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF3521F861D for ; Thu, 6 Sep 2012 03:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvHB57wH0aaf for ; Thu, 6 Sep 2012 03:45:28 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A7B0A21F8587 for ; Thu, 6 Sep 2012 03:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q86AjHAL023011; Thu, 6 Sep 2012 12:45:18 +0200 (CEST) Received: from [192.168.217.105] (p54893AEF.dip.t-dialin.net [84.137.58.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8B5A4446; Thu, 6 Sep 2012 12:45:17 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <01OJWHSPET3Q0006TF@mauve.mrochek.com> Date: Thu, 6 Sep 2012 12:45:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <88B1FC3F-3847-44B1-AD36-15DB532BFF1E@tzi.org> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> <01OJWHSPET3Q0006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1486) Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 10:45:28 -0000 On Sep 6, 2012, at 00:38, Ned Freed wrote: > Use of obfuscation techniques are appropriate when a need exists to = be > able to track connections back to the client only in some cases and = only > with the cooperation of the proxy operator. In the wikipedia use case, obfuscation (in the sense of IP address = anonymization) would also be appropriate, but neither leg of the = predicate behind the "when" evaluates to true. Gr=FC=DFe, Carsten From acooper@cdt.org Thu Sep 6 07:10:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87B521F8646 for ; Thu, 6 Sep 2012 07:10:41 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2O+gSoxi8br for ; Thu, 6 Sep 2012 07:10:41 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id F289E21F8622 for ; Thu, 6 Sep 2012 07:10:40 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for apps-discuss@ietf.org; Thu, 6 Sep 2012 10:10:39 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Alissa Cooper In-Reply-To: <88B1FC3F-3847-44B1-AD36-15DB532BFF1E@tzi.org> Date: Thu, 6 Sep 2012 10:10:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3F602497-A028-4AF2-BC70-E2A6C52E1670@cdt.org> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> <01OJWHSPET3Q0006TF@mauve.mrochek.com> <88B1FC3F-3847-44B1-AD36-15DB532BFF1E@tzi.org> To: Apps Discuss X-Mailer: Apple Mail (2.1084) Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:10:41 -0000 I'm looking forward to Andreas' draft update, but wanted to share some = thoughts in the meantime. There have been claims of interoperability problems with XFF in the = wild. If there is indeed an interoperability problem to be solved, = attempting to do so in a standards track RFC is often a good option. = However, if such a standard were to be produced, successfully overcoming = the interoperability challenge will require changes to deployed code. = Therefore, there aren't strong reasons (or at least I haven't seen them = articulated) for having the RFC track as closely as possible to the way = XFF already works -- otherwise there would be no point in standardizing, = because no one would have to change anything that's already out there. This means that, assuming work towards an RFC continues, there is an = opportunity to design a solution (or several) that attempts to meet the = requirements of current consumers of XFF, but in a better and more = privacy-friendly way that XFF does. Assuming that there is an actual = interoperability problem and that XFF use will continue regardless of = what happens with Forwarded, the standardization process seems like an = opportunity to replace what is already out there with something better. The use cases for XFF that have been mentioned on the list thus far (as = summarized by Stephen) are: =20 - logging - access control - rate limits - dealing with wrongly localized pages - requests you get for end user identity from law enforcement - IP-based lockout along the lines Wikipedia use Each of these uses has different requirements for what kind of = information needs to be present in the header, how unique it needs to = be, and how permanent it needs to be. A privacy-oriented design process = would start by asking which uses can be fulfilled with the least = identifiable, unique, and permanent information made available, and work = backward from there to begin making exceptions for sharing more = identifiable, unique, or permanent identifiers. Probably some uses will = require client IP address, but that's not a good reason to standardize a = header that will always be used to share client IP even when it's not = necessary. The draft would be a good place to recommend against such = behavior. The above analysis is likely much more difficult to conceptualize in the = forward proxy case than in the reverse proxy case, but it's at least = worth trying. Alissa From scott@kitterman.com Thu Sep 6 07:14:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BA921F8668 for ; Thu, 6 Sep 2012 07:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uC26M8st56Zg for ; Thu, 6 Sep 2012 07:14:53 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 00B9321F8646 for ; Thu, 6 Sep 2012 07:14:45 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0CC4520E4104; Thu, 6 Sep 2012 10:14:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346940885; bh=paxX9JA0gv51CiVFyOTz/upI631zQ0OVP+n5Z/PNqDU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cDDXrL3VMW/GLi1cjYNM/stZ2GcH37ExxybVPswSJ/wn/jqArSCSnqGheQ1tTUYBh lPq9EOEhJNaDqLuRLVyhXMrLBlMXMozfzJWbOMjci0lkiQRMuCKFizL3ADpTY9ZW8U 8xyMuENlzsdlLEpCVp8OGgr6ECsjtbf0q+mRbD6Q= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D5CD620E40E8; Thu, 6 Sep 2012 10:14:44 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org Date: Thu, 06 Sep 2012 10:14:44 -0400 Message-ID: <3028831.YLBPitRtZz@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <3F602497-A028-4AF2-BC70-E2A6C52E1670@cdt.org> References: <504068F3.6090601@cisco.com> <88B1FC3F-3847-44B1-AD36-15DB532BFF1E@tzi.org> <3F602497-A028-4AF2-BC70-E2A6C52E1670@cdt.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:14:54 -0000 On Thursday, September 06, 2012 10:10:38 AM Alissa Cooper wrote: ... > There have been claims of interoperability problems with XFF in the wild. If > there is indeed an interoperability problem to be solved, attempting to do > so in a standards track RFC is often a good option. However, if such a > standard were to be produced, successfully overcoming the interoperability > challenge will require changes to deployed code. Therefore, there aren't > strong reasons (or at least I haven't seen them articulated) for having the > RFC track as closely as possible to the way XFF already works -- otherwise > there would be no point in standardizing, because no one would have to > change anything that's already out there. ... To flip that around, it sounds like you are saying the only point in standardizing things is to cause changes in deployed code. Surely that's not right? Scott K From acooper@cdt.org Thu Sep 6 07:55:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252D121F869F for ; Thu, 6 Sep 2012 07:55:56 -0700 (PDT) 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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEGGlSpUB6tX for ; Thu, 6 Sep 2012 07:55:55 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 4A62221F868A for ; Thu, 6 Sep 2012 07:55:55 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 6 Sep 2012 10:55:53 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <3028831.YLBPitRtZz@scott-latitude-e6320> Date: Thu, 6 Sep 2012 10:55:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <504068F3.6090601@cisco.com> <88B1FC3F-3847-44B1-AD36-15DB532BFF1E@tzi.org> <3F602497-A028-4AF2-BC70-E2A6C52E1670@cdt.org> <3028831.YLBPitRtZz@scott-latitude-e6320> To: Scott Kitterman X-Mailer: Apple Mail (2.1084) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:55:56 -0000 On Sep 6, 2012, at 10:14 AM, Scott Kitterman wrote: > On Thursday, September 06, 2012 10:10:38 AM Alissa Cooper wrote: > ... >> There have been claims of interoperability problems with XFF in the = wild. If >> there is indeed an interoperability problem to be solved, attempting = to do >> so in a standards track RFC is often a good option. However, if such = a >> standard were to be produced, successfully overcoming the = interoperability >> challenge will require changes to deployed code. Therefore, there = aren't >> strong reasons (or at least I haven't seen them articulated) for = having the >> RFC track as closely as possible to the way XFF already works -- = otherwise >> there would be no point in standardizing, because no one would have = to >> change anything that's already out there. > ... >=20 > To flip that around, it sounds like you are saying the only point in=20= > standardizing things is to cause changes in deployed code. Surely = that's not=20 > right? No, in the abstract there can be plenty of reasons to standardize = something. The reason given in this thread seems to be that different = implementations of XFF are not interoperable. If people want to solve = that problem, some of those implementations will have to change. If they = don't, the interoperability problems will not go away. To be clear, I haven't seen the interoperability problems with XFF = specifically described and I don't know what they are or if they = actually exist. Alissa >=20 > Scott K > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From ned.freed@mrochek.com Thu Sep 6 08:27:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7F521F86DF for ; Thu, 6 Sep 2012 08:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyTZ2CVT64UH for ; Thu, 6 Sep 2012 08:27:36 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8D78621F866A for ; Thu, 6 Sep 2012 08:27:34 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJXGAMB9R40089UA@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 6 Sep 2012 08:22:20 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Thu, 6 Sep 2012 08:22:18 -0700 (PDT) Message-id: <01OJXGAKV3CW0006TF@mauve.mrochek.com> Date: Thu, 06 Sep 2012 08:21:34 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 06 Sep 2012 12:45:17 +0200" <88B1FC3F-3847-44B1-AD36-15DB532BFF1E@tzi.org> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> <01OJWHSPET3Q0006TF@mauve.mrochek.com> <88B1FC3F-3847-44B1-AD36-15DB532BFF1E@tzi.org> To: Carsten Bormann Cc: Ned Freed , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:27:37 -0000 > On Sep 6, 2012, at 00:38, Ned Freed wrote: > > Use of obfuscation techniques are appropriate when a need exists to be > > able to track connections back to the client only in some cases and only > > with the cooperation of the proxy operator. > In the wikipedia use case, obfuscation (in the sense of IP address anonymization) would also be appropriate, but neither leg of the predicate behind the "when" evaluates to true. Feel free to suggest text. Ned From john-ietf@jck.com Thu Sep 6 09:10:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC9D21F86D5 for ; Thu, 6 Sep 2012 09:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Qi8upZBRtRV for ; Thu, 6 Sep 2012 09:10:41 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 22A2F21F86CF for ; Thu, 6 Sep 2012 09:10:41 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1T9ef9-000Pf7-UJ; Thu, 06 Sep 2012 12:10:39 -0400 Date: Thu, 06 Sep 2012 12:10:34 -0400 From: John C Klensin To: Alissa Cooper , Apps Discuss Message-ID: <3E42CB5B6826E54EB4ED8380@JcK-HP8200.jck.com> In-Reply-To: <3F602497-A028-4AF2-BC70-E2A6C52E1670@cdt.org> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> <01OJWHSPET3Q0006TF@mauve.mrochek.com> <88B1FC3F-3847-44B1-AD36-15DB532BFF1E@tzi.org> <3F602497-A028-4AF2-BC70-E2A6C52E1670@cdt.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 16:10:41 -0000 Alissa, One observation on a very specific part of your comment, which I think may be critical... --On Thursday, September 06, 2012 10:10 -0400 Alissa Cooper wrote: >... > Assuming that there is an actual interoperability problem and > that XFF use will continue regardless of what happens with > Forwarded, the standardization process seems like an > opportunity to replace what is already out there with > something better. If "XFF use will continue regardless of what happens with Forwarded" then the standardization process is largely irrelevant unless there is a clear commitment to change a significant fraction of those non-interoperable implementations to match the standard. That is true whether we make one of the existing implementations the standard (presumably the "least bad" one on whatever scale that is evaluated) or whether we do something new and improved. Note that a "something better" replacement is substantially guaranteed to be be non-interoperable with the installed base. I think it is a fair summary of our general experience that such replacement is likely to be deployed in the marketplace and widely accepted only if it hugely better and/or it fills a need that almost all users of existing methods are feeling and feel is very pressing. That could change if there were general consensus that one of the versions is better than the others (i.e., that there was reason to believe the others would adapt to it if it were standardized) or that the interoperability problems were causing so much trauma that there was demand for a replacement with "something IETF-approved" or "something new". I haven't read every work of every message on this thread, but I haven't seen a strong case made for either of those positions or strong commitments to them. Standardization may still be worthwhile if it provides a target for new implementations and an excuse to get the facilities, the issues, and the points of non-interoperability documented. The subset of that role which is just to document what is going on and what the issues are could be served as well by an Informational document. But let's be careful about assuming that "something better" will take off merely because there are interoperability problems with existing (and likely continuing) practices (if, in fact, that is the case). best, john From andreas@sbin.se Thu Sep 6 09:31:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7AC21F86F9 for ; Thu, 6 Sep 2012 09:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+fCQATXETJF for ; Thu, 6 Sep 2012 09:31:02 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id B1D1C21F86C9 for ; Thu, 6 Sep 2012 09:31:00 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q86GUe0X000630; Thu, 6 Sep 2012 16:30:40 GMT Date: Thu, 6 Sep 2012 18:30:34 +0200 From: Andreas Petersson To: Alissa Cooper Message-ID: <20120906183034.1213fde5@hetzer> In-Reply-To: <3F602497-A028-4AF2-BC70-E2A6C52E1670@cdt.org> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> <01OJWHSPET3Q0006TF@mauve.mrochek.com> <88B1FC3F-3847-44B1-AD36-15DB532BFF1E@tzi.org> <3F602497-A028-4AF2-BC70-E2A6C52E1670@cdt.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/+wr9vUgtORN97jR7P0yp3HY"; protocol="application/pgp-signature" Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 16:31:03 -0000 --Sig_/+wr9vUgtORN97jR7P0yp3HY Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 6 Sep 2012 10:10:38 -0400 Alissa Cooper wrote: > I'm looking forward to Andreas' draft update, but wanted to share some th= oughts in the meantime. It is already submitted. One thing I forgot to add was to encouraging this feature to be off by default, that will be added in the next revision. > There have been claims of interoperability problems with XFF in the wild.= If there is indeed an interoperability problem to be solved, attempting to= do so in a standards track RFC is often a good option. However, if such a = standard were to be produced, successfully overcoming the interoperability = challenge will require changes to deployed code. Therefore, there aren't st= rong reasons (or at least I haven't seen them articulated) for having the R= FC track as closely as possible to the way XFF already works -- otherwise t= here would be no point in standardizing, because no one would have to chang= e anything that's already out there. >=20 > This means that, assuming work towards an RFC continues, there is an oppo= rtunity to design a solution (or several) that attempts to meet the require= ments of current consumers of XFF, but in a better and more privacy-friendl= y way that XFF does. Assuming that there is an actual interoperability prob= lem and that XFF use will continue regardless of what happens with Forwarde= d, the standardization process seems like an opportunity to replace what is= already out there with something better. >=20 > The use cases for XFF that have been mentioned on the list thus far (as s= ummarized by Stephen) are: =20 >=20 > - logging > - access control > - rate limits > - dealing with wrongly localized pages > - requests you get for end user identity from law enforcement > - IP-based lockout along the lines Wikipedia use >=20 > Each of these uses has different requirements for what kind of informatio= n needs to be present in the header, how unique it needs to be, and how per= manent it needs to be. A privacy-oriented design process would start by ask= ing which uses can be fulfilled with the least identifiable, unique, and pe= rmanent information made available, and work backward from there to begin m= aking exceptions for sharing more identifiable, unique, or permanent identi= fiers. Probably some uses will require client IP address, but that's not a = good reason to standardize a header that will always be used to share clien= t IP even when it's not necessary. The draft would be a good place to recom= mend against such behavior. >=20 > The above analysis is likely much more difficult to conceptualize in the = forward proxy case than in the reverse proxy case, but it's at least worth = trying. >=20 > Alissa We believe that if the new header field is too far away from XFF it will not be used to solve the problems that arise when the client source IP address is unavailable. A change in semantics will require a redesign of all involved components, while a change in syntax requires a parser code patch. Best regards, /Andreas --Sig_/+wr9vUgtORN97jR7P0yp3HY Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJQSM+qAAoJEEaYRbQUWNlevtQP/AlE+STCVNrgTIoWdjplhKvi 1kxAhNZnkH4REvGrSH+kwCPw3ouIrHuaIHLY33IwqUVdOQ/2vF5m7xjF7JagUOx7 k0MmX8ljWyh+HnfCIfmGgHFInIexnlS4fQ50f5zg7B1xFhvXuommqCr5J5OalpHL dgto0vvxy4UbCTxERclczZPG9hixAiAu2ERya7h71l5189lj4cghdLtobCP8JaNJ 198adJk1Qr67UKgHL3sbkj/brwkSeNmgE4WSJ6HZWedvFgyalzhK7pmSsVTZKuMj PX/DdRF2fnJ4SxxSaEKdPZmod4NjE9ppcMBkbTWgkjnSp1fXoo6ksZ5axVrnFvmv RBi2JU2+68og2NE5dCidC1qoDM1PKurrAewxwr0LiiOCwheseicaEQoma7bCk+3i wAhnOsm5afiLUgkJMYpCZBHtRkZajXLY2baOsnZKtZHEbT7Cs3N3HfFGXEP/2+jb yHNmg/WuYApw2qYftiho8FyPy27QszxOnqx9eWHSjQUANRicU87a44ZZZb6tSwGi 8WIRZ3Q0SsXea/JqwlUmadPWi+rfiGAmzN2dtPPO/dpI3+QIrKJhKy2HjVEiA78P jrkcYuOo5mC4hOKde4IAGvadhRo+7xUmpEVcOvRXXbIECRibJVGFgZI33gtK3x+0 dNfAxjfVQpmnSIGTAHWa =RmAy -----END PGP SIGNATURE----- --Sig_/+wr9vUgtORN97jR7P0yp3HY-- From andreas@sbin.se Thu Sep 6 09:40:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4C421F86FF for ; Thu, 6 Sep 2012 09:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQR4xIiu4KRW for ; Thu, 6 Sep 2012 09:40:42 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id F2C1221F86EB for ; Thu, 6 Sep 2012 09:40:41 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q86GeL1E003550; Thu, 6 Sep 2012 16:40:21 GMT Date: Thu, 6 Sep 2012 18:40:20 +0200 From: Andreas Petersson To: Alissa Cooper Message-ID: <20120906184020.7a5f03b0@hetzer> In-Reply-To: References: <504068F3.6090601@cisco.com> <88B1FC3F-3847-44B1-AD36-15DB532BFF1E@tzi.org> <3F602497-A028-4AF2-BC70-E2A6C52E1670@cdt.org> <3028831.YLBPitRtZz@scott-latitude-e6320> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Scott Kitterman , apps-discuss@ietf.org Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 16:40:43 -0000 On Thu, 6 Sep 2012 10:55:50 -0400 Alissa Cooper wrote: > On Sep 6, 2012, at 10:14 AM, Scott Kitterman wrote: > > > On Thursday, September 06, 2012 10:10:38 AM Alissa Cooper wrote: > > ... > >> There have been claims of interoperability problems with XFF in the wild. If > >> there is indeed an interoperability problem to be solved, attempting to do > >> so in a standards track RFC is often a good option. However, if such a > >> standard were to be produced, successfully overcoming the interoperability > >> challenge will require changes to deployed code. Therefore, there aren't > >> strong reasons (or at least I haven't seen them articulated) for having the > >> RFC track as closely as possible to the way XFF already works -- otherwise > >> there would be no point in standardizing, because no one would have to > >> change anything that's already out there. > > ... > > > > To flip that around, it sounds like you are saying the only point in > > standardizing things is to cause changes in deployed code. Surely that's not > > right? > > No, in the abstract there can be plenty of reasons to standardize something. The reason given in this thread seems to be that different implementations of XFF are not interoperable. If people want to solve that problem, some of those implementations will have to change. If they don't, the interoperability problems will not go away. > > To be clear, I haven't seen the interoperability problems with XFF specifically described and I don't know what they are or if they actually exist. > Some examples of interoperability issues would be: * IPv6 format * Wrong order, or simply not being aware that the XFF can contain a list of tokens * Synchronization between different X-Forwarded-* header fields. I do believe that this draft addresses these issues. I also think that the initial discussions on the http-mailing list involved enough proxy- and http-people to ensure that it solves these issues in a reasonable way. Best regards, Andreas From ned.freed@mrochek.com Thu Sep 6 14:35:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21E221F8745 for ; Thu, 6 Sep 2012 14:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw3Bg-Jn57z3 for ; Thu, 6 Sep 2012 14:35:35 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4B07C21F8716 for ; Thu, 6 Sep 2012 14:35:35 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJXT4ZV3B40083IA@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 6 Sep 2012 14:30:25 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Thu, 6 Sep 2012 14:30:23 -0700 (PDT) Message-id: <01OJXT4YWFDO0006TF@mauve.mrochek.com> Date: Thu, 06 Sep 2012 14:05:44 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 06 Sep 2012 12:10:34 -0400" <3E42CB5B6826E54EB4ED8380@JcK-HP8200.jck.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> <01OJWHSPET3Q0006TF@mauve.mrochek.com> <88B1FC3F-3847-44B1-AD36-15DB532BFF1E@tzi.org> <3F602497-A028-4AF2-BC70-E2A6C52E1670@cdt.org> <3E42CB5B6826E54EB4ED8380@JcK-HP8200.jck.com> To: John C Klensin Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 21:35:36 -0000 > Alissa, > One observation on a very specific part of your comment, which I > think may be critical... > --On Thursday, September 06, 2012 10:10 -0400 Alissa Cooper > wrote: > >... > > Assuming that there is an actual interoperability problem and > > that XFF use will continue regardless of what happens with > > Forwarded, the standardization process seems like an > > opportunity to replace what is already out there with > > something better. > If "XFF use will continue regardless of what happens with > Forwarded" > then > the standardization process is largely irrelevant unless there > is a clear commitment to change a significant fraction of those > non-interoperable implementations to match the standard. That > is true whether we make one of the existing implementations the > standard (presumably the "least bad" one on whatever scale that > is evaluated) or whether we do something new and improved. I really don't think you mean this because by this rule, MIME would have been standardized. (At the time there were at least five deployed systems for multimedia mail and not only was there no commitment to change from any of them, there was significant opposition to it. At least two of those are still in use today, as a matter of fact.) > Note that a "something better" replacement is substantially > guaranteed to be be non-interoperable with the installed base. > I think it is a fair summary of our general experience that such > replacement is likely to be deployed in the marketplace and > widely accepted only if it hugely better and/or it fills a need > that almost all users of existing methods are feeling and feel > is very pressing. Forwarded: definitely offers capabilities XFF does not have. Are those plus the promise of better interoperability enough to cause adoption? I have no idea. I personally would have preferred a specification that just standardized XFF. But the consensus went the other way, and one of the things I try to avoid is second guessing such decisions. > That could change if there were general consensus that one of > the versions is better than the others (i.e., that there was > reason to believe the others would adapt to it if it were > standardized) or that the interoperability problems were causing > so much trauma that there was demand for a replacement with > "something IETF-approved" or "something new". I haven't read > every work of every message on this thread, but I haven't seen a > strong case made for either of those positions or strong > commitments to them. Well, if we're going to go by past experience, I'll just point out that the predictive capability of IETFers engaging in such discussions is highly questionable. So if you're looking for assurances as to the future, I think tea leaves provide a better alternative: At least with them you get a nice cup of tea out of the deal. > Standardization may still be worthwhile if it provides a target > for new implementations and an excuse to get the facilities, the > issues, and the points of non-interoperability documented. The > subset of that role which is just to document what is going on > and what the issues are could be served as well by an > Informational document. But let's be careful about assuming > that "something better" will take off merely because there are > interoperability problems with existing (and likely continuing) > practices (if, in fact, that is the case). On this we agree. But I'll also note that another thing having a standard will do is instruct people as to both the utility and the risks of such mechanisms. Ned From wwwrun@rfc-editor.org Thu Sep 6 14:39:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581EA21F876A for ; Thu, 6 Sep 2012 14:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.341 X-Spam-Level: X-Spam-Status: No, score=-102.341 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jyY8ZsFjUcb for ; Thu, 6 Sep 2012 14:39:35 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E02A221F8745 for ; Thu, 6 Sep 2012 14:39:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B6957B1E002; Thu, 6 Sep 2012 14:36:46 -0700 (PDT) To: dcrocker@bbiw.net, superuser@gmail.com, barryleiba@computer.org, presnick@qualcomm.com, superuser@gmail.com, Salvatore.Loreto@ericsson.com From: RFC Errata System Message-Id: <20120906213646.B6957B1E002@rfc-editor.org> Date: Thu, 6 Sep 2012 14:36:46 -0700 (PDT) Cc: d.stussy@yahoo.com, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Technical Errata Reported] RFC6729 (3337) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 21:39:36 -0000 The following errata report has been submitted for RFC6729, "Indicating Email Handling States in Trace Fields". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6729&eid=3337 -------------------------------------- Type: Technical Reported by: D. Stussy Section: 3 Original Text ------------- In Section 6, the "state" clause is added to the Additional- Registered-Clauses IANA sub-registry. The ABNF for this clause is: State = CFWS "state" FWS queue-state-keyword [ "/" value ] ... Corrected Text -------------- Notes ----- Clarification needed: Does this "state" clause keyword place before, after, or in either order with the "priority" clause keyword specified in RFC 6710? RFC 5321 does not specify an order for additional "Received:" header clauses defined after its publication. The order of additional clauses may need to be defined for proper parsing to determine validity of messages for spam classification or determination of other subversive purposes (as invalid values may indicate bad messages). (See also the note filed in errata #1 filed for RFC 6710.) 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. -------------------------------------- RFC6729 (draft-ietf-appsawg-received-state-04) -------------------------------------- Title : Indicating Email Handling States in Trace Fields Publication Date : September 2012 Author(s) : D. Crocker, M. Kucherawy Category : PROPOSED STANDARD Source : Applications Area Working Group Area : Applications Stream : IETF Verifying Party : IESG From john-ietf@jck.com Thu Sep 6 15:14:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F67A21F86DD for ; Thu, 6 Sep 2012 15:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Scd8Zo2RZEX3 for ; Thu, 6 Sep 2012 15:14:30 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 54EE621F86DB for ; Thu, 6 Sep 2012 15:14:02 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1T9kKg-0000gu-06; Thu, 06 Sep 2012 18:13:54 -0400 Date: Thu, 06 Sep 2012 18:13:48 -0400 From: John C Klensin To: Ned Freed Message-ID: <4E9E4E976759E6BD2F8B1D04@JcK-HP8200.jck.com> In-Reply-To: <01OJXT4YWFDO0006TF@mauve.mrochek.com> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> <01OJWHSPET3Q0006TF@mauve.mrochek.com> <88B1FC3F-3847-44B1-AD36-15DB532BFF1E@tzi.org> <3F602497-A028-4AF2-BC70-E2A6C52E1670@cdt.org> <3E42CB5B6826E54EB4ED8380@JcK-HP8200.jck.com> <01OJXT4YWFDO0006TF@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 22:14:31 -0000 --On Thursday, September 06, 2012 14:05 -0700 Ned Freed wrote: >> If "XFF use will continue regardless of what happens with >> Forwarded" > >> then > >> the standardization process is largely irrelevant unless there >> is a clear commitment to change a significant fraction of >> those non-interoperable implementations to match the >> standard. That is true whether we make one of the existing >> implementations the standard (presumably the "least bad" one >> on whatever scale that is evaluated) or whether we do >> something new and improved. > > I really don't think you mean this because by this rule, MIME > would have been standardized. (At the time there were at least > five deployed systems for multimedia mail and not only was > there no commitment to change from any of them, there was > significant opposition to it. At least two of those are still > in use today, as a matter of fact.) I assume you meant "not been standardized". The difference is that, at the time MIME was done, there was significant perception of a need for an improved multimedia mail (and non-ASCII mail) model and a similarly strong perception that the existing/ deployed systems weren't up to the job as others saw it. That perception certainly wasn't universal, nor was there universal agreement that MIME was the right approach. As you say, some of the predecessor systems are still in use. But there was a sufficient perception of need to result in careful consideration of the MIME approach and its fairly broad adoption. I haven't seen that level of perceived need with the proposals that are now coming out. Perhaps it is there and I've just lost it in the noise. What I have seen (and I'm not accusing Alissa of this) is a lot of concerns and complaints about functionality that is not present (especially with regard to privacy protection) without either a clear explanation of why what people are trying to use "forwarded" for isn't necessary. That would be ok except that it is not clear to me that we have a way to provide solid privacy protection other than "if you are worried about privacy, or need to consider this capability in a privacy-sensitive environment, don't use this". That may be a fine answer, but, if it is the acceptable one, we should get a statement about it into the document and move on. What I'm objecting to -- and I may still not be saying this very well-- is any belief that, if there are interoperability problems now, either -- An IETF choice of one set of options over another without a really strong rationale as to why that is superior to other choices or -- A completely new IETF solution that is still recognizably similar to the existing approaches can be counted on to automagically be adopted and take off. I'd expect a good deal of reactions along the lines of "why should we bother with that when it requires changes to our installed base and doesn't provide significant additional functionality". For MIME, we had an answer to that question (actually, several separate ones -- there was significant additional functionality). A better example, sadly, has been IPv6 and the long uphill struggle to get it adopted and widely deployed. >> Note that a "something better" replacement is substantially >> guaranteed to be be non-interoperable with the installed base. >> I think it is a fair summary of our general experience that >> such replacement is likely to be deployed in the marketplace >> and widely accepted only if it hugely better and/or it fills >> a need that almost all users of existing methods are feeling >> and feel is very pressing. > > Forwarded: definitely offers capabilities XFF does not have. > Are those plus the promise of better interoperability enough > to cause adoption? I have no idea. I don't either. All I am trying to do is to encourage people to ask that question clearly and with a maximum of objectivity and minimum of passion. And also I'm questioning whether the IETF has heard demand for this beyond "we know how to make it better, therefore we should". I definitely do not know the answer to that question either, but I'm hoping that there are some clear answers out there. > I personally would have preferred a specification that just > standardized XFF. But the consensus went the other way, and > one of the things I try to avoid is second guessing such > decisions. Agreed. But I think we should be clear-headed about what we are getting into. >> That could change if there were general consensus that one of >> the versions is better than the others (i.e., that there was >> reason to believe the others would adapt to it if it were >> standardized) or that the interoperability problems were >> causing so much trauma that there was demand for a >> replacement with "something IETF-approved" or "something >> new". I haven't read every work of every message on this >> thread, but I haven't seen a strong case made for either of >> those positions or strong commitments to them. > > Well, if we're going to go by past experience, I'll just point > out that the predictive capability of IETFers engaging in such > discussions is highly questionable. So if you're looking for > assurances as to the future, I think tea leaves provide a > better alternative: At least with them you get a nice cup of > tea out of the deal. No disagreement other than to again point out that we've had much better success deploying protocols that fill a gap (whether recognized at the time or not) than we have with protocols that try to replace existing ones by making a small incremental but incompatible change. That is _not_ a prediction about any particular case and there are certainly exceptions to the general pattern. But it is a pattern of which I think we should be aware. >> Standardization may still be worthwhile if it provides a >> target for new implementations and an excuse to get the >> facilities, the issues, and the points of >> non-interoperability documented. The subset of that role >> which is just to document what is going on and what the >> issues are could be served as well by an Informational >> document. But let's be careful about assuming that >> "something better" will take off merely because there are >> interoperability problems with existing (and likely >> continuing) practices (if, in fact, that is the case). > > On this we agree. But I'll also note that another thing having > a standard will do is instruct people as to both the utility > and the risks of such mechanisms. And that is why I definitely favor publishing something in this area, something that addresses those topics in a clear and fair way. I prefer that it be done with a standard and would prefer that even if we somehow knew in advance that the standard would not deploy. But if we can't get agreement on a standard, I strongly favor an Informational document that describes the status quo, utility, and risks so that the knowledge doesn't get lost. john From ned.freed@mrochek.com Thu Sep 6 16:26:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCF721F8674 for ; Thu, 6 Sep 2012 16:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuLgAV549kx2 for ; Thu, 6 Sep 2012 16:26:20 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF3821F8672 for ; Thu, 6 Sep 2012 16:26:20 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJXX0FX8WG0070LX@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 6 Sep 2012 16:21:17 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Thu, 6 Sep 2012 16:21:15 -0700 (PDT) Message-id: <01OJXX0EPZ400006TF@mauve.mrochek.com> Date: Thu, 06 Sep 2012 15:52:11 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 06 Sep 2012 14:36:46 -0700 (PDT)" <20120906213646.B6957B1E002@rfc-editor.org> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120906213646.B6957B1E002@rfc-editor.org> To: RFC Errata System Cc: apps-discuss@ietf.org, dcrocker@bbiw.net, presnick@qualcomm.com, d.stussy@yahoo.com, barryleiba@computer.org, rfc-editor@rfc-editor.org Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6729 (3337) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 23:26:20 -0000 I strongly disagree that this is in any way, shape, or form an appropriate errata for RFC 6729 and I believe it should be rejected outright. RFC 5321 neither requires any ordering nor attaches any significance to the ordering of additional Received: field clauses. To change that would require updating RFC 5321 itself, and that in turn would require figuring out some ordering scheme that works across future registrations. > The following errata report has been submitted for RFC6729, > "Indicating Email Handling States in Trace Fields". > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6729&eid=3337 > -------------------------------------- > Type: Technical > Reported by: D. Stussy > Section: 3 > Original Text > ------------- > In Section 6, the "state" clause is added to the Additional- > Registered-Clauses IANA sub-registry. The ABNF for this clause is: > State = CFWS "state" FWS queue-state-keyword [ "/" value ] > ... > Corrected Text > -------------- > Notes > ----- > Clarification needed: Does this "state" clause keyword place > before, after, or in either order with the "priority" clause keyword specified > in RFC 6710? What semantics would attach to such an ordering anyway? That's the only reason I can concieve of for requiring an ordering of these clauses. > RFC 5321 does not specify an order for additional "Received:" > header clauses defined after its publication. Exactly. > The order of additional clauses > may need to be defined for proper parsing If that's indeed the case then it's a flaw in RFC 5321 and would have to be corrected there. Consider: Since the list of additional clauses can be amended at any time, software that intends to parse these clauses has to be able to accomodate previously unknown clauses. Moreoever, knowing the relative ordering of the clauses your software is written to understand doesn't help you at all with unknown clauses. However, this can be seen to be a nonissue simply by looking at the definition in RFC 5321: Additional-Registered-Clauses = CFWS Atom FWS String So additional clauses always consists of either a pair of atoms or an atom following by a quoted string. No other syntaxes are allowed and this is trivially easy to parse. > to determine validity of messages for > spam classification or determination of other subversive purposes (as invalid > values may indicate bad messages). First, while it is true that agency may sometimes be inferred indirectly through syntax use, both legal and illegal, this is *lightyears* away from anything that we should be standardizing. The slope here is perilous in the extreme and in many cases we're already sliding down it: It is not at all uncommon for perfectly legal messages to be rejected by overzealous antispam software simply because they employed some bit of syntax that's commonly associated with some spam agent or other. The last thing we want to do is specify some ordering requirement that could be amended at any time by the addition of a new clause. Ned From barryleiba@gmail.com Thu Sep 6 16:29:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D5721E803A for ; Thu, 6 Sep 2012 16:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.946 X-Spam-Level: X-Spam-Status: No, score=-102.946 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-G5PoCiWkSf for ; Thu, 6 Sep 2012 16:29:16 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 25EF721F853F for ; Thu, 6 Sep 2012 16:29:16 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2274721vbb.31 for ; Thu, 06 Sep 2012 16:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=axRupPJA/NGaYsySGc+ibzx04q1uklbN3BUKjsw0krs=; b=Rm/YPA1cjtr98icbLjq8X1qi2gPgAi8GweFXw8QbKKThll7sf2tD/Xo4UkeN8BoQg9 1QiPgZIVc5ZXHG5vdYSWSqjokiNYz3kOkWw7lp0gj0zgRsqGrLPhN9fRxr6rhsbmN2eR 0+hbRneCtHGp1VECWSFzq5eEGEtJ0VyxOyRAW9AJ0R166fPzi4+WJ383NxwXe+pXoFRm pmTGN2rK0w1Kh3cayrrD4JWvfxo+PXbSmddFzvukcgutnLJwMBtFnzpSOEB6cCQOE+md OAtRkCmrMa260yZZjqMUBMDAUgLSIgoz96U/lQb69dspbApy+hQ98aDfPtD0XPLEmXd2 AOQQ== MIME-Version: 1.0 Received: by 10.221.13.72 with SMTP id pl8mr4782782vcb.5.1346974155604; Thu, 06 Sep 2012 16:29:15 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.58.41 with HTTP; Thu, 6 Sep 2012 16:29:15 -0700 (PDT) In-Reply-To: <01OJXX0EPZ400006TF@mauve.mrochek.com> References: <20120906213646.B6957B1E002@rfc-editor.org> <01OJXX0EPZ400006TF@mauve.mrochek.com> Date: Thu, 6 Sep 2012 19:29:15 -0400 X-Google-Sender-Auth: TMiLh7-Ujn0lwb-D4hcNy08f1R4 Message-ID: From: Barry Leiba To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org, dcrocker@bbiw.net, presnick@qualcomm.com, d.stussy@yahoo.com, RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6729 (3337) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 23:29:16 -0000 > I strongly disagree that this is in any way, shape, or form an appropriate > errata for RFC 6729 and I believe it should be rejected outright. Already has been, hours ago. > RFC 5321 neither requires any ordering nor attaches any significance to the > ordering of additional Received: field clauses. To change that would require > updating RFC 5321 itself, and that in turn would require figuring out some > ordering scheme that works across future registrations. 's what I said when I rejected it. Barry From ned.freed@mrochek.com Thu Sep 6 16:53:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232CB21F8648 for ; Thu, 6 Sep 2012 16:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifsKisOI23lc for ; Thu, 6 Sep 2012 16:53:05 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1985321F847B for ; Thu, 6 Sep 2012 16:53:05 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJXXXJYW8W008EJM@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 6 Sep 2012 16:47:59 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Thu, 6 Sep 2012 16:47:56 -0700 (PDT) Message-id: <01OJXXXIQNLI0006TF@mauve.mrochek.com> Date: Thu, 06 Sep 2012 16:27:27 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 06 Sep 2012 18:13:48 -0400" <4E9E4E976759E6BD2F8B1D04@JcK-HP8200.jck.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> <01OJWHSPET3Q0006TF@mauve.mrochek.com> <88B1FC3F-3847-44B1-AD36-15DB532BFF1E@tzi.org> <3F602497-A028-4AF2-BC70-E2A6C52E1670@cdt.org> <3E42CB5B6826E54EB4ED8380@JcK-HP8200.jck.com> <01OJXT4YWFDO0006TF@mauve.mrochek.com> <4E9E4E976759E6BD2F8B1D04@JcK-HP8200.jck.com> To: John C Klensin Cc: Ned Freed , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 23:53:08 -0000 > --On Thursday, September 06, 2012 14:05 -0700 Ned Freed > wrote: > >> If "XFF use will continue regardless of what happens with > >> Forwarded" > > > >> then > > > >> the standardization process is largely irrelevant unless there > >> is a clear commitment to change a significant fraction of > >> those non-interoperable implementations to match the > >> standard. That is true whether we make one of the existing > >> implementations the standard (presumably the "least bad" one > >> on whatever scale that is evaluated) or whether we do > >> something new and improved. > > > > I really don't think you mean this because by this rule, MIME > > would have been standardized. (At the time there were at least > > five deployed systems for multimedia mail and not only was > > there no commitment to change from any of them, there was > > significant opposition to it. At least two of those are still > > in use today, as a matter of fact.) > I assume you meant "not been standardized". My bad. > The difference is > that, at the time MIME was done, there was significant > perception of a need for an improved multimedia mail (and > non-ASCII mail) model and a similarly strong perception that the > existing/ deployed systems weren't up to the job as others saw > it. That perception certainly wasn't universal, nor was there > universal agreement that MIME was the right approach. As you > say, some of the predecessor systems are still in use. But > there was a sufficient perception of need to result in careful > consideration of the MIME approach and its fairly broad adoption. But "perception of need" wasn't part of your proposed criteria. Your criteria was "commitment to change", and that was what I was responding to. > I haven't seen that level of perceived need with the proposals > that are now coming out. Perhaps it is there and I've just lost > it in the noise. What I have seen (and I'm not accusing Alissa > of this) is a lot of concerns and complaints about functionality > that is not present (especially with regard to privacy > protection) without either a clear explanation of why what > people are trying to use "forwarded" for isn't necessary. Once again we are in agreement. > That > would be ok except that it is not clear to me that we have a way > to provide solid privacy protection other than "if you are > worried about privacy, or need to consider this capability in a > privacy-sensitive environment, don't use this". That may be a > fine answer, but, if it is the acceptable one, we should get a > statement about it into the document and move on. I think that's exactly what is needed, and I have attempted to propose text to that effect. > What I'm objecting to -- and I may still not be saying this very > well-- is any belief that, if there are interoperability > problems now, either > -- An IETF choice of one set of options over another > without a really strong rationale as to why that is > superior to other choices or > -- A completely new IETF solution that is still > recognizably similar to the existing approaches > can be counted on to automagically be adopted and take off. I agree with the sentiment, but what I'm not seeing are all the people that are in fact making these assumptions. Standardizing something that replaces existing ad-hoc mechanism is always risky. And you can argue till the cows come home about whether or not you've chosen the right tradeoff. I've already stated that I have no idea if this is the correct tradeoff or not. If someone has evidence that it is or isn't the correct one, I'd love to hear it. (The only thing I've seen that comes close is one position posted by someone who builds product in this area saying this is a good thing.) > I'd > expect a good deal of reactions along the lines of "why should > we bother with that when it requires changes to our installed > base and doesn't provide significant additional functionality". > For MIME, we had an answer to that question (actually, several > separate ones -- there was significant additional > functionality). A better example, sadly, has been IPv6 and the > long uphill struggle to get it adopted and widely deployed. Very different kettle of fish, I think. Extrapolating from what it costs me to add support for a new field to our product, this should amount to litle more than an option setting plus a few lines of code on either end. Testing is also pretty easy. In contrast, supporting IPv6 easily required several options and took 20X as much code as that in our application alone, never mind the small matter of network stack support. (You don't want to get me started on the topic of what's involved in IPv6 testing...) > ... > >> Standardization may still be worthwhile if it provides a > >> target for new implementations and an excuse to get the > >> facilities, the issues, and the points of > >> non-interoperability documented. The subset of that role > >> which is just to document what is going on and what the > >> issues are could be served as well by an Informational > >> document. But let's be careful about assuming that > >> "something better" will take off merely because there are > >> interoperability problems with existing (and likely > >> continuing) practices (if, in fact, that is the case). > > > > On this we agree. But I'll also note that another thing having > > a standard will do is instruct people as to both the utility > > and the risks of such mechanisms. > And that is why I definitely favor publishing something in this > area, something that addresses those topics in a clear and fair > way. I prefer that it be done with a standard and would prefer > that even if we somehow knew in advance that the standard would > not deploy. But if we can't get agreement on a standard, I > strongly favor an Informational document that describes the > status quo, utility, and risks so that the knowledge doesn't get > lost. Complete agreement on all points. What worries me is that the outcome of this exercise will be nothing, that's far worse than almost any other result. Ned From ned.freed@mrochek.com Thu Sep 6 17:27:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EC021F849B for ; Thu, 6 Sep 2012 17:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJv2a4+1n1hV for ; Thu, 6 Sep 2012 17:27:44 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A0CE121F8497 for ; Thu, 6 Sep 2012 17:27:44 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJXZ96POXS007NWM@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 6 Sep 2012 17:25:37 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Thu, 6 Sep 2012 17:25:32 -0700 (PDT) Message-id: <01OJXZ94EYU40006TF@mauve.mrochek.com> Date: Thu, 06 Sep 2012 17:23:51 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 06 Sep 2012 19:29:15 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120906213646.B6957B1E002@rfc-editor.org> <01OJXX0EPZ400006TF@mauve.mrochek.com> To: Barry Leiba Cc: Ned Freed , apps-discuss@ietf.org, dcrocker@bbiw.net, presnick@qualcomm.com, d.stussy@yahoo.com, RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6729 (3337) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 00:27:45 -0000 > > I strongly disagree that this is in any way, shape, or form an appropriate > > errata for RFC 6729 and I believe it should be rejected outright. > Already has been, hours ago. Good. > > RFC 5321 neither requires any ordering nor attaches any significance to the > > ordering of additional Received: field clauses. To change that would require > > updating RFC 5321 itself, and that in turn would require figuring out some > > ordering scheme that works across future registrations. > 's what I said when I rejected it. The one action I would consider in regards to this - and it does NOT rise to the level of an errata - is to make the lack of ordering, as well as the *reason* why ordering doesn't help, clear in a future revision of RFC 5321, assuming that ever happens. Future-proofing and all that. Ned From john-ietf@jck.com Thu Sep 6 18:09:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2205F21F869F for ; Thu, 6 Sep 2012 18:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDKbOPznQ-qU for ; Thu, 6 Sep 2012 18:09:32 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2D73821F8699 for ; Thu, 6 Sep 2012 18:09:32 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1T9n4X-000165-To; Thu, 06 Sep 2012 21:09:25 -0400 Date: Thu, 06 Sep 2012 21:09:20 -0400 From: John C Klensin To: Ned Freed , RFC Errata System Message-ID: <45CF154F900A3E0040BFE290@JcK-HP8200.jck.com> In-Reply-To: <01OJXX0EPZ400006TF@mauve.mrochek.com> References: <20120906213646.B6957B1E002@rfc-editor.org> <01OJXX0EPZ400006TF@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: presnick@qualcomm.com, barryleiba@computer.org, d.stussy@yahoo.com, dcrocker@bbiw.net, apps-discuss@ietf.org Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6729 (3337) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 01:09:34 -0000 I doubt that Ned's note needs any additional reinforcement but, for the record and as editor, if he hadn't responded to this first, my response would have been among much that same lines (although probably not as eloquent). The one thing I might add is that we have known for about as long as I can remember that the switch in parsing rules in the middle of the "Received:" header field from keyword-dependent with per-keyword syntax to strict Atom-String pairs up to the semicolon that sets off the date-time was a bit inelegant and perhaps even a trap for the unwary. It was already old (as part of " when we added the explicit provision for Additional-Registered-Clauses in RFC 5321. I vaguely recall discussing it then with the conclusion that nothing could be done about it that would not have been worse. So complaints about it at this stage are not only incorrect, but are well over a decade too late. best, john --On Thursday, September 06, 2012 15:52 -0700 Ned Freed wrote: > I strongly disagree that this is in any way, shape, or form an > appropriate errata for RFC 6729 and I believe it should be > rejected outright. > > RFC 5321 neither requires any ordering nor attaches any > significance to the ordering of additional Received: field > clauses. To change that would require updating RFC 5321 > itself, and that in turn would require figuring out some > ordering scheme that works across future registrations. > >> The following errata report has been submitted for RFC6729, >> "Indicating Email Handling States in Trace Fields". > >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6729&eid=3337 > >> -------------------------------------- >> Type: Technical >> Reported by: D. Stussy > >> Section: 3 > >> Original Text >> ------------- >> In Section 6, the "state" clause is added to the Additional- >> Registered-Clauses IANA sub-registry. The ABNF for this >> clause is: > >> State = CFWS "state" FWS queue-state-keyword [ "/" >> value ] ... > > > >> Corrected Text >> -------------- > > >> Notes >> ----- >> Clarification needed: Does this "state" clause keyword place >> before, after, or in either order with the "priority" clause >> keyword specified in RFC 6710? > > What semantics would attach to such an ordering anyway? That's > the only reason I can concieve of for requiring an ordering of > these clauses. > >> RFC 5321 does not specify an order for additional "Received:" >> header clauses defined after its publication. > > Exactly. > >> The order of additional clauses >> may need to be defined for proper parsing > > If that's indeed the case then it's a flaw in RFC 5321 and > would have to be corrected there. Consider: Since the list of > additional clauses can be amended at any time, software that > intends to parse these clauses has to be able to accomodate > previously unknown clauses. Moreoever, knowing the relative > ordering of the clauses your software is written to understand > doesn't help you at all with unknown clauses. > > However, this can be seen to be a nonissue simply by looking > at the definition in RFC 5321: > > Additional-Registered-Clauses = CFWS Atom FWS String > > So additional clauses always consists of either a pair of > atoms or an atom following by a quoted string. No other > syntaxes are allowed and this is trivially easy to parse. > >> to determine validity of messages for >> spam classification or determination of other subversive >> purposes (as invalid values may indicate bad messages). > > First, while it is true that agency may sometimes be inferred > indirectly through syntax use, both legal and illegal, this is > *lightyears* away from anything that we should be > standardizing. The slope here is perilous in the extreme and > in many cases we're already sliding down it: It is not at all > uncommon for perfectly legal messages to be rejected by > overzealous antispam software simply because they employed > some bit of syntax that's commonly associated with some spam > agent or other. > > The last thing we want to do is specify some ordering > requirement that could be amended at any time by the addition > of a new clause. > > Ned > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From enrico.marocco@telecomitalia.it Fri Sep 7 00:06:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC1121E8092 for ; Fri, 7 Sep 2012 00:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.719 X-Spam-Level: X-Spam-Status: No, score=-101.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ls-fs12HJAF2 for ; Fri, 7 Sep 2012 00:06:08 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9C87921E8037 for ; Fri, 7 Sep 2012 00:06:05 -0700 (PDT) Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.245.1; Fri, 7 Sep 2012 09:05:54 +0200 Received: from host7-247-static.125-81-b.business.telecomitalia.it (163.162.33.20) by smtp.telecomitalia.it (10.19.9.235) with Microsoft SMTP Server (TLS) id 8.3.245.1; Fri, 7 Sep 2012 09:05:54 +0200 Message-ID: <50499CD1.6090606@telecomitalia.it> Date: Fri, 7 Sep 2012 09:05:53 +0200 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Barry Leiba References: <504720F3.1080505@telecomitalia.it> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000804010909050302050101" X-TI-Disclaimer: Disclaimer1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Meeting minutes available X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 07:06:09 -0000 --------------ms000804010909050302050101 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 9/5/12 3:09 PM, Barry Leiba wrote: >> You can get rid of one just by s/Marco \?/Enrico:/. Just noticed, sorr= y >> for not pointing this out earlier. >=20 > Haha... sorry, that was my fault: I remembered your last name, and > mangled it to "Marco" as a given name. :-) > My apologies. Nevermind, it happens to me all the time, Larry ;-) Enrico --------------ms000804010909050302050101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MDcw NzA1NTNaMCMGCSqGSIb3DQEJBDEWBBSDSFrhG2kRbE8mrpCP/5iApQeyEDBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAF9NhnJAgWFT9FL2aaXlmd6g6W0elF7zEatuipdQS HjQ6wNNkIg6GSv+a0YvF71afq5mhG6nwsUeLdpENfHmcK9ZA6ZuWKiOE2mD485U8SxCBv7S5 qPi20uGHmPL+NIQuk9Z1plNRdQzxev28M6ioKdF6xZLU/Ir8FuckLAYbtXdNiauduMJ7sA65 TkL/U0ryCfD/GFJ581oNBxB9fQsmlmVPEoU5Omfiqg7DtCuMWGwmsk73RUaNi8spLa2hKA+i EBD6Sfy7dSSHcg/4GzytRDEp/eZSeGxRhQd9COBkMlT4ab5vZjU6GT4iRkJnJFSj45WzgRem TdrR+DXmviG5yQAAAAAAAA== --------------ms000804010909050302050101-- From ht@inf.ed.ac.uk Fri Sep 7 01:53:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B7A21F8715 for ; Fri, 7 Sep 2012 01:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5FT1+egzFpT for ; Fri, 7 Sep 2012 01:53:49 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 06E8121F86BD for ; Fri, 7 Sep 2012 01:53:48 -0700 (PDT) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q878rIEu017825; Fri, 7 Sep 2012 09:53:18 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q878rHie030075; Fri, 7 Sep 2012 09:53:17 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q878rHGv005781; Fri, 7 Sep 2012 09:53:17 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q878rH1F005777; Fri, 7 Sep 2012 09:53:17 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: "Murray S. Kucherawy" References: <502A21A2.8060106@isode.com> <502CEC1D.3010301@att.com> <502CEE3C.3010107@isode.com> <01OJ46MC14UA0006TF@mauve.mrochek.com> <502E38CD.2050107@isode.com> <01OJ5GAZWQ9A0006TF@mauve.mrochek.com> <503042F9.7000201@att.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 07 Sep 2012 09:53:16 +0100 In-Reply-To: (Murray S. Kucherawy's message of "Thu\, 30 Aug 2012 07\:12\:09 -0700") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Bilated issue with draft-ietf-appsawg-media-type-suffix-regs-02.txt: fragment identifier rules X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:53:50 -0000 Murray S. Kucherawy writes: > On Sat, Aug 18, 2012 at 6:35 PM, Tony Hansen wrote: >> I can work this in somewhere. Based on the discussion on fragment >> identifier precedence, I might choose my suggested wording from an >> earlier email instead. Coming back late to this party, I hope the "this" above is only the >> NEW: >> When updating a +suffix registration care should be taken to review all >> previously registered xxx/yyy+suffix media types regarding whether they >> might be affected by the updated +suffix registration. bit, and _not_ the proposed NEW re-ordering of the precedence overall. . . ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From ht@inf.ed.ac.uk Fri Sep 7 01:58:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F98121F86D6 for ; Fri, 7 Sep 2012 01:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmYxktfh4QOW for ; Fri, 7 Sep 2012 01:58:04 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6282321F86A5 for ; Fri, 7 Sep 2012 01:58:04 -0700 (PDT) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q878w1oU020811; Fri, 7 Sep 2012 09:58:01 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q878w1cL030356; Fri, 7 Sep 2012 09:58:01 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q878w04C005896; Fri, 7 Sep 2012 09:58:00 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q878w0Tf005892; Fri, 7 Sep 2012 09:58:00 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Tony Hansen References: <502A21A2.8060106@isode.com> <502CEC1D.3010301@att.com> <502CEE3C.3010107@isode.com> <01OJ46MC14UA0006TF@mauve.mrochek.com> <502E38CD.2050107@isode.com> <01OJ5GAZWQ9A0006TF@mauve.mrochek.com> <50304156.7070803@att.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 07 Sep 2012 09:58:00 +0100 In-Reply-To: <50304156.7070803@att.com> (Tony Hansen's message of "Sat\, 18 Aug 2012 21\:28\:54 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Need discussion of fragment identifier precedence for draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:58:05 -0000 Tony Hansen writes: > Since I wrote the text the way I did, I obviously fell on the side of > the common semantics across fragment identifiers having precedence. > > I would like to hear input from others on this issue. That's my position, and the TAG's. That's why it's crucial that the generic == suffix == +foo spec. for fragids must not make it an error if a fragid doesn't work in its terms, so that in such cases the resolution can legitimately "fall through" to the specific == suffixed == xxx/yyy+foo spec. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From andreas@sbin.se Fri Sep 7 03:39:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD9C21F8686 for ; Fri, 7 Sep 2012 03:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9g1xvZi4XIn for ; Fri, 7 Sep 2012 03:39:34 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9D49721F84EA for ; Fri, 7 Sep 2012 03:39:33 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q87AdUSG012186; Fri, 7 Sep 2012 10:39:31 GMT Date: Fri, 7 Sep 2012 12:39:02 +0200 From: Andreas Petersson To: John C Klensin Message-ID: <20120907123902.1ebd300b@hetzer> In-Reply-To: <4E9E4E976759E6BD2F8B1D04@JcK-HP8200.jck.com> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> <01OJWHSPET3Q0006TF@mauve.mrochek.com> <88B1FC3F-3847-44B1-AD36-15DB532BFF1E@tzi.org> <3F602497-A028-4AF2-BC70-E2A6C52E1670@cdt.org> <3E42CB5B6826E54EB4ED8380@JcK-HP8200.jck.com> <01OJXT4YWFDO0006TF@mauve.mrochek.com> <4E9E4E976759E6BD2F8B1D04@JcK-HP8200.jck.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/iWaWLpx2q.9GZ.Q3ihcZ+kh"; protocol="application/pgp-signature" Cc: Ned Freed , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:39:34 -0000 --Sig_/iWaWLpx2q.9GZ.Q3ihcZ+kh Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 06 Sep 2012 18:13:48 -0400 John C Klensin wrote: > I haven't seen that level of perceived need with the proposals > that are now coming out. Perhaps it is there and I've just lost > it in the noise. =20 > What I have seen (and I'm not accusing Alissa > of this) is a lot of concerns and complaints about functionality > that is not present (especially with regard to privacy > protection) without either a clear explanation of why what > people are trying to use "forwarded" for isn't necessary.=20 I think the non present functionality is requested by the people that are loudly fighting for privacy, while the implementors are quite satisfied. > > Forwarded: definitely offers capabilities XFF does not have. > > Are those plus the promise of better interoperability enough > > to cause adoption? I have no idea. >=20 > I don't either. All I am trying to do is to encourage people to > ask that question clearly and with a maximum of objectivity and > minimum of passion. And also I'm questioning whether the IETF > has heard demand for this beyond "we know how to make it better, > therefore we should". I definitely do not know the answer to > that question either, but I'm hoping that there are some clear > answers out there. We at Opera see the need for it, and will implement it. Willy from HAProxy seemed interested, so does Apache traffic server. PHK from varnish was much involved in the technical discussions in the beginning, and says it can easily be implemented in varnish. (Note, I don't speak for them, it is what I've perceived). I also got the impression from the discussions on the http-list that it was a welcome effort to clean up in the X-Forwarded-*-land. The last, months however, the discussions have been mostly about how to split the ABNF into different sections, and the privacy implications. I believe that the interest for such discussions is pretty low from those who are interested in implementing this. Note: I don't say these discussions are wrong or unnecessary, just that everyone doesn't have the interest to participate in these discussions over and over again. :-) > > I personally would have preferred a specification that just > > standardized XFF. But the consensus went the other way, and > > one of the things I try to avoid is second guessing such > > decisions. >=20 > Agreed. But I think we should be clear-headed about what we are > getting into. The initial version, draft-petersson-forwarded-for-00 did just that. Interest for extending it came up immediately. Best regards, Andreas Petersson --Sig_/iWaWLpx2q.9GZ.Q3ihcZ+kh Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJQSc7GAAoJEEaYRbQUWNleHygQAMRyOBj64tnTicGQ8Nhx9FW4 tQ0LLTAFx+GAxQn0ZFWaLolZSOWWec4g94mHsl98fJwsyg8K4tCdynrpdxvpR5gZ 9JFNC1DwD5KU0kQ43JeHqMP1l2/lpTJCO4xg0wM3YktABI2son6+GwRMyxH42jA3 OzI8/LAkmHv+4DoBLORSRfHStHkPwjAmqizM3sSRF5QkX0Cpxk7K0yAR5W4cWnJt liNQrIFZjAJPMwxSG0ImSwkjZjLltcqQLWayJpkNrsOR8vv/RVGMPBVhnj5TJ7h1 ILR8SB8edSp74Ridon9kDkUBj+8+EptGpUlUXzU5f7qJVXg/X9Xgbm9yfCRX/DKP /Q4ooOkZ3d7Z3N9czQZbEvgwsbf2DhVhB1XDk4nLCjhBeN3W/2iiRPgB4pnh9Bu1 TLGx5MHSJiT2gsNpmlnzxVbfv69ANg1jMj0eNIneYZg8ehdKrxf/TeNG/fO2QORw 9xaVWUDwNGo2sldrUZZXB1v6wUrRphRY1Jks4quuyj+qqFEJ162NbrwtU/9a6ol8 v9P9HvFSddIxPm5MfYkASGJLHPE8CzLi5fk6s3zPrRRE4MUg9H9HQ6HfB02VdiKF WkEpIb00c52VFm947jz3IeBudfVZzyD+/HnbBx+xgKgaQ87bHr5OrSg5bPUGPesG GFsu07ZDnM+QnzD7a216 =IsWc -----END PGP SIGNATURE----- --Sig_/iWaWLpx2q.9GZ.Q3ihcZ+kh-- From andreas@sbin.se Fri Sep 7 03:39:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CDD21F876F for ; Fri, 7 Sep 2012 03:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS82zS7a5bDv for ; Fri, 7 Sep 2012 03:39:44 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id CDBAB21F8751 for ; Fri, 7 Sep 2012 03:39:43 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q87AdfY9012221; Fri, 7 Sep 2012 10:39:42 GMT Date: Fri, 7 Sep 2012 12:39:36 +0200 From: Andreas Petersson To: Ned Freed Message-ID: <20120907123936.54a9800f@hetzer> In-Reply-To: <01OJXXXIQNLI0006TF@mauve.mrochek.com> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> <01OJWHSPET3Q0006TF@mauve.mrochek.com> <88B1FC3F-3847-44B1-AD36-15DB532BFF1E@tzi.org> <3F602497-A028-4AF2-BC70-E2A6C52E1670@cdt.org> <3E42CB5B6826E54EB4ED8380@JcK-HP8200.jck.com> <01OJXT4YWFDO0006TF@mauve.mrochek.com> <4E9E4E976759E6BD2F8B1D04@JcK-HP8200.jck.com> <01OJXXXIQNLI0006TF@mauve.mrochek.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/phPGKweC9Rzp2VeQ.qHv4TD"; protocol="application/pgp-signature" Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:39:44 -0000 --Sig_/phPGKweC9Rzp2VeQ.qHv4TD Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 06 Sep 2012 16:27:27 -0700 (PDT) Ned Freed wrote: > > That > > would be ok except that it is not clear to me that we have a way > > to provide solid privacy protection other than "if you are > > worried about privacy, or need to consider this capability in a > > privacy-sensitive environment, don't use this". That may be a > > fine answer, but, if it is the acceptable one, we should get a > > statement about it into the document and move on. >=20 > I think that's exactly what is needed, and I have attempted to propose > text to that effect. I think the text is pretty clear on that point. But, I have got the perception from some people that this is not enough. If you think the text do not clearly say "if you are worried about privacy, or need to consider this capability in a privacy-sensitive environment, don't use this", please suggest concrete changes to the document. I have used some of you suggested text, Ned, thanks. :) Is there further changes you suggest? Best regards, Andreas Petersson --Sig_/phPGKweC9Rzp2VeQ.qHv4TD Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJQSc7oAAoJEEaYRbQUWNleEKQQAK8DUK5VfTCeQVqHibo9k8zE y2UPUjH5qyHWkNEVIiZ8aTCyoSXJXQmDEfdduZEh+0CJVeOlv4MB9CigQGNY82Ff 78vsVmcBtFVJ5zmyGQ0HRnNeT8FxDeRcFzP7JuzzR9jqYohp5McPxut8W0OmCY+L Xi/lbuJSRS03AWpydyEkqpQ/tFyMEi1w5eRumEXr9OSwUPr4ffsq+3E/ZLbDvs3E LRBW5XCqwbRSTOxWDfKwg1APYJDqlNJG3gTnHoicc42sGyWBKHWV+opB48w8aliU 2xKbKgsyYUoAMu4LHJ+CWEtIDXHhuIQNwrpQ6XozrPYG3kOK4oRmh5m+3GQh465K 0RU2Dbuxi9ebc787OPSdkNR71/E67t/KZTzLi92IQOdJAvnHR/A+WowmYfBe9s5z u3wRdZ4bhFbzIGbStgHcC/LpWhhZrcy2FVGRMBAHqrKD0Fnk6S+O9Yk9moqKC/Ca K5xriXrRipUMpGS7Oxp8RqDIILvueh2Iuq7phnDQy17wktschtiu3fNRrCoUXhCh kHxXxOBdFCIzV2jc3s/snwp7Ju+J+uLSVZ2pzjlODoBhIGcl0rOQbwTkz+foCL5x wGwWIcaDgkLLx9WW+xkV/zMp5FUS0qZEykmcOz2e6ItDuXPmrimO+bf5mnbFsPBC 7MyGBebkGtCmA4nGjHbK =7W0d -----END PGP SIGNATURE----- --Sig_/phPGKweC9Rzp2VeQ.qHv4TD-- From evan@status.net Fri Sep 7 06:17:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B18A21F85A7 for ; Fri, 7 Sep 2012 06:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jfM47SFRp17 for ; Fri, 7 Sep 2012 06:17:44 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id BDBCA21F8491 for ; Fri, 7 Sep 2012 06:17:44 -0700 (PDT) Received: from [192.168.0.105] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id D5C328D68C2 for ; Fri, 7 Sep 2012 13:27:36 +0000 (UTC) Message-ID: <5049F3F5.4050404@status.net> Date: Fri, 07 Sep 2012 09:17:41 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 13:17:45 -0000 My name is Evan Prodromou; I'm the lead developer for StatusNet, and also the creator and maintainer of the NodeJS "webfinger" library. Webfinger is not being created ex nihilo; there are at least half a dozen implementations, and none of the servers I've seen support JSON. The interests of existing and new implementers aren't served when specifications fail to describe the existing state of the world. I think there are ways to structure the specification to strongly guide new implementers toward the JRD implementation without failing to document the existence of XRD implementations. -Evan -- Evan Prodromou, CEO and Founder, StatusNet Inc. 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 E: evan@status.net P: +1-514-554-3826 From barryleiba.mailing.lists@gmail.com Fri Sep 7 07:08:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FF421E805D for ; Fri, 7 Sep 2012 07:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.951 X-Spam-Level: X-Spam-Status: No, score=-102.951 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihLhi5ZgYOqK for ; Fri, 7 Sep 2012 07:08:40 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAB921E8051 for ; Fri, 7 Sep 2012 07:08:40 -0700 (PDT) Received: by lahm15 with SMTP id m15so2066178lah.31 for ; Fri, 07 Sep 2012 07:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lL/AiI6QRu6HAal3OGw2A48gQhOqjv378fx0/r1iLl8=; b=k6ALvC9wN6TiTRVd/5Q3mQU6KUKChBPMD0dzglX8cqtUOaU8EQVLvrlcPLBR0eQhwq cGO8FKff40wc9tYR9zqpcEsyXD/PwH+riDDbOJUI9Q2bdlVgAxpc8rQG6dYcWGZ7lQi4 fCTT0dHho07F6x28zcBpgt6DIa6NbXaPwKyJZDHKjVLXBKJHM6SwmQF7DxIjAxmO8AMI 4Edu29OI8+CvER8xy0KQerhWsoq9aU0y4tt2z6NHZmL8uOo7VnkulyGXOIoqbNzkNwZz nZIMIdCrpQAZUI4ARiqpZiGdx7bW+8FHNj5b6Zk22vlps3f6mPeLdssA7L5Zmb9m/OPE ihmA== MIME-Version: 1.0 Received: by 10.112.31.197 with SMTP id c5mr2229979lbi.50.1347026919461; Fri, 07 Sep 2012 07:08:39 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Fri, 7 Sep 2012 07:08:39 -0700 (PDT) In-Reply-To: <20120907123936.54a9800f@hetzer> References: <504068F3.6090601@cisco.com> <999913AB42CC9341B05A99BBF358718D01CA9E94@FIESEXC035.nsn-intra.net> <20120831075430.GA28281@1wt.eu> <97F2DB55-7311-4A05-B6B2-448D3151A24D@gmx.net> <20120904063106.GC9183@1wt.eu> <18BF8C7E-0CF5-4E1E-B837-7E6554BCAFFA@cdt.org> <20120904171636.GG11187@1wt.eu> <3A7C7149-E68C-4043-A38D-0680F5A5E6B3@cdt.org> <20120904181303.GJ11187@1wt.eu> <50464AAD.6060104@cs.tcd.ie> <50464CD1.7010200@cisco.com> <50464E79.6060409@cs.tcd.ie> <69BBDEBD-4840-44DC-A49A-2EDFEE3CA6A0@cdt.org> <01OJWHSPET3Q0006TF@mauve.mrochek.com> <88B1FC3F-3847-44B1-AD36-15DB532BFF1E@tzi.org> <3F602497-A028-4AF2-BC70-E2A6C52E1670@cdt.org> <3E42CB5B6826E54EB4ED8380@JcK-HP8200.jck.com> <01OJXT4YWFDO0006TF@mauve.mrochek.com> <4E9E4E976759E6BD2F8B1D04@JcK-HP8200.jck.com> <01OJXXXIQNLI0006TF@mauve.mrochek.com> <20120907123936.54a9800f@hetzer> Date: Fri, 7 Sep 2012 10:08:39 -0400 X-Google-Sender-Auth: IShvRGyS0tXGYAfIa310Xq5UZeI Message-ID: From: Barry Leiba To: Andreas Petersson Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:08:41 -0000 >> > would be ok except that it is not clear to me that we have a way >> > to provide solid privacy protection other than "if you are >> > worried about privacy, or need to consider this capability in a >> > privacy-sensitive environment, don't use this". That may be a >> > fine answer, but, if it is the acceptable one, we should get a >> > statement about it into the document and move on. ... > I think the text is pretty clear on that point. But, I have got the > perception from some people that this is not enough. > If you think the text do not clearly say "if you are worried about > privacy, or need to consider this capability in a privacy-sensitive > environment, don't use this", please suggest concrete changes to the > document. This is really the key point we're in right now, so let me be clear about it to everyone: 1. Andreas is working with Adrian Farrel to resolve his DISCUSS, which involves sufficient text in the introduction to explain what's being done and why. Adrian thinks the most recent version is going in the right direction, and he is preparing some proposed text to try to finish it up. 2. Andreas has an outstanding change that will go in at the same time as (1), which recommends that implementations have the use of "Forwarded:" turned off by default, requiring explicit configuration to enable it. This should resolve Stewart Bryant's DISCUSS. 3. If there are any further concerns about how much the text covers the privacy issues, we need to address those, and we will. But they must come with specific proposed text. It's certainly fair for some of that text to include something like "[...insert explanation here...]" if you don't feel you're the right person to craft that section of text, but you have to give Andreas something clear that he can work with so he knows specifically *what* you want added or changed *where*. Alyssa, can you make a specific suggestion for Andreas to take? Hannes, do you have anything to add here? John? Others? I'd like to get this wrapped up very soon into a version that we can at least agree addresses the privacy issues adequately, even though some would wish that we were not publishing this as a proposed standard. Barry, responsible AD From d.stussy@yahoo.com Thu Sep 6 17:43:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED24621F849D for ; Thu, 6 Sep 2012 17:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyhNv8ru2sMf for ; Thu, 6 Sep 2012 17:43:25 -0700 (PDT) Received: from nm25-vm0.bullet.mail.sp2.yahoo.com (nm25-vm0.bullet.mail.sp2.yahoo.com [98.139.91.228]) by ietfa.amsl.com (Postfix) with SMTP id 5186421F849A for ; Thu, 6 Sep 2012 17:43:25 -0700 (PDT) Received: from [98.139.91.64] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 07 Sep 2012 00:43:18 -0000 Received: from [66.94.237.118] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 07 Sep 2012 00:43:18 -0000 Received: from [127.0.0.1] by omp1023.access.mail.mud.yahoo.com with NNFMP; 07 Sep 2012 00:43:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 648659.31999.bm@omp1023.access.mail.mud.yahoo.com Received: (qmail 10048 invoked by uid 60001); 7 Sep 2012 00:43:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346978598; bh=qY++S919t5mOkankOTjoUw2iYgvNuVfqx5uy1K61ERM=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GU7EM3Ii1CqTg9YFR0EG0kzQBUh662ng7D1+YiC5wm1sjkrmD3KHzDQkD++JTnHCueY74Fdy31ti5xSbyqeMON0+8FK08B3JeY0bDoaMsr+0Jrb+zvuQWZ29BxsfwOXJqPJkBM12KX5IUT60qSsWJdOLCBEWOsfNsBlbMTC0LaY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aiSc9ypL3o1dDDkDCyVVobp5e2cVefZXsoXNATnrt15tXAM1Z9ovN98shvKyN/BtWcF5uxMZIZ7x0GcusKue2BZ9htiW0FHjiufB3sN1dEFbvXsnU7JZlISnPpEc+XgdJ6dfVr5fQMDiK/vvJ3MWqc2Od+OPiaDQ9F0Cwq+Xkwc=; X-YMail-OSG: M4p0BbMVM1nfs.rmxDwjEpoJeIHd86ndDBCs2ULv7VCrNiB oma9qrg2BbfNoizO03GthGdimlEir.ntTTQYnP66AWAow3lKJR_yy63AJCP_ amYEBszIarvnmk2Qyy2a8NCfKv6LgnoGpRe6vE2miPmjxohMzxCtMXbgMDLS tTrPNWg1_yTLryZpWkpWmqFtqYdZcf1GPv2dc15sINXw9VXNd6CUbBN7WV69 O2WufosIzoJnQXeFeN8MSeXHpG1.ZkB.z1TcITyZTwAOAPaj0wAyO88lAr0c 0nzow3kfaezuxEEFpVK7vfpt3d6XdW7xIE_3GJepmXz8foEJ.5DF_1uwd01. 4MpgveeBTPY_hj1tmRyUUSqJo83U3hPc_AZMecqLasE1sHX051nIumGPP8Uc fZS1H07ZjWOQPzIqzxzuBV7zu3FNmx.qP1UmasPRr3WT8zgFf4vvcjlAEigZ .0cjSmyIZkhOZdq4dF_qA6EogCk8GOtYKhIErxRAwSJw- Received: from [71.106.170.128] by web84510.mail.ne1.yahoo.com via HTTP; Thu, 06 Sep 2012 17:43:17 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346978597.8773.YahooMailClassic@web84510.mail.ne1.yahoo.com> Date: Thu, 6 Sep 2012 17:43:17 -0700 (PDT) From: d.stussy@yahoo.com To: RFC Errata System , Ned Freed In-Reply-To: <01OJXX0EPZ400006TF@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 07 Sep 2012 08:31:24 -0700 Cc: apps-discuss@ietf.org, dcrocker@bbiw.net, presnick@qualcomm.com, barryleiba@computer.org, rfc-editor@rfc-editor.org Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6729 (3337) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 00:43:26 -0000 --- On Thu, 9/6/12, Ned Freed wrote: > [snip] > > RFC 5321 does not specify an order for additional "Received:" > > header clauses defined after its publication. >=20 > Exactly. Nor should it. Order should be introduced as additional clauses are define= d, even if that order is "any." As it appears in RFC 5321, it was merely a= reservation of a place-holder for future use. =20 > > The order of additional clauses > > may need to be defined for proper parsing >=20 > If that's indeed the case then it's a flaw in RFC 5321 and would have to = be > corrected there. Consider: Since the list of additional clauses can be am= ended > at any time, software that intends to parse these clauses has to be able = to > accomodate previously unknown clauses. Moreoever, knowing the relative or= dering > of the clauses your software is written to understand doesn't help you at= all > with unknown clauses. Tell me why "previously unknown clauses" not registered with IANA (i.e. as = a result of the RFC process) should be accepted? To allow such is the same= as accepting random text, so one may as well say, "Spam me." > However, this can be seen to be a nonissue simply by looking at the > definition in RFC 5321: >=20 > =A0=A0=A0Additional-Registered-Clauses=A0 =3D CFWS Atom FWS String >=20 > So additional clauses always consists of either a pair of atoms or an=A0 = atom > following by a quoted string. No other syntaxes are allowed and this is > trivially easy to parse. Don't be so certain. The "for" clause may take (even if it's not the "best= current practice") multiple (even "infinite") values. Should I assume tha= t the first value that does not match the appropriate syntax (a mailbox or = a list) must then be a literal matching an optional additional clause keywo= rd added by a later RFC (such as 6710 or 6729)? If these additional keywor= ds may then appear in any order but only once, I now also have to remember = whether I've encountered it before; a complication to the linear parsing we= had before the second of these additions. It doesn't matter if one is parsing left-to-right through the "for" clause = (if present) or right-to-left from the semicolon separating the timestamp; = the problem of multiple parsing paths encountered due to "any" order occurs= . For "n" additional clauses appearing in any order, there are n! permutat= ions not counting omissions. Try writing a Turing machine for the syntax. Without multiple "for" clause= s, the machine is finite and without loops. At the clause level, the machi= ne is even linear in design. Now, add these additional clauses. If one lo= ops back to the state "after-for-value", one must now also remember whether= we've travelled an additional keyword path to the "found-X" state (where "= X" is an additional clause), and that violates TM design. A proper TM will= suffer the n! parsing path problem, and although state-finite, it gets ver= y complex quickly. =20 > > to determine validity of messages for > > spam classification or determination of other > subversive purposes (as invalid > > values may indicate bad messages). >=20 > First, while it is true that agency may sometimes be inferred indirectly > through syntax use, both legal and illegal, this is *lightyears* away fro= m > anything that we should be standardizing. The slope here is perilous in t= he > extreme and in many cases we're already sliding down it: It is not at all > uncommon for perfectly legal messages to be rejected by overzealous antis= pam > software simply because they employed some bit of syntax that's commonly > associated with some spam agent or other.=20 I would say that the mere existence of the "best current practices" series = of RFCs would contradict that position. > The last thing we want to do is specify some ordering requirement that co= uld be > amended at any time by the addition of a new clause. We already have an ordering requirement defined in the syntax itself for th= e first six clauses defined in RFC 5321. Messages with these clauses out o= f order are not RFC (or standards*) compliant and I have no problem rejecti= ng them as such. I see nothing wrong with defining a default order of futu= re additions to be in the order they were published by the RFC process. All we have per RFC 5321 is that additional clauses added by future changes= or additions follow the existing ones. It is up to these future documents= to define the characteristics of these additional items. Simply put, this= RFC left out a characteristic which was deferred to it. * - A standard is a policy, usage, or custom which is ENFORCED. Standards = track RFC documents are merely proposals. From ned.freed@mrochek.com Fri Sep 7 10:48:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBD421E809B for ; Fri, 7 Sep 2012 10:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROg7lCi6Kunz for ; Fri, 7 Sep 2012 10:48:17 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B92E821E805F for ; Fri, 7 Sep 2012 10:48:17 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJYZHH3QWG007UUA@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 7 Sep 2012 10:43:05 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=UTF-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Fri, 7 Sep 2012 10:43:01 -0700 (PDT) Message-id: <01OJYZHF0SJA0006TF@mauve.mrochek.com> Date: Fri, 07 Sep 2012 08:42:37 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 04 Sep 2012 20:38:25 +0200" <50464AA1.4040906@cisco.com> References: <1972D7F2-E7C1-4066-BC83-904D68C733F3@mnot.net> <01OJRY9JYK8G0006TF@mauve.mrochek.com> <01OJS30QN9SW0006TF@mauve.mrochek.com> <03BAF4AA-C350-41D0-BD9D-FC6389873C84@vpnc.org> <01OJTNEBJV620006TF@mauve.mrochek.com> <504588E8.9090200@cisco.com> <01OJUSKDXC4Y0006TF@mauve.mrochek.com> <50464AA1.4040906@cisco.com> To: Eliot Lear Cc: Ned Freed , Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 17:48:18 -0000 > Ned, > First, we disagree in our experiences and on facts, and my point is > *not* to kill the draft, but rather, as I wrote at the beginning, to > find the few sentences at the beginning so that the purpose of the > feature is clear– and it's *not*, and your logic isn't their logic. Which is why I have suggested text. Which you still haven't commented on, although apparently events have passed us both by and text has been added to the document to address this. > And then a clear discusison on privacy implications. I suggested some text for that as well. > Also, there should be some statements about the > limitations the approach (like the fact that sessions can and do outlast > IP addresses. > How hard could this be? Pretty darned hard when you refuse to engage on actual text. I freely acknowledge that the text I've suggested may be completely and total shit but it's hard to improve it without feedback. Ned P.S. You will notice I did not respond as to your assertions about facts and experiences. This is not because I have no respone, but rather because I now deem such a response to be irrelevant. From ned.freed@mrochek.com Fri Sep 7 14:11:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5763721E80E8 for ; Fri, 7 Sep 2012 14:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvCw0c53P-nF for ; Fri, 7 Sep 2012 14:11:38 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id ECDA221E80E3 for ; Fri, 7 Sep 2012 14:11:37 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJZ6LNFYWG00884Q@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 7 Sep 2012 14:06:29 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Fri, 7 Sep 2012 14:06:25 -0700 (PDT) Message-id: <01OJZ6LKN6XU0006TF@mauve.mrochek.com> Date: Fri, 07 Sep 2012 13:04:02 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 06 Sep 2012 17:43:17 -0700 (PDT)" <1346978597.8773.YahooMailClassic@web84510.mail.ne1.yahoo.com> References: <01OJXX0EPZ400006TF@mauve.mrochek.com> <1346978597.8773.YahooMailClassic@web84510.mail.ne1.yahoo.com> To: d.stussy@yahoo.com Cc: Ned Freed , apps-discuss@ietf.org, dcrocker@bbiw.net, presnick@qualcomm.com, barryleiba@computer.org, rfc-editor@rfc-editor.org Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6729 (3337) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 21:11:39 -0000 > --- On Thu, 9/6/12, Ned Freed wrote: > > [snip] > > > RFC 5321 does not specify an order for additional "Received:" > > > header clauses defined after its publication. > > > > Exactly. > Nor should it. Order should be introduced as additional clauses are defined, even if that order is "any." As it appears in RFC 5321, it was merely a reservation of a place-holder for future use. No, it should not. What should happen is that additional clauses that require ordering should be rejected as being badly designed. > > > The order of additional clauses > > > may need to be defined for proper parsing > > > > If that's indeed the case then it's a flaw in RFC 5321 and would have to be > > corrected there. Consider: Since the list of additional clauses can be amended > > at any time, software that intends to parse these clauses has to be able to > > accomodate previously unknown clauses. Moreoever, knowing the relative ordering > > of the clauses your software is written to understand doesn't help you at all > > with unknown clauses. > Tell me why "previously unknown clauses" not registered with IANA (i.e. as a > result of the RFC process) should be accepted? Read what I said again. I was talking about clauses registered after some piece of software was written and deployed. Registration can occur at any time, and in the case of > To allow such is the same as > accepting random text, so one may as well say, "Spam me." On what planet does it make sense for spammers to introduce new Received: clauses that will get them noticed as such? > > However, this can be seen to be a nonissue simply by looking at the > > definition in RFC 5321: > > > > Additional-Registered-Clauses = CFWS Atom FWS String > > > > So additional clauses always consists of either a pair of atoms or an atom > > following by a quoted string. No other syntaxes are allowed and this is > > trivially easy to parse. > Don't be so certain. My certainty, if you can call it that, derives from the way RFC 5321 is written. It only allows the addition of clauses with these forms and it carefully defines what preceeds them. > The "for" clause may take (even if it's not the "best > current practice") multiple (even "infinite") values. RFC 5321 (which is a draft standard, not a BCP), defines "for" clauses thusly: For = CFWS "FOR" FWS ( Path / Mailbox ) Path = "<" [ A-d-l ":" ] Mailbox ">" Mailbox = Local-part "@" ( Domain / address-literal ) Sure looks like it only takes one value to me. And this is actually unchanged from RFC 822, which also specified single value "for" clauses. In other words, the syntax you are now describing is currently invalid and has been a standards violation since at least 1982. > Should I assume that the > first value that does not match the appropriate syntax (a mailbox or a list) > must then be a literal matching an optional additional clause keyword added by > a later RFC (such as 6710 or 6729)? What you should do is parse the crap people put in Received: fields as best you can given that all sorts of syntax violations are common. (I haven't seen the multiple for value one myself, but I've seen many others and have no problem believing it exists.) What you appear to be doing instead is assuming that despite the fact that rules about the values the clauses take as well as the order the clauses appear in have been, let's say less than scrupulously followed for 30 years, that all of a sudden we can reject the consensus behind three standards track documents, one a draft standard, and instead implement a complex administrative procedure for forcing an ordering and this time things will be different and people will pay attention to the new rules while continuing to violate the old ones? > If these additional keywords may then > appear in any order but only once, I now also have to remember whether I've > encountered it before; a complication to the linear parsing we had before the > second of these additions. Yep, that's how it works. > It doesn't matter if one is parsing left-to-right through the "for" clause > (if present) or right-to-left from the semicolon separating the timestamp; the > problem of multiple parsing paths encountered due to "any" order occurs. For > "n" additional clauses appearing in any order, there are n! permutations not > counting omissions. Yes, but requiring an ordering doesn't help, because unless you've figured out a way to magically update all your software in the field the instant a new registered field shows up it is going to fail when that happens. And then there's the possibility of unregistered fields, not to mention out of order fields and various other messes, which are commonly produced by completely legitimate agents. > Try writing a Turing machine for the syntax. Without multiple "for" clauses, > the machine is finite and without loops. At the clause level, the machine is > even linear in design. Now, add these additional clauses. If one loops back > to the state "after-for-value", one must now also remember whether we've > travelled an additional keyword path to the "found-X" state (where "X" is an > additional clause), and that violates TM design. A proper TM will suffer the > n! parsing path problem, and although state-finite, it gets very complex > quickly. I would not waste my time on such a pointless exercise. Our software parses Received: fields all the time using a variety of tecniques and a handful of heuristics. It seems to work pretty well. > > > to determine validity of messages for > > > spam classification or determination of other > > subversive purposes (as invalid > > > values may indicate bad messages). > > > > First, while it is true that agency may sometimes be inferred indirectly > > through syntax use, both legal and illegal, this is *lightyears* away from > > anything that we should be standardizing. The slope here is perilous in the > > extreme and in many cases we're already sliding down it: It is not at all > > uncommon for perfectly legal messages to be rejected by overzealous antispam > > software simply because they employed some bit of syntax that's commonly > > associated with some spam agent or other. > I would say that the mere existence of the "best current practices" series of > RFCs would contradict that position. This plus your earlier comment means you need to reread RFC 2026 to better understand document statuses and what BCPs are actually for. > > The last thing we want to do is specify some ordering requirement that could be > > amended at any time by the addition of a new clause. > We already have an ordering requirement defined in the syntax itself for the > first six clauses defined in RFC 5321. Messages with these clauses out of > order are not RFC (or standards*) compliant and I have no problem rejecting > them as such. I see nothing wrong with defining a default order of future > additions to be in the order they were published by the RFC process. That's your opinion, which of course you're entitled to have. What I'm not seeing is a groundswell of support, let alone a strong consensus, to change an existing standard to say what you want it to say. There are quite a few things about RFC 5321 and RFC 5322, not to mention several other documents I actually coauthored, that I don't like and would change if I were King of the Standards for a day. But I'm not, and neither are you. > All we have per RFC 5321 is that additional clauses added by future changes > or additions follow the existing ones. It is up to these future documents to > define the characteristics of these additional items. Simply put, this RFC > left out a characteristic which was deferred to it. I see no text in RFC 5321 to support this view. > * - A standard is a policy, usage, or custom which is ENFORCED. Standards > track RFC documents are merely proposals. Even if grant this is true, which I don't, I completely fail to see the relevance. But in any case, I'm done with this. According to Barry your errata was rejected even before I posted my response and I see no point in discussing this further. Ned From mnot@mnot.net Fri Sep 7 20:43:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A607F21F853F for ; Fri, 7 Sep 2012 20:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.566 X-Spam-Level: X-Spam-Status: No, score=-103.566 tagged_above=-999 required=5 tests=[AWL=-1.567, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id So7tOlipxV62 for ; Fri, 7 Sep 2012 20:43:10 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id DEA2221F853C for ; Fri, 7 Sep 2012 20:43:09 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3643222E253 for ; Fri, 7 Sep 2012 23:43:02 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 8 Sep 2012 13:42:58 +1000 To: Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) Subject: [apps-discuss] A couple more PATCH issues X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 03:43:10 -0000 I posted a blog entry explaining why I'm keen on JSON Patch here: http://www.mnot.net/blog/2012/09/05/patch In the comments, a few issues came up: 1) Thomas Koch asked how a resource know which representation the patch = is intended for, against, if there are multiple representations of a = resource? His example was a case where there's a portable contacts JSON = format as well as a future vcard+json format available at the same URI.=20= I can see a few different approaches to this; e..g, a) letting the resource figure it out b) using If-Match to convey the ETag of the appropriate representation c) adding a field in the format identifying the media type of the = representation that the patch is intended for I'm sure there are more. Thoughts? 2) Markus Lanthaler asked why we don't use a +json media type. Way back = when, I advised Paul to use json-patch, because +json wasn't formalised = yet, and I had some philosophical issues with it (still do, but = whatever). What's the state of that now? Can we start minting +json formats? What's = the process for establishing one of these? Is anyone working on a +json = template in a draft (as per = )? Cheers, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Fri Sep 7 21:12:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF48B21E809A for ; Fri, 7 Sep 2012 21:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.709 X-Spam-Level: X-Spam-Status: No, score=-103.709 tagged_above=-999 required=5 tests=[AWL=-1.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yksqEvBm4nxT for ; Fri, 7 Sep 2012 21:12:49 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 908C621E8064 for ; Fri, 7 Sep 2012 21:12:49 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 91E1D22E1F4; Sat, 8 Sep 2012 00:12:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: Date: Sat, 8 Sep 2012 14:12:38 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <06449EEB-F0DF-43DC-812E-FDF9945F6A71@mnot.net> References: <1346890005.16601.45.camel@pbryan-wsl.internal.salesforce.com> To: James M Snell X-Mailer: Apple Mail (2.1486) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Json Patch Extended Operations - *Experimental* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 04:12:51 -0000 Effectively, we don't have extensibility in JSON Patch right now -- and = I think that's a Feature[tm]. However, nothing's stopping you from defining a superset of JSON Patch = as another media type -- and I agree that there are cases where this'd = be very interesting.=20 Cheers, On 06/09/2012, at 10:11 AM, James M Snell wrote: > Indeed. It is definitely a slippery slope. At the very least, I think = this can demonstrate that *IF* (and it's a big if) an application needs = additional support for a broader range of test options, it can be = implemented in a way that is generally consistent with the existing = json-patch format -- and defined as an extension of json patch albeit = with a different media type. For now, then, I'll likely table this and = chalk it up as an interesting experiment until and unless there is more = of a demonstrated need. >=20 > On Wed, Sep 5, 2012 at 5:06 PM, Paul C. Bryan wrote: > I agree that these additional constructs could come in handy under the = right circumstances. That said, I see no way to bound the scope, because = any addition could be deemed handy under the right circumstances. >=20 > I wrestled initially with the consequences of adding the test = operation when it was first suggested. My notable concern was that it = could creep into more than just a simple equality test, perhaps even be = pushed to qualify particular operations (as you're suggesting), and = ultimately lead toward the need to sport a Turing-complete query syntax! = Okay, that's going too far, but hopefully this illustrates the extent of = my concern: slippery slope, in for a penny in for a pound, etc. >=20 > The use case that drove the equality test for me was (quasi-) RESTful: = there's a clear need to test equality of the partial state of a JSON = document as a precondition of its modification. In the case of HTTP = PATCH in particular, this presumes that the patch document is not being = applied blindly. Your suggested extended operations definitely go beyond = that scope.=20 >=20 > Paul >=20 >=20 > On Wed, 2012-09-05 at 10:03 -0700, James M Snell wrote: >> I've recently been experimenting with the JSON Patch format in a = variety of scenarios in order to gain some additional implementation = experience. I've found that in a number of cases it can be useful to = apply more additional types of test operations. I am considering writing = these up as a separate I-D as an extension to Json-Patch but I'm not yet = fully convinced that it's something that should be done; so I wanted to = solicit some feedback from the group at large. >>=20 >>=20 >> In my experiments, I have toyed around with the following additional = test operations: >>=20 >>=20 >> "not" -- aggregate test... all of the contained operations must = evaluate to false.. must not contain change operations.. tests only >> "and" -- aggregate test... all of the contained operations must = evaluate to true.. must not contain change operations.. tests only >> "or" -- aggregate test... any of the contained operations must = evaluate to true.. must not contain change operations.. tests only >> "typeOf" -- tests to ensure that the referenced object is the = specified type (using javascript typeof) >> "contains" -- does the toString value of the referenced object = contain the specified value >> "startsWith"-- does the toString value of the referenced object start = with the specified value >> "endsWith" -- does the toString value of the referenced object end = with the specified value >> "matches" -- does the toString value of the referenced object match = the given regular expression >> "lessThan" -- if the value is numeric or a date, returns true if = node value is more than specified value >> "moreThan" -- if the value is numeric or a date, returns true if = node value is more than specified value >>=20 >>=20 >> For example, consider the following hypothetical, extended json-patch >>=20 >>=20 >> [ >> { "and": [ >> { "not": [ >> {"moreThan", "/a/bar", "value": 123}, >> {"matches", "/a/baz", "/sample/ig"} >> ] >> }, >> {"contains": "/a/foo", "value": "123"}, >> {"typeOf": "/a/b/version", "value": "number"} >> ] >> }, >> {"add": "/a/b/c", "value": "foo"}, >> {"replace": "/a/b/version", value: 1}=20 >> ] >>=20 >>=20 >> In this example, the change operations ("add" and "increment") are = only applied if and only if: >>=20 >>=20 >> * The /a/b/version property exists and is a numeric value, >> * The /a/foo property contains the characters "123" in it's string = representation, >> * The /a/baz property does not match the regular expression = /sample/ig, and >> * The /a/bar property is numeric and is less than or equal to 123 >>=20 >>=20 >> Yes, this adds quite a bit more complexity and yes, it's not yet = clear if this is something of value. I'm not arguing that we SHOULD do = this, but in a variety of experiments such tests have demonstrated = usefulness. >>=20 >>=20 >> Also, I was asked recently whether JSON-Patch could be made to apply = changes over a set of properties within a document that match a given = criteria. For example, consider the following source JSON document: >>=20 >>=20 >> { >> "items": [ >> { "actor": {"displayName": "James" }, >> "verb": "post", >> "object": {"objectType": "note", "content": "test 1" }}, >> { "actor": {"displayName": "Joe" }, >> "verb": "post", >> "object": {"objectType": "note", "content": "test 2" }}, >> { "actor": {"displayName": "Sally" }, >> "verb": "share", >> "updated": "2012-12-12T12:12:12Z", >> "object": {"objectType": "book", "id": "urn:foo:1" }}, >> ] >> } >>=20 >>=20 >> Suppose I wish to add a "published" property to all items that = currently do not have one... I could accomplish this using a new = extended "each" operation... >> =20 >> [ >> { "each": "/items",=20 >> "apply": [ >> {"not": [{"test":"/updated"}]}, >> {"add": "/updated", "value": "2012-12-12T12:12:12Z"} >> ] >> } >> ] >>=20 >>=20 >> This evaluates as: For each member of /items, test to see if the = member has an updated property. If not, add it with the value = "2012-12-12T12:12:12Z". If /items is a primitive, the "each" operation = would fail as an error condition. If /items is an array, then each = iterates over each member of the array. If /items is an object, each = iterates over each of that's objects member properties.=20 >>=20 >>=20 >> Note, however, that this differs quite a bit from the existing = semantics of json-patch. For one, a negative test within the "apply" = would not signal an error condition that would halt the entire patch = operation. The negative test would simply mean that the modification for = that particular element would not be applied. All of the changes within. >>=20 >>=20 >> Again, I'm not yet convinced this is a good idea but experimentation = has demonstrated that it's at least a workable approach. I'd very much = like to hear from others on whether or not this is something we should = or should not attempt to pursue. >>=20 >>=20 >> Thoughts? >>=20 >>=20 >> - James >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >>=20 >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Fri Sep 7 21:58:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B9B21F8643 for ; Fri, 7 Sep 2012 21:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.608 X-Spam-Level: X-Spam-Status: No, score=-103.608 tagged_above=-999 required=5 tests=[AWL=-1.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2lP2hxQf4-7 for ; Fri, 7 Sep 2012 21:58:16 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC8F21F8602 for ; Fri, 7 Sep 2012 21:58:16 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0044422E256; Sat, 8 Sep 2012 00:58:08 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: Date: Sat, 8 Sep 2012 14:58:04 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1486) Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 04:58:17 -0000 This conversation seems to be getting very quickly off-track. The original question was whether there's interest in progressing JSON = Schema, as currently defined, not whether we want to pile on new = requirements. Personally, I struggle with this. XML Schema caused *so* much pain and = had *so* much opportunity cost that my automatic reaction is to scream = *no*.=20 However, JSON is not the same as XML. The metamodel is much simpler, and = much more well-aligned with most programming languages, so the interop = problems we had with XML schema may not eventuate.=20 Furthermore, I think there are interesting use cases for JSON Schema; = e.g., helping automate documentation and QA.=20 However, I know people have other uses for them, and some of them have = potential to cause a lot of harm (read: interoperability problems, = lock-in to specific stacks, etc.) that we've seen with XML. (in that sense, btw, I strongly disagree with PHB, but I suspect that = won't surprise many) As such, if (and that's a big "if") we embark on giving JSON Schema some = status, I'd propose several requirements: - adherence to the spirit of simplicity in JSON (i.e., bias towards = *not* adding any particular feature / capability) - focus only on documentation and qa as use cases; NOT "language = binding" - target should be to describe simple protocol data structures, not any = arbitrary JSON - no addition of semantics to the document by the schema; it's only = describing structure - evolution should be very carefully defined, not left to chance I'd have a very hard time with anything that went against these.=20 Cheers, On 06/09/2012, at 10:37 AM, Phillip Hallam-Baker = wrote: > On Wed, Sep 5, 2012 at 7:58 PM, Francis Galiegue = wrote: >> On Thu, Sep 6, 2012 at 1:18 AM, Tim Bray = wrote: >> [...] >>=20 >>>=20 >>> Sure, but I think Phillip was looking for a mapping into native data >>> structures >>=20 >>=20 >> Yes, and this is territory which JSON Schema must not venture into, >> imho: JSON is, by virtue, a language-neutral standard, And we should >> thank it for that ;) >=20 > That is a non-sequetor, if there is a schema that makes any sense it > should define a mapping that can be applied to any well specified > language. >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From jasnell@gmail.com Fri Sep 7 22:19:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21D021F86C1 for ; Fri, 7 Sep 2012 22:19:44 -0700 (PDT) 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_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYQuTab0GEHo for ; Fri, 7 Sep 2012 22:19:44 -0700 (PDT) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF8521F86C2 for ; Fri, 7 Sep 2012 22:19:43 -0700 (PDT) Received: by weyr3 with SMTP id r3so179982wey.22 for ; Fri, 07 Sep 2012 22:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=75mjr1Ogzlph2lEQi1jFBiuJK7vWRL5MVPFQN5nwIoo=; b=qiUXE9amr+X9YYlj7Ub2pC1dDuHrUVktMoWByGIpC709UKjEDjKqWljPZ3gHuwmjd3 lmVXM03SxXSBb9cZQ1NzAbSLorEOZ6oAZ1CxK8PADfR9pDYu71YKzwRVI40ilG72wBDx sMv4PtIpm7uTHh7u4+pf6cLb3YxI0uPdyt6YqhHxXvjFI1K2uUSOp+7BA2yzJkkhVrpZ Cl+pVc0LVxQj+dA+jxsnSjYnlioK5Oyz7GkJcMG8Tj4E5k2LPj/RuvlL6CvbBUoXH3yP Nw1IGLuXQxMVNr5cRnif8i6/WSgn4+ZsYqop5FyLNM48HHsf9WFkSYYgbbMMMhloc/8L aLoQ== MIME-Version: 1.0 Received: by 10.216.237.161 with SMTP id y33mr4110704weq.62.1347081582183; Fri, 07 Sep 2012 22:19:42 -0700 (PDT) Received: by 10.223.58.136 with HTTP; Fri, 7 Sep 2012 22:19:41 -0700 (PDT) Received: by 10.223.58.136 with HTTP; Fri, 7 Sep 2012 22:19:41 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 22:19:41 -0700 Message-ID: From: James M Snell To: Apps Discuss Content-Type: multipart/alternative; boundary=00151757752c3084bc04c929df02 Subject: [apps-discuss] Fwd: Re: A couple more PATCH issues X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 05:19:44 -0000 --00151757752c3084bc04c929df02 Content-Type: text/plain; charset=UTF-8 Sending to the list this time... ---------- Forwarded message ---------- From: "James M Snell" Date: Sep 7, 2012 9:35 PM Subject: Re: [apps-discuss] A couple more PATCH issues To: "Mark Nottingham" On Sep 7, 2012 8:43 PM, "Mark Nottingham" wrote: > > I posted a blog entry explaining why I'm keen on JSON Patch here: > http://www.mnot.net/blog/2012/09/05/patch > > In the comments, a few issues came up: > > 1) Thomas Koch asked how a resource know which representation the patch is intended for, against, if there are multiple representations of a resource? His example was a case where there's a portable contacts JSON format as well as a future vcard+json format available at the same URI. > > I can see a few different approaches to this; e..g, > > a) letting the resource figure it out > b) using If-Match to convey the ETag of the appropriate representation > c) adding a field in the format identifying the media type of the representation that the patch is intended for > Well, this question came up a few times when we were working through http patch and it came down to two approaches: either leave it entirely up to the server to figure out (e.g. who says json patch can't be applied to the logical model that is the basis for each of the available representations) or leave it up to the patch document format to identify the target. In other words options (a) and (c). I don't think option (b) is that terribly interesting or viable in the long run. - James > I'm sure there are more. Thoughts? > > > 2) Markus Lanthaler asked why we don't use a +json media type. Way back when, I advised Paul to use json-patch, because +json wasn't formalised yet, and I had some philosophical issues with it (still do, but whatever). > > What's the state of that now? Can we start minting +json formats? What's the process for establishing one of these? Is anyone working on a +json template in a draft (as per < http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-14#section-6 >)? > > Cheers, > > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --00151757752c3084bc04c929df02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sending to the list this time...

---------- Forwarded message ----------
From:= "James M Snell" <jasnell= @gmail.com>
Date: Sep 7, 2012 9:35 PM
Subject: Re: [apps-discu= ss] A couple more PATCH issues
To: "Mark Nottingham" <mnot@m= not.net>

<= br> On Sep 7, 2012 8:43 PM, "Mark Nottingham" <mnot@mnot.net> wrote:
>
> I posted a blog entry explaining why I'm keen on JSON Patch here:<= br> > =C2=A0 http://www.mnot.net/blog/2012/09/05/patch
>
> In the comments, a few issues came up:
>
> 1) Thomas Koch asked how a resource know which representation the patc= h is intended for, against, if there are multiple representations of a reso= urce? His example was a case where there's a portable contacts JSON for= mat as well as a future vcard+json format available at the same URI.
>
> I can see a few different approaches to this; e..g,
>
> a) letting the resource figure it out
> b) using If-Match to convey the ETag of the appropriate representation=
> c) adding a field in the format identifying the media type of the repr= esentation that the patch is intended for
>

Well, this question came up a few times when we were working throu= gh http patch and it came down to two approaches: either leave it entirely = up to the server to figure out (e.g. who says json patch can't be appli= ed to the logical model that is the basis for each of the available represe= ntations) or leave it up to the patch document format to identify the targe= t. In other words options (a) and (c). I don't think option (b) is that= terribly interesting or viable in the long run.

- James

> I'm sure there are more. Thoughts?
>
>
> 2) Markus Lanthaler asked why we don't use a +json media type. Way= back when, I advised Paul to use json-patch, because +json wasn't form= alised yet, and I had some philosophical issues with it (still do, but what= ever).
>
> What's the state of that now? Can we start minting +json formats? = What's the process for establishing one of these? Is anyone working on = a +json template in a draft (as per <http:= //tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-14#section-6&g= t;)?
>
> Cheers,
>
>
> --
> Mark Nottingham =C2=A0 http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discus= s@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--00151757752c3084bc04c929df02-- From julian.reschke@gmx.de Sat Sep 8 03:03:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4771D21F8688 for ; Sat, 8 Sep 2012 03:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-4.300, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiILwnrfeIGi for ; Sat, 8 Sep 2012 03:03:40 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1D05821F8686 for ; Sat, 8 Sep 2012 03:03:39 -0700 (PDT) Received: (qmail invoked by alias); 08 Sep 2012 10:03:38 -0000 Received: from p5DD9631A.dip.t-dialin.net (EHLO [192.168.1.104]) [93.217.99.26] by mail.gmx.net (mp035) with SMTP; 08 Sep 2012 12:03:38 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/JJj1qobPJRl3HFj3S4c5ePkcszfuWTPjoAQIZu8 +yPm8Lij0MkSib Message-ID: <504B17F3.1090809@gmx.de> Date: Sat, 08 Sep 2012 12:03:31 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Mark Nottingham References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps Discuss Subject: Re: [apps-discuss] A couple more PATCH issues X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 10:03:41 -0000 On 2012-09-08 05:42, Mark Nottingham wrote: > I posted a blog entry explaining why I'm keen on JSON Patch here: > http://www.mnot.net/blog/2012/09/05/patch > > In the comments, a few issues came up: > > 1) Thomas Koch asked how a resource know which representation the patch is intended for, against, if there are multiple representations of a resource? His example was a case where there's a portable contacts JSON format as well as a future vcard+json format available at the same URI. > > I can see a few different approaches to this; e..g, > > a) letting the resource figure it out > b) using If-Match to convey the ETag of the appropriate representation > c) adding a field in the format identifying the media type of the representation that the patch is intended for > > I'm sure there are more. Thoughts? It's the same problem as with any write operation (such as PUT) to a content-negotiated resource. I believe the best answer is to avoid updates to content-negotiated resources (by using a more specific URI exposed by the Location header field). Or alternatively, leave it to the server, which may have no trouble at all for simple conneg cases such as XML/JSON/HTML. > ... Best regards, Julian From ve7jtb@ve7jtb.com Sat Sep 8 05:32:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B018221F8639 for ; Sat, 8 Sep 2012 05:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id js7cMbPu4XKm for ; Sat, 8 Sep 2012 05:32:04 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id BD4A421F863F for ; Sat, 8 Sep 2012 05:32:03 -0700 (PDT) Received: by qcsu28 with SMTP id u28so356261qcs.22 for ; Sat, 08 Sep 2012 05:32:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=YdJuuFpPs9cWsACRVl2GKokndFgm8TXsYD2FCvkhfVs=; b=CB6h2w2IBQLZ+QOODkn4tWj3TFh0+9E7N7iJnXvlCYeVXg/V4nPMjtKrhtr3hBVCVN DsA5nze598oDEgoZlbQ+8mw4dCc815JMI41oKyCPuEuZVfAjQXis7u0zd+/EGPNZhWwP iK/HM8IibVJSrO9QOnwSJxSvDqFqla9xFEPdaMGbb4g7bGZxVtDsucaNsbmqsnsJHOE+ QQffYr4003osO5VzcPOVF2v4oixXphSoESNuI/K4Zjlxh0Tx9GqUE+7903U+N/Hu5Jzi HjRo/GIwMVNNTGuNHq097ix9xGU6TK5wn/OPP6zE9xvW618j/NOdahIOAvwpfbr/bTnx cTNw== Received: by 10.229.136.73 with SMTP id q9mr280729qct.122.1347107522669; Sat, 08 Sep 2012 05:32:02 -0700 (PDT) Received: from [192.168.1.211] (190-20-5-81.baf.movistar.cl. [190.20.5.81]) by mx.google.com with ESMTPS id gx4sm4013302qab.3.2012.09.08.05.31.55 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 08 Sep 2012 05:32:01 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F8AD6066-6E99-4A4E-8F43-1AAB14A34659"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: Date: Sat, 8 Sep 2012 09:31:33 -0300 Message-Id: <724D22A0-E14F-48E8-B120-CFC964D0561F@ve7jtb.com> References: To: Mark Nottingham X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQnA/xw8lKgCii8dxxoc50vx4j+QQgwXYCgeEAe/IbBCQtJ7oN4+UC5PCidlkCXED/rsLzL/ Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 12:32:04 -0000 --Apple-Mail=_F8AD6066-6E99-4A4E-8F43-1AAB14A34659 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree with Mark. In doing openID Connect having a JSON schema would have helped with = describing and constraining the messages. It might have helped with = OAuth itself in some cases. I have also had a recent inquiry from some OASIS people wanting to know = what the state of JSON Schema is. If we focus on documentation and qa use-cases there is value in working = on it. John B. On 2012-09-08, at 1:58 AM, Mark Nottingham wrote: > This conversation seems to be getting very quickly off-track. >=20 > The original question was whether there's interest in progressing JSON = Schema, as currently defined, not whether we want to pile on new = requirements. >=20 > Personally, I struggle with this. XML Schema caused *so* much pain and = had *so* much opportunity cost that my automatic reaction is to scream = *no*.=20 >=20 > However, JSON is not the same as XML. The metamodel is much simpler, = and much more well-aligned with most programming languages, so the = interop problems we had with XML schema may not eventuate.=20 >=20 > Furthermore, I think there are interesting use cases for JSON Schema; = e.g., helping automate documentation and QA.=20 >=20 > However, I know people have other uses for them, and some of them have = potential to cause a lot of harm (read: interoperability problems, = lock-in to specific stacks, etc.) that we've seen with XML. >=20 > (in that sense, btw, I strongly disagree with PHB, but I suspect that = won't surprise many) >=20 > As such, if (and that's a big "if") we embark on giving JSON Schema = some status, I'd propose several requirements: >=20 > - adherence to the spirit of simplicity in JSON (i.e., bias towards = *not* adding any particular feature / capability) > - focus only on documentation and qa as use cases; NOT "language = binding" > - target should be to describe simple protocol data structures, not = any arbitrary JSON > - no addition of semantics to the document by the schema; it's only = describing structure > - evolution should be very carefully defined, not left to chance >=20 > I'd have a very hard time with anything that went against these.=20 >=20 > Cheers, >=20 >=20 >=20 >=20 > On 06/09/2012, at 10:37 AM, Phillip Hallam-Baker = wrote: >=20 >> On Wed, Sep 5, 2012 at 7:58 PM, Francis Galiegue = wrote: >>> On Thu, Sep 6, 2012 at 1:18 AM, Tim Bray = wrote: >>> [...] >>>=20 >>>>=20 >>>> Sure, but I think Phillip was looking for a mapping into native = data >>>> structures >>>=20 >>>=20 >>> Yes, and this is territory which JSON Schema must not venture into, >>> imho: JSON is, by virtue, a language-neutral standard, And we should >>> thank it for that ;) >>=20 >> That is a non-sequetor, if there is a schema that makes any sense it >> should define a mapping that can be applied to any well specified >> language. >>=20 >>=20 >>=20 >> --=20 >> Website: http://hallambaker.com/ >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_F8AD6066-6E99-4A4E-8F43-1AAB14A34659 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkw ODEyMzEzM1owIwYJKoZIhvcNAQkEMRYEFA75OJviPpDoK5hz0DA8EW6vXXvkMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ALCmHV9T+W+XizVDwQFhwLGZQE6UXUPUdEHyfu5iwq+LqEYqWvI3m1S3Ux5sisKtrMPbCuvDPRE1 kQwxvQ4KdPGCvBeIu3i/p52D6yeFxTFDgAIEh0eVeOivheVsdH6vdS7mpuBsD+KyysfL1HLyXyrg Udd1wc5nn4vT7+5/EWM0DeEHNXoRRs1Pmzl7OpjnfQTVwcjDvwsdQ/6ezsvlJECC10pqBevFfBhr I6NUAobV6z/pctJxyNCY1RB6C93Uh15kWPKxabMjmjexz7x+7/NOsd1B+GbocLGT4tDGKZxYjcYz d3qGFJIzrMcT5wer7GGyktqumPTXIGAHbzpXulwAAAAAAAA= --Apple-Mail=_F8AD6066-6E99-4A4E-8F43-1AAB14A34659-- From hallam@gmail.com Sat Sep 8 08:38:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E7521F8596 for ; Sat, 8 Sep 2012 08:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW8zAatdhh-m for ; Sat, 8 Sep 2012 08:38:33 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by ietfa.amsl.com (Postfix) with ESMTP id EA3B721F8595 for ; Sat, 8 Sep 2012 08:38:30 -0700 (PDT) Received: by obbta17 with SMTP id ta17so1138738obb.22 for ; Sat, 08 Sep 2012 08:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AomhjtmOulCtPhq+JkorpQHIKtXAqMTSqTkwcR++zwM=; b=Hk0pCryIQwOaXtrs3yz+QdROORa4I9XSGQ+77v8qks0hGR/um3yALJhNaeSii1Wpr9 acBv+dsx84dFenGYb33A6+RdntVp6vB4wbeF0VWs4RanN0TIzehRgnlPaM2Omp/z7IYR R3zd6A4apJO4togAxD5zlqxKvzhKjoe/bSkY5T6gztzUDcGjUFi1snFz6+SAlcJxeer3 giG4/8wsZ8oZdrv9vWKpYPKJutATHcLzeafDPm4SW4hPE1EIt6sQHARcaWJ1a5mZbuYv 9yBonvTEvSsbdImJ99nO3iRj1turnlLBWkdxU1IpuJ4WtR7o0j1YBRsJQPPkVOEhXa9O 73Hg== MIME-Version: 1.0 Received: by 10.182.152.97 with SMTP id ux1mr9161261obb.13.1347118707677; Sat, 08 Sep 2012 08:38:27 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Sat, 8 Sep 2012 08:38:27 -0700 (PDT) In-Reply-To: References: Date: Sat, 8 Sep 2012 11:38:27 -0400 Message-ID: From: Phillip Hallam-Baker To: Mark Nottingham Content-Type: multipart/alternative; boundary=f46d04462c0a0a98c704c9328422 Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 15:38:34 -0000 --f46d04462c0a0a98c704c9328422 Content-Type: text/plain; charset=ISO-8859-1 -1 on the XML Schema thing +1 on the rest XML Schema is FUBAR for reasons that go beyond XML syntax. The fundamental problem is that XML Schema tries to be a substitute for DTDs and ends up importing all their peculiarities. Trying to use XML Schema as a data modeling language is very painful even if you don't use the peculiar features of XML Schema like model groups. There are actually two type systems going on in parallel. XML element tags are in fact types for the data and XML Schema types are meta-types. Oh and both can do inheritance. When I was writing the SAML 1.0 spec I got so fed up of XML Schema that I wrote my own schema tool to dump out XML Schema. I am going to be using my schema to dump out both. Sometimes people want XML and sometimes they want JSON and sometimes they want ASN.1 The encoding syntax should not affect the schema structure at all. What we need here is a simple schema language that can map cleanly and simply to a rational subset of any sane programming language (or other schema) people might want to use. I don't see a great value to using JSON syntax for the schema language but that can be a choice. JSON syntax and XML are both cluttered up with unnecessary junk that I don't want to be typing. What I think we want for a JSON schema language is something that is as simple as JSON itself. So there would be a small set of intrinsic types: No-brainer: Integer, Float, String Useful to have: DateTime, Binary Add in inheritance, lists and types defined in the schema and that is all you need to define a protocol. If you want to define an extensible protocol then you need to consider what is going to happen when an unknown tag is encountered, accept, reject or ignore. That leads to wanting to have an 'ANY' type so that protocol designers can specify the exact point where the protocol is extensible. And since we want to generate documentation from the schema we have to have a slot for that. So in my protogen tool (which should be up on github soon) I specify a type thus: Type Message Description |Abstract message class from which all messages inherit Abstract DateTime Sent Type ConnectRequest Inherits Message String Username String Domain That is all that is needed to specify the wireline format. But to generate a client server implementation you need to know how messages are grouped into requests and responses. Transaction Connect Request ConnectRequest Response ConnectResponse This then allows the compiler to generate code for the client and/or server in your favorite language. I use C# because it is designed to support this type of code generation. Java is less friendly. The client side is easy, a synchronous method in C# would have the signature class Client { public ConnectResponse Connect (ConnectRequest Request) ; The compiler will also generate asynchronous callbacks using delegates just as soon as I work out how they should look. I think the cleanest way would be to simply pass a delegate that is going to be called when it completes. If the communication pattern is more complicated than request/response then it is probably best to just code it rather than trying to define the communication pattern in the compiler. Implementing the server side means overriding the dispatch methods for server initialization, termination and the dispatch methods for each transaction. C# makes this very easy as it has partial classes. But Java is not that much more complicated. Now my protocol compiler does go beyond just being a schema tool but not all that far. WSDL and XML Schema are terrible implementations of good ideas. They are over complicated with bells whistles and curlicues that are never ever necessary and the designers themselves don't seem to really understand. But the basic idea of having a machine readable definition of the protocol is a good one. On Sat, Sep 8, 2012 at 12:58 AM, Mark Nottingham wrote: > This conversation seems to be getting very quickly off-track. > > The original question was whether there's interest in progressing JSON > Schema, as currently defined, not whether we want to pile on new > requirements. > > Personally, I struggle with this. XML Schema caused *so* much pain and had > *so* much opportunity cost that my automatic reaction is to scream *no*. > > However, JSON is not the same as XML. The metamodel is much simpler, and > much more well-aligned with most programming languages, so the interop > problems we had with XML schema may not eventuate. > > Furthermore, I think there are interesting use cases for JSON Schema; > e.g., helping automate documentation and QA. > > However, I know people have other uses for them, and some of them have > potential to cause a lot of harm (read: interoperability problems, lock-in > to specific stacks, etc.) that we've seen with XML. > > (in that sense, btw, I strongly disagree with PHB, but I suspect that > won't surprise many) > > As such, if (and that's a big "if") we embark on giving JSON Schema some > status, I'd propose several requirements: > > - adherence to the spirit of simplicity in JSON (i.e., bias towards *not* > adding any particular feature / capability) > - focus only on documentation and qa as use cases; NOT "language binding" > - target should be to describe simple protocol data structures, not any > arbitrary JSON > - no addition of semantics to the document by the schema; it's only > describing structure > - evolution should be very carefully defined, not left to chance > > I'd have a very hard time with anything that went against these. > > Cheers, > > > > > On 06/09/2012, at 10:37 AM, Phillip Hallam-Baker wrote: > > > On Wed, Sep 5, 2012 at 7:58 PM, Francis Galiegue > wrote: > >> On Thu, Sep 6, 2012 at 1:18 AM, Tim Bray wrote: > >> [...] > >> > >>> > >>> Sure, but I think Phillip was looking for a mapping into native data > >>> structures > >> > >> > >> Yes, and this is territory which JSON Schema must not venture into, > >> imho: JSON is, by virtue, a language-neutral standard, And we should > >> thank it for that ;) > > > > That is a non-sequetor, if there is a schema that makes any sense it > > should define a mapping that can be applied to any well specified > > language. > > > > > > > > -- > > Website: http://hallambaker.com/ > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Mark Nottingham http://www.mnot.net/ > > > > -- Website: http://hallambaker.com/ --f46d04462c0a0a98c704c9328422 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable -1 on the XML Schema thing +1 on the rest

XML Schema= is FUBAR for reasons that go beyond XML syntax. The fundamental problem is= that XML Schema tries to be a substitute for DTDs and ends up importing al= l their peculiarities.

Trying to use XML Schema as a data modeling language is= very painful even if you don't use the peculiar features of XML Schema= like model groups. There are actually two type systems going on in paralle= l. XML element tags are in fact types for the data and XML Schema types are= meta-types. Oh and both can do inheritance.

When I was writing the SAML 1.0 spec I got so fed up of= XML Schema that I wrote my own schema tool to dump out XML Schema. I am go= ing to be using my schema to dump out both. Sometimes people want XML and s= ometimes they want JSON and sometimes they want ASN.1

The encoding syntax should not affect the schema struct= ure at all.


What we need here is a = simple schema language that can map cleanly and simply to a rational subset= of any sane programming language (or other schema) people might want to us= e.

I don't see a great value to using JSON syntax for = the schema language but that can be a choice. JSON syntax and XML are both = cluttered up with unnecessary junk that I don't want to be typing.


What I think we want for a JSON schema l= anguage is something that is as simple as JSON itself. So there would be a = small set of intrinsic types:

No-brainer: Integer,= Float, String
Useful to have: DateTime, Binary

Add in inheritance, lis= ts and types defined in the schema and that is all you need to define a pro= tocol.

If you want to define an extensible protoco= l then you need to consider what is going to happen when an unknown tag is = encountered, accept, reject or ignore. That leads to wanting to have an = 9;ANY' type so that protocol designers can specify the exact point wher= e the protocol is extensible.

And since we want to generate documentation from the schema we have to = have a slot for that.


So in my protogen tool (which should be up= on github soon) I specify a type thus:

Type Messa= ge
=A0 =A0Description
=A0 =A0 =A0 =A0|Abstract message class fr= om which all messages inherit
=A0 =A0Abstract
=A0 =A0Da= teTime Sent


Type ConnectRequest
=A0 =A0Inherits Message
=A0 =A0String Username
=A0 =A0String Domain =A0

That is all that is needed to specify the wireline format. But to gen= erate a client server implementation you need to know how messages are grou= ped into requests and responses.

Transaction Connect
=A0 =A0 Request ConnectRe= quest
=A0 =A0 Response ConnectResponse

T= his then allows the compiler to generate code for the client and/or server = in your favorite language. I use C# because it is designed to support this = type of code generation. Java is less friendly.

The client side is easy, a synchronous method in C# wou= ld have the signature

class Client {
=A0= =A0 public ConnectResponse Connect (ConnectRequest Request) ;
= =A0 =A0=A0
The compiler will also generate asynchronous callbacks using delegates= =A0just as soon as I work out how they should look. I think the cleanest wa= y would be to simply pass a delegate that is going to be called when it com= pletes.

If the communication pattern is more complicated than r= equest/response then it is probably best to just code it rather than trying= to define the communication pattern in the compiler.

Implementing the server side means overriding the dispatch methods for= server initialization, termination and the dispatch methods for each trans= action. C# makes this very easy as it has partial classes. But Java is not = that much more complicated.


Now my protocol compiler does go beyond = just being a schema tool but not all that far.

WSD= L and XML Schema are terrible implementations of good ideas. They are over = complicated with bells whistles and curlicues that are never ever necessary= and the designers themselves don't seem to really understand.

But the basic idea of having a machine readable definit= ion of the protocol is a good one.


On Sat, Sep 8, 2012 at 12:58 AM, Mark Nottingham <mnot@mnot.n= et> wrote:
This conversation seems to be getting very q= uickly off-track.

The original question was whether there's interest in progressing JSON = Schema, as currently defined, not whether we want to pile on new requiremen= ts.

Personally, I struggle with this. XML Schema caused *so* much pain and had = *so* much opportunity cost that my automatic reaction is to scream *no*.
However, JSON is not the same as XML. The metamodel is much simpler, and mu= ch more well-aligned with most programming languages, so the interop proble= ms we had with XML schema may not eventuate.

Furthermore, I think there are interesting use cases for JSON Schema; e.g.,= helping automate documentation and QA.

However, I know people have other uses for them, and some of them have pote= ntial to cause a lot of harm (read: interoperability problems, lock-in to s= pecific stacks, etc.) that we've seen with XML.

(in that sense, btw, I strongly disagree with PHB, but I suspect that won&#= 39;t surprise many)

As such, if (and that's a big "if") we embark on giving JSON = Schema some status, I'd propose several requirements:

=A0- adherence to the spirit of simplicity in JSON (i.e., bias towards *not= * adding any particular feature / capability)
=A0- focus only on documentation and qa as use cases; NOT "language bi= nding"
=A0- target should be to describe simple protocol data structures, not any = arbitrary JSON
=A0- no addition of semantics to the document by the schema; it's only = describing structure
=A0- evolution should be very carefully defined, not left to chance

I'd have a very hard time with anything that went against these.

Cheers,




On 06/09/2012, at 10:37 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:

> On Wed, Sep 5, 2012 at 7:58 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:
>> On Thu, Sep 6, 2012 at 1:18 AM, Tim Bray <tbray@textuality.com> wrote:
>> [...]
>>
>>>
>>> Sure, but I think Phillip was looking for a mapping into nativ= e data
>>> structures
>>
>>
>> Yes, and this is territory which JSON Schema must not venture into= ,
>> imho: JSON is, by virtue, a language-neutral standard, And we shou= ld
>> thank it for that ;)
>
> That is a non-sequetor, if there is a schema that makes any sense it > should define a mapping that can be applied to any well specified
> language.
>
>
>
> --
> Website: http://= hallambaker.com/
> ________________________________________= _______
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham =A0 http://www.mnot.net/






--
Website: http://hallambaker.com/

--f46d04462c0a0a98c704c9328422-- From mnot@mnot.net Sun Sep 9 00:53:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FD421F84E1 for ; Sun, 9 Sep 2012 00:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZctGGaXeJR0 for ; Sun, 9 Sep 2012 00:53:39 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1D16421F847A for ; Sun, 9 Sep 2012 00:53:38 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6D94C22DD6D; Sun, 9 Sep 2012 03:53:31 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: <504B17F3.1090809@gmx.de> Date: Sun, 9 Sep 2012 17:53:27 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <8B7478C6-C376-446D-BF17-FF5F597E06A1@mnot.net> References: <504B17F3.1090809@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1486) Cc: Apps Discuss Subject: Re: [apps-discuss] A couple more PATCH issues X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 07:53:39 -0000 On 08/09/2012, at 8:03 PM, Julian Reschke wrote: >>=20 >> I can see a few different approaches to this; e..g, >>=20 >> a) letting the resource figure it out >> b) using If-Match to convey the ETag of the appropriate = representation >> c) adding a field in the format identifying the media type of the = representation that the patch is intended for >>=20 >> I'm sure there are more. Thoughts? >=20 > It's the same problem as with any write operation (such as PUT) to a = content-negotiated resource. I believe the best answer is to avoid = updates to content-negotiated resources (by using a more specific URI = exposed by the Location header field). >=20 > Or alternatively, leave it to the server, which may have no trouble at = all for simple conneg cases such as XML/JSON/HTML. Yes; I can see documenting those possibilities. However, I also wonder whether adding something to accommodate (c) would = be helpful too; while it won't be necessary in every case, it may be for = some. Cheers, -- Mark Nottingham http://www.mnot.net/ From pbryan@anode.ca Sun Sep 9 10:35:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACC521F8539 for ; Sun, 9 Sep 2012 10:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bs8n-f+DTxfB for ; Sun, 9 Sep 2012 10:35:50 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 8C53A21F8534 for ; Sun, 9 Sep 2012 10:35:50 -0700 (PDT) Received: from [192.168.1.10] (S0106a021b762dbb3.vf.shawcable.net [174.1.50.247]) by maple.anode.ca (Postfix) with ESMTPSA id 6D06D647A; Sun, 9 Sep 2012 17:35:49 +0000 (UTC) Message-ID: <1347212160.14957.12.camel@polyjuice> From: "Paul C. Bryan" To: Mark Nottingham Date: Sun, 09 Sep 2012 10:36:00 -0700 In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-2bVl/YbI+cI9hwqzDH+3" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: Apps Discuss Subject: Re: [apps-discuss] A couple more PATCH issues X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 17:35:51 -0000 --=-2bVl/YbI+cI9hwqzDH+3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Sat, 2012-09-08 at 13:42 +1000, Mark Nottingham wrote: > 1) Thomas Koch asked how a resource know which representation the > patch is intended for, against, if there are multiple representations > of a resource? His example was a case where there's a portable > contacts JSON format as well as a future vcard+json format available > at the same URI. IMO, this is a problem that HTTP PATCH has in general, and whatever solution should address that specification. > I can see a few different approaches to this; e..g, > > a) letting the resource figure it out Seems valid. If the server can unambiguously determine which representation to modify (e.g. because there is only one) then there is no issue. > b) using If-Match to convey the ETag of the appropriate representation Also seems valid. Presumably if there are multiple representations of the resource, the server has to compare the ETag to all of them to determine whether one matches. If it does this, it's certainly unambiguous which representation to modify. > c) adding a field in the format identifying the media type of the > representation that the patch is intended for If you mean a header field, then this also seems valid. I'd suggest though that such a solution should be addressing HTTP PATCH. > 2) Markus Lanthaler asked why we don't use a +json media type. Way > back when, I advised Paul to use json-patch, because +json wasn't > formalised yet, and I had some philosophical issues with it (still do, > but whatever). > > What's the state of that now? Can we start minting +json formats? > What's the process for establishing one of these? Is anyone working on > a +json template in a draft (as per > )? +json makes sense to me when there are multiple representations of something. Since this is very much focused on JSON document structures, I believe it would be better to keep it as json-patch. Paul --=-2bVl/YbI+cI9hwqzDH+3 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 2012-09-08 at 13:42 +1000, Mark Nottingham wrote:

1) Thomas Koch asked how a resource know which representation the patch is intended for, against, if there are multiple representations of a resource? His example was a case where there's a portable contacts JSON format as well as a future vcard+json format available at the same URI.

IMO, this is a problem that HTTP PATCH has in general, and whatever solution should address that specification.

I can see a few different approaches to this; e..g,

a) letting the resource figure it out

Seems valid. If the server can unambiguously determine which representation to modify (e.g. because there is only one) then there is no issue.

b) using If-Match to convey the ETag of the appropriate representation

Also seems valid. Presumably if there are multiple representations of the resource, the server has to compare the ETag to all of them to determine whether one matches. If it does this, it's certainly unambiguous which representation to modify.

c) adding a field in the format identifying the media type of the representation that the patch is intended for

If you mean a header field, then this also seems valid. I'd suggest though that such a solution should be addressing HTTP PATCH.

2) Markus Lanthaler asked why we don't use a +json media type. Way back when, I advised Paul to use json-patch, because +json wasn't formalised yet, and I had some philosophical issues with it (still do, but whatever).

What's the state of that now? Can we start minting +json formats? What's the process for establishing one of these? Is anyone working on a +json template in a draft (as per <http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-14#section-6>)?

+json makes sense to me when there are multiple representations of something. Since this is very much focused on JSON document structures, I believe it would be better to keep it as json-patch.

Paul --=-2bVl/YbI+cI9hwqzDH+3-- From turners@ieca.com Sun Sep 9 17:41:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E84C21F8604 for ; Sun, 9 Sep 2012 17:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.079 X-Spam-Level: X-Spam-Status: No, score=-102.079 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7UXNsZKQnac for ; Sun, 9 Sep 2012 17:41:25 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [67.18.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 85E0F21F85F9 for ; Sun, 9 Sep 2012 17:41:25 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id A1C83F989C4; Sun, 9 Sep 2012 19:41:25 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 8F882F98966 for ; Sun, 9 Sep 2012 19:41:25 -0500 (CDT) Received: from [108.18.174.220] (port=57066 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TAs44-0003sP-Mp; Sun, 09 Sep 2012 19:41:24 -0500 Message-ID: <504D3733.5040203@ieca.com> Date: Sun, 09 Sep 2012 20:41:23 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Erik Andersen References: <504B358F.2080607@e-net.lt> <003501cd8e81$74999500$5dccbf00$@eu> In-Reply-To: <003501cd8e81$74999500$5dccbf00$@eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:57066 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: 'Stefan Santesson' , "'Moudrick M. Dadashov'" , apps-discuss@ietf.org, 'pkix' Subject: Re: [apps-discuss] [pkix] Need for an organizationalIdentifier attribute X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 00:41:26 -0000 Erik, I think the apps folks might have some ideas. I cc'ed that list to see if somebody is aware of an attribute that's already been defined for this purpose. spt On 9/9/12 7:51 AM, Erik Andersen wrote: > FYI > > Erik > > *Fra:*pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] *P vegne af > *Moudrick M. Dadashov > *Sendt:* 8. september 2012 14:10 > *Til:* Stefan Santesson > *Cc:* pkix > *Emne:* Re: [pkix] Need for an organizationalIdentifier attribute > > On 3/23/2012 7:13 PM, Stefan Santesson wrote: > > When a person is associated with an organization in a certificate > the subjects employee number or alike is often stored in the > serialNumber attribute. > > But where do you store an identifier of the organization? > > That is, not the name stored in organization name, but the > registered organization number? > > I've seen some odd solutions to this problem but nor clean solution. > > X.520 only offer organizationName and orgnizationalUnitName as > organizational attributes > > Have anyone else come across this issue? > > How did you solve it? > > Do we need to define a clean attribute for an organizationalIdentifier? > > Definitely yes. > > M.D. > > /Stefan > > > > > _______________________________________________ > > pkix mailing list > > pkix@ietf.org > > https://www.ietf.org/mailman/listinfo/pkix > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From mnot@mnot.net Mon Sep 10 04:59:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453FD21F8666 for ; Mon, 10 Sep 2012 04:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.453 X-Spam-Level: X-Spam-Status: No, score=-103.453 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhRIKXvhEfsX for ; Mon, 10 Sep 2012 04:59:23 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3D97321F865F for ; Mon, 10 Sep 2012 04:59:23 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 698C222E25F; Mon, 10 Sep 2012 07:59:16 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: Date: Mon, 10 Sep 2012 21:59:13 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> References: To: James M Snell X-Mailer: Apple Mail (2.1486) Cc: Apps Discuss Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 11:59:24 -0000 That seems like a useful thing; I've tried it out here: http://trac.tools.ietf.org/wg/appsawg/trac/changeset/112 Cheers, On 06/09/2012, at 4:42 AM, James M Snell wrote: > One additional point, I note that with the current "test" operation, = the "value" property is assumed to be required. What if all I want to do = is test for the presence of a property? {"test":"/a/b/c","value":null} = can be used to test that the property is null, but what if I don't care = about the specific value? can I do, {"test":"/a/b/c"} ? >=20 > - James >=20 > On Wed, Sep 5, 2012 at 8:47 AM, James M Snell = wrote: > Three points...=20 >=20 > 1) Re: test ... I would like to see more detail on why "test" would be = used in a patch document. Perhaps just by expanding on the example just = a bit. >=20 > 2) Section 5's discussion of error handling should be expanded a bit. = Yes the changes are atomic but a clear example of exactly what that = means would be helpful. >=20 > Example: This json-patch would result in no changes being made to the = document at all. >=20 > [ > {"replace": "/a/b/c", "value": 42}, > {"test": "/a/b/c", "value": "C"} > ] >=20 > 3) Unless we specifically want to allow for such things, it should be = made clear that "test" is not intended to be used as a replacement for = other types of http conditionals. For instance, I could imagine someone = doing something like... >=20 > [ > {"test": "/foo/last-updated", "value": "2012-12-12T12:12:12Z"}, > ("add": "/a/b/c", "value": 42} > ] >=20 > Or... >=20 > [ > {"test": "/@etag", "value": "ABC123"}, > ("add": "/a/b/c", "value": 42} > ] >=20 > - James >=20 >=20 > On Wed, Sep 5, 2012 at 12:18 AM, Mark Nottingham = wrote: > I've just submitted revised json-pointer and json-patch documents, = based upon feedback. >=20 > As far as I can tell, the only open issue on JSON-Patch is about = 'test': > http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7 >=20 > In Vancouver, we said that we'd wait for implementation experience to = see if 'test' is worthwhile. >=20 > In the meantime, I've found two implementations of json-patch "in the = wild": > https://github.com/stefankoegl/python-json-patch > https://github.com/bruth/jsonpatch-js >=20 > Both are somewhat old, and both support 'test'. >=20 > As such, I'd suggest we let 'test' remain in the spec (I think there = are good arguments for it anyway), and ship it. >=20 > Make sense? >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 -- Mark Nottingham http://www.mnot.net/ From alexey.melnikov@isode.com Mon Sep 10 07:16:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A545621F8694 for ; Mon, 10 Sep 2012 07:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.073 X-Spam-Level: X-Spam-Status: No, score=-103.073 tagged_above=-999 required=5 tests=[AWL=0.846, BAYES_00=-2.599, GB_I_LETTER=-2, SARE_ADLTOBFU=0.68, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bPXJsBLYxgt for ; Mon, 10 Sep 2012 07:16:02 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 4A77121F867E for ; Mon, 10 Sep 2012 07:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1347286561; d=isode.com; s=selector; i=@isode.com; bh=fkZP33SUNwMeoJtYMY5qr8fgT21G3Pb5lNHWf+F5wqw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=iq7y1G4L1UcLv1evkKdF2N2Mtcg3CuknQooCtGcOsh+4z5c9YVkyoRNcVp2FlOIX/HjoPw LLoNVeurVW1TNHtIrzFdGx/p4CUz9lLGIv02fOJodAAy6BCGsHCngd8CDelaUyimJiqurJ Mm/WQulY0YiEfV73ZwWuwTYuNHD3r68=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 10 Sep 2012 15:16:01 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <504DF62F.3090101@isode.com> Date: Mon, 10 Sep 2012 15:16:15 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: "Miguel A. Garcia" References: <4F2FA266.8040406@telecomitalia.it> <5044C19A.3080505@ericsson.com> In-Reply-To: <5044C19A.3080505@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Geir Arne Sandbakken , "apps-discuss@ietf.org" , Ben Campbell Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-simple-chat-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:16:03 -0000 On 03/09/2012 15:41, Miguel A. Garcia wrote: > Enrico, Alexey: > > I am pulling up your original review of draft-ietf-simple-chat back in > February, and I will try to address the pending issues. > > The current version of the draft is 16: > http://datatracker.ietf.org/doc/draft-ietf-simple-chat/ > > See inline comments. > > On 06/02/2012 10:50, Enrico Marocco wrote: >> Document: draft-ietf-simple-chat-13 >> Title: Multi-party Chat Using the Message Session Relay Protocol (MSRP) >> Reviewers: Alexey Melnicov and Enrico Marocco >> Review Date: 2012-02-06 >> IETF Last Call Date: 2012-02-06 >> >> >> Summary: This draft is almost ready for publication as a Proposed >> Standard, but has a major issue to be taken into consideration and a few >> minor issues to be fixed. >> >> >> Major Issue >> >> The document doesn't describe allowed characters in Nicks and any >> normalization that needs to be applied. > > With respect to the issue of "allowed characters", only UTF-8 s > allowed. This draft is an extension to RFC 4975 (MSRP). The ABNF > syntax of the Use-Nickname header refers to RFC 4975. Section 9 of RFC > 4975 says: "MSRP is a text protocol that uses the UTF-8 [14] > transformation format". So, I believe this issue is solved by indirect > reference. However, to add a bit more emphasis, we can add the > following text: > > According to RFC 4975, MSRP > uses the UTF-8 transformation > format. The syntax of the MSRP NICKNAME method and the > "Use-Nickname" header field is built upon the target="RFC4975">MSRP formal syntax using the > Augmented Backus-Naur Form (ABNF > . That would be perfect, thanks. > With respect to the issue of normalization, I believe this is now > solved in version 16. Section 7.1 contains now the following paragraphs: > > If the policy of the chat room allows the usage of nicknames, any new > nickname requested MUST be prepared and compared with nicknames > already in use or reserved following the rules defined in Preparation > and Comparison of Nicknames [I-D.ietf-precis-nickname]. > > This mitigates the problem of nickname duplication, but it does not > solve a problem whereby users can choose similar (but different) > characters to represent two different nicknames. For example, "BOY" > and "B0Y" are different nicknames which can mislead users. The > former uses the capital letter "O" while the latter uses the number > zero "0". In many fonts the letter "O" and the number zero "0" might > be quite similar, and difficult to be perceived as different > characters. Chat rooms MAY provide a mechanism to mitigate > confusable nicknames. Yes, this is addressed. >> Minor Issues >> >> The document strictly forbids multiple To: headers in the CPIM message, >> that could be used for example to send public personal messages (i.e. >> messages addressed to some particular individual, but shared with the >> entire conference, a-la Twitter). If there's a reason for that, some >> explanation would be useful. > > This was a decision taken by the working group due to the complexity. > For example, what happens if one of the recipients is correct, but > another one is incorrect or has left the chat room. Should the server > process the message to one recipient and not to the other? what would > be the error? It was also conflicting with requirements for side > conferences, something that was part of the deliverables in XCON. > > At the end of the day, the endpoint can always send multiple messages, > each one with a single To header. > > To address this issue, I proposed to add the following text in Section > 6.2: > > This version of the specification does not support > sending a private message to multiple recipients, i.e., > the presence of multiple To headers in the Message/CPIM > wrapper of the MSRP SEND request. This is due to added > complexity, for example, with the need to determine > whether a message was not deliver to some of the > intended recipients. Implementations that still want to > recreate this function can send a series of single > private messages, one private message per intended > recipient. The endpoint can correlate this series of > messages and create the effect of a private message > addressed to multiple recipients. Sounds good. > >> Figure 1 seems to imply that MSRP relays are mandatory. Since they are >> not -- and the draft is pretty clear about it -- I'd suggest to have >> some of MSRP flows in the diagram flow straight from the client to the >> switch. > > Agreed. > >> >> A reference to the SDP mechanism defined in S. 8. would be useful in in >> S. 5.2., last paragraph, S. 6.2, last paragraph, and in any other part >> that deals with discovering of client capability. >> > > Agreed for section 5.2. The proposed change is as follows: > > Last paragraph in Section 5.2 starts with: > > The conference focus of a chat room MUST learn the chat room > capabilities of each participant that joins the chat > room. This is achieved by the exchange of new 'chatroom' > attributes in SDP (see > for further details). > > > But I believe the last paragraph of S. 6.2 does not talk about > discovering capabilities, so I think the text does not fit there. But > I have found a paragraph in S 4 that talks about capability discovery, > so I have added the last sentence of the previous paragraph too. > >> In Section 5.2: >> >> The conference focus of a chat room MUST learn the chat room >> >> How can this be achieved? A forward pointer might be missing here. > > Yes, this is the previously mentioned paragraph. >> >> capabilities of each participant that joins the chat room. The >> conference focus MUST inform the MSRP switch of such support in >> order to prevent the MSRP switch from distributing private messages >> to participants who do not support private messaging. The >> recipient >> would not be able to render the message as private, and any >> potential reply would be sent to the whole chat room. >> >> 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. > > In the current version 16, these have been split into two errors: > - 424: Malformed nickname > - 425: Nickname reserved or already in use > > We believe this solves the issue. > Ok. >> Nits [Only the few that came out in non-nitpicking read] >> >> S. 3, REQ-3: s/depend no/depend on/ > > ok. > >> >> S. 4, second paragraph after Figure 2: s/a text/text/ > > ok > >> >> A few 2119 refuses can be also found in the text, e.g.: >> >> S. 5.2, sixth paragraph: s/URI must not/URI MUST NOT/ > > Ok. > > Thanks for your comments. They will be deployed in a newer version of > the document. Thanks, will sanity check it when it is posted. From melvincarvalho@gmail.com Mon Sep 10 07:43:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18C421F865D for ; Mon, 10 Sep 2012 07:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-MNnIFbLrZo for ; Mon, 10 Sep 2012 07:43:41 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 08C8E21F851E for ; Mon, 10 Sep 2012 07:43:40 -0700 (PDT) Received: by lbky2 with SMTP id y2so1363688lbk.31 for ; Mon, 10 Sep 2012 07:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0iuboGeXxJMkpFXL2LPxt+0PjJKnqj3h89juVY+bYk4=; b=msoN+mJEY35EWxtWCtLCmzwpCg54IDC2PGQ1Yc3t6z7hzFNwUB/x0zen/u+my4/bin OjRglNHTn2zXXhiLO6pNRFQJjChKgWYnhKPLB1KTm8dKY9/y2NqBb8ZiieHSDirktGSq o2GSkjZ+zqu9YSJn8kZiUWQP72I5T8Til/rvH3961GBcDoU8pELZEBJfXWS00dhAU9W4 v9TFMAmQ7gJolpbqA2jQyvfBNZCIEnTCNH6JyzEnO6STsFqxQXa4RFoInbplqmuug6Cf XIkIAiRj5lBAdH5c/y/gDGPuLwjeZhdlBrE0zRypU3yILz7/1ZBqo4lFJhIetVYZC9b1 OiMA== MIME-Version: 1.0 Received: by 10.112.86.200 with SMTP id r8mr5099296lbz.87.1347288212873; Mon, 10 Sep 2012 07:43:32 -0700 (PDT) Received: by 10.112.148.231 with HTTP; Mon, 10 Sep 2012 07:43:31 -0700 (PDT) In-Reply-To: <5049F3F5.4050404@status.net> References: <5049F3F5.4050404@status.net> Date: Mon, 10 Sep 2012 16:43:31 +0200 Message-ID: From: Melvin Carvalho To: Evan Prodromou Content-Type: multipart/alternative; boundary=f46d040172fd56a11204c959fbfd Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:43:42 -0000 --f46d040172fd56a11204c959fbfd Content-Type: text/plain; charset=ISO-8859-1 On 7 September 2012 15:17, Evan Prodromou wrote: > My name is Evan Prodromou; I'm the lead developer for StatusNet, and also > the creator and maintainer of the NodeJS "webfinger" library. > > Webfinger is not being created ex nihilo; there are at least half a dozen > implementations, and none of the servers I've seen support JSON. > > The interests of existing and new implementers aren't served when > specifications fail to describe the existing state of the world. > > I think there are ways to structure the specification to strongly guide > new implementers toward the JRD implementation without failing to document > the existence of XRD implementations. > My understanding was that consensus was reached that JSON would be the only REQUIRED format to be supported. If I've understood correctly, this does not preclude also supporting XML, for those that wish to. This would still mean that current XML implementations will continue to operate as they are, but just that new implementations would start including JSON, and, over time, hopefully older ones will add JSON too. > > -Evan > > -- > Evan Prodromou, CEO and Founder, StatusNet Inc. > 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 > E: evan@status.net P: +1-514-554-3826 > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --f46d040172fd56a11204c959fbfd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 7 September 2012 15:17, Evan Prodromo= u <evan@status.net> wrote:
My name is Evan Prodromou; I'm the lead developer for StatusNet, and al= so the creator and maintainer of the NodeJS "webfinger" library.<= br>
Webfinger is not being created ex nihilo; there are at least half a dozen i= mplementations, and none of the servers I've seen support JSON.

The interests of existing and new implementers aren't served when speci= fications fail to describe the existing state of the world.

I think there are ways to structure the specification to strongly guide new= implementers toward the JRD implementation without failing to document the= existence of XRD implementations.

My understanding was that consensus was= reached that JSON would be the only REQUIRED format to be supported.
If I've understood correctly, this does not preclude also supporting = XML, for those that wish to.=A0 This would still mean that current XML impl= ementations will continue to operate as they are, but just that new impleme= ntations would start including JSON, and, over time, hopefully older ones w= ill add JSON too.=A0
=A0

-Evan

--
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@status.net= P: +1-514-554-3826

_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--f46d040172fd56a11204c959fbfd-- From evan@status.net Mon Sep 10 09:11:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE48321E8034 for ; Mon, 10 Sep 2012 09:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoebvauKzbNq for ; Mon, 10 Sep 2012 09:11:11 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 1887321F8705 for ; Mon, 10 Sep 2012 09:11:11 -0700 (PDT) Received: from [192.168.0.101] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id DE1A18D5E4E for ; Mon, 10 Sep 2012 16:21:04 +0000 (UTC) Message-ID: <504E1116.6060808@status.net> Date: Mon, 10 Sep 2012 12:11:02 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <5049F3F5.4050404@status.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060304090000000607060102" Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 16:11:12 -0000 This is a multi-part message in MIME format. --------------060304090000000607060102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12-09-10 10:43 AM, Melvin Carvalho wrote: > > > On 7 September 2012 15:17, Evan Prodromou > wrote: > > My name is Evan Prodromou; I'm the lead developer for StatusNet, > and also the creator and maintainer of the NodeJS "webfinger" library. > > Webfinger is not being created ex nihilo; there are at least half > a dozen implementations, and none of the servers I've seen support > JSON. > > The interests of existing and new implementers aren't served when > specifications fail to describe the existing state of the world. > > I think there are ways to structure the specification to strongly > guide new implementers toward the JRD implementation without > failing to document the existence of XRD implementations. > > > My understanding was that consensus was reached that JSON would be the > only REQUIRED format to be supported. > > If I've understood correctly, this does not preclude also supporting > XML, for those that wish to. This would still mean that current XML > implementations will continue to operate as they are, but just that > new implementations would start including JSON, and, over time, > hopefully older ones will add JSON too. Changing the semantics of the "lrdd" link relation from "XRD by default" to "JRD by default" is unnecessarily damaging to existing implementations. It does not serve new implementers well if the specification doesn't describe the way current implementations work, or give a reasonable upgrade path. I very much like the way RFC 6415 deals with XRD and JRD and I think it is a great model to follow with Webfinger: XRD by default, and easy mechanisms (content negotiation or a separate endpoint) to get JRD. -Evan -- Evan Prodromou, CEO and Founder, StatusNet Inc. 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 E: evan@status.net P: +1-514-554-3826 --------------060304090000000607060102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12-09-10 10:43 AM, Melvin Carvalho wrote:


On 7 September 2012 15:17, Evan Prodromou <evan@status.net> wrote:
My name is Evan Prodromou; I'm the lead developer for StatusNet, and also the creator and maintainer of the NodeJS "webfinger" library.

Webfinger is not being created ex nihilo; there are at least half a dozen implementations, and none of the servers I've seen support JSON.

The interests of existing and new implementers aren't served when specifications fail to describe the existing state of the world.

I think there are ways to structure the specification to strongly guide new implementers toward the JRD implementation without failing to document the existence of XRD implementations.

My understanding was that consensus was reached that JSON would be the only REQUIRED format to be supported.

If I've understood correctly, this does not preclude also supporting XML, for those that wish to.  This would still mean that current XML implementations will continue to operate as they are, but just that new implementations would start including JSON, and, over time, hopefully older ones will add JSON too.  

Changing the semantics of the "lrdd" link relation from "XRD by default" to "JRD by default" is unnecessarily damaging to existing implementations.

It does not serve new implementers well if the specification doesn't describe the way current implementations work, or give a reasonable upgrade path.

I very much like the way RFC 6415 deals with XRD and JRD and I think it is a great model to follow with Webfinger: XRD by default, and easy mechanisms (content negotiation or a separate endpoint) to get JRD.

-Evan
-- 
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@status.net P: +1-514-554-3826
--------------060304090000000607060102-- From sheppyreno@gmail.com Sun Sep 9 09:28:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2AE21F84D6 for ; Sun, 9 Sep 2012 09:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5+dzE+c-PCX for ; Sun, 9 Sep 2012 09:28:51 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1F3421F8489 for ; Sun, 9 Sep 2012 09:28:50 -0700 (PDT) Received: by lahm15 with SMTP id m15so687760lah.31 for ; Sun, 09 Sep 2012 09:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=P2cj/1mUVnZUwPUb9p3SHoIP1G7Z0xGSpEeVBM2iOXU=; b=v0T0SOMigqqveKwxwNSOD+uMjTkXUjGWwvJxpYe4W6LyxVtuy9D15pQ8Vhflrh2pRu MqjnNbnwxdxVfJueDQGHQdWhXa9k3/r+ZOQjFTEceyOecmPcnAWK7M7iDRU7Vdfomgfx 4lLFxZ7JMcoip5ABO5aFuGL6fDNr5Vzlupc6XDFdAfvqgpJQe3XpCAlFJoeZ0jMzaObj vM6V1SfLhSnWHAicnCWVdPY0rOqQ2hS5TCu4Ain+KkJHBxK/7/SeacbQT7qrERP6qPC0 TLUsu+QZ0ZTRB4/gdsjPGDZrgzzqyeToRq6+tlgAg6QHn/jTSTA7qiIBGAgTzpMsnryo 5JBg== MIME-Version: 1.0 Received: by 10.152.46.209 with SMTP id x17mr10275211lam.38.1347208129739; Sun, 09 Sep 2012 09:28:49 -0700 (PDT) Received: by 10.112.87.231 with HTTP; Sun, 9 Sep 2012 09:28:49 -0700 (PDT) Date: Sun, 9 Sep 2012 12:28:49 -0400 Message-ID: From: Sheppy Reno To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=bcaec550b3ae02fac704c9475645 X-Mailman-Approved-At: Mon, 10 Sep 2012 09:14:52 -0700 Subject: [apps-discuss] Addition of Available Space to Host-Resources-MIB X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 16:30:47 -0000 --bcaec550b3ae02fac704c9475645 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable After working with SNMP for quite a while we=92ve repeatedly run into issue= s where monitoring software is unable to accurately determine the utilization of volumes on some Linux partitions due to regular processes being unable to access the reserved file space. I believe that the best way to correct this issue is to include an additional data point in the Host Resources MIB (RFC2790) that will return available space. This should have no negative impact on systems that do not utilization reserved space, but will allow for a much more accurate picture of the space that is truly available on those partitions using reserved space. I=92ve been reading through the IETF site a bit, but I=92m still not sure a= s to the best process to get this implemented. I was hoping someone on here could give me some tips on proceeding with this. From what I can see, I just need to update RFC2790 with the below information and resubmit. I=92d also like to apologize in advance if this is the wrong mailing list, but all those dealing specifically with SNMP don=92t seem to be active anymore. RFC 2790 Add: hrStorageAvail OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION =93The amount of the storage represented by this entry that is available to non-superusers, in units of hrStorageAllocationUnits.=94 ::=3D { hrStorageEntry 8 } Thanks, Sheppy Reno --bcaec550b3ae02fac704c9475645 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

After working with SNMP for quite a while we=92ve repeated= ly run into issues where monitoring software is unable to accurately determ= ine the utilization of volumes on some Linux partitions due to regular proc= esses being unable to access the reserved file space.=A0 I bel= ieve that the best way to correct this issue is to include an additional da= ta point in the Host Resources MIB (RFC2790) that will return available spa= ce.=A0 This should have no negative impact on systems that do = not utilization reserved space, but will allow for a much more accurate pic= ture of the space that is truly available on those partitions using reserve= d space.=A0

=A0

I=92ve been reading through the IETF site a bit, but I=92m= still not sure as to the best process to get this implemented.=A0 I was hoping someone on here could give me some tips on proceeding wit= h this.=A0 From what I can see, I just need to update RFC2790 = with the below information and resubmit.=A0

=A0

I=92d also like to apologize in advance if this is the wro= ng mailing list, but all those dealing specifically with SNMP don=92t seem = to be active anymore.

=A0

RFC 2790

=A0

Add:

=A0

hrStorageAvail OBJECT-TYPE

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SYNTAX=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Integer32= (0..2147483647)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MAX-ACCESS=A0=A0=A0=A0 read-only

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 STATUS=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 current

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DESCRIPTION

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =93The amount of the stor= age represented by this entry

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 that is available to non-= superusers, in units of

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 hrStorageAllocationUnits.= =94

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ::=3D { hrStorageEntry 8 }

=A0

=A0

Thanks,

Sheppy Reno

--bcaec550b3ae02fac704c9475645-- From pbryan@anode.ca Mon Sep 10 10:07:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C9321E8037 for ; Mon, 10 Sep 2012 10:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPO-4DKmMwLv for ; Mon, 10 Sep 2012 10:07:58 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 0F72421F859B for ; Mon, 10 Sep 2012 10:07:58 -0700 (PDT) Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 8058A6156; Mon, 10 Sep 2012 17:07:56 +0000 (UTC) From: "Paul C. Bryan" To: Mark Nottingham In-Reply-To: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> Content-Type: multipart/alternative; boundary="=-AiiasQY9kEXNv+48z+v+" Date: Mon, 10 Sep 2012 10:07:54 -0700 Message-ID: <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Apps Discuss Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 17:07:59 -0000 --=-AiiasQY9kEXNv+48z+v+ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Well, the natural next question is, how do you test for the lack of a value? Slippery slope... Paul On Mon, 2012-09-10 at 21:59 +1000, Mark Nottingham wrote: > That seems like a useful thing; I've tried it out here: > http://trac.tools.ietf.org/wg/appsawg/trac/changeset/112 > > Cheers, > > On 06/09/2012, at 4:42 AM, James M Snell wrote: > > > One additional point, I note that with the current "test" operation, the "value" property is assumed to be required. What if all I want to do is test for the presence of a property? {"test":"/a/b/c","value":null} can be used to test that the property is null, but what if I don't care about the specific value? can I do, {"test":"/a/b/c"} ? > > > > - James > > > > On Wed, Sep 5, 2012 at 8:47 AM, James M Snell wrote: > > Three points... > > > > 1) Re: test ... I would like to see more detail on why "test" would be used in a patch document. Perhaps just by expanding on the example just a bit. > > > > 2) Section 5's discussion of error handling should be expanded a bit. Yes the changes are atomic but a clear example of exactly what that means would be helpful. > > > > Example: This json-patch would result in no changes being made to the document at all. > > > > [ > > {"replace": "/a/b/c", "value": 42}, > > {"test": "/a/b/c", "value": "C"} > > ] > > > > 3) Unless we specifically want to allow for such things, it should be made clear that "test" is not intended to be used as a replacement for other types of http conditionals. For instance, I could imagine someone doing something like... > > > > [ > > {"test": "/foo/last-updated", "value": "2012-12-12T12:12:12Z"}, > > ("add": "/a/b/c", "value": 42} > > ] > > > > Or... > > > > [ > > {"test": "/@etag", "value": "ABC123"}, > > ("add": "/a/b/c", "value": 42} > > ] > > > > - James > > > > > > On Wed, Sep 5, 2012 at 12:18 AM, Mark Nottingham wrote: > > I've just submitted revised json-pointer and json-patch documents, based upon feedback. > > > > As far as I can tell, the only open issue on JSON-Patch is about 'test': > > http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7 > > > > In Vancouver, we said that we'd wait for implementation experience to see if 'test' is worthwhile. > > > > In the meantime, I've found two implementations of json-patch "in the wild": > > https://github.com/stefankoegl/python-json-patch > > https://github.com/bruth/jsonpatch-js > > > > Both are somewhat old, and both support 'test'. > > > > As such, I'd suggest we let 'test' remain in the spec (I think there are good arguments for it anyway), and ship it. > > > > Make sense? > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-AiiasQY9kEXNv+48z+v+ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Well, the natural next question is, how do you test for the lack of a value? Slippery slope...

Paul

On Mon, 2012-09-10 at 21:59 +1000, Mark Nottingham wrote: 
That seems like a useful thing; I've tried it out here:
  http://trac.tools.ietf.org/wg/appsawg/trac/changeset/112

Cheers,

On 06/09/2012, at 4:42 AM, James M Snell <jasnell@gmail.com> wrote:

> One additional point, I note that with the current "test" operation, the "value" property is assumed to be required. What if all I want to do is test for the presence of a property? {"test":"/a/b/c","value":null} can be used to test that the property is null, but what if I don't care about the specific value? can I do, {"test":"/a/b/c"} ?
> 
> - James
> 
> On Wed, Sep 5, 2012 at 8:47 AM, James M Snell <jasnell@gmail.com> wrote:
> Three points... 
> 
> 1) Re: test ... I would like to see more detail on why "test" would be used in a patch document. Perhaps just by expanding on the example just a bit.
> 
> 2) Section 5's discussion of error handling should be expanded a bit. Yes the changes are atomic but a clear example of exactly what that means would be helpful.
> 
> Example: This json-patch would result in no changes being made to the document at all.
> 
> [
>  {"replace": "/a/b/c", "value": 42},
>  {"test": "/a/b/c", "value": "C"}
> ]
> 
> 3) Unless we specifically want to allow for such things, it should be made clear that "test" is not intended to be used as a replacement for other types of http conditionals. For instance, I could imagine someone doing something like...
> 
> [
>  {"test": "/foo/last-updated", "value": "2012-12-12T12:12:12Z"},
>  ("add": "/a/b/c", "value": 42}
> ]
> 
> Or...
> 
> [
>  {"test": "/@etag", "value": "ABC123"},
>  ("add": "/a/b/c", "value": 42}
> ]
> 
> - James
> 
> 
> On Wed, Sep 5, 2012 at 12:18 AM, Mark Nottingham <mnot@mnot.net> wrote:
> I've just submitted revised json-pointer and json-patch documents, based upon feedback.
> 
> As far as I can tell, the only open issue on JSON-Patch is about 'test':
>   http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7
> 
> In Vancouver, we said that we'd wait for implementation experience to see if 'test' is worthwhile.
> 
> In the meantime, I've found two implementations of json-patch "in the wild":
>   https://github.com/stefankoegl/python-json-patch
>   https://github.com/bruth/jsonpatch-js
> 
> Both are somewhat old, and both support 'test'.
> 
> As such, I'd suggest we let 'test' remain in the spec (I think there are good arguments for it anyway), and ship it.
> 
> Make sense?
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> 

--
Mark Nottingham   http://www.mnot.net/



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--=-AiiasQY9kEXNv+48z+v+-- From jasnell@gmail.com Mon Sep 10 10:08:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E15C21E8049 for ; Mon, 10 Sep 2012 10:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gz-Bief6muqa for ; Mon, 10 Sep 2012 10:08:55 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 098D821E8047 for ; Mon, 10 Sep 2012 10:08:54 -0700 (PDT) Received: by lbky2 with SMTP id y2so1481339lbk.31 for ; Mon, 10 Sep 2012 10:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W0FSUdjbp08b512Qhfl1h8Q25tHe31isSgnRpGecGk4=; b=am0yeBjUWVS/egltPrz/ir9b9TWOFd1urtgfHwJNYRgmePosBULIXo+HzFimDXyVSo 7bYE0nFwVU/tbPTjfNmibKeLxe5vfL1XP4PQp9ra+koYli9Aqg75zt4zIiO1zq+4GVVB bAjRcuZq9ZCMuEqIxkCkIL0FYGkyM8m0J6CGKwWxViLRJuXqFCcBEyIayglsqPMU5jOW iSkVIR1/WEQW3/d9YLFMhKPHOrEynOwg2LzwhWZWiI0Ndd7rxyJmZQlihV0vmeN+8wsT CEkjbNwPXRmNDEG/lNxgFKfsgJveH0Wc27RW8D1yioFUcyaxo6jd+S5M99hO8f0n38VR qMcw== Received: by 10.152.123.206 with SMTP id mc14mr13286715lab.33.1347296933766; Mon, 10 Sep 2012 10:08:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.88.204 with HTTP; Mon, 10 Sep 2012 10:08:33 -0700 (PDT) In-Reply-To: <504E1116.6060808@status.net> References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> From: James M Snell Date: Mon, 10 Sep 2012 10:08:33 -0700 Message-ID: To: Evan Prodromou Content-Type: multipart/alternative; boundary=f46d044284ec24e7b804c95c0364 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 17:08:56 -0000 --f46d044284ec24e7b804c95c0364 Content-Type: text/plain; charset=UTF-8 I've seen similar kinds of issues pop up many times in other places. Within the Activity Streams spec, for instance, the way we dealt with this was to have a one spec for the Atom-based Activity Streams stuff and one spec for the JSON-based work. Emphasis moving forward, however, has been on the JSON spec with an eye towards eventually deprecating the Atom extensions. Such deprecation does not need to happen automatically so long as there is a consistent message and strategy moving forward. - James On Mon, Sep 10, 2012 at 9:11 AM, Evan Prodromou wrote: > On 12-09-10 10:43 AM, Melvin Carvalho wrote: > > > > On 7 September 2012 15:17, Evan Prodromou wrote: > >> My name is Evan Prodromou; I'm the lead developer for StatusNet, and also >> the creator and maintainer of the NodeJS "webfinger" library. >> >> Webfinger is not being created ex nihilo; there are at least half a dozen >> implementations, and none of the servers I've seen support JSON. >> >> The interests of existing and new implementers aren't served when >> specifications fail to describe the existing state of the world. >> >> I think there are ways to structure the specification to strongly guide >> new implementers toward the JRD implementation without failing to document >> the existence of XRD implementations. >> > > My understanding was that consensus was reached that JSON would be the > only REQUIRED format to be supported. > > If I've understood correctly, this does not preclude also supporting XML, > for those that wish to. This would still mean that current XML > implementations will continue to operate as they are, but just that new > implementations would start including JSON, and, over time, hopefully older > ones will add JSON too. > > > Changing the semantics of the "lrdd" link relation from "XRD by default" > to "JRD by default" is unnecessarily damaging to existing implementations. > > It does not serve new implementers well if the specification doesn't > describe the way current implementations work, or give a reasonable upgrade > path. > > I very much like the way RFC 6415 deals with XRD and JRD and I think it is > a great model to follow with Webfinger: XRD by default, and easy mechanisms > (content negotiation or a separate endpoint) to get JRD. > > > -Evan > > -- > Evan Prodromou, CEO and Founder, StatusNet Inc. > 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 > E: evan@status.net P: +1-514-554-3826 > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d044284ec24e7b804c95c0364 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've seen similar kinds of issues = pop up many times in other places. Within the Activity Streams spec, for in= stance, the way we dealt with this was to have a one spec for the Atom-base= d Activity Streams stuff and one spec for the JSON-based work. Emphasis mov= ing forward, however, has been on the JSON spec with an eye towards eventua= lly deprecating the Atom extensions. Such deprecation does not need to happ= en automatically so long as there is a consistent message and strategy movi= ng forward.=C2=A0

- James

On Mo= n, Sep 10, 2012 at 9:11 AM, Evan Prodromou <evan@status.net> w= rote:
=20 =20 =20
On 12-09-10 10:43 AM, Melvin Carvalho wrote:


On 7 September 2012 15:17, Evan Prodromou <evan@status.net> wrote:
My name is Evan Prodromou; I'm the lead developer for StatusNet, and also the creator and maintainer of the NodeJS "webfinger" library.

Webfinger is not being created ex nihilo; there are at least half a dozen implementations, and none of the servers I've seen support JSON.

The interests of existing and new implementers aren't served when specifications fail to describe the existing state of the world.

I think there are ways to structure the specification to strongly guide new implementers toward the JRD implementation without failing to document the existence of XRD implementations.

My understanding was that consensus was reached that JSON would be the only REQUIRED format to be supported.

If I've understood correctly, this does not preclude also supporting XML, for those that wish to.=C2=A0 This would still me= an that current XML implementations will continue to operate as they are, but just that new implementations would start including JSON, and, over time, hopefully older ones will add JSON too.=C2=A0=C2=A0

Changing the semantics of the "lrdd" link relation from "= ;XRD by default" to "JRD by default" is unnecessarily damaging t= o existing implementations.

It does not serve new implementers well if the specification doesn'= t describe the way current implementations work, or give a reasonable upgrade path.

I very much like the way RFC 6415 deals with XRD and JRD and I think it is a great model to follow with Webfinger: XRD by default, and easy mechanisms (content negotiation or a separate endpoint) to get JRD.


-Evan
--=20
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@status.net=
 P: +1-514-554-3826

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--f46d044284ec24e7b804c95c0364-- From jasnell@gmail.com Mon Sep 10 10:18:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DFB21F8585 for ; Mon, 10 Sep 2012 10:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMgnxve-rt3N for ; Mon, 10 Sep 2012 10:18:37 -0700 (PDT) Received: from mail-lpp01m010-f49.google.com (mail-lpp01m010-f49.google.com [209.85.215.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6047621F854D for ; Mon, 10 Sep 2012 10:18:36 -0700 (PDT) Received: by lagu2 with SMTP id u2so1706308lag.22 for ; Mon, 10 Sep 2012 10:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=O65wBlZN7JvRclqzjv1Uf+uDqa+rF59X01ndDM3ei5s=; b=yes0bo/3KYl5pA36RIKYoENPvVENo3sV+9CtuNk0aspnT0O7OrxRbXwlomR2+CGOur DKqvNLvnYmslQeqQu9toSFmWpkaQOHJTfOC7WiuGkRppSEi7XpzhNC6851UwQhbefA0n ReiEPyR9yXfocM0/BA/YN66Q3/8umRhMuSXRm8+hcho21rD+UAs8LqTUbS+vnHxoP1rT sS8b1fQ2Q95OJNVlQ6ge/ifyPCcLpdWGRVRU4SWOz+wSotXsQfINX4woIUKSYD6etaJO BfXEsLvIY5GG9L34SQ7Hi4JV00wyC2s/Lgk0wqLJp1waoJdltApqIMNhZPyrt/xhY+mE jTxA== Received: by 10.112.17.131 with SMTP id o3mr5285515lbd.6.1347297514996; Mon, 10 Sep 2012 10:18:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.88.204 with HTTP; Mon, 10 Sep 2012 10:18:14 -0700 (PDT) In-Reply-To: <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> From: James M Snell Date: Mon, 10 Sep 2012 10:18:14 -0700 Message-ID: To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=bcaec554d330c9c2b604c95c2528 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 17:18:38 -0000 --bcaec554d330c9c2b604c95c2528 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sadly rfc4627 does not allow for the use of the undefined keyword as a value option so the best we'd have there is the use of null.. {"test":"/a/b/c", "value": null} Seems simple enough. - James On Mon, Sep 10, 2012 at 10:07 AM, Paul C. Bryan wrote: > ** > Well, the natural next question is, how do you test for the lack of a > value? Slippery slope... > > Paul > > > On Mon, 2012-09-10 at 21:59 +1000, Mark Nottingham wrote: > > That seems like a useful thing; I've tried it out here: > http://trac.tools.ietf.org/wg/appsawg/trac/changeset/112 > > Cheers, > > On 06/09/2012, at 4:42 AM, James M Snell wrote: > > > One additional point, I note that with the current "test" operation, th= e "value" property is assumed to be required. What if all I want to do is t= est for the presence of a property? {"test":"/a/b/c","value":null} can be u= sed to test that the property is null, but what if I don't care about the s= pecific value? can I do, {"test":"/a/b/c"} ? > > > > - James > > > > On Wed, Sep 5, 2012 at 8:47 AM, James M Snell wrote= : > > Three points... > > > > 1) Re: test ... I would like to see more detail on why "test" would be = used in a patch document. Perhaps just by expanding on the example just a b= it. > > > > 2) Section 5's discussion of error handling should be expanded a bit. Y= es the changes are atomic but a clear example of exactly what that means wo= uld be helpful. > > > > Example: This json-patch would result in no changes being made to the d= ocument at all. > > > > [ > > {"replace": "/a/b/c", "value": 42}, > > {"test": "/a/b/c", "value": "C"} > > ] > > > > 3) Unless we specifically want to allow for such things, it should be m= ade clear that "test" is not intended to be used as a replacement for other= types of http conditionals. For instance, I could imagine someone doing so= mething like... > > > > [ > > {"test": "/foo/last-updated", "value": "2012-12-12T12:12:12Z"}, > > ("add": "/a/b/c", "value": 42} > > ] > > > > Or... > > > > [ > > {"test": "/@etag", "value": "ABC123"}, > > ("add": "/a/b/c", "value": 42} > > ] > > > > - James > > > > > > On Wed, Sep 5, 2012 at 12:18 AM, Mark Nottingham wrote: > > I've just submitted revised json-pointer and json-patch documents, base= d upon feedback. > > > > As far as I can tell, the only open issue on JSON-Patch is about 'test'= : > > http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7 > > > > In Vancouver, we said that we'd wait for implementation experience to s= ee if 'test' is worthwhile. > > > > In the meantime, I've found two implementations of json-patch "in the w= ild": > > https://github.com/stefankoegl/python-json-patch > > https://github.com/bruth/jsonpatch-js > > > > Both are somewhat old, and both support 'test'. > > > > As such, I'd suggest we let 'test' remain in the spec (I think there ar= e good arguments for it anyway), and ship it. > > > > Make sense? > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing listapps-discuss@ietf.orghttps://www.ietf.org/mailma= n/listinfo/apps-discuss > > > --bcaec554d330c9c2b604c95c2528 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sadly rfc4627 does not allow for the u= se of the undefined keyword as a value option so the best we'd have the= re is the use of null..
=C2=A0 {"test&q= uot;:"/a/b/c", "value": null}

Seems simple enough.

- James

On Mon, Sep 10, 2012 at 10:07 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
=20 =20
Well, the natural next question is, how do you test for the lack of a value= ? Slippery slope...

Paul


On Mon, 2012-09-10 at 21:59 +1000, Mark Nottingham wrote: 
That seems like a useful thing; I've tried it out here:
  http://trac.tools.ietf.org/wg/appsawg/trac/changeset/112

Cheers,

On 06/09/2012, at 4:42 AM, James M Snell <jasnell@gmail.com> wrote:

> One additional point, I note that with the current "test" op=
eration, the "value" property is assumed to be required. What if =
all I want to do is test for the presence of a property? {"test":=
"/a/b/c","value":null} can be used to test that the pro=
perty is null, but what if I don't care about the specific value? can I=
 do, {"test":"/a/b/c"} ?
>=20
> - James
>=20
> On Wed, Sep 5, 2012 at 8:47 AM, James M Snell <jasnell@gmail.com> wrote:
> Three points...=20
>=20
> 1) Re: test ... I would like to see more detail on why "test"=
; would be used in a patch document. Perhaps just by expanding on the examp=
le just a bit.
>=20
> 2) Section 5's discussion of error handling should be expanded a b=
it. Yes the changes are atomic but a clear example of exactly what that mea=
ns would be helpful.
>=20
> Example: This json-patch would result in no changes being made to the =
document at all.
>=20
> [
>  {"replace": "/a/b/c", "value": 42},
>  {"test": "/a/b/c", "value": "C&quo=
t;}
> ]
>=20
> 3) Unless we specifically want to allow for such things, it should be =
made clear that "test" is not intended to be used as a replacemen=
t for other types of http conditionals. For instance, I could imagine someo=
ne doing something like...
>=20
> [
>  {"test": "/foo/last-updated", "value": =
"2012-12-12T12:12:12Z"},
>  ("add": "/a/b/c", "value": 42}
> ]
>=20
> Or...
>=20
> [
>  {"test": "/@etag", "value": "ABC12=
3"},
>  ("add": "/a/b/c", "value": 42}
> ]
>=20
> - James
>=20
>=20
> On Wed, Sep 5, 2012 at 12:18 AM, Mark Nottingham <mnot@mnot.net> wrote:
> I've just submitted revised json-pointer and json-patch documents,=
 based upon feedback.
>=20
> As far as I can tell, the only open issue on JSON-Patch is about '=
test':
>   http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7
>=20
> In Vancouver, we said that we'd wait for implementation experience=
 to see if 'test' is worthwhile.
>=20
> In the meantime, I've found two implementations of json-patch &quo=
t;in the wild":
>   https://github.com/stefankoegl/python-json-patch
>   =
https://github.com/bruth/jsonpatch-js
>=20
> Both are somewhat old, and both support 'test'.
>=20
> As such, I'd suggest we let 'test' remain in the spec (I t=
hink there are good arguments for it anyway), and ship it.
>=20
> Make sense?
>=20
> --
> Mark Nottingham   h=
ttp://www.mnot.net/
>=20
>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discus=
s@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
>=20

--
Mark Nottingham   http:/=
/www.mnot.net/



_______________________________________________
apps-discuss mailing list
apps-discuss@iet=
f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--bcaec554d330c9c2b604c95c2528-- From pbryan@anode.ca Mon Sep 10 10:34:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609B921F863F for ; Mon, 10 Sep 2012 10:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkqyJxwzbbrY for ; Mon, 10 Sep 2012 10:34:08 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 4B22E21F8623 for ; Mon, 10 Sep 2012 10:34:08 -0700 (PDT) Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 778FE6156; Mon, 10 Sep 2012 17:34:07 +0000 (UTC) From: "Paul C. Bryan" To: James M Snell In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> Content-Type: multipart/alternative; boundary="=-AbrSXMBa31rnVhrR5iTU" Date: Mon, 10 Sep 2012 10:34:05 -0700 Message-ID: <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 17:34:09 -0000 --=-AbrSXMBa31rnVhrR5iTU Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Unfortunately, null is a testable value and should not be interpreted to mean lack of value. The original intent the test operation is to test for a known partial state of a resource before applying a partial change. We're now veering out of that into a new territory of "handy features" without any use case or other explicit scope. I recommend we do not adopt testing for presence unless we can clearly bound its scope. Paul On Mon, 2012-09-10 at 10:18 -0700, James M Snell wrote: > Sadly rfc4627 does not allow for the use of the undefined keyword as a > value option so the best we'd have there is the use of null.. > > > > {"test":"/a/b/c", "value": null} > > > Seems simple enough. > > > - James > > > On Mon, Sep 10, 2012 at 10:07 AM, Paul C. Bryan > wrote: > > Well, the natural next question is, how do you test for the > lack of a value? Slippery slope... > > Paul > > > > On Mon, 2012-09-10 at 21:59 +1000, Mark Nottingham wrote: > > > That seems like a useful thing; I've tried it out here: > > http://trac.tools.ietf.org/wg/appsawg/trac/changeset/112 > > > > Cheers, > > > > On 06/09/2012, at 4:42 AM, James M Snell wrote: > > > > > One additional point, I note that with the current "test" operation, the "value" property is assumed to be required. What if all I want to do is test for the presence of a property? {"test":"/a/b/c","value":null} can be used to test that the property is null, but what if I don't care about the specific value? can I do, {"test":"/a/b/c"} ? > > > > > > - James > > > > > > On Wed, Sep 5, 2012 at 8:47 AM, James M Snell wrote: > > > Three points... > > > > > > 1) Re: test ... I would like to see more detail on why "test" would be used in a patch document. Perhaps just by expanding on the example just a bit. > > > > > > 2) Section 5's discussion of error handling should be expanded a bit. Yes the changes are atomic but a clear example of exactly what that means would be helpful. > > > > > > Example: This json-patch would result in no changes being made to the document at all. > > > > > > [ > > > {"replace": "/a/b/c", "value": 42}, > > > {"test": "/a/b/c", "value": "C"} > > > ] > > > > > > 3) Unless we specifically want to allow for such things, it should be made clear that "test" is not intended to be used as a replacement for other types of http conditionals. For instance, I could imagine someone doing something like... > > > > > > [ > > > {"test": "/foo/last-updated", "value": "2012-12-12T12:12:12Z"}, > > > ("add": "/a/b/c", "value": 42} > > > ] > > > > > > Or... > > > > > > [ > > > {"test": "/@etag", "value": "ABC123"}, > > > ("add": "/a/b/c", "value": 42} > > > ] > > > > > > - James > > > > > > > > > On Wed, Sep 5, 2012 at 12:18 AM, Mark Nottingham wrote: > > > I've just submitted revised json-pointer and json-patch documents, based upon feedback. > > > > > > As far as I can tell, the only open issue on JSON-Patch is about 'test': > > > http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7 > > > > > > In Vancouver, we said that we'd wait for implementation experience to see if 'test' is worthwhile. > > > > > > In the meantime, I've found two implementations of json-patch "in the wild": > > > https://github.com/stefankoegl/python-json-patch > > > https://github.com/bruth/jsonpatch-js > > > > > > Both are somewhat old, and both support 'test'. > > > > > > As such, I'd suggest we let 'test' remain in the spec (I think there are good arguments for it anyway), and ship it. > > > > > > Make sense? > > > > > > -- > > > Mark Nottingham http://www.mnot.net/ > > > > > > > > > > > > _______________________________________________ > > > apps-discuss mailing list > > > apps-discuss@ietf.org > > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > --=-AbrSXMBa31rnVhrR5iTU Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Unfortunately, null is a testable value and should not be interpreted to mean lack of value.

The original intent the test operation is to test for a known partial state of a resource before applying a partial change. We're now veering out of that into a new territory of "handy features" without any use case or other explicit scope. I recommend we do not adopt testing for presence unless we can clearly bound its scope.

Paul

On Mon, 2012-09-10 at 10:18 -0700, James M Snell wrote:
Sadly rfc4627 does not allow for the use of the undefined keyword as a value option so the best we'd have there is the use of null..


  {"test":"/a/b/c", "value": null}


Seems simple enough.


- James

On Mon, Sep 10, 2012 at 10:07 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
Well, the natural next question is, how do you test for the lack of a value? Slippery slope...

Paul


On Mon, 2012-09-10 at 21:59 +1000, Mark Nottingham wrote: 
That seems like a useful thing; I've tried it out here:
  http://trac.tools.ietf.org/wg/appsawg/trac/changeset/112

Cheers,

On 06/09/2012, at 4:42 AM, James M Snell <jasnell@gmail.com> wrote:

> One additional point, I note that with the current "test" operation, the "value" property is assumed to be required. What if all I want to do is test for the presence of a property? {"test":"/a/b/c","value":null} can be used to test that the property is null, but what if I don't care about the specific value? can I do, {"test":"/a/b/c"} ?
> 
> - James
> 
> On Wed, Sep 5, 2012 at 8:47 AM, James M Snell <jasnell@gmail.com> wrote:
> Three points... 
> 
> 1) Re: test ... I would like to see more detail on why "test" would be used in a patch document. Perhaps just by expanding on the example just a bit.
> 
> 2) Section 5's discussion of error handling should be expanded a bit. Yes the changes are atomic but a clear example of exactly what that means would be helpful.
> 
> Example: This json-patch would result in no changes being made to the document at all.
> 
> [
>  {"replace": "/a/b/c", "value": 42},
>  {"test": "/a/b/c", "value": "C"}
> ]
> 
> 3) Unless we specifically want to allow for such things, it should be made clear that "test" is not intended to be used as a replacement for other types of http conditionals. For instance, I could imagine someone doing something like...
> 
> [
>  {"test": "/foo/last-updated", "value": "2012-12-12T12:12:12Z"},
>  ("add": "/a/b/c", "value": 42}
> ]
> 
> Or...
> 
> [
>  {"test": "/@etag", "value": "ABC123"},
>  ("add": "/a/b/c", "value": 42}
> ]
> 
> - James
> 
> 
> On Wed, Sep 5, 2012 at 12:18 AM, Mark Nottingham <mnot@mnot.net> wrote:
> I've just submitted revised json-pointer and json-patch documents, based upon feedback.
> 
> As far as I can tell, the only open issue on JSON-Patch is about 'test':
>   http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7
> 
> In Vancouver, we said that we'd wait for implementation experience to see if 'test' is worthwhile.
> 
> In the meantime, I've found two implementations of json-patch "in the wild":
>   https://github.com/stefankoegl/python-json-patch
>   https://github.com/bruth/jsonpatch-js
> 
> Both are somewhat old, and both support 'test'.
> 
> As such, I'd suggest we let 'test' remain in the spec (I think there are good arguments for it anyway), and ship it.
> 
> Make sense?
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> 

--
Mark Nottingham   http://www.mnot.net/



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss





--=-AbrSXMBa31rnVhrR5iTU-- From superuser@gmail.com Mon Sep 10 11:35:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7479021F859E for ; Mon, 10 Sep 2012 11:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg3GA4Xc+F2c for ; Mon, 10 Sep 2012 11:35:30 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A15FA21F859A for ; Mon, 10 Sep 2012 11:35:29 -0700 (PDT) Received: by lbky2 with SMTP id y2so1545133lbk.31 for ; Mon, 10 Sep 2012 11:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=aMxeeY1LVetW+G+zUuqEr+XlJ4bdmRYOuPbUaL55lGs=; b=t0ipBfA0h33WoOvxOM4ze+z+P2WAI6r9FUIKU+xAUTTXFp94XTDxQmfZF+74dr/VFA 7Uo2WMhS2c16/ltOiUd1SxyKh14/++bHejtPcyfHAXIwKH1s2IgYIggAcIVATHrA8lxg MKWNzVR3c7Jogw1qOA89f4XK1oMoG4uGiXSVb87yCXm0KUNBvhgCjCCJ4boyNVGo4juG hnz124/ZTsDuSAoP+ddmC70Bdoq630828JZMCJ1+SIKK5NGSHNO/R/3VEo1JyzqbOZsX HQ3piwsN7elGk8G88OVOmcctwhdbVoHlk2KAaUiZrJ1IFlJQCJeWyY68JoABerUYCjd/ 7Ypw== MIME-Version: 1.0 Received: by 10.112.51.228 with SMTP id n4mr5298888lbo.55.1347302128496; Mon, 10 Sep 2012 11:35:28 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Mon, 10 Sep 2012 11:35:28 -0700 (PDT) Date: Mon, 10 Sep 2012 11:35:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] draft-ietf-appsawg-media-type-suffix-regs editor X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:35:30 -0000 Colleagues, Due to the fact that the main author of the above document has had very limited time to work on it, and since its stalled progress is holding up the publication of draft-ietf-appsawg-media-type-regs, we've appointed Alexey Melnikov as an editor for this document to help complete its processing in the working group. We believe there are only a few issues outstanding, and Alexey has guidance for completing the work. Please be responsive to any requests he has for comments on the remaining issues so we can get this to the IESG at long last. Thank you, -MSK, APPSAWG co-chair From ned.freed@mrochek.com Mon Sep 10 11:41:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB89121E8049 for ; Mon, 10 Sep 2012 11:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2YGZJ638pdc for ; Mon, 10 Sep 2012 11:41:13 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 70B3421E8055 for ; Mon, 10 Sep 2012 11:41:13 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OK38ANXLY8007A37@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 10 Sep 2012 11:38:03 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Mon, 10 Sep 2012 11:38:01 -0700 (PDT) Message-id: <01OK38AMPYYU0006TF@mauve.mrochek.com> Date: Mon, 10 Sep 2012 11:37:23 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 10 Sep 2012 11:35:28 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: "Murray S. Kucherawy" Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-media-type-suffix-regs editor X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:41:14 -0000 Thanks Alexey and Murray for taking this step. Ned > Colleagues, > Due to the fact that the main author of the above document has had > very limited time to work on it, and since its stalled progress is > holding up the publication of draft-ietf-appsawg-media-type-regs, > we've appointed Alexey Melnikov as an editor for this document to help > complete its processing in the working group. > We believe there are only a few issues outstanding, and Alexey has > guidance for completing the work. Please be responsive to any > requests he has for comments on the remaining issues so we can get > this to the IESG at long last. > Thank you, > -MSK, APPSAWG co-chair > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From jasnell@gmail.com Mon Sep 10 11:46:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1C821F8715 for ; Mon, 10 Sep 2012 11:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDxbij7DUwQn for ; Mon, 10 Sep 2012 11:46:37 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id CBB8621F8707 for ; Mon, 10 Sep 2012 11:46:24 -0700 (PDT) Received: by lbbgf7 with SMTP id gf7so1858805lbb.22 for ; Mon, 10 Sep 2012 11:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yMnxY65evP2UqiQJC8vG32WDltnD9QfDgq0ellUcOTw=; b=q0SFjBb5ri3JBGDFBSmMClbSHGWeOpIIJFwk+L3bJM38vY7DEkimGidkFtjSQnmRTe oTJXi2qBZY11k77vT5KrOMDTmqGoCKmliOhbl8ZDfsOV1wbQcsdkxjApyv+ZEyhSKi8G 0TEESRyXxdPDkvikZnB8fclFWJbn/MYmVpA5h23MF1EvgEzjn2uhTg0zVVnmkCqsmB57 MuLH6KBcYIJ11mX/RUJkzgRf8Fk3CfV52hMKN1PVLmj8i3dvf3S1lxH0rXGhMILW7S3J /l26nxdjOhO6rWEv02FiGKDj64o9p3p7rzyJHPRoEvJEuzuZMHPaflHxJiS6/Uy02KC6 AYCQ== Received: by 10.152.132.168 with SMTP id ov8mr13501014lab.0.1347302783533; Mon, 10 Sep 2012 11:46:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.88.204 with HTTP; Mon, 10 Sep 2012 11:46:02 -0700 (PDT) In-Reply-To: <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> From: James M Snell Date: Mon, 10 Sep 2012 11:46:02 -0700 Message-ID: To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=f46d043085f4d140e404c95d5f8e Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:46:39 -0000 --f46d043085f4d140e404c95d5f8e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan wrote: > ** > Unfortunately, null is a testable value and should not be interpreted to > mean lack of value. > > Indeed, but I'd argue that the two cases are semantically equivalent enough for the such differences to be irrelevant. Particularly since many (if not most) json vocabularies tend to treat null and undefined as being equivalent. There is a clear use case for this and we can bind the scope simply by saying that, within json patch, undefined and null are equivalent= . - James > The original intent the test operation is to test for a known partial > state of a resource before applying a partial change. We're now veering o= ut > of that into a new territory of "handy features" without any use case or > other explicit scope. I recommend we do not adopt testing for presence > unless we can clearly bound its scope. > > Paul > > > On Mon, 2012-09-10 at 10:18 -0700, James M Snell wrote: > > Sadly rfc4627 does not allow for the use of the undefined keyword as a > value option so the best we'd have there is the use of null.. > > > > {"test":"/a/b/c", "value": null} > > > > Seems simple enough. > > > > - James > > On Mon, Sep 10, 2012 at 10:07 AM, Paul C. Bryan wrote: > > Well, the natural next question is, how do you test for the lack of a > value? Slippery slope... > > Paul > > > > On Mon, 2012-09-10 at 21:59 +1000, Mark Nottingham wrote: > > That seems like a useful thing; I've tried it out here: > http://trac.tools.ietf.org/wg/appsawg/trac/changeset/112 > > Cheers, > > On 06/09/2012, at 4:42 AM, James M Snell wrote: > > > One additional point, I note that with the current "test" operation, th= e "value" property is assumed to be required. What if all I want to do is t= est for the presence of a property? {"test":"/a/b/c","value":null} can be u= sed to test that the property is null, but what if I don't care about the s= pecific value? can I do, {"test":"/a/b/c"} ? > > > > - James > > > > On Wed, Sep 5, 2012 at 8:47 AM, James M Snell wrote= : > > Three points... > > > > 1) Re: test ... I would like to see more detail on why "test" would be = used in a patch document. Perhaps just by expanding on the example just a b= it. > > > > 2) Section 5's discussion of error handling should be expanded a bit. Y= es the changes are atomic but a clear example of exactly what that means wo= uld be helpful. > > > > Example: This json-patch would result in no changes being made to the d= ocument at all. > > > > [ > > {"replace": "/a/b/c", "value": 42}, > > {"test": "/a/b/c", "value": "C"} > > ] > > > > 3) Unless we specifically want to allow for such things, it should be m= ade clear that "test" is not intended to be used as a replacement for other= types of http conditionals. For instance, I could imagine someone doing so= mething like... > > > > [ > > {"test": "/foo/last-updated", "value": "2012-12-12T12:12:12Z"}, > > ("add": "/a/b/c", "value": 42} > > ] > > > > Or... > > > > [ > > {"test": "/@etag", "value": "ABC123"}, > > ("add": "/a/b/c", "value": 42} > > ] > > > > - James > > > > > > On Wed, Sep 5, 2012 at 12:18 AM, Mark Nottingham wrote: > > I've just submitted revised json-pointer and json-patch documents, base= d upon feedback. > > > > As far as I can tell, the only open issue on JSON-Patch is about 'test'= : > > http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7 > > > > In Vancouver, we said that we'd wait for implementation experience to s= ee if 'test' is worthwhile. > > > > In the meantime, I've found two implementations of json-patch "in the w= ild": > > https://github.com/stefankoegl/python-json-patch > > https://github.com/bruth/jsonpatch-js > > > > Both are somewhat old, and both support 'test'. > > > > As such, I'd suggest we let 'test' remain in the spec (I think there ar= e good arguments for it anyway), and ship it. > > > > Make sense? > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing listapps-discuss@ietf.orghttps://www.ietf.org/mailma= n/listinfo/apps-discuss > > > > > > > --f46d043085f4d140e404c95d5f8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan <<= a href=3D"mailto:pbryan@anode.ca" target=3D"_blank">pbryan@anode.ca>= wrote:
=20 =20
Unfortunately, null is a testable value and should not be interpreted to me= an lack of value.


Indeed, but I'd argue that t= he two cases are semantically equivalent enough for the such differences to= be irrelevant. Particularly since many (if not most) json vocabularies ten= d to treat null and undefined as being equivalent. There is a clear use cas= e for this and we can bind the scope simply by saying that, within json pat= ch, undefined and null are equivalent.

- James
=C2=A0
The original intent the test operation is to test for a known partial state= of a resource before applying a partial change. We're now veering out = of that into a new territory of "handy features" without any use = case or other explicit scope. I recommend we do not adopt testing for prese= nce unless we can clearly bound its scope.

Paul


On Mon, 2012-09-10 at 10:18 -0700, James M Snell wrote:
Sadly rfc4627 does not allow for the use of the undefined keyword as a = value option so the best we'd have there is the use of null..


=C2=A0 {"test":"/a/b/c", "value": null}


Seems simple enough.


- James

On Mon, Sep 10, 2012 at 10:07 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
Well, the natural next question is, how do you test for the lack of= a value? Slippery slope...

Paul


On Mon, 2012-09-10 at 21:59 +1000, Mark Nottingham wrote:=20 
That seems like a useful thing; I've tried it out here:
  http://trac.tools.ietf.org/wg/appsawg/trac/changeset/112

Cheers,

On 06/09/2012, at 4:42 AM, James M Snell <jasnell@gmail.com> wrote:

> One additional point, I note that with the current "test" op=
eration, the "value" property is assumed to be required. What if =
all I want to do is test for the presence of a property? {"test":=
"/a/b/c","value":null} can be used to test that the pro=
perty is null, but what if I don't care about the specific value? can I=
 do, {"test":"/a/b/c"} ?
>=20
> - James
>=20
> On Wed, Sep 5, 2012 at 8:47 AM, James M Snell <jasnell@gmail.com> wrote:
> Three points...=20
>=20
> 1) Re: test ... I would like to see more detail on why "test"=
; would be used in a patch document. Perhaps just by expanding on the examp=
le just a bit.
>=20
> 2) Section 5's discussion of error handling should be expanded a b=
it. Yes the changes are atomic but a clear example of exactly what that mea=
ns would be helpful.
>=20
> Example: This json-patch would result in no changes being made to the =
document at all.
>=20
> [
>  {"replace": "/a/b/c", "value": 42},
>  {"test": "/a/b/c", "value": "C&quo=
t;}
> ]
>=20
> 3) Unless we specifically want to allow for such things, it should be =
made clear that "test" is not intended to be used as a replacemen=
t for other types of http conditionals. For instance, I could imagine someo=
ne doing something like...
>=20
> [
>  {"test": "/foo/last-updated", "value": =
"2012-12-12T12:12:12Z"},
>  ("add": "/a/b/c", "value": 42}
> ]
>=20
> Or...
>=20
> [
>  {"test": "/@etag", "value": "ABC12=
3"},
>  ("add": "/a/b/c", "value": 42}
> ]
>=20
> - James
>=20
>=20
> On Wed, Sep 5, 2012 at 12:18 AM, Mark Nottingham <mnot@mnot.net> wrote:
> I've just submitted revised json-pointer and json-patch documents,=
 based upon feedback.
>=20
> As far as I can tell, the only open issue on JSON-Patch is about '=
test':
>   http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7
>=20
> In Vancouver, we said that we'd wait for implementation experience=
 to see if 'test' is worthwhile.
>=20
> In the meantime, I've found two implementations of json-patch &quo=
t;in the wild":
>   https://github.com/stefankoegl/python-json-patch
>   =
https://github.com/bruth/jsonpatch-js
>=20
> Both are somewhat old, and both support 'test'.
>=20
> As such, I'd suggest we let 'test' remain in the spec (I t=
hink there are good arguments for it anyway), and ship it.
>=20
> Make sense?
>=20
> --
> Mark Nottingham   h=
ttp://www.mnot.net/
>=20
>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discus=
s@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
>=20

--
Mark Nottingham   http:/=
/www.mnot.net/



_______________________________________________
apps-discuss mailing list
apps-discuss@iet=
f.org
https://www.ietf.org/mailman/listinfo/apps-discuss






--f46d043085f4d140e404c95d5f8e-- From pbryan@anode.ca Mon Sep 10 11:59:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5812021E808A for ; Mon, 10 Sep 2012 11:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIojX84Z6f+0 for ; Mon, 10 Sep 2012 11:59:25 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id C160A21E8089 for ; Mon, 10 Sep 2012 11:59:25 -0700 (PDT) Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 881A26156; Mon, 10 Sep 2012 18:59:24 +0000 (UTC) From: "Paul C. Bryan" To: James M Snell In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> Content-Type: multipart/alternative; boundary="=-ABv8k2sdcAKdavQ0r8bk" Date: Mon, 10 Sep 2012 11:59:22 -0700 Message-ID: <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:59:26 -0000 --=-ABv8k2sdcAKdavQ0r8bk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote: > On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan > wrote: > > Unfortunately, null is a testable value and should not be > interpreted to mean lack of value > > > Indeed, but I'd argue that the two cases are semantically equivalent > enough for the such differences to be irrelevant. Particularly since > many (if not most) json vocabularies tend to treat null and undefined > as being equivalent. While there are some languages that do not make this distinction, I must disagree with your conclusion that it is irrelevant. In JavaScript, null != undefined. The JSON specification went out of its way to define an explicit null value. I do not want to create ambiguities in the test operation, nor do I want to create incompatibilities with different implementations where the treatment of null may be concerned. > There is a clear use case for this and we can bind the scope simply > by saying that, within json patch, undefined and null are equivalent. And what is the clear use case for this? Paul --=-ABv8k2sdcAKdavQ0r8bk Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote:

On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
Unfortunately, null is a testable value and should not be interpreted to mean lack of value

Indeed, but I'd argue that the two cases are semantically equivalent enough for the such differences to be irrelevant. Particularly since many (if not most) json vocabularies tend to treat null and undefined as being equivalent.

While there are some languages that do not make this distinction, I must disagree with your conclusion that it is irrelevant. In JavaScript, null != undefined. The JSON specification went out of its way to define an explicit null value. I do not want to create ambiguities in the test operation, nor do I want to create incompatibilities with different implementations where the treatment of null may be concerned.

There is a clear use case for this and we can bind the scope simply by saying that, within json patch, undefined and null are equivalent.

And what is the clear use case for this?

Paul
--=-ABv8k2sdcAKdavQ0r8bk-- From andy@hxr.us Mon Sep 10 16:22:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4528421F86F0 for ; Mon, 10 Sep 2012 16:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoMOjOcHymub for ; Mon, 10 Sep 2012 16:22:15 -0700 (PDT) Received: from mail-lpp01m010-f49.google.com (mail-lpp01m010-f49.google.com [209.85.215.49]) by ietfa.amsl.com (Postfix) with ESMTP id 79DC121F8595 for ; Mon, 10 Sep 2012 16:22:15 -0700 (PDT) Received: by lagu2 with SMTP id u2so1942393lag.22 for ; Mon, 10 Sep 2012 16:22:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=CZZl5RyDyilaqu2ycB1lHFDa8wZYPinssrbZaYMIXsE=; b=fu0v86cY2IfVO7ATGm15sbOL5QfngP/MV2UnPZh6W9jTA98hhfzgHhvWAi8cXWHANs Z7odusV3hk92VVWVHUmcDZNPyikhZpoajDxTlHf3s3zJwUQbIA1sV0Q3V14PKSogrym7 i4BJtyOviIlbSaeXy/Q0WFNQvyVwdjB7zl1fEI0AiJrBUW+OmSOc0YUCpLLTfyGsNJIQ Xtuz//TG0qfpoaBuawwrzi5Bt51fhwDTQX+1lDdKuUuwRk9H7dwvlEeWh/CJMvbspuGq jNh2rbRoQ8+QimXLeX595QXYq9cdZ3bdjrwaDVDb6op6dVxtXF/ITwo5cJs9a5wRj2XY ql7A== MIME-Version: 1.0 Received: by 10.152.48.70 with SMTP id j6mr4287387lan.57.1347319332739; Mon, 10 Sep 2012 16:22:12 -0700 (PDT) Received: by 10.112.7.67 with HTTP; Mon, 10 Sep 2012 16:22:12 -0700 (PDT) X-Originating-IP: [71.191.219.28] In-Reply-To: References: Date: Mon, 10 Sep 2012 19:22:12 -0400 Message-ID: From: Andrew Newton To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkgy2/Pk7zdn9/ic50K4lT8Y3taeZRzlknHPl2SEkJW79KmMDyQzQV9Hk2R9uKY1C9i6bh9 Cc: discuss@apps.ietf.org Subject: Re: [apps-discuss] Reviving JSON Schema X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 23:22:16 -0000 On Sat, Sep 8, 2012 at 12:58 AM, Mark Nottingham wrote: > As such, if (and that's a big "if") we embark on giving JSON Schema some status, I'd propose several requirements: > > - adherence to the spirit of simplicity in JSON (i.e., bias towards *not* adding any particular feature / capability) > - focus only on documentation and qa as use cases; NOT "language binding" > - target should be to describe simple protocol data structures, not any arbitrary JSON > - no addition of semantics to the document by the schema; it's only describing structure > - evolution should be very carefully defined, not left to chance > > I'd have a very hard time with anything that went against these. I think these are good goals. As for "documentation and qa", I'm not sure what you mean by QA. Are you suggesting that schemas could be used to programmatically determine if a JSON file/stream is adherent to the schema? If so, I don't think that's a good goal as a schema can only carry things so far before custom application-specific logic is needed. Documentation is a good goal, but I don't think what is given in draft-zyp-json-schema-03 is well suited for documentation. It is too verbose. Perhaps if there was something like compact RelaxNG notation for JSON. -andy From barryleiba.mailing.lists@gmail.com Mon Sep 10 16:48:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07E521F86C5 for ; Mon, 10 Sep 2012 16:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.95 X-Spam-Level: X-Spam-Status: No, score=-102.95 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgyPDCMyrXpg for ; Mon, 10 Sep 2012 16:48:45 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2413821F86AD for ; Mon, 10 Sep 2012 16:48:44 -0700 (PDT) Received: by lahm15 with SMTP id m15so1646230lah.31 for ; Mon, 10 Sep 2012 16:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ADAt4slLS3hD1A3vBHID5wphqbFlrK1gmT1dkqP0EzE=; b=NOIF+G9K7hH68Ea7atR2Al9eaM9TRzSdCppjTD+G0ta77+Xs7/lD1AN4UgOyE4110A gV9z7RfLLLcpXr1W/ozeMzyxESFwi/T6F7Vo57/Z/ee3WQ1O6L3S7U2HW9Q5np6DVAo6 fPQxFGKpLEplvCKYxRlqzs/IJLvL4fYy9KH0Tx2POmiIEhTXjYOmMpEu2AHyzKAP44/8 J9gRIWMiZ/cFhS8nX8gLV0XQ1weoEjGKGfxqiFy0vYCWZ1nXe+Hhl2V3/xSZxJJw8fmT Z2eYGzA3o6Lzx3kUuB1JlPg37a7p5hbhGEVGn6UyIP37iCbLtGMMH9mXsMuxuH1c8oD0 lSwQ== MIME-Version: 1.0 Received: by 10.152.46.49 with SMTP id s17mr14132090lam.17.1347320924048; Mon, 10 Sep 2012 16:48:44 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Mon, 10 Sep 2012 16:48:43 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Sep 2012 19:48:43 -0400 X-Google-Sender-Auth: oV2Z-2d-vZzxHYlWKqOes3gROD0 Message-ID: From: Barry Leiba To: Sheppy Reno Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Addition of Available Space to Host-Resources-MIB X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 23:48:46 -0000 > After working with SNMP for quite a while we=92ve repeatedly run into iss= ues > where monitoring software is unable to accurately determine the utilizati= on > of volumes on some Linux partitions due to regular processes being unable= to > access the reserved file space. I believe that the best way to correct t= his > issue is to include an additional data point in the Host Resources MIB > (RFC2790) that will return available space. This should have no negative > impact on systems that do not utilization reserved space, but will allow = for > a much more accurate picture of the space that is truly available on thos= e > partitions using reserved space. Hi, Sheppy, and welcome to IETF land. I suggest that the Operations and Management Area Working Group (opsawg) is more likely the right place to take SNMP issues: General Discussion: opsawg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsawg Archive: http://www.ietf.org/mail-archive/web/opsawg Barry, Applications AD From evan@status.net Mon Sep 10 18:35:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4845121F8702 for ; Mon, 10 Sep 2012 18:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yy-6ATdCS1I for ; Mon, 10 Sep 2012 18:35:35 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6A321F870E for ; Mon, 10 Sep 2012 18:35:22 -0700 (PDT) Received: from [192.168.69.112] (modemcable107.194-202-24.mc.videotron.ca [24.202.194.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 24C438D5EB8 for ; Tue, 11 Sep 2012 01:45:22 +0000 (UTC) Message-ID: <504E9555.4070605@status.net> Date: Mon, 10 Sep 2012 21:35:17 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> In-Reply-To: <504E1116.6060808@status.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 01:35:36 -0000 On 12-09-10 12:11 PM, Evan Prodromou wrote: > Changing the semantics of the "lrdd" link relation from "XRD by > default" to "JRD by default" is unnecessarily damaging to existing > implementations. > > It does not serve new implementers well if the specification doesn't > describe the way current implementations work, or give a reasonable > upgrade path. > > I very much like the way RFC 6415 deals with XRD and JRD and I think > it is a great model to follow with Webfinger: XRD by default, and easy > mechanisms (content negotiation or a separate endpoint) to get JRD. So, reviewing RFC 6415, I see it covers almost everything I think of as "Webfinger": the lrdd link relation, XRD and JRD versions of host-meta and LRDD doc. -Evan From paulej@packetizer.com Mon Sep 10 20:56:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B28021F8770 for ; Mon, 10 Sep 2012 20:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7cKrHRV1XOK for ; Mon, 10 Sep 2012 20:56:29 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 197BB21F861F for ; Mon, 10 Sep 2012 20:56:29 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q8B3uRSD018152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Sep 2012 23:56:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1347335788; bh=R6xnyMHsQFcOw5jRLNmJXIqvaMaFD4VjBAj8WkhwN1c=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=WplWBSr4ZclYWbUjKbUhhb3qGZ0mxPZtzULNsbMYDGH8YwHhLvZYPn4yAIQhqZA5n 4sNCr5PRpczK/0+jHNXotkeVoOA6Y7CG7HUyIhvBzL6d2iWtM2MP7J2vs5b1gI2Unt eJjhIx6yiiVaXTkpIJoPHUuEEysegcqc67F9m3O0= From: "Paul E. Jones" To: "'Goix Laurent Walter'" , "=?utf-8?Q?'=E2=98=AE_elf_Pavlik_=E2=98=AE'?=" , "'Peter Saint-Andre'" References: <502B7037.4020901@ninebynine.org> <502D3C2B.3040900@stpeter.im> <5031FA92.2030700@ninebynine.org> <503658B0.2090303@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943667A7667@TK5EX14MBXC284.redmond.corp.microsoft.com> <1346172875-sup-9676@heahdk.net> <503D04E5.1090506@stpeter.im> <1346176849-sup-3504@heahdk.net> <047b01cd860f$d31f7ce0$795e76a0$@packetizer.com> <079001cd87de$4ba00480$e2e00d80$@packetizer.com> In-Reply-To: Date: Mon, 10 Sep 2012 23:56:31 -0400 Message-ID: <07b401cd8fd1$6e505e30$4af11a90$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHQkPRpqE241VMBhFX0b1E5n3icagGmT2cgAfxtLQICXYfDzwLd38ExAfCD3o0CSm6TWwHz+GlOAlI3tJgCXV8wQQGG1ghXAuhyjxkCUVJR+JaqlkSw Content-Language: en-us Cc: 'apps-discuss' Subject: Re: [apps-discuss] R: Comment on draft-ietf-appsawg-acct-uri-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 03:56:30 -0000 Walter, This flexibility does exist thanks to RFC 6415. I'm thinking about how = we might present this example. I'm taking note of your comments, but I = don't have time to make text changes right now. Paul > -----Original Message----- > From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] > Sent: Monday, September 03, 2012 10:00 AM > To: Paul E. Jones; '=E2=98=AE elf Pavlik =E2=98=AE'; 'Peter = Saint-Andre' > Cc: 'apps-discuss' > Subject: R: [apps-discuss] R: Comment on draft-ietf-appsawg-acct-uri- > 00.txt >=20 > Hello Paul, > > > > Walter, > > > > > I agree it is "more or less" the same at the end. However I expect > > > that from current implementations of webfinger, very little link > > > rels are provided in the host-meta vs resource-specific descriptor > > > so putting many templates in the host-meta already is not best > practice yet afaik. > > > Of course nothing prevents from changing this behaviour in the > > > future but as this scenario may become mainstream (I do hope that = in > > > a few years very big social islands will webfinger each other). > > > > > > Thus I am wondering whether it could make sense: > > > - adding it as an example in the draft clarifying the practice and > > > emphasizing the insertion of additional link rel templates already > > > in the host-meta > > > > I could certainly show an example similar to what is in RFC 6415 > > Section 1.1, perhaps adding additional host-wide properties and link > > relations. However, I'm not sure what you mean by "emphasizing the > > insertion of additional link rel templates". Host-wide information = uses > link relations, not templates. > > Templates are used for resource-specific information. >=20 > [walter] well the example could illustrate how to follow someone on a > "remote domain", showing the webfinger query from server1 to server2. = In > that case the xrd/jrd for the host-meta could show a list of link rels > "typical" of this example (federated social networks), such as > "http://webfinger.net/rel/avatar", > "http://schemas.google.com/g/2010#updates-from", "salmon", > "http://portablecontacts.net/spec/1.0" and the related templates (for = the > purpose of the example) that contain a {uri} template parameter in the > example itself, e.g. > > >=20 > >=20 > template=3D'http://example.com/avatar/{uri}' /> >=20 > template=3D'http://example.com/salmon/{uri}' /> >=20 > href=3D'http://example.com/people' /> >=20 > = template=3D"http://example.com/activitystreams/{uri}/@self?format=3Datom"= > type=3D"application/atom+xml" /> >=20 > > And commenting that these templates (for resource-specific info) allow = to > avoid querying each single resource on server example.com for these = link > rels, thus useful for interconnection of large providers. >=20 > > > > > - specifying new templates variable names to be used in templates, > > > as this scenario makes strong use of templates and may need to > > > reference additional information. The first that comes into my = mind > > > (as per the example in my previous email) is the local username, > > > that could be identified as {uri.userpart}, {username} or anything > > > else. Maybe other could also make sense. > > > > I really think it's a bad idea for us to introduce more template > variables. > > This gets complicated. WebFinger was designed to operate on a = single > URI. > > Since a URI can contain any kind of information, I think that should > > be sufficient. > [walter] My proposal is based on the observation of the webfinger > endpoints already exposed, where the URL of most resource-specific > information (link rels) is actually based on a pattern, which is = common to > all resources under that domain, but which pattern do not typically > includes the whole account URI but only a username (or some sort of = id, eg > in case of G+). >=20 > walter > > > > Paul > > >=20 >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle > persone indicate. La diffusione, copia o qualsiasi altra azione = derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. > Qualora abbiate ricevuto questo documento per errore siete = cortesemente > pregati di darne immediata comunicazione al mittente e di provvedere = alla > sua distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may contain = privileged > information intended for the addressee(s) only. Dissemination, = copying, > printing or use by anybody else is unauthorised. If you are not the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks. From paulej@packetizer.com Mon Sep 10 21:06:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C2D21F875D for ; Mon, 10 Sep 2012 21:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBxb0-TLSDaB for ; Mon, 10 Sep 2012 21:06:27 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5A78621F8746 for ; Mon, 10 Sep 2012 21:06:27 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q8B46O91018481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Sep 2012 00:06:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1347336385; bh=WRwRAUwJ4gcnxRVUYHpYSoN3bStiHsT5gLmUzAkMzGs=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=KEbVaVe8sJSKuCSpfgNXLU2Hqrte22G8GsQvf3WNynexwKpts1WLIQ7c1cPaZcCtH 1ZA8IWhV7CzwcXK/3o+r8/o2d1Oxp4mylzSCHFdrMODLh/P308lwRYse+qGLb1ZPpI 6av87c+5FAn8C/3yGUK2lNqt0xib62RzsL+q/Oy0= From: "Paul E. Jones" To: "'John Panzer'" , "'John Bradley'" References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com> <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net> <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> <046501cd860c$da464420$8ed2cc60$@packe! tizer.com> <287CDD14-DE C2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com> In-Reply-To: Date: Tue, 11 Sep 2012 00:06:28 -0400 Message-ID: <07cb01cd8fd2$d2320510$76960f30$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07CC_01CD8FB1.4B23C070" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFb3Wt68HpLZ7ZyHnoKMrZHlzcyBQH14U4xAZ6Br/cCWNrQtwIOUYf2AgMXr+8B4HmqlgGhGIVxAUAhVLECgOqLOADUaqV0Ain7f7cBffnLSQIkbXUiAp1soAQC/kiSjgGrOFrXAhluBTcBspR9LJdQQTGg Content-Language: en-us Cc: 'Mark Nottingham' , 'IETF Apps Discuss' Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 04:06:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07CC_01CD8FB1.4B23C070 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit John, I've hosted my domains with the smallest providers and I manage my primary domain myself. In all cases, I've been able to use 3xx to redirect requests. Do you think this will not be workable for any domain owners? I agree that if we had to do it all over again, we could explore lots of options. I do like the idea of a URI DNS record, but I'm not sure if any clients would query for it even if we mandated it at this point. We could specify a special name like "_webfinger.example.com". However, we run into the same issues: clients may not query for that. Perhaps equally important, this shifts us away from the ".well-known" work that was defined. What we do not want, of course, is a solution that is DOA. If there is anything about WF that is going to halt adoption, let's fix it now. Otherwise, I suggest we live with what has been specified. Paul From: John Panzer [mailto:jpanzer@google.com] Sent: Wednesday, August 29, 2012 2:13 PM To: John Bradley Cc: Paul E. Jones; Mark Nottingham; IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger Based on experience, I'd prefer to avoid things that depend on the bare ("naked") domain (example.com instead of www.example.com or webfinger.example.com). I could write up the reasons but it'd take some time. Unfortunately, webfinger as originally spec'd requires this. If we were to start over, and get to vote for whatever I wanted, and were going to allow DNS records at all, I would probably vote for something like webfinger.example.com as a special magic name (with the actual name chosen so as not to collide with any existing DNS entries). Any normal hosting mechanisms will work here, including A records and CNAMEs and HTTP redirects, but I'd also require everything be done via TLS with correctly signed certificates for that subdomain (argh! the pain!). Organizationally, this would mean that any part of the organization that can stand up a separate SSL service on a new subdomain can provide webfinger services. On Wed, Aug 29, 2012 at 10:57 AM, John Bradley wrote: I am not the best person to represent Google's needs. However as I understand it Google hosts applications such as email documents openID for tens of thousands of domains. Google themselves don't control the DNS. The people using the service generally add some MX records for aspmx.l.google.com. and a Cname for mail.example.com to ghs.google.com. The A record for the bare domain typically points off to some Content management site the company uses for their web pages. I think this is probably typical of Yahoo's mail hosting services and others. The service hosing the email/authentication/openID is not the one that controls the web server for company. Saying the CMS venders will provide WebFinger services doesn't seem all that likely, especially in virtual hosting environments. Getting a typical company to do anything more than enter a cname for webfinger.example.org is wildly optimistic. I am entirely open to Ideas on this. However the previous solution of having every RP check with google first to see if they host the email and provide the XRDS seems horribly flawed to me. I would like to see a workable solution at the discovery layer that accommodates how people deploy there sites. I think Bill suggested at one point using the MX record to find the webfinger host. That has a bunch of problems I would prefer to avoid. John B. On 2012-08-29, at 1:36 PM, "Paul E. Jones" wrote: John, Well, we need to figure out how to address this. Would it be reasonable to redirect requests from /.well-known/host-meta.json and /.well-known/host-meta to Google? Are there other services or files under /.well-known that Google's customers would not want Google to host? If they were OK with Google's servers responding to anything , then one could put an A (or CNAME) record in place for example.com that points to Google. Not being familiar with what Google offers, I'm a bit challenged to understand exactly what is and is not possible. Paul From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Wednesday, August 29, 2012 10:14 AM To: Paul E. Jones Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss' Subject: Re: [apps-discuss] Looking at Webfinger There mite be a A record but that typically goes off to some virtual web hosting company and not the email service provider. I think I have also heard William say this is a problem for Yahoo. Google was not able to get people to deploy XRDS for hosted domains. They came up with a proprietary extension to openID discovery to make hosted google apps domains work with some subset of RP. The problem is that the company hosting a small businesses website is unlikely to provide the web finger infrastructure and there is no way for the email/openID provider to do it without their cooperation. Adding a A record rather than a CNAME is generally not a good idea if it can be avoided. In the event of the provider changing an IP address it breaks all the customers if they have used A records, but that is separate issue. You can set up webfinger on your web server and manage it. It just won't work for large numbers of people as we have it now. If webfinger won't work for Google Apps for Domains and other hosted services like that then It will significantly impact adoption in my opinion. We will also need to work around that for Connect. We don't want another proprietary work around with the security problems that can entail. John B. On 2012-08-28, at 11:37 PM, "Paul E. Jones" < paulej@packetizer.com> wrote: John, If Google is hosting the domain or any other service provider, wouldn't there still be an A record for the domain (e.g., packetizer.com)? I know there is for virtually every web hosting company I've used. It seems like this might just be one more hosted service Google could provide to its customers, no? I do not know exactly how this hosted service works, but what's hosted? I assume it's just email. If web, then I see no issue. If only email, then the user just needs to have MX records pointing to Google and an A record pointing to whatever service runs the WebFinger service. In any case, if they can add a CNAME or MX record, I think we can get them to add an A record. I think it would be far more challenging for SMBs to add a host like webfinger.example.com. That would still require an A record and a service provider capable of supporting it. Paul From: John Bradley [mailto:ve7jtb@ ve7jtb.com] Sent: Tuesday, August 28, 2012 3:29 PM To: Paul E. Jones Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss' Subject: Re: [apps-discuss] Looking at Webfinger There are cases where there are hosted domains (Google etc) that may not have a http host for the domain name used in the users email address. There may be merit to having a webfinger.example.com fallback where the client can't reach the .well-known for the primary host. I know that some sort of SRV record would be the correct way to do it, but in the real world SMB don't enter SRV records even if there DNS provider support them. The most you can get them to do is add a CNAME or MX record. Supporting these sorts of domains somehow is a important issue. John B. On 2012-08-28, at 3:17 PM, "Paul E. Jones" < paulej@packetizer.com> wrote: George, I believe it might be useful to introduce those who break your WebFinger server to Louisville Slugger. :) Your pain is understood, but I do not see a way to avoid it. We could introduce something in DNS, but that would also present challenges. No matter where we "root" the discovery process, there is a potential somebody could break it. It could be rooted somewhere other than the root of the domain (e.g., webfinger.example.com), but we either need to decide in advance of such a location or introduce a way to discovery the discovery resources. Do you have a suggestion that would make this less likely to be broken? Paul From: apps-discuss-bounces@ietf.org [mailto:apps- discuss-bounces@ietf.org] On Behalf Of George Fletcher Sent: Tuesday, August 28, 2012 11:09 AM To: Mark Nottingham Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger Way "late to the party" but I can speak from experience that deployment can be a real issue in some environments. It's all really straight forward in a small company or an environment where the identity team "owns" the root domain (e.g. example.com). However, if an entire other group in a large organization "owns" the root domain (home page for the site) and the identity team then needs to get them to make changes, the deployment solution gets brittle pretty quick. I've had our webfinger support broken at least twice because the "other" team didn't know that certain configs were required:) Also, installing the "dynamic pluming" can be more problematic is these cases. It is possible to get apache rewrite rules or netscaler magic in place to make it work, it's just a more brittle deployment architecture. Thanks, George On 7/4/12 6:58 PM, John Panzer wrote: Mark -- Of course I was speaking about practical realities of typical web server administration and deployment. In practical terms, adding a new mod_rewrite rule or moral equivalent is going to be easier than adding a new PHP script that connects to a database. The latter is just always going to be a much higher bar. And, something that returns per-user data is generally going to need a dynamic service of some kind, unless your site has just a handful of users and you don't mind going through a publishing exercise each time you add or change a user... None of this has anything to do with the interface, just deployment realities. And in reality all of this is going to need a dynamic service somewhere for each non-trivial site, this is all just a question of how to hook it up. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham < mnot@mnot.net> wrote: On 05/07/2012, at 8:16 AM, John Panzer wrote: > Just as a historical note. The envisioned usage of host-meta was originally to avoid a specification which mandated a particular dynamic URL API at a particular /.well-known endpoint (because it may not be feasible to do that across all organizations and deployments). The host-meta document itself would be highly cacheable and so wouldn't incur an additional network trip in the common case. > > Having a 3xx redirect is a reasonable alternative that allows a similar escape hatch via something like mod_rewrite, albeit at the cost of needing an additional network trip each time. Since a deployment can always avoid the 3xx redirect with additional dynamic plumbing behind the well-known endpoint, I don't think that's a horrible thing. > > An application-level redirect would be almost equivalent to an HTTP redirect, but then there are two ways to do the same thing. If _only_ an application-level redirect is allowed, then you have to have at least a minimal dynamic service at the well-known endpoint (no more mod_rewrite). But the whole reason for this is to avoid the requirement for a dynamic service behind well-known... "dynamic" and "static" are properties of the implementation, not the interface. HTTP doesn't require that any particular URL be "dynamic"; anything can, with the right metadata, be cached (and indeed, I've cached many, many things with the wrong metadata, because of silly site operators and their ideas about "dynamic"). Now, if people want to target a particular implementation that makes it easier to serve a particular style of URL without writing code, fine, but let's not confuse things. E.g., a URL like http://example.com/.well-known/user/bob is easy to serve in pretty much any way you like with Apache. I'm also going to push back on the "it may not be feasible to do that across all organizations and deployments" motivation. This is a race to the bottom. The trick is to make it accessible enough to get sufficient traction to pull everyone along, without pandering to *everyone*'s requirements. Regards, -- Mark Nottingham http://www.mnot.net/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_07CC_01CD8FB1.4B23C070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John,

 

I’ve hosted my domains with the smallest providers and I manage = my primary domain myself.  In all cases, I’ve been able to = use 3xx to redirect requests.  Do you think this will not be = workable for any domain owners?

 

I agree that if we had to do it all over again, we could explore lots = of options.  I do like the idea of a URI DNS record, but I’m = not sure if any clients would query for it even if we mandated it at = this point.

 

We could specify a special name like = “_webfinger.example.com”.  However, we run into the = same issues: clients may not query for that.  Perhaps equally = important, this shifts us away from the “.well-known” work = that was defined.

 

What we do not want, of course, is a solution that is DOA.  If = there is anything about WF that is going to halt adoption, let’s = fix it now.  Otherwise, I suggest we live with what has been = specified.

 

Paul

 

From:= = John Panzer [mailto:jpanzer@google.com]
Sent: Wednesday, = August 29, 2012 2:13 PM
To: John Bradley
Cc: Paul E. = Jones; Mark Nottingham; IETF Apps Discuss
Subject: Re: = [apps-discuss] Looking at Webfinger

 

Based on = experience, I'd prefer to avoid things that depend on the bare = ("naked") domain (example.com instead of www.example.com or webfinger.example.com). =  I could write up the reasons but it'd take some time. =  Unfortunately, webfinger as originally spec'd requires = this.

 

If we were to start over, and get to vote for whatever = I wanted, and were going to allow DNS records at all, I would probably = vote for something like webfinger.example.com as a = special magic name (with the actual name chosen so as not to collide = with any existing DNS entries).  Any normal hosting mechanisms will = work here, including A records and CNAMEs and HTTP redirects, but I'd = also require everything be done via TLS with correctly signed = certificates for that subdomain (argh!  the = pain!).

 

Organizationally, this would mean that = any part of the organization that can stand up a separate SSL service on = a new subdomain can provide webfinger services. =  

On Wed, Aug 29, 2012 at = 10:57 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

I am not the best person to represent Google's = needs.

 

However as I understand it Google hosts applications = such as email documents openID for tens of thousands of = domains.

Google themselves = don't control the DNS.

 

The people using the service generally add some MX = records for aspmx.l.google.com. and a Cname for mail.example.com = to ghs.google.com.

 

The A record for the bare domain typically points off = to some Content management site the company uses for their web = pages.

 

I = think this is probably typical of Yahoo's mail hosting services and = others.   

 

The service hosing the email/authentication/openID is = not the one that controls the web server for = company.

 

Saying the CMS venders will provide WebFinger services = doesn't seem all that likely, especially in virtual hosting = environments.

 

Getting a typical company to do anything more than = enter a cname for webfinger.example.org is wildly = optimistic.

 

I = am entirely open to Ideas on this.   However the previous solution = of having every RP check with google first to see if they host the email = and provide the XRDS seems horribly flawed to = me.

 

I = would like to see a workable solution at the discovery layer that = accommodates how people deploy there sites.

 

I = think Bill suggested at one point using the MX record to find the = webfinger host.  That has a bunch of problems I would prefer to = avoid.

 

John B.

 

On = 2012-08-29, at 1:36 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:



John,

 

Well, we need to figure out how to address = this.

 

Would it be reasonable to redirect requests from = /.well-known/host-meta.json and /.well-known/host-meta to = Google?

 

Are there other services or files under /.well-known that = Google’s customers would not want Google to host?  If they = were OK with Google’s servers responding to anything , then one = could put an A (or CNAME) record in place for example.com that points to = Google.

 

Not being familiar with what Google offers, I’m a bit = challenged to understand exactly what is and is not = possible.

 

Paul

 

From:=  John = Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, = August 29, 2012 10:14 AM
To: Paul E. = Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF = Apps Discuss'
Subject: Re: [apps-discuss] Looking at = Webfinger

 

There mite be a A record but that typically goes off = to some virtual web hosting company and not the email service = provider.

 

I think I have also heard William say this is a = problem for Yahoo.

 

Google was not able to get people to deploy XRDS for = hosted domains.   They came up with a proprietary extension to = openID discovery to make hosted google apps domains work with some = subset of RP.

 

The problem is that the company hosting a small = businesses website is unlikely to provide the web finger infrastructure = and there is no way for the email/openID provider to do it without their = cooperation.

 

Adding a A record rather than a CNAME is generally not = a good idea if it can be avoided.   In the event of the provider = changing an IP address it breaks all the customers if they have used A = records, but that is separate issue. =  

 

You can set up webfinger on your web server and manage = it.   It just won't work for large numbers of people as we have it = now.  

 

If webfinger won't work for Google Apps for Domains = and other hosted services like that then It will significantly impact = adoption in my opinion.

 

We will also need to work around that for Connect. =  We don't want another proprietary work around with the security = problems that can entail.

 

John B.

 

On 2012-08-28, at 11:37 PM, "Paul E. Jones" = <paulej@packetizer.com> = wrote:

 

=

John,

 

If Google is hosting the domain or any other service provider, = wouldn’t there still be an A record for the domain (e.g.,packetizer.com)?  I know there is = for virtually every web hosting company I’ve used.  It seems = like this might just be one more hosted service Google could provide to = its customers, no?

 

I do not know exactly how this hosted service works, but what’s = hosted?  I assume it’s just email.  If web, then I see = no issue.  If only email, then the user just needs to have MX = records pointing to Google and an A record pointing to whatever service = runs the WebFinger = service.

 

In any case, if they can add a CNAME or MX record, I think we can get = them to add an A record.  I think it would be far more challenging = for SMBs to add a host like webfinger.example.com.  That = would still require an A record and a service provider capable of = supporting it.

 

Paul

 

From:=  John = Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: = Tuesday, August 28, 2012 3:29 PM
To: Paul E. = Jones
Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF = Apps Discuss'
Subject: Re: [apps-discuss] Looking at = Webfinger

 

There are cases where there are hosted domains (Google = etc) that may not have a http host for the domain name used in the users = email address.  

 

There may be merit to having a webfinger.example.com fallback = where the client can't reach the .well-known for the primary = host.

 

I know that some sort of SRV record would be the = correct way to do it, but in the real world SMB don't enter SRV records = even if there DNS provider support = them.

The most = you can get them to do is add a CNAME or MX = record.

 

Supporting these sorts of domains somehow is a = important issue.

 

John B.

 

On 2012-08-28, at 3:17 PM, "Paul E. Jones" = <paulej@packetizer.com> = wrote:



George,

 

I believe it might be useful to introduce those who break your = WebFinger server to Louisville Slugger. = :)

 

Your pain is understood, but I do not see a way to avoid it.  We = could introduce something in DNS, but that would also present = challenges.  No matter where we “root” the discovery = process, there is a potential somebody could break it.  It could be = rooted somewhere other than the root of the domain (e.g., webfinger.example.com), but we either = need to decide in advance of such a location or introduce a way to = discovery the discovery = resources.

 

Do you have a suggestion that would make this less likely to be = broken?

 

Paul

 

From:=  apps-discuss-bounces@ietf.org [mai= lto:apps-discuss-bounces@ietf.org] On = Behalf Of George Fletcher
Sent: Tuesday, August = 28, 2012 11:09 AM
To: Mark = Nottingham
Cc: IETF Apps = Discuss
Subject: Re: [apps-discuss] Looking at = Webfinger

 

Way "late to the = party" but I can speak from experience that deployment can be a = real issue in some environments. It's all really straight forward in a = small company or an environment where the identity team "owns" = the root domain (e.g. example.com). = However, if an entire other group in a large organization = "owns" the root domain (home page for the site) and the = identity team then needs to get them to make changes, the deployment = solution gets brittle pretty quick. I've had our webfinger support = broken at least twice because the "other" team didn't know = that certain configs were required:)

Also, installing the = "dynamic pluming" can be more problematic is these cases. It = is possible to get apache rewrite rules or netscaler magic in place to = make it work, it's just a more brittle deployment = architecture.

Thanks,
George

On 7/4/12 6:58 PM, John Panzer = wrote:

Mark -- Of course I was speaking about practical = realities of typical web server administration and deployment.  In = practical terms, adding a new mod_rewrite rule or moral equivalent is = going to be easier than adding a new PHP script that connects to a = database.  The latter is just always going to be a much higher = bar.

 

And, something that returns per-user data is generally = going to need a dynamic service of some kind, unless your site has just = a handful of users and you don't mind going through a publishing = exercise each time you add or change a = user...

 

None of this has anything to do with the interface, = just deployment realities.  And in reality all of this is going to = need a dynamic service somewhere for each non-trivial site, this is all = just a question of how to hook it = up.


--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / = @jpanzer

 

 

On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <mnot@mnot.net> = wrote:

On 05/07/2012, at 8:16 AM, John Panzer = wrote:

> Just as a historical note.  The envisioned usage = of host-meta was originally to avoid a specification which mandated a = particular dynamic URL API at a particular /.well-known endpoint = (because it may not be feasible to do that across all organizations and = deployments).  The host-meta document itself would be highly = cacheable and so wouldn't incur an additional network trip in the common = case.
>
> Having a 3xx redirect is a reasonable alternative = that allows a similar escape hatch via something like mod_rewrite, = albeit at the cost of needing an additional network trip each time. =  Since a deployment can always avoid the 3xx redirect with = additional dynamic plumbing behind the well-known endpoint, I don't = think that's a horrible thing.
>
> An application-level = redirect would be almost equivalent to an HTTP redirect, but then there = are two ways to do the same thing.  If _only_ an application-level = redirect is allowed, then you have to have at least a minimal dynamic = service at the well-known endpoint (no more mod_rewrite).  But the = whole reason for this is to avoid the requirement for a dynamic service = behind well-known...

"dynamic" and "static" are = properties of the implementation, not the interface. HTTP doesn't = require that any particular URL be "dynamic"; anything can, = with the right metadata, be cached (and indeed, I've cached many, many = things with the wrong metadata, because of silly site operators and = their ideas about "dynamic").

Now, if people want to = target a particular implementation that makes it easier to serve a = particular style of URL without writing code, fine, but let's not = confuse things.

E.g., a URL like

http://example.com/.well-known/user/bob=

is easy to serve in pretty much any way you like with = Apache.

I'm also going to push back on the "it may not be = feasible to do that across all organizations and deployments" = motivation. This is a race to the bottom. The trick is to make it = accessible enough to get sufficient traction to pull everyone along, = without pandering to *everyone*'s = requirements.

Regards,


--
Mark = Nottingham   http://www.mnot.net/



 





_______________________________________________
 
 
apps-discuss =
mailing list
apps-discuss@ietf.org
<= pre>https://www.ietf.org/mailman/listinfo/apps-discuss=

 

_________= ______________________________________
apps-discuss mailing = list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss=

 


______________________________________= _________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 

------=_NextPart_000_07CC_01CD8FB1.4B23C070-- From laurentwalter.goix@telecomitalia.it Tue Sep 11 01:36:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B80721F8779 for ; Tue, 11 Sep 2012 01:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NA+YPeVoVUTU for ; Tue, 11 Sep 2012 01:36:37 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id B2BE221F8778 for ; Tue, 11 Sep 2012 01:36:35 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 11 Sep 2012 10:36:32 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Tue, 11 Sep 2012 10:36:32 +0200 From: Goix Laurent Walter To: Evan Prodromou , "apps-discuss@ietf.org" Date: Tue, 11 Sep 2012 10:36:29 +0200 Thread-Topic: [apps-discuss] XML in Webfinger Thread-Index: Ac2PvcNb4PzgGQSiR9OYfklUvwU4UgAOTPwg Message-ID: References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> In-Reply-To: <504E9555.4070605@status.net> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [apps-discuss] R: XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 08:36:37 -0000 > On 12-09-10 12:11 PM, Evan Prodromou wrote: > > Changing the semantics of the "lrdd" link relation from "XRD by > > default" to "JRD by default" is unnecessarily damaging to existing > > implementations. > > > > It does not serve new implementers well if the specification doesn't > > describe the way current implementations work, or give a reasonable > > upgrade path. > > > > I very much like the way RFC 6415 deals with XRD and JRD and I think > > it is a great model to follow with Webfinger: XRD by default, and easy > > mechanisms (content negotiation or a separate endpoint) to get JRD. > So, reviewing RFC 6415, I see it covers almost everything I think of as > "Webfinger": the lrdd link relation, XRD and JRD versions of host-meta > and LRDD doc. except the "resource" and "rel" query parameters (and the "acct" link rel) = yes. Your (and james) points seem to suggest to rather rely on 2 distinct e= ndpoints and have both support such query parameters. As pointed out many t= imes in the past this does not conflict with neither rfc6415 nor with exist= ing implementations (basically for fsw/ostatus implementations resource and= rel could need to be added over time), and does accommodate new use cases = (openid connect etc) to have json supported with a minimal overhead on the = server-side. Theoretically if the ietf WF is specified as json/jrd only then it would be= a somehow independent spec from rfc6415. In this case current implementati= ons would claim rfc6415-compliance but not wf-compliance, which could be ok= if referenced as such from other specs. I guess the whole point is here in claiming compliance. Json endpoints may = not be needed for federated social web use cases for now, but at this stage= one could argue whether anything more is actually needed to be specified b= eyond rfc6415 for webfinger, now that acct uri is on its way. Then it becom= es all about "resource" and "rel" parameters, which to me look like they co= uld easily apply to both endpoints. walter > > -Evan > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From dromasca@avaya.com Tue Sep 11 01:54:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0348C21F8797 for ; Tue, 11 Sep 2012 01:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.219 X-Spam-Level: X-Spam-Status: No, score=-103.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRBKrRtZlIWw for ; Tue, 11 Sep 2012 01:54:15 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0405421F86F9 for ; Tue, 11 Sep 2012 01:54:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACf7TlDGmAcF/2dsb2JhbABFu0+BB4IgAQEBAQMBAQEPHgo0CwwEAgEIDQQEAQELAgQMCwEGASYfCQgBAQQBEggBGYduC54ynU+LEBqFLGADm16KHIJogWE X-IronPort-AV: E=Sophos;i="4.80,403,1344225600"; d="scan'208";a="324231880" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Sep 2012 04:49:53 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Sep 2012 04:47:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Sep 2012 10:54:11 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [apps-discuss] Addition of Available Space to Host-Resources-MIB Thread-Index: Ac2PrtfuE+GQjY15Q2mFUNgQsvNWOAAS6Ucw References: From: "Romascanu, Dan (Dan)" To: "Barry Leiba" , "Sheppy Reno" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Addition of Available Space to Host-Resources-MIB X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 08:54:16 -0000 Barry's suggestion is correct. Some of the people dealing with SNMP are still active in that space and OPSAWG is the place to find them. Adding new objects to an existing MIB module can be done only by updating that MIB module, but I am anticipating the advice that will be given there. Dan > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Barry Leiba > Sent: Tuesday, September 11, 2012 2:49 AM > To: Sheppy Reno > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Addition of Available Space to Host- > Resources-MIB >=20 > > After working with SNMP for quite a while we've repeatedly run into > > issues where monitoring software is unable to accurately determine the > > utilization of volumes on some Linux partitions due to regular > > processes being unable to access the reserved file space. I believe > > that the best way to correct this issue is to include an additional > > data point in the Host Resources MIB > > (RFC2790) that will return available space. This should have no > > negative impact on systems that do not utilization reserved space, but > > will allow for a much more accurate picture of the space that is truly > > available on those partitions using reserved space. >=20 > Hi, Sheppy, and welcome to IETF land. I suggest that the Operations and > Management Area Working Group (opsawg) is more likely the right place to > take SNMP issues: > General Discussion: opsawg@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/opsawg > Archive: http://www.ietf.org/mail-archive/web/opsawg >=20 > Barry, Applications AD > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From laurentwalter.goix@telecomitalia.it Tue Sep 11 06:54:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD0C21F8718 for ; Tue, 11 Sep 2012 06:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65SSE+LeSHS2 for ; Tue, 11 Sep 2012 06:54:06 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB6F21F85F4 for ; Tue, 11 Sep 2012 06:54:05 -0700 (PDT) Content-Type: multipart/mixed; boundary="_162964ee-3a4b-497c-8b91-a0047df2b1ec_" Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 11 Sep 2012 15:53:57 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Tue, 11 Sep 2012 15:53:56 +0200 From: Goix Laurent Walter To: "apps-discuss@ietf.org" Date: Tue, 11 Sep 2012 15:53:55 +0200 Thread-Topic: New version of I-D for ENUM service for acct URI Thread-Index: Ac2QJOIumroETdorQzmwufjgg+IwoA== Message-ID: Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Subject: [apps-discuss] New version of I-D for ENUM service for acct URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 13:54:06 -0000 --_162964ee-3a4b-497c-8b91-a0047df2b1ec_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A2D216D1GRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A2D216D1GRFMBX704BA02_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I just uploaded this draft [1] as a revision of former draft-goix-appsawg-e= num-sn-service-02 based on the discussion held in Vancouver. In particular the text was generalized and a use cases section was added to= clarify the problem to be solved as requested by Dave. We also expanded the security section to clarify potential privacy issues a= s requested by Ted and Hannes, further clarifying why inserting link rel en= dpoint directly in ENUM itself are not appropriate. The example was slightl= y revised as well. Finally, on whether RAI or APPS should handle this draft, the authors spons= or APPS, and in particular APPSAWG, which already handles the webfinger and= acct uri drafts and the related experts. Enum experts already performed a = sanity check on previous versions of this draft. We welcome your feedback on this revision. Walter [1] http://tools.ietf.org/html/draft-goix-appsawg-enum-acct-uri-00 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non ? necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE53A2D216D1GRFMBX704BA02_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I just uploaded this draft [1] = as a revision of former draft-goix-appsawg-enum-sn-service-02 based on the = discussion held in Vancouver.

 

In particular the text was gene= ralized and a use cases section was added to clarify the problem to be solv= ed as requested by Dave.

We also expanded the security s= ection to clarify potential privacy issues as requested by Ted and Hannes, = further clarifying why inserting link rel endpoint directly in ENUM itself = are not appropriate. The example was slightly revised as well.

 

Finally, on whether RAI or APPS= should handle this draft, the authors sponsor APPS, and in particular APPS= AWG, which already handles the webfinger and acct uri drafts and the relate= d experts. Enum experts already performed a sanity check on previous versions of this draft.

 

We welcome your feedback on thi= s revision.

Walter

 

[1] http://tools.ietf.or= g/html/draft-goix-appsawg-enum-acct-uri-00

 =

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non è necessario.

--_000_A09A9E0A4B9C654E8672D1DC003633AE53A2D216D1GRFMBX704BA02_-- --_162964ee-3a4b-497c-8b91-a0047df2b1ec_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_162964ee-3a4b-497c-8b91-a0047df2b1ec_-- From ve7jtb@ve7jtb.com Tue Sep 11 08:45:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E2521F8828 for ; Tue, 11 Sep 2012 08:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hz8l8dQUL8v9 for ; Tue, 11 Sep 2012 08:45:24 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF47221F8826 for ; Tue, 11 Sep 2012 08:45:23 -0700 (PDT) Received: by ghbg16 with SMTP id g16so123396ghb.31 for ; Tue, 11 Sep 2012 08:45:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=qvMhGbURMxkvKBSaPkvBiPLeTUUIdRC/zalgIkeYqTQ=; b=fBFp4gbcnbP4bjLzVLgzJrskjBpa4koMAJz7xyEm5k4bD/Kw6zvSiLrdYEpEMJ0F1b YnzvMmBz1WLyRE/JxHAYdzsWWQmBwjozZrx22YyAkVYU+hwdIu58hDiJTDFQ0zanAOga toOUR3TTsLTjFvgwI9rKNGbgFECXs0EwAF6FnixGODKZYEpvcvBdtt40etEfUANs5x2X vmcida7HhHaVv3KFm8syoV87FSRyo5WPATiOvs4/PcBC/SbeVQyYkQDPrR1JjfnTVVaH tGOpG99OUznjPIM+rxt5VZEqRp+XNmkSmYDxr+TLjicFYttpIpAvs4IJcUzbLdrZSdi/ oP7A== Received: by 10.236.175.234 with SMTP id z70mr16209512yhl.63.1347378322687; Tue, 11 Sep 2012 08:45:22 -0700 (PDT) Received: from [192.168.1.211] ([190.20.45.140]) by mx.google.com with ESMTPS id e5sm30569634yhi.12.2012.09.11.08.45.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Sep 2012 08:45:20 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2642CAB0-1300-417B-AA59-62EFC04F7AC8"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: <07cb01cd8fd2$d2320510$76960f30$@packetizer.com> Date: Tue, 11 Sep 2012 12:45:05 -0300 Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com> <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net> <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> <046501cd860c$da464420$8ed2cc60$@packe! tizer.com> <287CDD14-DE C2-40AD-AD5D-DC102D5AAAE6@ve7jtb.com> <07cb01cd8fd2$d2320510$76960f30$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQnCBO07R3Vc76FZSO1oPYenqB/xYxosYNUkcD03vjQQpw0bdohvuEXT/1JtxeGsbi6aAJ41 Cc: 'Mark Nottingham' , 'IETF Apps Discuss' Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 15:45:27 -0000 --Apple-Mail=_2642CAB0-1300-417B-AA59-62EFC04F7AC8 Content-Type: multipart/alternative; boundary="Apple-Mail=_DBF1DF8E-A909-4D03-BF13-588718B0FC3B" --Apple-Mail=_DBF1DF8E-A909-4D03-BF13-588718B0FC3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Having a webfinger host doesn't necessarily move us away from = .well-known. I am not attached to any particular solution. =20 For openID Connect we must be able to support google apps domains and = others. For that the admins of those domains need to be able to perform the = configuration. A solution that only works for an expert will fail. It also needs appropriate security considerations. One concern is if discovery is not done securely it creates a phishing = opportunity. If I can change someones discovery record I can have a RP redirect them = to a fake IdP and phish there credentials. Other protocols wishing to use webfinger may have similar concerns. = That is why SWD is https: only. DNS without DNSsec is not without issues. It would be attractive to use a SRV record to get the host and port for = making the TLS request though for security reasons the domain would need = to match in some way unless you are doing DNSsec.=20 This seems like it may be too complicated to work well. I agree that redirecting at the HTTP level using https: URI would work = if domains can deploy them. =20 The question to Google and others who have done the research is what can = domain owners reasonably be expected to do. John B. On 2012-09-11, at 1:06 AM, "Paul E. Jones" = wrote: > John, > =20 > I=92ve hosted my domains with the smallest providers and I manage my = primary domain myself. In all cases, I=92ve been able to use 3xx to = redirect requests. Do you think this will not be workable for any = domain owners? > =20 > I agree that if we had to do it all over again, we could explore lots = of options. I do like the idea of a URI DNS record, but I=92m not sure = if any clients would query for it even if we mandated it at this point. > =20 > We could specify a special name like =93_webfinger.example.com=94. = However, we run into the same issues: clients may not query for that. = Perhaps equally important, this shifts us away from the =93.well-known=94 = work that was defined. > =20 > What we do not want, of course, is a solution that is DOA. If there = is anything about WF that is going to halt adoption, let=92s fix it now. = Otherwise, I suggest we live with what has been specified. > =20 > Paul > =20 > From: John Panzer [mailto:jpanzer@google.com]=20 > Sent: Wednesday, August 29, 2012 2:13 PM > To: John Bradley > Cc: Paul E. Jones; Mark Nottingham; IETF Apps Discuss > Subject: Re: [apps-discuss] Looking at Webfinger > =20 > Based on experience, I'd prefer to avoid things that depend on the = bare ("naked") domain (example.com instead ofwww.example.com or = webfinger.example.com). I could write up the reasons but it'd take some = time. Unfortunately, webfinger as originally spec'd requires this. > =20 > If we were to start over, and get to vote for whatever I wanted, and = were going to allow DNS records at all, I would probably vote for = something like webfinger.example.com as a special magic name (with the = actual name chosen so as not to collide with any existing DNS entries). = Any normal hosting mechanisms will work here, including A records and = CNAMEs and HTTP redirects, but I'd also require everything be done via = TLS with correctly signed certificates for that subdomain (argh! the = pain!). > =20 > Organizationally, this would mean that any part of the organization = that can stand up a separate SSL service on a new subdomain can provide = webfinger services. =20 >=20 > On Wed, Aug 29, 2012 at 10:57 AM, John Bradley = wrote: > I am not the best person to represent Google's needs. > =20 > However as I understand it Google hosts applications such as email = documents openID for tens of thousands of domains. > Google themselves don't control the DNS. > =20 > The people using the service generally add some MX records for = aspmx.l.google.com. and a Cname for mail.example.comto ghs.google.com. > =20 > The A record for the bare domain typically points off to some Content = management site the company uses for their web pages. > =20 > I think this is probably typical of Yahoo's mail hosting services and = others. =20 > =20 > The service hosing the email/authentication/openID is not the one that = controls the web server for company. > =20 > Saying the CMS venders will provide WebFinger services doesn't seem = all that likely, especially in virtual hosting environments. > =20 > Getting a typical company to do anything more than enter a cname for = webfinger.example.org is wildly optimistic. > =20 > I am entirely open to Ideas on this. However the previous solution = of having every RP check with google first to see if they host the email = and provide the XRDS seems horribly flawed to me. > =20 > I would like to see a workable solution at the discovery layer that = accommodates how people deploy there sites. > =20 > I think Bill suggested at one point using the MX record to find the = webfinger host. That has a bunch of problems I would prefer to avoid. > =20 > John B. > =20 > On 2012-08-29, at 1:36 PM, "Paul E. Jones" = wrote: >=20 >=20 > John, > =20 > Well, we need to figure out how to address this. > =20 > Would it be reasonable to redirect requests from = /.well-known/host-meta.json and /.well-known/host-meta to Google? > =20 > Are there other services or files under /.well-known that Google=92s = customers would not want Google to host? If they were OK with Google=92s = servers responding to anything , then one could put an A (or CNAME) = record in place for example.com that points to Google. > =20 > Not being familiar with what Google offers, I=92m a bit challenged to = understand exactly what is and is not possible. > =20 > Paul > =20 > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Wednesday, August 29, 2012 10:14 AM > To: Paul E. Jones > Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss' > Subject: Re: [apps-discuss] Looking at Webfinger > =20 > There mite be a A record but that typically goes off to some virtual = web hosting company and not the email service provider. > =20 > I think I have also heard William say this is a problem for Yahoo. > =20 > Google was not able to get people to deploy XRDS for hosted domains. = They came up with a proprietary extension to openID discovery to make = hosted google apps domains work with some subset of RP. > =20 > The problem is that the company hosting a small businesses website is = unlikely to provide the web finger infrastructure and there is no way = for the email/openID provider to do it without their cooperation. > =20 > Adding a A record rather than a CNAME is generally not a good idea if = it can be avoided. In the event of the provider changing an IP address = it breaks all the customers if they have used A records, but that is = separate issue. =20 > =20 > You can set up webfinger on your web server and manage it. It just = won't work for large numbers of people as we have it now. =20 > =20 > If webfinger won't work for Google Apps for Domains and other hosted = services like that then It will significantly impact adoption in my = opinion. > =20 > We will also need to work around that for Connect. We don't want = another proprietary work around with the security problems that can = entail. > =20 > John B. > =20 > On 2012-08-28, at 11:37 PM, "Paul E. Jones" = wrote: > =20 >=20 > John, > =20 > If Google is hosting the domain or any other service provider, = wouldn=92t there still be an A record for the domain = (e.g.,packetizer.com)? I know there is for virtually every web hosting = company I=92ve used. It seems like this might just be one more hosted = service Google could provide to its customers, no? > =20 > I do not know exactly how this hosted service works, but what=92s = hosted? I assume it=92s just email. If web, then I see no issue. If = only email, then the user just needs to have MX records pointing to = Google and an A record pointing to whatever service runs the WebFinger = service. > =20 > In any case, if they can add a CNAME or MX record, I think we can get = them to add an A record. I think it would be far more challenging for = SMBs to add a host like webfinger.example.com. That would still require = an A record and a service provider capable of supporting it. > =20 > Paul > =20 > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Tuesday, August 28, 2012 3:29 PM > To: Paul E. Jones > Cc: 'George Fletcher'; 'Mark Nottingham'; 'IETF Apps Discuss' > Subject: Re: [apps-discuss] Looking at Webfinger > =20 > There are cases where there are hosted domains (Google etc) that may = not have a http host for the domain name used in the users email = address. =20 > =20 > There may be merit to having a webfinger.example.com fallback where = the client can't reach the .well-known for the primary host. > =20 > I know that some sort of SRV record would be the correct way to do it, = but in the real world SMB don't enter SRV records even if there DNS = provider support them. > The most you can get them to do is add a CNAME or MX record. > =20 > Supporting these sorts of domains somehow is a important issue. > =20 > John B. > =20 > On 2012-08-28, at 3:17 PM, "Paul E. Jones" = wrote: >=20 >=20 >=20 > George, > =20 > I believe it might be useful to introduce those who break your = WebFinger server to Louisville Slugger. :) > =20 > Your pain is understood, but I do not see a way to avoid it. We could = introduce something in DNS, but that would also present challenges. No = matter where we =93root=94 the discovery process, there is a potential = somebody could break it. It could be rooted somewhere other than the = root of the domain (e.g., webfinger.example.com), but we either need to = decide in advance of such a location or introduce a way to discovery the = discovery resources. > =20 > Do you have a suggestion that would make this less likely to be = broken? > =20 > Paul > =20 > From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of George Fletcher > Sent: Tuesday, August 28, 2012 11:09 AM > To: Mark Nottingham > Cc: IETF Apps Discuss > Subject: Re: [apps-discuss] Looking at Webfinger > =20 > Way "late to the party" but I can speak from experience that = deployment can be a real issue in some environments. It's all really = straight forward in a small company or an environment where the identity = team "owns" the root domain (e.g. example.com). However, if an entire = other group in a large organization "owns" the root domain (home page = for the site) and the identity team then needs to get them to make = changes, the deployment solution gets brittle pretty quick. I've had our = webfinger support broken at least twice because the "other" team didn't = know that certain configs were required:) >=20 > Also, installing the "dynamic pluming" can be more problematic is = these cases. It is possible to get apache rewrite rules or netscaler = magic in place to make it work, it's just a more brittle deployment = architecture. >=20 > Thanks, > George >=20 > On 7/4/12 6:58 PM, John Panzer wrote: > Mark -- Of course I was speaking about practical realities of typical = web server administration and deployment. In practical terms, adding a = new mod_rewrite rule or moral equivalent is going to be easier than = adding a new PHP script that connects to a database. The latter is just = always going to be a much higher bar. > =20 > And, something that returns per-user data is generally going to need a = dynamic service of some kind, unless your site has just a handful of = users and you don't mind going through a publishing exercise each time = you add or change a user... > =20 > None of this has anything to do with the interface, just deployment = realities. And in reality all of this is going to need a dynamic = service somewhere for each non-trivial site, this is all just a question = of how to hook it up. >=20 > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > =20 > =20 >=20 > On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham wrote: > On 05/07/2012, at 8:16 AM, John Panzer wrote: >=20 > > Just as a historical note. The envisioned usage of host-meta was = originally to avoid a specification which mandated a particular dynamic = URL API at a particular /.well-known endpoint (because it may not be = feasible to do that across all organizations and deployments). The = host-meta document itself would be highly cacheable and so wouldn't = incur an additional network trip in the common case. > > > > Having a 3xx redirect is a reasonable alternative that allows a = similar escape hatch via something like mod_rewrite, albeit at the cost = of needing an additional network trip each time. Since a deployment can = always avoid the 3xx redirect with additional dynamic plumbing behind = the well-known endpoint, I don't think that's a horrible thing. > > > > An application-level redirect would be almost equivalent to an HTTP = redirect, but then there are two ways to do the same thing. If _only_ = an application-level redirect is allowed, then you have to have at least = a minimal dynamic service at the well-known endpoint (no more = mod_rewrite). But the whole reason for this is to avoid the requirement = for a dynamic service behind well-known... >=20 > "dynamic" and "static" are properties of the implementation, not the = interface. HTTP doesn't require that any particular URL be "dynamic"; = anything can, with the right metadata, be cached (and indeed, I've = cached many, many things with the wrong metadata, because of silly site = operators and their ideas about "dynamic"). >=20 > Now, if people want to target a particular implementation that makes = it easier to serve a particular style of URL without writing code, fine, = but let's not confuse things. >=20 > E.g., a URL like >=20 > http://example.com/.well-known/user/bob >=20 > is easy to serve in pretty much any way you like with Apache. >=20 > I'm also going to push back on the "it may not be feasible to do that = across all organizations and deployments" motivation. This is a race to = the bottom. The trick is to make it accessible enough to get sufficient = traction to pull everyone along, without pandering to *everyone*'s = requirements. >=20 > Regards, >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 >=20 > =20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > =20 > =20 > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > =20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > =20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 --Apple-Mail=_DBF1DF8E-A909-4D03-BF13-588718B0FC3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Having a webfinger host doesn't = necessarily move us away from .well-known.

I am not = attached to any particular solution.  

For = openID Connect we must be able to support google apps domains and = others.
For that the admins of those domains need to be able = to perform the configuration.   A solution that only works for an = expert will fail.

It also needs appropriate = security considerations.

One concern is if = discovery is not done securely it creates a phishing = opportunity.

If I can change someones discovery = record I can have a RP redirect them to a fake IdP and phish there = credentials.
Other protocols wishing to use webfinger may have = similar concerns.  That is why SWD is https: = only.

DNS without DNSsec is not without = issues.

It would be attractive to use a SRV = record to get the host and port for making the TLS request though for = security reasons the domain would need to match in some way unless you = are doing DNSsec. 
This seems like it may be too = complicated to work well.

I agree that = redirecting at the HTTP level using https: URI would work if domains can = deploy them.  
The question to Google and others who have = done the research is what can domain owners reasonably be expected to = do.

John B.

On = 2012-09-11, at 1:06 AM, "Paul E. Jones" <paulej@packetizer.com> = wrote:

 
I=92ve hosted my domains with the smallest = providers and I manage my primary domain myself.  In all cases, = I=92ve been able to use 3xx to redirect requests.  Do you think = this will not be workable for any domain = owners?
 
I agree that if we had to do it all over = again, we could explore lots of options.  I do like the idea of a = URI DNS record, but I=92m not sure if any clients would query for it = even if we mandated it at this point.
 
We could specify a = special name like =93_ 
 John = Panzer [mailto:jpanzer@google.com] 
Sent: Wednesday, August 29, 2012 = 2:13 PM
To: John = Bradley
Cc: Paul E. Jones; Mark = Nottingham; IETF Apps Discuss
Subject: Re: [apps-discuss] Looking = at Webfinger
 
Based on = experience, I'd prefer to avoid things that depend on the bare ("naked") = domain (example.com instead ofwww.example.com or webfinger.example.com).  I could = write up the reasons but it'd take some time.  Unfortunately, = webfinger as originally spec'd requires this.
 
If we were to start over, and get to vote for = whatever I wanted, and were going to allow DNS records at all, I would = probably vote for something like webfinger.example.com as a special magic name = (with the actual name chosen so as not to collide with any existing DNS = entries).  Any normal hosting mechanisms will work here, including = A records and CNAMEs and HTTP redirects, but I'd also require everything = be done via TLS with correctly signed certificates for that subdomain = (argh!  the pain!).
 

Organizationally, this would mean that any part of the = organization that can stand up a separate SSL service on a new subdomain = can provide webfinger services.  

On Wed, Aug 29, 2012 at 10:57 AM, John Bradley = <ve7jtb@ve7jtb.com> = wrote:
I am not the = best person to represent Google's needs.
 
However as I understand it Google hosts = applications such as email documents openID for tens of thousands of = domains.
The = people using the service generally add some MX records for aspmx.l.google.com. and a = Cname for mail.example.comto  
 webfinger.example.org is wildly = optimistic.
I am = entirely open to Ideas on this.   However the previous solution of = having every RP check with google first to see if they host the email = and provide the XRDS seems horribly flawed to = me.
I = would like to see a workable solution at the discovery layer that = accommodates how people deploy there = sites.
I = think Bill suggested at one point using the MX record to find the = webfinger host.  That has a bunch of problems I would prefer to = avoid.
John = B.
On = 2012-08-29, at 1:36 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:
John,
Well, we need to figure out how to address = this.
 
Would it be reasonable = to redirect requests from /.well-known/host-meta.json and = /.well-known/host-meta to Google?
Are there other services or files under = /.well-known that Google=92s customers would not want Google to = host?  If they were OK with Google=92s servers responding to = anything , then one could put an A (or CNAME) record in place = for  
Paul
 John Bradley [mailto: 
 
Do you have a suggestion = that would make this less likely to be = broken?
 
 
From: apps- 

example.com). However, if = an entire other group in a large organization "owns" the root domain = (home page for the site) and the identity team then needs to get them to = make changes, the deployment solution gets brittle pretty quick. I've = had our webfinger support broken at least twice because the "other" team = didn't know that certain configs were required:)

Also, installing = the "dynamic pluming" can be more problematic is these cases. It is = possible to get apache rewrite rules or netscaler magic in place to make = it work, it's just a more brittle deployment = architecture.

Thanks,
George

On 7/4/12 6:58 PM, John Panzer = wrote:
Mark -- Of = course I was speaking about practical realities of typical web server = administration and deployment.  In practical terms, adding a new = mod_rewrite rule or moral equivalent is going to be easier than adding a = new PHP script that connects to a database.  The latter is just = always going to be a much higher bar.
 
And, something that returns per-user data is = generally going to need a dynamic service of some kind, unless your site = has just a handful of users and you don't mind going through a = publishing exercise each time you add or change a = user...
None = of this has anything to do with the interface, just deployment = realities.  And in reality all of this is going to need a dynamic = service somewhere for each non-trivial site, this is all just a question = of how to hook it up.

--
John Panzer / Google
 

On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <On 05/07/2012, at 8:16 AM, John = Panzer wrote:

> Just as a historical note.  The = envisioned usage of host-meta was originally to avoid a specification = which mandated a particular dynamic URL API at a particular /.well-known = endpoint (because it may not be feasible to do that across all = organizations and deployments).  The host-meta document itself = would be highly cacheable and so wouldn't incur an additional network = trip in the common case.
>
> Having a 3xx redirect is a = reasonable alternative that allows a similar escape hatch via something = like mod_rewrite, albeit at the cost of needing an additional network = trip each time.  Since a deployment can always avoid the 3xx = redirect with additional dynamic plumbing behind the well-known = endpoint, I don't think that's a horrible thing.
>
> An = application-level redirect would be almost equivalent to an HTTP = redirect, but then there are two ways to do the same thing.  If = _only_ an application-level redirect is allowed, then you have to have = at least a minimal dynamic service at the well-known endpoint (no more = mod_rewrite).  But the whole reason for this is to avoid the = requirement for a dynamic service behind = well-known...

 
apps-discuss =
mailing list
apps-discuss@ietf.org
 

apps-discuss@ietf.org
In-Reply-To: Date: Tue, 11 Sep 2012 12:49:22 -0300 Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com> <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net> <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> <04f001cd8627$092727e0$1b7577a0$@packetizer.com> <90420743-8FE8-4EDB-98EF-D717D5346397@frobbit.se> <1346306587.53748.YahooMailNeo@web31804.mail.mud.yahoo.com> <251A4741-1E52-41D3-B4C8-43BEDE5C79B7@ve7jtb.com> To: Nat Sakimura X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQmdtwlOxj2zDhYL6us789+TuPLr/EoxLkoJRFBURhRGeyQNCaGAJr1XA1iDnTeBBwddpqHU Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 15:49:39 -0000 --Apple-Mail=_E2F8ADCD-07F1-4C32-A7D4-52BA3720ACBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Nat, TuCows supports SRV records at least for openSRS. Some of there = resellers may be using other things to manage DNS recodes and just using = them for registration, so it would be hard to make a blanket statement. I think using a SRV record introduces other security issues that would = have to be looked at without DNSsec. John B. On 2012-08-31, at 11:19 PM, Nat Sakimura wrote: > I think it is not the problem of the clients. Any decent scripting > language has the ability to query SRV records in DNS. >=20 > It is the problem of the DNS service provider, which always have GUI > for A and CNAME records but not necessarily TXT or SRV records. >=20 > Having said that, have we done the reality check on the above claim > that those providers do not support them? Quick check reveals the > following about top domain registrar's support SRV records (market > share is from = http://collegefallout.com/list-of-top-10-domain-name-registrars/ > which may not be correct) : >=20 > - Regstrar Name (market share) Support of SRV record >=20 > - GoDaddy (31%)YES > - enom.com (8.5%) YES > - TuCows (6.6%) ??? > - NetworkSolutions (5.4%) YES > - Schlund+Partner (4.3%) NO > - melbourneit (3.6%) NO > - Wild West Domains (2.8%) YES > - moniker.com (2.4%) ??? > - ResellerClub (2.2%) YES > - REGISTER.com (2.0%) YES >=20 > It is actually better than I thought. The world may be changing... >=20 > Nat >=20 >=20 > On Fri, Aug 31, 2012 at 6:00 AM, John Bradley = wrote: >> I agree that doing it via DNS would be the proper way. >>=20 >> The reality is that not all clients can easily access DNS directly. = Doing anything more than a http get reduces adoption. >>=20 >> Not all DNS providers support srv records. I think your draft on DNS = records has expired, and I know of no support for it. >> http://tools.ietf.org/html/draft-faltstrom-uri-06 >>=20 >> Something like DNS records would be the answer, I just don't think = protocols like Webfinger are likely to wait for wide deployment of that = as a underlying technology. >>=20 >> John B. >> On 2012-08-30, at 2:44 AM, Patrik F=E4ltstr=F6m = wrote: >>=20 >>> First, I did not talk about SRV records, but URI records. >>>=20 >>> Secondly, I think it is fascinating that people that love new things = like "the web" and new HTML5 features are the most conservative ones = regarding other protocols like DNS. >>>=20 >>> With that attitude, we have no evolution, and no innovation. >>>=20 >>> Providers that do not support such features will die. It is that = simple. >>>=20 >>> Patrik >>>=20 >>> On 30 aug 2012, at 08:03, William Mills = wrote: >>>=20 >>>> There are a few folks that feel that SRV records are not really an = option for hosting situatiosn where the users don't currently have the = ability to configure SRV records. >>>>=20 >>>> From: Patrik F=E4ltstr=F6m >>>> To: Paul E. Jones >>>> Cc: 'Mark Nottingham' ; 'IETF Apps Discuss' = >>>> Sent: Wednesday, August 29, 2012 8:01 PM >>>> Subject: Re: [apps-discuss] Looking at Webfinger >>>>=20 >>>> On 29 aug 2012, at 22:44, Paul E. Jones = wrote: >>>>=20 >>>>> 1) TXT records (e.g., _webfinger.packetizer.com IN TXT = =93https://packetizer.webfinger-provider.com/=94) >>>>=20 >>>> Please see URI Resource Record, for example: >>>>=20 >>>> _webfinger._tcp.packetizer.com. IN URI 0 0 = =93https://packetizer.webfinger-provider.com/=94 >>>>=20 >>>> Patrik >>>>=20 >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --Apple-Mail=_E2F8ADCD-07F1-4C32-A7D4-52BA3720ACBB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkx MTE1NDkyM1owIwYJKoZIhvcNAQkEMRYEFMfichbOGUGyBvsPJsv2HRUT3gvnMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AG3tjtXXzwkVZX89EzI7zBZfVaw28DdorF2BRuqi/HIY1fw50Qd7fRgE4aE7lKPE7el4t2mEta5E mifTNeYlQzi8qNbtfxQz0xPqVUsDC9wVtA0QNHKltlVC7Dvy+JtlrejsttskNyIl0Uq439DfZtBX DQfI+xkhnT0HA49v60BUESta6jgoorBtSnPjA8RBh12P4bIAtMXgrhdLtEXNppxrg84+v95Xer4w eQdVuRjPrb9Lj0fRkdQDi8+aDaJzxvXfxmECHaPsRSHpwdGWhEfGL8AxxOC5O/AJCGk7zuCjS1Bf m/ONVq/6ZhxhC61KdGxTfyZ0YiBbswNfRYD2lxcAAAAAAAA= --Apple-Mail=_E2F8ADCD-07F1-4C32-A7D4-52BA3720ACBB-- From Michael.Jones@microsoft.com Tue Sep 11 10:44:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA7721F87AF for ; Tue, 11 Sep 2012 10:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chPiq8go5PMY for ; Tue, 11 Sep 2012 10:44:06 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4737921F87A8 for ; Tue, 11 Sep 2012 10:44:06 -0700 (PDT) Received: from mail68-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id 14.1.225.23; Tue, 11 Sep 2012 17:44:04 +0000 Received: from mail68-va3 (localhost [127.0.0.1]) by mail68-va3-R.bigfish.com (Postfix) with ESMTP id CF1C83C00BD for ; Tue, 11 Sep 2012 17:44:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzc85fhzz1202h1d1ah1d2ahzz17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh1155h) Received-SPF: pass (mail68-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail68-va3 (localhost.localdomain [127.0.0.1]) by mail68-va3 (MessageSwitch) id 1347385443606023_21477; Tue, 11 Sep 2012 17:44:03 +0000 (UTC) Received: from VA3EHSMHS007.bigfish.com (unknown [10.7.14.237]) by mail68-va3.bigfish.com (Postfix) with ESMTP id 90448E0044 for ; Tue, 11 Sep 2012 17:44:03 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS007.bigfish.com (10.7.99.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 11 Sep 2012 17:44:01 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Tue, 11 Sep 2012 17:43:58 +0000 From: Mike Jones To: "apps-discuss@ietf.org" Thread-Topic: WebFinger should be HTTPS only Thread-Index: Ac2QRQSzltpZrwMvS1qOPhUEu+jxxA== Date: Tue, 11 Sep 2012 17:43:57 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667C07CC@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943667C07CCTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [apps-discuss] WebFinger should be HTTPS only X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 17:44:07 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943667C07CCTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Having looked at the WebFinger specification a bit more, I recently realize= d that it currently does not require TLS to be used. Section 5.1 - Perform= ing a WebFinger Query - currently begins "The first step a client must perf= orm in executing a WebFinger query is to query for the host metadata using = HTTPS or HTTP". This concerns me, since this may enable classes of phishin= g attacks in some situations. I would therefore request that the specification be updated to prohibit non= -TLS connections. Thank you, -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943667C07CCTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Having looked at the WebFinger specification a bit m= ore, I recently realized that it currently does not require TLS to be used.=   Section 5.1 - Performing a WebFinger Query – currently begins = “The first step a client must perform in executing a WebFinger query is to query for the host metadata using HTTPS or HTTP”.  This concerns me, since this may enable classe= s of phishing attacks in some situations.

 

I would therefore request that the specification be = updated to prohibit non-TLS connections.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; Thank you,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_4E1F6AAD24975D4BA5B1680429673943667C07CCTK5EX14MBXC284r_-- From mmn@hethane.se Tue Sep 11 11:40:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFDC21F84DC for ; Tue, 11 Sep 2012 11:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fx-WdjyjmwE9 for ; Tue, 11 Sep 2012 11:40:26 -0700 (PDT) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id A821B21F84D7 for ; Tue, 11 Sep 2012 11:40:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 11 Sep 2012 20:40:24 +0200 From: Mikael Nordfeldth To: In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667C07CC@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943667C07CC@TK5EX14MBXC284.redmond.corp.microsoft.com> Message-ID: <76e1f63c1744eb235efc2a298af4b294@hethane.se> X-Sender: mmn@hethane.se User-Agent: Roundcube Webmail/0.7.1 Subject: [apps-discuss] HTTPS-only WF would mean hassle or false sense of security X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 18:40:28 -0000 11.09.2012 19:43 skrev Mike Jones: > I would therefore request that the specification be updated to > prohibit non-TLS connections. Given that a lot of users don't trust several of today's main certificate authorities, I think it is an unnecessary requirement to force HTTPS usage on WebFinger. Should HTTPS be forced, reasonably you should also verify all WF providers' certificates thoroughly. It is a very unrealistic situation that this would give a reliable user experience. Not only the fact that we'd all have to have the same idea on who's a valid CA (I for one have removed several big CAs from /etc/ssl/certs), but also that Webfinger would only be deployable by administrators with ability to enable SSL - ruling out a lot of same-IP-virtual-hosting as of today. And if HTTPS certificate validation is not a MUST then I'd make the argument that HTTP is equally trustworthy. Either way I have personally never thought of using Webfinger as means of _authenticating_ more than having entries pointing to an OpenID provider or similar. And in that case I think it would be noticable enough for an end-user that one has been prompted with a phishing attempt when their OpenID Provider isn't what was expected. -- Mikael Nordfeldth http://blog.mmn-o.se/ mmn@hethane.se +46705657637 From internet-drafts@ietf.org Tue Sep 11 11:59:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6571121F865B; Tue, 11 Sep 2012 11:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fq378iptsnWY; Tue, 11 Sep 2012 11:59:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6904B21F8608; Tue, 11 Sep 2012 11:59:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120911185920.15727.44587.idtracker@ietfa.amsl.com> Date: Tue, 11 Sep 2012 11:59:20 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 18:59:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Additional Media Type Structured Syntax Suffixes Author(s) : Tony Hansen Alexey Melnikov Filename : draft-ietf-appsawg-media-type-suffix-regs-03.txt Pages : 14 Date : 2012-09-11 Abstract: A content media type name sometimes includes partitioned meta- information distinguish by a Structured Syntax, to permit noting an attribute of the media as a suffix to the name. This document defines several Structured Syntax Suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax Suffixes, and updates the "+xml" Message Type Structured Syntax Suffix registration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-suffix-regs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-media-type-suffix-reg= s-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alexey.melnikov@isode.com Tue Sep 11 12:05:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC0321F866A for ; Tue, 11 Sep 2012 12:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2bPRmquTlCa for ; Tue, 11 Sep 2012 12:05:42 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8B01D21F8596 for ; Tue, 11 Sep 2012 12:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1347390340; d=isode.com; s=selector; i=@isode.com; bh=SQUoXL1fT2BqQZTcd+eMulZOOy0WtZH4dwbyy20ni0I=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=xL/pPa/EIPKwgQ+pcA3L05AM3s4iye9idaJj8ShYupOvOEtsyLVFDpScYEY/BIBYiJDqXI Zth0fvPhupwutV5QO8e08Qnv+a+np+s02M3fsXlnZKsOL+7yrEbR19am8ntOKqQCQRigcG fvU66mEBciW2kKUI+AIkuPFSY1l3T3o=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 11 Sep 2012 20:05:40 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <504F8B98.3090002@isode.com> Date: Tue, 11 Sep 2012 20:06:00 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: apps-discuss@ietf.org References: <20120911185920.15727.44587.idtracker@ietfa.amsl.com> In-Reply-To: <20120911185920.15727.44587.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 19:05:43 -0000 On 11/09/2012 19:59, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : Additional Media Type Structured Syntax Suffixes > Author(s) : Tony Hansen > Alexey Melnikov > Filename : draft-ietf-appsawg-media-type-suffix-regs-03.txt > Pages : 14 > Date : 2012-09-11 > > Abstract: > A content media type name sometimes includes partitioned meta- > information distinguish by a Structured Syntax, to permit noting an > attribute of the media as a suffix to the name. This document > defines several Structured Syntax Suffixes for use with media type > registrations. In particular, it defines and registers the "+json", > "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax > Suffixes, and updates the "+xml" Message Type Structured Syntax > Suffix registration. This version addresses the following issues: 1) make the text about fragment identifiers for +ber/+der consistent with the rest of registrations (some minor textual differences, as there is no generic application/ber media type registered) 2) added a warning that updates to generic fragment identifier handling rules can break existing specific media type registrations. I didn't feel there was enough support for reversing the fragment identifier rules to make media type specific rules override generic +suffix rules, so I didn't do this change. I believe this addresses all outstanding issues I know of. Please have a quick look and let submit this document to IESG. Best Regards, Alexey From melvincarvalho@gmail.com Tue Sep 11 12:14:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC69D21F8685 for ; Tue, 11 Sep 2012 12:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id og3KYpDh0ga7 for ; Tue, 11 Sep 2012 12:14:46 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E025B21F8682 for ; Tue, 11 Sep 2012 12:14:45 -0700 (PDT) Received: by lahm15 with SMTP id m15so627273lah.31 for ; Tue, 11 Sep 2012 12:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3qkr6doY1b5ymQj+MSMRy/lNoE/bPTjASlyfsDIAmoQ=; b=G4UYgK0/R2vagZDjkkWEuFovh2lswlNMw98jlcC3zzVv7h9c3xvCNTEk2X5lqAN0uF 4wAyeaAeHnM9VVT5GCtwGKKkKNx51GIJxNRaYH3A0a3Sgu+g3a2ptwozTfPTu0NjXHtx 5QB+y8Lw8Cjh63UDTol6tp/toxgL83eX1oARF2RQ+QFQqLXJGraOCbI8HTZVQPbfaHX0 8apsT+zNdZHKTcrNUxRv2PMUc2nOOUiRn6pblYMHKnhjcUzHq736vVUNCUQUFUa7X959 Mdfu6W+C0mL5fxM/5NL8UoX4vCkZkZ0bLG/IqIOpqvuBcSYTQ7FargVwFsxp9P0iXlZq uNig== MIME-Version: 1.0 Received: by 10.152.110.9 with SMTP id hw9mr12106363lab.55.1347390884587; Tue, 11 Sep 2012 12:14:44 -0700 (PDT) Received: by 10.112.148.231 with HTTP; Tue, 11 Sep 2012 12:14:44 -0700 (PDT) In-Reply-To: <76e1f63c1744eb235efc2a298af4b294@hethane.se> References: <4E1F6AAD24975D4BA5B1680429673943667C07CC@TK5EX14MBXC284.redmond.corp.microsoft.com> <76e1f63c1744eb235efc2a298af4b294@hethane.se> Date: Tue, 11 Sep 2012 21:14:44 +0200 Message-ID: From: Melvin Carvalho To: Mikael Nordfeldth Content-Type: multipart/alternative; boundary=bcaec54b48860ca69e04c971e3e1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] HTTPS-only WF would mean hassle or false sense of security X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 19:14:47 -0000 --bcaec54b48860ca69e04c971e3e1 Content-Type: text/plain; charset=ISO-8859-1 On 11 September 2012 20:40, Mikael Nordfeldth wrote: > 11.09.2012 19:43 skrev Mike Jones: > >> I would therefore request that the specification be updated to >> prohibit non-TLS connections. >> > > Given that a lot of users don't trust several of today's main certificate > authorities, I think it is an unnecessary requirement to force HTTPS usage > on WebFinger. > > Should HTTPS be forced, reasonably you should also verify all WF > providers' certificates thoroughly. It is a very unrealistic situation that > this would give a reliable user experience. Not only the fact that we'd all > have to have the same idea on who's a valid CA (I for one have removed > several big CAs from /etc/ssl/certs), but also that Webfinger would only be > deployable by administrators with ability to enable SSL - ruling out a lot > of same-IP-virtual-hosting as of today. > > And if HTTPS certificate validation is not a MUST then I'd make the > argument that HTTP is equally trustworthy. > > Either way I have personally never thought of using Webfinger as means of > _authenticating_ more than having entries pointing to an OpenID provider or > similar. And in that case I think it would be noticable enough for an > end-user that one has been prompted with a phishing attempt when their > OpenID Provider isn't what was expected. > Perhaps an interesting data point is the following list of diaspora (which supports WF) hubs: http://podupti.me/ HTTP is marked in green and HTTPS is marked in red. Surprising to me was to see that over 90% of the hubs are actually HTTPS, as I might have expected the opposite to be the case! > > -- > Mikael Nordfeldth > http://blog.mmn-o.se/ > mmn@hethane.se > +46705657637 > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --bcaec54b48860ca69e04c971e3e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 11 September 2012 20:40, Mikael Nordf= eldth <mmn@hethane.se> wrote:
11.09.2012 19:43 skrev Mike Jones:
I would therefore request that the specification be updated to
prohibit non-TLS connections.

Given that a lot of users don't trust several of today's main certi= ficate authorities, I think it is an unnecessary requirement to force HTTPS= usage on WebFinger.

Should HTTPS be forced, reasonably you should also verify all WF providers&= #39; certificates thoroughly. It is a very unrealistic situation that this = would give a reliable user experience. Not only the fact that we'd all = have to have the same idea on who's a valid CA (I for one have removed = several big CAs from /etc/ssl/certs), but also that Webfinger would only be= deployable by administrators with ability to enable SSL - ruling out a lot= of same-IP-virtual-hosting as of today.

And if HTTPS certificate validation is not a MUST then I'd make the arg= ument that HTTP is equally trustworthy.

Either way I have personally never thought of using Webfinger as means of _= authenticating_ more than having entries pointing to an OpenID provider or = similar. And in that case I think it would be noticable enough for an end-u= ser that one has been prompted with a phishing attempt when their OpenID Pr= ovider isn't what was expected.

Perhaps an interesting data point is th= e following list of diaspora (which supports WF) hubs:

http://podupti.me/

HTTP is marked in green and= HTTPS is marked in red.

Surprising to me was to see that over 90% of the hubs are actually HTTP= S, as I might have expected the opposite to be the case!
=A0

--
Mikael Nordfeldth
http://blog.mmn-o.se/
mmn@hethane.se
+46= 705657637
_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--bcaec54b48860ca69e04c971e3e1-- From evan@status.net Tue Sep 11 12:16:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF4D21F8685 for ; Tue, 11 Sep 2012 12:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXYjU+N8P11G for ; Tue, 11 Sep 2012 12:16:22 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 7002321F8682 for ; Tue, 11 Sep 2012 12:16:16 -0700 (PDT) Received: from [192.168.0.113] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id AB9CE8D602C for ; Tue, 11 Sep 2012 19:26:16 +0000 (UTC) Message-ID: <504F8DF9.2080603@status.net> Date: Tue, 11 Sep 2012 15:16:09 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <4E1F6AAD24975D4BA5B1680429673943667C07CC@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667C07CC@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------080405080506090302020807" Subject: Re: [apps-discuss] WebFinger should be HTTPS only X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 19:16:23 -0000 This is a multi-part message in MIME format. --------------080405080506090302020807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12-09-11 01:43 PM, Mike Jones wrote: > > Having looked at the WebFinger specification a bit more, I recently > realized that it currently does not require TLS to be used. Section > 5.1 - Performing a WebFinger Query -- currently begins "The first step > a client must perform in executing a WebFinger query is to query for > the host metadata using HTTPS or HTTP". This concerns me, since this > may enable classes of phishing attacks in some situations. > > I think that HTTPS should be required /in those situations/, then. Here's the language from RFC 6415: Applications utilizing the host-meta document where the authenticity of the information is necessary MUST require the use of the HTTPS protocol and MUST NOT produce a host-meta document using other means. In addition, such applications MUST require that any redirection leading to the retrieval of a host-meta document also utilize the HTTPS protocol. I think this strikes a nice balance. -Evan --------------080405080506090302020807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12-09-11 01:43 PM, Mike Jones wrote:

Having looked at the WebFinger specification a bit more, I recently realized that it currently does not require TLS to be used.  Section 5.1 - Performing a WebFinger Query – currently begins “The first step a client must perform in executing a WebFinger query is to query for the host metadata using HTTPS or HTTP”.  This concerns me, since this may enable classes of phishing attacks in some situations.


I think that HTTPS should be required in those situations, then.

Here's the language from RFC 6415:
   Applications utilizing the host-meta document where the authenticity
   of the information is necessary MUST require the use of the HTTPS
   protocol and MUST NOT produce a host-meta document using other means.
   In addition, such applications MUST require that any redirection
   leading to the retrieval of a host-meta document also utilize the
   HTTPS protocol.
I think this strikes a nice balance.

-Evan


--------------080405080506090302020807-- From mmorley@mpcm.com Tue Sep 11 16:59:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BCA21F8646 for ; Tue, 11 Sep 2012 16:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnNnJB1JqgJT for ; Tue, 11 Sep 2012 16:59:14 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id ED56121F861B for ; Tue, 11 Sep 2012 16:59:13 -0700 (PDT) Received: by qafk1 with SMTP id k1so1149776qaf.1 for ; Tue, 11 Sep 2012 16:59:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=3n/DSAlYwW9WL11Wx4HVgtyNBH5BPjnW+8At8ssNibw=; b=S1JjWTrY2fmp20MH/4jVpNOysZOL9dMRYh0mPJ/Kq8BZK1DFWequkhEAEi5eyjx2Jp cM/W1UrJPwhCDiwyDqHpdjxkRPuIjBQXvVwwTvXI93QnHtc/6j67GvJA1Lc1dD9Orn5i kcGODjsSOnpGfaA26vNhoduSpX9+K6omhhit5Qpx8jUnsXIc63M/WzPcH84iWX0wz7b+ AtaO6rsg/zsNuW7AQt+j32GuzC9dx+5FgF+sp1vChbMxSmi7/+rv4eW6YnjlFhDlDqjh 77yBEgtDQBQLZHpKxausoIAOENMeYsvP3wBuetHUNt+VpRIfzWh3KXP0u+CHkdnCpdqS 2CIg== MIME-Version: 1.0 Received: by 10.224.196.135 with SMTP id eg7mr20995018qab.24.1347407948753; Tue, 11 Sep 2012 16:59:08 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.49.30.66 with HTTP; Tue, 11 Sep 2012 16:59:08 -0700 (PDT) In-Reply-To: <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> Date: Tue, 11 Sep 2012 19:59:08 -0400 X-Google-Sender-Auth: 1z6P3zVTygM_lOxhLAscGnKEWUw Message-ID: From: Matthew Morley To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=20cf3005ddb0272c7804c975dcf0 X-Gm-Message-State: ALoCoQnC2AbbEvWYeDc6RoFaQ7isTnVMH6cdZ5pNQ0Blvjvm3iOt2HjQYO9cxr5tSggOWa51o7jG Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 23:59:15 -0000 --20cf3005ddb0272c7804c975dcf0 Content-Type: text/plain; charset=ISO-8859-1 As long as there is a "test" operation, people are going to want to extend it into something that matches complex conditionals that exist in the base languages. I'm not convinced of the value in the operation as it exists. I'm concerned about what it would become as well, to fit people's real needs needs. My initial reaction was that I would use this operation to test a 'version' field within the data at the top level. This way sequential patching could indicate if a patch is sufficient to bring an object to a certain state. But really in describing the patch, we are already making the assumption that we are applying it to the right json later. Or something 'right' enough. Conditional matching/logic is something worthy of a spec, but I'm not convinced this is that specification. How are people using the test operation in practice now? I'm assuming only non-structured matching is recommended... or is deep comparison of structured types suggested? Would this not be better handled outside of the work description itself? -- Matt (MPCM) On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan wrote: > ** > On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote: > > On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan wrote: > > Unfortunately, null is a testable value and should not be interpreted to > mean lack of value > > > Indeed, but I'd argue that the two cases are semantically equivalent > enough for the such differences to be irrelevant. Particularly since many > (if not most) json vocabularies tend to treat null and undefined as being > equivalent. > > > While there are some languages that do not make this distinction, I must > disagree with your conclusion that it is irrelevant. In JavaScript, null != > undefined. The JSON specification went out of its way to define an explicit > null value. I do not want to create ambiguities in the test operation, nor > do I want to create incompatibilities with different implementations where > the treatment of null may be concerned. > > > There is a clear use case for this and we can bind the scope simply by > saying that, within json patch, undefined and null are equivalent. > > > And what is the clear use case for this? > > Paul > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --20cf3005ddb0272c7804c975dcf0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As long as there is a "test" operation, people are going to want = to extend it into something that matches complex conditionals that exist in= the base languages. I'm not convinced of the value in the operation as= it exists. I'm concerned about what it would become as well, to fit pe= ople's real needs needs.

My initial reaction was that I would use this operation to test a '= version' field within the data at the top level. This way sequential pa= tching could indicate if a patch is=A0sufficient=A0to bring an object to a = certain state. But really in describing the patch, we are already making th= e assumption that we are applying it to the right json later. Or something = 'right' enough.

Conditional matching/logic is something worthy of a spec, but I= 9;m not convinced this is that specification.

How = are people using the test operation in practice now? I'm assuming only = non-structured matching is recommended... or is deep comparison of structur= ed types suggested?

Would this not be better handled outside of the work description itself= ?

--=A0
Matt (MPCM)

On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan <= ;pbryan@anode.ca&g= t; wrote:
=20 =20
On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote:

On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
Unfortunately, null is a testable value and should not be interpret= ed to mean lack of value

Indeed, but I'd argue that the two cases are semantically equivalen= t enough for the such differences to be irrelevant. Particularly since many= (if not most) json vocabularies tend to treat null and undefined as being = equivalent.

While there are some languages that do not make this distinction, I must di= sagree with your conclusion that it is irrelevant. In JavaScript, null !=3D= undefined. The JSON specification went out of its way to define an explici= t null value. I do not want to create ambiguities in the test operation, no= r do I want to create incompatibilities with different implementations wher= e the treatment of null may be concerned.


There is a clear use case for this and we can bind the scope simply by= saying that, within json patch, undefined and null are equivalent.

And what is the clear use case for this?

Paul

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--20cf3005ddb0272c7804c975dcf0-- From jasnell@gmail.com Tue Sep 11 17:12:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE19821F8678 for ; Tue, 11 Sep 2012 17:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvFDUdUASlfF for ; Tue, 11 Sep 2012 17:12:25 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 726ED21F8674 for ; Tue, 11 Sep 2012 17:12:25 -0700 (PDT) Received: by wgbfm10 with SMTP id fm10so1033602wgb.34 for ; Tue, 11 Sep 2012 17:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EHpjPn0QGrERACbiSHJyUxRWdOMMxaj1/4AkwrEfIXc=; b=BHNucyD5EIiB+3q83Dl6t9AHTVQJXCHCBVx0SZyAASXocKrshDr+HzjIejtDOi6tz0 Dtpwb6FIUDTE3gXRfYsY5z2XP9Fqj0WMJXJcHO4EvU1tXHVQEWo5CEb1jrPtHP4V6bUE auzViRXC1aqCBEQA24bUmy4gjPaAzvy+BuRkqbIsine8UX3qCSqoSyJ23iKo6GBTWYIx pcU2SBsfQoDUw4/aaCA9Xdj/ah/bTL5Ijm+vNVk+CvaKQqAa7n4LEMuc6NQzKR6gvE5J hVnAv4hYymK1BX76MiftJaNM/7ufFpHc7V+YlA86E4TdVDkWL4gbpO5SsKaqiNbNEDvF jVpg== Received: by 10.180.77.34 with SMTP id p2mr28607778wiw.0.1347408744238; Tue, 11 Sep 2012 17:12:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.96.2 with HTTP; Tue, 11 Sep 2012 17:12:03 -0700 (PDT) In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> From: James M Snell Date: Tue, 11 Sep 2012 17:12:03 -0700 Message-ID: To: Matthew Morley Content-Type: multipart/alternative; boundary=f46d043c7dd4914e0504c9760b25 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 00:12:26 -0000 --f46d043c7dd4914e0504c9760b25 Content-Type: text/plain; charset=UTF-8 The more I look through this, the more I'm generally inclined to agree. As was discussed in the separate thread I brought up about extending json-patch, it is possible to define a super-set of json-patch that introduces a range of potentially very useful predicate operations that follow the same fundamental design as json-patch. Done properly, the two can be layered in interesting ways. "test" can easily fit into the separate specification, allowing json-patch to focus specifically on defining the change operations. - James On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley wrote: > As long as there is a "test" operation, people are going to want to extend > it into something that matches complex conditionals that exist in the base > languages. I'm not convinced of the value in the operation as it exists. > I'm concerned about what it would become as well, to fit people's real > needs needs. > > My initial reaction was that I would use this operation to test a > 'version' field within the data at the top level. This way sequential > patching could indicate if a patch is sufficient to bring an object to a > certain state. But really in describing the patch, we are already making > the assumption that we are applying it to the right json later. Or > something 'right' enough. > > Conditional matching/logic is something worthy of a spec, but I'm not > convinced this is that specification. > > How are people using the test operation in practice now? I'm assuming only > non-structured matching is recommended... or is deep comparison of > structured types suggested? > > Would this not be better handled outside of the work description itself? > > -- > Matt (MPCM) > > On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan wrote: > >> ** >> On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote: >> >> On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan >> wrote: >> >> Unfortunately, null is a testable value and should not be interpreted >> to mean lack of value >> >> >> Indeed, but I'd argue that the two cases are semantically equivalent >> enough for the such differences to be irrelevant. Particularly since many >> (if not most) json vocabularies tend to treat null and undefined as being >> equivalent. >> >> >> While there are some languages that do not make this distinction, I must >> disagree with your conclusion that it is irrelevant. In JavaScript, null != >> undefined. The JSON specification went out of its way to define an explicit >> null value. I do not want to create ambiguities in the test operation, nor >> do I want to create incompatibilities with different implementations where >> the treatment of null may be concerned. >> >> >> There is a clear use case for this and we can bind the scope simply by >> saying that, within json patch, undefined and null are equivalent. >> >> >> And what is the clear use case for this? >> >> Paul >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > --f46d043c7dd4914e0504c9760b25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The more I look through this, the more= I'm generally inclined to agree. As was discussed in the separate thre= ad I brought up about extending json-patch, it is possible to define a supe= r-set of json-patch that introduces a range of potentially very useful pred= icate operations that follow the same fundamental design as json-patch. Don= e properly, the two can be layered in interesting ways. "test" ca= n easily fit into the separate specification, allowing json-patch to focus = specifically on defining the change operations.=C2=A0

- James

On Tu= e, Sep 11, 2012 at 4:59 PM, Matthew Morley <matt@mpcm.com> wrote= :
As long as there is a "test" opera= tion, people are going to want to extend it into something that matches com= plex conditionals that exist in the base languages. I'm not convinced o= f the value in the operation as it exists. I'm concerned about what it = would become as well, to fit people's real needs needs.

My initial reaction was that I would use this operation to test a '= version' field within the data at the top level. This way sequential pa= tching could indicate if a patch is=C2=A0sufficient=C2=A0to bring an object= to a certain state. But really in describing the patch, we are already mak= ing the assumption that we are applying it to the right json later. Or some= thing 'right' enough.

Conditional matching/logic is something worthy of a spec, but I= 9;m not convinced this is that specification.

How = are people using the test operation in practice now? I'm assuming only = non-structured matching is recommended... or is deep comparison of structur= ed types suggested?

Would this not be better handled outside of the work description itself= ?

--=C2=A0
Mat= t (MPCM)

On Mon,= Sep 10, 2012 at 2:59 PM, Paul C. Bryan <pbryan@anode.ca> wrot= e:
=20 =20
On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote:

On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
Unfortunately, null is a testable value and should not be interpret= ed to mean lack of value

Indeed, but I'd argue that the two cases are semantically equivalen= t enough for the such differences to be irrelevant. Particularly since many= (if not most) json vocabularies tend to treat null and undefined as being = equivalent.

While there are some languages that do not make this distinction, I must di= sagree with your conclusion that it is irrelevant. In JavaScript, null !=3D= undefined. The JSON specification went out of its way to define an explici= t null value. I do not want to create ambiguities in the test operation, no= r do I want to create incompatibilities with different implementations wher= e the treatment of null may be concerned.


There is a clear use case for this and we can bind the scope simply by= saying that, within json patch, undefined and null are equivalent.

And what is the clear use case for this?

Paul

_________________________________________= ______
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss



--f46d043c7dd4914e0504c9760b25-- From pbryan@anode.ca Tue Sep 11 18:36:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C18121E804A for ; Tue, 11 Sep 2012 18:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnyliIN8Jlj2 for ; Tue, 11 Sep 2012 18:36:38 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCFB21E8048 for ; Tue, 11 Sep 2012 18:36:38 -0700 (PDT) Received: from [192.168.1.10] (S0106a021b762dbb3.vf.shawcable.net [174.1.50.247]) by maple.anode.ca (Postfix) with ESMTPSA id 83D616156; Wed, 12 Sep 2012 01:36:35 +0000 (UTC) Message-ID: <1347413811.4006.3.camel@polyjuice> From: "Paul C. Bryan" To: Matthew Morley Date: Tue, 11 Sep 2012 18:36:51 -0700 In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> Content-Type: multipart/alternative; boundary="=-7MgjyVdQDOLrYMWdBG2p" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 01:36:39 -0000 --=-7MgjyVdQDOLrYMWdBG2p Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit What are people's real needs you're thinking about fitting? It's been said that there is a concrete use case for extending the functionality of test, but I've yet to hear anything beyond the theoretical. Without knowing these, it's all just conjecture to me. Paul On Tue, 2012-09-11 at 19:59 -0400, Matthew Morley wrote: > As long as there is a "test" operation, people are going to want to > extend it into something that matches complex conditionals that exist > in the base languages. I'm not convinced of the value in the operation > as it exists. I'm concerned about what it would become as well, to fit > people's real needs needs. > > > My initial reaction was that I would use this operation to test a > 'version' field within the data at the top level. This way sequential > patching could indicate if a patch is sufficient to bring an object to > a certain state. But really in describing the patch, we are already > making the assumption that we are applying it to the right json later. > Or something 'right' enough. > > Conditional matching/logic is something worthy of a spec, but I'm not > convinced this is that specification. > > > How are people using the test operation in practice now? I'm assuming > only non-structured matching is recommended... or is deep comparison > of structured types suggested? > > Would this not be better handled outside of the work description > itself? > > > -- > Matt (MPCM) > > > On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan > wrote: > > On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote: > > > > On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan > > wrote: > > > > Unfortunately, null is a testable value and should > > not be interpreted to mean lack of value > > > > > > Indeed, but I'd argue that the two cases are semantically > > equivalent enough for the such differences to be irrelevant. > > Particularly since many (if not most) json vocabularies tend > > to treat null and undefined as being equivalent. > > > > > While there are some languages that do not make this > distinction, I must disagree with your conclusion that it is > irrelevant. In JavaScript, null != undefined. The JSON > specification went out of its way to define an explicit null > value. I do not want to create ambiguities in the test > operation, nor do I want to create incompatibilities with > different implementations where the treatment of null may be > concerned. > > > > > > There is a clear use case for this and we can bind the scope > > simply by saying that, within json patch, undefined and null > > are equivalent. > > > > > And what is the clear use case for this? > > Paul > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > --=-7MgjyVdQDOLrYMWdBG2p Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit What are people's real needs you're thinking about fitting? It's been said that there is a concrete use case for extending the functionality of test, but I've yet to hear anything beyond the theoretical. Without knowing these, it's all just conjecture to me.

Paul

On Tue, 2012-09-11 at 19:59 -0400, Matthew Morley wrote:
As long as there is a "test" operation, people are going to want to extend it into something that matches complex conditionals that exist in the base languages. I'm not convinced of the value in the operation as it exists. I'm concerned about what it would become as well, to fit people's real needs needs.

My initial reaction was that I would use this operation to test a 'version' field within the data at the top level. This way sequential patching could indicate if a patch is sufficient to bring an object to a certain state. But really in describing the patch, we are already making the assumption that we are applying it to the right json later. Or something 'right' enough.

Conditional matching/logic is something worthy of a spec, but I'm not convinced this is that specification.


How are people using the test operation in practice now? I'm assuming only non-structured matching is recommended... or is deep comparison of structured types suggested?

Would this not be better handled outside of the work description itself?


-- 
Matt (MPCM)

On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote:

On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
Unfortunately, null is a testable value and should not be interpreted to mean lack of value

Indeed, but I'd argue that the two cases are semantically equivalent enough for the such differences to be irrelevant. Particularly since many (if not most) json vocabularies tend to treat null and undefined as being equivalent.


While there are some languages that do not make this distinction, I must disagree with your conclusion that it is irrelevant. In JavaScript, null != undefined. The JSON specification went out of its way to define an explicit null value. I do not want to create ambiguities in the test operation, nor do I want to create incompatibilities with different implementations where the treatment of null may be concerned.


There is a clear use case for this and we can bind the scope simply by saying that, within json patch, undefined and null are equivalent.


And what is the clear use case for this?

Paul


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss




--=-7MgjyVdQDOLrYMWdBG2p-- From mnot@mnot.net Tue Sep 11 18:57:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F4021F8584 for ; Tue, 11 Sep 2012 18:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.392 X-Spam-Level: X-Spam-Status: No, score=-103.392 tagged_above=-999 required=5 tests=[AWL=-0.793, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfo7YFLZRtbV for ; Tue, 11 Sep 2012 18:57:22 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id E9D3A21F8582 for ; Tue, 11 Sep 2012 18:57:21 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3BAEE22E255; Tue, 11 Sep 2012 21:57:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> Date: Wed, 12 Sep 2012 11:57:10 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <0B188E69-8680-4E35-95EB-A769FF107A1C@mnot.net> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> To: Paul C. Bryan X-Mailer: Apple Mail (2.1486) Cc: Apps Discuss Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 01:57:24 -0000 Well, if someone really wanted that, we could do something like { "test": "/a/b/c", "present": false } Do we have a real use case for that? To be clear -- I do *not* want to throw the kitchen sink in here. = Testing for presence seemed easy to support and implement, and = personally I think there's a reasonable chance of it being used.=20 =46rom here, I think we could do any of: a) Revert the patch to test for presence b) Leave it as is (with test for presence c) Expand to support test for absence, e.g., as above Personally, my preference would be (b), although I don't have a problem = with (a) if it helps us move forward. (c) seems like gilding the lily to = me.=20 Cheers, On 11/09/2012, at 3:07 AM, Paul C. Bryan wrote: > Well, the natural next question is, how do you test for the lack of a = value? Slippery slope... >=20 > Paul >=20 > On Mon, 2012-09-10 at 21:59 +1000, Mark Nottingham wrote: >> That seems like a useful thing; I've tried it out here: >> =20 >> http://trac.tools.ietf.org/wg/appsawg/trac/changeset/112 >>=20 >>=20 >> Cheers, >>=20 >> On 06/09/2012, at 4:42 AM, James M Snell < >> jasnell@gmail.com >> > wrote: >>=20 >> > One additional point, I note that with the current "test" = operation, the "value" property is assumed to be required. What if all I = want to do is test for the presence of a property? = {"test":"/a/b/c","value":null} can be used to test that the property is = null, but what if I don't care about the specific value? can I do, = {"test":"/a/b/c"} ? >> >=20 >> > - James >> >=20 >> > On Wed, Sep 5, 2012 at 8:47 AM, James M Snell < >> jasnell@gmail.com >> > wrote: >> > Three points...=20 >> >=20 >> > 1) Re: test ... I would like to see more detail on why "test" would = be used in a patch document. Perhaps just by expanding on the example = just a bit. >> >=20 >> > 2) Section 5's discussion of error handling should be expanded a = bit. Yes the changes are atomic but a clear example of exactly what that = means would be helpful. >> >=20 >> > Example: This json-patch would result in no changes being made to = the document at all. >> >=20 >> > [ >> > {"replace": "/a/b/c", "value": 42}, >> > {"test": "/a/b/c", "value": "C"} >> > ] >> >=20 >> > 3) Unless we specifically want to allow for such things, it should = be made clear that "test" is not intended to be used as a replacement = for other types of http conditionals. For instance, I could imagine = someone doing something like... >> >=20 >> > [ >> > {"test": "/foo/last-updated", "value": "2012-12-12T12:12:12Z"}, >> > ("add": "/a/b/c", "value": 42} >> > ] >> >=20 >> > Or... >> >=20 >> > [ >> > {"test": "/@etag", "value": "ABC123"}, >> > ("add": "/a/b/c", "value": 42} >> > ] >> >=20 >> > - James >> >=20 >> >=20 >> > On Wed, Sep 5, 2012 at 12:18 AM, Mark Nottingham < >> mnot@mnot.net >> > wrote: >> > I've just submitted revised json-pointer and json-patch documents, = based upon feedback. >> >=20 >> > As far as I can tell, the only open issue on JSON-Patch is about = 'test': >> > =20 >> http://trac.tools.ietf.org/wg/appsawg/trac/ticket/7 >>=20 >> >=20 >> > In Vancouver, we said that we'd wait for implementation experience = to see if 'test' is worthwhile. >> >=20 >> > In the meantime, I've found two implementations of json-patch "in = the wild": >> > =20 >> https://github.com/stefankoegl/python-json-patch >>=20 >> > =20 >> https://github.com/bruth/jsonpatch-js >>=20 >> >=20 >> > Both are somewhat old, and both support 'test'. >> >=20 >> > As such, I'd suggest we let 'test' remain in the spec (I think = there are good arguments for it anyway), and ship it. >> >=20 >> > Make sense? >> >=20 >> > -- >> > Mark Nottingham =20 >> http://www.mnot.net/ >>=20 >> >=20 >> >=20 >> >=20 >> > _______________________________________________ >> > apps-discuss mailing list >> >=20 >> apps-discuss@ietf.org >>=20 >> >=20 >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> >=20 >> >=20 >>=20 >> -- >> Mark Nottingham =20 >> http://www.mnot.net/ >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >>=20 >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 -- Mark Nottingham http://www.mnot.net/ From Peter.Rushforth@NRCan-RNCan.gc.ca Wed Sep 12 04:45:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D499121F8602 for ; Wed, 12 Sep 2012 04:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeMJdnqzVRVn for ; Wed, 12 Sep 2012 04:45:16 -0700 (PDT) Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCB621F85F4 for ; Wed, 12 Sep 2012 04:45:15 -0700 (PDT) Received: from S-BSC-CAS1.nrn.nrcan.gc.ca (132.156.238.11) by S-BSC-EDGE1.nrcan.gc.ca (132.156.238.13) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 12 Sep 2012 07:45:14 -0400 Received: from S-BSC-MBX1.nrn.nrcan.gc.ca ([169.254.1.198]) by S-BSC-CAS1.nrn.nrcan.gc.ca ([fe80::c0ec:b772:2bfe:c34d%18]) with mapi id 14.02.0318.001; Wed, 12 Sep 2012 07:45:14 -0400 From: "Rushforth, Peter" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-03.txt Thread-Index: AQHNkFBzxrqF3LhOs0qTvqXJIn3u3JeGlqUQ Date: Wed, 12 Sep 2012 11:45:12 +0000 Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF1AE51E2C@S-BSC-MBX1.nrn.nrcan.gc.ca> References: <20120911185920.15727.44587.idtracker@ietfa.amsl.com> <504F8B98.3090002@isode.com> In-Reply-To: <504F8B98.3090002@isode.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.156.238.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 11:45:17 -0000 Hi, Is it forbidden by structured suffix reg procedures to register stacked suf= fixes? e.g. application/foo+bar+xml Thanks=20 Peter Rushforth > -----Original Message----- > From: apps-discuss-bounces@ietf.org=20 > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Alexey Melnikov > Sent: September 11, 2012 15:06 > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action:=20 > draft-ietf-appsawg-media-type-suffix-regs-03.txt >=20 > On 11/09/2012 19:59, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > This draft is a work item of the Applications Area=20 > Working Group Working Group of the IETF. > > > > Title : Additional Media Type Structured=20 > Syntax Suffixes > > Author(s) : Tony Hansen > > Alexey Melnikov > > Filename :=20 > draft-ietf-appsawg-media-type-suffix-regs-03.txt > > Pages : 14 > > Date : 2012-09-11 > > > > Abstract: > > A content media type name sometimes includes partitioned meta- > > information distinguish by a Structured Syntax, to=20 > permit noting an > > attribute of the media as a suffix to the name. This document > > defines several Structured Syntax Suffixes for use with=20 > media type > > registrations. In particular, it defines and registers=20 > the "+json", > > "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip"=20 > Structured Syntax > > Suffixes, and updates the "+xml" Message Type Structured Syntax > > Suffix registration. >=20 > This version addresses the following issues: >=20 > 1) make the text about fragment identifiers for +ber/+der=20 > consistent with the rest of registrations (some minor textual=20 > differences, as there is no generic application/ber media=20 > type registered) >=20 > 2) added a warning that updates to generic fragment=20 > identifier handling rules can break existing specific media=20 > type registrations. >=20 > I didn't feel there was enough support for reversing the=20 > fragment identifier rules to make media type specific rules=20 > override generic=20 > +suffix rules, so I didn't do this change. >=20 > I believe this addresses all outstanding issues I know of. >=20 > Please have a quick look and let submit this document to IESG. >=20 > Best Regards, > Alexey >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > = From Peter.Rushforth@NRCan-RNCan.gc.ca Wed Sep 12 07:56:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A230421F861F for ; Wed, 12 Sep 2012 07:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XdW3GfjFhwL for ; Wed, 12 Sep 2012 07:56:15 -0700 (PDT) Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id C650521F8602 for ; Wed, 12 Sep 2012 07:56:14 -0700 (PDT) Received: from S-BSC-CAS2.nrn.nrcan.gc.ca (132.156.238.12) by S-BSC-EDGE1.nrcan.gc.ca (132.156.238.13) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 12 Sep 2012 10:56:13 -0400 Received: from S-BSC-MBX1.nrn.nrcan.gc.ca ([169.254.1.198]) by S-BSC-CAS2.nrn.nrcan.gc.ca ([fe80::48d4:f168:78ba:d4e8%19]) with mapi id 14.02.0318.001; Wed, 12 Sep 2012 10:56:13 -0400 From: "Rushforth, Peter" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-03.txt Thread-Index: AQHNkFBzxrqF3LhOs0qTvqXJIn3u3JeGlqUQgAA1noA= Date: Wed, 12 Sep 2012 14:56:13 +0000 Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF1AE5229C@S-BSC-MBX1.nrn.nrcan.gc.ca> References: <20120911185920.15727.44587.idtracker@ietfa.amsl.com> <504F8B98.3090002@isode.com> <1CD55F04538DEA4F85F3ADF7745464AF1AE51E2C@S-BSC-MBX1.nrn.nrcan.gc.ca> In-Reply-To: <1CD55F04538DEA4F85F3ADF7745464AF1AE51E2C@S-BSC-MBX1.nrn.nrcan.gc.ca> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.156.238.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:56:15 -0000 Hi again, RFC 3023 has some discussion of this topic here: https://tools.ietf.org/html/rfc3023#appendix-A.14 Wondering if that is a preferred approach? Am I off topic? If so, apologies. Thanks Peter > -----Original Message----- > From: apps-discuss-bounces@ietf.org=20 > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Rushforth, Peter > Sent: September 12, 2012 07:45 > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action:=20 > draft-ietf-appsawg-media-type-suffix-regs-03.txt >=20 > Hi, >=20 > Is it forbidden by structured suffix reg procedures to=20 > register stacked suffixes? > e.g. application/foo+bar+xml >=20 > Thanks > Peter Rushforth >=20 > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org > > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Alexey Melnikov > > Sent: September 11, 2012 15:06 > > To: apps-discuss@ietf.org > > Subject: Re: [apps-discuss] I-D Action:=20 > > draft-ietf-appsawg-media-type-suffix-regs-03.txt > >=20 > > On 11/09/2012 19:59, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > This draft is a work item of the Applications Area > > Working Group Working Group of the IETF. > > > > > > Title : Additional Media Type Structured=20 > > Syntax Suffixes > > > Author(s) : Tony Hansen > > > Alexey Melnikov > > > Filename :=20 > > draft-ietf-appsawg-media-type-suffix-regs-03.txt > > > Pages : 14 > > > Date : 2012-09-11 > > > > > > Abstract: > > > A content media type name sometimes includes partitioned meta- > > > information distinguish by a Structured Syntax, to > > permit noting an > > > attribute of the media as a suffix to the name. This document > > > defines several Structured Syntax Suffixes for use with > > media type > > > registrations. In particular, it defines and registers > > the "+json", > > > "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip"=20 > > Structured Syntax > > > Suffixes, and updates the "+xml" Message Type=20 > Structured Syntax > > > Suffix registration. > >=20 > > This version addresses the following issues: > >=20 > > 1) make the text about fragment identifiers for +ber/+der=20 > consistent=20 > > with the rest of registrations (some minor textual differences, as=20 > > there is no generic application/ber media type registered) > >=20 > > 2) added a warning that updates to generic fragment identifier=20 > > handling rules can break existing specific media type registrations. > >=20 > > I didn't feel there was enough support for reversing the fragment=20 > > identifier rules to make media type specific rules override generic > > +suffix rules, so I didn't do this change. > >=20 > > I believe this addresses all outstanding issues I know of. > >=20 > > Please have a quick look and let submit this document to IESG. > >=20 > > Best Regards, > > Alexey > >=20 > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > = From pbryan@anode.ca Wed Sep 12 09:10:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF0B21F856C for ; Wed, 12 Sep 2012 09:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGWT3Aa95tG3 for ; Wed, 12 Sep 2012 09:10:04 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 74F1521F858F for ; Wed, 12 Sep 2012 09:10:04 -0700 (PDT) Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 6EA4C648E; Wed, 12 Sep 2012 16:10:03 +0000 (UTC) From: "Paul C. Bryan" To: James M Snell In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> Content-Type: multipart/alternative; boundary="=-Go7EPL87m9nvmwQimrDj" Date: Wed, 12 Sep 2012 09:10:01 -0700 Message-ID: <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 16:10:05 -0000 --=-Go7EPL87m9nvmwQimrDj Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I currently imagine a "container" JSON-Test document, which would contain a number of conditional expressions as well as the patch document to apply if such tests prove true. I would wholeheartedly support such an initiative, especially if it resulted in keeping JSON-Patch simple. :-) Paul On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote: > The more I look through this, the more I'm generally inclined to > agree. As was discussed in the separate thread I brought up about > extending json-patch, it is possible to define a super-set of > json-patch that introduces a range of potentially very useful > predicate operations that follow the same fundamental design as > json-patch. Done properly, the two can be layered in interesting ways. > "test" can easily fit into the separate specification, allowing > json-patch to focus specifically on defining the change operations. > > > > - James > > > On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley wrote: > > As long as there is a "test" operation, people are going to > want to extend it into something that matches complex > conditionals that exist in the base languages. I'm not > convinced of the value in the operation as it exists. I'm > concerned about what it would become as well, to fit people's > real needs needs. > > > My initial reaction was that I would use this operation to > test a 'version' field within the data at the top level. This > way sequential patching could indicate if a patch > is sufficient to bring an object to a certain state. But > really in describing the patch, we are already making the > assumption that we are applying it to the right json later. Or > something 'right' enough. > > Conditional matching/logic is something worthy of a spec, but > I'm not convinced this is that specification. > > > How are people using the test operation in practice now? I'm > assuming only non-structured matching is recommended... or is > deep comparison of structured types suggested? > > Would this not be better handled outside of the work > description itself? > > > -- > Matt (MPCM) > > > On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan > wrote: > > On Mon, 2012-09-10 at 11:46 -0700, James M Snell > wrote: > > > > On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan > > wrote: > > > > Unfortunately, null is a testable value and > > should not be interpreted to mean lack of > > value > > > > > > Indeed, but I'd argue that the two cases are > > semantically equivalent enough for the such > > differences to be irrelevant. Particularly since > > many (if not most) json vocabularies tend to treat > > null and undefined as being equivalent. > > > > > While there are some languages that do not make this > distinction, I must disagree with your conclusion that > it is irrelevant. In JavaScript, null != undefined. > The JSON specification went out of its way to define > an explicit null value. I do not want to create > ambiguities in the test operation, nor do I want to > create incompatibilities with different > implementations where the treatment of null may be > concerned. > > > > > > There is a clear use case for this and we can bind > > the scope simply by saying that, within json patch, > > undefined and null are equivalent. > > > > > And what is the clear use case for this? > > Paul > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > > > --=-Go7EPL87m9nvmwQimrDj Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit I currently imagine a "container" JSON-Test document, which would contain a number of conditional expressions as well as the patch document to apply if such tests prove true. I would wholeheartedly support such an initiative, especially if it resulted in keeping JSON-Patch simple. :-)

Paul

On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote:
The more I look through this, the more I'm generally inclined to agree. As was discussed in the separate thread I brought up about extending json-patch, it is possible to define a super-set of json-patch that introduces a range of potentially very useful predicate operations that follow the same fundamental design as json-patch. Done properly, the two can be layered in interesting ways. "test" can easily fit into the separate specification, allowing json-patch to focus specifically on defining the change operations. 


- James

On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley <matt@mpcm.com> wrote:
As long as there is a "test" operation, people are going to want to extend it into something that matches complex conditionals that exist in the base languages. I'm not convinced of the value in the operation as it exists. I'm concerned about what it would become as well, to fit people's real needs needs.

My initial reaction was that I would use this operation to test a 'version' field within the data at the top level. This way sequential patching could indicate if a patch is sufficient to bring an object to a certain state. But really in describing the patch, we are already making the assumption that we are applying it to the right json later. Or something 'right' enough.

Conditional matching/logic is something worthy of a spec, but I'm not convinced this is that specification.


How are people using the test operation in practice now? I'm assuming only non-structured matching is recommended... or is deep comparison of structured types suggested?

Would this not be better handled outside of the work description itself?


-- 
Matt (MPCM)

On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan <pbryan@anode.ca> wrote:

On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote:

On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
Unfortunately, null is a testable value and should not be interpreted to mean lack of value

Indeed, but I'd argue that the two cases are semantically equivalent enough for the such differences to be irrelevant. Particularly since many (if not most) json vocabularies tend to treat null and undefined as being equivalent.


While there are some languages that do not make this distinction, I must disagree with your conclusion that it is irrelevant. In JavaScript, null != undefined. The JSON specification went out of its way to define an explicit null value. I do not want to create ambiguities in the test operation, nor do I want to create incompatibilities with different implementations where the treatment of null may be concerned.


There is a clear use case for this and we can bind the scope simply by saying that, within json patch, undefined and null are equivalent.


And what is the clear use case for this?

Paul



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss







--=-Go7EPL87m9nvmwQimrDj-- From jasnell@gmail.com Wed Sep 12 09:12:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6542D21F84EA for ; Wed, 12 Sep 2012 09:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWGM04QxErLi for ; Wed, 12 Sep 2012 09:12:34 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5C78B21F84DE for ; Wed, 12 Sep 2012 09:12:34 -0700 (PDT) Received: by wibhm2 with SMTP id hm2so2099089wib.16 for ; Wed, 12 Sep 2012 09:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hfwiagSR90KX82IHe5+v+YSEqNgN4RPijtkqkkR7/e0=; b=loKlbEJLcWGtStPAsbBm1zGDwrzZyf4zBWYm/nwBm9B/pyvkOB6EFN9K9gcHojhFdi MaDxmkqVn6nziZLaeph7fW5RJCN6Ta/JhbXs5JRTyce/lZMiDzAGsJ7ozQ7Arjvr2HDt n+/kULDAWHnh3pKUbN3ZDu45P2pdbmQYEVycw3P5J0YSvPr5nZZYL8hs/4oAwN+zGDKm oWTreGhgqBECPllfBBsDmEn7OFvDjKxKY3OttLl7pQc10leOQXswAKJimWHH4enx2luU zaU2YqXt0+KNbaE+un0DW20CT/orgMUldv/78XUM9hmJgRBQgkFgH9On0zdcWOiWJwVb vyrA== Received: by 10.217.1.79 with SMTP id m57mr11799422wes.121.1347466353236; Wed, 12 Sep 2012 09:12:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.96.2 with HTTP; Wed, 12 Sep 2012 09:12:12 -0700 (PDT) In-Reply-To: <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> From: James M Snell Date: Wed, 12 Sep 2012 09:12:12 -0700 Message-ID: To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=20cf302077dc54d95604c98375ae Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 16:12:36 -0000 --20cf302077dc54d95604c98375ae Content-Type: text/plain; charset=UTF-8 Precisely. I've actually already began sketching up a rough and will.. hopefully.. have the chance to prototype some code for it this weekend to prove out the idea. On Wed, Sep 12, 2012 at 9:10 AM, Paul C. Bryan wrote: > ** > I currently imagine a "container" JSON-Test document, which would contain > a number of conditional expressions as well as the patch document to apply > if such tests prove true. I would wholeheartedly support such an > initiative, especially if it resulted in keeping JSON-Patch simple. :-) > > Paul > > > On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote: > > The more I look through this, the more I'm generally inclined to agree. As > was discussed in the separate thread I brought up about extending > json-patch, it is possible to define a super-set of json-patch that > introduces a range of potentially very useful predicate operations that > follow the same fundamental design as json-patch. Done properly, the two > can be layered in interesting ways. "test" can easily fit into the separate > specification, allowing json-patch to focus specifically on defining the > change operations. > > > > - James > > On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley wrote: > > As long as there is a "test" operation, people are going to want to extend > it into something that matches complex conditionals that exist in the base > languages. I'm not convinced of the value in the operation as it exists. > I'm concerned about what it would become as well, to fit people's real > needs needs. > > > My initial reaction was that I would use this operation to test a > 'version' field within the data at the top level. This way sequential > patching could indicate if a patch is sufficient to bring an object to a > certain state. But really in describing the patch, we are already making > the assumption that we are applying it to the right json later. Or > something 'right' enough. > > > Conditional matching/logic is something worthy of a spec, but I'm not > convinced this is that specification. > > > > How are people using the test operation in practice now? I'm assuming > only non-structured matching is recommended... or is deep comparison of > structured types suggested? > > Would this not be better handled outside of the work description itself? > > > > -- > Matt (MPCM) > > On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan wrote: > > On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote: > > On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan wrote: > > Unfortunately, null is a testable value and should not be interpreted to > mean lack of value > > > Indeed, but I'd argue that the two cases are semantically equivalent > enough for the such differences to be irrelevant. Particularly since many > (if not most) json vocabularies tend to treat null and undefined as being > equivalent. > > > > While there are some languages that do not make this distinction, I > must disagree with your conclusion that it is irrelevant. In JavaScript, > null != undefined. The JSON specification went out of its way to define an > explicit null value. I do not want to create ambiguities in the test > operation, nor do I want to create incompatibilities with different > implementations where the treatment of null may be concerned. > > > > There is a clear use case for this and we can bind the scope simply by > saying that, within json patch, undefined and null are equivalent. > > > > And what is the clear use case for this? > > Paul > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > > > --20cf302077dc54d95604c98375ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precisely. I've actually already b= egan sketching up a rough and will.. hopefully.. have the chance to prototy= pe some code for it this weekend to prove out the idea.

On Wed, Sep 12, 2012 at 9:10 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
=20 =20
I currently imagine a "container" JSON-Test document, which would= contain a number of conditional expressions as well as the patch document = to apply if such tests prove true. I would wholeheartedly support such an i= nitiative, especially if it resulted in keeping JSON-Patch simple. :-)

Paul


On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote:
The more I look through this, the more I'm generally inclined to ag= ree. As was discussed in the separate thread I brought up about extending j= son-patch, it is possible to define a super-set of json-patch that introduc= es a range of potentially very useful predicate operations that follow the = same fundamental design as json-patch. Done properly, the two can be layere= d in interesting ways. "test" can easily fit into the separate sp= ecification, allowing json-patch to focus specifically on defining the chan= ge operations.=C2=A0


- James

On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley <matt@mpcm.com> wrote:
As long as there is a "test" operation, people are going = to want to extend it into something that matches complex conditionals that = exist in the base languages. I'm not convinced of the value in the oper= ation as it exists. I'm concerned about what it would become as well, t= o fit people's real needs needs.

My initial reaction was that I would use this operation to test a &= #39;version' field within the data at the top level. This way sequentia= l patching could indicate if a patch is=C2=A0sufficient=C2=A0to bring an ob= ject to a certain state. But really in describing the patch, we are already= making the assumption that we are applying it to the right json later. Or = something 'right' enough.

Conditional matching/logic is something worthy of a spec, but I'= ;m not convinced this is that specification.


How are people using the test operation in practice now? I'm as= suming only non-structured matching is recommended... or is deep comparison= of structured types suggested?

Would this not be better handled outside of the work description it= self?


--=C2=A0
Matt (MPCM)

On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan <pbryan@anode.ca> wrote:

On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote:

On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan <pbryan@anode.ca> wrote= :
Unfortunately, null is a testable value and should not = be interpreted to mean lack of value

Indeed, but I'd argue that the two cases are semantical= ly equivalent enough for the such differences to be irrelevant. Particularl= y since many (if not most) json vocabularies tend to treat null and undefin= ed as being equivalent.


While there are some languages that do not make this distinctio= n, I must disagree with your conclusion that it is irrelevant. In JavaScrip= t, null !=3D undefined. The JSON specification went out of its way to defin= e an explicit null value. I do not want to create ambiguities in the test o= peration, nor do I want to create incompatibilities with different implemen= tations where the treatment of null may be concerned.


There is a clear use case for this and we can bind the scop= e simply by saying that, within json patch, undefined and null are equivale= nt.


And what is the clear use case for this?

Paul



_______________________________________________
apps-discuss mailing list
apps= -discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss







--20cf302077dc54d95604c98375ae-- From pbryan@anode.ca Wed Sep 12 09:15:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AB821F862B for ; Wed, 12 Sep 2012 09:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fmPUGcZei4E for ; Wed, 12 Sep 2012 09:15:44 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id D7E2321F8661 for ; Wed, 12 Sep 2012 09:15:43 -0700 (PDT) Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id BF69E648E; Wed, 12 Sep 2012 16:15:42 +0000 (UTC) From: "Paul C. Bryan" To: James M Snell In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> Content-Type: multipart/alternative; boundary="=-z/76dJzmcPSTujgTYqO6" Date: Wed, 12 Sep 2012 09:15:41 -0700 Message-ID: <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 16:15:44 -0000 --=-z/76dJzmcPSTujgTYqO6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit +1! On Wed, 2012-09-12 at 09:12 -0700, James M Snell wrote: > Precisely. I've actually already began sketching up a rough and will.. > hopefully.. have the chance to prototype some code for it this weekend > to prove out the idea. > > > On Wed, Sep 12, 2012 at 9:10 AM, Paul C. Bryan > wrote: > > I currently imagine a "container" JSON-Test document, which > would contain a number of conditional expressions as well as > the patch document to apply if such tests prove true. I would > wholeheartedly support such an initiative, especially if it > resulted in keeping JSON-Patch simple. :-) > > Paul > > > > On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote: > > > The more I look through this, the more I'm generally > > inclined to agree. As was discussed in the separate thread I > > brought up about extending json-patch, it is possible to > > define a super-set of json-patch that introduces a range of > > potentially very useful predicate operations that follow the > > same fundamental design as json-patch. Done properly, the > > two can be layered in interesting ways. "test" can easily > > fit into the separate specification, allowing json-patch to > > focus specifically on defining the change operations. > > > > > > - James > > > > On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley > > wrote: > > > > As long as there is a "test" operation, people are > > going to want to extend it into something that > > matches complex conditionals that exist in the base > > languages. I'm not convinced of the value in the > > operation as it exists. I'm concerned about what it > > would become as well, to fit people's real needs > > needs. > > > > My initial reaction was that I would use this > > operation to test a 'version' field within the data > > at the top level. This way sequential patching could > > indicate if a patch is sufficient to bring an object > > to a certain state. But really in describing the > > patch, we are already making the assumption that we > > are applying it to the right json later. Or > > something 'right' enough. > > > > Conditional matching/logic is something worthy of a > > spec, but I'm not convinced this is that > > specification. > > > > > > How are people using the test operation in practice > > now? I'm assuming only non-structured matching is > > recommended... or is deep comparison of structured > > types suggested? > > > > Would this not be better handled outside of the work > > description itself? > > > > > > -- > > Matt (MPCM) > > > > On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan > > wrote: > > > > > > On Mon, 2012-09-10 at 11:46 -0700, James M > > Snell wrote: > > > > > > > On Mon, Sep 10, 2012 at 10:34 AM, Paul C. > > > Bryan wrote: > > > > > > Unfortunately, null is a testable > > > value and should not be > > > interpreted to mean lack of value > > > > > > > > > Indeed, but I'd argue that the two cases > > > are semantically equivalent enough for the > > > such differences to be irrelevant. > > > Particularly since many (if not most) json > > > vocabularies tend to treat null and > > > undefined as being equivalent. > > > > > > > > While there are some languages that do not > > make this distinction, I must disagree with > > your conclusion that it is irrelevant. In > > JavaScript, null != undefined. The JSON > > specification went out of its way to define > > an explicit null value. I do not want to > > create ambiguities in the test operation, > > nor do I want to create incompatibilities > > with different implementations where the > > treatment of null may be concerned. > > > > > > > > > There is a clear use case for this and we > > > can bind the scope simply by saying that, > > > within json patch, undefined and null are > > > equivalent. > > > > > > > > And what is the clear use case for this? > > > > Paul > > > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > > > > > > > > > > > > > > > > --=-z/76dJzmcPSTujgTYqO6 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit +1!

On Wed, 2012-09-12 at 09:12 -0700, James M Snell wrote:
Precisely. I've actually already began sketching up a rough and will.. hopefully.. have the chance to prototype some code for it this weekend to prove out the idea.

On Wed, Sep 12, 2012 at 9:10 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
I currently imagine a "container" JSON-Test document, which would contain a number of conditional expressions as well as the patch document to apply if such tests prove true. I would wholeheartedly support such an initiative, especially if it resulted in keeping JSON-Patch simple. :-)

Paul


On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote:
The more I look through this, the more I'm generally inclined to agree. As was discussed in the separate thread I brought up about extending json-patch, it is possible to define a super-set of json-patch that introduces a range of potentially very useful predicate operations that follow the same fundamental design as json-patch. Done properly, the two can be layered in interesting ways. "test" can easily fit into the separate specification, allowing json-patch to focus specifically on defining the change operations. 


- James

On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley <matt@mpcm.com> wrote:
As long as there is a "test" operation, people are going to want to extend it into something that matches complex conditionals that exist in the base languages. I'm not convinced of the value in the operation as it exists. I'm concerned about what it would become as well, to fit people's real needs needs.

My initial reaction was that I would use this operation to test a 'version' field within the data at the top level. This way sequential patching could indicate if a patch is sufficient to bring an object to a certain state. But really in describing the patch, we are already making the assumption that we are applying it to the right json later. Or something 'right' enough.

Conditional matching/logic is something worthy of a spec, but I'm not convinced this is that specification.


How are people using the test operation in practice now? I'm assuming only non-structured matching is recommended... or is deep comparison of structured types suggested?

Would this not be better handled outside of the work description itself?


-- 
Matt (MPCM)

On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan <pbryan@anode.ca> wrote:

On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote:

On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
Unfortunately, null is a testable value and should not be interpreted to mean lack of value

Indeed, but I'd argue that the two cases are semantically equivalent enough for the such differences to be irrelevant. Particularly since many (if not most) json vocabularies tend to treat null and undefined as being equivalent.


While there are some languages that do not make this distinction, I must disagree with your conclusion that it is irrelevant. In JavaScript, null != undefined. The JSON specification went out of its way to define an explicit null value. I do not want to create ambiguities in the test operation, nor do I want to create incompatibilities with different implementations where the treatment of null may be concerned.


There is a clear use case for this and we can bind the scope simply by saying that, within json patch, undefined and null are equivalent.


And what is the clear use case for this?

Paul



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss










--=-z/76dJzmcPSTujgTYqO6-- From ned.freed@mrochek.com Wed Sep 12 09:41:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F82B21F84FD for ; Wed, 12 Sep 2012 09:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyV9M-DEGEqr for ; Wed, 12 Sep 2012 09:41:20 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 381B021F84EB for ; Wed, 12 Sep 2012 09:41:20 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OK5WMEKIC0008FDI@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 12 Sep 2012 09:36:18 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Wed, 12 Sep 2012 09:36:15 -0700 (PDT) Message-id: <01OK5WMCTO1Q0006TF@mauve.mrochek.com> Date: Wed, 12 Sep 2012 09:31:29 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 12 Sep 2012 11:45:12 +0000" <1CD55F04538DEA4F85F3ADF7745464AF1AE51E2C@S-BSC-MBX1.nrn.nrcan.gc.ca> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120911185920.15727.44587.idtracker@ietfa.amsl.com> <504F8B98.3090002@isode.com> <1CD55F04538DEA4F85F3ADF7745464AF1AE51E2C@S-BSC-MBX1.nrn.nrcan.gc.ca> To: "Rushforth, Peter" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 16:41:21 -0000 > Is it forbidden by structured suffix reg procedures to register stacked suffixes? > e.g. application/foo+bar+xml The syntax allows it, but the meaning is undefined. The rule is that the material after the last plus sign is the suffix. Plus signs before that currently have no special meaning. Since that could change in the future, this is one of those things where it makes sense to push back on such usage in registrations should someone ever try it. Ned > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org > > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Alexey Melnikov > > Sent: September 11, 2012 15:06 > > To: apps-discuss@ietf.org > > Subject: Re: [apps-discuss] I-D Action: > > draft-ietf-appsawg-media-type-suffix-regs-03.txt > > > > On 11/09/2012 19:59, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > This draft is a work item of the Applications Area > > Working Group Working Group of the IETF. > > > > > > Title : Additional Media Type Structured > > Syntax Suffixes > > > Author(s) : Tony Hansen > > > Alexey Melnikov > > > Filename : > > draft-ietf-appsawg-media-type-suffix-regs-03.txt > > > Pages : 14 > > > Date : 2012-09-11 > > > > > > Abstract: > > > A content media type name sometimes includes partitioned meta- > > > information distinguish by a Structured Syntax, to > > permit noting an > > > attribute of the media as a suffix to the name. This document > > > defines several Structured Syntax Suffixes for use with > > media type > > > registrations. In particular, it defines and registers > > the "+json", > > > "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" > > Structured Syntax > > > Suffixes, and updates the "+xml" Message Type Structured Syntax > > > Suffix registration. > > > > This version addresses the following issues: > > > > 1) make the text about fragment identifiers for +ber/+der > > consistent with the rest of registrations (some minor textual > > differences, as there is no generic application/ber media > > type registered) > > > > 2) added a warning that updates to generic fragment > > identifier handling rules can break existing specific media > > type registrations. > > > > I didn't feel there was enough support for reversing the > > fragment identifier rules to make media type specific rules > > override generic > > +suffix rules, so I didn't do this change. > > > > I believe this addresses all outstanding issues I know of. > > > > Please have a quick look and let submit this document to IESG. > > > > Best Regards, > > Alexey > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From superuser@gmail.com Wed Sep 12 09:50:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B65021F866B for ; Wed, 12 Sep 2012 09:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHqyZMymvJf7 for ; Wed, 12 Sep 2012 09:50:46 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A29621F865F for ; Wed, 12 Sep 2012 09:50:46 -0700 (PDT) Received: by lbky2 with SMTP id y2so1418759lbk.31 for ; Wed, 12 Sep 2012 09:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S36dNToFOsdcZjN8bNlITLvI76ylUXifz6TAfQ9lM3U=; b=HtahCWb8MHdz2UJgfaPkIQkoyZRFfgyI9RL9dZYB/Hq0mukQ4sT0kuT5KMZ3Y3hHI+ X97n/TltjNtba1jgKMZVDSthb23oBdQHW26WhDQlQxAQTR0k/PJuFQIYnpspKaax1Izx hnCeK8Q8bfDrNuZtzNulG6RfMWeLGAA7PVB4yXqaSdbShBFfEP+ch1uhctAxF+8I/4aC e6k74uMggM27hrX0kINSR5bfjr771nds2BuMTbHydSpMdOPUhhzddykSBa8hVNeNwBgx nNX/eVzgKKys2p/DAJwYoobvxh4G5qv3/WI6UdYTxYJ4LHpwH8q1Lt7t7KNAnEPgsYt2 0kaQ== MIME-Version: 1.0 Received: by 10.112.31.233 with SMTP id d9mr7712404lbi.116.1347468645318; Wed, 12 Sep 2012 09:50:45 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Wed, 12 Sep 2012 09:50:45 -0700 (PDT) In-Reply-To: <01OK5WMCTO1Q0006TF@mauve.mrochek.com> References: <20120911185920.15727.44587.idtracker@ietfa.amsl.com> <504F8B98.3090002@isode.com> <1CD55F04538DEA4F85F3ADF7745464AF1AE51E2C@S-BSC-MBX1.nrn.nrcan.gc.ca> <01OK5WMCTO1Q0006TF@mauve.mrochek.com> Date: Wed, 12 Sep 2012 09:50:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 16:50:47 -0000 On Wed, Sep 12, 2012 at 9:31 AM, Ned Freed wrote: >> Is it forbidden by structured suffix reg procedures to register stacked suffixes? >> e.g. application/foo+bar+xml > > The syntax allows it, but the meaning is undefined. The rule is that the > material after the last plus sign is the suffix. Plus signs before that > currently have no special meaning. Since that could change in the future, > this is one of those things where it makes sense to push back on such > usage in registrations should someone ever try it. Would you say this constitutes advice for the Designated Expert that should be added to the draft? -MSK From ned.freed@mrochek.com Wed Sep 12 14:23:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3CF21F8569 for ; Wed, 12 Sep 2012 14:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVO5sIB-xPAv for ; Wed, 12 Sep 2012 14:23:08 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id EF0D621F8554 for ; Wed, 12 Sep 2012 14:23:07 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OK66GRDBTC007Y61@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 12 Sep 2012 14:18:05 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Wed, 12 Sep 2012 14:18:02 -0700 (PDT) Message-id: <01OK66GPDDRO0006TF@mauve.mrochek.com> Date: Wed, 12 Sep 2012 14:02:16 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 12 Sep 2012 09:50:45 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120911185920.15727.44587.idtracker@ietfa.amsl.com> <504F8B98.3090002@isode.com> <1CD55F04538DEA4F85F3ADF7745464AF1AE51E2C@S-BSC-MBX1.nrn.nrcan.gc.ca> <01OK5WMCTO1Q0006TF@mauve.mrochek.com> To: "Murray S. Kucherawy" Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 21:23:08 -0000 > On Wed, Sep 12, 2012 at 9:31 AM, Ned Freed wrote: > >> Is it forbidden by structured suffix reg procedures to register stacked suffixes? > >> e.g. application/foo+bar+xml > > > > The syntax allows it, but the meaning is undefined. The rule is that the > > material after the last plus sign is the suffix. Plus signs before that > > currently have no special meaning. Since that could change in the future, > > this is one of those things where it makes sense to push back on such > > usage in registrations should someone ever try it. > Would you say this constitutes advice for the Designated Expert that > should be added to the draft? No. The rule for what pluses mean (and don't mean) is already there. The fact that things change over time is, among other things, implicit in the process itself. It is just common sense that multiple plus signs in a name are risky. Moreover, if you start down that path, there are dozens if not hundreds of similar common sense considerations for media types that deserve equal if not greater consideration in these documents Should we have a warning about overly long (or short) type names? How about a name containing a pointless & intended primarily for use in an XML context? How about something like $A$B$C$D? (And yes, several of these sorts of things have been proposed, and saying "that may not be the greatest idea" has kept all of them out of the registry.) And that's just names. How about the assessment of whether or not something qualifies as a type at all, or as a suffix? I bet we could write a dozen pages on that topic alone, but even assuming we could get consensus, the chances of that text actually being helpful are low. Finally, I'll again point out that this is a registry seeding document. Name selection advice has no business being here. Ned From likepeng@huawei.com Wed Sep 12 17:38:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A82821F8624 for ; Wed, 12 Sep 2012 17:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.025 X-Spam-Level: X-Spam-Status: No, score=0.025 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdftz1bYmq9V for ; Wed, 12 Sep 2012 17:38:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 072EE21F8616 for ; Wed, 12 Sep 2012 17:38:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJP62776; Thu, 13 Sep 2012 00:38:50 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Sep 2012 01:38:37 +0100 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Sep 2012 01:38:48 +0100 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.168]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Thu, 13 Sep 2012 08:38:42 +0800 From: Likepeng To: Goix Laurent Walter , "apps-discuss@ietf.org" Thread-Topic: New version of I-D for ENUM service for acct URI Thread-Index: Ac2QJOIumroETdorQzmwufjgg+IwoABId/DA Date: Thu, 13 Sep 2012 00:38:41 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F21ED43779@szxeml525-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.124] Content-Type: multipart/related; boundary="_004_34966E97BE8AD64EAE9D3D6E4DEE36F21ED43779szxeml525mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [apps-discuss] New version of I-D for ENUM service for acct URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 00:38:59 -0000 --_004_34966E97BE8AD64EAE9D3D6E4DEE36F21ED43779szxeml525mbxchi_ Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F21ED43779szxeml525mbxchi_" --_000_34966E97BE8AD64EAE9D3D6E4DEE36F21ED43779szxeml525mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SnVzdCB0byBjbGFyaWZ5IHRoYXQgaW4gdGhlIHByZXZpb3VzIGVudW0tc24tc2VydmljZSBkcmFm dCwgaXQgb25seSBmb2N1c2VzIG9uIHNvY2lhbCBuZXR3b3JrIGFjY291bnQuDQoNCk5vdyBpbiB0 aGUgbmV3IGVudW0tYWNjdC11cmkgZHJhZnQsIHdlIGNoYW5nZSB0aGF0IHRvIGFjY3QgdXJpLCBk b26hr3QgbGltaXQgaXQgdG8gc29jaWFsIG5ldHdvcmsgYWNjb3VudC4NCg0KV2UgcmVjZWl2ZWQg bWFueSB2YWx1YWJsZSBvZmZsaW5lIGRpc2N1c3Npb24gY29tbWVudHMgZm9yIHRoZSBwcmV2aW91 cyBkcmFmdCwgaG9wZSB0byBnZXQgZmVlZGJhY2sgdG8gdGhlIG5ldyBkcmFmdC4NCg0KVGhhbmtz LA0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQq3orz+yMs6IEdvaXggTGF1cmVudCBXYWx0ZXIg W21haWx0bzpsYXVyZW50d2FsdGVyLmdvaXhAdGVsZWNvbWl0YWxpYS5pdF0NCreiy83KsbzkOiAy MDEyxOo51MIxMcjVIDIxOjU0DQrK1bz+yMs6IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0Ks63LzTog TGlrZXBlbmcNCtb3zOI6IE5ldyB2ZXJzaW9uIG9mIEktRCBmb3IgRU5VTSBzZXJ2aWNlIGZvciBh Y2N0IFVSSQ0KDQpEZWFyIGFsbCwNCg0KSSBqdXN0IHVwbG9hZGVkIHRoaXMgZHJhZnQgWzFdIGFz IGEgcmV2aXNpb24gb2YgZm9ybWVyIGRyYWZ0LWdvaXgtYXBwc2F3Zy1lbnVtLXNuLXNlcnZpY2Ut MDIgYmFzZWQgb24gdGhlIGRpc2N1c3Npb24gaGVsZCBpbiBWYW5jb3V2ZXIuDQoNCkluIHBhcnRp Y3VsYXIgdGhlIHRleHQgd2FzIGdlbmVyYWxpemVkIGFuZCBhIHVzZSBjYXNlcyBzZWN0aW9uIHdh cyBhZGRlZCB0byBjbGFyaWZ5IHRoZSBwcm9ibGVtIHRvIGJlIHNvbHZlZCBhcyByZXF1ZXN0ZWQg YnkgRGF2ZS4NCldlIGFsc28gZXhwYW5kZWQgdGhlIHNlY3VyaXR5IHNlY3Rpb24gdG8gY2xhcmlm eSBwb3RlbnRpYWwgcHJpdmFjeSBpc3N1ZXMgYXMgcmVxdWVzdGVkIGJ5IFRlZCBhbmQgSGFubmVz LCBmdXJ0aGVyIGNsYXJpZnlpbmcgd2h5IGluc2VydGluZyBsaW5rIHJlbCBlbmRwb2ludCBkaXJl Y3RseSBpbiBFTlVNIGl0c2VsZiBhcmUgbm90IGFwcHJvcHJpYXRlLiBUaGUgZXhhbXBsZSB3YXMg c2xpZ2h0bHkgcmV2aXNlZCBhcyB3ZWxsLg0KDQpGaW5hbGx5LCBvbiB3aGV0aGVyIFJBSSBvciBB UFBTIHNob3VsZCBoYW5kbGUgdGhpcyBkcmFmdCwgdGhlIGF1dGhvcnMgc3BvbnNvciBBUFBTLCBh bmQgaW4gcGFydGljdWxhciBBUFBTQVdHLCB3aGljaCBhbHJlYWR5IGhhbmRsZXMgdGhlIHdlYmZp bmdlciBhbmQgYWNjdCB1cmkgZHJhZnRzIGFuZCB0aGUgcmVsYXRlZCBleHBlcnRzLiBFbnVtIGV4 cGVydHMgYWxyZWFkeSBwZXJmb3JtZWQgYSBzYW5pdHkgY2hlY2sgb24gcHJldmlvdXMgdmVyc2lv bnMgb2YgdGhpcyBkcmFmdC4NCg0KV2Ugd2VsY29tZSB5b3VyIGZlZWRiYWNrIG9uIHRoaXMgcmV2 aXNpb24uDQpXYWx0ZXINCg0KWzFdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdv aXgtYXBwc2F3Zy1lbnVtLWFjY3QtdXJpLTAwDQoNCg0KUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3Vv aSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBp bmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lIGRl cml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdv cm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1l bnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRp YXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRp c3RydXppb25lLCBHcmF6aWUuDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMg Y29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVu ZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHBy aW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBh bmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWls LCBUaGFua3MuDQpbcmlzcGV0dGEgbCdhbWJpZW50ZV1SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24g c3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIKioIG5lY2Vzc2FyaW8uDQoNCg0K --_000_34966E97BE8AD64EAE9D3D6E4DEE36F21ED43779szxeml525mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Just to clarify that in the previous enum-sn-service draft, it on= ly focuses on social network account.

 

Now in the new enum-acct-uri draft, we change that to acct uri, d= on=A1=AFt limit it to social network account.

 

We received many valuable offline discussion comments for the pre= vious draft, hope to get feedback to the new draft.  

 

Thanks,

 

Kind Regards

Kepeng

 

=B7=A2=BC=FE=C8=CB: Goix La= urent Walter [mailto:laurentwalter.goix@telecomitalia.it]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2012=C4=EA9=D4=C211=C8=D5 21:54
=CA=D5=BC=FE=C8=CB: apps-discuss@ietf.org
=B3=AD=CB=CD: Likepeng
=D6=F7=CC=E2: New version of I-D for ENUM service for acct URI=

 

Dear all,

 

I just uploaded this draft [1] = as a revision of former draft-goix-appsawg-enum-sn-service-02 based on the = discussion held in Vancouver.

 

In particular the text was gene= ralized and a use cases section was added to clarify the problem to be solv= ed as requested by Dave.

We also expanded the security s= ection to clarify potential privacy issues as requested by Ted and Hannes, = further clarifying why inserting link rel endpoint directly in ENUM itself = are not appropriate. The example was slightly revised as well.

 

Finally, on whether RAI or APPS= should handle this draft, the authors sponsor APPS, and in particular APPS= AWG, which already handles the webfinger and acct uri drafts and the relate= d experts. Enum experts already performed a sanity check on previous versions of this draft.

 

We welcome your feedback on thi= s revision.

Walter=

 =

[1] ht= tp://tools.ietf.org/html/draft-goix-appsawg-enum-acct-uri-00

 =

 

Que= sto messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione deriv= ante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qu= alora abbiate ricevuto questo documento per errore siete cortesemente prega= ti di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any = attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"=Rispetta l'ambiente. Non stampare questa mail se non =A8=A8 necessario.<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Verdana"= ;,"sans-serif";color:black">

 

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F21ED43779szxeml525mbxchi_-- --_004_34966E97BE8AD64EAE9D3D6E4DEE36F21ED43779szxeml525mbxchi_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=677; creation-date="Thu, 13 Sep 2012 00:38:41 GMT"; modification-date="Thu, 13 Sep 2012 00:38:41 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_004_34966E97BE8AD64EAE9D3D6E4DEE36F21ED43779szxeml525mbxchi_-- From mnot@mnot.net Wed Sep 12 21:05:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9977121F84EF for ; Wed, 12 Sep 2012 21:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.993 X-Spam-Level: X-Spam-Status: No, score=-102.993 tagged_above=-999 required=5 tests=[AWL=-0.994, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lphcFCwvVA2B for ; Wed, 12 Sep 2012 21:05:22 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id E9DA421F84EE for ; Wed, 12 Sep 2012 21:05:21 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 03CDD22E257; Thu, 13 Sep 2012 00:05:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: <1347212160.14957.12.camel@polyjuice> Date: Thu, 13 Sep 2012 14:05:11 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <17E89E4A-36E1-467B-9736-BEC80201816D@mnot.net> References: <1347212160.14957.12.camel@polyjuice> To: Paul C. Bryan X-Mailer: Apple Mail (2.1486) Cc: Apps Discuss Subject: Re: [apps-discuss] A couple more PATCH issues X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 04:05:22 -0000 OK.=20 It seems to me that we don't need any changes to the document for these, = then. Cheers, On 10/09/2012, at 3:36 AM, Paul C. Bryan wrote: > On Sat, 2012-09-08 at 13:42 +1000, Mark Nottingham wrote: >=20 >> 1) Thomas Koch asked how a resource know which representation the = patch is intended for, against, if there are multiple representations of = a resource? His example was a case where there's a portable contacts = JSON format as well as a future vcard+json format available at the same = URI. >=20 > IMO, this is a problem that HTTP PATCH has in general, and whatever = solution should address that specification. >=20 >> I can see a few different approaches to this; e..g, >>=20 >> a) letting the resource figure it out >=20 > Seems valid. If the server can unambiguously determine which = representation to modify (e.g. because there is only one) then there is = no issue.=20 >=20 >> b) using If-Match to convey the ETag of the appropriate = representation >=20 > Also seems valid. Presumably if there are multiple representations of = the resource, the server has to compare the ETag to all of them to = determine whether one matches. If it does this, it's certainly = unambiguous which representation to modify. >=20 >> c) adding a field in the format identifying the media type of the = representation that the patch is intended for >=20 > If you mean a header field, then this also seems valid. I'd suggest = though that such a solution should be addressing HTTP PATCH. >=20 >> 2) Markus Lanthaler asked why we don't use a +json media type. Way = back when, I advised Paul to use json-patch, because +json wasn't = formalised yet, and I had some philosophical issues with it (still do, = but whatever). >>=20 >> What's the state of that now? Can we start minting +json formats? = What's the process for establishing one of these? Is anyone working on a = +json template in a draft (as per = )? >=20 > +json makes sense to me when there are multiple representations of = something. Since this is very much focused on JSON document structures, = I believe it would be better to keep it as json-patch. >=20 > Paul -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Wed Sep 12 21:06:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3900F21F84F2 for ; Wed, 12 Sep 2012 21:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.234 X-Spam-Level: X-Spam-Status: No, score=-103.234 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixHw+9F-Sz+u for ; Wed, 12 Sep 2012 21:06:34 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id F310E21F84EE for ; Wed, 12 Sep 2012 21:06:33 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EA99E22DD6D; Thu, 13 Sep 2012 00:06:26 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> Date: Thu, 13 Sep 2012 14:06:23 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> To: Paul C. Bryan X-Mailer: Apple Mail (2.1486) Cc: Apps Discuss Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 04:06:35 -0000 So, what does this mean for the document? Should we remove the 'test' = operation (which may create further controversy), or leave it in = (assuming it will be extended / supplanted if someone designs a = 'wrapper')? Regards, On 13/09/2012, at 2:15 AM, Paul C. Bryan wrote: > +1! >=20 > On Wed, 2012-09-12 at 09:12 -0700, James M Snell wrote: >> Precisely. I've actually already began sketching up a rough and = will.. hopefully.. have the chance to prototype some code for it this = weekend to prove out the idea. >>=20 >> On Wed, Sep 12, 2012 at 9:10 AM, Paul C. Bryan = wrote: >> I currently imagine a "container" JSON-Test document, which would = contain a number of conditional expressions as well as the patch = document to apply if such tests prove true. I would wholeheartedly = support such an initiative, especially if it resulted in keeping = JSON-Patch simple. :-) >>=20 >> Paul >>=20 >>=20 >> On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote: >>> The more I look through this, the more I'm generally inclined to = agree. As was discussed in the separate thread I brought up about = extending json-patch, it is possible to define a super-set of json-patch = that introduces a range of potentially very useful predicate operations = that follow the same fundamental design as json-patch. Done properly, = the two can be layered in interesting ways. "test" can easily fit into = the separate specification, allowing json-patch to focus specifically on = defining the change operations.=20 >>>=20 >>>=20 >>> - James >>>=20 >>> On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley = wrote: >>> As long as there is a "test" operation, people are going to want to = extend it into something that matches complex conditionals that exist in = the base languages. I'm not convinced of the value in the operation as = it exists. I'm concerned about what it would become as well, to fit = people's real needs needs.=20 >>>=20 >>> My initial reaction was that I would use this operation to test a = 'version' field within the data at the top level. This way sequential = patching could indicate if a patch is sufficient to bring an object to a = certain state. But really in describing the patch, we are already making = the assumption that we are applying it to the right json later. Or = something 'right' enough.=20 >>>=20 >>> Conditional matching/logic is something worthy of a spec, but I'm = not convinced this is that specification.=20 >>>=20 >>>=20 >>> How are people using the test operation in practice now? I'm = assuming only non-structured matching is recommended... or is deep = comparison of structured types suggested? >>>=20 >>> Would this not be better handled outside of the work description = itself?=20 >>>=20 >>>=20 >>> --=20 >>> Matt (MPCM) >>>=20 >>> On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan = wrote: >>>=20 >>> On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote: >>>=20 >>>> On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan = wrote: >>>> Unfortunately, null is a testable value and should not be = interpreted to mean lack of value >>>>=20 >>>> Indeed, but I'd argue that the two cases are semantically = equivalent enough for the such differences to be irrelevant. = Particularly since many (if not most) json vocabularies tend to treat = null and undefined as being equivalent. >>>=20 >>>=20 >>> While there are some languages that do not make this distinction, I = must disagree with your conclusion that it is irrelevant. In JavaScript, = null !=3D undefined. The JSON specification went out of its way to = define an explicit null value. I do not want to create ambiguities in = the test operation, nor do I want to create incompatibilities with = different implementations where the treatment of null may be concerned.=20= >>>=20 >>>=20 >>>> There is a clear use case for this and we can bind the scope simply = by saying that, within json patch, undefined and null are equivalent. >>>=20 >>>=20 >>> And what is the clear use case for this? >>>=20 >>> Paul=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From mmorley@mpcm.com Thu Sep 13 05:11:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720B121F8574 for ; Thu, 13 Sep 2012 05:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5XRZc1YIqrI for ; Thu, 13 Sep 2012 05:10:59 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2F03E21F8568 for ; Thu, 13 Sep 2012 05:10:58 -0700 (PDT) Received: by qafk1 with SMTP id k1so3010312qaf.1 for ; Thu, 13 Sep 2012 05:10:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=c2+hvp2Xt7Q1080KVsSixe6oIZB4sGEmULTT8TBr+Vw=; b=PgHqt3vdhztBfW7HU+fzN/G/whSVkoBfa2JmlXcUiZMrXP4IvgEfdPNhTvxjbr3qqN EPt/lyX9DMaetXIntEawpPrTLa04I+rkx7XP63vXQO9SlJ2YDCi2XBpRlKPOv2VsyKaL k+QNOmt8kXWjVIBidK+1Iujfqlx3c58CUoq3H+lXlDG0sofMCzYL9WLCGBYp5GHkUNz6 a3LXssyZIZrl1p/zYGuwyfqNwTg2kcXIdHJ1nGKh/3WuCSOkoTYZTQkjyQCLzo9/hcaK kXupGZymUasWCkK9X6X68j4aS6tRyDtGNMqUS/alFqnska58vqfHVuVjfbGS+QXoRL+g Rxig== MIME-Version: 1.0 Received: by 10.224.138.143 with SMTP id a15mr5158661qau.64.1347538258198; Thu, 13 Sep 2012 05:10:58 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.49.30.66 with HTTP; Thu, 13 Sep 2012 05:10:58 -0700 (PDT) In-Reply-To: <1347413811.4006.3.camel@polyjuice> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347413811.4006.3.camel@polyjuice> Date: Thu, 13 Sep 2012 08:10:58 -0400 X-Google-Sender-Auth: MQ-FlRQ-pXw5Ac2veR31q1B623A Message-ID: From: Matthew Morley To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=20cf3074d77c33815204c9943304 X-Gm-Message-State: ALoCoQl1H0QuDz4aFuM7b6ToaKX6d+xp9ZM2CoWhAr/JLg4PW9aq2ztBK0rTyokpUAwdkUmNtz85 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 12:11:00 -0000 --20cf3074d77c33815204c9943304 Content-Type: text/plain; charset=ISO-8859-1 I am not using json patch with any real data/situations so far, so it is still conjecture from my part, but based with situations I encountered in real systems in the past. I struggled with a reasonable approach to conditionals in my rule engine, and adopted a functional but incomplete mechanism. With these discussions, I'll forward something over off-list to the people of this thread, which might explain some of my views. We can bring it on list, if you feel it won't distract the conversation/topic. I'm happy to leave test as is, I just see it as a weak point in the specification. But currently the test operation is limited in that it can only: - test that a path exists - AND that it resolves to a single known value - AND that the value is known at the time of the patch creation You can combine multiple test operations within a patch, to create something like a logical (A=1 AND B=2 AND c=3). You can create multiple patches with unique tests to simulate something like (A=1 OR B=2 OR C=3). If you were to test for existence, something like { "test":/foo/bar"} seems to be the clearest to me. Also, currently you cannot perform tests where the data in the json document itself is the point of consideration ( { "test":"/foo/bar", match:"/foo/baz"}. This gets closer to the approach I ended up using, more about paths as relationships within the data. JSON schema does a good job of describing the shape of objects, and there are times when that might be a consideration. Simple shapes can be represented in complex (AND|OR) tests. Most of the situations I am envisioning, which require more complex test operations, are were a patch is generated, but it needs to be selectively applied across a large set of json documents. If you know specifically which documents you need to apply patches to, you can use the test operation pretty well. If you can generate multiple specific patches that also works well. But it is the compound, negative, and relationship tests that are the issues. This may not be how you envision json patch being utilized. But the test operation does not seem to fit into the concept of "a JSON document structure for expressing a sequence of operations to apply to a JSON document". test is much more of a " and when to apply them" concept. 'When to apply them' will require a more complex offering, in my opinion. I don't know currently of a specification that handles this within JSON realm. On Tue, Sep 11, 2012 at 9:36 PM, Paul C. Bryan wrote: > ** > What are people's real needs you're thinking about fitting? It's been said > that there is a concrete use case for extending the functionality of test, > but I've yet to hear anything beyond the theoretical. Without knowing > these, it's all just conjecture to me. > > Paul > > On Tue, 2012-09-11 at 19:59 -0400, Matthew Morley wrote: > > As long as there is a "test" operation, people are going to want to extend > it into something that matches complex conditionals that exist in the base > languages. I'm not convinced of the value in the operation as it exists. > I'm concerned about what it would become as well, to fit people's real > needs needs. > > > My initial reaction was that I would use this operation to test a > 'version' field within the data at the top level. This way sequential > patching could indicate if a patch is sufficient to bring an object to a > certain state. But really in describing the patch, we are already making > the assumption that we are applying it to the right json later. Or > something 'right' enough. > > > Conditional matching/logic is something worthy of a spec, but I'm not > convinced this is that specification. > > > > How are people using the test operation in practice now? I'm assuming > only non-structured matching is recommended... or is deep comparison of > structured types suggested? > > Would this not be better handled outside of the work description itself? > > > > -- > Matt (MPCM) > > On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan wrote: > > On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote: > > On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan wrote: > > Unfortunately, null is a testable value and should not be interpreted to > mean lack of value > > > Indeed, but I'd argue that the two cases are semantically equivalent > enough for the such differences to be irrelevant. Particularly since many > (if not most) json vocabularies tend to treat null and undefined as being > equivalent. > > > > While there are some languages that do not make this distinction, I > must disagree with your conclusion that it is irrelevant. In JavaScript, > null != undefined. The JSON specification went out of its way to define an > explicit null value. I do not want to create ambiguities in the test > operation, nor do I want to create incompatibilities with different > implementations where the treatment of null may be concerned. > > > > There is a clear use case for this and we can bind the scope simply by > saying that, within json patch, undefined and null are equivalent. > > > > And what is the clear use case for this? > > Paul > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > -- Matthew P. C. Morley --20cf3074d77c33815204c9943304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not using json patch with any real data/situations so far, so it is st= ill conjecture from my part, but based with situations I encountered in rea= l systems in the past. I struggled with a reasonable approach to conditiona= ls in my rule engine, and adopted a functional but incomplete mechanism.
With these discussions, I'll forward something over off-list to the= people of this thread, which might explain some of my views. We can bring = it on list, if you feel it won't distract the conversation/topic. I'= ;m happy to leave test as is, I just see it as a weak point in the specific= ation.

But currently the test operation is limited in that it can only:
  • test that a path exists
  • AND that it resolves to a single known= value
  • AND that the value is known at the time of the patch creatio= n
    • You can combine multiple test operations within a patch, to creat= e something like a logical (A=3D1 AND B=3D2 AND c=3D3). You can create mult= iple patches with unique tests to simulate something like (A=3D1 OR B=3D2 O= R C=3D3).

    If you were to test for existence, something like { "test":/f= oo/bar"} seems to be the clearest to me. Also, currently you cannot pe= rform tests where the data in the json document itself is the point of cons= ideration ( { "test":"/foo/bar", match:"/foo/baz&q= uot;}. This gets closer to the approach I ended up using, more about paths = as relationships within the data.

    JSON schema does a good job of describing the shape of objects, an= d there are times when that might be a consideration. Simple shapes can be = represented in complex (AND|OR) tests.=A0

    Most of the sit= uations I am envisioning, which require more complex test operations, are w= ere a patch is generated, but it needs to be selectively applied across a l= arge set of json documents. If you know specifically which documents you ne= ed to apply patches to, you can use the test operation pretty well. If you = can generate multiple specific patches that also works well. But it is the = compound, negative, and relationship tests that are the issues.

    This may not be how you envision json patch being utilized. But the tes= t operation does not seem to fit into the concept of "a JSON document = structure for expressing a sequence of operations to apply to a JSON docume= nt". test is much more of a " and when to apply them" concep= t.

    'When to apply them' will require a more complex offering, in m= y opinion. I don't know currently of a specification that handles this = within JSON realm.



    On Tue, Sep 11, 2012 at 9:36 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
    =20 =20
    What are people's real needs you're thinking about fitting? It'= s been said that there is a concrete use case for extending the functionali= ty of test, but I've yet to hear anything beyond the theoretical. Witho= ut knowing these, it's all just conjecture to me.

    Paul

    On Tue, 2012-09-11 at 19:59 -0400, Matthew Morley wrote:
    As long as there is a "test" operation, people are going to w= ant to extend it into something that matches complex conditionals that exis= t in the base languages. I'm not convinced of the value in the operatio= n as it exists. I'm concerned about what it would become as well, to fi= t people's real needs needs.

    My initial reaction was that I would use this operation to test a '= version' field within the data at the top level. This way sequential pa= tching could indicate if a patch is=A0sufficient=A0to bring an object to a = certain state. But really in describing the patch, we are already making th= e assumption that we are applying it to the right json later. Or something = 'right' enough.

    Conditional matching/logic is something worthy of a spec, but I'm n= ot convinced this is that specification.


    How are people using the test operation in practice now? I'm assumi= ng only non-structured matching is recommended... or is deep comparison of = structured types suggested?

    Would this not be better handled outside of the work description itself= ?


    --=A0
    Matt (MPCM)

    On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
    On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote:

    On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
    Unfortunately, null is a testable value and should not be i= nterpreted to mean lack of value

    Indeed, but I'd argue that the two cases are semantically e= quivalent enough for the such differences to be irrelevant. Particularly si= nce many (if not most) json vocabularies tend to treat null and undefined a= s being equivalent.


    While there are some languages that do not make this distinction, I= must disagree with your conclusion that it is irrelevant. In JavaScript, n= ull !=3D undefined. The JSON specification went out of its way to define an= explicit null value. I do not want to create ambiguities in the test opera= tion, nor do I want to create incompatibilities with different implementati= ons where the treatment of null may be concerned.


    There is a clear use case for this and we can bind the scope si= mply by saying that, within json patch, undefined and null are equivalent.<= br>


    And what is the clear use case for this?

    Paul


    _______________________________________________
    apps-discuss mailing list
    apps-dis= cuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss







    --
    Matthew P. C= . Morley
    --20cf3074d77c33815204c9943304-- From mmorley@mpcm.com Thu Sep 13 05:15:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A407121F8574 for ; Thu, 13 Sep 2012 05:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0n+gagY8MjvI for ; Thu, 13 Sep 2012 05:15:45 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECCC21F8570 for ; Thu, 13 Sep 2012 05:15:45 -0700 (PDT) Received: by qcsu28 with SMTP id u28so2437334qcs.22 for ; Thu, 13 Sep 2012 05:15:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=HGzPknlyM0k2LifiqVO9RBtusMDfydioabgBnRmGERk=; b=TNpP0aK2n7n6jkWI6uOitrfRbgK33CbhPSFcpsWSzktkxyUYV/ioOw3M5a0qN1Zshn 8Z5Gm4Yk0sVy76+RfstDB1xLX8oIb8OJzAzJg6FznZglH6/+V4zOEFs7AOJPNcgkSOMR QSdzIxfhDcdCRzGwLwFYuFa2V/wDLU02j1mxIM8iPSNXk5e0e/nU/t8eqyZoMTKW7+OV olDuUPa4PbWJVOzKDFU4Ifnt2MByYtp5r7alKYUL06crXngmB36QTbuB406RLUSfxAnn FpbVw5xEMvjOzzQj9uDVcdXM50E1AsQkwk0N4OhQDEJiYnAvj2tcsFyJf6SOk2PI+bm2 gNLg== MIME-Version: 1.0 Received: by 10.224.168.83 with SMTP id t19mr5363981qay.8.1347538544881; Thu, 13 Sep 2012 05:15:44 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.49.30.66 with HTTP; Thu, 13 Sep 2012 05:15:44 -0700 (PDT) In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> Date: Thu, 13 Sep 2012 08:15:44 -0400 X-Google-Sender-Auth: irUgZapOjajW1H1G6PEKp9e5Wxg Message-ID: From: Matthew Morley To: James M Snell Content-Type: multipart/alternative; boundary=20cf3074b5ce49eecd04c99444c8 X-Gm-Message-State: ALoCoQmbfcpHBDpo9y9fVw+kwpnuXr1zDt4BV4MlIf6rIkGvHC7eHX5k1ur+REbWxLN8QfOtngTn Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 12:15:46 -0000 --20cf3074b5ce49eecd04c99444c8 Content-Type: text/plain; charset=ISO-8859-1 I'll get some notes together from my prior setup and send them over before the weekend. Might offer some thoughts, or confirm your approaches, or save you from some of the stuff I never found clean solutions for. Parts of my brain are still stuck down some of those rabbit holes... I'm excited to see this actively being discussed. On Wed, Sep 12, 2012 at 12:12 PM, James M Snell wrote: > Precisely. I've actually already began sketching up a rough and will.. > hopefully.. have the chance to prototype some code for it this weekend to > prove out the idea. > > On Wed, Sep 12, 2012 at 9:10 AM, Paul C. Bryan wrote: > >> ** >> I currently imagine a "container" JSON-Test document, which would contain >> a number of conditional expressions as well as the patch document to apply >> if such tests prove true. I would wholeheartedly support such an >> initiative, especially if it resulted in keeping JSON-Patch simple. :-) >> >> Paul >> >> >> On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote: >> >> The more I look through this, the more I'm generally inclined to agree. >> As was discussed in the separate thread I brought up about extending >> json-patch, it is possible to define a super-set of json-patch that >> introduces a range of potentially very useful predicate operations that >> follow the same fundamental design as json-patch. Done properly, the two >> can be layered in interesting ways. "test" can easily fit into the separate >> specification, allowing json-patch to focus specifically on defining the >> change operations. >> >> >> >> - James >> >> On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley wrote: >> >> As long as there is a "test" operation, people are going to want to >> extend it into something that matches complex conditionals that exist in >> the base languages. I'm not convinced of the value in the operation as it >> exists. I'm concerned about what it would become as well, to fit people's >> real needs needs. >> >> >> My initial reaction was that I would use this operation to test a >> 'version' field within the data at the top level. This way sequential >> patching could indicate if a patch is sufficient to bring an object to a >> certain state. But really in describing the patch, we are already making >> the assumption that we are applying it to the right json later. Or >> something 'right' enough. >> >> >> Conditional matching/logic is something worthy of a spec, but I'm not >> convinced this is that specification. >> >> >> >> How are people using the test operation in practice now? I'm assuming >> only non-structured matching is recommended... or is deep comparison of >> structured types suggested? >> >> Would this not be better handled outside of the work description itself? >> >> >> >> -- >> Matt (MPCM) >> >> On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan wrote: >> >> On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote: >> >> On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan wrote: >> >> Unfortunately, null is a testable value and should not be interpreted to >> mean lack of value >> >> >> Indeed, but I'd argue that the two cases are semantically equivalent >> enough for the such differences to be irrelevant. Particularly since many >> (if not most) json vocabularies tend to treat null and undefined as being >> equivalent. >> >> >> >> While there are some languages that do not make this distinction, I >> must disagree with your conclusion that it is irrelevant. In JavaScript, >> null != undefined. The JSON specification went out of its way to define an >> explicit null value. I do not want to create ambiguities in the test >> operation, nor do I want to create incompatibilities with different >> implementations where the treatment of null may be concerned. >> >> >> >> There is a clear use case for this and we can bind the scope simply by >> saying that, within json patch, undefined and null are equivalent. >> >> >> >> And what is the clear use case for this? >> >> Paul >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> >> >> >> >> >> >> > -- Matthew P. C. Morley --20cf3074b5ce49eecd04c99444c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'll get some notes together from my prior setup and send them over bef= ore the weekend. Might offer some thoughts, or confirm your approaches, or = save you from some of the stuff I never found clean solutions for.

    Parts of my brain are still stuck down some of those rabbit holes... I'= m excited to see this actively being discussed.

    On Wed, Sep 12, 2012 at 12:12 PM, James M Snell &l= t;jasnell@gmail.com<= /a>> wrote:
    Precise= ly. I've actually already began sketching up a rough and will.. hopeful= ly.. have the chance to prototype some code for it this weekend to prove ou= t the idea.

    On Wed, Sep 12, 2012 at 9:10 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
    =20 =20
    I currently imagine a "container" JSON-Test document, which would= contain a number of conditional expressions as well as the patch document = to apply if such tests prove true. I would wholeheartedly support such an i= nitiative, especially if it resulted in keeping JSON-Patch simple. :-)

    Paul


    On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote:
    The more I look through this, the more I'm generally inclined to ag= ree. As was discussed in the separate thread I brought up about extending j= son-patch, it is possible to define a super-set of json-patch that introduc= es a range of potentially very useful predicate operations that follow the = same fundamental design as json-patch. Done properly, the two can be layere= d in interesting ways. "test" can easily fit into the separate sp= ecification, allowing json-patch to focus specifically on defining the chan= ge operations.=A0


    - James

    On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley <matt@mpcm.com> wrote:
    As long as there is a "test" operation, people are going = to want to extend it into something that matches complex conditionals that = exist in the base languages. I'm not convinced of the value in the oper= ation as it exists. I'm concerned about what it would become as well, t= o fit people's real needs needs.

    My initial reaction was that I would use this operation to test a &= #39;version' field within the data at the top level. This way sequentia= l patching could indicate if a patch is=A0sufficient=A0to bring an object t= o a certain state. But really in describing the patch, we are already makin= g the assumption that we are applying it to the right json later. Or someth= ing 'right' enough.

    Conditional matching/logic is something worthy of a spec, but I'= ;m not convinced this is that specification.


    How are people using the test operation in practice now? I'm as= suming only non-structured matching is recommended... or is deep comparison= of structured types suggested?

    Would this not be better handled outside of the work description it= self?


    --=A0
    Matt (MPCM)

    On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan <pbryan@anode.ca> wrote:

    On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote:

    On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan <pbryan@anode.ca> wrote= :
    Unfortunately, null is a testable value and should not = be interpreted to mean lack of value

    Indeed, but I'd argue that the two cases are semantical= ly equivalent enough for the such differences to be irrelevant. Particularl= y since many (if not most) json vocabularies tend to treat null and undefin= ed as being equivalent.


    While there are some languages that do not make this distinctio= n, I must disagree with your conclusion that it is irrelevant. In JavaScrip= t, null !=3D undefined. The JSON specification went out of its way to defin= e an explicit null value. I do not want to create ambiguities in the test o= peration, nor do I want to create incompatibilities with different implemen= tations where the treatment of null may be concerned.


    There is a clear use case for this and we can bind the scop= e simply by saying that, within json patch, undefined and null are equivale= nt.


    And what is the clear use case for this?

    Paul



    _______________________________________________
    apps-discuss mailing list
    apps= -discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss










    --
    = Matthew P. C. Morley
    --20cf3074b5ce49eecd04c99444c8-- From mnot@mnot.net Thu Sep 13 05:21:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0F021F859A for ; Thu, 13 Sep 2012 05:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.938 X-Spam-Level: X-Spam-Status: No, score=-103.938 tagged_above=-999 required=5 tests=[AWL=-1.339, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g3K5e8ffhBs for ; Thu, 13 Sep 2012 05:21:05 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id AE97721F8568 for ; Thu, 13 Sep 2012 05:21:05 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0A38322E255 for ; Thu, 13 Sep 2012 08:20:58 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Sep 2012 22:20:55 +1000 References: <20120913122030.18862.42892.idtracker@ietfa.amsl.com> To: Apps Discuss Message-Id: <6F089E49-6482-421C-AE4E-1DE26E423406@mnot.net> Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-json-home-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 12:21:06 -0000 FYI. A few small changes; more to come. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-json-home-02.txt > Date: 13 September 2012 10:20:30 PM AEST > To: mnot@mnot.net >=20 >=20 > A new version of I-D, draft-nottingham-json-home-02.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Filename: draft-nottingham-json-home > Revision: 02 > Title: Home Documents for HTTP APIs > Creation date: 2012-09-13 > WG ID: Individual Submission > Number of pages: 14 > URL: = http://www.ietf.org/internet-drafts/draft-nottingham-json-home-02.txt > Status: = http://datatracker.ietf.org/doc/draft-nottingham-json-home > Htmlized: = http://tools.ietf.org/html/draft-nottingham-json-home-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-json-home-02 >=20 > Abstract: > This document proposes a "home document" format for non-browser HTTP > clients. >=20 > Note to Readers >=20 > This draft should be discussed on the apps-discuss mailing list [1]. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 -- Mark Nottingham http://www.mnot.net/ From mmorley@mpcm.com Thu Sep 13 05:21:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D9321F859F for ; Thu, 13 Sep 2012 05:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtiPPDTp+8ZD for ; Thu, 13 Sep 2012 05:21:34 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 99AE221F8568 for ; Thu, 13 Sep 2012 05:21:34 -0700 (PDT) Received: by qaeb19 with SMTP id b19so4968938qae.1 for ; Thu, 13 Sep 2012 05:21:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=IatROC4TAijJiBmx+jpT3NMSyMyG7xBLtQNf/8R71o8=; b=QCO3qfXsFVM32jJOAFlZFcifAk3LB3lugWy9LJHsKRT+NydefbftdyLEQozdulay+Z iqBeoPXKivYQiFiqoDIBxODEFmG/1SPUTJKwbCDgdrihZEDKbWi8mL2ypORWi9lkb3ew DBvhc7L1RPtiwNW0hOuQLlOdX0EXPmcsEceYvFyNBIG+e1MPlqivK40Vl7SaJkvCr6vy kE3DYQb5zvqK2cickRg2E+BzvqA1YmV0pPp8VSGUJs56/1Vl+FePOsdjG33xVnBJZL7g YH8txea2xZczdLW3X9eVLWz2XlmY6Yd/HzUMBaLqDYAD+h0KHz70NpO4zuJT/dZFHlf3 aUWA== MIME-Version: 1.0 Received: by 10.229.135.3 with SMTP id l3mr995538qct.119.1347538885487; Thu, 13 Sep 2012 05:21:25 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.49.30.66 with HTTP; Thu, 13 Sep 2012 05:21:25 -0700 (PDT) In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347413811.4006.3.camel@polyjuice> Date: Thu, 13 Sep 2012 08:21:25 -0400 X-Google-Sender-Auth: GRMawh4rwFAdpCODp-nmOCqP07M Message-ID: From: Matthew Morley To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=00248c7690d2972e9704c994583c X-Gm-Message-State: ALoCoQmZOS07ePpGVK/kfBqyfYxxlfpdIQ5KIB8ixoKwXL9E3aibhJsiUvpNd8vRrtbrnXqqITF7 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 12:21:36 -0000 --00248c7690d2972e9704c994583c Content-Type: text/plain; charset=ISO-8859-1 Okay... I was thinking of this specification as being more free standing. But given "[...] suitable for use with the HTTP PATCH method." this will probably play against more of my thoughts than I was considering. On Thu, Sep 13, 2012 at 8:10 AM, Matthew Morley wrote: > I am not using json patch with any real data/situations so far, so it is > still conjecture from my part, but based with situations I encountered in > real systems in the past. I struggled with a reasonable approach to > conditionals in my rule engine, and adopted a functional but incomplete > mechanism. > > With these discussions, I'll forward something over off-list to the people > of this thread, which might explain some of my views. We can bring it on > list, if you feel it won't distract the conversation/topic. I'm happy to > leave test as is, I just see it as a weak point in the specification. > > But currently the test operation is limited in that it can only: > > - test that a path exists > - AND that it resolves to a single known value > - AND that the value is known at the time of the patch creation > > You can combine multiple test operations within a patch, to create > something like a logical (A=1 AND B=2 AND c=3). You can create multiple > patches with unique tests to simulate something like (A=1 OR B=2 OR C=3). > > If you were to test for existence, something like { "test":/foo/bar"} > seems to be the clearest to me. Also, currently you cannot perform tests > where the data in the json document itself is the point of consideration ( > { "test":"/foo/bar", match:"/foo/baz"}. This gets closer to the approach I > ended up using, more about paths as relationships within the data. > > JSON schema does a good job of describing the shape of objects, and there > are times when that might be a consideration. Simple shapes can be > represented in complex (AND|OR) tests. > > Most of the situations I am envisioning, which require more complex test > operations, are were a patch is generated, but it needs to be selectively > applied across a large set of json documents. If you know specifically > which documents you need to apply patches to, you can use the test > operation pretty well. If you can generate multiple specific patches that > also works well. But it is the compound, negative, and relationship tests > that are the issues. > > This may not be how you envision json patch being utilized. But the test > operation does not seem to fit into the concept of "a JSON document > structure for expressing a sequence of operations to apply to a JSON > document". test is much more of a " and when to apply them" concept. > > 'When to apply them' will require a more complex offering, in my opinion. > I don't know currently of a specification that handles this within JSON > realm. > > > > On Tue, Sep 11, 2012 at 9:36 PM, Paul C. Bryan wrote: > >> ** >> What are people's real needs you're thinking about fitting? It's been >> said that there is a concrete use case for extending the functionality of >> test, but I've yet to hear anything beyond the theoretical. Without knowing >> these, it's all just conjecture to me. >> >> Paul >> >> On Tue, 2012-09-11 at 19:59 -0400, Matthew Morley wrote: >> >> As long as there is a "test" operation, people are going to want to >> extend it into something that matches complex conditionals that exist in >> the base languages. I'm not convinced of the value in the operation as it >> exists. I'm concerned about what it would become as well, to fit people's >> real needs needs. >> >> >> My initial reaction was that I would use this operation to test a >> 'version' field within the data at the top level. This way sequential >> patching could indicate if a patch is sufficient to bring an object to a >> certain state. But really in describing the patch, we are already making >> the assumption that we are applying it to the right json later. Or >> something 'right' enough. >> >> >> Conditional matching/logic is something worthy of a spec, but I'm not >> convinced this is that specification. >> >> >> >> How are people using the test operation in practice now? I'm assuming >> only non-structured matching is recommended... or is deep comparison of >> structured types suggested? >> >> Would this not be better handled outside of the work description itself? >> >> >> >> -- >> Matt (MPCM) >> >> On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan wrote: >> >> On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote: >> >> On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan wrote: >> >> Unfortunately, null is a testable value and should not be interpreted to >> mean lack of value >> >> >> Indeed, but I'd argue that the two cases are semantically equivalent >> enough for the such differences to be irrelevant. Particularly since many >> (if not most) json vocabularies tend to treat null and undefined as being >> equivalent. >> >> >> >> While there are some languages that do not make this distinction, I >> must disagree with your conclusion that it is irrelevant. In JavaScript, >> null != undefined. The JSON specification went out of its way to define an >> explicit null value. I do not want to create ambiguities in the test >> operation, nor do I want to create incompatibilities with different >> implementations where the treatment of null may be concerned. >> >> >> >> There is a clear use case for this and we can bind the scope simply by >> saying that, within json patch, undefined and null are equivalent. >> >> >> >> And what is the clear use case for this? >> >> Paul >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> >> >> >> > > > -- > Matthew P. C. Morley > -- Matthew P. C. Morley --00248c7690d2972e9704c994583c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Okay... I was thinking of this specification as being more free standing. B= ut given "[...] suitable for use with th= e HTTP PATCH method." this will probably play against more of my thoug= hts than I was=A0considering.
    On Thu, Sep 13, 2012 at 8:10 AM, Matthew Mor= ley <matt@mpcm.com> wrote:
    I am not using json patch with any real data/situations so far, so it is st= ill conjecture from my part, but based with situations I encountered in rea= l systems in the past. I struggled with a reasonable approach to conditiona= ls in my rule engine, and adopted a functional but incomplete mechanism.
    With these discussions, I'll forward something over off-list to the= people of this thread, which might explain some of my views. We can bring = it on list, if you feel it won't distract the conversation/topic. I'= ;m happy to leave test as is, I just see it as a weak point in the specific= ation.

    But currently the test operation is limited in that it can only:
  • test that a path exists
  • AND that it resolves to a single known= value
  • AND that the value is known at the time of the patch creatio= n
    • You can combine multiple test operations within a patch, to creat= e something like a logical (A=3D1 AND B=3D2 AND c=3D3). You can create mult= iple patches with unique tests to simulate something like (A=3D1 OR B=3D2 O= R C=3D3).

    If you were to test for existence, something like { "test":/f= oo/bar"} seems to be the clearest to me. Also, currently you cannot pe= rform tests where the data in the json document itself is the point of cons= ideration ( { "test":"/foo/bar", match:"/foo/baz&q= uot;}. This gets closer to the approach I ended up using, more about paths = as relationships within the data.

    JSON schema does a good job of describing the shape of objects, an= d there are times when that might be a consideration. Simple shapes can be = represented in complex (AND|OR) tests.=A0

    Most of the sit= uations I am envisioning, which require more complex test operations, are w= ere a patch is generated, but it needs to be selectively applied across a l= arge set of json documents. If you know specifically which documents you ne= ed to apply patches to, you can use the test operation pretty well. If you = can generate multiple specific patches that also works well. But it is the = compound, negative, and relationship tests that are the issues.

    This may not be how you envision json patch being utilized. But the tes= t operation does not seem to fit into the concept of "a JSON document = structure for expressing a sequence of operations to apply to a JSON docume= nt". test is much more of a " and when to apply them" concep= t.

    'When to apply them' will require a more complex offering, in m= y opinion. I don't know currently of a specification that handles this = within JSON realm.



    On Tue, Sep 11, 2012 at 9:36 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
    =20 =20
    What are people's real needs you're thinking about fitting? It'= s been said that there is a concrete use case for extending the functionali= ty of test, but I've yet to hear anything beyond the theoretical. Witho= ut knowing these, it's all just conjecture to me.

    Paul

    On Tue, 2012-09-11 at 19:59 -0400, Matthew Morley wrote:
    As long as there is a "test" operation, people are going to w= ant to extend it into something that matches complex conditionals that exis= t in the base languages. I'm not convinced of the value in the operatio= n as it exists. I'm concerned about what it would become as well, to fi= t people's real needs needs.

    My initial reaction was that I would use this operation to test a '= version' field within the data at the top level. This way sequential pa= tching could indicate if a patch is=A0sufficient=A0to bring an object to a = certain state. But really in describing the patch, we are already making th= e assumption that we are applying it to the right json later. Or something = 'right' enough.

    Conditional matching/logic is something worthy of a spec, but I'm n= ot convinced this is that specification.


    How are people using the test operation in practice now? I'm assumi= ng only non-structured matching is recommended... or is deep comparison of = structured types suggested?

    Would this not be better handled outside of the work description itself= ?


    --=A0
    Matt (MPCM)

    On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
    On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote:

    On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
    Unfortunately, null is a testable value and should not be i= nterpreted to mean lack of value

    Indeed, but I'd argue that the two cases are semantically e= quivalent enough for the such differences to be irrelevant. Particularly si= nce many (if not most) json vocabularies tend to treat null and undefined a= s being equivalent.


    While there are some languages that do not make this distinction, I= must disagree with your conclusion that it is irrelevant. In JavaScript, n= ull !=3D undefined. The JSON specification went out of its way to define an= explicit null value. I do not want to create ambiguities in the test opera= tion, nor do I want to create incompatibilities with different implementati= ons where the treatment of null may be concerned.


    There is a clear use case for this and we can bind the scope si= mply by saying that, within json patch, undefined and null are equivalent.<= br>


    And what is the clear use case for this?

    Paul


    _______________________________________________
    apps-discuss mailing list
    apps-dis= cuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss







    --
    Matthew P. C. Morley



    -- Matthew P. C. Morley
    --00248c7690d2972e9704c994583c-- From mnot@mnot.net Thu Sep 13 05:33:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBE921F85BB for ; Thu, 13 Sep 2012 05:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.882 X-Spam-Level: X-Spam-Status: No, score=-103.882 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zG6NHeP+2yY for ; Thu, 13 Sep 2012 05:33:51 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id F24BE21F85C4 for ; Thu, 13 Sep 2012 05:33:50 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7815622E257 for ; Thu, 13 Sep 2012 08:33:44 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Sep 2012 22:33:41 +1000 References: <20120913123322.711.48708.idtracker@ietfa.amsl.com> To: Apps Discuss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-http-problem-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 12:33:51 -0000 FYI. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-http-problem-01.txt > Date: 13 September 2012 10:33:22 PM AEST > To: mnot@mnot.net >=20 >=20 > A new version of I-D, draft-nottingham-http-problem-01.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Filename: draft-nottingham-http-problem > Revision: 01 > Title: Indicating Details of Problems to Machines in = HTTP > Creation date: 2012-09-13 > WG ID: Individual Submission > Number of pages: 9 > URL: = http://www.ietf.org/internet-drafts/draft-nottingham-http-problem-01.txt > Status: = http://datatracker.ietf.org/doc/draft-nottingham-http-problem > Htmlized: = http://tools.ietf.org/html/draft-nottingham-http-problem-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-http-problem-01 >=20 > Abstract: > This document defines a "Problem Detail" as an extensible way to > carry machine-readable details of HTTP errors in a response, to = avoid > the need to invent new response formats for non-human consumers. >=20 > Note to Readers >=20 > This draft should be discussed on the apps-discuss mailing list [1]. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 -- Mark Nottingham http://www.mnot.net/ From pbryan@anode.ca Thu Sep 13 09:30:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F348521F8533 for ; Thu, 13 Sep 2012 09:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnO3rznEcotf for ; Thu, 13 Sep 2012 09:30:25 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id C9ADF21F84F8 for ; Thu, 13 Sep 2012 09:30:25 -0700 (PDT) Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 1AA3C647C; Thu, 13 Sep 2012 16:30:25 +0000 (UTC) From: "Paul C. Bryan" To: Mark Nottingham In-Reply-To: <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> Content-Type: multipart/alternative; boundary="=-Zr51zOGr3oX6gw8PddrQ" Date: Thu, 13 Sep 2012 09:30:16 -0700 Message-ID: <1347553816.23081.17.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Apps Discuss Subject: Re: [apps-discuss] JSON-Patch and the 'test' operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 16:30:27 -0000 --=-Zr51zOGr3oX6gw8PddrQ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I could be persuaded to support removing test. Paul On Thu, 2012-09-13 at 14:06 +1000, Mark Nottingham wrote: > So, what does this mean for the document? Should we remove the 'test' operation (which may create further controversy), or leave it in (assuming it will be extended / supplanted if someone designs a 'wrapper')? > > Regards, > > > On 13/09/2012, at 2:15 AM, Paul C. Bryan wrote: > > > +1! > > > > On Wed, 2012-09-12 at 09:12 -0700, James M Snell wrote: > >> Precisely. I've actually already began sketching up a rough and will.. hopefully.. have the chance to prototype some code for it this weekend to prove out the idea. > >> > >> On Wed, Sep 12, 2012 at 9:10 AM, Paul C. Bryan wrote: > >> I currently imagine a "container" JSON-Test document, which would contain a number of conditional expressions as well as the patch document to apply if such tests prove true. I would wholeheartedly support such an initiative, especially if it resulted in keeping JSON-Patch simple. :-) > >> > >> Paul > >> > >> > >> On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote: > >>> The more I look through this, the more I'm generally inclined to agree. As was discussed in the separate thread I brought up about extending json-patch, it is possible to define a super-set of json-patch that introduces a range of potentially very useful predicate operations that follow the same fundamental design as json-patch. Done properly, the two can be layered in interesting ways. "test" can easily fit into the separate specification, allowing json-patch to focus specifically on defining the change operations. > >>> > >>> > >>> - James > >>> > >>> On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley wrote: > >>> As long as there is a "test" operation, people are going to want to extend it into something that matches complex conditionals that exist in the base languages. I'm not convinced of the value in the operation as it exists. I'm concerned about what it would become as well, to fit people's real needs needs. > >>> > >>> My initial reaction was that I would use this operation to test a 'version' field within the data at the top level. This way sequential patching could indicate if a patch is sufficient to bring an object to a certain state. But really in describing the patch, we are already making the assumption that we are applying it to the right json later. Or something 'right' enough. > >>> > >>> Conditional matching/logic is something worthy of a spec, but I'm not convinced this is that specification. > >>> > >>> > >>> How are people using the test operation in practice now? I'm assuming only non-structured matching is recommended... or is deep comparison of structured types suggested? > >>> > >>> Would this not be better handled outside of the work description itself? > >>> > >>> > >>> -- > >>> Matt (MPCM) > >>> > >>> On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan wrote: > >>> > >>> On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote: > >>> > >>>> On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan wrote: > >>>> Unfortunately, null is a testable value and should not be interpreted to mean lack of value > >>>> > >>>> Indeed, but I'd argue that the two cases are semantically equivalent enough for the such differences to be irrelevant. Particularly since many (if not most) json vocabularies tend to treat null and undefined as being equivalent. > >>> > >>> > >>> While there are some languages that do not make this distinction, I must disagree with your conclusion that it is irrelevant. In JavaScript, null != undefined. The JSON specification went out of its way to define an explicit null value. I do not want to create ambiguities in the test operation, nor do I want to create incompatibilities with different implementations where the treatment of null may be concerned. > >>> > >>> > >>>> There is a clear use case for this and we can bind the scope simply by saying that, within json patch, undefined and null are equivalent. > >>> > >>> > >>> And what is the clear use case for this? > >>> > >>> Paul > >>> > >>> > >>> > >>> _______________________________________________ > >>> apps-discuss mailing list > >>> apps-discuss@ietf.org > >>> https://www.ietf.org/mailman/listinfo/apps-discuss > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Mark Nottingham http://www.mnot.net/ > > > --=-Zr51zOGr3oX6gw8PddrQ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit I could be persuaded to support removing test.

    Paul

    On Thu, 2012-09-13 at 14:06 +1000, Mark Nottingham wrote: 
    So, what does this mean for the document? Should we remove the 'test' operation (which may create further controversy), or leave it in (assuming it will be extended / supplanted if someone designs a 'wrapper')?

Regards,


On 13/09/2012, at 2:15 AM, Paul C. Bryan <pbryan@anode.ca> wrote:

> +1!
> 
> On Wed, 2012-09-12 at 09:12 -0700, James M Snell wrote:
>> Precisely. I've actually already began sketching up a rough and will.. hopefully.. have the chance to prototype some code for it this weekend to prove out the idea.
>> 
>> On Wed, Sep 12, 2012 at 9:10 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
>> I currently imagine a "container" JSON-Test document, which would contain a number of conditional expressions as well as the patch document to apply if such tests prove true. I would wholeheartedly support such an initiative, especially if it resulted in keeping JSON-Patch simple. :-)
>> 
>> Paul
>> 
>> 
>> On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote:
>>> The more I look through this, the more I'm generally inclined to agree. As was discussed in the separate thread I brought up about extending json-patch, it is possible to define a super-set of json-patch that introduces a range of potentially very useful predicate operations that follow the same fundamental design as json-patch. Done properly, the two can be layered in interesting ways. "test" can easily fit into the separate specification, allowing json-patch to focus specifically on defining the change operations. 
>>> 
>>> 
>>> - James
>>> 
>>> On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley <matt@mpcm.com> wrote:
>>> As long as there is a "test" operation, people are going to want to extend it into something that matches complex conditionals that exist in the base languages. I'm not convinced of the value in the operation as it exists. I'm concerned about what it would become as well, to fit people's real needs needs. 
>>> 
>>> My initial reaction was that I would use this operation to test a 'version' field within the data at the top level. This way sequential patching could indicate if a patch is sufficient to bring an object to a certain state. But really in describing the patch, we are already making the assumption that we are applying it to the right json later. Or something 'right' enough. 
>>> 
>>> Conditional matching/logic is something worthy of a spec, but I'm not convinced this is that specification. 
>>> 
>>> 
>>> How are people using the test operation in practice now? I'm assuming only non-structured matching is recommended... or is deep comparison of structured types suggested?
>>> 
>>> Would this not be better handled outside of the work description itself? 
>>> 
>>> 
>>> -- 
>>> Matt (MPCM)
>>> 
>>> On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
>>> 
>>> On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote:
>>> 
>>>> On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
>>>> Unfortunately, null is a testable value and should not be interpreted to mean lack of value
>>>> 
>>>> Indeed, but I'd argue that the two cases are semantically equivalent enough for the such differences to be irrelevant. Particularly since many (if not most) json vocabularies tend to treat null and undefined as being equivalent.
>>> 
>>> 
>>> While there are some languages that do not make this distinction, I must disagree with your conclusion that it is irrelevant. In JavaScript, null != undefined. The JSON specification went out of its way to define an explicit null value. I do not want to create ambiguities in the test operation, nor do I want to create incompatibilities with different implementations where the treatment of null may be concerned. 
>>> 
>>> 
>>>> There is a clear use case for this and we can bind the scope simply by saying that, within json patch, undefined and null are equivalent.
>>> 
>>> 
>>> And what is the clear use case for this?
>>> 
>>> Paul 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> apps-discuss mailing list
>>> apps-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   http://www.mnot.net/

    --=-Zr51zOGr3oX6gw8PddrQ-- From internet-drafts@ietf.org Thu Sep 13 10:02:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA8221F84DF; Thu, 13 Sep 2012 10:02:50 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGN5kz+kmV8v; Thu, 13 Sep 2012 10:02:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A5221F851B; Thu, 13 Sep 2012 10:02:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120913170250.20903.66979.idtracker@ietfa.amsl.com> Date: Thu, 13 Sep 2012 10:02:50 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 17:02:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Additional Media Type Structured Syntax Suffixes Author(s) : Tony Hansen Alexey Melnikov Filename : draft-ietf-appsawg-media-type-suffix-regs-04.txt Pages : 15 Date : 2012-09-13 Abstract: A content media type name sometimes includes partitioned meta- information distinguish by a Structured Syntax, to permit noting an attribute of the media as a suffix to the name. This document defines several Structured Syntax Suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax Suffixes, and updates the "+xml" Message Type Structured Syntax Suffix registration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-suffix-regs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-media-type-suffix-reg= s-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alexey.melnikov@isode.com Thu Sep 13 10:42:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB2821F846C for ; Thu, 13 Sep 2012 10:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wA+0h6zwB9Jl for ; Thu, 13 Sep 2012 10:42:33 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 3F04521F8450 for ; Thu, 13 Sep 2012 10:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1347558151; d=isode.com; s=selector; i=@isode.com; bh=l7R9BUlGD4gpBTDW8V159g7SMO/Vp/Q9ByYaidASHpw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=tr5F+hRBurts/6PizEeEUeOIdBieR3P+yjHOXVfNy3oaWJTXTJEiV2EOJzng7+jH9ZAG9H qMrEKErF4xIUq7yjqAuxQfBSLi0uUbZoVdKelbozS3HOJaodiFb+S60MpoF8v00ObpwOQp p1r5dh7g3i85M1hWvXMegQUCdMAmuFw=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 13 Sep 2012 18:42:31 +0100 Message-ID: <50521B06.3010002@isode.com> Date: Thu, 13 Sep 2012 18:42:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: apps-discuss@ietf.org References: <20120913170250.20903.66979.idtracker@ietfa.amsl.com> In-Reply-To: <20120913170250.20903.66979.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 17:42:34 -0000 On 13/09/2012 18:02, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : Additional Media Type Structured Syntax Suffixes > Author(s) : Tony Hansen > Alexey Melnikov > Filename : draft-ietf-appsawg-media-type-suffix-regs-04.txt > Pages : 15 > Date : 2012-09-13 > > Abstract: > A content media type name sometimes includes partitioned meta- > information distinguish by a Structured Syntax, to permit noting an > attribute of the media as a suffix to the name. This document > defines several Structured Syntax Suffixes for use with media type > registrations. In particular, it defines and registers the "+json", > "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax > Suffixes, and updates the "+xml" Message Type Structured Syntax > Suffix registration. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-suffix-regs I just posted a new version that contains some additional changes suggested by Tony: basically better text describing dangers of updating fragment identifier rules for either a suffix or a particular media type. I think this includes much better text than the one I wrote for -03. From superuser@gmail.com Thu Sep 13 13:02:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5969C21F8476 for ; Thu, 13 Sep 2012 13:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIv+U-lj6nLn for ; Thu, 13 Sep 2012 13:02:30 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1AC21F8475 for ; Thu, 13 Sep 2012 13:02:29 -0700 (PDT) Received: by lbky2 with SMTP id y2so2412681lbk.31 for ; Thu, 13 Sep 2012 13:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=defD5JKA9TJTP087NvnmC6AcvSYJ64Qf20dYz+MSFUc=; b=jRb9CPTXoCjhwEiIthw+RAr3GNi9KKNvelvSuUHOB8ENFQ4k6Ha5XKoleseDZgz1Z+ w/KobWQPG8tOkatBzcOCk7P0yEI7F+s1otCc5oNqsouizdZk4DP25eQ22ErNj4ZlUv0T GZ6APvBltjceBer5HfRvn+Gw66Ikjx/QtxvT5pOzOPvDxPZ5Z7hMShoLWOVz9st4E4t6 i1MkH7UBm/1aZs9uPDynefQXBN7qy2EYKL0zeQav2M5qL6TLWMJ60rMrg5zdFJmnI72J qhPOw7odYojbMul2gT5COujxwYJv+E6F2yuPocInv7/ro5zyH0vMvL4OprYgvKDP6/vh gtoA== MIME-Version: 1.0 Received: by 10.112.51.228 with SMTP id n4mr299961lbo.55.1347566548582; Thu, 13 Sep 2012 13:02:28 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Thu, 13 Sep 2012 13:02:28 -0700 (PDT) In-Reply-To: <50521B06.3010002@isode.com> References: <20120913170250.20903.66979.idtracker@ietfa.amsl.com> <50521B06.3010002@isode.com> Date: Thu, 13 Sep 2012 13:02:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 20:02:30 -0000 On Thu, Sep 13, 2012 at 10:42 AM, Alexey Melnikov wrote: > I just posted a new version that contains some additional changes suggested > by Tony: basically better text describing dangers of updating fragment > identifier rules for either a suffix or a particular media type. I think > this includes much better text than the one I wrote for -03. To everyone that's looked at and commented on earlier versions: Please give this a once-over and let us know if you think it's ready to go. -MSK From ht@inf.ed.ac.uk Fri Sep 14 01:26:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6158B21F8546 for ; Fri, 14 Sep 2012 01:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jE4LRrjtFXcU for ; Fri, 14 Sep 2012 01:26:20 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAD421F853B for ; Fri, 14 Sep 2012 01:26:19 -0700 (PDT) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q8E8Q8iK029061; Fri, 14 Sep 2012 09:26:13 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q8E8Q89j017046; Fri, 14 Sep 2012 09:26:08 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q8E8Q8Gh029622; Fri, 14 Sep 2012 09:26:08 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q8E8Q7ww029618; Fri, 14 Sep 2012 09:26:07 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Alexey Melnikov References: <20120913170250.20903.66979.idtracker@ietfa.amsl.com> <50521B06.3010002@isode.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 14 Sep 2012 09:26:07 +0100 In-Reply-To: <50521B06.3010002@isode.com> (Alexey Melnikov's message of "Thu\, 13 Sep 2012 18\:42\:30 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 08:26:21 -0000 Alexey Melnikov writes: > I just posted a new version that contains some additional changes > suggested by Tony: basically better text describing dangers of > updating fragment identifier rules for either a suffix or a particular > media type. I think this includes much better text than the one I > wrote for -03. I agree that covering both cases is good. I did have to read the two new bits in section 5 several times before I was sure I understood the two cases. Could I suggest a small change which might improve understanding: When updating the fragment identifier processing rules for a specific media type, --> When updating the fragment identifier processing rules for a specific xxx/yyy+ media type, I think this is good to go -- thanks for getting it over the line. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From alexey.melnikov@isode.com Fri Sep 14 07:15:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517B821F84B5 for ; Fri, 14 Sep 2012 07:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpjgtpWiFj5g for ; Fri, 14 Sep 2012 07:15:17 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9F76221F8499 for ; Fri, 14 Sep 2012 07:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1347632109; d=isode.com; s=selector; i=@isode.com; bh=10lpSnErb3jBnqwYRtUXJZs1RjX09V/cMgioo3kOrac=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=poIsPc8g6Td3e/CiFwKhFXZ0CF97rtPIKv3yeNgIllxp07xG5X5IhVlZ/I/O29DzcOEh07 Oj8bYPSz+cmP6x6EmhiD0qX8Bit4jSjfb+wtebg+RRGC13JeY30wIn3PqcrUF2zzFVyExS w0tGSz20PeIQwnRllfc4xTf893EjEHc=; Received: from [192.168.1.145] ((unknown) [62.3.217.253]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 14 Sep 2012 15:15:08 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <50533BED.9020609@isode.com> Date: Fri, 14 Sep 2012 15:15:10 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: "Henry S. Thompson" References: <20120913170250.20903.66979.idtracker@ietfa.amsl.com> <50521B06.3010002@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 14:15:18 -0000 Hi Henri, On 14/09/2012 09:26, Henry S. Thompson wrote: > Alexey Melnikov writes: > >> I just posted a new version that contains some additional changes >> suggested by Tony: basically better text describing dangers of >> updating fragment identifier rules for either a suffix or a particular >> media type. I think this includes much better text than the one I >> wrote for -03. > I agree that covering both cases is good. I did have to read the two > new bits in section 5 several times before I was sure I understood the > two cases. > > Could I suggest a small change which might improve understanding: > > When updating the fragment identifier processing rules for a > specific media type, > --> > When updating the fragment identifier processing rules for a > specific xxx/yyy+ media type, > > I think this is good to go -- thanks for getting it over the line. Thanks for the comment, updated my copy. From dret@berkeley.edu Fri Sep 14 11:59:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FEE21F84B6 for ; Fri, 14 Sep 2012 11:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IfEzKkuJG09 for ; Fri, 14 Sep 2012 11:59:01 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 027E921F84B2 for ; Fri, 14 Sep 2012 11:59:00 -0700 (PDT) Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.64]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TCb6M-0001Bn-DU; Fri, 14 Sep 2012 11:58:58 -0700 Message-ID: <50537E6C.8070008@berkeley.edu> Date: Fri, 14 Sep 2012 11:58:52 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" References: <20120914185135.1018.71064.idtracker@ietfa.amsl.com> In-Reply-To: <20120914185135.1018.71064.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120914185135.1018.71064.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hypermedia-web@googlegroups.com, REST-Discuss Subject: [apps-discuss] Fwd: New Version Notification for draft-wilde-profile-link-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 18:59:01 -0000 A new version of I-D, draft-wilde-profile-link-03.txt has been successfully submitted by Erik Wilde and posted to the IETF repository. Filename: draft-wilde-profile-link Revision: 03 Title: The 'profile' Link Relation Type Creation date: 2012-09-14 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-wilde-profile-link-03.txt Status: http://datatracker.ietf.org/doc/draft-wilde-profile-link Htmlized: http://tools.ietf.org/html/draft-wilde-profile-link-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-wilde-profile-link-03 Abstract: This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined to not alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms. Editorial Note (to be removed by RFC Editor) Please discuss this draft on the apps-discuss@ietf.org mailing list. From dret@berkeley.edu Fri Sep 14 12:58:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003E921F84D3 for ; Fri, 14 Sep 2012 12:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHAIaooynQXT for ; Fri, 14 Sep 2012 12:58:22 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 5354B21F84C4 for ; Fri, 14 Sep 2012 12:58:22 -0700 (PDT) Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.64]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TCc1s-0007qc-B1; Fri, 14 Sep 2012 12:58:22 -0700 Message-ID: <50538C5A.3010404@berkeley.edu> Date: Fri, 14 Sep 2012 12:58:18 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" References: <20120914192831.17338.16316.idtracker@ietfa.amsl.com> In-Reply-To: <20120914192831.17338.16316.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120914192831.17338.16316.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hypermedia-web@googlegroups.com, REST-Discuss Subject: [apps-discuss] Fwd: New Version Notification for draft-sinnema-xacml-media-type-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 19:58:23 -0000 A new version of I-D, draft-sinnema-xacml-media-type-00.txt has been successfully submitted by Erik Wilde and posted to the IETF repository. Filename: draft-sinnema-xacml-media-type Revision: 00 Title: eXtensible Access Control Markup Language (XACML) Media Type Creation date: 2012-09-14 WG ID: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-sinnema-xacml-media-type-00.txt Status: http://datatracker.ietf.org/doc/draft-sinnema-xacml-media-type Htmlized: http://tools.ietf.org/html/draft-sinnema-xacml-media-type-00 Abstract: This specification registers an XML-based media type for the eXtensible Access Control Markup Language (XACML). -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From paul.hoffman@vpnc.org Fri Sep 14 13:10:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC38521F855E for ; Fri, 14 Sep 2012 13:10:16 -0700 (PDT) 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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFYkC5Um+-kF for ; Fri, 14 Sep 2012 13:10:16 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 381FC21F8532 for ; Fri, 14 Sep 2012 13:10:16 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q8EKADRw046132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 14 Sep 2012 13:10:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Sep 2012 13:10:12 -0700 References: <20120914184457.16683.33382.idtracker@ietfa.amsl.com> To: Apps Discuss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) Subject: [apps-discuss] Fwd: Last Call: (Prefer Header for HTTP) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 20:10:16 -0000 Of interest to some people here. Begin forwarded message: > From: The IESG > Subject: Last Call: (Prefer Header = for HTTP) to Proposed Standard > Date: September 14, 2012 11:44:57 AM PDT > To: IETF-Announce > Reply-To: ietf@ietf.org >=20 >=20 > The IESG has received a request from an individual submitter to = consider > the following document: > - 'Prefer Header for HTTP' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-10-12. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This specification defines an HTTP header field that can be used by = a > client to request that certain behaviors be implemented by a server > while processing a request. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-snell-http-prefer/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-snell-http-prefer/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 From mnot@mnot.net Fri Sep 14 18:11:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C591221F85AA for ; Fri, 14 Sep 2012 18:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.985 X-Spam-Level: X-Spam-Status: No, score=-103.985 tagged_above=-999 required=5 tests=[AWL=-1.386, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LOWX91xQFgx for ; Fri, 14 Sep 2012 18:11:23 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6842921F85A4 for ; Fri, 14 Sep 2012 18:11:22 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A6B9522E255; Fri, 14 Sep 2012 21:11:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: <1347553816.23081.17.camel@pbryan-wsl.internal.salesforce.com> Date: Sat, 15 Sep 2012 11:11:14 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347553816.23081.17.camel@pbryan-wsl.interna l.salesforce.com> To: Apps Discuss X-Mailer: Apple Mail (2.1486) Subject: [apps-discuss] JSON Patch: removing the "test" operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 01:11:23 -0000 Does anyone object to removing 'test' from json-patch? Regards, On 14/09/2012, at 2:30 AM, Paul C. Bryan wrote: > I could be persuaded to support removing test. >=20 > Paul >=20 > On Thu, 2012-09-13 at 14:06 +1000, Mark Nottingham wrote: >> So, what does this mean for the document? Should we remove the 'test' = operation (which may create further controversy), or leave it in = (assuming it will be extended / supplanted if someone designs a = 'wrapper')? >>=20 >> Regards, >>=20 >>=20 >> On 13/09/2012, at 2:15 AM, Paul C. Bryan < >> pbryan@anode.ca >> > wrote: >>=20 >> > +1! >> >=20 >> > On Wed, 2012-09-12 at 09:12 -0700, James M Snell wrote: >> >> Precisely. I've actually already began sketching up a rough and = will.. hopefully.. have the chance to prototype some code for it this = weekend to prove out the idea. >> >>=20 >> >> On Wed, Sep 12, 2012 at 9:10 AM, Paul C. Bryan < >> pbryan@anode.ca >> > wrote: >> >> I currently imagine a "container" JSON-Test document, which would = contain a number of conditional expressions as well as the patch = document to apply if such tests prove true. I would wholeheartedly = support such an initiative, especially if it resulted in keeping = JSON-Patch simple. :-) >> >>=20 >> >> Paul >> >>=20 >> >>=20 >> >> On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote: >> >>> The more I look through this, the more I'm generally inclined to = agree. As was discussed in the separate thread I brought up about = extending json-patch, it is possible to define a super-set of json-patch = that introduces a range of potentially very useful predicate operations = that follow the same fundamental design as json-patch. Done properly, = the two can be layered in interesting ways. "test" can easily fit into = the separate specification, allowing json-patch to focus specifically on = defining the change operations.=20 >> >>>=20 >> >>>=20 >> >>> - James >> >>>=20 >> >>> On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley < >> matt@mpcm.com >> > wrote: >> >>> As long as there is a "test" operation, people are going to want = to extend it into something that matches complex conditionals that exist = in the base languages. I'm not convinced of the value in the operation = as it exists. I'm concerned about what it would become as well, to fit = people's real needs needs.=20 >> >>>=20 >> >>> My initial reaction was that I would use this operation to test a = 'version' field within the data at the top level. This way sequential = patching could indicate if a patch is sufficient to bring an object to a = certain state. But really in describing the patch, we are already making = the assumption that we are applying it to the right json later. Or = something 'right' enough.=20 >> >>>=20 >> >>> Conditional matching/logic is something worthy of a spec, but I'm = not convinced this is that specification.=20 >> >>>=20 >> >>>=20 >> >>> How are people using the test operation in practice now? I'm = assuming only non-structured matching is recommended... or is deep = comparison of structured types suggested? >> >>>=20 >> >>> Would this not be better handled outside of the work description = itself?=20 >> >>>=20 >> >>>=20 >> >>> --=20 >> >>> Matt (MPCM) >> >>>=20 >> >>> On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan < >> pbryan@anode.ca >> > wrote: >> >>>=20 >> >>> On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote: >> >>>=20 >> >>>> On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan < >> pbryan@anode.ca >> > wrote: >> >>>> Unfortunately, null is a testable value and should not be = interpreted to mean lack of value >> >>>>=20 >> >>>> Indeed, but I'd argue that the two cases are semantically = equivalent enough for the such differences to be irrelevant. = Particularly since many (if not most) json vocabularies tend to treat = null and undefined as being equivalent. >> >>>=20 >> >>>=20 >> >>> While there are some languages that do not make this distinction, = I must disagree with your conclusion that it is irrelevant. In = JavaScript, null !=3D undefined. The JSON specification went out of its = way to define an explicit null value. I do not want to create = ambiguities in the test operation, nor do I want to create = incompatibilities with different implementations where the treatment of = null may be concerned.=20 >> >>>=20 >> >>>=20 >> >>>> There is a clear use case for this and we can bind the scope = simply by saying that, within json patch, undefined and null are = equivalent. >> >>>=20 >> >>>=20 >> >>> And what is the clear use case for this? >> >>>=20 >> >>> Paul=20 >> >>>=20 >> >>>=20 >> >>>=20 >> >>> _______________________________________________ >> >>> apps-discuss mailing list >> >>>=20 >> apps-discuss@ietf.org >>=20 >> >>>=20 >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> >>>=20 >> >>>=20 >> >>>=20 >> >>>=20 >> >>>=20 >> >>>=20 >> >>=20 >> >>=20 >> >>=20 >> >=20 >> > _______________________________________________ >> > apps-discuss mailing list >> >=20 >> apps-discuss@ietf.org >>=20 >> >=20 >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >>=20 >> -- >> Mark Nottingham =20 >> http://www.mnot.net/ >>=20 >>=20 >>=20 >>=20 >>=20 >=20 -- Mark Nottingham http://www.mnot.net/ From mccabe@archive.org Sat Sep 15 04:37:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8DF21F84A0 for ; Sat, 15 Sep 2012 04:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCaYKRUKUEQD for ; Sat, 15 Sep 2012 04:37:58 -0700 (PDT) Received: from mail.archive.org (mail.us.archive.org [207.241.224.6]) by ietfa.amsl.com (Postfix) with ESMTP id 292DE21F849D for ; Sat, 15 Sep 2012 04:37:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.archive.org (Postfix) with ESMTP id 88785684019C; Sat, 15 Sep 2012 04:37:57 -0700 (PDT) Received: from mail.archive.org ([127.0.0.1]) by localhost (mail.archive.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4frkWjpJ-C-k; Sat, 15 Sep 2012 04:37:55 -0700 (PDT) Received: from mikemac-2.local (208-90-212-115.PUBLIC.monkeybrains.net [208.90.212.115]) by mail.archive.org (Postfix) with ESMTPSA id B18446840173; Sat, 15 Sep 2012 04:37:55 -0700 (PDT) Message-ID: <50546893.4080704@archive.org> Date: Sat, 15 Sep 2012 04:37:55 -0700 From: Mike McCabe User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347553816.23081.17.camel@pbryan-wsl.interna l.salesforce.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] JSON Patch: removing the "test" operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 11:37:59 -0000 On 9/14/12 6:11 PM, Mark Nottingham wrote: > Does anyone object to removing 'test' from json-patch? I'm working on a production system for the Internet Archive that uses json-patch to express metadata modifications. So far, it's been a great fit - and a very timely discovery. (I was about to roll my own.) Thank you! For some uses, we need protection against concurrent writes. I was planning on using the 'test' operation for this (with a 'version' field) as 'optimistic' concurrency control. (Locking isn't a good fit, as we want to support writes from outside organizations.) I'd prefer that we not throw out 'test' without a good idea of what might replace it, as there's no flexible, 'in-band' way to get optimistic concurrency without it. I'll try to answer a few of the objections to 'test' that I've seen: * It's unnecessary, as the other patch operations assume knowledge about the document. (That is, errors in patch application will catch unexpected concurrent changes.) -> While other operations can also fail if the document has changed such that they can't apply, this won't catch changes that might have occurred elsewhere in the document (that could be semantically important) (Also, most array operations will succeed even if the array has changed.) * It's unneeded given conditional HTTP, eTag or other mechanisms. -> json-patch is not HTTP PATCH, so these approaches may not be available. They're 'out-of-band' - part of the information needed to apply the patch is outside of the patch (and not a JSON document) They're less flexible; it's easy to imagine a larger JSON document that had sub-documents, where only the sub-documents required atomic changes; each could get it's own version field if needed. Sometimes concurrency control isn't important, or the only requirement is that we don't overwrite if someone else got there first. * It's different from the other operations. -> Other operations can abort the patch, just as test can; it's easily implemented as an operation that happens to not change anything. * It's an incomplete part of an otherwise-useful generic comparison facility. -> For help with concurrency, 'test' *doesn't* need to be a generic comparison facility. If I needed to do that, it would be more flexible to pull document snippets with json-pointer, then do comparisons myself. Testing value equality is enough; testing existence might be useful for some cases. On Thu, Sep 13, 2012 at 8:10 AM, Matthew Morley wrote: > Most of the situations I am envisioning, which require more complex > test operations, are were a patch is generated, but it needs to be > selectively applied across a large set of json documents. If you know > specifically which documents you need to apply patches to, you can use > the test operation pretty well. If you can generate multiple specific > patches that also works well. But it is the compound, negative, and > relationship tests that are the issues. I do see how a more general facility would be useful in this case. (Is such a facility useful outside of json-patch?) Can we get a proposal before removing 'test'? My implementation of json-patch is here: https://github.com/mikemccabe/json-patch-php A JSON test suite for json-patch is here: https://github.com/mikemccabe/json-patch-tests Regards, Mike On 9/14/12 6:11 PM, Mark Nottingham wrote: > > Does anyone object to removing 'test' from json-patch? > > Regards, > > > On 14/09/2012, at 2:30 AM, Paul C. Bryan wrote: > >> I could be persuaded to support removing test. >> >> Paul >> >> On Thu, 2012-09-13 at 14:06 +1000, Mark Nottingham wrote: >>> So, what does this mean for the document? Should we remove the 'test' operation (which may create further controversy), or leave it in (assuming it will be extended / supplanted if someone designs a 'wrapper')? >>> >>> Regards, >>> >>> >>> On 13/09/2012, at 2:15 AM, Paul C. Bryan < >>> pbryan@anode.ca >>>> wrote: >>> >>>> +1! >>>> >>>> On Wed, 2012-09-12 at 09:12 -0700, James M Snell wrote: >>>>> Precisely. I've actually already began sketching up a rough and will.. hopefully.. have the chance to prototype some code for it this weekend to prove out the idea. >>>>> >>>>> On Wed, Sep 12, 2012 at 9:10 AM, Paul C. Bryan < >>> pbryan@anode.ca >>>> wrote: >>>>> I currently imagine a "container" JSON-Test document, which would contain a number of conditional expressions as well as the patch document to apply if such tests prove true. I would wholeheartedly support such an initiative, especially if it resulted in keeping JSON-Patch simple. :-) >>>>> >>>>> Paul >>>>> >>>>> >>>>> On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote: >>>>>> The more I look through this, the more I'm generally inclined to agree. As was discussed in the separate thread I brought up about extending json-patch, it is possible to define a super-set of json-patch that introduces a range of potentially very useful predicate operations that follow the same fundamental design as json-patch. Done properly, the two can be layered in interesting ways. "test" can easily fit into the separate specification, allowing json-patch to focus specifically on defining the change operations. >>>>>> >>>>>> >>>>>> - James >>>>>> >>>>>> On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley < >>> matt@mpcm.com >>>> wrote: >>>>>> As long as there is a "test" operation, people are going to want to extend it into something that matches complex conditionals that exist in the base languages. I'm not convinced of the value in the operation as it exists. I'm concerned about what it would become as well, to fit people's real needs needs. >>>>>> >>>>>> My initial reaction was that I would use this operation to test a 'version' field within the data at the top level. This way sequential patching could indicate if a patch is sufficient to bring an object to a certain state. But really in describing the patch, we are already making the assumption that we are applying it to the right json later. Or something 'right' enough. >>>>>> >>>>>> Conditional matching/logic is something worthy of a spec, but I'm not convinced this is that specification. >>>>>> >>>>>> >>>>>> How are people using the test operation in practice now? I'm assuming only non-structured matching is recommended... or is deep comparison of structured types suggested? >>>>>> >>>>>> Would this not be better handled outside of the work description itself? >>>>>> >>>>>> >>>>>> -- >>>>>> Matt (MPCM) >>>>>> >>>>>> On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan < >>> pbryan@anode.ca >>>> wrote: >>>>>> >>>>>> On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote: >>>>>> >>>>>>> On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan < >>> pbryan@anode.ca >>>> wrote: >>>>>>> Unfortunately, null is a testable value and should not be interpreted to mean lack of value >>>>>>> >>>>>>> Indeed, but I'd argue that the two cases are semantically equivalent enough for the such differences to be irrelevant. Particularly since many (if not most) json vocabularies tend to treat null and undefined as being equivalent. >>>>>> >>>>>> >>>>>> While there are some languages that do not make this distinction, I must disagree with your conclusion that it is irrelevant. In JavaScript, null != undefined. The JSON specification went out of its way to define an explicit null value. I do not want to create ambiguities in the test operation, nor do I want to create incompatibilities with different implementations where the treatment of null may be concerned. >>>>>> >>>>>> >>>>>>> There is a clear use case for this and we can bind the scope simply by saying that, within json patch, undefined and null are equivalent. >>>>>> >>>>>> >>>>>> And what is the clear use case for this? >>>>>> >>>>>> Paul >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> apps-discuss mailing list >>>>>> >>> apps-discuss@ietf.org >>> >>>>>> >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> >>> apps-discuss@ietf.org >>> >>>> >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >>> >>> -- >>> Mark Nottingham >>> http://www.mnot.net/ >>> >>> >>> >>> >>> >> > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From tony@att.com Sat Sep 15 19:09:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0962B21F8466 for ; Sat, 15 Sep 2012 19:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY6X07Ww+fzs for ; Sat, 15 Sep 2012 19:09:16 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 16FA521F8464 for ; Sat, 15 Sep 2012 19:09:16 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id bc435505.0.1141510.00-490.3146950.nbfkord-smmo05.seg.att.com (envelope-from ); Sun, 16 Sep 2012 02:09:16 +0000 (UTC) X-MXL-Hash: 505534cc1cbf952a-850f90eebaf7395f0a45d42c648422eaf45cbf6e Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q8G29DPg006413 for ; Sat, 15 Sep 2012 19:09:14 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q8G297R7006301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 15 Sep 2012 19:09:10 -0700 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint04.pst.cso.att.com (RSA Interceptor) for ; Sat, 15 Sep 2012 19:08:53 -0700 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q8G28qlB017430 for ; Sat, 15 Sep 2012 22:08:52 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q8G28ivv017281 for ; Sat, 15 Sep 2012 22:08:49 -0400 Received: from [130.10.236.27] (vpn-130-10-236-27.vpn.sest.att.com[130.10.236.27]) by maillennium.att.com (mailgw1) with ESMTP id <20120916020805gw100sspmte> (Authid: tony); Sun, 16 Sep 2012 02:08:07 +0000 X-Originating-IP: [130.10.236.27] Message-ID: <505534A9.30301@att.com> Date: Sat, 15 Sep 2012 22:08:41 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <20120913170250.20903.66979.idtracker@ietfa.amsl.com> <50521B06.3010002@isode.com> <50533BED.9020609@isode.com> In-Reply-To: <50533BED.9020609@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=CLKdq2XD c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=1Jwi4qLS6dgA:10 a=orCKFiEqKuoA:10 a=W8a0okJZ_94A:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=fK92HPE7l_oA:10 a=xdW3qOfMRIpfcQDOemsA:9 a=wPNLv] X-AnalysisOut: [fGTeEIA:10] Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 02:09:17 -0000 On 9/14/2012 10:15 AM, Alexey Melnikov wrote: > Hi Henri, > > On 14/09/2012 09:26, Henry S. Thompson wrote: >> I agree that covering both cases is good. I did have to read the two >> new bits in section 5 several times before I was sure I understood the >> two cases. >> >> Could I suggest a small change which might improve understanding: >> >> When updating the fragment identifier processing rules for a >> specific media type, >> --> >> When updating the fragment identifier processing rules for a >> specific xxx/yyy+ media type, >> >> I think this is good to go -- thanks for getting it over the line. > > Thanks for the comment, updated my copy. works for me Tony Hansen From alexey.melnikov@isode.com Sun Sep 16 01:25:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F3F21F84E1 for ; Sun, 16 Sep 2012 01:25:01 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDPUjZR5BO62 for ; Sun, 16 Sep 2012 01:25:00 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id AD7B221F84DC for ; Sun, 16 Sep 2012 01:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1347783897; d=isode.com; s=selector; i=@isode.com; bh=UrKmgCKF3y/6LB6v54S+lMlJR36gGKv5nTZBTiRuxk0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=IuOdpq3DAiPOK9g+pbkdSqXWCINe6nAS8s/UZIyYqrpnPMoRo0is0jwYUupQ6N+GR7aCc3 UfbdPpMKrYirtod8bIaRXrxMP8KR/OoRJq42k7lnt3gb7ZSQJUBbfMl0iArd8VDhK6UQNB PhkMCHDW0PZ6lEJdXUF1+6nzo1vzkmI=; Received: from [192.168.1.4] (ppp95-165-113-163.pppoe.spdop.ru [95.165.113.163]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 16 Sep 2012 09:24:57 +0100 Message-ID: <50558CD6.4080103@isode.com> Date: Sun, 16 Sep 2012 09:24:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Larry Masinter References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "www-tag@w3.org" , "apps-discuss@ietf.org" Subject: [apps-discuss] Pending changes to draft-ietf-appsawg-media-type-suffix-regs (was "Best Practices for Fragment Identifiers and Media Type Definitions") X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 08:25:01 -0000 On 30/07/2012 17:36, Larry Masinter wrote: > To be more explicit (and provide additional URLs): > > http://www.w3.org/TR/fragid-best-practices/ is now (as of last week) a W3C "First Public Working Draft" as the first step of the "Recommendation" track at W3C. > The W3C TAG plan for moving this to Recommendation is http://www.w3.org/2001/tag/products/fragids.html > > (a) comments on the document itself should be sent to www-tag@w3.org. Please note that the latest 'editor draft' is http://www.w3.org/2001/tag/doc/mimeTypesAndFragids. > > (b) it is likely too late to affect draft-ietf-appsawg-media-type-regs > > (c) Perhaps a reference to it from http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs (as an informative source of considerations an expert reviewer might take into account) would be in order. I've just read http://www.w3.org/TR/fragid-best-practices/ and I think it would be a good idea to reference it informatively. Unless there are objections from the APPSAWG Working Group, I will add the reference to draft-ietf-appsawg-media-type-suffix-regs. From pbryan@anode.ca Sun Sep 16 15:42:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397E421F84DE for ; Sun, 16 Sep 2012 15:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGnYyp8xV+xY for ; Sun, 16 Sep 2012 15:42:11 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id A390321F84DD for ; Sun, 16 Sep 2012 15:42:11 -0700 (PDT) Received: from [192.168.1.4] (S0106a021b762dbb3.vf.shawcable.net [174.1.50.247]) by maple.anode.ca (Postfix) with ESMTPSA id 0C85F616A; Sun, 16 Sep 2012 22:42:09 +0000 (UTC) Message-ID: <1347810127.2811.1.camel@polyglot> From: "Paul C. Bryan" To: Mike McCabe Date: Sun, 16 Sep 2012 08:42:07 -0700 In-Reply-To: <50546893.4080704@archive.org> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347553816.23081.17.camel@pbryan-wsl.interna l.salesforce.com> <50546893.4080704@archive.org> Content-Type: multipart/alternative; boundary="=-WRgEs/GC67kBP7nmCdgw" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Patch: removing the "test" operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 22:42:13 -0000 --=-WRgEs/GC67kBP7nmCdgw Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Alright, I propose we keep the test operation as documented in draft-ietf-appsawg-json-patch-03. Paul On Sat, 2012-09-15 at 04:37 -0700, Mike McCabe wrote: > On 9/14/12 6:11 PM, Mark Nottingham wrote: > > Does anyone object to removing 'test' from json-patch? > > > I'm working on a production system for the Internet Archive that uses > json-patch to express metadata modifications. > > So far, it's been a great fit - and a very timely discovery. (I was > about to roll my own.) Thank you! > > > For some uses, we need protection against concurrent writes. I was > planning on using the 'test' operation for this (with a 'version' field) > as 'optimistic' concurrency control. (Locking isn't a good fit, as we > want to support writes from outside organizations.) > > I'd prefer that we not throw out 'test' without a good idea of what > might replace it, as there's no flexible, 'in-band' way to get > optimistic concurrency without it. > > > I'll try to answer a few of the objections to 'test' that I've seen: > > * It's unnecessary, as the other patch operations assume knowledge about > the document. (That is, errors in patch application will catch > unexpected concurrent changes.) > > -> While other operations can also fail if the document has changed such > that they can't apply, this won't catch changes that might have occurred > elsewhere in the document (that could be semantically important) > > (Also, most array operations will succeed even if the array has changed.) > > > * It's unneeded given conditional HTTP, eTag or other mechanisms. > > -> json-patch is not HTTP PATCH, so these approaches may not be available. > > They're 'out-of-band' - part of the information needed to apply the > patch is outside of the patch (and not a JSON document) > > They're less flexible; it's easy to imagine a larger JSON document that > had sub-documents, where only the sub-documents required atomic changes; > each could get it's own version field if needed. > > Sometimes concurrency control isn't important, or the only requirement > is that we don't overwrite if someone else got there first. > > > * It's different from the other operations. > > -> Other operations can abort the patch, just as test can; it's easily > implemented as an operation that happens to not change anything. > > > * It's an incomplete part of an otherwise-useful generic comparison > facility. > > -> For help with concurrency, 'test' *doesn't* need to be a generic > comparison facility. If I needed to do that, it would be more flexible > to pull document snippets with json-pointer, then do comparisons myself. > Testing value equality is enough; testing existence might be useful > for some cases. > > On Thu, Sep 13, 2012 at 8:10 AM, Matthew Morley wrote: > > Most of the situations I am envisioning, which require more complex > > test operations, are were a patch is generated, but it needs to be > > selectively applied across a large set of json documents. If you know > > specifically which documents you need to apply patches to, you can use > > the test operation pretty well. If you can generate multiple specific > > patches that also works well. But it is the compound, negative, and > > relationship tests that are the issues. > > I do see how a more general facility would be useful in this case. (Is > such a facility useful outside of json-patch?) > > > Can we get a proposal before removing 'test'? > > > > My implementation of json-patch is here: > > https://github.com/mikemccabe/json-patch-php > > A JSON test suite for json-patch is here: > > https://github.com/mikemccabe/json-patch-tests > > Regards, > Mike > > > > On 9/14/12 6:11 PM, Mark Nottingham wrote: > > > > Does anyone object to removing 'test' from json-patch? > > > > Regards, > > > > > > On 14/09/2012, at 2:30 AM, Paul C. Bryan wrote: > > > >> I could be persuaded to support removing test. > >> > >> Paul > >> > >> On Thu, 2012-09-13 at 14:06 +1000, Mark Nottingham wrote: > >>> So, what does this mean for the document? Should we remove the 'test' operation (which may create further controversy), or leave it in (assuming it will be extended / supplanted if someone designs a 'wrapper')? > >>> > >>> Regards, > >>> > >>> > >>> On 13/09/2012, at 2:15 AM, Paul C. Bryan < > >>> pbryan@anode.ca > >>>> wrote: > >>> > >>>> +1! > >>>> > >>>> On Wed, 2012-09-12 at 09:12 -0700, James M Snell wrote: > >>>>> Precisely. I've actually already began sketching up a rough and will.. hopefully.. have the chance to prototype some code for it this weekend to prove out the idea. > >>>>> > >>>>> On Wed, Sep 12, 2012 at 9:10 AM, Paul C. Bryan < > >>> pbryan@anode.ca > >>>> wrote: > >>>>> I currently imagine a "container" JSON-Test document, which would contain a number of conditional expressions as well as the patch document to apply if such tests prove true. I would wholeheartedly support such an initiative, especially if it resulted in keeping JSON-Patch simple. :-) > >>>>> > >>>>> Paul > >>>>> > >>>>> > >>>>> On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote: > >>>>>> The more I look through this, the more I'm generally inclined to agree. As was discussed in the separate thread I brought up about extending json-patch, it is possible to define a super-set of json-patch that introduces a range of potentially very useful predicate operations that follow the same fundamental design as json-patch. Done properly, the two can be layered in interesting ways. "test" can easily fit into the separate specification, allowing json-patch to focus specifically on defining the change operations. > >>>>>> > >>>>>> > >>>>>> - James > >>>>>> > >>>>>> On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley < > >>> matt@mpcm.com > >>>> wrote: > >>>>>> As long as there is a "test" operation, people are going to want to extend it into something that matches complex conditionals that exist in the base languages. I'm not convinced of the value in the operation as it exists. I'm concerned about what it would become as well, to fit people's real needs needs. > >>>>>> > >>>>>> My initial reaction was that I would use this operation to test a 'version' field within the data at the top level. This way sequential patching could indicate if a patch is sufficient to bring an object to a certain state. But really in describing the patch, we are already making the assumption that we are applying it to the right json later. Or something 'right' enough. > >>>>>> > >>>>>> Conditional matching/logic is something worthy of a spec, but I'm not convinced this is that specification. > >>>>>> > >>>>>> > >>>>>> How are people using the test operation in practice now? I'm assuming only non-structured matching is recommended... or is deep comparison of structured types suggested? > >>>>>> > >>>>>> Would this not be better handled outside of the work description itself? > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Matt (MPCM) > >>>>>> > >>>>>> On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan < > >>> pbryan@anode.ca > >>>> wrote: > >>>>>> > >>>>>> On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote: > >>>>>> > >>>>>>> On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan < > >>> pbryan@anode.ca > >>>> wrote: > >>>>>>> Unfortunately, null is a testable value and should not be interpreted to mean lack of value > >>>>>>> > >>>>>>> Indeed, but I'd argue that the two cases are semantically equivalent enough for the such differences to be irrelevant. Particularly since many (if not most) json vocabularies tend to treat null and undefined as being equivalent. > >>>>>> > >>>>>> > >>>>>> While there are some languages that do not make this distinction, I must disagree with your conclusion that it is irrelevant. In JavaScript, null != undefined. The JSON specification went out of its way to define an explicit null value. I do not want to create ambiguities in the test operation, nor do I want to create incompatibilities with different implementations where the treatment of null may be concerned. > >>>>>> > >>>>>> > >>>>>>> There is a clear use case for this and we can bind the scope simply by saying that, within json patch, undefined and null are equivalent. > >>>>>> > >>>>>> > >>>>>> And what is the clear use case for this? > >>>>>> > >>>>>> Paul > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> apps-discuss mailing list > >>>>>> > >>> apps-discuss@ietf.org > >>> > >>>>>> > >>> https://www.ietf.org/mailman/listinfo/apps-discuss > >>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> apps-discuss mailing list > >>>> > >>> apps-discuss@ietf.org > >>> > >>>> > >>> https://www.ietf.org/mailman/listinfo/apps-discuss > >>> > >>> > >>> -- > >>> Mark Nottingham > >>> http://www.mnot.net/ > >>> > >>> > >>> > >>> > >>> > >> > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-WRgEs/GC67kBP7nmCdgw Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Alright, I propose we keep the test operation as documented in draft-ietf-appsawg-json-patch-03.

    Paul

    On Sat, 2012-09-15 at 04:37 -0700, Mike McCabe wrote: 
    On 9/14/12 6:11 PM, Mark Nottingham wrote:
 > Does anyone object to removing 'test' from json-patch?


I'm working on a production system for the Internet Archive that uses 
json-patch to express metadata modifications.

So far, it's been a great fit - and a very timely discovery.  (I was 
about to roll my own.)  Thank you!


For some uses, we need protection against concurrent writes.  I was 
planning on using the 'test' operation for this (with a 'version' field) 
as 'optimistic' concurrency control.  (Locking isn't a good fit, as we 
want to support writes from outside organizations.)

I'd prefer that we not throw out 'test' without a good idea of what 
might replace it, as there's no flexible, 'in-band' way to get 
optimistic concurrency without it.


I'll try to answer a few of the objections to 'test' that I've seen:

* It's unnecessary, as the other patch operations assume knowledge about 
the document.  (That is, errors in patch application will catch 
unexpected concurrent changes.)

-> While other operations can also fail if the document has changed such 
that they can't apply, this won't catch changes that might have occurred 
elsewhere in the document (that could be semantically important)

(Also, most array operations will succeed even if the array has changed.)


* It's unneeded given conditional HTTP, eTag or other mechanisms.

-> json-patch is not HTTP PATCH, so these approaches may not be available.

They're 'out-of-band' - part of the information needed to apply the 
patch is outside of the patch (and not a JSON document)

They're less flexible; it's easy to imagine a larger JSON document that 
had sub-documents, where only the sub-documents required atomic changes; 
each could get it's own version field if needed.

Sometimes concurrency control isn't important, or the only requirement 
is that we don't overwrite if someone else got there first.


* It's different from the other operations.

-> Other operations can abort the patch, just as test can; it's easily 
implemented as an operation that happens to not change anything.


* It's an incomplete part of an otherwise-useful generic comparison 
facility.

-> For help with concurrency, 'test' *doesn't* need to be a generic 
comparison facility.  If I needed to do that, it would be more flexible 
to pull document snippets with json-pointer, then do comparisons myself. 
  Testing value equality is enough; testing existence might be useful 
for some cases.

On Thu, Sep 13, 2012 at 8:10 AM, Matthew Morley <matt@mpcm.com> wrote:
> Most of the situations I am envisioning, which require more complex
 > test operations, are were a patch is generated, but it needs to be
 > selectively applied across a large set of json documents. If you know
 > specifically which documents you need to apply patches to, you can use
 > the test operation pretty well. If you can generate multiple specific
> patches that also works well. But it is the compound, negative, and
 > relationship tests that are the issues.

I do see how a more general facility would be useful in this case.  (Is 
such a facility useful outside of json-patch?)


Can we get a proposal before removing 'test'?



My implementation of json-patch is here:

https://github.com/mikemccabe/json-patch-php

A JSON test suite for json-patch is here:

https://github.com/mikemccabe/json-patch-tests

Regards,
Mike



On 9/14/12 6:11 PM, Mark Nottingham wrote:
>
> Does anyone object to removing 'test' from json-patch?
>
> Regards,
>
>
> On 14/09/2012, at 2:30 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
>
>> I could be persuaded to support removing test.
>>
>> Paul
>>
>> On Thu, 2012-09-13 at 14:06 +1000, Mark Nottingham wrote:
>>> So, what does this mean for the document? Should we remove the 'test' operation (which may create further controversy), or leave it in (assuming it will be extended / supplanted if someone designs a 'wrapper')?
>>>
>>> Regards,
>>>
>>>
>>> On 13/09/2012, at 2:15 AM, Paul C. Bryan <
>>> pbryan@anode.ca
>>>> wrote:
>>>
>>>> +1!
>>>>
>>>> On Wed, 2012-09-12 at 09:12 -0700, James M Snell wrote:
>>>>> Precisely. I've actually already began sketching up a rough and will.. hopefully.. have the chance to prototype some code for it this weekend to prove out the idea.
>>>>>
>>>>> On Wed, Sep 12, 2012 at 9:10 AM, Paul C. Bryan <
>>> pbryan@anode.ca
>>>> wrote:
>>>>> I currently imagine a "container" JSON-Test document, which would contain a number of conditional expressions as well as the patch document to apply if such tests prove true. I would wholeheartedly support such an initiative, especially if it resulted in keeping JSON-Patch simple. :-)
>>>>>
>>>>> Paul
>>>>>
>>>>>
>>>>> On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote:
>>>>>> The more I look through this, the more I'm generally inclined to agree. As was discussed in the separate thread I brought up about extending json-patch, it is possible to define a super-set of json-patch that introduces a range of potentially very useful predicate operations that follow the same fundamental design as json-patch. Done properly, the two can be layered in interesting ways. "test" can easily fit into the separate specification, allowing json-patch to focus specifically on defining the change operations.
>>>>>>
>>>>>>
>>>>>> - James
>>>>>>
>>>>>> On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley <
>>> matt@mpcm.com
>>>> wrote:
>>>>>> As long as there is a "test" operation, people are going to want to extend it into something that matches complex conditionals that exist in the base languages. I'm not convinced of the value in the operation as it exists. I'm concerned about what it would become as well, to fit people's real needs needs.
>>>>>>
>>>>>> My initial reaction was that I would use this operation to test a 'version' field within the data at the top level. This way sequential patching could indicate if a patch is sufficient to bring an object to a certain state. But really in describing the patch, we are already making the assumption that we are applying it to the right json later. Or something 'right' enough.
>>>>>>
>>>>>> Conditional matching/logic is something worthy of a spec, but I'm not convinced this is that specification.
>>>>>>
>>>>>>
>>>>>> How are people using the test operation in practice now? I'm assuming only non-structured matching is recommended... or is deep comparison of structured types suggested?
>>>>>>
>>>>>> Would this not be better handled outside of the work description itself?
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt (MPCM)
>>>>>>
>>>>>> On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan <
>>> pbryan@anode.ca
>>>> wrote:
>>>>>>
>>>>>> On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote:
>>>>>>
>>>>>>> On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan <
>>> pbryan@anode.ca
>>>> wrote:
>>>>>>> Unfortunately, null is a testable value and should not be interpreted to mean lack of value
>>>>>>>
>>>>>>> Indeed, but I'd argue that the two cases are semantically equivalent enough for the such differences to be irrelevant. Particularly since many (if not most) json vocabularies tend to treat null and undefined as being equivalent.
>>>>>>
>>>>>>
>>>>>> While there are some languages that do not make this distinction, I must disagree with your conclusion that it is irrelevant. In JavaScript, null != undefined. The JSON specification went out of its way to define an explicit null value. I do not want to create ambiguities in the test operation, nor do I want to create incompatibilities with different implementations where the treatment of null may be concerned.
>>>>>>
>>>>>>
>>>>>>> There is a clear use case for this and we can bind the scope simply by saying that, within json patch, undefined and null are equivalent.
>>>>>>
>>>>>>
>>>>>> And what is the clear use case for this?
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> apps-discuss mailing list
>>>>>>
>>> apps-discuss@ietf.org
>>>
>>>>>>
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> apps-discuss mailing list
>>>>
>>> apps-discuss@ietf.org
>>>
>>>>
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>
>>>
>>> --
>>> Mark Nottingham
>>> http://www.mnot.net/
>>>
>>>
>>>
>>>
>>>
>>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

    --=-WRgEs/GC67kBP7nmCdgw-- From mnot@mnot.net Sun Sep 16 23:10:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F321E21E8039 for ; Sun, 16 Sep 2012 23:10:48 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHSBf4StnJXA for ; Sun, 16 Sep 2012 23:10:44 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id D252221E8040 for ; Sun, 16 Sep 2012 23:10:15 -0700 (PDT) Received: from [192.168.110.52] (unknown [162.112.38.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0114150A85; Mon, 17 Sep 2012 02:10:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: <1347810127.2811.1.camel@polyglot> Date: Mon, 17 Sep 2012 18:10:08 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347553816.23081.17.camel@pbryan-wsl.interna l.salesforce.com> <5 0546893.4080704@archive.org> <1347810127.2811.1.camel@polyglot> To: Paul C. Bryan X-Mailer: Apple Mail (2.1486) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Patch: removing the "test" operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 06:10:49 -0000 Personally -- I'm +1 on that; it has a certain amount of utility, and = while it doesn't do everything, I think it's good enough. On 17/09/2012, at 3:42 AM, Paul C. Bryan wrote: > Alright, I propose we keep the test operation as documented in = draft-ietf-appsawg-json-patch-03. >=20 > Paul >=20 > On Sat, 2012-09-15 at 04:37 -0700, Mike McCabe wrote: >> On 9/14/12 6:11 PM, Mark Nottingham wrote: >> > Does anyone object to removing 'test' from json-patch? >>=20 >>=20 >> I'm working on a production system for the Internet Archive that uses=20= >> json-patch to express metadata modifications. >>=20 >> So far, it's been a great fit - and a very timely discovery. (I was=20= >> about to roll my own.) Thank you! >>=20 >>=20 >> For some uses, we need protection against concurrent writes. I was=20= >> planning on using the 'test' operation for this (with a 'version' = field)=20 >> as 'optimistic' concurrency control. (Locking isn't a good fit, as = we=20 >> want to support writes from outside organizations.) >>=20 >> I'd prefer that we not throw out 'test' without a good idea of what=20= >> might replace it, as there's no flexible, 'in-band' way to get=20 >> optimistic concurrency without it. >>=20 >>=20 >> I'll try to answer a few of the objections to 'test' that I've seen: >>=20 >> * It's unnecessary, as the other patch operations assume knowledge = about=20 >> the document. (That is, errors in patch application will catch=20 >> unexpected concurrent changes.) >>=20 >> -> While other operations can also fail if the document has changed = such=20 >> that they can't apply, this won't catch changes that might have = occurred=20 >> elsewhere in the document (that could be semantically important) >>=20 >> (Also, most array operations will succeed even if the array has = changed.) >>=20 >>=20 >> * It's unneeded given conditional HTTP, eTag or other mechanisms. >>=20 >> -> json-patch is not HTTP PATCH, so these approaches may not be = available. >>=20 >> They're 'out-of-band' - part of the information needed to apply the=20= >> patch is outside of the patch (and not a JSON document) >>=20 >> They're less flexible; it's easy to imagine a larger JSON document = that=20 >> had sub-documents, where only the sub-documents required atomic = changes;=20 >> each could get it's own version field if needed. >>=20 >> Sometimes concurrency control isn't important, or the only = requirement=20 >> is that we don't overwrite if someone else got there first. >>=20 >>=20 >> * It's different from the other operations. >>=20 >> -> Other operations can abort the patch, just as test can; it's = easily=20 >> implemented as an operation that happens to not change anything. >>=20 >>=20 >> * It's an incomplete part of an otherwise-useful generic comparison=20= >> facility. >>=20 >> -> For help with concurrency, 'test' *doesn't* need to be a generic=20= >> comparison facility. If I needed to do that, it would be more = flexible=20 >> to pull document snippets with json-pointer, then do comparisons = myself.=20 >> Testing value equality is enough; testing existence might be useful=20= >> for some cases. >>=20 >> On Thu, Sep 13, 2012 at 8:10 AM, Matthew Morley < >> matt@mpcm.com >> > wrote: >> > Most of the situations I am envisioning, which require more complex >> > test operations, are were a patch is generated, but it needs to be >> > selectively applied across a large set of json documents. If you = know >> > specifically which documents you need to apply patches to, you can = use >> > the test operation pretty well. If you can generate multiple = specific >> > patches that also works well. But it is the compound, negative, and >> > relationship tests that are the issues. >>=20 >> I do see how a more general facility would be useful in this case. = (Is=20 >> such a facility useful outside of json-patch?) >>=20 >>=20 >> Can we get a proposal before removing 'test'? >>=20 >>=20 >>=20 >> My implementation of json-patch is here: >>=20 >>=20 >> https://github.com/mikemccabe/json-patch-php >>=20 >>=20 >> A JSON test suite for json-patch is here: >>=20 >>=20 >> https://github.com/mikemccabe/json-patch-tests >>=20 >>=20 >> Regards, >> Mike >>=20 >>=20 >>=20 >> On 9/14/12 6:11 PM, Mark Nottingham wrote: >> > >> > Does anyone object to removing 'test' from json-patch? >> > >> > Regards, >> > >> > >> > On 14/09/2012, at 2:30 AM, Paul C. Bryan < >> pbryan@anode.ca >> > wrote: >> > >> >> I could be persuaded to support removing test. >> >> >> >> Paul >> >> >> >> On Thu, 2012-09-13 at 14:06 +1000, Mark Nottingham wrote: >> >>> So, what does this mean for the document? Should we remove the = 'test' operation (which may create further controversy), or leave it in = (assuming it will be extended / supplanted if someone designs a = 'wrapper')? >> >>> >> >>> Regards, >> >>> >> >>> >> >>> On 13/09/2012, at 2:15 AM, Paul C. Bryan < >> >>>=20 >> pbryan@anode.ca >>=20 >> >>>> wrote: >> >>> >> >>>> +1! >> >>>> >> >>>> On Wed, 2012-09-12 at 09:12 -0700, James M Snell wrote: >> >>>>> Precisely. I've actually already began sketching up a rough and = will.. hopefully.. have the chance to prototype some code for it this = weekend to prove out the idea. >> >>>>> >> >>>>> On Wed, Sep 12, 2012 at 9:10 AM, Paul C. Bryan < >> >>>=20 >> pbryan@anode.ca >>=20 >> >>>> wrote: >> >>>>> I currently imagine a "container" JSON-Test document, which = would contain a number of conditional expressions as well as the patch = document to apply if such tests prove true. I would wholeheartedly = support such an initiative, especially if it resulted in keeping = JSON-Patch simple. :-) >> >>>>> >> >>>>> Paul >> >>>>> >> >>>>> >> >>>>> On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote: >> >>>>>> The more I look through this, the more I'm generally inclined = to agree. As was discussed in the separate thread I brought up about = extending json-patch, it is possible to define a super-set of json-patch = that introduces a range of potentially very useful predicate operations = that follow the same fundamental design as json-patch. Done properly, = the two can be layered in interesting ways. "test" can easily fit into = the separate specification, allowing json-patch to focus specifically on = defining the change operations. >> >>>>>> >> >>>>>> >> >>>>>> - James >> >>>>>> >> >>>>>> On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley < >> >>>=20 >> matt@mpcm.com >>=20 >> >>>> wrote: >> >>>>>> As long as there is a "test" operation, people are going to = want to extend it into something that matches complex conditionals that = exist in the base languages. I'm not convinced of the value in the = operation as it exists. I'm concerned about what it would become as = well, to fit people's real needs needs. >> >>>>>> >> >>>>>> My initial reaction was that I would use this operation to = test a 'version' field within the data at the top level. This way = sequential patching could indicate if a patch is sufficient to bring an = object to a certain state. But really in describing the patch, we are = already making the assumption that we are applying it to the right json = later. Or something 'right' enough. >> >>>>>> >> >>>>>> Conditional matching/logic is something worthy of a spec, but = I'm not convinced this is that specification. >> >>>>>> >> >>>>>> >> >>>>>> How are people using the test operation in practice now? I'm = assuming only non-structured matching is recommended... or is deep = comparison of structured types suggested? >> >>>>>> >> >>>>>> Would this not be better handled outside of the work = description itself? >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Matt (MPCM) >> >>>>>> >> >>>>>> On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan < >> >>>=20 >> pbryan@anode.ca >>=20 >> >>>> wrote: >> >>>>>> >> >>>>>> On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote: >> >>>>>> >> >>>>>>> On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan < >> >>>=20 >> pbryan@anode.ca >>=20 >> >>>> wrote: >> >>>>>>> Unfortunately, null is a testable value and should not be = interpreted to mean lack of value >> >>>>>>> >> >>>>>>> Indeed, but I'd argue that the two cases are semantically = equivalent enough for the such differences to be irrelevant. = Particularly since many (if not most) json vocabularies tend to treat = null and undefined as being equivalent. >> >>>>>> >> >>>>>> >> >>>>>> While there are some languages that do not make this = distinction, I must disagree with your conclusion that it is irrelevant. = In JavaScript, null !=3D undefined. The JSON specification went out of = its way to define an explicit null value. I do not want to create = ambiguities in the test operation, nor do I want to create = incompatibilities with different implementations where the treatment of = null may be concerned. >> >>>>>> >> >>>>>> >> >>>>>>> There is a clear use case for this and we can bind the scope = simply by saying that, within json patch, undefined and null are = equivalent. >> >>>>>> >> >>>>>> >> >>>>>> And what is the clear use case for this? >> >>>>>> >> >>>>>> Paul >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> apps-discuss mailing list >> >>>>>> >> >>>=20 >> apps-discuss@ietf.org >>=20 >> >>> >> >>>>>> >> >>>=20 >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> >>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> _______________________________________________ >> >>>> apps-discuss mailing list >> >>>> >> >>>=20 >> apps-discuss@ietf.org >>=20 >> >>> >> >>>> >> >>>=20 >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> >>> >> >>> >> >>> -- >> >>> Mark Nottingham >> >>>=20 >> http://www.mnot.net/ >>=20 >> >>> >> >>> >> >>> >> >>> >> >>> >> >> >> > >> > -- >> > Mark Nottingham =20 >> http://www.mnot.net/ >>=20 >> > >> > >> > >> > _______________________________________________ >> > apps-discuss mailing list >> >=20 >> apps-discuss@ietf.org >>=20 >> >=20 >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> > >> _______________________________________________ >> apps-discuss mailing list >>=20 >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From internet-drafts@ietf.org Sun Sep 16 23:22:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A7C21F84D3; Sun, 16 Sep 2012 23:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzlJ1KKFx33B; Sun, 16 Sep 2012 23:22:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AA021F84CE; Sun, 16 Sep 2012 23:21:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120917062153.31160.74199.idtracker@ietfa.amsl.com> Date: Sun, 16 Sep 2012 23:21:53 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 06:22:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : JSON Patch Author(s) : Paul C. Bryan Mark Nottingham Filename : draft-ietf-appsawg-json-patch-04.txt Pages : 15 Date : 2012-09-16 Abstract: JSON Patch defines the media type "application/json-patch", a JSON document structure for expressing a sequence of operations to apply to a JSON document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-patch-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mnot@mnot.net Sun Sep 16 23:24:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A57C21F847C for ; Sun, 16 Sep 2012 23:24:17 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFqwTkBaSixx for ; Sun, 16 Sep 2012 23:24:16 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id C5B8A21F8435 for ; Sun, 16 Sep 2012 23:24:16 -0700 (PDT) Received: from [192.168.110.52] (unknown [162.112.38.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6AF86509B4; Mon, 17 Sep 2012 02:24:01 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham Date: Mon, 17 Sep 2012 18:24:02 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120917062225.31160.89210.idtracker@ietfa.amsl.com> To: "Murray S. Kucherawy" , Salvatore Loreto X-Mailer: Apple Mail (2.1486) Cc: Apps Discuss Subject: [apps-discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-patch-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 06:24:17 -0000 This draft incorporated some minor feedback from James and made a few = error conditions explicit. With it -- assuming that the decision to keep "test" in as-is -- I = *think* we're ready for WGLC for both json-pointer and json-patch. Cheers, Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-appsawg-json-patch-04.txt > Date: 17 September 2012 6:22:25 PM NZST > To: mnot@mnot.net > Cc: pbryan@anode.ca >=20 >=20 > A new version of I-D, draft-ietf-appsawg-json-patch-04.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Filename: draft-ietf-appsawg-json-patch > Revision: 04 > Title: JSON Patch > Creation date: 2012-09-17 > WG ID: appsawg > Number of pages: 15 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-04.txt > Status: = http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch > Htmlized: = http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-patch-04 >=20 > Abstract: > JSON Patch defines the media type "application/json-patch", a JSON > document structure for expressing a sequence of operations to apply > to a JSON document. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 -- Mark Nottingham http://www.mnot.net/ From James.H.Manger@team.telstra.com Mon Sep 17 00:32:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B94C21F8471 for ; Mon, 17 Sep 2012 00:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8C+Zzbkdkpm for ; Mon, 17 Sep 2012 00:32:56 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 84F3C21F8440 for ; Mon, 17 Sep 2012 00:32:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,434,1344175200"; d="scan'208";a="94408917" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 17 Sep 2012 17:32:53 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6837"; a="123730909" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcavi.tcif.telstra.com.au with ESMTP; 17 Sep 2012 17:32:53 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Mon, 17 Sep 2012 17:32:53 +1000 From: "Manger, James H" To: Mark Nottingham , Paul C.Bryan , "apps-discuss@ietf.org" Date: Mon, 17 Sep 2012 17:32:51 +1000 Thread-Topic: JSON Patch: extensibility Thread-Index: Ac2Umzhxf2RbQlG6RWaubgGgjktsewABAWBg Message-ID: <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347553816.23081.17.camel@pbryan-wsl.interna l.salesforce.com> <5 0546893.4080704@archive.org> <1347810127.2811.1.camel@polyglot> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 07:32:57 -0000 VGhlIEpTT04gcGF0Y2ggc3BlYyBsb29rcyBnb29kOiBkcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1w YXRjaC0wNC4NCg0KVGhlcmUgaXMgbm8gZXhwbGljaXQgbWVudGlvbiBvZiBleHRlbnNpYmlsaXR5 IG9mIHRoZSBKU09OIHBhdGNoIHN5bnRheC4gUHJlc3VtYWJseSBuZXcgb3BlcmF0aW9ucyAoYmV5 b25kIGFkZC9yZW1vdmUvcmVwbGFjZS9tb3ZlL2NvcHkvdGVzdCkgY291bGQgYmUgYWRkZWQsIHdp dGggdGhlIHVuZGVyc3RhbmRpbmcgdGhhdCAib2xkIiBpbXBsZW1lbnRhdGlvbnMgd2lsbCByZWpl Y3Qgc3VjaCBkb2N1bWVudHMgW3NlY3Rpb24gNCBzYXlzIGFuIHVua25vd24gb3BlcmF0aW9uIGlz IGFuIGVycm9yXS4gQWRkaW5nIGV4dHJhIGZpZWxkcyB0byBhbiBleGlzdGluZyBvcGVyYXRpb24g aXMgbGVzcyBjbGVhciAoZWcgeyJhZGQiOiIvZm9vLzEiLCJ2YWx1ZSI6ImJheiIsInJlcGVhdCI6 MTB9KS4gVGhlcmUgaXMgbm8gZXhwbGljaXQgbWVudGlvbiB0aGF0IHRoYXQgd291bGQgYmUgYW4g ZXJyb3IuIFBlcmhhcHMgaW1wbGVtZW50YXRpb25zIHdpbGwgaWdub3JlIHVucmVjb2duaXplZCBm aWVsZHMuDQoNCkNvdWxkIG1vcmUgc29waGlzdGljYXRlZCBmdXR1cmUgdGVzdCBydWxlcyBkZWZp bmUsIHNheSwgYSAidGVzdDIiIG9wZXJhdGlvbj8gT3IgaXMgaXQgdGhlIGV4cGVjdGF0aW9uIHRo YXQgc3VjaCBhIHN5bnRheCB3b3VsZCBuZWVkIGEgbmV3IG1lZGlhIHR5cGU/DQoNCkVhY2ggb3Bl cmF0aW9uIGxpc3RzIGEgZnVsbCBKU09OIHBvaW50ZXIgZnJvbSB0aGUgcm9vdCBvZiB0aGUgcmVz b3VyY2UuIElmIHlvdSB3YW50IHRvIHJlcGxhY2UgYSBkb3plbiBmaWVsZHMgaW4gYSBkZWVwbHkg bmVzdGVkIG9iamVjdCB5b3UgbmVlZCB0byByZXBlYXQgdGhlIHBhdGggdG8gdGhhdCBvYmplY3Qg YSBkb3plbiB0aW1lcy4gVGhpcyBtYXkgYmUgYSByZWFzb25hYmxlIGNvbXByb21pc2UgdG8gYXZv aWQgYSBtb3JlIGNvbXBsZXggcGF0Y2ggc3RydWN0dXJlIChwYXJ0aWN1bGFybHkgaWYgY29tcHJl c3Npb24gcmVtb3ZlcyBtdWNoIG9mIHRoZSBvdmVyaGVhZCksIGJ1dCBJIHdhc24ndCBzdXJlIGlm IGFueSBhbHRlcm5hdGl2ZSBoYWQgYmVlbiBjb25zaWRlcmVkLiBGb3IgZXhhbXBsZSwgeyJwYXRj aCI6Ii9mZWUvZmllL2ZvL2Z1bS9mb28iLCJ2YWx1ZSI6W3siYWRkIjoieCIsInZhbHVlIjoiYmF6 In0seyJhZGQiOiJ5IiwidmFsdWUiOjN9XX0uDQoNCldvdWxkIEkgYmUgb3BlbmluZyBhIGNhbiBv ZiB3b3JtcyAob3IgZG9pbmcgc29tZSBiaWtlLXNoZWRkaW5nKSBpZiBJIGFza2VkIHdoeSBhcHBs aWNhdGlvbi9qc29uLXBhdGNoIGluc3RlYWQgb2YgYXBwbGljYXRpb24vcGF0Y2granNvbj8NCg0K LS0NCkphbWVzIE1hbmdlcg0K From pbryan@anode.ca Mon Sep 17 12:15:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFB421F867B for ; Mon, 17 Sep 2012 12:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0LVz19jLCcW for ; Mon, 17 Sep 2012 12:15:26 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 60CF921F84EA for ; Mon, 17 Sep 2012 12:15:25 -0700 (PDT) Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 67F42616A; Mon, 17 Sep 2012 19:15:24 +0000 (UTC) From: "Paul C. Bryan" To: Mark Nottingham In-Reply-To: References: <20120917062225.31160.89210.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="=-0i2rLIKBeYS93oiMaVhy" Date: Mon, 17 Sep 2012 12:15:23 -0700 Message-ID: <1347909323.19756.12.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-patch-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 19:15:27 -0000 --=-0i2rLIKBeYS93oiMaVhy Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit By recommending we go with -03's test semantics, I was not endorsing testing for presence. For my edification, could I know the case for testing presence is? In other words, since most operations fail if a value is not present, in what case would it be necessary to test for presence before applying such operations? Paul On Mon, 2012-09-17 at 18:24 +1200, Mark Nottingham wrote: > This draft incorporated some minor feedback from James and made a few error conditions explicit. > > With it -- assuming that the decision to keep "test" in as-is -- I *think* we're ready for WGLC for both json-pointer and json-patch. > > Cheers, > > > Begin forwarded message: > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for draft-ietf-appsawg-json-patch-04.txt > > Date: 17 September 2012 6:22:25 PM NZST > > To: mnot@mnot.net > > Cc: pbryan@anode.ca > > > > > > A new version of I-D, draft-ietf-appsawg-json-patch-04.txt > > has been successfully submitted by Mark Nottingham and posted to the > > IETF repository. > > > > Filename: draft-ietf-appsawg-json-patch > > Revision: 04 > > Title: JSON Patch > > Creation date: 2012-09-17 > > WG ID: appsawg > > Number of pages: 15 > > URL: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-04.txt > > Status: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch > > Htmlized: http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04 > > Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-patch-04 > > > > Abstract: > > JSON Patch defines the media type "application/json-patch", a JSON > > document structure for expressing a sequence of operations to apply > > to a JSON document. > > > > > > > > > > The IETF Secretariat > > > > -- > Mark Nottingham > http://www.mnot.net/ > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-0i2rLIKBeYS93oiMaVhy Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit By recommending we go with -03's test semantics, I was not endorsing testing for presence. For my edification, could I know the case for testing presence is? In other words, since most operations fail if a value is not present, in what case would it be necessary to test for presence before applying such operations?

    Paul

    On Mon, 2012-09-17 at 18:24 +1200, Mark Nottingham wrote: 
    This draft incorporated some minor feedback from James and made a few error conditions explicit.

With it -- assuming that the decision to keep "test" in as-is -- I *think* we're ready for WGLC for both json-pointer and json-patch.

Cheers,


Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-ietf-appsawg-json-patch-04.txt
> Date: 17 September 2012 6:22:25 PM NZST
> To: mnot@mnot.net
> Cc: pbryan@anode.ca
> 
> 
> A new version of I-D, draft-ietf-appsawg-json-patch-04.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Filename:	 draft-ietf-appsawg-json-patch
> Revision:	 04
> Title:		 JSON Patch
> Creation date:	 2012-09-17
> WG ID:		 appsawg
> Number of pages: 15
> URL:             http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-04.txt
> Status:          http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch
> Htmlized:        http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-patch-04
> 
> Abstract:
>   JSON Patch defines the media type "application/json-patch", a JSON
>   document structure for expressing a sequence of operations to apply
>   to a JSON document.
> 
> 
> 
> 
> The IETF Secretariat
> 

--
Mark Nottingham
http://www.mnot.net/




_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

    --=-0i2rLIKBeYS93oiMaVhy-- From pbryan@anode.ca Mon Sep 17 12:33:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B459221F861E for ; Mon, 17 Sep 2012 12:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USEpD+331kCd for ; Mon, 17 Sep 2012 12:33:18 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id DB66921F8639 for ; Mon, 17 Sep 2012 12:33:18 -0700 (PDT) Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 28749616A; Mon, 17 Sep 2012 19:33:18 +0000 (UTC) From: "Paul C. Bryan" To: "Manger, James H" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347553816.23081.17.camel@pbryan-wsl.interna l.salesforce.com> <5 0546893.4080704@archive.org> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="=-/Au8Oo1ZKGAdPqNcSBrG" Date: Mon, 17 Sep 2012 12:33:16 -0700 Message-ID: <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 19:33:19 -0000 --=-/Au8Oo1ZKGAdPqNcSBrG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Mon, 2012-09-17 at 17:32 +1000, Manger, James H wrote: > The JSON patch spec looks good: draft-ietf-appsawg-json-patch-04. > > There is no explicit mention of extensibility of the JSON patch > syntax. Presumably new operations (beyond > add/remove/replace/move/copy/test) could be added, with the > understanding that "old" implementations will reject such documents > [section 4 says an unknown operation is an error]. Adding extra fields > to an existing operation is less clear (eg > {"add":"/foo/1","value":"baz","repeat":10}). There is no explicit > mention that that would be an error. Perhaps implementations will > ignore unrecognized fields. I had envisioned a container document type, which would enumerate a set of conditions that must be met before processing the operations an associated (contained) JSON Patch document. Taking this approach means that there is no confusion over what's a JSON Patch document vs. the extension document type. Since JSON Patch is an array of operation objects, such a structure would remain relatively straightforward. More concretely, perhaps something like: { "tests": [ { "less-than": "/some/path", "value": 42 }, { "exists": "/some/other/path" }, { "not-exists": "/yet/another/path" }, { "contains": "/foo/bar", "value": "Major-General" } ], "application/json-patch": [ { "replace": "/some/path", "value": 42 }, { "delete": "/some/other/path" }, { "add": "/yet/another/path", "value": "bar!" } ] } Thoughts? > Could more sophisticated future test rules define, say, a "test2" > operation? Or is it the expectation that such a syntax would need a > new media type? I would say any extension should require its own media type. > Each operation lists a full JSON pointer from the root of the > resource. If you want to replace a dozen fields in a deeply nested > object you need to repeat the path to that object a dozen times. This > may be a reasonable compromise to avoid a more complex patch structure > (particularly if compression removes much of the overhead), but I > wasn't sure if any alternative had been considered. For example, > {"patch":"/fee/fie/fo/fum/foo","value":[{"add":"x","value":"baz"},{"add":"y","value":3}]}. We've considered alternatives in the past, but concluded that given the verbosity of the JSON Patch document, the likely strategy to reduce size would be through compression. As such, multiple similar paths would compress fairly well. > Would I be opening a can of worms (or doing some bike-shedding) if I > asked why application/json-patch instead of application/patch+json? Probably. I originally proposed application/patch+json. The main problem with application/patch+json is that it implies that there are other representations of application/patch, not just JSON (e.g. application/patch+xml). In this case, JSON Patch is meant to address only JSON documents in a JSON format. Furthermore, I'm not yet aware of a specification for JSON like there is is for XML that promotes the addition of +json. Therefore, I'd say that application/json-patch is probably the better choice. Paul --=-/Au8Oo1ZKGAdPqNcSBrG Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 2012-09-17 at 17:32 +1000, Manger, James H wrote:
    The JSON patch spec looks good: draft-ietf-appsawg-json-patch-04.

    There is no explicit mention of extensibility of the JSON patch syntax. Presumably new operations (beyond add/remove/replace/move/copy/test) could be added, with the understanding that "old" implementations will reject such documents [section 4 says an unknown operation is an error]. Adding extra fields to an existing operation is less clear (eg {"add":"/foo/1","value":"baz","repeat":10}). There is no explicit mention that that would be an error. Perhaps implementations will ignore unrecognized fields.

    I had envisioned a container document type, which would enumerate a set of conditions that must be met before processing the operations an associated (contained) JSON Patch document. Taking this approach means that there is no confusion over what's a JSON Patch document vs. the extension document type. Since JSON Patch is an array of operation objects, such a structure would remain relatively straightforward.

    More concretely, perhaps something like:

    {
    "tests": [
        { "less-than": "/some/path", "value": 42 },
        { "exists": "/some/other/path" },
        { "not-exists": "/yet/another/path" },
        { "contains": "/foo/bar", "value": "Major-General" }
    ], "application/json-patch": [
        { "replace": "/some/path", "value": 42 },
        { "delete": "/some/other/path" },
        { "add": "/yet/another/path", "value": "bar!" }
    ]
}

    Thoughts?

    Could more sophisticated future test rules define, say, a "test2" operation? Or is it the expectation that such a syntax would need a new media type?

    I would say any extension should require its own media type.

    Each operation lists a full JSON pointer from the root of the resource. If you want to replace a dozen fields in a deeply nested object you need to repeat the path to that object a dozen times. This may be a reasonable compromise to avoid a more complex patch structure (particularly if compression removes much of the overhead), but I wasn't sure if any alternative had been considered. For example, {"patch":"/fee/fie/fo/fum/foo","value":[{"add":"x","value":"baz"},{"add":"y","value":3}]}.

    We've considered alternatives in the past, but concluded that given the verbosity of the JSON Patch document, the likely strategy to reduce size would be through compression. As such, multiple similar paths would compress fairly well.

    Would I be opening a can of worms (or doing some bike-shedding) if I asked why application/json-patch instead of application/patch+json?

    Probably. I originally proposed application/patch+json. The main problem with application/patch+json is that it implies that there are other representations of application/patch, not just JSON (e.g. application/patch+xml). In this case, JSON Patch is meant to address only JSON documents in a JSON format. Furthermore, I'm not yet aware of a specification for JSON like there is is for XML that promotes the addition of +json. Therefore, I'd say that application/json-patch is probably the better choice.

    Paul --=-/Au8Oo1ZKGAdPqNcSBrG-- From jasnell@gmail.com Mon Sep 17 12:39:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D59021E803C for ; Mon, 17 Sep 2012 12:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dp97FZBKL44 for ; Mon, 17 Sep 2012 12:39:23 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE8021E8037 for ; Mon, 17 Sep 2012 12:39:22 -0700 (PDT) Received: by weyx48 with SMTP id x48so944208wey.31 for ; Mon, 17 Sep 2012 12:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=IADkK9p0W/9/M/ceXlg7WyPtInRcJmYSc42lxA5bREw=; b=geURSateL54EkuyU5NA/axU3yGMRMs9UyiOipQmKcxzxh6dCDOWV28hTr6iSIn8jCl vnRgdAvznMItJchPxA2I4LHGJCksN0QAFLgVqv8tQ7S6cSRxOuURo9IVmbTagYKQiP0Y l2Qrfy0LoXmYI8BpY3/nL/RzZhorUU9Ra3bwp+lqC/tVfV0LbVHJL7uijzL3a4+zugBP LyULPT/ntfuyPbMQOy/T+NZWtA3wcdp+1zPerhh6acpAr47GP7PBdLYYq4y57dPhVqTu nzFtIKfYSOJG17mKAKg9+RC9C80O+4F729O5z6lZmIw1qAA9q4aWNWMeTNAJDZhKDYWE cLLQ== Received: by 10.217.1.79 with SMTP id m57mr6370947wes.121.1347910762020; Mon, 17 Sep 2012 12:39:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.96.2 with HTTP; Mon, 17 Sep 2012 12:39:01 -0700 (PDT) From: James M Snell Date: Mon, 17 Sep 2012 12:39:01 -0700 Message-ID: To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=20cf302077dc28beb904c9eaee4c Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: [apps-discuss] Early Initial Draft: JSON-Test (was Re: JSON Patch: extensibility) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 19:39:24 -0000 --20cf302077dc28beb904c9eaee4c Content-Type: text/plain; charset=UTF-8 Here is the early initial draft of JSON-Test ... this is not yet published as an I-D. I need to fill in some of the additional detail and examples around the basic predicate operations. However, the key elements are in place. I will try to get this published either tonight or tomorrow at the latest http://goo.gl/osKeI <== Links to my Github repo As always, feedback is more than welcome. - James On Mon, Sep 17, 2012 at 12:33 PM, Paul C. Bryan wrote: > ** > On Mon, 2012-09-17 at 17:32 +1000, Manger, James H wrote: > > The JSON patch spec looks good: draft-ietf-appsawg-json-patch-04. > > There is no explicit mention of extensibility of the JSON patch syntax. > Presumably new operations (beyond add/remove/replace/move/copy/test) could > be added, with the understanding that "old" implementations will reject > such documents [section 4 says an unknown operation is an error]. Adding > extra fields to an existing operation is less clear (eg > {"add":"/foo/1","value":"baz","repeat":10}). There is no explicit mention > that that would be an error. Perhaps implementations will ignore > unrecognized fields. > > > I had envisioned a container document type, which would enumerate a set of > conditions that must be met before processing the operations an associated > (contained) JSON Patch document. Taking this approach means that there is > no confusion over what's a JSON Patch document vs. the extension document > type. Since JSON Patch is an array of operation objects, such a structure > would remain relatively straightforward. > > More concretely, perhaps something like: > > { "tests": [ { "less-than": "/some/path", "value": 42 }, { "exists": "/some/other/path" }, { "not-exists": "/yet/another/path" }, > { "contains": "/foo/bar", "value": "Major-General" } ], "application/json-patch": [ { "replace": "/some/path", "value": 42 }, { "delete": "/some/other/path" }, { "add": "/yet/another/path", "value": "bar!" } ]} > > > Thoughts? > > > Could more sophisticated future test rules define, say, a "test2" > operation? Or is it the expectation that such a syntax would need a new > media type? > > > I would say any extension should require its own media type. > > > Each operation lists a full JSON pointer from the root of the resource. > If you want to replace a dozen fields in a deeply nested object you need to > repeat the path to that object a dozen times. This may be a reasonable > compromise to avoid a more complex patch structure (particularly if > compression removes much of the overhead), but I wasn't sure if any > alternative had been considered. For example, > {"patch":"/fee/fie/fo/fum/foo","value":[{"add":"x","value":"baz"},{"add":"y","value":3}]}. > > > We've considered alternatives in the past, but concluded that given the > verbosity of the JSON Patch document, the likely strategy to reduce size > would be through compression. As such, multiple similar paths would > compress fairly well. > > > Would I be opening a can of worms (or doing some bike-shedding) if I > asked why application/json-patch instead of application/patch+json? > > > Probably. I originally proposed application/patch+json. The main problem > with application/patch+json is that it implies that there are other > representations of application/patch, not just JSON (e.g. > application/patch+xml). In this case, JSON Patch is meant to address *only > * JSON documents in a JSON format. Furthermore, I'm not yet aware of a > specification for JSON like there is is for XML that promotes the addition > of +json. Therefore, I'd say that application/json-patch is probably the > better choice. > > Paul > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --20cf302077dc28beb904c9eaee4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here is the early initial draft of JSO= N-Test ... this is not yet published as an I-D. I need to fill in some of t= he additional detail and examples around the basic predicate operations. Ho= wever, the key elements are in place. I will try to get this published eith= er tonight or tomorrow at the latest

    =C2=A0 http://goo.gl/o= sKeI =C2=A0<=3D=3D Links to my Github repo

    As always, feedback= is more than welcome.

    - James


    On Mon, Sep 17, 2012 at 12:33 PM, P= aul C. Bryan <pbryan@anode.ca> wrote:
    =20 =20
    On Mon, 2012-09-17 at 17:32 +1000, Manger, James H wrote:
    The JSON patch spec looks good: draft-ietf-appsawg-json-patch-04.

    There is no explicit mention of extensibility of the JSON patch syntax.= Presumably new operations (beyond add/remove/replace/move/copy/test) could= be added, with the understanding that "old" implementations will= reject such documents [section 4 says an unknown operation is an error]. A= dding extra fields to an existing operation is less clear (eg {"add&qu= ot;:"/foo/1","value":"baz","repeat"= :10}). There is no explicit mention that that would be an error. Perhaps im= plementations will ignore unrecognized fields.

    I had envisioned a container document type, which would enumerate a set of = conditions that must be met before processing the operations an associated = (contained) JSON Patch document. Taking this approach means that there is n= o confusion over what's a JSON Patch document vs. the extension documen= t type. Since JSON Patch is an array of operation objects, such a structure= would remain relatively straightforward.

    More concretely, perhaps something like:

    {
=C2=A0=C2=A0=C2=A0 "tests": [
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "less-than": &qu=
ot;/some/path", "value": 42 },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "exists": "=
/some/other/path" },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "not-exists": &q=
uot;/yet/another/path" },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "contains": "/f=
oo/bar", "value": "Major-General" }
=C2=A0=C2=A0=C2=A0 ], "application/json-patch": [
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "replace": "=
;/some/path", "value": 42 },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "delete": "=
/some/other/path" },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "add": "/ye=
t/another/path", "value": "bar!" }
=C2=A0=C2=A0=C2=A0 ]
}

    Thoughts?


    Could more sophisticated future test rules define, say, a "test2&q= uot; operation? Or is it the expectation that such a syntax would need a ne= w media type?

    I would say any extension should require its own media type.


    Each operation lists a full JSON pointer from the root of the resource.= If you want to replace a dozen fields in a deeply nested object you need t= o repeat the path to that object a dozen times. This may be a reasonable co= mpromise to avoid a more complex patch structure (particularly if compressi= on removes much of the overhead), but I wasn't sure if any alternative = had been considered. For example, {"patch":"/fee/fie/fo/fum/= foo","value":[{"add":"x","value&quo= t;:"baz"},{"add":"y","value":3}]}.<= br>

    We've considered alternatives in the past, but concluded that given the= verbosity of the JSON Patch document, the likely strategy to reduce size w= ould be through compression. As such, multiple similar paths would compress= fairly well.


    Would I be opening a can of worms (or doing some bike-shedding) if I as= ked why application/json-patch instead of application/patch+json?

    Probably. I originally proposed application/patch+json. The main problem wi= th application/patch+json is that it implies that there are other represent= ations of application/patch, not just JSON (e.g. application/patch+xml). In= this case, JSON Patch is meant to address only JSON documents in a = JSON format. Furthermore, I'm not yet aware of a specification for JSON= like there is is for XML that promotes the addition of +json. Therefore, I= 'd say that application/json-patch is probably the better choice.

    Paul

    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss


    --20cf302077dc28beb904c9eaee4c-- From mnot@mnot.net Mon Sep 17 13:17:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6460221F8608 for ; Mon, 17 Sep 2012 13:17:26 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFPJyATEw-7M for ; Mon, 17 Sep 2012 13:17:25 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5A021E8037 for ; Mon, 17 Sep 2012 13:17:25 -0700 (PDT) Received: from [192.168.185.180] (unknown [67.159.191.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 222D9509EB; Mon, 17 Sep 2012 16:17:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: <1347909323.19756.12.camel@pbryan-wsl.internal.salesforce.com> Date: Mon, 17 Sep 2012 13:17:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120917062225.31160.89210.idtracker@ietfa.amsl.com> <1347909323.19756.12.camel@pbryan-wsl.internal.salesforce.com> To: Paul C. Bryan X-Mailer: Apple Mail (2.1486) Cc: Apps Discuss Subject: Re: [apps-discuss] New Version Notification for draft-ietf-appsawg-json-patch-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 20:17:26 -0000 Ah, sorry - I looked at the diffs before I released, but that slipped by = (will teach me to submit in an airport).=20 I'll re-release without it. Regards, On 17/09/2012, at 12:15 PM, Paul C. Bryan wrote: > By recommending we go with -03's test semantics, I was not endorsing = testing for presence. For my edification, could I know the case for = testing presence is? In other words, since most operations fail if a = value is not present, in what case would it be necessary to test for = presence before applying such operations? >=20 > Paul >=20 > On Mon, 2012-09-17 at 18:24 +1200, Mark Nottingham wrote: >> This draft incorporated some minor feedback from James and made a few = error conditions explicit. >>=20 >> With it -- assuming that the decision to keep "test" in as-is -- I = *think* we're ready for WGLC for both json-pointer and json-patch. >>=20 >> Cheers, >>=20 >>=20 >> Begin forwarded message: >>=20 >> > From:=20 >> internet-drafts@ietf.org >>=20 >> > Subject: New Version Notification for = draft-ietf-appsawg-json-patch-04.txt >> > Date: 17 September 2012 6:22:25 PM NZST >> > To:=20 >> mnot@mnot.net >>=20 >> > Cc:=20 >> pbryan@anode.ca >>=20 >> >=20 >> >=20 >> > A new version of I-D, draft-ietf-appsawg-json-patch-04.txt >> > has been successfully submitted by Mark Nottingham and posted to = the >> > IETF repository. >> >=20 >> > Filename: draft-ietf-appsawg-json-patch >> > Revision: 04 >> > Title: JSON Patch >> > Creation date: 2012-09-17 >> > WG ID: appsawg >> > Number of pages: 15 >> > URL: =20 >> = http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-04.txt >>=20 >> > Status: =20 >> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch >>=20 >> > Htmlized: =20 >> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04 >>=20 >> > Diff: =20 >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-patch-04 >>=20 >> >=20 >> > Abstract: >> > JSON Patch defines the media type "application/json-patch", a = JSON >> > document structure for expressing a sequence of operations to = apply >> > to a JSON document. >> >=20 >> >=20 >> >=20 >> >=20 >> > The IETF Secretariat >> >=20 >>=20 >> -- >> Mark Nottingham >>=20 >> http://www.mnot.net/ >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >>=20 >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 -- Mark Nottingham http://www.mnot.net/ From jasnell@gmail.com Mon Sep 17 13:30:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF2921E804B for ; Mon, 17 Sep 2012 13:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH4triUuqZpp for ; Mon, 17 Sep 2012 13:30:25 -0700 (PDT) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by ietfa.amsl.com (Postfix) with ESMTP id 440FC21E8047 for ; Mon, 17 Sep 2012 13:30:25 -0700 (PDT) Received: by weyr3 with SMTP id r3so4977638wey.22 for ; Mon, 17 Sep 2012 13:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=A+L1TmDQYfyt2LPbK+LqOEPUv3eIMiYfBBF/5bvHLvY=; b=kaXi/3NkT4oNGknapO+W6h1p8zZY6YZVA0BoVtxJGCTPRIct2fGnAyEcos7kWbpadq OcR8Bt14d0hzFlT3w4iCfoujiDDDJmMqHPPtQGdvz2xT4vmsBTIoSg+fbVERJ2gxI64v d2HhIxYOwcKohno+DXy2eRiqkeLUaB9gv9NRt8lFMgMNlGimlKgBYF0COvbA0K7HnSjq bWz5UOkdlZSR/5Vbcsu9Ym4xUJ/ZL4DB6KppKTQUYtabDhf2kgSZWhXB9okGQuvJ+75+ 1W5mdahSnisMKv8MMRt9sDWq5CANrKhbcqCx/DtTvY3xAQ1VaB+4ZFQlFSfz4CRC8tgH 2DtQ== Received: by 10.180.100.35 with SMTP id ev3mr18368768wib.7.1347913824194; Mon, 17 Sep 2012 13:30:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.96.2 with HTTP; Mon, 17 Sep 2012 13:30:03 -0700 (PDT) In-Reply-To: References: <20120917062225.31160.89210.idtracker@ietfa.amsl.com> <1347909323.19756.12.camel@pbryan-wsl.internal.salesforce.com> From: James M Snell Date: Mon, 17 Sep 2012 13:30:03 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=f46d044282a6add01604c9eba431 Cc: Apps Discuss Subject: Re: [apps-discuss] New Version Notification for draft-ietf-appsawg-json-patch-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 20:30:26 -0000 --f46d044282a6add01604c9eba431 Content-Type: text/plain; charset=UTF-8 Edge case question... the current description for "add" is not 100% clear for this case: Assume we have the following existing document... {"a":{}} And we provide... {"add":"/a/b/c", value:"foo"} Is this an error or will the operation create the entire path? Likewise with "move".. given {"a":{"b":{"c":"foo"}}} If I provide... {"move":"/a/b/c", to:"/x/y/z"} What happens if neither x or y currently exist? - James On Mon, Sep 17, 2012 at 1:17 PM, Mark Nottingham wrote: > Ah, sorry - I looked at the diffs before I released, but that slipped by > (will teach me to submit in an airport). > > I'll re-release without it. > > Regards, > > > On 17/09/2012, at 12:15 PM, Paul C. Bryan wrote: > > > By recommending we go with -03's test semantics, I was not endorsing > testing for presence. For my edification, could I know the case for testing > presence is? In other words, since most operations fail if a value is not > present, in what case would it be necessary to test for presence before > applying such operations? > > > > Paul > > > > On Mon, 2012-09-17 at 18:24 +1200, Mark Nottingham wrote: > >> This draft incorporated some minor feedback from James and made a few > error conditions explicit. > >> > >> With it -- assuming that the decision to keep "test" in as-is -- I > *think* we're ready for WGLC for both json-pointer and json-patch. > >> > >> Cheers, > >> > >> > >> Begin forwarded message: > >> > >> > From: > >> internet-drafts@ietf.org > >> > >> > Subject: New Version Notification for > draft-ietf-appsawg-json-patch-04.txt > >> > Date: 17 September 2012 6:22:25 PM NZST > >> > To: > >> mnot@mnot.net > >> > >> > Cc: > >> pbryan@anode.ca > >> > >> > > >> > > >> > A new version of I-D, draft-ietf-appsawg-json-patch-04.txt > >> > has been successfully submitted by Mark Nottingham and posted to the > >> > IETF repository. > >> > > >> > Filename: draft-ietf-appsawg-json-patch > >> > Revision: 04 > >> > Title: JSON Patch > >> > Creation date: 2012-09-17 > >> > WG ID: appsawg > >> > Number of pages: 15 > >> > URL: > >> > http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-04.txt > >> > >> > Status: > >> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch > >> > >> > Htmlized: > >> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04 > >> > >> > Diff: > >> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-patch-04 > >> > >> > > >> > Abstract: > >> > JSON Patch defines the media type "application/json-patch", a JSON > >> > document structure for expressing a sequence of operations to apply > >> > to a JSON document. > >> > > >> > > >> > > >> > > >> > The IETF Secretariat > >> > > >> > >> -- > >> Mark Nottingham > >> > >> http://www.mnot.net/ > >> > >> > >> > >> > >> > >> _______________________________________________ > >> apps-discuss mailing list > >> > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > -- > Mark Nottingham > http://www.mnot.net/ > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d044282a6add01604c9eba431 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Edge case question... the current desc= ription for "add" is not 100% clear for this case:

    Assume we have the following existing document...=

    =C2=A0 {"a":{}}

    And we provide...

    =C2=A0 {"add":"/a/b/c", valu= e:"foo"}
    Is this an error or will the oper= ation create the entire path?

    Likewis= e with "move".. given {"a":{"b":{"c"= ;:"foo"}}}

    If I provide...

    =C2=A0 {"move":"/a/b/c", to:"/x/y/z"}

    What happens if neither x or y currently exist?<= /font>

    - James


    On Mon, Sep 17, 2012 at 1:17 PM, = Mark Nottingham <mnot@mnot.net> wrote:
    Ah, sorry - I looked at the diffs before I released, but that slipped by (w= ill teach me to submit in an airport).

    I'll re-release without it.

    Regards,


    On 17/09/2012, at 12:15 PM, Paul C. Bryan <pbryan@anode.ca> wrote:

    > By recommending we go with -03's test semantics, I was not endorsi= ng testing for presence. For my edification, could I know the case for test= ing presence is? In other words, since most operations fail if a value is n= ot present, in what case would it be necessary to test for presence before = applying such operations?
    >
    > Paul
    >
    > On Mon, 2012-09-17 at 18:24 +1200, Mark Nottingham wrote:
    >> This draft incorporated some minor feedback from James and made a = few error conditions explicit.
    >>
    >> With it -- assuming that the decision to keep "test" in = as-is -- I *think* we're ready for WGLC for both json-pointer and json-= patch.
    >>
    >> Cheers,
    >>
    >>
    >> Begin forwarded message:
    >>
    >> > From:
    >> internet-drafts@ietf.o= rg
    >>
    >> > Subject: New Version Notification for draft-ietf-appsawg-json= -patch-04.txt
    >> > Date: 17 September 2012 6:22:25 PM NZST
    >> > To:
    >> mnot@mnot.net
    >>
    >> > Cc:
    >> pbryan@anode.ca
    >>
    >> >
    >> >
    >> > A new version of I-D, draft-ietf-appsawg-json-patch-04.txt >> > has been successfully submitted by Mark Nottingham and posted= to the
    >> > IETF repository.
    >> >
    >> > Filename: =C2=A0 draft-ietf-appsawg-json-patch
    >> > Revision: =C2=A0 04
    >> > Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0JSON P= atch
    >> > Creation date: =C2=A0 =C2=A0 =C2=A02012-09-17
    >> > WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0appsaw= g
    >> > Number of pages: 15
    >> > URL:
    >> http://www.ietf.org/internet-drafts/dr= aft-ietf-appsawg-json-patch-04.txt
    >>
    >> > Status:
    >> http://datatracker.ietf.org/doc/draft-ietf-appsaw= g-json-patch
    >>
    >> > Htmlized:
    >> http://tools.ietf.org/html/draft-ietf-appsawg-json-= patch-04
    >>
    >> > Diff:
    >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-appsawg-json-patch-04
    >>
    >> >
    >> > Abstract:
    >> > =C2=A0 JSON Patch defines the media type "application/js= on-patch", a JSON
    >> > =C2=A0 document structure for expressing a sequence of operat= ions to apply
    >> > =C2=A0 to a JSON document.
    >> >
    >> >
    >> >
    >> >
    >> > The IETF Secretariat
    >> >
    >>
    >> --
    >> Mark Nottingham
    >>
    >> http://www.mnot= .net/
    >>
    >>
    >>
    >>
    >>
    >> _______________________________________________
    >> apps-discuss mailing list
    >>
    >> apps-discuss@ietf.org=
    >> https://www.ietf.org/mailman/listinfo/apps-discuss
    >

    --
    Mark Nottingham
    http://www.mnot.net/=




    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss

    --f46d044282a6add01604c9eba431-- From pbryan@anode.ca Mon Sep 17 14:56:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2283821E8063 for ; Mon, 17 Sep 2012 14:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzU6vYPy7nA1 for ; Mon, 17 Sep 2012 14:56:11 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id B090C21E8053 for ; Mon, 17 Sep 2012 14:56:11 -0700 (PDT) Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 1A813648E; Mon, 17 Sep 2012 21:56:10 +0000 (UTC) From: "Paul C. Bryan" To: James M Snell In-Reply-To: References: <20120917062225.31160.89210.idtracker@ietfa.amsl.com> <1347909323.19756.12.camel@pbryan-wsl.internal.salesforce.com> Content-Type: multipart/alternative; boundary="=-biNs/3yp2D3CyLd20L2F" Date: Mon, 17 Sep 2012 14:56:08 -0700 Message-ID: <1347918968.19756.30.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] New Version Notification for draft-ietf-appsawg-json-patch-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 21:56:12 -0000 --=-biNs/3yp2D3CyLd20L2F Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Mon, 2012-09-17 at 13:30 -0700, James M Snell wrote: > Edge case question... the current description for "add" is not 100% > clear for this case: > > > > Assume we have the following existing document... > > > {"a":{}} > > > And we provide... > > > {"add":"/a/b/c", value:"foo"} > > > Is this an error or will the operation create the entire path? My original intent was for this to be an error condition, though I agree the current language makes it unclear. > Likewise with "move".. given {"a":{"b":{"c":"foo"}}} > > > If I provide... > > > {"move":"/a/b/c", to:"/x/y/z"} > > > What happens if neither x or y currently exist? Likewise, was intended to be an error condition. Paul --=-biNs/3yp2D3CyLd20L2F Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 2012-09-17 at 13:30 -0700, James M Snell wrote:
    Edge case question... the current description for "add" is not 100% clear for this case:


    Assume we have the following existing document...


      {"a":{}}


    And we provide...


      {"add":"/a/b/c", value:"foo"}


    Is this an error or will the operation create the entire path?

    My original intent was for this to be an error condition, though I agree the current language makes it unclear.

    Likewise with "move".. given {"a":{"b":{"c":"foo"}}}


    If I provide...


      {"move":"/a/b/c", to:"/x/y/z"}


    What happens if neither x or y currently exist?

    Likewise, was intended to be an error condition.

    Paul
    --=-biNs/3yp2D3CyLd20L2F-- From martin.thomson@gmail.com Mon Sep 17 15:15:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83C421F8717 for ; Mon, 17 Sep 2012 15:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.737 X-Spam-Level: X-Spam-Status: No, score=-3.737 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iicZ7II-E2U3 for ; Mon, 17 Sep 2012 15:15:36 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 75E9021F8716 for ; Mon, 17 Sep 2012 15:15:35 -0700 (PDT) Received: by lbbgf7 with SMTP id gf7so5819911lbb.22 for ; Mon, 17 Sep 2012 15:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IeyWQj+tpDkH1CP0Hh8SQbRV9Me8L4H9CaEuJAHJxkA=; b=X6b1AEgJs+bU28+FwqBW8bTeUNGTkyfYsAh+6urJy5RhxuQW4nywJqtz76yKhdyCVw vJ6NiWoTkv0KoFIRhU4xz9CyGEoX4tuzKijXcZT5QUC6ETXKuJ2FOk2t00KXQmlyS7iX KVRoNfEbDk6GSkgtZ6ZRQOW1oMODvbuKjzB6lGCkMH8bGpZftNOo4x1oTksXIBeODK54 rZdRy1P/oQsOTOiq9DycB5vKvgmy+g+tMA0GxuK3QHXkZi+hnjyYXICp77kX20fXziEM sY3+c3cqIZRvlCpxY97ZYlFODG8tlkjcWUA59bu+Zg3V+VvNV/u8rJ9wuH8c6vtOWiP9 ZX/Q== MIME-Version: 1.0 Received: by 10.152.106.81 with SMTP id gs17mr11137576lab.2.1347920133038; Mon, 17 Sep 2012 15:15:33 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Mon, 17 Sep 2012 15:15:33 -0700 (PDT) In-Reply-To: References: <20120917062225.31160.89210.idtracker@ietfa.amsl.com> Date: Mon, 17 Sep 2012 15:15:33 -0700 Message-ID: From: Martin Thomson To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-patch-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 22:15:37 -0000 Reading the description of "move", I can infer that the intent is to specify the name of the node such that, olddoc#{move} == newdoc#{to} This is unlike other "move" or "mv" commands where you are able to identify a container as the target of a move. old: { "a": { "b": "foo" } } patch: { "move": "/a/b", "to": "/" } new: { "a": {}, "b":"foo" } I assume that it is entirely intentional that this is not supported, but it would be nice to clarify that this is not a feature that is provided. --Martin On 16 September 2012 23:24, Mark Nottingham wrote: > This draft incorporated some minor feedback from James and made a few error conditions explicit. > > With it -- assuming that the decision to keep "test" in as-is -- I *think* we're ready for WGLC for both json-pointer and json-patch. > > Cheers, > > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-ietf-appsawg-json-patch-04.txt >> Date: 17 September 2012 6:22:25 PM NZST >> To: mnot@mnot.net >> Cc: pbryan@anode.ca >> >> >> A new version of I-D, draft-ietf-appsawg-json-patch-04.txt >> has been successfully submitted by Mark Nottingham and posted to the >> IETF repository. >> >> Filename: draft-ietf-appsawg-json-patch >> Revision: 04 >> Title: JSON Patch >> Creation date: 2012-09-17 >> WG ID: appsawg >> Number of pages: 15 >> URL: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-04.txt >> Status: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch >> Htmlized: http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-patch-04 >> >> Abstract: >> JSON Patch defines the media type "application/json-patch", a JSON >> document structure for expressing a sequence of operations to apply >> to a JSON document. >> >> >> >> >> The IETF Secretariat >> > > -- > Mark Nottingham > http://www.mnot.net/ > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From pbryan@anode.ca Mon Sep 17 15:21:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D757B21F8628 for ; Mon, 17 Sep 2012 15:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+qIwTu61Y1a for ; Mon, 17 Sep 2012 15:21:17 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id DF95621F851C for ; Mon, 17 Sep 2012 15:21:16 -0700 (PDT) Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 3669B648E; Mon, 17 Sep 2012 22:21:16 +0000 (UTC) From: "Paul C. Bryan" To: Martin Thomson In-Reply-To: References: <20120917062225.31160.89210.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="=-z38L14AmHPfFGG61lwbf" Date: Mon, 17 Sep 2012 15:21:15 -0700 Message-ID: <1347920475.19756.39.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-patch-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 22:21:17 -0000 --=-z38L14AmHPfFGG61lwbf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Mon, 2012-09-17 at 15:15 -0700, Martin Thomson wrote: > Reading the description of "move", I can infer that the intent is to > specify the name of the node such that, olddoc#{move} == newdoc#{to} > > This is unlike other "move" or "mv" commands where you are able to > identify a container as the target of a move. > > old: > { "a": { "b": "foo" } } > patch: > { "move": "/a/b", "to": "/" } > new: > { "a": {}, "b":"foo" } This attempt at the "move" operation above will fail because there is already a value at "/", namely an object containing a sole "a" member. > I assume that it is entirely intentional that this is not supported, > but it would be nice to clarify that this is not a feature that is > provided. Not only is it entirely intentional that it's not supported, it's actually documented as such. To wit in §4.4: "If the location in the 'to' member references a member of an existing object in the target document, it is an error condition if a value at the specified location already exists..." Hence, it will fail as indicated above. Paul > > --Martin > > On 16 September 2012 23:24, Mark Nottingham wrote: > > This draft incorporated some minor feedback from James and made a few error conditions explicit. > > > > With it -- assuming that the decision to keep "test" in as-is -- I *think* we're ready for WGLC for both json-pointer and json-patch. > > > > Cheers, > > > > > > Begin forwarded message: > > > >> From: internet-drafts@ietf.org > >> Subject: New Version Notification for draft-ietf-appsawg-json-patch-04.txt > >> Date: 17 September 2012 6:22:25 PM NZST > >> To: mnot@mnot.net > >> Cc: pbryan@anode.ca > >> > >> > >> A new version of I-D, draft-ietf-appsawg-json-patch-04.txt > >> has been successfully submitted by Mark Nottingham and posted to the > >> IETF repository. > >> > >> Filename: draft-ietf-appsawg-json-patch > >> Revision: 04 > >> Title: JSON Patch > >> Creation date: 2012-09-17 > >> WG ID: appsawg > >> Number of pages: 15 > >> URL: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-04.txt > >> Status: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch > >> Htmlized: http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04 > >> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-patch-04 > >> > >> Abstract: > >> JSON Patch defines the media type "application/json-patch", a JSON > >> document structure for expressing a sequence of operations to apply > >> to a JSON document. > >> > >> > >> > >> > >> The IETF Secretariat > >> > > > > -- > > Mark Nottingham > > http://www.mnot.net/ > > > > > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-z38L14AmHPfFGG61lwbf Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 2012-09-17 at 15:15 -0700, Martin Thomson wrote: 
    Reading the description of "move", I can infer that the intent is to
specify the name of the node such that, olddoc#{move} == newdoc#{to}

This is unlike other "move" or "mv" commands where you are able to
identify a container as the target of a move.

old:
  { "a": { "b": "foo" } }
patch:
  { "move": "/a/b", "to": "/" }
new:
  { "a": {}, "b":"foo" }

    This attempt at the "move" operation above will fail because there is already a value at "/", namely an object containing a sole "a" member.

    I assume that it is entirely intentional that this is not supported,
but it would be nice to clarify that this is not a feature that is
provided.

    Not only is it entirely intentional that it's not supported, it's actually documented as such. To wit in §4.4:

    "If the location in the 'to' member references a member of an existing object in the target document, it is an error condition if a value at the specified location already exists..." Hence, it will fail as indicated above.

    Paul

    
--Martin

On 16 September 2012 23:24, Mark Nottingham <mnot@mnot.net> wrote:
> This draft incorporated some minor feedback from James and made a few error conditions explicit.
>
> With it -- assuming that the decision to keep "test" in as-is -- I *think* we're ready for WGLC for both json-pointer and json-patch.
>
> Cheers,
>
>
> Begin forwarded message:
>
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for draft-ietf-appsawg-json-patch-04.txt
>> Date: 17 September 2012 6:22:25 PM NZST
>> To: mnot@mnot.net
>> Cc: pbryan@anode.ca
>>
>>
>> A new version of I-D, draft-ietf-appsawg-json-patch-04.txt
>> has been successfully submitted by Mark Nottingham and posted to the
>> IETF repository.
>>
>> Filename:      draft-ietf-appsawg-json-patch
>> Revision:      04
>> Title:                 JSON Patch
>> Creation date:         2012-09-17
>> WG ID:                 appsawg
>> Number of pages: 15
>> URL:             http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-04.txt
>> Status:          http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch
>> Htmlized:        http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04
>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-patch-04
>>
>> Abstract:
>>   JSON Patch defines the media type "application/json-patch", a JSON
>>   document structure for expressing a sequence of operations to apply
>>   to a JSON document.
>>
>>
>>
>>
>> The IETF Secretariat
>>
>
> --
> Mark Nottingham
> http://www.mnot.net/
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

    --=-z38L14AmHPfFGG61lwbf-- From pbryan@anode.ca Mon Sep 17 15:50:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F0021E808C for ; Mon, 17 Sep 2012 15:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKsAImUXboot for ; Mon, 17 Sep 2012 15:50:24 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id AD65521E8063 for ; Mon, 17 Sep 2012 15:50:24 -0700 (PDT) Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id D07F5616A; Mon, 17 Sep 2012 22:50:23 +0000 (UTC) From: "Paul C. Bryan" To: Martin Thomson In-Reply-To: <1347920475.19756.39.camel@pbryan-wsl.internal.salesforce.com> References: <20120917062225.31160.89210.idtracker@ietfa.amsl.com> <1347920475.19756.39.camel@pbryan-wsl.internal.salesforce.com> Content-Type: multipart/alternative; boundary="=-xy3mR09WgNr/tqnYM4+8" Date: Mon, 17 Sep 2012 15:50:22 -0700 Message-ID: <1347922222.19756.67.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-patch-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 22:50:26 -0000 --=-xy3mR09WgNr/tqnYM4+8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Okay, I take it back; I was referring to an object, which root cannot be inferred to be. So we have a hole where the root value of the document is neither an array nor an object; it's merely a value. Perhaps language stating that the root is an invalid "to" target, because it always exists. Paul On Mon, 2012-09-17 at 15:21 -0700, Paul C. Bryan wrote: > On Mon, 2012-09-17 at 15:15 -0700, Martin Thomson wrote: > > > Reading the description of "move", I can infer that the intent is to > > specify the name of the node such that, olddoc#{move} == newdoc#{to} > > > > This is unlike other "move" or "mv" commands where you are able to > > identify a container as the target of a move. > > > > old: > > { "a": { "b": "foo" } } > > patch: > > { "move": "/a/b", "to": "/" } > > new: > > { "a": {}, "b":"foo" } > > > This attempt at the "move" operation above will fail because there is > already a value at "/", namely an object containing a sole "a" member. > > > > I assume that it is entirely intentional that this is not supported, > > but it would be nice to clarify that this is not a feature that is > > provided. > > > Not only is it entirely intentional that it's not supported, it's > actually documented as such. To wit in §4.4: > > "If the location in the 'to' member references a member of an existing > object in the target document, it is an error condition if a value at > the specified location already exists..." Hence, it will fail as > indicated above. > > Paul > > > > > > --Martin > > > > On 16 September 2012 23:24, Mark Nottingham wrote: > > > This draft incorporated some minor feedback from James and made a few error conditions explicit. > > > > > > With it -- assuming that the decision to keep "test" in as-is -- I *think* we're ready for WGLC for both json-pointer and json-patch. > > > > > > Cheers, > > > > > > > > > Begin forwarded message: > > > > > >> From: internet-drafts@ietf.org > > >> Subject: New Version Notification for draft-ietf-appsawg-json-patch-04.txt > > >> Date: 17 September 2012 6:22:25 PM NZST > > >> To: mnot@mnot.net > > >> Cc: pbryan@anode.ca > > >> > > >> > > >> A new version of I-D, draft-ietf-appsawg-json-patch-04.txt > > >> has been successfully submitted by Mark Nottingham and posted to the > > >> IETF repository. > > >> > > >> Filename: draft-ietf-appsawg-json-patch > > >> Revision: 04 > > >> Title: JSON Patch > > >> Creation date: 2012-09-17 > > >> WG ID: appsawg > > >> Number of pages: 15 > > >> URL: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-04.txt > > >> Status: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch > > >> Htmlized: http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04 > > >> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-patch-04 > > >> > > >> Abstract: > > >> JSON Patch defines the media type "application/json-patch", a JSON > > >> document structure for expressing a sequence of operations to apply > > >> to a JSON document. > > >> > > >> > > >> > > >> > > >> The IETF Secretariat > > >> > > > > > > -- > > > Mark Nottingham > > > http://www.mnot.net/ > > > > > > > > > > > > > > > _______________________________________________ > > > apps-discuss mailing list > > > apps-discuss@ietf.org > > > https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-xy3mR09WgNr/tqnYM4+8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Okay, I take it back; I was referring to an object, which root cannot be inferred to be. So we have a hole where the root value of the document is neither an array nor an object; it's merely a value. Perhaps language stating that the root is an invalid "to" target, because it always exists.

    Paul

    On Mon, 2012-09-17 at 15:21 -0700, Paul C. Bryan wrote:
    On Mon, 2012-09-17 at 15:15 -0700, Martin Thomson wrote: 
    Reading the description of "move", I can infer that the intent is to
specify the name of the node such that, olddoc#{move} == newdoc#{to}

This is unlike other "move" or "mv" commands where you are able to
identify a container as the target of a move.

old:
  { "a": { "b": "foo" } }
patch:
  { "move": "/a/b", "to": "/" }
new:
  { "a": {}, "b":"foo" }

    This attempt at the "move" operation above will fail because there is already a value at "/", namely an object containing a sole "a" member.

    I assume that it is entirely intentional that this is not supported,
but it would be nice to clarify that this is not a feature that is
provided.

    Not only is it entirely intentional that it's not supported, it's actually documented as such. To wit in §4.4:

    "If the location in the 'to' member references a member of an existing object in the target document, it is an error condition if a value at the specified location already exists..." Hence, it will fail as indicated above.

    Paul

    
--Martin

On 16 September 2012 23:24, Mark Nottingham <mnot@mnot.net> wrote:
> This draft incorporated some minor feedback from James and made a few error conditions explicit.
>
> With it -- assuming that the decision to keep "test" in as-is -- I *think* we're ready for WGLC for both json-pointer and json-patch.
>
> Cheers,
>
>
> Begin forwarded message:
>
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for draft-ietf-appsawg-json-patch-04.txt
>> Date: 17 September 2012 6:22:25 PM NZST
>> To: mnot@mnot.net
>> Cc: pbryan@anode.ca
>>
>>
>> A new version of I-D, draft-ietf-appsawg-json-patch-04.txt
>> has been successfully submitted by Mark Nottingham and posted to the
>> IETF repository.
>>
>> Filename:      draft-ietf-appsawg-json-patch
>> Revision:      04
>> Title:                 JSON Patch
>> Creation date:         2012-09-17
>> WG ID:                 appsawg
>> Number of pages: 15
>> URL:             http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-04.txt
>> Status:          http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch
>> Htmlized:        http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04
>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-patch-04
>>
>> Abstract:
>>   JSON Patch defines the media type "application/json-patch", a JSON
>>   document structure for expressing a sequence of operations to apply
>>   to a JSON document.
>>
>>
>>
>>
>> The IETF Secretariat
>>
>
> --
> Mark Nottingham
> http://www.mnot.net/
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


    _______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

    --=-xy3mR09WgNr/tqnYM4+8-- From jasnell@gmail.com Mon Sep 17 16:35:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52AD21E80A3 for ; Mon, 17 Sep 2012 16:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1iDrC1Odp-x for ; Mon, 17 Sep 2012 16:35:48 -0700 (PDT) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC2621E80A2 for ; Mon, 17 Sep 2012 16:35:48 -0700 (PDT) Received: by weyr3 with SMTP id r3so5063034wey.22 for ; Mon, 17 Sep 2012 16:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TAn9+d8d32iecTnYxy8+AZDB/uyRu5p8L8QFhfTbY14=; b=oI8rCQHZKEtTGBIR3Xzsm8ewyfFLejwmSnmVuSy+1MB7Z3VU9NSg46dOka04L2frzO CYLX2bgJQYqFw5aQFborSO2u52enxk2Du6QFNBrnJrY88CU1NbGpPSwnJWRax3nvs1sg ljlfEGOanEf7JJGkbt9fVw8JxpjnHR3dS3dZCV+IeFxNy3KMEPgVlp6vP9p8H1SFzd0D 4zVRJqGylMaTUYX5UGlpOBkGZ1YXYFRyVG09RRakslVEL/kG2559WZfaX3PM3pEu+/Ck awF1eKyqe7wJ0YFYnYXxuUMNrSF+w1Y7HOKLvVfweAB8qQsVpBSXccIVEGBMO8KJ2XCA 7dZw== Received: by 10.217.1.79 with SMTP id m57mr6616961wes.121.1347924947195; Mon, 17 Sep 2012 16:35:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.96.2 with HTTP; Mon, 17 Sep 2012 16:35:26 -0700 (PDT) In-Reply-To: <1347922222.19756.67.camel@pbryan-wsl.internal.salesforce.com> References: <20120917062225.31160.89210.idtracker@ietfa.amsl.com> <1347920475.19756.39.camel@pbryan-wsl.internal.salesforce.com> <1347922222.19756.67.camel@pbryan-wsl.internal.salesforce.com> From: James M Snell Date: Mon, 17 Sep 2012 16:35:26 -0700 Message-ID: To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=20cf302077dca9575a04c9ee3b43 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-patch-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 23:35:49 -0000 --20cf302077dca9575a04c9ee3b43 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1... root never makes sense as a move to target. If the intent is to alter the root element, use "replace" instead. On Mon, Sep 17, 2012 at 3:50 PM, Paul C. Bryan wrote: > ** > Okay, I take it back; I was referring to an object, which root cannot be > inferred to be. So we have a hole where the root value of the document is > neither an array nor an object; it's merely a value. Perhaps language > stating that the root is an invalid "to" target, because it always exists= . > > Paul > > On Mon, 2012-09-17 at 15:21 -0700, Paul C. Bryan wrote: > > On Mon, 2012-09-17 at 15:15 -0700, Martin Thomson wrote: > > Reading the description of "move", I can infer that the intent is to > specify the name of the node such that, olddoc#{move} =3D=3D newdoc#{to} > > This is unlike other "move" or "mv" commands where you are able to > identify a container as the target of a move. > > old: > { "a": { "b": "foo" } } > patch: > { "move": "/a/b", "to": "/" } > new: > { "a": {}, "b":"foo" } > > > This attempt at the "move" operation above will fail because there is > already a value at "/", namely an object containing a sole "a" member. > > I assume that it is entirely intentional that this is not supported, > but it would be nice to clarify that this is not a feature that is > provided. > > > Not only is it entirely intentional that it's not supported, it's actuall= y > documented as such. To wit in =C2=A74.4: > > "If the location in the 'to' member references a member of an existing > object in the target document, it is an error condition if a value at the > specified location already exists..." Hence, it will fail as indicated > above. > > Paul > > --Martin > > On 16 September 2012 23:24, Mark Nottingham wrote: > > This draft incorporated some minor feedback from James and made a few e= rror conditions explicit. > > > > With it -- assuming that the decision to keep "test" in as-is -- I *thi= nk* we're ready for WGLC for both json-pointer and json-patch. > > > > Cheers, > > > > > > Begin forwarded message: > > > >> From: internet-drafts@ietf.org > >> Subject: New Version Notification for draft-ietf-appsawg-json-patch-04= .txt > >> Date: 17 September 2012 6:22:25 PM NZST > >> To: mnot@mnot.net > >> Cc: pbryan@anode.ca > >> > >> > >> A new version of I-D, draft-ietf-appsawg-json-patch-04.txt > >> has been successfully submitted by Mark Nottingham and posted to the > >> IETF repository. > >> > >> Filename: draft-ietf-appsawg-json-patch > >> Revision: 04 > >> Title: JSON Patch > >> Creation date: 2012-09-17 > >> WG ID: appsawg > >> Number of pages: 15 > >> URL: http://www.ietf.org/internet-drafts/draft-ietf-appsaw= g-json-patch-04.txt > >> Status: http://datatracker.ietf.org/doc/draft-ietf-appsawg-js= on-patch > >> Htmlized: http://tools.ietf.org/html/draft-ietf-appsawg-json-pa= tch-04 > >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg= -json-patch-04 > >> > >> Abstract: > >> JSON Patch defines the media type "application/json-patch", a JSON > >> document structure for expressing a sequence of operations to apply > >> to a JSON document. > >> > >> > >> > >> > >> The IETF Secretariat > >> > > > > -- > > Mark Nottingham > > http://www.mnot.net/ > > > > > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ > apps-discuss mailing listapps-discuss@ietf.orghttps://www.ietf.org/mailma= n/listinfo/apps-discuss > > > _______________________________________________ > apps-discuss mailing listapps-discuss@ietf.orghttps://www.ietf.org/mailma= n/listinfo/apps-discuss > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --20cf302077dca9575a04c9ee3b43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1... root never makes sense as a move= to target. If the intent is to alter the root element, use "replace&q= uot; instead.

    On Mon, Sep 17, 201= 2 at 3:50 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
    =20 =20
    Okay, I take it back; I was referring to an object, which root cannot be in= ferred to be. So we have a hole where the root value of the document is nei= ther an array nor an object; it's merely a value. Perhaps language stat= ing that the root is an invalid "to" target, because it always ex= ists.

    Paul

    On Mon, 2012-09-17 at 15:21 -0700, Paul C. Bryan wrote:
    On Mon, 2012-09-17 at 15:15 -0700, Martin Thomson wrote:=20 
    Reading the description of "move", I can infer that the inte=
nt is to
specify the name of the node such that, olddoc#{move} =3D=3D newdoc#{to}

This is unlike other "move" or "mv" commands where you =
are able to
identify a container as the target of a move.

old:
  { "a": { "b": "foo" } }
patch:
  { "move": "/a/b", "to": "/" }
new:
=C2=A0 { "a": {}, "b":"foo" }

    This attempt at the "move" operation above will fail because = there is already a value at "/", namely an object containing a so= le "a" member.

    I assume that it is entirely intentional that this is not supported,
but it would be nice to clarify that this is not a feature that is
provided.

    Not only is it entirely intentional that it's not supported, it'= ;s actually documented as such. To wit in =C2=A74.4:

    "If the location in the 'to' member references a member of= an existing object in the target document, it is an error condition if a v= alue at the specified location already exists..." Hence, it will fail = as indicated above.

    Paul

    --Martin

On 16 September 2012 23:24, Mark Nottingham <mnot@mnot.net> wrote:
> This draft incorporated some minor feedback from James and made a few =
error conditions explicit.
>
> With it -- assuming that the decision to keep "test" in as-i=
s -- I *think* we're ready for WGLC for both json-pointer and json-patc=
h.
>
> Cheers,
>
>
> Begin forwarded message:
>
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for draft-ietf-appsawg-json-patc=
h-04.txt
>> Date: 17 September 2012 6:22:25 PM NZST
>> To: mnot@mnot.n=
et
>> Cc: pbryan@an=
ode.ca
>>
>>
>> A new version of I-D, draft-ietf-appsawg-json-patch-04.txt
>> has been successfully submitted by Mark Nottingham and posted to t=
he
>> IETF repository.
>>
>> Filename:      draft-ietf-appsawg-json-patch
>> Revision:      04
>> Title:                 JSON Patch
>> Creation date:         2012-09-17
>> WG ID:                 appsawg
>> Number of pages: 15
>> URL:             http://www.ietf.org/i=
nternet-drafts/draft-ietf-appsawg-json-patch-04.txt
>> Status:          http://datatracker.ietf.org/doc/=
draft-ietf-appsawg-json-patch
>> Htmlized:        http://tools.ietf.org/html/draft-i=
etf-appsawg-json-patch-04
>> Diff:            http://www.ietf.org/rfcdif=
f?url2=3Ddraft-ietf-appsawg-json-patch-04
>>
>> Abstract:
>>   JSON Patch defines the media type "application/json-patch&q=
uot;, a JSON
>>   document structure for expressing a sequence of operations to ap=
ply
>>   to a JSON document.
>>
>>
>>
>>
>> The IETF Secretariat
>>
>
> --
> Mark Nottingham
> http://www.mnot.net=
/
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discus=
s@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
_______________________________________________
apps-discuss mailing list
apps-discuss@iet=
f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


    _______________________________________________
apps-discuss mailing list
apps-discuss@iet=
f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss


    --20cf302077dca9575a04c9ee3b43-- From jasnell@gmail.com Mon Sep 17 16:57:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE1121E809E for ; Mon, 17 Sep 2012 16:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMV2Yho+m9Ja for ; Mon, 17 Sep 2012 16:57:12 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2081821E804A for ; Mon, 17 Sep 2012 16:57:11 -0700 (PDT) Received: by weyx48 with SMTP id x48so1063790wey.31 for ; Mon, 17 Sep 2012 16:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=r4RYhr84ahgaodxnV4BL3uam+r0U6TlXwAeWYigafLc=; b=qk6eUw2MakRl3eSFiKZsy3cpq1MeyiSD+vHsmC46J0I4CEK/UqGQ5oka29A6EzT61d 0yNl+knnJ5oWlEXXsx6txrmC0xs8G0oHx68EV1XsuRc49KtjOXlpWT5ab1ZOfpoIMWeA PWx7lscQPFsEl5bSyIWqzWf/jN3d9PrIX31H+oGY9vtf4JjHcwqbZY5ZFTkVXycrT4ZY u84WrVbAZRLBrZWDkEEcFSab/N+Ze7K+3P0sfgSgJiwKOvsgyNmgjJG3PrgGq4GZhu4f 5VfB+HgAFDHWksxFlgA3VKSfkBnlpWlGycn/+ticmiLCSqj30+E0BtPLSqBquIig+3ww L5jA== Received: by 10.180.90.104 with SMTP id bv8mr19179881wib.22.1347926230916; Mon, 17 Sep 2012 16:57:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.96.2 with HTTP; Mon, 17 Sep 2012 16:56:50 -0700 (PDT) In-Reply-To: References: From: James M Snell Date: Mon, 17 Sep 2012 16:56:50 -0700 Message-ID: To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=f46d043c7f382d5f5604c9ee8883 Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Early Initial Draft: JSON-Test (was Re: JSON Patch: extensibility) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 23:57:13 -0000 --f46d043c7f382d5f5604c9ee8883 Content-Type: text/plain; charset=UTF-8 Ok.. working through some possible ways of manifesting the predicate operations within a JSON-Patch context... there are two possible options that I see... (A) One is to use something like the example syntax Paul suggests in his previous note... { "tests": [ { "less-than": "/some/path", "value": 42 }, { "test": "/some/other/path" }, { "contains": "/foo/bar", "value": "Major-General" } ], "application/json-patch": [ { "replace": "/some/path", "value": 42 }, { "delete": "/some/other/path" }, { "add": "/yet/another/path", "value": "bar!" } ] } (B) Another is to introduce an optional "predicate" member on the JSON-Patch "test" operation, such that a "test" operation would only succeed if, and only if, the attached predicate evaluates true: [ {"test": "/", "predicate": { "and": [ { "less-than": "/some/path", "value": 42 }, { "test": "/some/other/path" }, { "contains": "/foo/bar", "value": "Major-General" } ] } }, { "replace": "/some/path", "value": 42 }, { "delete": "/some/other/path" }, { "add": "/yet/another/path", "value": "bar!" } ] Running through the various cases, option (B) seems to be a cleaner mapping overall. Note that in this case, the JSON-Pointer value specified by the "test" member identifies the base reference point for the predicate. One of the main reasons I prefer (B) is that it allows me a clean way of interpolating predicate checks throughout the patch document. Option (B) also allows us to get by without necessarily creating a new base document type and media type. Thoughts? - James On Mon, Sep 17, 2012 at 12:39 PM, James M Snell wrote: > Here is the early initial draft of JSON-Test ... this is not yet published > as an I-D. I need to fill in some of the additional detail and examples > around the basic predicate operations. However, the key elements are in > place. I will try to get this published either tonight or tomorrow at the > latest > > http://goo.gl/osKeI <== Links to my Github repo > > As always, feedback is more than welcome. > > - James > > > On Mon, Sep 17, 2012 at 12:33 PM, Paul C. Bryan wrote: > >> ** >> On Mon, 2012-09-17 at 17:32 +1000, Manger, James H wrote: >> >> The JSON patch spec looks good: draft-ietf-appsawg-json-patch-04. >> >> There is no explicit mention of extensibility of the JSON patch syntax. >> Presumably new operations (beyond add/remove/replace/move/copy/test) could >> be added, with the understanding that "old" implementations will reject >> such documents [section 4 says an unknown operation is an error]. Adding >> extra fields to an existing operation is less clear (eg >> {"add":"/foo/1","value":"baz","repeat":10}). There is no explicit mention >> that that would be an error. Perhaps implementations will ignore >> unrecognized fields. >> >> >> I had envisioned a container document type, which would enumerate a set >> of conditions that must be met before processing the operations an >> associated (contained) JSON Patch document. Taking this approach means that >> there is no confusion over what's a JSON Patch document vs. the extension >> document type. Since JSON Patch is an array of operation objects, such a >> structure would remain relatively straightforward. >> >> More concretely, perhaps something like: >> >> { "tests": [ { "less-than": "/some/path", "value": 42 }, { "exists": "/some/other/path" }, { "not-exists": "/yet/another/path" }, >> { "contains": "/foo/bar", "value": "Major-General" } ], "application/json-patch": [ { "replace": "/some/path", "value": 42 }, { "delete": "/some/other/path" }, { "add": "/yet/another/path", "value": "bar!" } ]} >> >> >> Thoughts? >> >> >> Could more sophisticated future test rules define, say, a "test2" >> operation? Or is it the expectation that such a syntax would need a new >> media type? >> >> >> I would say any extension should require its own media type. >> >> >> Each operation lists a full JSON pointer from the root of the resource. >> If you want to replace a dozen fields in a deeply nested object you need to >> repeat the path to that object a dozen times. This may be a reasonable >> compromise to avoid a more complex patch structure (particularly if >> compression removes much of the overhead), but I wasn't sure if any >> alternative had been considered. For example, >> {"patch":"/fee/fie/fo/fum/foo","value":[{"add":"x","value":"baz"},{"add":"y","value":3}]}. >> >> >> We've considered alternatives in the past, but concluded that given the >> verbosity of the JSON Patch document, the likely strategy to reduce size >> would be through compression. As such, multiple similar paths would >> compress fairly well. >> >> >> Would I be opening a can of worms (or doing some bike-shedding) if I >> asked why application/json-patch instead of application/patch+json? >> >> >> Probably. I originally proposed application/patch+json. The main problem >> with application/patch+json is that it implies that there are other >> representations of application/patch, not just JSON (e.g. >> application/patch+xml). In this case, JSON Patch is meant to address * >> only* JSON documents in a JSON format. Furthermore, I'm not yet aware of >> a specification for JSON like there is is for XML that promotes the >> addition of +json. Therefore, I'd say that application/json-patch is >> probably the better choice. >> >> Paul >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d043c7f382d5f5604c9ee8883 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ok.. working through some possible way= s of manifesting the predicate operations within a JSON-Patch context... th= ere are two possible options that I see...=C2=A0

    (A) One is to use so= mething like the example syntax Paul suggests in his previous note...

    =C2=A0 {
    =C2=A0 =C2=A0 "tests": [
    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 { "less-than": "/some/path", "va= lue": 42 },
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "test": = "/some/other/path" },
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { &qu= ot;contains": "/foo/bar", "value": "Major-Gen= eral" }
    =C2=A0 =C2=A0 ], "application/json-patch": [
    =C2= =A0 =C2=A0 =C2=A0 =C2=A0 { "replace": "/some/path", &qu= ot;value": 42 },
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "delete&= quot;: "/some/other/path" },
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "add": "/yet/another/path"= ;, "value": "bar!" }
    =C2=A0 =C2=A0 ]
    =C2=A0 }

    (B) Another is to introduce an optional= "predicate" member on the JSON-Patch "test" operation,= such that a "test" operation would only succeed if, and only if,= the attached predicate evaluates true:

    =C2=A0 [
    =C2=A0 =C2=A0 {"test": &qu= ot;/",
    =C2=A0 =C2=A0 =C2=A0"predicate": {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0"and": [
    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 { "less-than": "/some/path", "va= lue": 42 },
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "test": "/some/other/path= " },
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "contains": &qu= ot;/foo/bar", "value": "Major-General" }
    =C2=A0 =C2=A0 =C2=A0 =C2=A0]
    =C2=A0 =C2=A0 =C2=A0}
    =C2=A0 =C2=A0 },
    =C2=A0 =C2=A0 { "replace": "/some/path&quo= t;, "value": 42 },
    =C2=A0 =C2=A0 { "delete": "/some/other/pat= h" },
    =C2=A0 =C2=A0 { "add": = "/yet/another/path", "value": "bar!" }=C2=A0 = =C2=A0=C2=A0
    =C2=A0 ]

    Running through th= e various cases, option (B) seems to be a cleaner mapping overall. Note tha= t in this case, the JSON-Pointer value specified by the "test" me= mber identifies the base reference point for the predicate.

    One of the main reasons I prefer (B) is that it allows = me a clean way of interpolating predicate checks throughout the patch docum= ent.

    Option (B) also allows us to get by without n= ecessarily creating a new base document type and media type.

    Thoughts?

    - James
    =
    On Mon, Sep 17, 2012 at 12:39 PM, James M Sn= ell <jasnell@gmail.com> wrote:
    Here is= the early initial draft of JSON-Test ... this is not yet published as an I= -D. I need to fill in some of the additional detail and examples around the= basic predicate operations. However, the key elements are in place. I will= try to get this published either tonight or tomorrow at the latest<= div>
    =C2=A0 http://goo.gl/osKeI =C2=A0<=3D=3D Links to my Github repo<= /div>

    As always, feedback= is more than welcome.

    - James


    On Mon, Sep 17, 2012 at 12:33 PM, P= aul C. Bryan <pbryan@anode.ca> wrote:
    =20 =20
    On Mon, 2012-09-17 at 17:32 +1000, Manger, James H wrote:
    The JSON patch spec looks good: draft-ietf-appsawg-json-patch-04.

    There is no explicit mention of extensibility of the JSON patch syntax.= Presumably new operations (beyond add/remove/replace/move/copy/test) could= be added, with the understanding that "old" implementations will= reject such documents [section 4 says an unknown operation is an error]. A= dding extra fields to an existing operation is less clear (eg {"add&qu= ot;:"/foo/1","value":"baz","repeat"= :10}). There is no explicit mention that that would be an error. Perhaps im= plementations will ignore unrecognized fields.

    I had envisioned a container document type, which would enumerate a set of = conditions that must be met before processing the operations an associated = (contained) JSON Patch document. Taking this approach means that there is n= o confusion over what's a JSON Patch document vs. the extension documen= t type. Since JSON Patch is an array of operation objects, such a structure= would remain relatively straightforward.

    More concretely, perhaps something like:

    {
=C2=A0=C2=A0=C2=A0 "tests": [
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "less-than": &qu=
ot;/some/path", "value": 42 },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "exists": "=
/some/other/path" },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "not-exists": &q=
uot;/yet/another/path" },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "contains": "/f=
oo/bar", "value": "Major-General" }
=C2=A0=C2=A0=C2=A0 ], "application/json-patch": [
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "replace": "=
;/some/path", "value": 42 },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "delete": "=
/some/other/path" },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "add": "/ye=
t/another/path", "value": "bar!" }
=C2=A0=C2=A0=C2=A0 ]
}

    Thoughts?


    Could more sophisticated future test rules define, say, a "test2&q= uot; operation? Or is it the expectation that such a syntax would need a ne= w media type?

    I would say any extension should require its own media type.


    Each operation lists a full JSON pointer from the root of the resource.= If you want to replace a dozen fields in a deeply nested object you need t= o repeat the path to that object a dozen times. This may be a reasonable co= mpromise to avoid a more complex patch structure (particularly if compressi= on removes much of the overhead), but I wasn't sure if any alternative = had been considered. For example, {"patch":"/fee/fie/fo/fum/= foo","value":[{"add":"x","value&quo= t;:"baz"},{"add":"y","value":3}]}.<= br>

    We've considered alternatives in the past, but concluded that given the= verbosity of the JSON Patch document, the likely strategy to reduce size w= ould be through compression. As such, multiple similar paths would compress= fairly well.


    Would I be opening a can of worms (or doing some bike-shedding) if I as= ked why application/json-patch instead of application/patch+json?

    Probably. I originally proposed application/patch+json. The main problem wi= th application/patch+json is that it implies that there are other represent= ations of application/patch, not just JSON (e.g. application/patch+xml). In= this case, JSON Patch is meant to address only JSON documents in a = JSON format. Furthermore, I'm not yet aware of a specification for JSON= like there is is for XML that promotes the addition of +json. Therefore, I= 'd say that application/json-patch is probably the better choice.=

    Paul

    _______________________________________________
    apps-discuss mailing list
    apps-discuss@iet= f.org
    https://www.ietf.org/mailman/listinfo/apps-discuss



    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss


    --f46d043c7f382d5f5604c9ee8883-- From pbryan@anode.ca Mon Sep 17 18:02:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55ED121E8083 for ; Mon, 17 Sep 2012 18:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSxJdF4Y1yWn for ; Mon, 17 Sep 2012 18:02:05 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 0271021E804A for ; Mon, 17 Sep 2012 18:02:05 -0700 (PDT) Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 19E0E616A; Tue, 18 Sep 2012 01:02:04 +0000 (UTC) From: "Paul C. Bryan" To: James M Snell In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-gnUPHf5YBQbHUIlFL69N" Date: Mon, 17 Sep 2012 18:02:01 -0700 Message-ID: <1347930121.19756.145.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Early Initial Draft: JSON-Test (was Re: JSON Patch: extensibility) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 01:02:06 -0000 --=-gnUPHf5YBQbHUIlFL69N Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Some comments off the top of my head: 1. I'd probably like to understand more about the interpolation usage, especially its utility value before defaulting to my preference for option A. :-) 2. I happen to think that the introduction of a new media type will probably be necessary. 3. I like your thinking about logical (a.k.a "aggregate" in your document) operations: "and", "or", "not". 4. Though I have no concrete use case so far, there's something very attractive to me about having something wrap a set of conditions around something else that can be processed. Paul On Mon, 2012-09-17 at 16:56 -0700, James M Snell wrote: > Ok.. working through some possible ways of manifesting the predicate > operations within a JSON-Patch context... there are two possible > options that I see... > > > > (A) One is to use something like the example syntax Paul suggests in > his previous note... > > > { > "tests": [ > { "less-than": "/some/path", "value": 42 }, > { "test": "/some/other/path" }, > { "contains": "/foo/bar", "value": "Major-General" } > ], "application/json-patch": [ > { "replace": "/some/path", "value": 42 }, > { "delete": "/some/other/path" }, > { "add": "/yet/another/path", "value": "bar!" } > ] > } > > > (B) Another is to introduce an optional "predicate" member on the > JSON-Patch "test" operation, such that a "test" operation would only > succeed if, and only if, the attached predicate evaluates true: > > > [ > {"test": "/", > "predicate": { > "and": [ > { "less-than": "/some/path", "value": 42 }, > { "test": "/some/other/path" }, > { "contains": "/foo/bar", "value": "Major-General" } > ] > } > }, > { "replace": "/some/path", "value": 42 }, > { "delete": "/some/other/path" }, > { "add": "/yet/another/path", "value": "bar!" } > ] > > > Running through the various cases, option (B) seems to be a cleaner > mapping overall. Note that in this case, the JSON-Pointer value > specified by the "test" member identifies the base reference point for > the predicate. > > > One of the main reasons I prefer (B) is that it allows me a clean way > of interpolating predicate checks throughout the patch document. > > > Option (B) also allows us to get by without necessarily creating a new > base document type and media type. > > > Thoughts? > > > - James > > > > On Mon, Sep 17, 2012 at 12:39 PM, James M Snell > wrote: > > Here is the early initial draft of JSON-Test ... this is not > yet published as an I-D. I need to fill in some of the > additional detail and examples around the basic predicate > operations. However, the key elements are in place. I will try > to get this published either tonight or tomorrow at the latest > > > > http://goo.gl/osKeI <== Links to my Github repo > > > As always, feedback is more than welcome. > > > - James > > > > On Mon, Sep 17, 2012 at 12:33 PM, Paul C. Bryan > wrote: > > On Mon, 2012-09-17 at 17:32 +1000, Manger, James H > wrote: > > > The JSON patch spec looks good: > > draft-ietf-appsawg-json-patch-04. > > > > There is no explicit mention of extensibility of the > > JSON patch syntax. Presumably new operations (beyond > > add/remove/replace/move/copy/test) could be added, > > with the understanding that "old" implementations > > will reject such documents [section 4 says an > > unknown operation is an error]. Adding extra fields > > to an existing operation is less clear (eg > > {"add":"/foo/1","value":"baz","repeat":10}). There > > is no explicit mention that that would be an error. > > Perhaps implementations will ignore unrecognized > > fields. > > > > > I had envisioned a container document type, which > would enumerate a set of conditions that must be met > before processing the operations an associated > (contained) JSON Patch document. Taking this approach > means that there is no confusion over what's a JSON > Patch document vs. the extension document type. Since > JSON Patch is an array of operation objects, such a > structure would remain relatively straightforward. > > More concretely, perhaps something like: > > > { > "tests": [ > { "less-than": "/some/path", "value": 42 }, > { "exists": "/some/other/path" }, > { "not-exists": "/yet/another/path" }, > { "contains": "/foo/bar", "value": "Major-General" } > ], "application/json-patch": [ > { "replace": "/some/path", "value": 42 }, > { "delete": "/some/other/path" }, > { "add": "/yet/another/path", "value": "bar!" } > ] > } > > > Thoughts? > > > > > > Could more sophisticated future test rules define, > > say, a "test2" operation? Or is it the expectation > > that such a syntax would need a new media type? > > > > > I would say any extension should require its own media > type. > > > > > > Each operation lists a full JSON pointer from the > > root of the resource. If you want to replace a dozen > > fields in a deeply nested object you need to repeat > > the path to that object a dozen times. This may be a > > reasonable compromise to avoid a more complex patch > > structure (particularly if compression removes much > > of the overhead), but I wasn't sure if any > > alternative had been considered. For example, > > {"patch":"/fee/fie/fo/fum/foo","value":[{"add":"x","value":"baz"},{"add":"y","value":3}]}. > > > > > We've considered alternatives in the past, but > concluded that given the verbosity of the JSON Patch > document, the likely strategy to reduce size would be > through compression. As such, multiple similar paths > would compress fairly well. > > > > > > Would I be opening a can of worms (or doing some > > bike-shedding) if I asked why application/json-patch > > instead of application/patch+json? > > > > > Probably. I originally proposed application/patch > +json. The main problem with application/patch+json is > that it implies that there are other representations > of application/patch, not just JSON (e.g. > application/patch+xml). In this case, JSON Patch is > meant to address only JSON documents in a JSON format. > Furthermore, I'm not yet aware of a specification for > JSON like there is is for XML that promotes the > addition of +json. Therefore, I'd say that > application/json-patch is probably the better choice. > > Paul > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > --=-gnUPHf5YBQbHUIlFL69N Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Some comments off the top of my head:

    1. I'd probably like to understand more about the interpolation usage, especially its utility value before defaulting to my preference for option A. :-)
    2. I happen to think that the introduction of a new media type will probably be necessary.
    3. I like your thinking about logical (a.k.a "aggregate" in your document) operations: "and", "or", "not".
    4. Though I have no concrete use case so far, there's something very attractive to me about having something wrap a set of conditions around something else that can be processed.

    Paul

    On Mon, 2012-09-17 at 16:56 -0700, James M Snell wrote:
    Ok.. working through some possible ways of manifesting the predicate operations within a JSON-Patch context... there are two possible options that I see... 


    (A) One is to use something like the example syntax Paul suggests in his previous note...


      {
        "tests": [
            { "less-than": "/some/path", "value": 42 },
            { "test": "/some/other/path" },
            { "contains": "/foo/bar", "value": "Major-General" }
        ], "application/json-patch": [
            { "replace": "/some/path", "value": 42 },
            { "delete": "/some/other/path" },
            { "add": "/yet/another/path", "value": "bar!" }
        ]
      }


    (B) Another is to introduce an optional "predicate" member on the JSON-Patch "test" operation, such that a "test" operation would only succeed if, and only if, the attached predicate evaluates true:


      [
        {"test": "/",
         "predicate": {
           "and": [
            { "less-than": "/some/path", "value": 42 },
            { "test": "/some/other/path" },
            { "contains": "/foo/bar", "value": "Major-General" }
           ]
         }
        },
        { "replace": "/some/path", "value": 42 },
        { "delete": "/some/other/path" },
        { "add": "/yet/another/path", "value": "bar!" }    
      ]


    Running through the various cases, option (B) seems to be a cleaner mapping overall. Note that in this case, the JSON-Pointer value specified by the "test" member identifies the base reference point for the predicate.


    One of the main reasons I prefer (B) is that it allows me a clean way of interpolating predicate checks throughout the patch document.


    Option (B) also allows us to get by without necessarily creating a new base document type and media type.


    Thoughts?


    - James

    On Mon, Sep 17, 2012 at 12:39 PM, James M Snell <jasnell@gmail.com> wrote:
    Here is the early initial draft of JSON-Test ... this is not yet published as an I-D. I need to fill in some of the additional detail and examples around the basic predicate operations. However, the key elements are in place. I will try to get this published either tonight or tomorrow at the latest


      http://goo.gl/osKeI  <== Links to my Github repo


    As always, feedback is more than welcome.


    - James


    On Mon, Sep 17, 2012 at 12:33 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
    On Mon, 2012-09-17 at 17:32 +1000, Manger, James H wrote:
    The JSON patch spec looks good: draft-ietf-appsawg-json-patch-04.

    There is no explicit mention of extensibility of the JSON patch syntax. Presumably new operations (beyond add/remove/replace/move/copy/test) could be added, with the understanding that "old" implementations will reject such documents [section 4 says an unknown operation is an error]. Adding extra fields to an existing operation is less clear (eg {"add":"/foo/1","value":"baz","repeat":10}). There is no explicit mention that that would be an error. Perhaps implementations will ignore unrecognized fields.


    I had envisioned a container document type, which would enumerate a set of conditions that must be met before processing the operations an associated (contained) JSON Patch document. Taking this approach means that there is no confusion over what's a JSON Patch document vs. the extension document type. Since JSON Patch is an array of operation objects, such a structure would remain relatively straightforward.

    More concretely, perhaps something like:

    {
    "tests": [
        { "less-than": "/some/path", "value": 42 },
        { "exists": "/some/other/path" },
        { "not-exists": "/yet/another/path" },
        { "contains": "/foo/bar", "value": "Major-General" }
    ], "application/json-patch": [
        { "replace": "/some/path", "value": 42 },
        { "delete": "/some/other/path" },
        { "add": "/yet/another/path", "value": "bar!" }
    ]
}

    Thoughts?


    Could more sophisticated future test rules define, say, a "test2" operation? Or is it the expectation that such a syntax would need a new media type?


    I would say any extension should require its own media type.


    Each operation lists a full JSON pointer from the root of the resource. If you want to replace a dozen fields in a deeply nested object you need to repeat the path to that object a dozen times. This may be a reasonable compromise to avoid a more complex patch structure (particularly if compression removes much of the overhead), but I wasn't sure if any alternative had been considered. For example, {"patch":"/fee/fie/fo/fum/foo","value":[{"add":"x","value":"baz"},{"add":"y","value":3}]}.


    We've considered alternatives in the past, but concluded that given the verbosity of the JSON Patch document, the likely strategy to reduce size would be through compression. As such, multiple similar paths would compress fairly well.


    Would I be opening a can of worms (or doing some bike-shedding) if I asked why application/json-patch instead of application/patch+json?


    Probably. I originally proposed application/patch+json. The main problem with application/patch+json is that it implies that there are other representations of application/patch, not just JSON (e.g. application/patch+xml). In this case, JSON Patch is meant to address only JSON documents in a JSON format. Furthermore, I'm not yet aware of a specification for JSON like there is is for XML that promotes the addition of +json. Therefore, I'd say that application/json-patch is probably the better choice.

    Paul

    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss




    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss




    --=-gnUPHf5YBQbHUIlFL69N-- From jasnell@gmail.com Mon Sep 17 18:14:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AD221E809E for ; Mon, 17 Sep 2012 18:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2atg-xE9nmp for ; Mon, 17 Sep 2012 18:14:13 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1F421E8083 for ; Mon, 17 Sep 2012 18:14:12 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so2496743wib.13 for ; Mon, 17 Sep 2012 18:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eBskzf98o4vh31gELItdk+BUriu7bBm1I6ofzlN0I8E=; b=KuEDohRaIBOjN3agcbp7wRU6sKMuHb/PcmkOfus+Qn6gAF24SiLsq5UJGs30CnTWlX Dlybw9iaRBRM+07LrKPn6mDfnN2aEMdtaKHK5dzfD1heVkxAtSUCRXyxOrgNmlftqBCT pkyLwXjDVpix9oS9eEkRRsK2hw4MV6p0UeAGEbeM2UUkhK5YPEoQiCQDuc4v7tYxr0mc oEnWOLiMwJFAIplzKWsIddMzJ0G3RKi9Rz/3uT6og1qlaZ3mevfOMlu2nlT4IwPI6GG1 RQ+Kd89TbXGNrEPW8yzqS7dWJrxdlLk7rHAKR16hlw1rKyWTv1SCPj6KAljNXhUJlczn rgKg== Received: by 10.180.98.200 with SMTP id ek8mr19642314wib.0.1347930851769; Mon, 17 Sep 2012 18:14:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.96.2 with HTTP; Mon, 17 Sep 2012 18:13:51 -0700 (PDT) In-Reply-To: <1347930121.19756.145.camel@pbryan-wsl.internal.salesforce.com> References: <1347930121.19756.145.camel@pbryan-wsl.internal.salesforce.com> From: James M Snell Date: Mon, 17 Sep 2012 18:13:51 -0700 Message-ID: To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=f46d0442886099fbdd04c9ef9bb2 Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Early Initial Draft: JSON-Test (was Re: JSON Patch: extensibility) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 01:14:14 -0000 --f46d0442886099fbdd04c9ef9bb2 Content-Type: text/plain; charset=UTF-8 The interpolation case is a bit abstract and deals more with allowing for fail-fast (checking to see if an operation could succeed before actually attempting the operation) as well as ensuring success in cases where the target resource may not actually be a json document and a preceding change might potentially trigger an unintended change of state. (This is largely experimental for now so I can be easily swayed in either direction with a solid enough argument :-) ...) For example, suppose I have a resource that can be represented as JSON, but implements a rule that the "/updated" property is to be modified automatically whenever any of it's other discreet fields are modified. A client may not be aware of this semantic and may attempt to set the "/updated" and "/title" values... [ {"replace":"/title","value":"foo"}, {"replace":"/updated", "value":"2012-12-12T12:12:12Z"} {"test":"/updated", "value":"2012-12-12T12:12:12Z"} ] The test ensures that the patch as a whole will only succeed if the value of "/updated" is precisely the value intended by the sender. Yes, this is a fairly contrived example.. like I said, I'm more than willing to be convinced that I'm just being silly. - James On Mon, Sep 17, 2012 at 6:02 PM, Paul C. Bryan wrote: > ** > Some comments off the top of my head: > > 1. I'd probably like to understand more about the interpolation usage, > especially its utility value before defaulting to my preference for option > A. :-) > 2. I happen to think that the introduction of a new media type will > probably be necessary. > 3. I like your thinking about logical (a.k.a "aggregate" in your document) > operations: "and", "or", "not". > 4. Though I have no concrete use case so far, there's something very > attractive to me about having something wrap a set of conditions around > something else that can be processed. > > Paul > > > On Mon, 2012-09-17 at 16:56 -0700, James M Snell wrote: > > Ok.. working through some possible ways of manifesting the predicate > operations within a JSON-Patch context... there are two possible options > that I see... > > > > (A) One is to use something like the example syntax Paul suggests in his > previous note... > > > > { > > "tests": [ > > { "less-than": "/some/path", "value": 42 }, > > { "test": "/some/other/path" }, > > { "contains": "/foo/bar", "value": "Major-General" } > > ], "application/json-patch": [ > > { "replace": "/some/path", "value": 42 }, > > { "delete": "/some/other/path" }, > > { "add": "/yet/another/path", "value": "bar!" } > > ] > > } > > > > (B) Another is to introduce an optional "predicate" member on the > JSON-Patch "test" operation, such that a "test" operation would only > succeed if, and only if, the attached predicate evaluates true: > > > > [ > > {"test": "/", > > "predicate": { > > "and": [ > > { "less-than": "/some/path", "value": 42 }, > > { "test": "/some/other/path" }, > > { "contains": "/foo/bar", "value": "Major-General" } > > ] > > } > > }, > > { "replace": "/some/path", "value": 42 }, > > { "delete": "/some/other/path" }, > > { "add": "/yet/another/path", "value": "bar!" } > > ] > > > > Running through the various cases, option (B) seems to be a cleaner > mapping overall. Note that in this case, the JSON-Pointer value specified > by the "test" member identifies the base reference point for the predicate. > > > > One of the main reasons I prefer (B) is that it allows me a clean way of > interpolating predicate checks throughout the patch document. > > > > Option (B) also allows us to get by without necessarily creating a new > base document type and media type. > > > > Thoughts? > > > > - James > > > On Mon, Sep 17, 2012 at 12:39 PM, James M Snell > wrote: > > Here is the early initial draft of JSON-Test ... this is not yet published > as an I-D. I need to fill in some of the additional detail and examples > around the basic predicate operations. However, the key elements are in > place. I will try to get this published either tonight or tomorrow at the > latest > > > > http://goo.gl/osKeI <== Links to my Github repo > > > > As always, feedback is more than welcome. > > > > - James > > > > On Mon, Sep 17, 2012 at 12:33 PM, Paul C. Bryan > wrote: > > On Mon, 2012-09-17 at 17:32 +1000, Manger, James H wrote: > > The JSON patch spec looks good: draft-ietf-appsawg-json-patch-04. > > There is no explicit mention of extensibility of the JSON patch syntax. > Presumably new operations (beyond add/remove/replace/move/copy/test) could > be added, with the understanding that "old" implementations will reject > such documents [section 4 says an unknown operation is an error]. Adding > extra fields to an existing operation is less clear (eg > {"add":"/foo/1","value":"baz","repeat":10}). There is no explicit mention > that that would be an error. Perhaps implementations will ignore > unrecognized fields. > > > > I had envisioned a container document type, which would enumerate a > set of conditions that must be met before processing the operations an > associated (contained) JSON Patch document. Taking this approach means that > there is no confusion over what's a JSON Patch document vs. the extension > document type. Since JSON Patch is an array of operation objects, such a > structure would remain relatively straightforward. > > More concretely, perhaps something like: > > { "tests": [ { "less-than": "/some/path", "value": 42 }, { "exists": "/some/other/path" }, { "not-exists": "/yet/another/path" }, > { "contains": "/foo/bar", "value": "Major-General" } ], "application/json-patch": [ { "replace": "/some/path", "value": 42 }, { "delete": "/some/other/path" }, { "add": "/yet/another/path", "value": "bar!" } ]} > > > Thoughts? > > > > Could more sophisticated future test rules define, say, a "test2" > operation? Or is it the expectation that such a syntax would need a new > media type? > > > > I would say any extension should require its own media type. > > > > Each operation lists a full JSON pointer from the root of the resource. > If you want to replace a dozen fields in a deeply nested object you need to > repeat the path to that object a dozen times. This may be a reasonable > compromise to avoid a more complex patch structure (particularly if > compression removes much of the overhead), but I wasn't sure if any > alternative had been considered. For example, > {"patch":"/fee/fie/fo/fum/foo","value":[{"add":"x","value":"baz"},{"add":"y","value":3}]}. > > > > We've considered alternatives in the past, but concluded that given > the verbosity of the JSON Patch document, the likely strategy to reduce > size would be through compression. As such, multiple similar paths would > compress fairly well. > > > > Would I be opening a can of worms (or doing some bike-shedding) if I > asked why application/json-patch instead of application/patch+json? > > > > Probably. I originally proposed application/patch+json. The main > problem with application/patch+json is that it implies that there are other > representations of application/patch, not just JSON (e.g. > application/patch+xml). In this case, JSON Patch is meant to address *only > * JSON documents in a JSON format. Furthermore, I'm not yet aware of a > specification for JSON like there is is for XML that promotes the addition > of +json. Therefore, I'd say that application/json-patch is probably the > better choice. > > Paul > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > --f46d0442886099fbdd04c9ef9bb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The interpolation case is a bit abstra= ct and deals more with allowing for fail-fast (checking to see if an operat= ion could succeed before actually attempting the operation) as well as ensu= ring success in cases where the target resource may not actually be a json = document and a preceding change might potentially trigger an unintended cha= nge of state. (This is largely experimental for now so I can be easily sway= ed in either direction with a solid enough argument :-) ...)

    For example, suppose I have a resource that can be r= epresented as JSON, but implements a rule that the "/updated" pro= perty is to be modified automatically whenever any of it's other discre= et fields are modified. A client may not be aware of this semantic and may = attempt to set the "/updated" and "/title" values...

    [
    =C2=A0 {"replace":"/title","value":= "foo"},
    =C2=A0 {"replace":&quo= t;/updated", "value":"2012-12-12T12:12:12Z"}
    =C2=A0 {"test":= "/updated", "value":"2012-12-12T12:12:12Z"}
    ]

    The test ensures that the patch as a whole will only succeed if t= he value of "/updated" is precisely the value intended by the sen= der.

    Yes, this is a fairly contrived example.. like = I said, I'm more than willing to be convinced that I'm just being s= illy.

    - James

    On Mon, Sep 17, 2012 at 6:02 PM, Paul C. Bryan <pbryan@anode.ca<= /a>> wrote:
    =20 =20
    Some comments off the top of my head:

    1. I'd probably like to understand more about the interpolation usage, = especially its utility value before defaulting to my preference for option = A. :-)
    2. I happen to think that the introduction of a new media type will probabl= y be necessary.
    3. I like your thinking about logical (a.k.a "aggregate" in your = document) operations: "and", "or", "not".
    4. Though I have no concrete use case so far, there's something very at= tractive to me about having something wrap a set of conditions around somet= hing else that can be processed.

    Paul


    On Mon, 2012-09-17 at 16:56 -0700, James M Snell wrote:
    Ok.. working through some possible ways of manifesting the predicate op= erations within a JSON-Patch context... there are two possible options that= I see...=C2=A0


    (A) One is to use something like the example syntax Paul suggests in hi= s previous note...


    =C2=A0 {
    =C2=A0 =C2=A0 "tests": [
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "less-than": "/some/path&q= uot;, "value": 42 },
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "test": "/some/other/path&= quot; },
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "contains": "/foo/bar"= ;, "value": "Major-General" }
    =C2=A0 =C2=A0 ], "application/json-patch": [
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "replace": "/some/path&quo= t;, "value": 42 },
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "delete": "/some/other/pat= h" },
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "add": "/yet/another/path&= quot;, "value": "bar!" }
    =C2=A0 =C2=A0 ]
    =C2=A0 }


    (B) Another is to introduce an optional "predicate" member on= the JSON-Patch "test" operation, such that a "test" op= eration would only succeed if, and only if, the attached predicate evaluate= s true:


    =C2=A0 [
    =C2=A0 =C2=A0 {"test": "/",
    =C2=A0 =C2=A0 =C2=A0"predicate": {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0"and": [
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "less-than": "/some/path&q= uot;, "value": 42 },
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "test": "/some/other/path&= quot; },
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "contains": "/foo/bar"= ;, "value": "Major-General" }
    =C2=A0 =C2=A0 =C2=A0 =C2=A0]
    =C2=A0 =C2=A0 =C2=A0}
    =C2=A0 =C2=A0 },
    =C2=A0 =C2=A0 { "replace": "/some/path", "valu= e": 42 },
    =C2=A0 =C2=A0 { "delete": "/some/other/path" },
    =C2=A0 =C2=A0 { "add": "/yet/another/path", "v= alue": "bar!" }=C2=A0 =C2=A0=C2=A0
    =C2=A0 ]


    Running through the various cases, option (B) seems to be a cleaner map= ping overall. Note that in this case, the JSON-Pointer value specified by t= he "test" member identifies the base reference point for the pred= icate.


    One of the main reasons I prefer (B) is that it allows me a clean way o= f interpolating predicate checks throughout the patch document.


    Option (B) also allows us to get by without necessarily creating a new = base document type and media type.


    Thoughts?


    - James

    On Mon, Sep 17, 2012 at 12:39 PM, James M Snell <jasnell@gmail.com> wrote:
    Here is the early initial draft of JSON-Test ... this is not yet pu= blished as an I-D. I need to fill in some of the additional detail and exam= ples around the basic predicate operations. However, the key elements are i= n place. I will try to get this published either tonight or tomorrow at the= latest


    =C2=A0 http://goo= .gl/osKeI =C2=A0<=3D=3D Links to my Github repo


    As always, feedback is more than welcome.


    - James


    On Mon, Sep 17, 2012 at 12:33 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
    On Mon, 2012-09-17 at 17:32 +1000, Manger, James H wrote:
    The JSON patch spec looks good: draft-ietf-appsawg-json-pat= ch-04.

    There is no explicit mention of extensibility of the JSON p= atch syntax. Presumably new operations (beyond add/remove/replace/move/copy= /test) could be added, with the understanding that "old" implemen= tations will reject such documents [section 4 says an unknown operation is = an error]. Adding extra fields to an existing operation is less clear (eg {= "add":"/foo/1","value":"baz","= repeat":10}). There is no explicit mention that that would be an error= . Perhaps implementations will ignore unrecognized fields.


    I had envisioned a container document type, which would enumera= te a set of conditions that must be met before processing the operations an= associated (contained) JSON Patch document. Taking this approach means tha= t there is no confusion over what's a JSON Patch document vs. the exten= sion document type. Since JSON Patch is an array of operation objects, such= a structure would remain relatively straightforward.

    More concretely, perhaps something like:

    {
=C2=A0=C2=A0=C2=A0 "tests": [
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "less-than": &qu=
ot;/some/path", "value": 42 },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "exists": "=
/some/other/path" },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "not-exists": &q=
uot;/yet/another/path" },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "contains": "/f=
oo/bar", "value": "Major-General" }
=C2=A0=C2=A0=C2=A0 ], "application/json-patch": [
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "replace": "=
;/some/path", "value": 42 },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "delete": "=
/some/other/path" },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "add": "/ye=
t/another/path", "value": "bar!" }
=C2=A0=C2=A0=C2=A0 ]
}

    Thoughts?


    Could more sophisticated future test rules define, say, a &= quot;test2" operation? Or is it the expectation that such a syntax wou= ld need a new media type?


    I would say any extension should require its own media type.


    Each operation lists a full JSON pointer from the root of t= he resource. If you want to replace a dozen fields in a deeply nested objec= t you need to repeat the path to that object a dozen times. This may be a r= easonable compromise to avoid a more complex patch structure (particularly = if compression removes much of the overhead), but I wasn't sure if any = alternative had been considered. For example, {"patch":"/fee= /fie/fo/fum/foo","value":[{"add":"x",&qu= ot;value":"baz"},{"add":"y","value&= quot;:3}]}.


    We've considered alternatives in the past, but concluded th= at given the verbosity of the JSON Patch document, the likely strategy to r= educe size would be through compression. As such, multiple similar paths wo= uld compress fairly well.


    Would I be opening a can of worms (or doing some bike-shedd= ing) if I asked why application/json-patch instead of application/patch+jso= n?


    Probably. I originally proposed application/patch+json. The mai= n problem with application/patch+json is that it implies that there are oth= er representations of application/patch, not just JSON (e.g. application/pa= tch+xml). In this case, JSON Patch is meant to address only JSON doc= uments in a JSON format. Furthermore, I'm not yet aware of a specificat= ion for JSON like there is is for XML that promotes the addition of +json. = Therefore, I'd say that application/json-patch is probably the better c= hoice.

    Paul

    _______________________________________________
    apps-discuss mailing list
    apps= -discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss



    _______________________________________________
    apps-discuss mailing list
    apps-dis= cuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss





    --f46d0442886099fbdd04c9ef9bb2-- From James.H.Manger@team.telstra.com Mon Sep 17 19:33:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD65021E803D for ; Mon, 17 Sep 2012 19:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGfxtrHOvwly for ; Mon, 17 Sep 2012 19:33:51 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 60C0C21E80A4 for ; Mon, 17 Sep 2012 19:33:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,440,1344175200"; d="scan'208,217";a="91715958" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 18 Sep 2012 12:33:44 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6838"; a="90136169" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcbni.tcif.telstra.com.au with ESMTP; 18 Sep 2012 12:33:44 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Tue, 18 Sep 2012 12:33:43 +1000 From: "Manger, James H" To: "Paul C. Bryan" , Martin Thomson Date: Tue, 18 Sep 2012 12:33:42 +1000 Thread-Topic: [apps-discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-patch-04.txt Thread-Index: Ac2VJteuqZiQErlFSu6HiXLRw/MghAAGy2wg Message-ID: <255B9BB34FB7D647A506DC292726F6E114FD10E3C3@WSMSG3153V.srv.dir.telstra.com> References: <20120917062225.31160.89210.idtracker@ietfa.amsl.com> <1347920475.19756.39.camel@pbryan-wsl.internal.salesforce.com> <1347922222.19756.67.camel@pbryan-wsl.internal.salesforce.com> In-Reply-To: <1347922222.19756.67.camel@pbryan-wsl.internal.salesforce.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114FD10E3C3WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-patch-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 02:33:52 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114FD10E3C3WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Ii8iIGlzIG5vdCB0aGUgcm9vdC4gSXQgaXMgYW4gaXRlbSBpbiB0aGUgcm9vdCBvYmplY3Qgd2l0 aCBhbiBlbXB0eSBzdHJpbmcgYXMgaXRzIG5hbWUuDQpIZW5jZSwgTWFydGlu4oCZcyBleGFtcGxl IOKAnG9sZOKAnSBhbmQg4oCccGF0Y2jigJ0gdmFsdWVzIGFyZSB2YWxpZCwgYnV0IHRoZXkgZG9u 4oCZdCBwcm9kdWNlIGhpcyDigJxuZXfigJ0gdmFsdWUsIG5vciBQYXVs4oCZcyBlcnJvci4gVGhl eSBwcm9kdWNlIHsgImEiOiB7fSwgIiI6ImZvbyIgfS4NCg0Kb2xkOg0KICB7ICJhIjogeyAiYiI6 ICJmb28iIH0gfQ0KcGF0Y2g6DQogIHsgIm1vdmUiOiAiL2EvYiIsICJ0byI6ICIvIiB9DQpuZXc6 DQogIHsgImEiOiB7fSwgIiI6ImZvbyIgfQ0KDQoNClAuUy4gVGhlIGVtcHR5IHN0cmluZyAiIiBp cyB0aGUgSlNPTi1Qb2ludGVyIHRvIHRoZSByb290LCB3aGljaCB3aWxsIG9mdGVuIGJlIGFuIG9i amVjdCwgb3IgYW4gYXJyYXksIGJ1dCBjb3VsZCBhbHNvIGJlIGEgc3RyaW5nLCBvciBudW1iZXIg ZXRjLiBJIGd1ZXNzIHsicmVtb3ZlIjoiIn0gaXMgdmFsaWQuIEl0IGxlYXZlcyBhbiBlbXB0eSBk b2N1bWVudCAoZWcgYSByZXNvdXJjZSB3aXRoIDAgYnl0ZXMpLCB0aG91Z2ggdGhhdCBpc27igJl0 IGEgdmFsaWQgSlNPTiB2YWx1ZS4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQpGcm9tOiBhcHBzLWRp c2N1c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgUGF1bCBDLiBCcnlhbg0KU2VudDogVHVlc2RheSwgMTggU2VwdGVt YmVyIDIwMTIgODo1MCBBTQ0KVG86IE1hcnRpbiBUaG9tc29uDQpDYzogQXBwcyBEaXNjdXNzOyBN YXJrIE5vdHRpbmdoYW0NClN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBGd2Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1hcHBzYXdnLWpzb24tcGF0Y2gtMDQudHh0 DQoNCk9rYXksIEkgdGFrZSBpdCBiYWNrOyBJIHdhcyByZWZlcnJpbmcgdG8gYW4gb2JqZWN0LCB3 aGljaCByb290IGNhbm5vdCBiZSBpbmZlcnJlZCB0byBiZS4gU28gd2UgaGF2ZSBhIGhvbGUgd2hl cmUgdGhlIHJvb3QgdmFsdWUgb2YgdGhlIGRvY3VtZW50IGlzIG5laXRoZXIgYW4gYXJyYXkgbm9y IGFuIG9iamVjdDsgaXQncyBtZXJlbHkgYSB2YWx1ZS4gUGVyaGFwcyBsYW5ndWFnZSBzdGF0aW5n IHRoYXQgdGhlIHJvb3QgaXMgYW4gaW52YWxpZCAidG8iIHRhcmdldCwgYmVjYXVzZSBpdCBhbHdh eXMgZXhpc3RzLg0KDQpQYXVsDQoNCk9uIE1vbiwgMjAxMi0wOS0xNyBhdCAxNToyMSAtMDcwMCwg UGF1bCBDLiBCcnlhbiB3cm90ZToNCg0KT24gTW9uLCAyMDEyLTA5LTE3IGF0IDE1OjE1IC0wNzAw LCBNYXJ0aW4gVGhvbXNvbiB3cm90ZToNCg0KDQoNClJlYWRpbmcgdGhlIGRlc2NyaXB0aW9uIG9m ICJtb3ZlIiwgSSBjYW4gaW5mZXIgdGhhdCB0aGUgaW50ZW50IGlzIHRvDQoNCnNwZWNpZnkgdGhl IG5hbWUgb2YgdGhlIG5vZGUgc3VjaCB0aGF0LCBvbGRkb2Mje21vdmV9ID09IG5ld2RvYyN7dG99 DQoNCg0KDQpUaGlzIGlzIHVubGlrZSBvdGhlciAibW92ZSIgb3IgIm12IiBjb21tYW5kcyB3aGVy ZSB5b3UgYXJlIGFibGUgdG8NCg0KaWRlbnRpZnkgYSBjb250YWluZXIgYXMgdGhlIHRhcmdldCBv ZiBhIG1vdmUuDQoNCg0KDQpvbGQ6DQoNCiAgeyAiYSI6IHsgImIiOiAiZm9vIiB9IH0NCg0KcGF0 Y2g6DQoNCiAgeyAibW92ZSI6ICIvYS9iIiwgInRvIjogIi8iIH0NCg0KbmV3Og0KDQogIHsgImEi OiB7fSwgImIiOiJmb28iIH0NCg0KVGhpcyBhdHRlbXB0IGF0IHRoZSAibW92ZSIgb3BlcmF0aW9u IGFib3ZlIHdpbGwgZmFpbCBiZWNhdXNlIHRoZXJlIGlzIGFscmVhZHkgYSB2YWx1ZSBhdCAiLyIs IG5hbWVseSBhbiBvYmplY3QgY29udGFpbmluZyBhIHNvbGUgImEiIG1lbWJlci4NCg0KDQoNCg0K DQpJIGFzc3VtZSB0aGF0IGl0IGlzIGVudGlyZWx5IGludGVudGlvbmFsIHRoYXQgdGhpcyBpcyBu b3Qgc3VwcG9ydGVkLA0KDQpidXQgaXQgd291bGQgYmUgbmljZSB0byBjbGFyaWZ5IHRoYXQgdGhp cyBpcyBub3QgYSBmZWF0dXJlIHRoYXQgaXMNCg0KcHJvdmlkZWQuDQoNCk5vdCBvbmx5IGlzIGl0 IGVudGlyZWx5IGludGVudGlvbmFsIHRoYXQgaXQncyBub3Qgc3VwcG9ydGVkLCBpdCdzIGFjdHVh bGx5IGRvY3VtZW50ZWQgYXMgc3VjaC4gVG8gd2l0IGluIMKnNC40Og0KDQoiSWYgdGhlIGxvY2F0 aW9uIGluIHRoZSAndG8nIG1lbWJlciByZWZlcmVuY2VzIGEgbWVtYmVyIG9mIGFuIGV4aXN0aW5n IG9iamVjdCBpbiB0aGUgdGFyZ2V0IGRvY3VtZW50LCBpdCBpcyBhbiBlcnJvciBjb25kaXRpb24g aWYgYSB2YWx1ZSBhdCB0aGUgc3BlY2lmaWVkIGxvY2F0aW9uIGFscmVhZHkgZXhpc3RzLi4uIiBI ZW5jZSwgaXQgd2lsbCBmYWlsIGFzIGluZGljYXRlZCBhYm92ZS4NCg0KUGF1bA0KDQoNCg0KDQoN Cg0KDQotLU1hcnRpbg0KDQoNCg0KT24gMTYgU2VwdGVtYmVyIDIwMTIgMjM6MjQsIE1hcmsgTm90 dGluZ2hhbSA8bW5vdEBtbm90Lm5ldDxtYWlsdG86bW5vdEBtbm90Lm5ldD4+IHdyb3RlOg0KDQo+ IFRoaXMgZHJhZnQgaW5jb3Jwb3JhdGVkIHNvbWUgbWlub3IgZmVlZGJhY2sgZnJvbSBKYW1lcyBh bmQgbWFkZSBhIGZldyBlcnJvciBjb25kaXRpb25zIGV4cGxpY2l0Lg0KDQo+DQoNCj4gV2l0aCBp dCAtLSBhc3N1bWluZyB0aGF0IHRoZSBkZWNpc2lvbiB0byBrZWVwICJ0ZXN0IiBpbiBhcy1pcyAt LSBJICp0aGluayogd2UncmUgcmVhZHkgZm9yIFdHTEMgZm9yIGJvdGgganNvbi1wb2ludGVyIGFu ZCBqc29uLXBhdGNoLg0KDQo+DQoNCj4gQ2hlZXJzLA0KDQo+DQoNCj4NCg0KPiBCZWdpbiBmb3J3 YXJkZWQgbWVzc2FnZToNCg0KPg0KDQo+PiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8 bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCg0KPj4gU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1wYXRjaC0wNC50eHQN Cg0KPj4gRGF0ZTogMTcgU2VwdGVtYmVyIDIwMTIgNjoyMjoyNSBQTSBOWlNUDQoNCj4+IFRvOiBt bm90QG1ub3QubmV0PG1haWx0bzptbm90QG1ub3QubmV0Pg0KDQo+PiBDYzogcGJyeWFuQGFub2Rl LmNhPG1haWx0bzpwYnJ5YW5AYW5vZGUuY2E+DQoNCj4+DQoNCj4+DQoNCj4+IEEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1wYXRjaC0wNC50eHQNCg0KPj4gaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNYXJrIE5vdHRpbmdoYW0gYW5kIHBvc3Rl ZCB0byB0aGUNCg0KPj4gSUVURiByZXBvc2l0b3J5Lg0KDQo+Pg0KDQo+PiBGaWxlbmFtZTogICAg ICBkcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1wYXRjaA0KDQo+PiBSZXZpc2lvbjogICAgICAwNA0K DQo+PiBUaXRsZTogICAgICAgICAgICAgICAgIEpTT04gUGF0Y2gNCg0KPj4gQ3JlYXRpb24gZGF0 ZTogICAgICAgICAyMDEyLTA5LTE3DQoNCj4+IFdHIElEOiAgICAgICAgICAgICAgICAgYXBwc2F3 Zw0KDQo+PiBOdW1iZXIgb2YgcGFnZXM6IDE1DQoNCj4+IFVSTDogICAgICAgICAgICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1hcHBzYXdnLWpzb24tcGF0 Y2gtMDQudHh0DQoNCj4+IFN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1wYXRjaA0KDQo+PiBIdG1saXplZDogICAg ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXBwc2F3Zy1qc29uLXBh dGNoLTA0DQoNCj4+IERpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1hcHBzYXdnLWpzb24tcGF0Y2gtMDQNCg0KPj4NCg0KPj4gQWJzdHJh Y3Q6DQoNCj4+ICAgSlNPTiBQYXRjaCBkZWZpbmVzIHRoZSBtZWRpYSB0eXBlICJhcHBsaWNhdGlv bi9qc29uLXBhdGNoIiwgYSBKU09ODQoNCj4+ICAgZG9jdW1lbnQgc3RydWN0dXJlIGZvciBleHBy ZXNzaW5nIGEgc2VxdWVuY2Ugb2Ygb3BlcmF0aW9ucyB0byBhcHBseQ0KDQo+PiAgIHRvIGEgSlNP TiBkb2N1bWVudC4NCg0KPj4NCg0KPj4NCg0KPj4NCg0KPj4NCg0KPj4gVGhlIElFVEYgU2VjcmV0 YXJpYXQNCg0KPj4NCg0KPg0KDQo+IC0tDQoNCj4gTWFyayBOb3R0aW5naGFtDQoNCj4gaHR0cDov L3d3dy5tbm90Lm5ldC8NCg0KPg0KDQo+DQoNCj4NCg0KPg0KDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4gYXBwcy1kaXNjdXNzIG1haWxpbmcg bGlzdA0KDQo+IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYu b3JnPg0KDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNj dXNzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN CmFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCg0KYXBwcy1kaXNjdXNzQGlldGYub3JnPG1haWx0 bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYXBwcy1kaXNjdXNzDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCmFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCg0KYXBw cy1kaXNjdXNzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmc+DQoNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQoNCg== --_000_255B9BB34FB7D647A506DC292726F6E114FD10E3C3WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0 ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD b25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tQVUgbGluaz1ibHVlIHZsaW5rPXB1 cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz4mcXVvdDsvJnF1b3Q7IGlzIG5vdCB0aGUgcm9vdC4gSXQgaXMgYW4gaXRl bSBpbiB0aGUgcm9vdCBvYmplY3Qgd2l0aCBhbiBlbXB0eSBzdHJpbmcgYXMgaXRzIG5hbWUuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPkhlbmNlLCBNYXJ0aW7igJlzIGV4YW1wbGUg4oCcb2xk4oCdIGFuZCDigJxwYXRjaOKAnSB2 YWx1ZXMgYXJlIHZhbGlkLCBidXQgdGhleSBkb27igJl0IHByb2R1Y2UgaGlzIOKAnG5ld+KAnSB2 YWx1ZSwgbm9yIFBhdWzigJlzIGVycm9yLiBUaGV5IHByb2R1Y2UgeyAmcXVvdDthJnF1b3Q7OiB7 fSwgJnF1b3Q7JnF1b3Q7OiZxdW90O2ZvbyZxdW90OyB9LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+b2xk OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz7CoCB7ICZxdW90O2EmcXVvdDs6IHsgJnF1b3Q7YiZxdW90OzogJnF1b3Q7Zm9vJnF1 b3Q7IH0gfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5wYXRjaDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+wqAgeyAmcXVvdDttb3ZlJnF1b3Q7OiAmcXVvdDsv YS9iJnF1b3Q7LCAmcXVvdDt0byZxdW90OzogJnF1b3Q7LyZxdW90OyB9PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPm5ldzo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+wqAgeyAmcXVvdDthJnF1b3Q7OiB7fSwgJnF1b3Q7JnF1b3Q7OiZxdW90O2ZvbyZxdW90OyB9 PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UC5TLiBUaGUgZW1wdHkgc3RyaW5nICZx dW90OyZxdW90OyBpcyB0aGUgSlNPTi1Qb2ludGVyIHRvIHRoZSByb290LCB3aGljaCB3aWxsIG9m dGVuIGJlIGFuIG9iamVjdCwgb3IgYW4gYXJyYXksIGJ1dCBjb3VsZCBhbHNvIGJlIGEgc3RyaW5n LCBvciBudW1iZXIgZXRjLiBJIGd1ZXNzIHsmcXVvdDtyZW1vdmUmcXVvdDs6JnF1b3Q7JnF1b3Q7 fSBpcyB2YWxpZC4gSXQgbGVhdmVzIGFuIGVtcHR5IGRvY3VtZW50IChlZyBhIHJlc291cmNlIHdp dGggMCBieXRlcyksIHRob3VnaCB0aGF0IGlzbuKAmXQgYSB2YWxpZCBKU09OIHZhbHVlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2 IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBhcHBzLWRpc2N1c3MtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXSA8Yj5P biBCZWhhbGYgT2YgPC9iPlBhdWwgQy4gQnJ5YW48YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIDE4 IFNlcHRlbWJlciAyMDEyIDg6NTAgQU08YnI+PGI+VG86PC9iPiBNYXJ0aW4gVGhvbXNvbjxicj48 Yj5DYzo8L2I+IEFwcHMgRGlzY3VzczsgTWFyayBOb3R0aW5naGFtPGJyPjxiPlN1YmplY3Q6PC9i PiBSZTogW2FwcHMtZGlzY3Vzc10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWlldGYtYXBwc2F3Zy1qc29uLXBhdGNoLTA0LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPk9rYXksIEkgdGFrZSBpdCBiYWNrOyBJIHdhcyByZWZlcnJpbmcgdG8gYW4g b2JqZWN0LCB3aGljaCByb290IGNhbm5vdCBiZSBpbmZlcnJlZCB0byBiZS4gU28gd2UgaGF2ZSBh IGhvbGUgd2hlcmUgdGhlIHJvb3QgdmFsdWUgb2YgdGhlIGRvY3VtZW50IGlzIG5laXRoZXIgYW4g YXJyYXkgbm9yIGFuIG9iamVjdDsgaXQncyBtZXJlbHkgYSB2YWx1ZS4gUGVyaGFwcyBsYW5ndWFn ZSBzdGF0aW5nIHRoYXQgdGhlIHJvb3QgaXMgYW4gaW52YWxpZCAmcXVvdDt0byZxdW90OyB0YXJn ZXQsIGJlY2F1c2UgaXQgYWx3YXlzIGV4aXN0cy48YnI+PGJyPlBhdWwgPGJyPjxicj5PbiBNb24s IDIwMTItMDktMTcgYXQgMTU6MjEgLTA3MDAsIFBhdWwgQy4gQnJ5YW4gd3JvdGU6PGJyPjxicj48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+T24gTW9uLCAyMDEyLTA5LTE3IGF0IDE1 OjE1IC0wNzAwLCBNYXJ0aW4gVGhvbXNvbiB3cm90ZTogPG86cD48L286cD48L3A+PHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+UmVhZGluZyB0aGUgZGVzY3JpcHRpb24gb2YgJnF1b3Q7 bW92ZSZxdW90OywgSSBjYW4gaW5mZXIgdGhhdCB0aGUgaW50ZW50IGlzIHRvPG86cD48L286cD48 L3ByZT48cHJlPnNwZWNpZnkgdGhlIG5hbWUgb2YgdGhlIG5vZGUgc3VjaCB0aGF0LCBvbGRkb2Mj e21vdmV9ID09IG5ld2RvYyN7dG99PG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+PHByZT5UaGlzIGlzIHVubGlrZSBvdGhlciAmcXVvdDttb3ZlJnF1b3Q7IG9yICZx dW90O212JnF1b3Q7IGNvbW1hbmRzIHdoZXJlIHlvdSBhcmUgYWJsZSB0bzxvOnA+PC9vOnA+PC9w cmU+PHByZT5pZGVudGlmeSBhIGNvbnRhaW5lciBhcyB0aGUgdGFyZ2V0IG9mIGEgbW92ZS48bzpw PjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPm9sZDo8bzpwPjwv bzpwPjwvcHJlPjxwcmU+wqAgeyAmcXVvdDthJnF1b3Q7OiB7ICZxdW90O2ImcXVvdDs6ICZxdW90 O2ZvbyZxdW90OyB9IH08bzpwPjwvbzpwPjwvcHJlPjxwcmU+cGF0Y2g6PG86cD48L286cD48L3By ZT48cHJlPsKgIHsgJnF1b3Q7bW92ZSZxdW90OzogJnF1b3Q7L2EvYiZxdW90OywgJnF1b3Q7dG8m cXVvdDs6ICZxdW90Oy8mcXVvdDsgfTxvOnA+PC9vOnA+PC9wcmU+PHByZT5uZXc6PG86cD48L286 cD48L3ByZT48cHJlPiZuYnNwOyB7ICZxdW90O2EmcXVvdDs6IHt9LCAmcXVvdDtiJnF1b3Q7OiZx dW90O2ZvbyZxdW90OyB9PG86cD48L286cD48L3ByZT48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPlRo aXMgYXR0ZW1wdCBhdCB0aGUgJnF1b3Q7bW92ZSZxdW90OyBvcGVyYXRpb24gYWJvdmUgd2lsbCBm YWlsIGJlY2F1c2UgdGhlcmUgaXMgYWxyZWFkeSBhIHZhbHVlIGF0ICZxdW90Oy8mcXVvdDssIG5h bWVseSBhbiBvYmplY3QgY29udGFpbmluZyBhIHNvbGUgJnF1b3Q7YSZxdW90OyBtZW1iZXIuPGJy Pjxicj48YnI+PG86cD48L286cD48L3A+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+ SSBhc3N1bWUgdGhhdCBpdCBpcyBlbnRpcmVseSBpbnRlbnRpb25hbCB0aGF0IHRoaXMgaXMgbm90 IHN1cHBvcnRlZCw8bzpwPjwvbzpwPjwvcHJlPjxwcmU+YnV0IGl0IHdvdWxkIGJlIG5pY2UgdG8g Y2xhcmlmeSB0aGF0IHRoaXMgaXMgbm90IGEgZmVhdHVyZSB0aGF0IGlzPG86cD48L286cD48L3By ZT48cHJlPnByb3ZpZGVkLjxvOnA+PC9vOnA+PC9wcmU+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj5O b3Qgb25seSBpcyBpdCBlbnRpcmVseSBpbnRlbnRpb25hbCB0aGF0IGl0J3Mgbm90IHN1cHBvcnRl ZCwgaXQncyBhY3R1YWxseSBkb2N1bWVudGVkIGFzIHN1Y2guIFRvIHdpdCBpbiDCpzQuNDo8YnI+ PGJyPiZxdW90O0lmIHRoZSBsb2NhdGlvbiBpbiB0aGUgJ3RvJyBtZW1iZXIgcmVmZXJlbmNlcyBh IG1lbWJlciBvZiBhbiBleGlzdGluZyBvYmplY3QgaW4gdGhlIHRhcmdldCBkb2N1bWVudCwgaXQg aXMgYW4gZXJyb3IgY29uZGl0aW9uIGlmIGEgdmFsdWUgYXQgdGhlIHNwZWNpZmllZCBsb2NhdGlv biBhbHJlYWR5IGV4aXN0cy4uLiZxdW90OyBIZW5jZSwgaXQgd2lsbCBmYWlsIGFzIGluZGljYXRl ZCBhYm92ZS48YnI+PGJyPlBhdWw8YnI+PGJyPjxicj48bzpwPjwvbzpwPjwvcD48cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+LS1NYXJ0 aW48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPk9uIDE2 IFNlcHRlbWJlciAyMDEyIDIzOjI0LCBNYXJrIE5vdHRpbmdoYW0gJmx0OzxhIGhyZWY9Im1haWx0 bzptbm90QG1ub3QubmV0Ij5tbm90QG1ub3QubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3ByZT48cHJlPiZndDsgVGhpcyBkcmFmdCBpbmNvcnBvcmF0ZWQgc29tZSBtaW5vciBmZWVkYmFj ayBmcm9tIEphbWVzIGFuZCBtYWRlIGEgZmV3IGVycm9yIGNvbmRpdGlvbnMgZXhwbGljaXQuPG86 cD48L286cD48L3ByZT48cHJlPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+Jmd0OyBX aXRoIGl0IC0tIGFzc3VtaW5nIHRoYXQgdGhlIGRlY2lzaW9uIHRvIGtlZXAgJnF1b3Q7dGVzdCZx dW90OyBpbiBhcy1pcyAtLSBJICp0aGluayogd2UncmUgcmVhZHkgZm9yIFdHTEMgZm9yIGJvdGgg anNvbi1wb2ludGVyIGFuZCBqc29uLXBhdGNoLjxvOnA+PC9vOnA+PC9wcmU+PHByZT4mZ3Q7PG86 cD4mbmJzcDs8L286cD48L3ByZT48cHJlPiZndDsgQ2hlZXJzLDxvOnA+PC9vOnA+PC9wcmU+PHBy ZT4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwv cHJlPjxwcmU+Jmd0OyBCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8bzpwPjwvbzpwPjwvcHJlPjxw cmU+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT4mZ3Q7Jmd0OyBGcm9tOiA8YSBocmVm PSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc8L2E+PG86cD48L286cD48L3ByZT48cHJlPiZndDsmZ3Q7IFN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1hcHBzYXdnLWpzb24tcGF0Y2gtMDQudHh0PG86 cD48L286cD48L3ByZT48cHJlPiZndDsmZ3Q7IERhdGU6IDE3IFNlcHRlbWJlciAyMDEyIDY6MjI6 MjUgUE0gTlpTVDxvOnA+PC9vOnA+PC9wcmU+PHByZT4mZ3Q7Jmd0OyBUbzogPGEgaHJlZj0ibWFp bHRvOm1ub3RAbW5vdC5uZXQiPm1ub3RAbW5vdC5uZXQ8L2E+PG86cD48L286cD48L3ByZT48cHJl PiZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86cGJyeWFuQGFub2RlLmNhIj5wYnJ5YW5AYW5v ZGUuY2E8L2E+PG86cD48L286cD48L3ByZT48cHJlPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48 L3ByZT48cHJlPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPiZndDsmZ3Q7IEEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1wYXRjaC0wNC50eHQ8 bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jmd0OyZndDsgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBNYXJrIE5vdHRpbmdoYW0gYW5kIHBvc3RlZCB0byB0aGU8bzpwPjwvbzpwPjwvcHJl PjxwcmU+Jmd0OyZndDsgSUVURiByZXBvc2l0b3J5LjxvOnA+PC9vOnA+PC9wcmU+PHByZT4mZ3Q7 Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT4mZ3Q7Jmd0OyBGaWxlbmFtZTrCoMKgwqDC oMKgIGRyYWZ0LWlldGYtYXBwc2F3Zy1qc29uLXBhdGNoPG86cD48L286cD48L3ByZT48cHJlPiZn dDsmZ3Q7IFJldmlzaW9uOsKgwqDCoMKgwqAgMDQ8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jmd0OyZn dDsgVGl0bGU6wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgSlNPTiBQYXRjaDxvOnA+ PC9vOnA+PC9wcmU+PHByZT4mZ3Q7Jmd0OyBDcmVhdGlvbiBkYXRlOsKgwqDCoMKgwqDCoMKgwqAg MjAxMi0wOS0xNzxvOnA+PC9vOnA+PC9wcmU+PHByZT4mZ3Q7Jmd0OyBXRyBJRDrCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBhcHBzYXdnPG86cD48L286cD48L3ByZT48cHJlPiZndDsm Z3Q7IE51bWJlciBvZiBwYWdlczogMTU8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jmd0OyZndDsgVVJM OsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1wYXRjaC0wNC50eHQiPmh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtYXBwc2F3Zy1qc29uLXBh dGNoLTA0LnR4dDwvYT48bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jmd0OyZndDsgU3RhdHVzOsKgwqDC oMKgwqDCoMKgwqDCoCA8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtYXBwc2F3Zy1qc29uLXBhdGNoIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtYXBwc2F3Zy1qc29uLXBhdGNoPC9hPjxvOnA+PC9vOnA+PC9wcmU+PHBy ZT4mZ3Q7Jmd0OyBIdG1saXplZDrCoMKgwqDCoMKgwqDCoCA8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1wYXRjaC0wNCI+aHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hcHBzYXdnLWpzb24tcGF0Y2gtMDQ8L2E+PG86 cD48L286cD48L3ByZT48cHJlPiZndDsmZ3Q7IERpZmY6wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8 YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWFwcHNh d2ctanNvbi1wYXRjaC0wNCI+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1hcHBzYXdnLWpzb24tcGF0Y2gtMDQ8L2E+PG86cD48L286cD48L3ByZT48cHJlPiZndDsm Z3Q7PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPiZndDsmZ3Q7IEFic3RyYWN0OjxvOnA+PC9v OnA+PC9wcmU+PHByZT4mZ3Q7Jmd0O8KgwqAgSlNPTiBQYXRjaCBkZWZpbmVzIHRoZSBtZWRpYSB0 eXBlICZxdW90O2FwcGxpY2F0aW9uL2pzb24tcGF0Y2gmcXVvdDssIGEgSlNPTjxvOnA+PC9vOnA+ PC9wcmU+PHByZT4mZ3Q7Jmd0O8KgwqAgZG9jdW1lbnQgc3RydWN0dXJlIGZvciBleHByZXNzaW5n IGEgc2VxdWVuY2Ugb2Ygb3BlcmF0aW9ucyB0byBhcHBseTxvOnA+PC9vOnA+PC9wcmU+PHByZT4m Z3Q7Jmd0O8KgwqAgdG8gYSBKU09OIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wcmU+PHByZT4mZ3Q7 Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+PHByZT4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT4mZ3Q7Jmd0Ozxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT4mZ3Q7Jmd0OyBUaGUgSUVURiBTZWNyZXRhcmlhdDxv OnA+PC9vOnA+PC9wcmU+PHByZT4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT4m Z3Q7PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPiZndDsgLS08bzpwPjwvbzpwPjwvcHJlPjxw cmU+Jmd0OyBNYXJrIE5vdHRpbmdoYW08bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jmd0OyA8YSBocmVm PSJodHRwOi8vd3d3Lm1ub3QubmV0LyI+aHR0cDovL3d3dy5tbm90Lm5ldC88L2E+PG86cD48L286 cD48L3ByZT48cHJlPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+PHByZT4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPiZndDs8 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+PHByZT4mZ3Q7IGFwcHMtZGlz Y3VzcyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Jmd0OyA8YSBocmVmPSJtYWls dG86YXBwcy1kaXNjdXNzQGlldGYub3JnIj5hcHBzLWRpc2N1c3NAaWV0Zi5vcmc8L2E+PG86cD48 L286cD48L3ByZT48cHJlPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hcHBzLWRpc2N1c3MiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vYXBwcy1kaXNjdXNzPC9hPjxvOnA+PC9vOnA+PC9wcmU+PHByZT5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+PHByZT5h cHBzLWRpc2N1c3MgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT48cHJlPjxhIGhyZWY9Im1h aWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmciPmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzwvYT48bzpw PjwvbzpwPjwvcHJlPjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9hcHBzLWRpc2N1c3MiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYXBwcy1kaXNjdXNzPC9hPjxvOnA+PC9vOnA+PC9wcmU+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3By ZT48cHJlPmFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGEg aHJlZj0ibWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZyI+YXBwcy1kaXNjdXNzQGlldGYub3Jn PC9hPjxvOnA+PC9vOnA+PC9wcmU+PHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3VzcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hcHBzLWRpc2N1c3M8L2E+PG86cD48L286cD48L3ByZT48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E114FD10E3C3WSMSG3153Vsrv_-- From jasnell@gmail.com Mon Sep 17 19:36:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B5B21F8528 for ; Mon, 17 Sep 2012 19:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN2B2cvPhReb for ; Mon, 17 Sep 2012 19:36:27 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9F79721F8527 for ; Mon, 17 Sep 2012 19:36:26 -0700 (PDT) Received: by wgbdr1 with SMTP id dr1so4012803wgb.34 for ; Mon, 17 Sep 2012 19:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ha+fdPbnETR51yLPZVN39gBvgIvbESNhTVwgwzJEgpU=; b=M7sp/bt/d2gnoKq7UKGIN+Xew1QH+qxhlyRaBEP7pSRQMQ19w5FIcVJnD8z5ONpXiL cL52mIAarvvRR66XlqA2iev3TqwXzJQ6MrEmtl6G3Vbz6ATcdEVfiSoj16g4qFOiy7AO /2HiHcmM7xI9L0Y3ilrvDZDhMIWq2I2lQe8nSFLV2seaMHcFxJ0D/OUPzVahgjRUm1Bf lDKMs1H8lYMx8N4zUyoEu7moGkaA39mJ/P58+THt7NaIiwJM6RG8CHjzD8Q2G7WDkI81 WjjCsiIm4XXVrFqqgJlNdg82cfomNIOeggGTJSumUxilyHckZJyMgx/CC2WailA0E1u7 HHng== Received: by 10.180.100.35 with SMTP id ev3mr19955280wib.7.1347935785330; Mon, 17 Sep 2012 19:36:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.96.2 with HTTP; Mon, 17 Sep 2012 19:36:05 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FD10E3C3@WSMSG3153V.srv.dir.telstra.com> References: <20120917062225.31160.89210.idtracker@ietfa.amsl.com> <1347920475.19756.39.camel@pbryan-wsl.internal.salesforce.com> <1347922222.19756.67.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114FD10E3C3@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Mon, 17 Sep 2012 19:36:05 -0700 Message-ID: To: "Manger, James H" Content-Type: multipart/alternative; boundary=f46d044282a6aa287304c9f0c1b1 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-patch-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 02:36:28 -0000 --f46d044282a6aa287304c9f0c1b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ah! Good catch. My brain had completely misfiled that little detail. On Mon, Sep 17, 2012 at 7:33 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > "/" is not the root. It is an item in the root object with an empty strin= g > as its name.**** > > Hence, Martin=E2=80=99s example =E2=80=9Cold=E2=80=9D and =E2=80=9Cpatch= =E2=80=9D values are valid, but they don=E2=80=99t > produce his =E2=80=9Cnew=E2=80=9D value, nor Paul=E2=80=99s error. They p= roduce { "a": {}, "":"foo" > }.**** > > ** ** > > old:**** > > { "a": { "b": "foo" } }**** > > patch:**** > > { "move": "/a/b", "to": "/" }**** > > new:**** > > { "a": {}, "":"foo" }**** > > ** ** > > ** ** > > P.S. The empty string "" is the JSON-Pointer to the root, which will ofte= n > be an object, or an array, but could also be a string, or number etc. I > guess {"remove":""} is valid. It leaves an empty document (eg a resource > with 0 bytes), though that isn=E2=80=99t a valid JSON value.**** > > ** ** > > --**** > > James Manger**** > > ** ** > > *From:* apps-discuss-bounces@ietf.org [mailto: > apps-discuss-bounces@ietf.org] *On Behalf Of *Paul C. Bryan > *Sent:* Tuesday, 18 September 2012 8:50 AM > *To:* Martin Thomson > *Cc:* Apps Discuss; Mark Nottingham > *Subject:* Re: [apps-discuss] Fwd: New Version Notification for > draft-ietf-appsawg-json-patch-04.txt**** > > ** ** > > Okay, I take it back; I was referring to an object, which root cannot be > inferred to be. So we have a hole where the root value of the document is > neither an array nor an object; it's merely a value. Perhaps language > stating that the root is an invalid "to" target, because it always exists= . > > Paul > > On Mon, 2012-09-17 at 15:21 -0700, Paul C. Bryan wrote: > > **** > > On Mon, 2012-09-17 at 15:15 -0700, Martin Thomson wrote: **** > > ** ** > > > Reading the description of "move", I can infer that the intent is to**** > > specify the name of the node such that, olddoc#{move} =3D=3D newdoc#{to}*= *** > > ** ** > > > This is unlike other "move" or "mv" commands where you are able to**** > > identify a container as the target of a move.**** > > ** ** > > old:**** > > { "a": { "b": "foo" } }**** > > patch:**** > > { "move": "/a/b", "to": "/" }**** > > new:**** > > { "a": {}, "b":"foo" }**** > > > This attempt at the "move" operation above will fail because there is > already a value at "/", namely an object containing a sole "a" member. > > > **** > > ** ** > > I assume that it is entirely intentional that this is not supported,**** > > but it would be nice to clarify that this is not a feature that is**** > > provided.**** > > > Not only is it entirely intentional that it's not supported, it's actuall= y > documented as such. To wit in =C2=A74.4: > > "If the location in the 'to' member references a member of an existing > object in the target document, it is an error condition if a value at the > specified location already exists..." Hence, it will fail as indicated > above. > > Paul > > > **** > > ** ** > > ** ** > > --Martin**** > > ** ** > > On 16 September 2012 23:24, Mark Nottingham wrote:**** > > > This draft incorporated some minor feedback from James and made a few e= rror conditions explicit.**** > > >** ** > > > With it -- assuming that the decision to keep "test" in as-is -- I *thi= nk* we're ready for WGLC for both json-pointer and json-patch.**** > > >** ** > > > Cheers,**** > > >** ** > > >** ** > > > Begin forwarded message:**** > > >** ** > > >> From: internet-drafts@ietf.org**** > > >> Subject: New Version Notification for draft-ietf-appsawg-json-patch-04= .txt**** > > >> Date: 17 September 2012 6:22:25 PM NZST**** > > >> To: mnot@mnot.net**** > > >> Cc: pbryan@anode.ca**** > > >>** ** > > >>** ** > > >> A new version of I-D, draft-ietf-appsawg-json-patch-04.txt**** > > >> has been successfully submitted by Mark Nottingham and posted to the**= ** > > >> IETF repository.**** > > >>** ** > > >> Filename: draft-ietf-appsawg-json-patch**** > > >> Revision: 04**** > > >> Title: JSON Patch**** > > >> Creation date: 2012-09-17**** > > >> WG ID: appsawg**** > > >> Number of pages: 15**** > > >> URL: http://www.ietf.org/internet-drafts/draft-ietf-appsaw= g-json-patch-04.txt**** > > >> Status: http://datatracker.ietf.org/doc/draft-ietf-appsawg-js= on-patch**** > > >> Htmlized: http://tools.ietf.org/html/draft-ietf-appsawg-json-pa= tch-04**** > > >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg= -json-patch-04**** > > >>** ** > > >> Abstract:**** > > >> JSON Patch defines the media type "application/json-patch", a JSON**= ** > > >> document structure for expressing a sequence of operations to apply*= *** > > >> to a JSON document.**** > > >>** ** > > >>** ** > > >>** ** > > >>** ** > > >> The IETF Secretariat**** > > >>** ** > > >** ** > > > --**** > > > Mark Nottingham**** > > > http://www.mnot.net/**** > > >** ** > > >** ** > > >** ** > > >** ** > > > _______________________________________________**** > > > apps-discuss mailing list**** > > > apps-discuss@ietf.org**** > > > https://www.ietf.org/mailman/listinfo/apps-discuss**** > > _______________________________________________**** > > apps-discuss mailing list**** > > apps-discuss@ietf.org**** > > https://www.ietf.org/mailman/listinfo/apps-discuss**** > > ** ** > > ** ** > > _______________________________________________**** > > apps-discuss mailing list**** > > apps-discuss@ietf.org**** > > https://www.ietf.org/mailman/listinfo/apps-discuss**** > > ** ** > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d044282a6aa287304c9f0c1b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ah! Good catch. My brain had completel= y misfiled that little detail.=C2=A0

    On Mon, Sep 17, 2012 at 7:33 PM, Manger, James H <<= a href=3D"mailto:James.H.Manger@team.telstra.com" target=3D"_blank">James.H= .Manger@team.telstra.com> wrote:

    "/"= is not the root. It is an item in the root object with an empty string as = its name.

    Hence, Martin=E2=80=99s e= xample =E2=80=9Cold=E2=80=9D and =E2=80=9Cpatch=E2=80=9D values are valid, = but they don=E2=80=99t produce his =E2=80=9Cnew=E2=80=9D value, nor Paul=E2= =80=99s error. They produce { "a": {}, "":"foo&quo= t; }.

    = =C2=A0

    o= ld:

    =C2=A0 { "a": {= "b": "foo" } }

    patch:

    =C2=A0 { "move": "/a/b"= ;, "to": "/" }

    new:=

    =C2=A0 { "= a": {}, "":"foo" }

    =C2=A0

    =C2=A0

    P.S. The empty string &qu= ot;" is the JSON-Pointer to the root, which will often be an object, o= r an array, but could also be a string, or number etc. I guess {"remov= e":""} is valid. It leaves an empty document (eg a resource = with 0 bytes), though that isn=E2=80=99t a valid JSON value.<= /span>

    =C2=A0

    --

    James Manger

    = =C2=A0

    From: apps-discuss-bounces@ietf.org [mai= lto:apps= -discuss-bounces@ietf.org] On Behalf Of Paul C. Bryan
    Sent: Tuesday, 18 September 2012 8:50 AM
    To: Martin Thomso= n
    Cc: Apps Discuss; Mark Nottingham
    Subject: Re: [apps-= discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-patch-04= .txt

    =C2=A0<= /u>

    Okay, I take it back; I was referring to an o= bject, which root cannot be inferred to be. So we have a hole where the roo= t value of the document is neither an array nor an object; it's merely = a value. Perhaps language stating that the root is an invalid "to"= ; target, because it always exists.

    Paul

    On Mon, 2012-09-17 at 15:21 -0700, Paul C. Bryan wrote:

    On Mon, 2012-09-17 at 15:15 -= 0700, Martin Thomson wrote: 

    =C2=A0

    Reading the description of "move", I can infer that the intent is=
 to
    specify the name of the node such that, olddoc#=
{move} =3D=3D newdoc#{to}
    =C2=A0
    
This is unlike other "move" or "mv" commands where you =
are able to
    identify a container as the target of a=
 move.
    =C2=A0
    old:
    


    =C2=A0 { "a": { "b": "foo" } }=

    patch:
    =C2=A0 { "move": &q=
uot;/a/b", "to": "/" }
    new=
:
    


    =C2=A0 { "a": {}, "b":"foo" }<=
/u>

    This attempt at the "move" op=
eration above will fail because there is already a value at "/", =
namely an object containing a sole "a" member.
    



    =C2=A0
    I assume that=
 it is entirely intentional that this is not supported,
    =

    but it would be nice to clarify that this is not a feature that is<=
/u>
    


    provided.

    Not only is it=
 entirely intentional that it's not supported, it's actually docume=
nted as such. To wit in =C2=A74.4:

    "If the location in the '=
;to' member references a member of an existing object in the target doc=
ument, it is an error condition if a value at the specified location alread=
y exists..." Hence, it will fail as indicated above.
    


    Paul


    =C2=A0
    <=
u>=C2=A0
    --Martin
    =C2=
=A0
    On 16 September 2012 23:24, Mark Nottingham <mnot@mnot.net> wrote:
    


    > This draft incorporated some minor feedback from James and made a=
 few error conditions explicit.
    >=C2=A0
    > With it -- assuming that the decision to keep "te=
st" in as-is -- I *think* we're ready for WGLC for both json-point=
er and json-patch.
    


    >=C2=A0
    > Cheers,
    >=C2=A0
    >=C2=A0
    >=
; Begin forwarded message:
    >=C2=A0=

    >> From: internet-drafts@ietf.org
    


    >> Subject: New Version Notification for draft-ietf-appsawg-json=
-patch-04.txt
    >> Date: 17 September 2012 6:22=
:25 PM NZST
    >> To: mnot@mnot.net
    


    >> Cc: pbry=
an@anode.ca
    >>=C2=A0
    <=
pre>>>=C2=A0
    >> A new version of I-D, d=
raft-ietf-appsawg-json-patch-04.txt
    >> has been successfully submitted by Mark Nottingham and posted=
 to the
    >> IETF repository.
    >>=C2=A0
    >> Filename:=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 draft-ietf-appsawg-json-patch
    


    >> Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 04
    >> Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 JSON Patch
    >> Creation date:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
2012-09-17
    >> WG ID:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ap=
psawg
    


    >> Number of pages: 15
    >> URL:=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/internet-drafts/draft-ietf-appsa=
wg-json-patch-04.txt
    


    >> Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-p=
atch
    >> Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-ietf-app=
sawg-json-patch-04
    


    >> Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 http://www.ietf.org/rfcdiff?url2=3Ddraf=
t-ietf-appsawg-json-patch-04
    >>=C2=
=A0
    


    >> Abstract:
    >>=C2=A0=C2=A0 JSON P=
atch defines the media type "application/json-patch", a JSON
    >>=C2=A0=C2=A0 document structure for expressing =
a sequence of operations to apply
    


    >>=C2=A0=C2=A0 to a JSON document.
    >&=
gt;=C2=A0
    >>=C2=A0
    &g=
t;>=C2=A0
    >>=C2=A0
    >> The IETF Secretariat
    >>=C2=A0
    >=C2=A0
    <= pre>> --
    > Mark Nottingham
    > http://www.mn=
ot.net/
    


    >=C2=A0
    >=C2=A0
    =
>=C2=A0
    >=C2=A0
    > =
_______________________________________________
    >=
; apps-discuss mailing list
    


    > apps-d=
iscuss@ietf.org
    > https://www.ietf.org=
/mailman/listinfo/apps-discuss
    


    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org=

    https://www.ietf.org/mailman/listinfo/apps-discuss

    =C2=A0

    =C2=
=A0
    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org=

    https://www.ietf.org/mailman/listinfo/apps-discuss

    =C2=A0


    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss


    --f46d044282a6aa287304c9f0c1b1-- From pbryan@anode.ca Mon Sep 17 19:53:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8B921E80A0 for ; Mon, 17 Sep 2012 19:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 840-oJ9DlmTo for ; Mon, 17 Sep 2012 19:53:15 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 914B021E809C for ; Mon, 17 Sep 2012 19:53:15 -0700 (PDT) Received: from [10.71.13.58] (adsl-75-55-201-218.dsl.pltn13.sbcglobal.net [75.55.201.218]) by maple.anode.ca (Postfix) with ESMTPSA id 2EDB9616A; Tue, 18 Sep 2012 02:53:14 +0000 (UTC) Message-ID: <1347936793.2920.1.camel@polyglot> From: "Paul C. Bryan" To: "Manger, James H" Date: Mon, 17 Sep 2012 19:53:13 -0700 In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FD10E3C3@WSMSG3153V.srv.dir.telstra.com> References: <20120917062225.31160.89210.idtracker@ietfa.amsl.com> <1347920475.19756.39.camel@pbryan-wsl.internal.salesforce.com> <1347922222.19756.67.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114FD10E3C3@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="=-yG9f0ZS5tAZINoOLo6hL" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-patch-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 02:53:18 -0000 --=-yG9f0ZS5tAZINoOLo6hL Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit You're right, thanks! So, "/" would be a valid move-to location. "" would yield an error condition. Paul On Tue, 2012-09-18 at 12:33 +1000, Manger, James H wrote: > "/" is not the root. It is an item in the root object with an empty > string as its name. > > Hence, Martin’s example “old” and “patch” values are valid, but they > don’t produce his “new” value, nor Paul’s error. They produce { "a": > {}, "":"foo" }. > > > > old: > > { "a": { "b": "foo" } } > > patch: > > { "move": "/a/b", "to": "/" } > > new: > > { "a": {}, "":"foo" } > > > > > > P.S. The empty string "" is the JSON-Pointer to the root, which will > often be an object, or an array, but could also be a string, or number > etc. I guess {"remove":""} is valid. It leaves an empty document (eg a > resource with 0 bytes), though that isn’t a valid JSON value. > > > > > -- > > James Manger > > > > > > > From: apps-discuss-bounces@ietf.org > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul C. Bryan > Sent: Tuesday, 18 September 2012 8:50 AM > To: Martin Thomson > Cc: Apps Discuss; Mark Nottingham > Subject: Re: [apps-discuss] Fwd: New Version Notification for > draft-ietf-appsawg-json-patch-04.txt > > > > > > Okay, I take it back; I was referring to an object, which root cannot > be inferred to be. So we have a hole where the root value of the > document is neither an array nor an object; it's merely a value. > Perhaps language stating that the root is an invalid "to" target, > because it always exists. > > Paul > > On Mon, 2012-09-17 at 15:21 -0700, Paul C. Bryan wrote: > > > > On Mon, 2012-09-17 at 15:15 -0700, Martin Thomson wrote: > > > > Reading the description of "move", I can infer that the intent is to > specify the name of the node such that, olddoc#{move} == newdoc#{to} > > This is unlike other "move" or "mv" commands where you are able to > identify a container as the target of a move. > > old: > { "a": { "b": "foo" } } > patch: > { "move": "/a/b", "to": "/" } > new: > { "a": {}, "b":"foo" } > > > > This attempt at the "move" operation above will fail because there is > already a value at "/", namely an object containing a sole "a" member. > > > > > > > I assume that it is entirely intentional that this is not supported, > but it would be nice to clarify that this is not a feature that is > provided. > > > > Not only is it entirely intentional that it's not supported, it's > actually documented as such. To wit in §4.4: > > "If the location in the 'to' member references a member of an existing > object in the target document, it is an error condition if a value at > the specified location already exists..." Hence, it will fail as > indicated above. > > Paul > > > > > > > > --Martin > > On 16 September 2012 23:24, Mark Nottingham wrote: > > This draft incorporated some minor feedback from James and made a few error conditions explicit. > > > > With it -- assuming that the decision to keep "test" in as-is -- I *think* we're ready for WGLC for both json-pointer and json-patch. > > > > Cheers, > > > > > > Begin forwarded message: > > > >> From: internet-drafts@ietf.org > >> Subject: New Version Notification for draft-ietf-appsawg-json-patch-04.txt > >> Date: 17 September 2012 6:22:25 PM NZST > >> To: mnot@mnot.net > >> Cc: pbryan@anode.ca > >> > >> > >> A new version of I-D, draft-ietf-appsawg-json-patch-04.txt > >> has been successfully submitted by Mark Nottingham and posted to the > >> IETF repository. > >> > >> Filename: draft-ietf-appsawg-json-patch > >> Revision: 04 > >> Title: JSON Patch > >> Creation date: 2012-09-17 > >> WG ID: appsawg > >> Number of pages: 15 > >> URL: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-04.txt > >> Status: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch > >> Htmlized: http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04 > >> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-patch-04 > >> > >> Abstract: > >> JSON Patch defines the media type "application/json-patch", a JSON > >> document structure for expressing a sequence of operations to apply > >> to a JSON document. > >> > >> > >> > >> > >> The IETF Secretariat > >> > > > > -- > > Mark Nottingham > > http://www.mnot.net/ > > > > > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > --=-yG9f0ZS5tAZINoOLo6hL Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit You're right, thanks! So, "/" would be a valid move-to location. "" would yield an error condition.

    Paul

    On Tue, 2012-09-18 at 12:33 +1000, Manger, James H wrote:
    "/" is not the root. It is an item in the root object with an empty string as its name.

    Hence, Martin’s example “old” and “patch” values are valid, but they don’t produce his “new” value, nor Paul’s error. They produce { "a": {}, "":"foo" }.

     

    old:

      { "a": { "b": "foo" } }

    patch:

      { "move": "/a/b", "to": "/" }

    new:

      { "a": {}, "":"foo" }

     

     

    P.S. The empty string "" is the JSON-Pointer to the root, which will often be an object, or an array, but could also be a string, or number etc. I guess {"remove":""} is valid. It leaves an empty document (eg a resource with 0 bytes), though that isn’t a valid JSON value.

     

    --

    James Manger


     

    From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul C. Bryan
    Sent: Tuesday, 18 September 2012 8:50 AM
    To: Martin Thomson
    Cc: Apps Discuss; Mark Nottingham
    Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-patch-04.txt


     

    Okay, I take it back; I was referring to an object, which root cannot be inferred to be. So we have a hole where the root value of the document is neither an array nor an object; it's merely a value. Perhaps language stating that the root is an invalid "to" target, because it always exists.

    Paul

    On Mon, 2012-09-17 at 15:21 -0700, Paul C. Bryan wrote:



    On Mon, 2012-09-17 at 15:15 -0700, Martin Thomson wrote: 

     
Reading the description of "move", I can infer that the intent is to
specify the name of the node such that, olddoc#{move} == newdoc#{to}
 
This is unlike other "move" or "mv" commands where you are able to
identify a container as the target of a move.
 
old:
  { "a": { "b": "foo" } }
patch:
  { "move": "/a/b", "to": "/" }
new:
  { "a": {}, "b":"foo" }


    This attempt at the "move" operation above will fail because there is already a value at "/", namely an object containing a sole "a" member.




     
I assume that it is entirely intentional that this is not supported,
but it would be nice to clarify that this is not a feature that is
provided.


    Not only is it entirely intentional that it's not supported, it's actually documented as such. To wit in §4.4:

    "If the location in the 'to' member references a member of an existing object in the target document, it is an error condition if a value at the specified location already exists..." Hence, it will fail as indicated above.

    Paul




     
 
--Martin
 
On 16 September 2012 23:24, Mark Nottingham <mnot@mnot.net> wrote:
> This draft incorporated some minor feedback from James and made a few error conditions explicit.
> 
> With it -- assuming that the decision to keep "test" in as-is -- I *think* we're ready for WGLC for both json-pointer and json-patch.
> 
> Cheers,
> 
> 
> Begin forwarded message:
> 
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for draft-ietf-appsawg-json-patch-04.txt
>> Date: 17 September 2012 6:22:25 PM NZST
>> To: mnot@mnot.net
>> Cc: pbryan@anode.ca
>> 
>> 
>> A new version of I-D, draft-ietf-appsawg-json-patch-04.txt
>> has been successfully submitted by Mark Nottingham and posted to the
>> IETF repository.
>> 
>> Filename:      draft-ietf-appsawg-json-patch
>> Revision:      04
>> Title:                 JSON Patch
>> Creation date:         2012-09-17
>> WG ID:                 appsawg
>> Number of pages: 15
>> URL:             http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-04.txt
>> Status:          http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch
>> Htmlized:        http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04
>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-patch-04
>> 
>> Abstract:
>>   JSON Patch defines the media type "application/json-patch", a JSON
>>   document structure for expressing a sequence of operations to apply
>>   to a JSON document.
>> 
>> 
>> 
>> 
>> The IETF Secretariat
>> 
> 
> --
> Mark Nottingham
> http://www.mnot.net/
> 
> 
> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

     

     
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

     



    --=-yG9f0ZS5tAZINoOLo6hL-- From andy@hxr.us Tue Sep 18 04:08:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E719B21F8738 for ; Tue, 18 Sep 2012 04:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40UWu8ayHmRV for ; Tue, 18 Sep 2012 04:08:09 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF7E21F8735 for ; Tue, 18 Sep 2012 04:08:08 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4154560wgb.13 for ; Tue, 18 Sep 2012 04:08:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=ODOx2QxyiVT6rrIbGasDcvj/OhFvV7uY4ZpeLY+3/bU=; b=G3tmd0Bqlh5oytpsIqnEQQTbxZz7YVK5O9Lsj+DwEtvPe19rl6DWKXqRet6IUS2oMS SjA3P9Fot2u82rNQ6xr4YKoZTI2/PH/ZPJD0Jgnr/FuytSm9JUOlJwE/vHxhBY/E99gI Kvo+DcUtzSgPxIE/7WNJGOZBv8bSkJRXP3WXg/4/yfJa+bJjBbML4Ity63gEl1z1Awov beOsiRdpzAJP7nyaFG99B37Fi1JrMJ6BTuodtjTctEUj3qzLwJwLXlTcli5o2/6T2rfy zKsEgapw2uyIpWtzqpezyMi2PslFGXdRpg4K3ltLPrh5BBQxRxgLWG+G71KLxHRknSjm IIqw== MIME-Version: 1.0 Received: by 10.216.72.5 with SMTP id s5mr553391wed.154.1347966488109; Tue, 18 Sep 2012 04:08:08 -0700 (PDT) Received: by 10.217.83.75 with HTTP; Tue, 18 Sep 2012 04:08:08 -0700 (PDT) X-Originating-IP: [71.191.219.28] Date: Tue, 18 Sep 2012 07:08:08 -0400 Message-ID: From: Andrew Newton To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl0G+D/ZNUHFpTlKxLO2lKenqtKVlemLI1kFwGGgmFkfCQ3rNkitlYa7coX7cX+/S+C/Blh Subject: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 11:08:10 -0000 All, Excuse me for asking some basic questions. What is the current guidance for using RFC 4627 as a normative reference? And as that is a registration of the media type, is 4627 also an acceptable normative reference for the JSON syntax? -andy From hallam@gmail.com Tue Sep 18 04:35:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC6B21E80BA for ; Tue, 18 Sep 2012 04:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqvEF1aSyP7M for ; Tue, 18 Sep 2012 04:35:39 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9167F21E80B0 for ; Tue, 18 Sep 2012 04:35:39 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so11433639obb.31 for ; Tue, 18 Sep 2012 04:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0Z6RGSpiuXeZGlTgkk5X4SjaqT3XQo9fW9oh+pUs/dM=; b=E8EKreTeA0a4ELqPvj3eM/3cKVAX+3ROHy2eqvjfuxA+mh3RMJpRvqyFtrennm47Od WwNHk+Y3szZab0duFIxHcecqYgxdhkqpaPMWNq7rhdJsWn0433oCVpGcl9aMip7y2IGh vh2c+qL3GI5ojTdmKbAXD6anFSW4ZEHgI2QbHBoUaQe99ROYznif9SYyI5tj0nwHyelZ LBDusKcQLBTMQ4CbQV74vyAeRB1PG4UU8wQA/13WBsJebOf1CC4NQXjZuh9pLwpTdSb0 bdo1p6C6jXvbw96VxmU82mG4qLgHJC88SGytXUdhr58KcL2HwyvcKAdhUR9ylkopcAPT u4CA== MIME-Version: 1.0 Received: by 10.60.29.72 with SMTP id i8mr14456430oeh.26.1347968139141; Tue, 18 Sep 2012 04:35:39 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Tue, 18 Sep 2012 04:35:39 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Sep 2012 07:35:39 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Newton Content-Type: multipart/alternative; boundary=e89a8fb1f8061a22ff04c9f84a15 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 11:35:41 -0000 --e89a8fb1f8061a22ff04c9f84a15 Content-Type: text/plain; charset=ISO-8859-1 Didn't we do away with the 'down-reference' prohibition? So using an informational draft as a normative reference in a standards draft should be OK. As a practical matter it is easier to follow RFC 4627 than to fish the JSON spec out of the ECMA spec (at least the versions I have read). So I would cite RFC 4627 as normative.. But the ECMA specification is the original standard and they did the original work so they should probably get a non-normative reference. Which is of course backwards but that is pretty much a consequence of the original RFC being issued. It is pretty clear that change control for using JSON in application protocols is going to have to rest with IETF as the IETF criteria are going to be stricter. RFC4267 is not a sufficient description in my view, you have to state things such as whether the order of objects matters, what to do if an unexpected tag is encountered and several other issues. Those are issues for a protocol but not an application programming language. It probably makes sense if the IETF came to a consistent approach on such issues at some point in the future. On Tue, Sep 18, 2012 at 7:08 AM, Andrew Newton wrote: > All, > > Excuse me for asking some basic questions. What is the current > guidance for using RFC 4627 as a normative reference? And as that is a > registration of the media type, is 4627 also an acceptable normative > reference for the JSON syntax? > > -andy > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Website: http://hallambaker.com/ --e89a8fb1f8061a22ff04c9f84a15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Didn't we do away with the 'down-reference' prohibition? So usi= ng an informational draft as a normative reference in a standards draft sho= uld be OK.

    As a practical matter it is easier to follow = RFC 4627 than to fish the JSON spec out of the ECMA spec (at least the vers= ions I have read). So I would cite RFC 4627 as normative..=A0

    But the ECMA specification is the original standard and= they did the original work so they should probably get a non-normative ref= erence.

    Which is of course backwards but that is p= retty much a consequence of the original RFC being issued.


    It is pretty clear that change control f= or using JSON in application protocols is going to have to rest with IETF a= s the IETF criteria are going to be stricter. RFC4267 is not a sufficient d= escription in my view, you have to state things such as whether the order o= f objects matters, what to do if an unexpected tag is encountered and sever= al other issues.

    Those are issues for a protocol but not an application = programming language.=A0

    It probably makes sense i= f the IETF came to a consistent approach on such issues at some point in th= e future.

    On Tue, Sep 18, 2012 at 7:08 AM, Andrew Newt= on <a= ndy@hxr.us> wrote:
    All,

    Excuse me for asking some basic questions. What is the current
    guidance for using RFC 4627 as a normative reference? And as that is a
    registration of the media type, is 4627 also an acceptable normative
    reference for the JSON syntax?

    -andy
    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss



    --
    Website: http://hallambaker.com/

    --e89a8fb1f8061a22ff04c9f84a15-- From mmorley@mpcm.com Tue Sep 18 04:42:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D76D21E80A7 for ; Tue, 18 Sep 2012 04:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ua1PPv0BW55l for ; Tue, 18 Sep 2012 04:42:22 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1086921E80BB for ; Tue, 18 Sep 2012 04:42:21 -0700 (PDT) Received: by qcac10 with SMTP id c10so6199062qca.31 for ; Tue, 18 Sep 2012 04:42:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=c5CTILO2zpCif29alxB9ghTSx0g296ZbTkLT623oqXU=; b=G182KelGpG0skscN5n/h98DC4IpH4wKsZy1fHqdXBtmoxAu/FMJ02dJa5KDyNleGcg pYe2AuhE+EcWRp+pw0452YwmY2J18zwki9aMqHD4ekeo4mv7AQDXMnBz8qYwbEk/py+c DG3J2GJZ6fFjqrLJ4wFYNfyZO2wpz7nzMgoIqqj4mt0RaH2GdqRZomjggIo0R6R6otn2 cJFBGYBrbrsZR3OBuF+VdDmJZxRDNDmIo8VLVF02TeLDzUEHRhymLu1ziR/do/e6xpIg 13iXDMlDoPxypeNaN+FEPOPywgGtAsy8/nCcqr34RqkZsNc9yCRxIQpS4DmgFDQBJMb+ Mgww== MIME-Version: 1.0 Received: by 10.229.137.133 with SMTP id w5mr9347595qct.21.1347968541461; Tue, 18 Sep 2012 04:42:21 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.49.30.66 with HTTP; Tue, 18 Sep 2012 04:42:21 -0700 (PDT) In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> Date: Tue, 18 Sep 2012 07:42:21 -0400 X-Google-Sender-Auth: Ocfrm1_-wfhZP_lUbGBrK14-tDw Message-ID: From: Matthew Morley To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=00235452fd84150c4c04c9f86279 X-Gm-Message-State: ALoCoQl2NjyCXATKSEr6MVKAllhemeyYYLuX56BYLZcCJr+Hpxg6f13T6FbjOB8F1E7NXCgVvnx4 Subject: Re: [apps-discuss] JSON Patch: removing the "test" operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 11:42:24 -0000 --00235452fd84150c4c04c9f86279 Content-Type: text/plain; charset=ISO-8859-1 +1 Better to leave it in place if is is being used. On Mon, Sep 17, 2012 at 2:10 AM, Mark Nottingham wrote: > Personally -- I'm +1 on that; it has a certain amount of utility, and > while it doesn't do everything, I think it's good enough. > > > On 17/09/2012, at 3:42 AM, Paul C. Bryan wrote: > > > Alright, I propose we keep the test operation as documented in > draft-ietf-appsawg-json-patch-03. > > > > Paul > > > > On Sat, 2012-09-15 at 04:37 -0700, Mike McCabe wrote: > >> On 9/14/12 6:11 PM, Mark Nottingham wrote: > >> > Does anyone object to removing 'test' from json-patch? > >> > >> > >> I'm working on a production system for the Internet Archive that uses > >> json-patch to express metadata modifications. > >> > >> So far, it's been a great fit - and a very timely discovery. (I was > >> about to roll my own.) Thank you! > >> > >> > >> For some uses, we need protection against concurrent writes. I was > >> planning on using the 'test' operation for this (with a 'version' field) > >> as 'optimistic' concurrency control. (Locking isn't a good fit, as we > >> want to support writes from outside organizations.) > >> > >> I'd prefer that we not throw out 'test' without a good idea of what > >> might replace it, as there's no flexible, 'in-band' way to get > >> optimistic concurrency without it. > >> > >> > >> I'll try to answer a few of the objections to 'test' that I've seen: > >> > >> * It's unnecessary, as the other patch operations assume knowledge about > >> the document. (That is, errors in patch application will catch > >> unexpected concurrent changes.) > >> > >> -> While other operations can also fail if the document has changed such > >> that they can't apply, this won't catch changes that might have occurred > >> elsewhere in the document (that could be semantically important) > >> > >> (Also, most array operations will succeed even if the array has > changed.) > >> > >> > >> * It's unneeded given conditional HTTP, eTag or other mechanisms. > >> > >> -> json-patch is not HTTP PATCH, so these approaches may not be > available. > >> > >> They're 'out-of-band' - part of the information needed to apply the > >> patch is outside of the patch (and not a JSON document) > >> > >> They're less flexible; it's easy to imagine a larger JSON document that > >> had sub-documents, where only the sub-documents required atomic changes; > >> each could get it's own version field if needed. > >> > >> Sometimes concurrency control isn't important, or the only requirement > >> is that we don't overwrite if someone else got there first. > >> > >> > >> * It's different from the other operations. > >> > >> -> Other operations can abort the patch, just as test can; it's easily > >> implemented as an operation that happens to not change anything. > >> > >> > >> * It's an incomplete part of an otherwise-useful generic comparison > >> facility. > >> > >> -> For help with concurrency, 'test' *doesn't* need to be a generic > >> comparison facility. If I needed to do that, it would be more flexible > >> to pull document snippets with json-pointer, then do comparisons myself. > >> Testing value equality is enough; testing existence might be useful > >> for some cases. > >> > >> On Thu, Sep 13, 2012 at 8:10 AM, Matthew Morley < > >> matt@mpcm.com > >> > wrote: > >> > Most of the situations I am envisioning, which require more complex > >> > test operations, are were a patch is generated, but it needs to be > >> > selectively applied across a large set of json documents. If you know > >> > specifically which documents you need to apply patches to, you can > use > >> > the test operation pretty well. If you can generate multiple specific > >> > patches that also works well. But it is the compound, negative, and > >> > relationship tests that are the issues. > >> > >> I do see how a more general facility would be useful in this case. (Is > >> such a facility useful outside of json-patch?) > >> > >> > >> Can we get a proposal before removing 'test'? > >> > >> > >> > >> My implementation of json-patch is here: > >> > >> > >> https://github.com/mikemccabe/json-patch-php > >> > >> > >> A JSON test suite for json-patch is here: > >> > >> > >> https://github.com/mikemccabe/json-patch-tests > >> > >> > >> Regards, > >> Mike > >> > >> > >> > >> On 9/14/12 6:11 PM, Mark Nottingham wrote: > >> > > >> > Does anyone object to removing 'test' from json-patch? > >> > > >> > Regards, > >> > > >> > > >> > On 14/09/2012, at 2:30 AM, Paul C. Bryan < > >> pbryan@anode.ca > >> > wrote: > >> > > >> >> I could be persuaded to support removing test. > >> >> > >> >> Paul > >> >> > >> >> On Thu, 2012-09-13 at 14:06 +1000, Mark Nottingham wrote: > >> >>> So, what does this mean for the document? Should we remove the > 'test' operation (which may create further controversy), or leave it in > (assuming it will be extended / supplanted if someone designs a 'wrapper')? > >> >>> > >> >>> Regards, > >> >>> > >> >>> > >> >>> On 13/09/2012, at 2:15 AM, Paul C. Bryan < > >> >>> > >> pbryan@anode.ca > >> > >> >>>> wrote: > >> >>> > >> >>>> +1! > >> >>>> > >> >>>> On Wed, 2012-09-12 at 09:12 -0700, James M Snell wrote: > >> >>>>> Precisely. I've actually already began sketching up a rough and > will.. hopefully.. have the chance to prototype some code for it this > weekend to prove out the idea. > >> >>>>> > >> >>>>> On Wed, Sep 12, 2012 at 9:10 AM, Paul C. Bryan < > >> >>> > >> pbryan@anode.ca > >> > >> >>>> wrote: > >> >>>>> I currently imagine a "container" JSON-Test document, which would > contain a number of conditional expressions as well as the patch document > to apply if such tests prove true. I would wholeheartedly support such an > initiative, especially if it resulted in keeping JSON-Patch simple. :-) > >> >>>>> > >> >>>>> Paul > >> >>>>> > >> >>>>> > >> >>>>> On Tue, 2012-09-11 at 17:12 -0700, James M Snell wrote: > >> >>>>>> The more I look through this, the more I'm generally inclined to > agree. As was discussed in the separate thread I brought up about extending > json-patch, it is possible to define a super-set of json-patch that > introduces a range of potentially very useful predicate operations that > follow the same fundamental design as json-patch. Done properly, the two > can be layered in interesting ways. "test" can easily fit into the separate > specification, allowing json-patch to focus specifically on defining the > change operations. > >> >>>>>> > >> >>>>>> > >> >>>>>> - James > >> >>>>>> > >> >>>>>> On Tue, Sep 11, 2012 at 4:59 PM, Matthew Morley < > >> >>> > >> matt@mpcm.com > >> > >> >>>> wrote: > >> >>>>>> As long as there is a "test" operation, people are going to want > to extend it into something that matches complex conditionals that exist in > the base languages. I'm not convinced of the value in the operation as it > exists. I'm concerned about what it would become as well, to fit people's > real needs needs. > >> >>>>>> > >> >>>>>> My initial reaction was that I would use this operation to test > a 'version' field within the data at the top level. This way sequential > patching could indicate if a patch is sufficient to bring an object to a > certain state. But really in describing the patch, we are already making > the assumption that we are applying it to the right json later. Or > something 'right' enough. > >> >>>>>> > >> >>>>>> Conditional matching/logic is something worthy of a spec, but > I'm not convinced this is that specification. > >> >>>>>> > >> >>>>>> > >> >>>>>> How are people using the test operation in practice now? I'm > assuming only non-structured matching is recommended... or is deep > comparison of structured types suggested? > >> >>>>>> > >> >>>>>> Would this not be better handled outside of the work description > itself? > >> >>>>>> > >> >>>>>> > >> >>>>>> -- > >> >>>>>> Matt (MPCM) > >> >>>>>> > >> >>>>>> On Mon, Sep 10, 2012 at 2:59 PM, Paul C. Bryan < > >> >>> > >> pbryan@anode.ca > >> > >> >>>> wrote: > >> >>>>>> > >> >>>>>> On Mon, 2012-09-10 at 11:46 -0700, James M Snell wrote: > >> >>>>>> > >> >>>>>>> On Mon, Sep 10, 2012 at 10:34 AM, Paul C. Bryan < > >> >>> > >> pbryan@anode.ca > >> > >> >>>> wrote: > >> >>>>>>> Unfortunately, null is a testable value and should not be > interpreted to mean lack of value > >> >>>>>>> > >> >>>>>>> Indeed, but I'd argue that the two cases are semantically > equivalent enough for the such differences to be irrelevant. Particularly > since many (if not most) json vocabularies tend to treat null and undefined > as being equivalent. > >> >>>>>> > >> >>>>>> > >> >>>>>> While there are some languages that do not make this > distinction, I must disagree with your conclusion that it is irrelevant. In > JavaScript, null != undefined. The JSON specification went out of its way > to define an explicit null value. I do not want to create ambiguities in > the test operation, nor do I want to create incompatibilities with > different implementations where the treatment of null may be concerned. > >> >>>>>> > >> >>>>>> > >> >>>>>>> There is a clear use case for this and we can bind the scope > simply by saying that, within json patch, undefined and null are equivalent. > >> >>>>>> > >> >>>>>> > >> >>>>>> And what is the clear use case for this? > >> >>>>>> > >> >>>>>> Paul > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> _______________________________________________ > >> >>>>>> apps-discuss mailing list > >> >>>>>> > >> >>> > >> apps-discuss@ietf.org > >> > >> >>> > >> >>>>>> > >> >>> > >> https://www.ietf.org/mailman/listinfo/apps-discuss > >> > >> >>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> apps-discuss mailing list > >> >>>> > >> >>> > >> apps-discuss@ietf.org > >> > >> >>> > >> >>>> > >> >>> > >> https://www.ietf.org/mailman/listinfo/apps-discuss > >> > >> >>> > >> >>> > >> >>> -- > >> >>> Mark Nottingham > >> >>> > >> http://www.mnot.net/ > >> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >> > >> > > >> > -- > >> > Mark Nottingham > >> http://www.mnot.net/ > >> > >> > > >> > > >> > > >> > _______________________________________________ > >> > apps-discuss mailing list > >> > > >> apps-discuss@ietf.org > >> > >> > > >> https://www.ietf.org/mailman/listinfo/apps-discuss > >> > >> > > >> _______________________________________________ > >> apps-discuss mailing list > >> > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Mark Nottingham > http://www.mnot.net/ > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Matthew P. C. Morley --00235452fd84150c4c04c9f86279 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 =A0
    Better to leave it in place if is is being used.

    On Mon, Sep 17, 2012 at 2:10 AM, Mark Nottingham <mnot@mnot.= net> wrote:
    Personally -- I'm +1 on that; it has a c= ertain amount of utility, and while it doesn't do everything, I think i= t's good enough.


    On 17/09/2012, at 3:42 AM, Paul C. Bryan <pbryan@anode.ca> wrote:

    > Alright, I propose we keep the test operation as documented in draft-i= etf-appsawg-json-patch-03.
    >
    > Paul
    >
    > On Sat, 2012-09-15 at 04:37 -0700, Mike McCabe wrote:
    >> On 9/14/12 6:11 PM, Mark Nottingham wrote:
    >> =A0> Does anyone object to removing 'test' from json-pa= tch?
    >>
    >>
    >> I'm working on a production system for the Internet Archive th= at uses
    >> json-patch to express metadata modifications.
    >>
    >> So far, it's been a great fit - and a very timely discovery. = =A0(I was
    >> about to roll my own.) =A0Thank you!
    >>
    >>
    >> For some uses, we need protection against concurrent writes. =A0I = was
    >> planning on using the 'test' operation for this (with a &#= 39;version' field)
    >> as 'optimistic' concurrency control. =A0(Locking isn't= a good fit, as we
    >> want to support writes from outside organizations.)
    >>
    >> I'd prefer that we not throw out 'test' without a good= idea of what
    >> might replace it, as there's no flexible, 'in-band' wa= y to get
    >> optimistic concurrency without it.
    >>
    >>
    >> I'll try to answer a few of the objections to 'test' t= hat I've seen:
    >>
    >> * It's unnecessary, as the other patch operations assume knowl= edge about
    >> the document. =A0(That is, errors in patch application will catch<= br> >> unexpected concurrent changes.)
    >>
    >> -> While other operations can also fail if the document has cha= nged such
    >> that they can't apply, this won't catch changes that might= have occurred
    >> elsewhere in the document (that could be semantically important) >>
    >> (Also, most array operations will succeed even if the array has ch= anged.)
    >>
    >>
    >> * It's unneeded given conditional HTTP, eTag or other mechanis= ms.
    >>
    >> -> json-patch is not HTTP PATCH, so these approaches may not be= available.
    >>
    >> They're 'out-of-band' - part of the information needed= to apply the
    >> patch is outside of the patch (and not a JSON document)
    >>
    >> They're less flexible; it's easy to imagine a larger JSON = document that
    >> had sub-documents, where only the sub-documents required atomic ch= anges;
    >> each could get it's own version field if needed.
    >>
    >> Sometimes concurrency control isn't important, or the only req= uirement
    >> is that we don't overwrite if someone else got there first. >>
    >>
    >> * It's different from the other operations.
    >>
    >> -> Other operations can abort the patch, just as test can; it&#= 39;s easily
    >> implemented as an operation that happens to not change anything. >>
    >>
    >> * It's an incomplete part of an otherwise-useful generic compa= rison
    >> facility.
    >>
    >> -> For help with concurrency, 'test' *doesn't* need= to be a generic
    >> comparison facility. =A0If I needed to do that, it would be more f= lexible
    >> to pull document snippets with json-pointer, then do comparisons m= yself.
    >> =A0 Testing value equality is enough; testing existence might be u= seful
    >> for some cases.
    >>
    >> On Thu, Sep 13, 2012 at 8:10 AM, Matthew Morley <
    >> matt@mpcm.com
    >> > wrote:
    >> > Most of the situations I am envisioning, which require more c= omplex
    >> =A0> test operations, are were a patch is generated, but it nee= ds to be
    >> =A0> selectively applied across a large set of json documents. = If you know
    >> =A0> specifically which documents you need to apply patches to,= you can use
    >> =A0> the test operation pretty well. If you can generate multip= le specific
    >> > patches that also works well. But it is the compound, negativ= e, and
    >> =A0> relationship tests that are the issues.
    >>
    >> I do see how a more general facility would be useful in this case.= =A0(Is
    >> such a facility useful outside of json-patch?)
    >>
    >>
    >> Can we get a proposal before removing 'test'?
    >>
    >>
    >>
    >> My implementation of json-patch is here:
    >>
    >>
    >> https://github.com/mikemccabe/json-patch-php
    >>
    >>
    >> A JSON test suite for json-patch is here:
    >>
    >>
    >> https://github.com/mikemccabe/json-patch-tests
    >>
    >>
    >> Regards,
    >> Mike
    >>
    >>
    >>
    >> On 9/14/12 6:11 PM, Mark Nottingham wrote:
    >> >
    >> > Does anyone object to removing 'test' from json-patch= ?
    >> >
    >> > Regards,
    >> >
    >> >
    >> > On 14/09/2012, at 2:30 AM, Paul C. Bryan <
    >> pbryan@anode.ca
    >> > wrote:
    >> >
    >> >> I could be persuaded to support removing test.
    >> >>
    >> >> Paul
    >> >>
    >> >> On Thu, 2012-09-13 at 14:06 +1000, Mark Nottingham wrote:=
    >> >>> So, what does this mean for the document? Should we r= emove the 'test' operation (which may create further controversy), = or leave it in (assuming it will be extended / supplanted if someone design= s a 'wrapper')?
    >> >>>
    >> >>> Regards,
    >> >>>
    >> >>>
    >> >>> On 13/09/2012, at 2:15 AM, Paul C. Bryan <
    >> >>>
    >> pbryan@anode.ca
    >>
    >> >>>> wrote:
    >> >>>
    >> >>>> +1!
    >> >>>>
    >> >>>> On Wed, 2012-09-12 at 09:12 -0700, James M Snell = wrote:
    >> >>>>> Precisely. I've actually already began sk= etching up a rough and will.. hopefully.. have the chance to prototype some= code for it this weekend to prove out the idea.
    >> >>>>>
    >> >>>>> On Wed, Sep 12, 2012 at 9:10 AM, Paul C. Brya= n <
    >> >>>
    >> pbryan@anode.ca
    >>
    >> >>>> wrote:
    >> >>>>> I currently imagine a "container" J= SON-Test document, which would contain a number of conditional expressions = as well as the patch document to apply if such tests prove true. I would wh= oleheartedly support such an initiative, especially if it resulted in keepi= ng JSON-Patch simple. :-)
    >> >>>>>
    >> >>>>> Paul
    >> >>>>>
    >> >>>>>
    >> >>>>> On Tue, 2012-09-11 at 17:12 -0700, James M Sn= ell wrote:
    >> >>>>>> The more I look through this, the more I&= #39;m generally inclined to agree. As was discussed in the separate thread = I brought up about extending json-patch, it is possible to define a super-s= et of json-patch that introduces a range of potentially very useful predica= te operations that follow the same fundamental design as json-patch. Done p= roperly, the two can be layered in interesting ways. "test" can e= asily fit into the separate specification, allowing json-patch to focus spe= cifically on defining the change operations.
    >> >>>>>>
    >> >>>>>>
    >> >>>>>> - James
    >> >>>>>>
    >> >>>>>> On Tue, Sep 11, 2012 at 4:59 PM, Matthew = Morley <
    >> >>>
    >> matt@mpcm.com
    >>
    >> >>>> wrote:
    >> >>>>>> As long as there is a "test" op= eration, people are going to want to extend it into something that matches = complex conditionals that exist in the base languages. I'm not convince= d of the value in the operation as it exists. I'm concerned about what = it would become as well, to fit people's real needs needs.
    >> >>>>>>
    >> >>>>>> My initial reaction was that I would use = this operation to test a 'version' field within the data at the top= level. This way sequential patching could indicate if a patch is sufficien= t to bring an object to a certain state. But really in describing the patch= , we are already making the assumption that we are applying it to the right= json later. Or something 'right' enough.
    >> >>>>>>
    >> >>>>>> Conditional matching/logic is something w= orthy of a spec, but I'm not convinced this is that specification.
    >> >>>>>>
    >> >>>>>>
    >> >>>>>> How are people using the test operation i= n practice now? I'm assuming only non-structured matching is recommende= d... or is deep comparison of structured types suggested?
    >> >>>>>>
    >> >>>>>> Would this not be better handled outside = of the work description itself?
    >> >>>>>>
    >> >>>>>>
    >> >>>>>> --
    >> >>>>>> Matt (MPCM)
    >> >>>>>>
    >> >>>>>> On Mon, Sep 10, 2012 at 2:59 PM, Paul C. = Bryan <
    >> >>>
    >> pbryan@anode.ca
    >>
    >> >>>> wrote:
    >> >>>>>>
    >> >>>>>> On Mon, 2012-09-10 at 11:46 -0700, James = M Snell wrote:
    >> >>>>>>
    >> >>>>>>> On Mon, Sep 10, 2012 at 10:34 AM, Pau= l C. Bryan <
    >> >>>
    >> pbryan@anode.ca
    >>
    >> >>>> wrote:
    >> >>>>>>> Unfortunately, null is a testable val= ue and should not be interpreted to mean lack of value
    >> >>>>>>>
    >> >>>>>>> Indeed, but I'd argue that the tw= o cases are semantically equivalent enough for the such differences to be i= rrelevant. Particularly since many (if not most) json vocabularies tend to = treat null and undefined as being equivalent.
    >> >>>>>>
    >> >>>>>>
    >> >>>>>> While there are some languages that do no= t make this distinction, I must disagree with your conclusion that it is ir= relevant. In JavaScript, null !=3D undefined. The JSON specification went o= ut of its way to define an explicit null value. I do not want to create amb= iguities in the test operation, nor do I want to create incompatibilities w= ith different implementations where the treatment of null may be concerned.=
    >> >>>>>>
    >> >>>>>>
    >> >>>>>>> There is a clear use case for this an= d we can bind the scope simply by saying that, within json patch, undefined= and null are equivalent.
    >> >>>>>>
    >> >>>>>>
    >> >>>>>> And what is the clear use case for this?<= br> >> >>>>>>
    >> >>>>>> Paul
    >> >>>>>>
    >> >>>>>>
    >> >>>>>>
    >> >>>>>> _________________________________________= ______
    >> >>>>>> apps-discuss mailing list
    >> >>>>>>
    >> >>>
    >> apps-discuss@ietf.org=
    >>
    >> >>>
    >> >>>>>>
    >> >>>
    >> https://www.ietf.org/mailman/listinfo/apps-discuss
    >>
    >> >>>
    >> >>>>>>
    >> >>>>>>
    >> >>>>>>
    >> >>>>>>
    >> >>>>>>
    >> >>>>>>
    >> >>>>>
    >> >>>>>
    >> >>>>>
    >> >>>>
    >> >>>> _______________________________________________ >> >>>> apps-discuss mailing list
    >> >>>>
    >> >>>
    >> apps-discuss@ietf.org=
    >>
    >> >>>
    >> >>>>
    >> >>>
    >> https://www.ietf.org/mailman/listinfo/apps-discuss
    >>
    >> >>>
    >> >>>
    >> >>> --
    >> >>> Mark Nottingham
    >> >>>
    >> http://www.mnot= .net/
    >>
    >> >>>
    >> >>>
    >> >>>
    >> >>>
    >> >>>
    >> >>
    >> >
    >> > --
    >> > Mark Nottingham
    >> http://www.mnot= .net/
    >>
    >> >
    >> >
    >> >
    >> > _______________________________________________
    >> > apps-discuss mailing list
    >> >
    >> apps-discuss@ietf.org=
    >>
    >> >
    >> https://www.ietf.org/mailman/listinfo/apps-discuss
    >>
    >> >
    >> _______________________________________________
    >> apps-discuss mailing list
    >>
    >> apps-discuss@ietf.org=
    >> https://www.ietf.org/mailman/listinfo/apps-discuss
    >
    > _______________________________________________
    > apps-discuss mailing list
    > apps-discuss@ietf.org
    > https://www.ietf.org/mailman/listinfo/apps-discuss

    --
    Mark Nottingham
    http://www.mnot.net/=




    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss



    --
    = Matthew P. C. Morley
    --00235452fd84150c4c04c9f86279-- From julian.reschke@gmx.de Tue Sep 18 04:51:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C5F21E80BE for ; Tue, 18 Sep 2012 04:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=-0.970, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cN89tf33PGaJ for ; Tue, 18 Sep 2012 04:51:51 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id C502221F870F for ; Tue, 18 Sep 2012 04:51:50 -0700 (PDT) Received: (qmail invoked by alias); 18 Sep 2012 11:51:49 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp012) with SMTP; 18 Sep 2012 13:51:49 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+/YZcb+K+/5ZgvZ/zbE5jJfVdsW5oB9Bb3xpysUu ynJSeB61BQO5O4 Message-ID: <50586051.1040005@gmx.de> Date: Tue, 18 Sep 2012 13:51:45 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andrew Newton References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 11:51:51 -0000 On 2012-09-18 13:08, Andrew Newton wrote: > All, > > Excuse me for asking some basic questions. What is the current > guidance for using RFC 4627 as a normative reference? And as that is a > registration of the media type, is 4627 also an acceptable normative > reference for the JSON syntax? > ... As far as I can tell, JSON is fully defined by in RFC 4627 (both the media type and the syntax). Best regards, Julian From mmorley@mpcm.com Tue Sep 18 05:06:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D294C21F876E for ; Tue, 18 Sep 2012 05:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksAORE-d1tEl for ; Tue, 18 Sep 2012 05:06:00 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1AD21F8629 for ; Tue, 18 Sep 2012 05:05:59 -0700 (PDT) Received: by qadz3 with SMTP id z3so2461240qad.10 for ; Tue, 18 Sep 2012 05:05:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=++QJfZ2poHzTv6CeHjxJ0kJj+of3Sb7Rgbbs9XlQ1Rc=; b=HzZZhv93B2JfPd8C+C0wIKRirGcKvTU6bRHP4yVYdsQ+vr6Wm711EQmX4fUPdpsxXN mLbB30xYUBHdT4KJszQCgMFK07M4R3Olz13PfvQplayzkSgMIqWNSAY/qcDVehjpLaXI hkB5bZwu1Noedf/l/eaxNMaDll8xAVlg9jOqXEElm0z5lADtwV50KHqcOJqpxTeYEDy1 IqoMNW/SdVZ+vowCLr5aC4ledOcno/CaS/1Low0xwrc2hw8ZHwEZMtU7p+KysVKgBao3 Yju9E09jr2eDKAb11trKBIBXgmjC3tKD12cOttrx/5EebxhWRCk4o5sk6NXmG9ZK4+ck M3kA== MIME-Version: 1.0 Received: by 10.224.138.143 with SMTP id a15mr1024863qau.64.1347969959341; Tue, 18 Sep 2012 05:05:59 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.49.30.66 with HTTP; Tue, 18 Sep 2012 05:05:59 -0700 (PDT) In-Reply-To: References: <1347930121.19756.145.camel@pbryan-wsl.internal.salesforce.com> Date: Tue, 18 Sep 2012 08:05:59 -0400 X-Google-Sender-Auth: 41g3cY1BlNJaCz8Ge3lr5DwXeC4 Message-ID: From: Matthew Morley To: James M Snell Content-Type: multipart/alternative; boundary=20cf3074d77c982ed504c9f8b64e X-Gm-Message-State: ALoCoQliA4VyQXVTqdkG3T7gZ7slYod+EXn695B0aqz1uGcqyFNvHOFwCrB2eR4Rosl3nqMULMEM Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Early Initial Draft: JSON-Test (was Re: JSON Patch: extensibility) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 12:06:01 -0000 --20cf3074d77c982ed504c9f8b64e Content-Type: text/plain; charset=ISO-8859-1 I used a less verbose json structure to do something along the same lines... calling it 'minimum change communication' (MMC). This was the use case: - Client requests a full json object from the server - the object comes with a version field (integer) - Client sends a change request to the server for the object - also sending the version field it knows about - If a request comes in with a matching version field - responses to the request can be easily expressed in a diff - if a request comes in and doesn't match - additional handling may be needed if other clients have already changed the structure significantly - the request may be processed anyway, but the UI can then also brought into the loop - "the last change you requested was prevented due to other editors actions" The one portion where this deviated for me, with MCC, is that I communicated what values the server set, *not* just the values that changed. This way, details of the servers actions could be used to trigger additional actions within the client, even if the field value was the same. I'm not promoting this approach, but it can be an issue when your client needs awareness of the action, more than the change in value. Json patch can be used in this way with a same value replace, but it does impact how you generate the patch. On Mon, Sep 17, 2012 at 9:13 PM, James M Snell wrote: > The interpolation case is a bit abstract and deals more with allowing for > fail-fast (checking to see if an operation could succeed before actually > attempting the operation) as well as ensuring success in cases where the > target resource may not actually be a json document and a preceding change > might potentially trigger an unintended change of state. (This is largely > experimental for now so I can be easily swayed in either direction with a > solid enough argument :-) ...) > > For example, suppose I have a resource that can be represented as JSON, > but implements a rule that the "/updated" property is to be modified > automatically whenever any of it's other discreet fields are modified. A > client may not be aware of this semantic and may attempt to set the > "/updated" and "/title" values... > > [ > {"replace":"/title","value":"foo"}, > {"replace":"/updated", "value":"2012-12-12T12:12:12Z"} > {"test":"/updated", "value":"2012-12-12T12:12:12Z"} > ] > > The test ensures that the patch as a whole will only succeed if the value > of "/updated" is precisely the value intended by the sender. > > Yes, this is a fairly contrived example.. like I said, I'm more than > willing to be convinced that I'm just being silly. > > - James > > On Mon, Sep 17, 2012 at 6:02 PM, Paul C. Bryan wrote: > >> ** >> Some comments off the top of my head: >> >> 1. I'd probably like to understand more about the interpolation usage, >> especially its utility value before defaulting to my preference for option >> A. :-) >> 2. I happen to think that the introduction of a new media type will >> probably be necessary. >> 3. I like your thinking about logical (a.k.a "aggregate" in your >> document) operations: "and", "or", "not". >> 4. Though I have no concrete use case so far, there's something very >> attractive to me about having something wrap a set of conditions around >> something else that can be processed. >> >> Paul >> >> >> On Mon, 2012-09-17 at 16:56 -0700, James M Snell wrote: >> >> Ok.. working through some possible ways of manifesting the predicate >> operations within a JSON-Patch context... there are two possible options >> that I see... >> >> >> >> (A) One is to use something like the example syntax Paul suggests in >> his previous note... >> >> >> >> { >> >> "tests": [ >> >> { "less-than": "/some/path", "value": 42 }, >> >> { "test": "/some/other/path" }, >> >> { "contains": "/foo/bar", "value": "Major-General" } >> >> ], "application/json-patch": [ >> >> { "replace": "/some/path", "value": 42 }, >> >> { "delete": "/some/other/path" }, >> >> { "add": "/yet/another/path", "value": "bar!" } >> >> ] >> >> } >> >> >> >> (B) Another is to introduce an optional "predicate" member on the >> JSON-Patch "test" operation, such that a "test" operation would only >> succeed if, and only if, the attached predicate evaluates true: >> >> >> >> [ >> >> {"test": "/", >> >> "predicate": { >> >> "and": [ >> >> { "less-than": "/some/path", "value": 42 }, >> >> { "test": "/some/other/path" }, >> >> { "contains": "/foo/bar", "value": "Major-General" } >> >> ] >> >> } >> >> }, >> >> { "replace": "/some/path", "value": 42 }, >> >> { "delete": "/some/other/path" }, >> >> { "add": "/yet/another/path", "value": "bar!" } >> >> ] >> >> >> >> Running through the various cases, option (B) seems to be a cleaner >> mapping overall. Note that in this case, the JSON-Pointer value specified >> by the "test" member identifies the base reference point for the predicate. >> >> >> >> One of the main reasons I prefer (B) is that it allows me a clean way >> of interpolating predicate checks throughout the patch document. >> >> >> >> Option (B) also allows us to get by without necessarily creating a new >> base document type and media type. >> >> >> >> Thoughts? >> >> >> >> - James >> >> >> On Mon, Sep 17, 2012 at 12:39 PM, James M Snell >> wrote: >> >> Here is the early initial draft of JSON-Test ... this is not yet >> published as an I-D. I need to fill in some of the additional detail and >> examples around the basic predicate operations. However, the key elements >> are in place. I will try to get this published either tonight or tomorrow >> at the latest >> >> >> >> http://goo.gl/osKeI <== Links to my Github repo >> >> >> >> As always, feedback is more than welcome. >> >> >> >> - James >> >> >> >> On Mon, Sep 17, 2012 at 12:33 PM, Paul C. Bryan >> wrote: >> >> On Mon, 2012-09-17 at 17:32 +1000, Manger, James H wrote: >> >> The JSON patch spec looks good: draft-ietf-appsawg-json-patch-04. >> >> There is no explicit mention of extensibility of the JSON patch syntax. >> Presumably new operations (beyond add/remove/replace/move/copy/test) could >> be added, with the understanding that "old" implementations will reject >> such documents [section 4 says an unknown operation is an error]. Adding >> extra fields to an existing operation is less clear (eg >> {"add":"/foo/1","value":"baz","repeat":10}). There is no explicit mention >> that that would be an error. Perhaps implementations will ignore >> unrecognized fields. >> >> >> >> I had envisioned a container document type, which would enumerate a >> set of conditions that must be met before processing the operations an >> associated (contained) JSON Patch document. Taking this approach means that >> there is no confusion over what's a JSON Patch document vs. the extension >> document type. Since JSON Patch is an array of operation objects, such a >> structure would remain relatively straightforward. >> >> More concretely, perhaps something like: >> >> { "tests": [ { "less-than": "/some/path", "value": 42 }, { "exists": "/some/other/path" }, { "not-exists": "/yet/another/path" }, >> { "contains": "/foo/bar", "value": "Major-General" } ], "application/json-patch": [ { "replace": "/some/path", "value": 42 }, { "delete": "/some/other/path" }, { "add": "/yet/another/path", "value": "bar!" } ]} >> >> >> Thoughts? >> >> >> >> Could more sophisticated future test rules define, say, a "test2" >> operation? Or is it the expectation that such a syntax would need a new >> media type? >> >> >> >> I would say any extension should require its own media type. >> >> >> >> Each operation lists a full JSON pointer from the root of the resource. >> If you want to replace a dozen fields in a deeply nested object you need to >> repeat the path to that object a dozen times. This may be a reasonable >> compromise to avoid a more complex patch structure (particularly if >> compression removes much of the overhead), but I wasn't sure if any >> alternative had been considered. For example, >> {"patch":"/fee/fie/fo/fum/foo","value":[{"add":"x","value":"baz"},{"add":"y","value":3}]}. >> >> >> >> We've considered alternatives in the past, but concluded that given >> the verbosity of the JSON Patch document, the likely strategy to reduce >> size would be through compression. As such, multiple similar paths would >> compress fairly well. >> >> >> >> Would I be opening a can of worms (or doing some bike-shedding) if I >> asked why application/json-patch instead of application/patch+json? >> >> >> >> Probably. I originally proposed application/patch+json. The main >> problem with application/patch+json is that it implies that there are other >> representations of application/patch, not just JSON (e.g. >> application/patch+xml). In this case, JSON Patch is meant to address * >> only* JSON documents in a JSON format. Furthermore, I'm not yet aware of >> a specification for JSON like there is is for XML that promotes the >> addition of +json. Therefore, I'd say that application/json-patch is >> probably the better choice. >> >> Paul >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> >> >> >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- Matthew P. C. Morley --20cf3074d77c982ed504c9f8b64e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I used a less verbose json structure to do something along the same lines..= . calling it 'minimum change communication' (MMC).

    This was the use case:
    • Client requests a full json obj= ect from the server
      • the object comes with a version field (integer)
    • Client= sends a =A0change request to the server for the object
      • also se= nding the version field it knows about
    • If a request comes in w= ith a matching version field
      • responses to the request can be easily expressed in a diff
      • if a request comes in and doesn't match
        • additional han= dling may be needed if other clients have already changed the structure sig= nificantly
        • the request may be processed anyway, but the UI can then also brought i= nto the loop
          • "the last change you requested was prevented = due to other editors actions"

    The on= e portion where this deviated for me, with MCC, is that I communicated what= values the server set, *not* just the values that changed. This way, detai= ls of the servers actions could be used to trigger additional actions withi= n the client, even if the field value was the same.

    I'm not promoting this approach, but it can be an issue when your c= lient needs awareness of the action, more than the change in value. Json pa= tch can be used in this way with a same value replace, but it does impact h= ow you generate the patch.



    On Mon, S= ep 17, 2012 at 9:13 PM, James M Snell <jasnell@gmail.com> wr= ote:
    The int= erpolation case is a bit abstract and deals more with allowing for fail-fas= t (checking to see if an operation could succeed before actually attempting= the operation) as well as ensuring success in cases where the target resou= rce may not actually be a json document and a preceding change might potent= ially trigger an unintended change of state. (This is largely experimental = for now so I can be easily swayed in either direction with a solid enough a= rgument :-) ...)

    For example, suppose I have a resource that can be r= epresented as JSON, but implements a rule that the "/updated" pro= perty is to be modified automatically whenever any of it's other discre= et fields are modified. A client may not be aware of this semantic and may = attempt to set the "/updated" and "/title" values...

    [
    =A0 {"replace":"/title","value":&qu= ot;foo"},
    =A0 {"replace":"/= updated", "value":"2012-12-12T12:12:12Z"}
    =A0 {"test":"= /updated", "value":"2012-12-12T12:12:12Z"}
    ]

    The test ensures that the patch as a whole will only succeed if t= he value of "/updated" is precisely the value intended by the sen= der.

    Yes, this is a fairly contrived example.. like = I said, I'm more than willing to be convinced that I'm just being s= illy.

    <= div>- James
    <= div>
    On Mon, Sep 17, 2012 at 6:02 PM, Paul C. Bryan <= span dir=3D"ltr"><p= bryan@anode.ca> wrote:
    =20 =20
    Some comments off the top of my head:

    1. I'd probably like to understand more about the interpolation usage, = especially its utility value before defaulting to my preference for option = A. :-)
    2. I happen to think that the introduction of a new media type will probabl= y be necessary.
    3. I like your thinking about logical (a.k.a "aggregate" in your = document) operations: "and", "or", "not".
    4. Though I have no concrete use case so far, there's something very at= tractive to me about having something wrap a set of conditions around somet= hing else that can be processed.

    Paul


    On Mon, 2012-09-17 at 16:56 -0700, James M Snell wrote:
    Ok.. working through some possible ways of manifesting the predicate op= erations within a JSON-Patch context... there are two possible options that= I see...=A0


    (A) One is to use something like the example syntax Paul suggests in hi= s previous note...


    =A0 {
    =A0 =A0 "tests": [
    =A0 =A0 =A0 =A0 { "less-than": "/some/path", "= value": 42 },
    =A0 =A0 =A0 =A0 { "test": "/some/other/path" },
    =A0 =A0 =A0 =A0 { "contains": "/foo/bar", "val= ue": "Major-General" }
    =A0 =A0 ], "application/json-patch": [
    =A0 =A0 =A0 =A0 { "replace": "/some/path", "va= lue": 42 },
    =A0 =A0 =A0 =A0 { "delete": "/some/other/path" },
    =A0 =A0 =A0 =A0 { "add": "/yet/another/path", "= ;value": "bar!" }
    =A0 =A0 ]
    =A0 }


    (B) Another is to introduce an optional "predicate" member on= the JSON-Patch "test" operation, such that a "test" op= eration would only succeed if, and only if, the attached predicate evaluate= s true:


    =A0 [
    =A0 =A0 {"test": "/",
    =A0 =A0 =A0"predicate": {
    =A0 =A0 =A0 =A0"and": [
    =A0 =A0 =A0 =A0 { "less-than": "/some/path", "= value": 42 },
    =A0 =A0 =A0 =A0 { "test": "/some/other/path" },
    =A0 =A0 =A0 =A0 { "contains": "/foo/bar", "val= ue": "Major-General" }
    =A0 =A0 =A0 =A0]
    =A0 =A0 =A0}
    =A0 =A0 },
    =A0 =A0 { "replace": "/some/path", "value"= ;: 42 },
    =A0 =A0 { "delete": "/some/other/path" },
    =A0 =A0 { "add": "/yet/another/path", "value&q= uot;: "bar!" }=A0 =A0=A0
    =A0 ]


    Running through the various cases, option (B) seems to be a cleaner map= ping overall. Note that in this case, the JSON-Pointer value specified by t= he "test" member identifies the base reference point for the pred= icate.


    One of the main reasons I prefer (B) is that it allows me a clean way o= f interpolating predicate checks throughout the patch document.


    Option (B) also allows us to get by without necessarily creating a new = base document type and media type.


    Thoughts?


    - James

    On Mon, Sep 17, 2012 at 12:39 PM, James M Snell <jasnell@gmail.com> wrote:
    Here is the early initial draft of JSON-Test ... this is not yet pu= blished as an I-D. I need to fill in some of the additional detail and exam= ples around the basic predicate operations. However, the key elements are i= n place. I will try to get this published either tonight or tomorrow at the= latest


    =A0 http://goo.gl= /osKeI =A0<=3D=3D Links to my Github repo


    As always, feedback is more than welcome.


    - James


    On Mon, Sep 17, 2012 at 12:33 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
    On Mon, 2012-09-17 at 17:32 +1000, Manger, James H wrote:
    The JSON patch spec looks good: draft-ietf-appsawg-json-pat= ch-04.

    There is no explicit mention of extensibility of the JSON p= atch syntax. Presumably new operations (beyond add/remove/replace/move/copy= /test) could be added, with the understanding that "old" implemen= tations will reject such documents [section 4 says an unknown operation is = an error]. Adding extra fields to an existing operation is less clear (eg {= "add":"/foo/1","value":"baz","= repeat":10}). There is no explicit mention that that would be an error= . Perhaps implementations will ignore unrecognized fields.


    I had envisioned a container document type, which would enumera= te a set of conditions that must be met before processing the operations an= associated (contained) JSON Patch document. Taking this approach means tha= t there is no confusion over what's a JSON Patch document vs. the exten= sion document type. Since JSON Patch is an array of operation objects, such= a structure would remain relatively straightforward.

    More concretely, perhaps something like:

    {
=A0=A0=A0 "tests": [
=A0=A0=A0=A0=A0=A0=A0 { "less-than": "/some/path", =
"value": 42 },
=A0=A0=A0=A0=A0=A0=A0 { "exists": "/some/other/path"=
; },
=A0=A0=A0=A0=A0=A0=A0 { "not-exists": "/yet/another/path=
" },
=A0=A0=A0=A0=A0=A0=A0 { "contains": "/foo/bar", "v=
alue": "Major-General" }
=A0=A0=A0 ], "application/json-patch": [
=A0=A0=A0=A0=A0=A0=A0 { "replace": "/some/path", &q=
uot;value": 42 },
=A0=A0=A0=A0=A0=A0=A0 { "delete": "/some/other/path"=
; },
=A0=A0=A0=A0=A0=A0=A0 { "add": "/yet/another/path",=
 "value": "bar!" }
=A0=A0=A0 ]
}

    Thoughts?


    Could more sophisticated future test rules define, say, a &= quot;test2" operation? Or is it the expectation that such a syntax wou= ld need a new media type?


    I would say any extension should require its own media type.


    Each operation lists a full JSON pointer from the root of t= he resource. If you want to replace a dozen fields in a deeply nested objec= t you need to repeat the path to that object a dozen times. This may be a r= easonable compromise to avoid a more complex patch structure (particularly = if compression removes much of the overhead), but I wasn't sure if any = alternative had been considered. For example, {"patch":"/fee= /fie/fo/fum/foo","value":[{"add":"x",&qu= ot;value":"baz"},{"add":"y","value&= quot;:3}]}.


    We've considered alternatives in the past, but concluded th= at given the verbosity of the JSON Patch document, the likely strategy to r= educe size would be through compression. As such, multiple similar paths wo= uld compress fairly well.


    Would I be opening a can of worms (or doing some bike-shedd= ing) if I asked why application/json-patch instead of application/patch+jso= n?


    Probably. I originally proposed application/patch+json. The mai= n problem with application/patch+json is that it implies that there are oth= er representations of application/patch, not just JSON (e.g. application/pa= tch+xml). In this case, JSON Patch is meant to address only JSON doc= uments in a JSON format. Furthermore, I'm not yet aware of a specificat= ion for JSON like there is is for XML that promotes the addition of +json. = Therefore, I'd say that application/json-patch is probably the better c= hoice.

    Paul

    _______________________________________________
    apps-discuss mailing list
    apps= -discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss



    _______________________________________________
    apps-discuss mailing list
    apps-dis= cuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss






    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss




    --
    Matthew = P. C. Morley
    --20cf3074d77c982ed504c9f8b64e-- From barryleiba.mailing.lists@gmail.com Tue Sep 18 06:11:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC2921E80B0 for ; Tue, 18 Sep 2012 06:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZT6+88BrBq8R for ; Tue, 18 Sep 2012 06:11:27 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 822AB21F8794 for ; Tue, 18 Sep 2012 06:11:27 -0700 (PDT) Received: by lahm15 with SMTP id m15so5269784lah.31 for ; Tue, 18 Sep 2012 06:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+UKjwj+lcm+mSUaXCPq927YJlOMX3l1PQllp0oecRYM=; b=wUxMa8irvyrZUtko1IZyzUggTluvVkXz4aRgF6oc2YiTfKDYLEInCSo3/t3W1f7Lzk nPdGcgS6uSO+V6YosYJGGUeNZGhj233ySmgXWR1hGYd8460M1gM/hW9qP4DAgDJOxu1d sudx5VUVHkYLEwanRsxK6kyUqs8NCNySU5fxI2o+4zDpA/ehXxfoIm+aktgns4T3W0fl kcnwJNZUVDED/hr+RNvaZGBKFkq4fqWo1mHqOpazqyfswYQxenHI5doVv/OyzZrhjeGa d9zbgLyxEoTQWLqPgtiQtSQDyLJicClzZSeju77CKH2DtfHjV6oV5hrU/rvS4hNDYsNQ H80g== MIME-Version: 1.0 Received: by 10.112.42.103 with SMTP id n7mr214544lbl.69.1347973886308; Tue, 18 Sep 2012 06:11:26 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Tue, 18 Sep 2012 06:11:26 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Sep 2012 09:11:26 -0400 X-Google-Sender-Auth: MfvJ4BekuP7zDircaJ469fwOhO4 Message-ID: From: Barry Leiba To: Andrew Newton Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 13:11:28 -0000 > Didn't we do away with the 'down-reference' prohibition? So using an > informational draft as a normative reference in a standards draft should be > OK. Indeed, what Phill says. All we need to do is call it out in the Last Call announcement. What's more, 4627 is in the downref registry: http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry ...so it's already got an exemption from even needing to be called out like that. Apart from that, Your Friendly ADs have been discussing the possibility of reclassifying it as Proposed Standard. Comments about such a move are welcome on this thread. > As a practical matter it is easier to follow RFC 4627 than to fish the JSON > spec out of the ECMA spec (at least the versions I have read). So I would > cite RFC 4627 as normative. As Julian points out, RFC 4627 is actually the only reference for JSON now (which is why we're thinking of changing its status). Far from just registering the media type, it fully defines the grammar, and the current version of the ECMA spec actually normatively references RFC 4627. Barry, Applications AD From andy@hxr.us Tue Sep 18 06:21:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1560D21E80C1 for ; Tue, 18 Sep 2012 06:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVU0XbMnopZk for ; Tue, 18 Sep 2012 06:21:01 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB99A21F875D for ; Tue, 18 Sep 2012 06:21:00 -0700 (PDT) Received: by lahm15 with SMTP id m15so5277921lah.31 for ; Tue, 18 Sep 2012 06:20:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=5RXTsY1pZXimtJvD+xhDrXxD4BwriKHWHODM+Ujzq3E=; b=Ep8vN68MWGwZkeGgS/kpSLQKPtG6jHgtOiQdfXogrDYhT2J1TbmCN9B2G6FrfMuPte b0nJxhuwvgHWCD1EOuGN7hN0jGblW1dXPAzKbqAc6TTsrWduscTWXhxIwZOTIzJQdlLe /q3N9qtN+/XM+dISxy3GUVXu06AxG1SyFjzeulvXCaty5bt6xkpyFeBLYnoHizrwqHyK zC37XwC0+mefvE9faTmZX4giahGdbpHpgUrnhbiJykm8YWWYXhUWzafq7ysB1J0cMZNI s2KHMItJhWAz1BiO4HUu7miSpHbojFREUzGS0CfcT7ScDabpg4OzeZeAtuOLJC/KyIse GOjw== MIME-Version: 1.0 Received: by 10.112.36.138 with SMTP id q10mr227006lbj.63.1347974459711; Tue, 18 Sep 2012 06:20:59 -0700 (PDT) Received: by 10.112.7.67 with HTTP; Tue, 18 Sep 2012 06:20:59 -0700 (PDT) X-Originating-IP: [71.191.219.28] In-Reply-To: References: Date: Tue, 18 Sep 2012 09:20:59 -0400 Message-ID: From: Andrew Newton To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnaVTQLj0MgOACy/EuuiVsQlm+QO+DlLPXMX0wh+o+8ToqAe9pFAkuAkB4L9md2+n0Wjkkj Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 13:21:02 -0000 On Tue, Sep 18, 2012 at 9:11 AM, Barry Leiba wrote: > Indeed, what Phill says. All we need to do is call it out in the Last > Call announcement. What's more, 4627 is in the downref registry: > http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry > ...so it's already got an exemption from even needing to be called out > like that. Excellent! Exactly what I wanted to know. > > Apart from that, Your Friendly ADs have been discussing the > possibility of reclassifying it as Proposed Standard. Comments about > such a move are welcome on this thread. I support moving 4627 to Proposed Standard. PHB raises some good points regarding object member uniqueness and ordering, but I do not think they need to be addressed in the PS. Those issues are more appropriate for a separate BCP. > As Julian points out, RFC 4627 is actually the only reference for JSON > now (which is why we're thinking of changing its status). Far from > just registering the media type, it fully defines the grammar, and the > current version of the ECMA spec actually normatively references RFC > 4627. Good to know. Thanks. -andy From julian.reschke@gmx.de Tue Sep 18 06:27:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABA121E80D2 for ; Tue, 18 Sep 2012 06:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.448 X-Spam-Level: X-Spam-Status: No, score=-103.448 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjZPX3Dxnmp2 for ; Tue, 18 Sep 2012 06:27:42 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 17DAE21E80D1 for ; Tue, 18 Sep 2012 06:27:41 -0700 (PDT) Received: (qmail invoked by alias); 18 Sep 2012 13:27:40 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 18 Sep 2012 15:27:40 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19pzkJ6G/ZpbtHIEusGl8ToJ1g2DTroe6Y8V01CKq zRFd1LKd3MSYNa Message-ID: <505876BF.7020708@gmx.de> Date: Tue, 18 Sep 2012 15:27:27 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andrew Newton References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Barry Leiba , apps-discuss@ietf.org Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 13:27:43 -0000 On 2012-09-18 15:20, Andrew Newton wrote: > On Tue, Sep 18, 2012 at 9:11 AM, Barry Leiba wrote: >> Indeed, what Phill says. All we need to do is call it out in the Last >> Call announcement. What's more, 4627 is in the downref registry: >> http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry >> ...so it's already got an exemption from even needing to be called out >> like that. > > Excellent! Exactly what I wanted to know. > >> >> Apart from that, Your Friendly ADs have been discussing the >> possibility of reclassifying it as Proposed Standard. Comments about >> such a move are welcome on this thread. > > I support moving 4627 to Proposed Standard. PHB raises some good > ... +1 From julian.reschke@gmx.de Tue Sep 18 06:40:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473B621E80BD for ; Tue, 18 Sep 2012 06:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.354 X-Spam-Level: X-Spam-Status: No, score=-103.354 tagged_above=-999 required=5 tests=[AWL=-0.755, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxd8apQn6nll for ; Tue, 18 Sep 2012 06:40:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 45A3921E804A for ; Tue, 18 Sep 2012 06:40:04 -0700 (PDT) Received: (qmail invoked by alias); 18 Sep 2012 13:40:04 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp032) with SMTP; 18 Sep 2012 15:40:04 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/WE4V/I2TW286t9FjUZUaBGVTE2d1ztCny490P5H ove5xLPxzZ7sdZ Message-ID: <505879AE.5060307@gmx.de> Date: Tue, 18 Sep 2012 15:39:58 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 13:40:06 -0000 On 2012-09-18 13:35, Phillip Hallam-Baker wrote: > ... > It is pretty clear that change control for using JSON in application > protocols is going to have to rest with IETF as the IETF criteria are > going to be stricter. RFC4267 is not a sufficient description in my > view, you have to state things such as whether the order of objects > matters, what to do if an unexpected tag is encountered and several > other issues. > ... - The ordering of objects does not matter. There's nothing to define here. - Handling unexpected tags is an application-level issue; the answer is likely to depend on the use case. What else are you looking for? Best regards, Julian From paul.hoffman@vpnc.org Tue Sep 18 06:49:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7081821F860D for ; Tue, 18 Sep 2012 06:49:35 -0700 (PDT) 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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwbr-yjYEzmo for ; Tue, 18 Sep 2012 06:49:35 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EBEA021F8608 for ; Tue, 18 Sep 2012 06:49:34 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q8IDnSuH092573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Sep 2012 06:49:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Paul Hoffman In-Reply-To: Date: Tue, 18 Sep 2012 06:49:29 -0700 Content-Transfer-Encoding: 7bit Message-Id: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> References: To: Barry Leiba X-Mailer: Apple Mail (2.1486) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 13:49:35 -0000 On Sep 18, 2012, at 6:11 AM, Barry Leiba wrote: > Apart from that, Your Friendly ADs have been discussing the > possibility of reclassifying it as Proposed Standard. Comments about > such a move are welcome on this thread. +1. It's more of a standard than many of our standards. --Paul Hoffman From john-ietf@jck.com Tue Sep 18 09:13:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487E721E80E5 for ; Tue, 18 Sep 2012 09:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WCks+bxLI5T for ; Tue, 18 Sep 2012 09:13:41 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5522121E80ED for ; Tue, 18 Sep 2012 09:13:41 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TE0QW-000KcP-6A; Tue, 18 Sep 2012 12:13:32 -0400 Date: Tue, 18 Sep 2012 12:13:27 -0400 From: John C Klensin To: Paul Hoffman , Barry Leiba Message-ID: In-Reply-To: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:13:42 -0000 --On Tuesday, September 18, 2012 06:49 -0700 Paul Hoffman wrote: > On Sep 18, 2012, at 6:11 AM, Barry Leiba > wrote: > >> Apart from that, Your Friendly ADs have been discussing the >> possibility of reclassifying it as Proposed Standard. >> Comments about such a move are welcome on this thread. > > +1. It's more of a standard than many of our standards. To say on this list, as requested, what has been said in other places, the Security Considerations section of 4627 is, to be much more polite than it deserves, not up to the standard for IETF Standards Track documents. I think moving it to PS without some fix to that (either a new document that could be identical to 4627 other than having that section fixed or an updating document that would replace that section) would be a disservice to the community and reduction in the acceptable minimum quality of standards track protocol specifications. john From hallam@gmail.com Tue Sep 18 09:32:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B35C21F8622 for ; Tue, 18 Sep 2012 09:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.194 X-Spam-Level: X-Spam-Status: No, score=-4.194 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2ISoa8hjUnG for ; Tue, 18 Sep 2012 09:32:57 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0B90A21F84E2 for ; Tue, 18 Sep 2012 09:32:56 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so41315obb.31 for ; Tue, 18 Sep 2012 09:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DjqrNX8OH+faJ2RennHOCTV7rrXc3zv/tkVDR2E7emI=; b=c0qIOAZaaey+AYU+J9Bj7UGa5sclsq5EzuxNOfDogtSzPRDJ6rEI3GA0yKw4qBxthn 8VPBegOYABOSV+J0xus6lSPU7uG0LuGGs670w2zo1HWJuE/1BukuSH+p0kH7HZewpwGZ fAZFmM032/VhcUZPAW4xt2ANoQi4G4BSRc9IOS/aFMHFf1dveFy+1TogTs8JQZkrdrU0 2DvySrIxbt2kzCARK9jH70yDuLxRJWQE7222zudlmD3+meHzpRl3Q2XniC0ThkQVOeT3 Vs/lR29lHxLBNY26VGLfZUwfg0H8rrjDQ1dUM2iHIHVFhHamIJcq7o3E2NJ5eLQlz/lJ 9DmQ== MIME-Version: 1.0 Received: by 10.60.11.34 with SMTP id n2mr736187oeb.18.1347985976381; Tue, 18 Sep 2012 09:32:56 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Tue, 18 Sep 2012 09:32:56 -0700 (PDT) In-Reply-To: <505879AE.5060307@gmx.de> References: <505879AE.5060307@gmx.de> Date: Tue, 18 Sep 2012 12:32:56 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=e89a8fb206e648d17904c9fc7129 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:32:58 -0000 --e89a8fb206e648d17904c9fc7129 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 18, 2012 at 9:39 AM, Julian Reschke wrote: > On 2012-09-18 13:35, Phillip Hallam-Baker wrote: > >> ... >> >> It is pretty clear that change control for using JSON in application >> protocols is going to have to rest with IETF as the IETF criteria are >> going to be stricter. RFC4267 is not a sufficient description in my >> view, you have to state things such as whether the order of objects >> matters, what to do if an unexpected tag is encountered and several >> other issues. >> ... >> > > - The ordering of objects does not matter. There's nothing to define here. > You have to decide whether it matters or not. JSON does not commit to one approach or the other. It makes a very big difference when you try to implement a protocol. As far as the bits on the wire go there is no difference between List and Bag but there is a very big difference at the application layer. In my protocol I am sending a JSON structure that contains an ordered list of potential choices for a connection to a service endpoint. In other words the order darn well matters in that case and anyone who simply throws the data into a hash tree is going to end up with the wrong result. > - Handling unexpected tags is an application-level issue; the answer is > likely to depend on the use case. > Precisely my point. Application protocols have to decide whether they care about these things. This is actually the sort of thing that becomes apparent when you use a schema. So if you are writing something like SAML you might have: Type Assertion Statements List Any Conditions List Any Advice List Any So the following would be valid JSON (according to a particular mapping, give or take some punctuation): { "Assertion" [ {"Authenticate" {...}} ], "Conditions" [], "Advice" [] } There are three lists and any tagged object can be inserted into any of the lists, so the structure can be extended in certain places but the following would be a parse error: { "Assertion" [ {"Authenticate" {...}} ], "Conditions" [], "Advice" [] "NewList" [] } Deciding whether the order in which members of a tagged structure like the above occur matters is another choice. In SAML the order does matter but there is no particular reason that it needs to matter. Just citing RFC 4627 is not sufficient to describe how to implement a protocol. If the draft is going to be revised and become a Proposed Standard, I would like to see it mention these issue as choices that a protocol using JSON syntax must address clearly. Simply deciding to use JSON does not remove the obligation to be precise when stating what is acceptable and what is not. If you are going to have a specification that says order does not matter then you are going to have to test for that when you do interop testing. Contrawise if you decide that order does matter then you are going to have to test for that. -- Website: http://hallambaker.com/ --e89a8fb206e648d17904c9fc7129 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Tue, Sep 18, 2012 at 9:39 AM, Julian = Reschke <julian.reschke@gmx.de> wrote:
    On 2012-09-18 13:35, Phillip Hallam-Baker wrote:
    ...

    It is pretty clear that change control for using JSON in application
    protocols is going to have to rest with IETF as the IETF criteria are
    going to be stricter. RFC4267 is not a sufficient description in my
    view, you have to state things such as whether the order of objects
    matters, what to do if an unexpected tag is encountered and several
    other issues.
    ...

    - The ordering of objects does not matter. There's nothing to define he= re.

    You have to decide whether it matte= rs or not. JSON does not commit to one approach or the other.

    It makes a very big difference when you try to implement a p= rotocol. As far as the bits on the wire go there is no difference between L= ist<Object> and Bag<Object> but there is a very big difference = at the application layer.

    In my protocol I am sending a JSON structure that conta= ins an ordered list of potential choices for a connection to a service endp= oint. In other words the order darn well matters in that case and anyone wh= o simply throws the data into a hash tree is going to end up with the wrong= result.=A0

    =A0
    - Handling unexpected tags is an application-level issue; the answer is lik= ely to depend on the use case.

    Precisel= y my point. Application protocols have to decide whether they care about th= ese things.=A0

    This is actually the sort of thing that becomes apparen= t when you use a schema. So if you are writing something like SAML you migh= t have:

    Type Assertion
    =A0 =A0 Statement= s List Any
    =A0 =A0 Conditions List Any
    =A0 =A0 Advice List Any=A0
    =

    So the following would be valid JSON (according to a pa= rticular mapping, give or take some punctuation):

    = { "Assertion" [ {"Authenticate" {...}} ],
    =A0 "Conditions" [],
    =A0 "Advice" [] }

    There are three lists and any tagged object can be = inserted into any of the lists, so the structure can be extended in certain= places but the following would be a parse error:

    { "Assertion" [ {"Authenticate"= ; {...}} ],
    =A0 "Conditions" [],
    =A0 "Ad= vice" []
    =A0 "NewList" [] }

    Deciding whether the order in which members of a tagged structure like= the above occur matters is another choice. In SAML the order does matter b= ut there is no particular reason that it needs to matter.



    Just citing RFC 4627 is not suffi= cient to describe how to implement a protocol.

    If the dr= aft is going to be revised and become a Proposed Standard, I would like to = see it mention these issue as choices that a protocol using JSON syntax mus= t address clearly.


    Simply deciding to use JSON does not rem= ove the obligation to be precise when stating what is acceptable and what i= s not. If you are going to have a specification that says order does not ma= tter then you are going to have to test for that when you do interop testin= g. Contrawise if you decide that order does matter then you are going to ha= ve to test for that.

    --
    Website: http://h= allambaker.com/

    --e89a8fb206e648d17904c9fc7129-- From julian.reschke@gmx.de Tue Sep 18 09:45:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC7E21F85F4 for ; Tue, 18 Sep 2012 09:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.278 X-Spam-Level: X-Spam-Status: No, score=-103.278 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OzGMyWuwQTH for ; Tue, 18 Sep 2012 09:45:40 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id A6F2A21F8627 for ; Tue, 18 Sep 2012 09:45:36 -0700 (PDT) Received: (qmail invoked by alias); 18 Sep 2012 16:45:35 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp017) with SMTP; 18 Sep 2012 18:45:35 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/yUsUWGnbytqiw+bX+gPdxHVUFXANgKgCysRs3d+ 1J42+dFA2V1eIv Message-ID: <5058A52B.7060405@gmx.de> Date: Tue, 18 Sep 2012 18:45:31 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <505879AE.5060307@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:45:41 -0000 On 2012-09-18 18:32, Phillip Hallam-Baker wrote: > > > On Tue, Sep 18, 2012 at 9:39 AM, Julian Reschke > wrote: > > On 2012-09-18 13:35, Phillip Hallam-Baker wrote: > > ... > > It is pretty clear that change control for using JSON in application > protocols is going to have to rest with IETF as the IETF > criteria are > going to be stricter. RFC4267 is not a sufficient description in my > view, you have to state things such as whether the order of objects > matters, what to do if an unexpected tag is encountered and several > other issues. > ... > > > - The ordering of objects does not matter. There's nothing to define > here. > > > You have to decide whether it matters or not. JSON does not commit to > one approach or the other. It doesn't matter in Javascript, so trying to make it matter in JSON will break with many existing implementations. > It makes a very big difference when you try to implement a protocol. As > far as the bits on the wire go there is no difference between > List and Bag but there is a very big difference at the > application layer. Indeed. If you need ordering you can't rely on object order. > In my protocol I am sending a JSON structure that contains an ordered > list of potential choices for a connection to a service endpoint. In > other words the order darn well matters in that case and anyone who > simply throws the data into a hash tree is going to end up with the > wrong result. ...which is what some browsers do (and rightly so), so your protocol has a design problem :-). > - Handling unexpected tags is an application-level issue; the answer > is likely to depend on the use case. > > > Precisely my point. Application protocols have to decide whether they > care about these things. Yes. > This is actually the sort of thing that becomes apparent when you use a > schema. So if you are writing something like SAML you might have: > > Type Assertion > Statements List Any > Conditions List Any > Advice List Any > > So the following would be valid JSON (according to a particular mapping, > give or take some punctuation): > > { "Assertion" [ {"Authenticate" {...}} ], > "Conditions" [], > "Advice" [] } > > There are three lists and any tagged object can be inserted into any of > the lists, so the structure can be extended in certain places but the > following would be a parse error: > > { "Assertion" [ {"Authenticate" {...}} ], > "Conditions" [], > "Advice" [] > "NewList" [] } > > Deciding whether the order in which members of a tagged structure like > the above occur matters is another choice. In SAML the order does matter > but there is no particular reason that it needs to matter. > > > > Just citing RFC 4627 is not sufficient to describe how to implement a > protocol. That is true, but that's not a defect of RFC 4627. > If the draft is going to be revised and become a Proposed Standard, I > would like to see it mention these issue as choices that a protocol > using JSON syntax must address clearly. I agree for the bot about handling unexpected content (== extension elements). > Simply deciding to use JSON does not remove the obligation to be precise > when stating what is acceptable and what is not. If you are going to > have a specification that says order does not matter then you are going > to have to test for that when you do interop testing. Contrawise if you > decide that order does matter then you are going to have to test for that. Again, if you make ordering significant you are in trouble. And yes, as this question comes up from time to time, a revision of 4627 could mention that. Best regards, Julian From hallam@gmail.com Tue Sep 18 09:47:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08C121E80D9 for ; Tue, 18 Sep 2012 09:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.169 X-Spam-Level: X-Spam-Status: No, score=-4.169 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWv1gM1BNA5M for ; Tue, 18 Sep 2012 09:47:49 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA5BB21F85F0 for ; Tue, 18 Sep 2012 09:47:49 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so63353obb.31 for ; Tue, 18 Sep 2012 09:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xdeX/EmZx+Y49tpZImFRJpV+D1a5KJLo62K6J0TYkXs=; b=oKL959RV2dnsoTgxdFXtlzruPgB3zhWJqXlbVGovEUY8leRQnpZZIjwALFuVxLysSC 4ggF7Wvae4xssqiM2CXUfQVywCvBil0PDELK5UkErJmwVxdfn+ppKXIEOh+2+xXeqNfi Tc4SLvvhiJDZr+HNBVR4JDK9SL2x1w01V9jRN7CqwNUMbZInNZWJtIuw7QavPmPO8wa3 mML2vAPSZA/5PGoR8XI5QM53HzNw2iRRRfkHEj/acqBlOqRoxff6vSSJRPTjO6QNSiv6 Y7A8RGzZzKPuPPRaHhZENYZH6CYRHfNQMcF+r8IoRLtylYMJhHoU3051Qk+PpQIbUzIO W0bA== MIME-Version: 1.0 Received: by 10.60.25.129 with SMTP id c1mr756312oeg.36.1347986869225; Tue, 18 Sep 2012 09:47:49 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Tue, 18 Sep 2012 09:47:49 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Sep 2012 12:47:49 -0400 Message-ID: From: Phillip Hallam-Baker To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=e89a8ff1c6ce80891704c9fca67a Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:47:50 -0000 --e89a8ff1c6ce80891704c9fca67a Content-Type: text/plain; charset=ISO-8859-1 How can you use tools 'correctly' without having a definition of what 'correct' is? I can't see a place in the JSON specification where it says that the following are equivalent: [ {"name": "foo", "value": "one"}, {"name": "bar", "value": "two"}] [ {"name": "foo", "value": "two"}, {"name": "bar", "value": "one"}] If you want them to be equivalent then you have to say so and this has to be something the WG discusses and comes to consensus on. This is what we do with RFC822 headers, there is an explicit statement in the spec that says that the order in which the headers are presented does not change the semantics. My opinion is that considering the elements to be lists of items rather than bags is better because it is less work using appropriate tools and the resulting representation is more compact. On Tue, Sep 18, 2012 at 12:39 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 9/18/12 9:32 AM, "Phillip Hallam-Baker" wrote: > > >In my protocol I am sending a JSON structure that contains an ordered > >list of potential choices for a connection to a service endpoint. In > >other words the order darn well matters in that case and anyone who > >simply throws the data into a hash tree is going > > to end up with the wrong result. > > If it's possible, I'd suggest exploring other design patterns. Instead of > the order mattering in: > > { "foo": "one", "bar": "two" } > > You could use: > > [ {"name": "foo", "value": "one"}, {"name": "bar", "value": "two"}] > > Or some other non-ambiguous approach. > > >If the draft is going to be revised and become a Proposed Standard, I > >would like to see it mention these issue as choices that a protocol using > >JSON syntax must address clearly. > > It seems reasonable to give guidelines to protocol implementors. Whether > that belongs in this document or not is a separate question. If we can > come to consensus on what those guidelines are quickly, it wouldn't hurt > to include them -- but that seems unlikely. > > >Simply deciding to use JSON does not remove the obligation to be precise > >when stating what is acceptable and what is not. If you are going to have > >a specification that says order does not matter then you are going to > >have to test for that when you do interop > > testing. Contrawise if you decide that order does matter then you are > >going to have to test for that. > > Or: use the tools correctly according to the guidelines that may exist one > day, and you won't have this interop issue. > > -- > Joe Hildebrand > > > > -- Website: http://hallambaker.com/ --e89a8ff1c6ce80891704c9fca67a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable How can you use tools 'correctly' without having a definition of wh= at 'correct' is?

    I can't see a place in the = JSON specification where it says that the following are equivalent:

    [ {"name&qu= ot;: "foo", "value": "one"}, {"name"= ;: "bar", "value": "two"}]
    [ {"name": &quo= t;foo", "value": "two"}, {"name": "= bar", "value": "one"}]

    If you want them to be equivalent then you have to say so an= d this has to be something the WG discusses and comes to consensus on.

    This is what we do with RFC822 headers, there is an ex= plicit statement in the spec that says that the order in which the headers = are presented does not change the semantics.

    My opinion is that considering the elements to be lists= of items rather than bags is better because it is less work using appropri= ate tools and the resulting representation is more compact.


    On Tue, Sep 18, 2012 at 12:39 PM, Joe Hildebrand= (jhildebr) <jhildebr@cisco.com> wrote:
    On 9/18/12 9:32 AM, "Phillip Hallam-Baker" <= hallam@gmail.com> wrote:

    >In my protocol I am sending a JSON structure that contains an ordered >list of potential choices for a connection to a service endpoint. In >other words the order darn well matters in that case and anyone who
    >simply throws the data into a hash tree is going
    > to end up with the wrong result.

    If it's possible, I'd suggest exploring other design patterns= . =A0Instead of
    the order mattering in:

    { "foo": "one", "bar": "two" }

    You could use:

    [ {"name": "foo", "value": "one"}, = {"name": "bar", "value": "two"}]
    Or some other non-ambiguous approach.

    >If the draft is going to be revised and become a Proposed Standard, I >would like to see it mention these issue as choices that a protocol usi= ng
    >JSON syntax must address clearly.

    It seems reasonable to give guidelines to protocol implementors. =A0W= hether
    that belongs in this document or not is a separate question. =A0If we can come to consensus on what those guidelines are quickly, it wouldn't hur= t
    to include them -- but that seems unlikely.

    >Simply deciding to use JSON does not remove the obligation to be precis= e
    >when stating what is acceptable and what is not. If you are going to ha= ve
    >a specification that says order does not matter then you are going to >have to test for that when you do interop
    > testing. Contrawise if you decide that order does matter then you are<= br> >going to have to test for that.

    Or: use the tools correctly according to the guidelines that may exis= t one
    day, and you won't have this interop issue.

    --
    Joe Hildebrand






    -- Website: http://hallambaker.com/<= br>
    --e89a8ff1c6ce80891704c9fca67a-- From hallam@gmail.com Tue Sep 18 09:51:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD94021E80E2 for ; Tue, 18 Sep 2012 09:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.146 X-Spam-Level: X-Spam-Status: No, score=-4.146 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wy+k5SdtQOs3 for ; Tue, 18 Sep 2012 09:51:55 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id B8B3E21E80DF for ; Tue, 18 Sep 2012 09:51:55 -0700 (PDT) Received: by oagk14 with SMTP id k14so72883oag.31 for ; Tue, 18 Sep 2012 09:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O5AhA5Y6gEXishxVqFH3TaIjuvGoBnmpHLsp93o5bw8=; b=EXGiHcueotG/Y66q66v1fch5zx6i20e6YRaMP7XR6gi4Uan1mJMpihaZlHmlmaDOc3 DDdaB7D/Rk5OgJZQW52foq7wX0uURwPLS4BU3sY2/7jtEnkLNFeu1+WsPeheWIfJHCzg +ugN1XE4Iz8Ymsil0NNhjcR+ufSFuMRyu0hO+6M/X1ceHw16KER7gRXwQDxrzSx0T/Fd Qpc7J8KE2beFdFfZrbck/I4wz3847gBvea9NNPARDr0C59zsV2GiO51VkLiqcT2smLeK bc8ZP4NyO6xpMJgAhpI+5qBvGlOYdX8zu1I3yhEnuseovNlGdqgwo0RrKzkOtpTJlpNs 4U9g== MIME-Version: 1.0 Received: by 10.182.197.73 with SMTP id is9mr769758obc.32.1347987109133; Tue, 18 Sep 2012 09:51:49 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Tue, 18 Sep 2012 09:51:49 -0700 (PDT) In-Reply-To: <5058A52B.7060405@gmx.de> References: <505879AE.5060307@gmx.de> <5058A52B.7060405@gmx.de> Date: Tue, 18 Sep 2012 12:51:49 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=14dae9399cadcd3d9f04c9fcb4f6 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:51:56 -0000 --14dae9399cadcd3d9f04c9fcb4f6 Content-Type: text/plain; charset=ISO-8859-1 RFC 4627 states: 2.3. Arrays An array structure is represented as square brackets surrounding zero or more values (or elements). Elements are separated by commas. array = begin-array [ value *( value-separator value ) ] end-array So has JavaScript redefined the meaning of 'Array' then? how vewy peculiar. I suggest that you fix your broken language or change the term 'Array' to 'Bag' in the specification because where I come from 'Array' and 'List' can be used interchangeably in some contexts but 'Array' and 'Bag' cannot. On Tue, Sep 18, 2012 at 12:45 PM, Julian Reschke wrote: > On 2012-09-18 18:32, Phillip Hallam-Baker wrote: > >> >> >> On Tue, Sep 18, 2012 at 9:39 AM, Julian Reschke > **> wrote: >> >> On 2012-09-18 13:35, Phillip Hallam-Baker wrote: >> >> ... >> >> It is pretty clear that change control for using JSON in >> application >> protocols is going to have to rest with IETF as the IETF >> criteria are >> going to be stricter. RFC4267 is not a sufficient description in >> my >> view, you have to state things such as whether the order of >> objects >> matters, what to do if an unexpected tag is encountered and >> several >> other issues. >> ... >> >> >> - The ordering of objects does not matter. There's nothing to define >> here. >> >> >> You have to decide whether it matters or not. JSON does not commit to >> one approach or the other. >> > > It doesn't matter in Javascript, so trying to make it matter in JSON will > break with many existing implementations. > > > It makes a very big difference when you try to implement a protocol. As >> far as the bits on the wire go there is no difference between >> List and Bag but there is a very big difference at the >> application layer. >> > > Indeed. If you need ordering you can't rely on object order. > > > In my protocol I am sending a JSON structure that contains an ordered >> list of potential choices for a connection to a service endpoint. In >> other words the order darn well matters in that case and anyone who >> simply throws the data into a hash tree is going to end up with the >> wrong result. >> > > ...which is what some browsers do (and rightly so), so your protocol has a > design problem :-). > > > - Handling unexpected tags is an application-level issue; the answer >> is likely to depend on the use case. >> >> >> Precisely my point. Application protocols have to decide whether they >> care about these things. >> > > Yes. > > > This is actually the sort of thing that becomes apparent when you use a >> schema. So if you are writing something like SAML you might have: >> >> Type Assertion >> Statements List Any >> Conditions List Any >> Advice List Any >> >> So the following would be valid JSON (according to a particular mapping, >> give or take some punctuation): >> >> { "Assertion" [ {"Authenticate" {...}} ], >> "Conditions" [], >> "Advice" [] } >> >> There are three lists and any tagged object can be inserted into any of >> the lists, so the structure can be extended in certain places but the >> following would be a parse error: >> >> { "Assertion" [ {"Authenticate" {...}} ], >> "Conditions" [], >> "Advice" [] >> "NewList" [] } >> >> Deciding whether the order in which members of a tagged structure like >> the above occur matters is another choice. In SAML the order does matter >> but there is no particular reason that it needs to matter. >> >> >> >> Just citing RFC 4627 is not sufficient to describe how to implement a >> protocol. >> > > That is true, but that's not a defect of RFC 4627. > > > If the draft is going to be revised and become a Proposed Standard, I >> would like to see it mention these issue as choices that a protocol >> using JSON syntax must address clearly. >> > > I agree for the bot about handling unexpected content (== extension > elements). > > > Simply deciding to use JSON does not remove the obligation to be precise >> when stating what is acceptable and what is not. If you are going to >> have a specification that says order does not matter then you are going >> to have to test for that when you do interop testing. Contrawise if you >> decide that order does matter then you are going to have to test for that. >> > > Again, if you make ordering significant you are in trouble. And yes, as > this question comes up from time to time, a revision of 4627 could mention > that. > > Best regards, Julian > > -- Website: http://hallambaker.com/ --14dae9399cadcd3d9f04c9fcb4f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RFC 4627 states:

    2.3.  Arrays

   An array structure is represented as square brackets surrounding zero
   or more values (or elements).  Elements are separated by commas.

      array =3D begin-array [ value *( value-separator value ) ] end-array<=
/pre>
    So has JavaScript redefined the meaning of 'Array' then?=
=A0

    how vewy peculiar.

    I =
suggest that you fix your broken language or change the term 'Array'=
; to 'Bag' in the specification because where I come from 'Arra=
y' and 'List' can be used interchangeably in some contexts but =
'Array' and 'Bag' cannot.
    

    On Tue, Sep 18, 2012 at 12:45 PM, Julian Res=
chke <julian.reschke@gmx.de> wrote:
    

    On 2012-09-18 18:32, Phillip Hallam-Baker wrote:
    

    

    

    
On Tue, Sep 18, 2012 at 9:39 AM, Julian Reschke <julian.reschke@gmx.de
    
<mailto:julia=
n.reschke@gmx.de>> wrote:
    

    
=A0 =A0 On 2012-09-18 13:35, Phillip Hallam-Baker wrote:
    

    
=A0 =A0 =A0 =A0 ...
    

    
=A0 =A0 =A0 =A0 It is pretty clear that change control for using JSON in ap=
plication
    
=A0 =A0 =A0 =A0 protocols is going to have to rest with IETF as the IETF
=A0 =A0 =A0 =A0 criteria are
    
=A0 =A0 =A0 =A0 going to be stricter. RFC4267 is not a sufficient descripti=
on in my
    
=A0 =A0 =A0 =A0 view, you have to state things such as whether the order of=
 objects
    
=A0 =A0 =A0 =A0 matters, what to do if an unexpected tag is encountered and=
 several
    
=A0 =A0 =A0 =A0 other issues.
    
=A0 =A0 =A0 =A0 ...
    

    

    
=A0 =A0 - The ordering of objects does not matter. There's nothing to d=
efine
    
=A0 =A0 here.
    

    

    
You have to decide whether it matters or not. JSON does not commit to
    
one approach or the other.
    

    

    
It doesn't matter in Javascript, so trying to make it matter in JSON wi=
ll break with many existing implementations.

    

    

    
It makes a very big difference when you try to implement a protocol. As
    
far as the bits on the wire go there is no difference between
    
List<Object> and Bag<Object> but there is a very big difference=
 at the
    
application layer.
    

    

    
Indeed. If you need ordering you can't rely on object order.

    

    

    
In my protocol I am sending a JSON structure that contains an ordered
    
list of potential choices for a connection to a service endpoint. In
    
other words the order darn well matters in that case and anyone who
    
simply throws the data into a hash tree is going to end up with the
    
wrong result.
    

    

    
...which is what some browsers do (and rightly so), so your protocol has a =
design problem :-).

    

    

    
=A0 =A0 - Handling unexpected tags is an application-level issue; the answe=
r
    
=A0 =A0 is likely to depend on the use case.
    

    

    
Precisely my point. Application protocols have to decide whether they
    
care about these things.
    

    

    
Yes.

    

    

    
This is actually the sort of thing that becomes apparent when you use a
    
schema. So if you are writing something like SAML you might have:
    

    
Type Assertion
    
=A0 =A0 =A0Statements List Any
    
=A0 =A0 =A0Conditions List Any
    
=A0 =A0 =A0Advice List Any
    

    
So the following would be valid JSON (according to a particular mapping,
give or take some punctuation):
    

    
{ "Assertion" [ {"Authenticate" {...}} ],
    
=A0 =A0"Conditions" [],
    
=A0 =A0"Advice" [] }
    

    
There are three lists and any tagged object can be inserted into any of
    
the lists, so the structure can be extended in certain places but the
    
following would be a parse error:
    

    
{ "Assertion" [ {"Authenticate" {...}} ],
    
=A0 =A0"Conditions" [],
    
=A0 =A0"Advice" []
    
=A0 =A0"NewList" [] }
    

    
Deciding whether the order in which members of a tagged structure like
    
the above occur matters is another choice. In SAML the order does matter
but there is no particular reason that it needs to matter.
    

    

    

    
Just citing RFC 4627 is not sufficient to describe how to implement a
    
protocol.
    

    

    
That is true, but that's not a defect of RFC 4627.
    

    

    
If the draft is going to be revised and become a Proposed Standard, I
    
would like to see it mention these issue as choices that a protocol
    
using JSON syntax must address clearly.
    

    

    
I agree for the bot about handling unexpected content (=3D=3D extension ele=
ments).

    

    

    
Simply deciding to use JSON does not remove the obligation to be precise
when stating what is acceptable and what is not. If you are going to
    
have a specification that says order does not matter then you are going
    
to have to test for that when you do interop testing. Contrawise if you
    
decide that order does matter then you are going to have to test for that.<=
br>

    

    
Again, if you make ordering significant you are in trouble. And yes, as thi=
s question comes up from time to time, a revision of 4627 could mention tha=
t.
    

    
Best regards, Julian



    --
    Website: http://hallambaker.com/

    --14dae9399cadcd3d9f04c9fcb4f6-- From andy@hxr.us Tue Sep 18 09:53:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3D821F84A1 for ; Tue, 18 Sep 2012 09:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzIOewEcdbxH for ; Tue, 18 Sep 2012 09:53:24 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9B9C21F849D for ; Tue, 18 Sep 2012 09:53:23 -0700 (PDT) Received: by lahm15 with SMTP id m15so41692lah.31 for ; Tue, 18 Sep 2012 09:53:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=anFXEnSt3IA7LzZEO8d+fJXRtFPf5Ry1I7zFRgX1Dd0=; b=oamXipSVb0AeU51ifdRp3iWahXpzXVtCAz7Cwp30PObE2n9pAMAqvEWBfkUOOMV//D Yg5HVqBhqQL+2Om5yuvxPqvpuikoIRBScCMZoGNRAFIMVEy/WASnWzeU66GZaU1LfcgH qVeQ9IhgTRQ15pkEXPLkO4IRM7yYnO7loSoZq0zKolWpnagxriUlPV5ZztP4BjLEnKCn 2aeWjnmWcpfnRqDzEAPVZwfMS11vwdTa8o93yRD6AQEv2q3AsVcfjNE3uKRuz/u+b305 z+2CCMWT9U4OqM5zE+sOE7HCAXQknwroFIcg6yVByDIAIjKv2EMtLeYhxryXE7aTjkis Z0Bg== MIME-Version: 1.0 Received: by 10.152.148.162 with SMTP id tt2mr396473lab.10.1347987200323; Tue, 18 Sep 2012 09:53:20 -0700 (PDT) Received: by 10.112.7.67 with HTTP; Tue, 18 Sep 2012 09:53:20 -0700 (PDT) X-Originating-IP: [71.191.219.28] In-Reply-To: References: Date: Tue, 18 Sep 2012 12:53:20 -0400 Message-ID: From: Andrew Newton To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmt0LhnxrmExYusdF3xltSg8jjV9PZCyUVLoYVk4MKYskx4NbKghFhyI0BDy8a2EzAoCzzV Cc: Julian Reschke , "apps-discuss@ietf.org" , "Joe Hildebrand \(jhildebr\)" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:53:24 -0000 On Tue, Sep 18, 2012 at 12:47 PM, Phillip Hallam-Baker wrote: > How can you use tools 'correctly' without having a definition of what > 'correct' is? I agree with Phillip. What may seem obvious to those who use an API that uses hashes is not so obvious to those who don't (and in the IETF, you can count on the majority of reviewers not being programmers and so not realizing the issue). -andy From julian.reschke@gmx.de Tue Sep 18 09:55:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1CE21F849D for ; Tue, 18 Sep 2012 09:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.217 X-Spam-Level: X-Spam-Status: No, score=-103.217 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MzFHO3K+qQp for ; Tue, 18 Sep 2012 09:55:06 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0798B21F8733 for ; Tue, 18 Sep 2012 09:55:05 -0700 (PDT) Received: (qmail invoked by alias); 18 Sep 2012 16:55:05 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp012) with SMTP; 18 Sep 2012 18:55:05 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/ofn1PHKHozmWzmumGMErcvzfXuwh+GuFeXqrWSS 2/i/0xaWfa41l2 Message-ID: <5058A764.9080301@gmx.de> Date: Tue, 18 Sep 2012 18:55:00 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <505879AE.5060307@gmx.de> <5058A52B.7060405@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:55:07 -0000 On 2012-09-18 18:51, Phillip Hallam-Baker wrote: > RFC 4627 states: > > 2.3. Arrays > > An array structure is represented as square brackets surrounding zero > or more values (or elements). Elements are separated by commas. > > array = begin-array [ value *( value-separator value ) ] end-array > > So has JavaScript redefined the meaning of 'Array' then? > > how vewy peculiar. No. Arrays are indeed ordered. But ordering inside an *object* is not significant. > I suggest that you fix your broken language or change the term 'Array' > to 'Bag' in the specification because where I come from 'Array' and > 'List' can be used interchangeably in some contexts but 'Array' and > 'Bag' cannot. Philip, you asked: > you have to state things such as whether the order of objects matters It does not matter in objects, but it does matter in arrays. Best regards, Julian From jasnell@gmail.com Tue Sep 18 09:56:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F38721E80D9 for ; Tue, 18 Sep 2012 09:56:54 -0700 (PDT) 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_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ6w2dMfqLTV for ; Tue, 18 Sep 2012 09:56:53 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1735C21F8606 for ; Tue, 18 Sep 2012 09:56:52 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so66269wib.13 for ; Tue, 18 Sep 2012 09:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wyv9bNWJwRZc1LUpwjXoUQ+hD5etaj7ppSqNTiLCbUE=; b=whl+CcA6+ykW8AsDKLTdKjuCe8H/F2IUpbB6JZeRiF4rsyjBaIWHjuDIWHxpKmfIat AM9O5FbtsrM4geKVsvk7aA0wdL2SytdXV/yeDWCB1bIqqWpEs8DQwst8eGkjhwYrfA0k MWuE3eWYy+1O2WeFXV945UzuiNLqaNjsw0nT8A/OyvEd4yqRauLXI0zjKsuaOov6u4wd dMZj1dPQF+DcH5d2D8QbxWVThsnlHPNaKIsRXnnpdJByrmGSLft+fIYB2KmYKCsu51lj ZZCVjLhPj95AXnXEf8HAZQ8T7fTar4i+qR/6FZa3zm99pffr15ciEOEcq8cgnNlH9Tep rpcA== Received: by 10.217.1.79 with SMTP id m57mr200789wes.121.1347987412004; Tue, 18 Sep 2012 09:56:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.96.2 with HTTP; Tue, 18 Sep 2012 09:56:31 -0700 (PDT) In-Reply-To: References: <505879AE.5060307@gmx.de> <5058A52B.7060405@gmx.de> From: James M Snell Date: Tue, 18 Sep 2012 09:56:31 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=20cf302077dcdaaf5004c9fcc672 Cc: Julian Reschke , apps-discuss@ietf.org Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:56:54 -0000 --20cf302077dcdaaf5004c9fcc672 Content-Type: text/plain; charset=UTF-8 A couple points of clarification... the ordering of objects in a JSON Array *does* matter. The ordering of key:value pairs within an object does not. [1,2] is not equivalent to [2,1] while {"a":"b","c":"d"} is equivalent to {"c":"d","a":"b"}. The spec could be clearer on this point, definitely. - James On Tue, Sep 18, 2012 at 9:51 AM, Phillip Hallam-Baker wrote: > RFC 4627 states: > > 2.3. Arrays > > An array structure is represented as square brackets surrounding zero > or more values (or elements). Elements are separated by commas. > > array = begin-array [ value *( value-separator value ) ] end-array > > So has JavaScript redefined the meaning of 'Array' then? > > how vewy peculiar. > > I suggest that you fix your broken language or change the term 'Array' to > 'Bag' in the specification because where I come from 'Array' and 'List' can > be used interchangeably in some contexts but 'Array' and 'Bag' cannot. > > On Tue, Sep 18, 2012 at 12:45 PM, Julian Reschke wrote: > >> On 2012-09-18 18:32, Phillip Hallam-Baker wrote: >> >>> >>> >>> On Tue, Sep 18, 2012 at 9:39 AM, Julian Reschke >> **> wrote: >>> >>> On 2012-09-18 13:35, Phillip Hallam-Baker wrote: >>> >>> ... >>> >>> It is pretty clear that change control for using JSON in >>> application >>> protocols is going to have to rest with IETF as the IETF >>> criteria are >>> going to be stricter. RFC4267 is not a sufficient description in >>> my >>> view, you have to state things such as whether the order of >>> objects >>> matters, what to do if an unexpected tag is encountered and >>> several >>> other issues. >>> ... >>> >>> >>> - The ordering of objects does not matter. There's nothing to define >>> here. >>> >>> >>> You have to decide whether it matters or not. JSON does not commit to >>> one approach or the other. >>> >> >> It doesn't matter in Javascript, so trying to make it matter in JSON will >> break with many existing implementations. >> >> >> It makes a very big difference when you try to implement a protocol. As >>> far as the bits on the wire go there is no difference between >>> List and Bag but there is a very big difference at the >>> application layer. >>> >> >> Indeed. If you need ordering you can't rely on object order. >> >> >> In my protocol I am sending a JSON structure that contains an ordered >>> list of potential choices for a connection to a service endpoint. In >>> other words the order darn well matters in that case and anyone who >>> simply throws the data into a hash tree is going to end up with the >>> wrong result. >>> >> >> ...which is what some browsers do (and rightly so), so your protocol has >> a design problem :-). >> >> >> - Handling unexpected tags is an application-level issue; the answer >>> is likely to depend on the use case. >>> >>> >>> Precisely my point. Application protocols have to decide whether they >>> care about these things. >>> >> >> Yes. >> >> >> This is actually the sort of thing that becomes apparent when you use a >>> schema. So if you are writing something like SAML you might have: >>> >>> Type Assertion >>> Statements List Any >>> Conditions List Any >>> Advice List Any >>> >>> So the following would be valid JSON (according to a particular mapping, >>> give or take some punctuation): >>> >>> { "Assertion" [ {"Authenticate" {...}} ], >>> "Conditions" [], >>> "Advice" [] } >>> >>> There are three lists and any tagged object can be inserted into any of >>> the lists, so the structure can be extended in certain places but the >>> following would be a parse error: >>> >>> { "Assertion" [ {"Authenticate" {...}} ], >>> "Conditions" [], >>> "Advice" [] >>> "NewList" [] } >>> >>> Deciding whether the order in which members of a tagged structure like >>> the above occur matters is another choice. In SAML the order does matter >>> but there is no particular reason that it needs to matter. >>> >>> >>> >>> Just citing RFC 4627 is not sufficient to describe how to implement a >>> protocol. >>> >> >> That is true, but that's not a defect of RFC 4627. >> >> >> If the draft is going to be revised and become a Proposed Standard, I >>> would like to see it mention these issue as choices that a protocol >>> using JSON syntax must address clearly. >>> >> >> I agree for the bot about handling unexpected content (== extension >> elements). >> >> >> Simply deciding to use JSON does not remove the obligation to be precise >>> when stating what is acceptable and what is not. If you are going to >>> have a specification that says order does not matter then you are going >>> to have to test for that when you do interop testing. Contrawise if you >>> decide that order does matter then you are going to have to test for >>> that. >>> >> >> Again, if you make ordering significant you are in trouble. And yes, as >> this question comes up from time to time, a revision of 4627 could mention >> that. >> >> Best regards, Julian >> >> > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --20cf302077dcdaaf5004c9fcc672 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A couple points of clarification... th= e ordering of objects in a JSON Array *does* matter. The ordering of key:va= lue pairs within an object does not. [1,2] is not equivalent to [2,1] while= {"a":"b","c":"d"} is equivalent to= {"c":"d","a":"b"}. The spec could = be clearer on this point, definitely.

    - James

    On Tu= e, Sep 18, 2012 at 9:51 AM, Phillip Hallam-Baker <hallam@gmail.com><= /span> wrote:
    RFC 4627 states:

    2.3.  Arrays

   An array structure is represented as square brackets surrounding zero
   or more values (or elements).  Elements are separated by commas.

      array =3D begin-array [ value *( value-separator value ) ] end-array<=
/pre>
    So has JavaScript redefined the meaning of 'Array' then?=
=C2=A0

    how vewy peculiar.

    I suggest that you fix your broken language or change the term 'Array&=
#39; to 'Bag' in the specification because where I come from 'A=
rray' and 'List' can be used interchangeably in some contexts b=
ut 'Array' and 'Bag' cannot.

    On Tue, Sep 18, 2012 at 12:45 PM, Julian Res= chke <julian.reschke@gmx.de> wrote:
    On 2012-09-18 18:32, Phillip Hallam-Baker wrote:


    On Tue, Sep 18, 2012 at 9:39 AM, Julian Reschke <julian.reschke@gmx.de
    <mailto:julia= n.reschke@gmx.de>> wrote:

    =C2=A0 =C2=A0 On 2012-09-18 13:35, Phillip Hallam-Baker wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 It is pretty clear that change control for usin= g JSON in application
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 protocols is going to have to rest with IETF as= the IETF
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 criteria are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 going to be stricter. RFC4267 is not a sufficie= nt description in my
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 view, you have to state things such as whether = the order of objects
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 matters, what to do if an unexpected tag is enc= ountered and several
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 other issues.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...


    =C2=A0 =C2=A0 - The ordering of objects does not matter. There's nothin= g to define
    =C2=A0 =C2=A0 here.


    You have to decide whether it matters or not. JSON does not commit to
    one approach or the other.

    It doesn't matter in Javascript, so trying to make it matter in JSON wi= ll break with many existing implementations.


    It makes a very big difference when you try to implement a protocol. As
    far as the bits on the wire go there is no difference between
    List<Object> and Bag<Object> but there is a very big difference= at the
    application layer.

    Indeed. If you need ordering you can't rely on object order.


    In my protocol I am sending a JSON structure that contains an ordered
    list of potential choices for a connection to a service endpoint. In
    other words the order darn well matters in that case and anyone who
    simply throws the data into a hash tree is going to end up with the
    wrong result.

    ...which is what some browsers do (and rightly so), so your protocol has a = design problem :-).


    =C2=A0 =C2=A0 - Handling unexpected tags is an application-level issue; the= answer
    =C2=A0 =C2=A0 is likely to depend on the use case.


    Precisely my point. Application protocols have to decide whether they
    care about these things.

    Yes.


    This is actually the sort of thing that becomes apparent when you use a
    schema. So if you are writing something like SAML you might have:

    Type Assertion
    =C2=A0 =C2=A0 =C2=A0Statements List Any
    =C2=A0 =C2=A0 =C2=A0Conditions List Any
    =C2=A0 =C2=A0 =C2=A0Advice List Any

    So the following would be valid JSON (according to a particular mapping, give or take some punctuation):

    { "Assertion" [ {"Authenticate" {...}} ],
    =C2=A0 =C2=A0"Conditions" [],
    =C2=A0 =C2=A0"Advice" [] }

    There are three lists and any tagged object can be inserted into any of
    the lists, so the structure can be extended in certain places but the
    following would be a parse error:

    { "Assertion" [ {"Authenticate" {...}} ],
    =C2=A0 =C2=A0"Conditions" [],
    =C2=A0 =C2=A0"Advice" []
    =C2=A0 =C2=A0"NewList" [] }

    Deciding whether the order in which members of a tagged structure like
    the above occur matters is another choice. In SAML the order does matter but there is no particular reason that it needs to matter.



    Just citing RFC 4627 is not sufficient to describe how to implement a
    protocol.

    That is true, but that's not a defect of RFC 4627.


    If the draft is going to be revised and become a Proposed Standard, I
    would like to see it mention these issue as choices that a protocol
    using JSON syntax must address clearly.

    I agree for the bot about handling unexpected content (=3D=3D extension ele= ments).


    Simply deciding to use JSON does not remove the obligation to be precise when stating what is acceptable and what is not. If you are going to
    have a specification that says order does not matter then you are going
    to have to test for that when you do interop testing. Contrawise if you
    decide that order does matter then you are going to have to test for that.<= br>

    Again, if you make ordering significant you are in trouble. And yes, as thi= s question comes up from time to time, a revision of 4627 could mention tha= t.

    Best regards, Julian




    --
    Website: http://hallambaker.com/
    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss


    --20cf302077dcdaaf5004c9fcc672-- From julian.reschke@gmx.de Tue Sep 18 09:57:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0706821F8505 for ; Tue, 18 Sep 2012 09:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.165 X-Spam-Level: X-Spam-Status: No, score=-103.165 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cliGskQIlR8y for ; Tue, 18 Sep 2012 09:57:52 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0686421F8504 for ; Tue, 18 Sep 2012 09:57:49 -0700 (PDT) Received: (qmail invoked by alias); 18 Sep 2012 16:57:48 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 18 Sep 2012 18:57:48 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/3orNjW8j3nk34RxENQonCIAe6ZGMkqaMA+utHFR WHlf77W3Zu1gn9 Message-ID: <5058A808.7050803@gmx.de> Date: Tue, 18 Sep 2012 18:57:44 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" , "Joe Hildebrand \(jhildebr\)" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:57:53 -0000 On 2012-09-18 18:47, Phillip Hallam-Baker wrote: > How can you use tools 'correctly' without having a definition of what > 'correct' is? > > I can't see a place in the JSON specification where it says that the > following are equivalent: > > [ {"name": "foo", "value": "one"}, {"name": "bar", "value": "two"}] > [ {"name": "foo", "value": "two"}, {"name": "bar", "value": "one"}] They are not equivalent. > If you want them to be equivalent then you have to say so and this has > to be something the WG discusses and comes to consensus on. > > This is what we do with RFC822 headers, there is an explicit statement > in the spec that says that the order in which the headers are presented > does not change the semantics. > > My opinion is that considering the elements to be lists of items rather > than bags is better because it is less work using appropriate tools and > the resulting representation is more compact. Again, you can't change application/json to have semantics that Javascript does not have. Best regards, Julian From jasnell@gmail.com Tue Sep 18 10:10:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0A221F84B8 for ; Tue, 18 Sep 2012 10:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.735 X-Spam-Level: X-Spam-Status: No, score=-2.735 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FQKmLa4JRD7 for ; Tue, 18 Sep 2012 10:10:35 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6D921F85F3 for ; Tue, 18 Sep 2012 10:10:34 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so40689wgb.13 for ; Tue, 18 Sep 2012 10:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6ZZOCKduyfYLBYc8Xl5CVx+IxAhRuvB9sN4/tGk+O1E=; b=WTjN21OUhKGpSMScEqpF4Okh5RPltNaIn6luWW8RJD0vZeUk1O8Vm4dbhpCOqwWDLk 3vw6Hma1nqxyVXDj+HGA9gvMjaHjJ28MVzBM3p45CU4Ipd5iSSZUxEWGSHe15ida7AFK X/tbW11e5UylRgtpmGiQin2r6YOD0MuJ6FvUmrWlVixPq1osx4BuDkTQUe2DosGyaDhZ FmCIW5KILpduf1C7hVQgByMQ6Bjl/gsFL/byh6BsH6D6ebui26+cHNa1NOTGP/MeoqmQ uxTQLj3E4Taj0yzOQpPs4eXnLApcI74yPP6bllr+pPdRT2ddwJk0rt5l6UxHUujtqsw3 v8EA== Received: by 10.180.78.40 with SMTP id y8mr899534wiw.7.1347988233725; Tue, 18 Sep 2012 10:10:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.96.2 with HTTP; Tue, 18 Sep 2012 10:10:13 -0700 (PDT) In-Reply-To: <5058A808.7050803@gmx.de> References: <5058A808.7050803@gmx.de> From: James M Snell Date: Tue, 18 Sep 2012 10:10:13 -0700 Message-ID: To: Julian Reschke Content-Type: multipart/alternative; boundary=f46d043c80b4d5251604c9fcf79e Cc: "Joe Hildebrand \(jhildebr\)" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 17:10:36 -0000 --f46d043c80b4d5251604c9fcf79e Content-Type: text/plain; charset=UTF-8 In fact... the current introduction of RFC4627 makes this all quite clear... [snip] An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array. An array is an ordered sequence of zero or more values. The terms "object" and "array" come from the conventions of JavaScript. JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript. [snip] - James On Tue, Sep 18, 2012 at 9:57 AM, Julian Reschke wrote: > On 2012-09-18 18:47, Phillip Hallam-Baker wrote: > >> How can you use tools 'correctly' without having a definition of what >> 'correct' is? >> >> I can't see a place in the JSON specification where it says that the >> following are equivalent: >> >> [ {"name": "foo", "value": "one"}, {"name": "bar", "value": "two"}] >> [ {"name": "foo", "value": "two"}, {"name": "bar", "value": "one"}] >> > > They are not equivalent. > > > If you want them to be equivalent then you have to say so and this has >> to be something the WG discusses and comes to consensus on. >> >> This is what we do with RFC822 headers, there is an explicit statement >> in the spec that says that the order in which the headers are presented >> does not change the semantics. >> >> My opinion is that considering the elements to be lists of items rather >> than bags is better because it is less work using appropriate tools and >> the resulting representation is more compact. >> > > Again, you can't change application/json to have semantics that Javascript > does not have. > > Best regards, Julian > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --f46d043c80b4d5251604c9fcf79e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In fact... the current introduction of= RFC4627 makes this all quite clear...

    [sn= ip]
       An object is an unordered collection of zero or=
 more name/value
   pairs, where a name is a string and a value is a string, number,
   boolean, null, object, or array.

   An array is an ordered sequence of zero or more values.

   The terms "object" and "array" come from the convent=
ions of
   JavaScript.

   JSON's design goals were for it to be minimal, portable, textual, an=
d
   a subset of JavaScript.
    [snip]

    - James
    <= br>
    On Tue, Sep 18, 2012 at 9:57 AM, Julian Reschke = <julian.reschke@gmx.de> wrote:
    On 2012-09-18 18:47, Phillip Hallam-Baker wrote:
    How can you use tools 'correctly' without having a definition of wh= at
    'correct' is?

    I can't see a place in the JSON specification where it says that the following are equivalent:

    [ {"name": "foo", "value": "one"}, = {"name": "bar", "value": "two"}] [ {"name": "foo", "value": "two"}, = {"name": "bar", "value": "one"}]

    They are not equivalent.


    If you want them to be equivalent then you have to say so and this has
    to be something the WG discusses and comes to consensus on.

    This is what we do with RFC822 headers, there is an explicit statement
    in the spec that says that the order in which the headers are presented
    does not change the semantics.

    My opinion is that considering the elements to be lists of items rather
    than bags is better because it is less work using appropriate tools and
    the resulting representation is more compact.

    Again, you can't change application/json to have semantics that Javascr= ipt does not have.

    Best regards, Julian

    _______________________________________________
    apps-discuss mailing list
    apps-discuss@iet= f.org
    https://www.ietf.org/mailman/listinfo/apps-discuss

    --f46d043c80b4d5251604c9fcf79e-- From hallam@gmail.com Tue Sep 18 10:16:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756FE21F86A3 for ; Tue, 18 Sep 2012 10:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuCiMJCaagJH for ; Tue, 18 Sep 2012 10:16:33 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0C021F8688 for ; Tue, 18 Sep 2012 10:16:33 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so103905obb.31 for ; Tue, 18 Sep 2012 10:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wwjPu8aVCAmDgAkQ4jvZ8D8VBp7Z+tzZ3Hrh1VRDbkg=; b=qIa6vt0aF1iRalXT/fbw+NU9i9OYdtUWJCtcjnunkwKr2jhy82hfpDExKBr5Wv//sb JaDUzetSWGhaDehN6RAJGUHBt4R8j7nJkb/Nvi0Qn1A/sHP+R2+fsFnnfYEQ4sdPFcrY d2zf3L4GgZDxgk8wC74HOtyPqUmM7QZEOSZyO4T4DlwSyKQr04RuhPAKeCgBRZwPuxFc cOhtxHWBlT/VXgh7vGORYIURWrRvOVvqz/kkhmYU0xB4JpDnxPBiKrMMm20JkzOTHwtf J4s2ewLsXgS3xQiiQNNRB0/dq7oUzUCEQeWCWUbDLziDl3xCM0VYZWPZ9yewX0GJ+agt WSaQ== MIME-Version: 1.0 Received: by 10.60.172.236 with SMTP id bf12mr915334oec.23.1347988593007; Tue, 18 Sep 2012 10:16:33 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Tue, 18 Sep 2012 10:16:32 -0700 (PDT) In-Reply-To: <5058A764.9080301@gmx.de> References: <505879AE.5060307@gmx.de> <5058A52B.7060405@gmx.de> <5058A764.9080301@gmx.de> Date: Tue, 18 Sep 2012 13:16:32 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=bcaec54d47683f5dba04c9fd0d9d Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 17:16:34 -0000 --bcaec54d47683f5dba04c9fd0d9d Content-Type: text/plain; charset=ISO-8859-1 When I use language, I try to be precise. The order of objects and the order of entries within objects are not the same. Even so, when writing a spec I usually call out such distinctions clearly if I notice them and telling people that this is what they need to do is something that I would like RFC 4627-BIS to address specifically. In another part of the schema compiler I allow objects with repeated elements: { "A": 1, "A": 2, "B": 3 } Now my code does not see a difference between that and { "B": 3, "A": 1, "A": 2 } or { "A": 1, "B": 3, "A": 2 } The serializer will emit the data in a canonical order but accepts them in any order. So an application could consider the following to be different: { "A": 2, "A": 1, "B": 3 } The same is almost certainly true of the hash bag approach, at least for some hash baggers but not necessarily of others. Whether the order of a repeated element is significant or not is going to have quite an impact on your design. On Tue, Sep 18, 2012 at 12:55 PM, Julian Reschke wrote: > On 2012-09-18 18:51, Phillip Hallam-Baker wrote: > >> RFC 4627 states: >> >> 2.3. Arrays >> >> An array structure is represented as square brackets surrounding zero >> or more values (or elements). Elements are separated by commas. >> >> array = begin-array [ value *( value-separator value ) ] end-array >> >> So has JavaScript redefined the meaning of 'Array' then? >> >> how vewy peculiar. >> > > No. Arrays are indeed ordered. But ordering inside an *object* is not > significant. > > > I suggest that you fix your broken language or change the term 'Array' >> to 'Bag' in the specification because where I come from 'Array' and >> 'List' can be used interchangeably in some contexts but 'Array' and >> 'Bag' cannot. >> > > Philip, you asked: > > > you have to state things such as whether the order of objects matters >> > > It does not matter in objects, but it does matter in arrays. > > Best regards, Julian > -- Website: http://hallambaker.com/ --bcaec54d47683f5dba04c9fd0d9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable When I use language, I try to be precise. The order of objects and the orde= r of entries within objects are not the same.

    Even so, w= hen writing a spec I usually call out such distinctions clearly if I notice= them and telling people that this is what they need to do is something tha= t I would like RFC 4627-BIS to address specifically.


    In another part of the schema compiler I= allow objects with repeated elements:

    { "A&q= uot;: 1, "A": 2, "B": 3 }

    Now my code does not see a difference between that and=A0

    {=A0"B": 3,=A0"A": 1, "A": 2 } or=A0{= =A0"A": 1,=A0"B": 3,=A0"A": 2 }
    The serializer will emit the data in a canonical order but accepts them in = any order. So an application could consider the following to be different:<= /div>

    { "A": 2, "A": 1, "B"= ;: 3 }

    The same is almost certainly true of the hash bag= approach, at least for some hash baggers but not necessarily of others. Wh= ether the order of a repeated element is significant or not is going to hav= e quite an impact on your design.


    On Tue, Sep 18, 2012 at 12:55 = PM, Julian Reschke <julian.reschke@gmx.de> wrote:
    On 2012-09-18 18:51, Phillip Hallam-Baker wrote:
    RFC 4627 states:

    2.3. =A0Arrays

    =A0 =A0 An array structure is represented as square brackets surrounding ze= ro
    =A0 =A0 or more values (or elements). =A0Elements are separated by commas.<= br>
    =A0 =A0 =A0 =A0array =3D begin-array [ value *( value-separator value ) ] e= nd-array

    So has JavaScript redefined the meaning of 'Array' then?

    how vewy peculiar.

    No. Arrays are indeed ordered. But ordering inside an *object* is not signi= ficant.


    I suggest that you fix your broken language or change the term 'Array&#= 39;
    to 'Bag' in the specification because where I come from 'Array&= #39; and
    'List' can be used interchangeably in some contexts but 'Array&= #39; and
    'Bag' cannot.

    Philip, you asked:


    you have to state things such as whether the order of objects matters

    It does not matter in objects, but it does matter in arrays.

    Best regards, Julian



    --
    Website: http://hallambaker.com/

    --bcaec54d47683f5dba04c9fd0d9d-- From hallam@gmail.com Tue Sep 18 10:23:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC03A21F86A3 for ; Tue, 18 Sep 2012 10:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=-1.341, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-9OHolADdUG for ; Tue, 18 Sep 2012 10:23:06 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 14A1C21E80CA for ; Tue, 18 Sep 2012 10:23:03 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so112440obb.31 for ; Tue, 18 Sep 2012 10:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h8jj/+n2LyxlL5AWuTmiG5xFuuyUQ3sxGMuv5F6OZ/k=; b=c8/dhoBg+pphvVX5eKr3krU+tH1IC8jWV1MKShYndwBirVmt6MCczE1dzufhF/zyqk SDJUj/mzAVraIT2cqRNdaQOKUXtEiIbq7vGbyfYrakM648z1c/gZ15XNgqOzU7z6+Yps iMKjAnJnVVgaqI/g/B79LfnPqAYSoISnZLIGxG9ViKnIEUoJTfuZxFLVwzWrPucFjFhA 6RrapAvyU/PGTu/S7881/01oYs0G0wkFthZaty7RgA1DA9rYQhosAsRhkbqGvbPMC9+l +O+d5coN0PvrLWO+VT6hzSkbx4DrnsqbObGeuAPajmzn10K1SQauGs+pktaXdEi/xlIm F4OA== MIME-Version: 1.0 Received: by 10.182.207.6 with SMTP id ls6mr880159obc.36.1347988982560; Tue, 18 Sep 2012 10:23:02 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Tue, 18 Sep 2012 10:23:02 -0700 (PDT) In-Reply-To: References: <5058A808.7050803@gmx.de> Date: Tue, 18 Sep 2012 13:23:02 -0400 Message-ID: From: Phillip Hallam-Baker To: James M Snell Content-Type: multipart/alternative; boundary=e89a8f646e2b77782a04c9fd24ba Cc: Julian Reschke , "Joe Hildebrand \(jhildebr\)" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 17:23:07 -0000 --e89a8f646e2b77782a04c9fd24ba Content-Type: text/plain; charset=ISO-8859-1 Which would seem to be a statement that should occur in the section headed 'grammar'... Note that pretty much all the preceeding examples given by folk also violate the following: An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The names within an object SHOULD be unique. I don't think you can have a SHOULD there in a standard of this type. Either the spec allows for non-unique names or it does not. It would seem reasonable to require names to be unique since the case of repeated names can be addressed using arrays. On Tue, Sep 18, 2012 at 1:10 PM, James M Snell wrote: > In fact... the current introduction of RFC4627 makes this all quite > clear... > > [snip] > > An object is an unordered collection of zero or more name/value > pairs, where a name is a string and a value is a string, number, > boolean, null, object, or array. > > An array is an ordered sequence of zero or more values. > > The terms "object" and "array" come from the conventions of > JavaScript. > > JSON's design goals were for it to be minimal, portable, textual, and > a subset of JavaScript. > > [snip] > > - James > > On Tue, Sep 18, 2012 at 9:57 AM, Julian Reschke wrote: > >> On 2012-09-18 18:47, Phillip Hallam-Baker wrote: >> >>> How can you use tools 'correctly' without having a definition of what >>> 'correct' is? >>> >>> I can't see a place in the JSON specification where it says that the >>> following are equivalent: >>> >>> [ {"name": "foo", "value": "one"}, {"name": "bar", "value": "two"}] >>> [ {"name": "foo", "value": "two"}, {"name": "bar", "value": "one"}] >>> >> >> They are not equivalent. >> >> >> If you want them to be equivalent then you have to say so and this has >>> to be something the WG discusses and comes to consensus on. >>> >>> This is what we do with RFC822 headers, there is an explicit statement >>> in the spec that says that the order in which the headers are presented >>> does not change the semantics. >>> >>> My opinion is that considering the elements to be lists of items rather >>> than bags is better because it is less work using appropriate tools and >>> the resulting representation is more compact. >>> >> >> Again, you can't change application/json to have semantics that >> Javascript does not have. >> >> Best regards, Julian >> >> ______________________________**_________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/**listinfo/apps-discuss >> > > -- Website: http://hallambaker.com/ --e89a8f646e2b77782a04c9fd24ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Which would seem to be a statement that should occur in the section headed = 'grammar'...


    Note that pretty muc= h all the preceeding examples given by folk also violate the following: 

       An object structure is represented as a pair of curly brackets
   surrounding zero or more name/value pairs (or members).  A name is a
   string.  A single colon comes after each name, separating the name
   from the value.  A single comma separates a value from a following
   name.  The names within an object SHOULD be unique.

    = I don't think you can have a SHOULD there in a standard of this type. E= ither the spec allows for non-unique names or it does not.

    It would seem reasonable to require names to be unique since the= case of repeated names can be addressed using arrays.

    On Tue, Sep 18, 2012 at 1:10 PM, James M Snell <jasnell@gmai= l.com> wrote:
    In fact= ... the current introduction of RFC4627 makes this all quite clear...

    [snip]
       An object is an unordered collection of zero or=
 more name/value
   pairs, where a name is a string and a value is a string, number,
   boolean, null, object, or array.

   An array is an ordered sequence of zero or more values.

   The terms "object" and "array" come from the convent=
ions of
   JavaScript.

   JSON's design goals were for it to be minimal, portable, textual, an=
d
   a subset of JavaScript.
    [snip]

    - James

    On Tue, Sep= 18, 2012 at 9:57 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
    On 2012-09-18 18:47, Phillip Hallam-Baker wrote:
    How can you use tools 'correctly' without having a definition of wh= at
    'correct' is?

    I can't see a place in the JSON specification where it says that the following are equivalent:

    [ {"name": "foo", "value": "one"}, = {"name": "bar", "value": "two"}] [ {"name": "foo", "value": "two"}, = {"name": "bar", "value": "one"}]

    They are not equivalent.


    If you want them to be equivalent then you have to say so and this has
    to be something the WG discusses and comes to consensus on.

    This is what we do with RFC822 headers, there is an explicit statement
    in the spec that says that the order in which the headers are presented
    does not change the semantics.

    My opinion is that considering the elements to be lists of items rather
    than bags is better because it is less work using appropriate tools and
    the resulting representation is more compact.

    Again, you can't change application/json to have semantics that Javascr= ipt does not have.

    Best regards, Julian

    _______________________________________________
    apps-discuss mailing list
    apps-discuss@iet= f.org
    https://www.ietf.org/mailman/listinfo/apps-discuss




    --
    Website: http://hallambaker.com/

    --e89a8f646e2b77782a04c9fd24ba-- From jhildebr@cisco.com Tue Sep 18 10:26:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AE421F86E2 for ; Tue, 18 Sep 2012 10:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcKc83DXDOcj for ; Tue, 18 Sep 2012 10:26:51 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 988D521F86DF for ; Tue, 18 Sep 2012 10:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=548; q=dns/txt; s=iport; t=1347989211; x=1349198811; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=3vcwdZHvIL+HgjIGotnCj0GKM3shWulD9B1nAqiLQpU=; b=RwOasixVjFX2NcbHcqLec3B6nxvPm0mBx0McXiAD5CxuuZ7X7F0dX9c3 HZKm2TBsY2fIcvVj2aXRMklSnXLUxa6E8oI2psLFdxw7tQB7oiWktXekx OqGgPhYlZWSydg0WVCB7fnGqPNXl/Xf+W/03l6R4gL1emD54xRjH/xjuM c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAAmuWFCtJV2a/2dsb2JhbABFhUK3AIEIgicSASc/EgEINjERJQIEAQ0FIodPAwyaJpZaDYlTijmHUgOUDoFVixeDIYFpgmaCFw X-IronPort-AV: E=Sophos;i="4.80,444,1344211200"; d="scan'208";a="122850495" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 18 Sep 2012 17:26:51 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8IHQpdw031463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 17:26:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Tue, 18 Sep 2012 12:26:50 -0500 From: "Joe Hildebrand (jhildebr)" To: Phillip Hallam-Baker , James M Snell Thread-Topic: [apps-discuss] Guidance on RFC 4627 as reference Thread-Index: AQHNlY3s9Yj5xKrn7EGS9IZMvZhKt5eQTCqAgAAivACAADBTAP//jIQAgAB3pYCAAALFAIAAA32AgAADlAD//4u0gA== Date: Tue, 18 Sep 2012 17:26:49 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.132.51] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19190.004 x-tm-as-result: No--26.198400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <892761651C04264181ECC0B221BAD51C@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 17:26:52 -0000 On 9/18/12 10:23 AM, "Phillip Hallam-Baker" wrote: >I don't think you can have a SHOULD there in a standard of this type. >Either the spec allows for non-unique names or it does not. Agree with that. It does not, so MUST is appropriate. >It would seem reasonable to require names to be unique since the case of >repeated names can be addressed using arrays. No, they aren't. Please don't complicate something simple because you don't want to change your syntax to match the simplicity. --=20 Joe Hildebrand From mnot@mnot.net Tue Sep 18 10:27:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E9B21E80DD for ; Tue, 18 Sep 2012 10:27:03 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSyYmMHDSlx7 for ; Tue, 18 Sep 2012 10:27:03 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id E256021E80D9 for ; Tue, 18 Sep 2012 10:27:02 -0700 (PDT) Received: from [172.30.66.198] (unknown [72.247.151.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A2E4822E259; Tue, 18 Sep 2012 13:26:55 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> Date: Tue, 18 Sep 2012 10:27:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347553816.23081.17.camel@pbryan-wsl.interna l.salesforce.com> <5 0546893.4080704@archive.org> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> To: Paul C. Bryan X-Mailer: Apple Mail (2.1486) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 17:27:03 -0000 I agree with the approach that Paul advocates here.=20 James is right that the document is currently silent about extra = properties on the operation. Do people have strong feelings about = whether this should result in an error condition, or be ignored? On 17/09/2012, at 12:33 PM, Paul C. Bryan wrote: > On Mon, 2012-09-17 at 17:32 +1000, Manger, James H wrote: >> The JSON patch spec looks good: draft-ietf-appsawg-json-patch-04. >>=20 >> There is no explicit mention of extensibility of the JSON patch = syntax. Presumably new operations (beyond = add/remove/replace/move/copy/test) could be added, with the = understanding that "old" implementations will reject such documents = [section 4 says an unknown operation is an error]. Adding extra fields = to an existing operation is less clear (eg = {"add":"/foo/1","value":"baz","repeat":10}). There is no explicit = mention that that would be an error. Perhaps implementations will ignore = unrecognized fields. >=20 > I had envisioned a container document type, which would enumerate a = set of conditions that must be met before processing the operations an = associated (contained) JSON Patch document. Taking this approach means = that there is no confusion over what's a JSON Patch document vs. the = extension document type. Since JSON Patch is an array of operation = objects, such a structure would remain relatively straightforward. >=20 > More concretely, perhaps something like: >=20 > { > "tests": [ > { "less-than": "/some/path", "value": 42 }, > { "exists": "/some/other/path" }, > { "not-exists": "/yet/another/path" }, >=20 > { "contains": "/foo/bar", "value": "Major-General" } >=20 > ], "application/json-patch": [ > { "replace": "/some/path", "value": 42 }, > { "delete": "/some/other/path" }, > { "add": "/yet/another/path", "value": "bar!" } > ] > } >=20 > Thoughts? >=20 >> Could more sophisticated future test rules define, say, a "test2" = operation? Or is it the expectation that such a syntax would need a new = media type? >=20 > I would say any extension should require its own media type. >=20 >> Each operation lists a full JSON pointer from the root of the = resource. If you want to replace a dozen fields in a deeply nested = object you need to repeat the path to that object a dozen times. This = may be a reasonable compromise to avoid a more complex patch structure = (particularly if compression removes much of the overhead), but I wasn't = sure if any alternative had been considered. For example, = {"patch":"/fee/fie/fo/fum/foo","value":[{"add":"x","value":"baz"},{"add":"= y","value":3}]}. >=20 > We've considered alternatives in the past, but concluded that given = the verbosity of the JSON Patch document, the likely strategy to reduce = size would be through compression. As such, multiple similar paths would = compress fairly well. >=20 >> Would I be opening a can of worms (or doing some bike-shedding) if I = asked why application/json-patch instead of application/patch+json? >=20 > Probably. I originally proposed application/patch+json. The main = problem with application/patch+json is that it implies that there are = other representations of application/patch, not just JSON (e.g. = application/patch+xml). In this case, JSON Patch is meant to address = only JSON documents in a JSON format. Furthermore, I'm not yet aware of = a specification for JSON like there is is for XML that promotes the = addition of +json. Therefore, I'd say that application/json-patch is = probably the better choice. >=20 > Paul -- Mark Nottingham http://www.mnot.net/ From jasnell@gmail.com Tue Sep 18 10:38:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668C921E80D9 for ; Tue, 18 Sep 2012 10:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH07KNtE9njv for ; Tue, 18 Sep 2012 10:38:48 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D86BB21F85EF for ; Tue, 18 Sep 2012 10:38:47 -0700 (PDT) Received: by weyx48 with SMTP id x48so62412wey.31 for ; Tue, 18 Sep 2012 10:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VS+5VqpiJjilJNcDLsuYvFQtYBGmDQC+uqOTjQs/UK8=; b=c7Nu8BjpLojVPwQwT1bCFYK3CK82APHSq4iz1LhdLgzZeQlPrH4fon3ZfAr4C6abwK +LAmM/jrO8zgN1qI2QRQ2/39Fu/WeXLytYpXyscJoK+pHLG3H4oZhv7YDk5wb1mnEhwI 8c5nZAXdsSo1eO4hXpAOhURXVUJgeJRaJchR249Y1ecoCyc1ZM2bv6qMR2GGuHWZL3b0 ycAnYIcEz/5dFbfqoVrn6X7rwmzQAm3bq0gnFI1xIjxyReGkMmbngd/njCLf7lvirXf0 yXOfSmTL21XLIuX59ihbQZ4GsNPBTMrVQzlrb3RGugR5f0IRatSu5keGe0zLOQhZOoBN NNNQ== Received: by 10.217.2.133 with SMTP id p5mr258681wes.143.1347989924226; Tue, 18 Sep 2012 10:38:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.96.2 with HTTP; Tue, 18 Sep 2012 10:38:23 -0700 (PDT) In-Reply-To: References: <5058A808.7050803@gmx.de> From: James M Snell Date: Tue, 18 Sep 2012 10:38:23 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=20cf301ee7c798265d04c9fd5cd4 Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 17:38:50 -0000 --20cf301ee7c798265d04c9fd5cd4 Content-Type: text/plain; charset=UTF-8 Again, the spec is very clear that the intent is to adopt the JavaScript semantics. JavaScript does not require that names within an object be unique, but it does specify that Property Attributes have a singular Value, meaning that if a given property is repeated within a structure, it's value is overwritten by each subsequent instance.. That is, given your example, { "A": 1, "A": 2, "B": 3 } The value of "A" is 2. The fact that there are two values for "A" given is not, by itself, an error. However, unexpected results could occur depending on how a developer processes the object structure and multiple instances of a property are almost always indicative of a bug. The SHOULD here is appropriate, then, in that developers really shouldn't be specifying a given property more than once but it's technically not an error if they do. - James On Tue, Sep 18, 2012 at 10:23 AM, Phillip Hallam-Baker wrote: > Which would seem to be a statement that should occur in the section headed > 'grammar'... > > > Note that pretty much all the preceeding examples given by folk also > violate the following: > > An object structure is represented as a pair of curly brackets > surrounding zero or more name/value pairs (or members). A name is a > string. A single colon comes after each name, separating the name > from the value. A single comma separates a value from a following > name. The names within an object SHOULD be unique. > > > I don't think you can have a SHOULD there in a standard of this type. > Either the spec allows for non-unique names or it does not. > > It would seem reasonable to require names to be unique since the case of > repeated names can be addressed using arrays. > > > On Tue, Sep 18, 2012 at 1:10 PM, James M Snell wrote: > >> In fact... the current introduction of RFC4627 makes this all quite >> clear... >> >> [snip] >> >> An object is an unordered collection of zero or more name/value >> pairs, where a name is a string and a value is a string, number, >> boolean, null, object, or array. >> >> An array is an ordered sequence of zero or more values. >> >> The terms "object" and "array" come from the conventions of >> JavaScript. >> >> JSON's design goals were for it to be minimal, portable, textual, and >> a subset of JavaScript. >> >> [snip] >> >> - James >> >> On Tue, Sep 18, 2012 at 9:57 AM, Julian Reschke wrote: >> >>> On 2012-09-18 18:47, Phillip Hallam-Baker wrote: >>> >>>> How can you use tools 'correctly' without having a definition of what >>>> 'correct' is? >>>> >>>> I can't see a place in the JSON specification where it says that the >>>> following are equivalent: >>>> >>>> [ {"name": "foo", "value": "one"}, {"name": "bar", "value": "two"}] >>>> [ {"name": "foo", "value": "two"}, {"name": "bar", "value": "one"}] >>>> >>> >>> They are not equivalent. >>> >>> >>> If you want them to be equivalent then you have to say so and this has >>>> to be something the WG discusses and comes to consensus on. >>>> >>>> This is what we do with RFC822 headers, there is an explicit statement >>>> in the spec that says that the order in which the headers are presented >>>> does not change the semantics. >>>> >>>> My opinion is that considering the elements to be lists of items rather >>>> than bags is better because it is less work using appropriate tools and >>>> the resulting representation is more compact. >>>> >>> >>> Again, you can't change application/json to have semantics that >>> Javascript does not have. >>> >>> Best regards, Julian >>> >>> ______________________________**_________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/**listinfo/apps-discuss >>> >> >> > > > -- > Website: http://hallambaker.com/ > > --20cf301ee7c798265d04c9fd5cd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Again, the spec is very clear that the= intent is to adopt the JavaScript semantics. JavaScript does not require t= hat names within an object be unique, but it does specify that Property Att= ributes have a singular Value, meaning that if a given property is repeated= within a structure, it's value is overwritten by each subsequent insta= nce..

    That is, given your ex= ample,=C2=A0

    =C2=A0 { "A": 1, "A": 2, "B": 3= }

    =C2=A0 The value of "A" is 2.=C2=A0

    The fact that there are two values for "A" given is not, by i= tself, an error. However, unexpected results could occur depending on how a= developer processes the object structure and multiple instances of a prope= rty are almost always indicative of a bug. The SHOULD here is appropriate, = then, in that developers really shouldn't be specifying a given propert= y more than once but it's technically not an error if they do.

    - James


    On Tue, Sep 18,= 2012 at 10:23 AM, Phillip Hallam-Baker <hallam@gmail.com> wr= ote:
    Which would seem to be a statement that shou= ld occur in the section headed 'grammar'...


    Note that pretty much all the preceeding examples given by folk = also violate the following:

       An object structure is represented as a pair of curly brackets
   surrounding zero or more name/value pairs (or members).  A name is a
   string.  A single colon comes after each name, separating the name
   from the value.  A single comma separates a value from a following
   name.  The names within an object SHOULD be unique.

    = I don't think you can have a SHOULD there in a standard of this type. E= ither the spec allows for non-unique names or it does not.

    It would seem reasonable to require names to be unique since the= case of repeated names can be addressed using arrays.


    On Tue, Sep 18, 2012 at 1:10 PM, James= M Snell <jasnell@gmail.com> wrote:
    In fact= ... the current introduction of RFC4627 makes this all quite clear...

    [snip]
       An object is an unordered collection of zero or=
 more name/value
   pairs, where a name is a string and a value is a string, number,
   boolean, null, object, or array.

   An array is an ordered sequence of zero or more values.

   The terms "object" and "array" come from the convent=
ions of
   JavaScript.

   JSON's design goals were for it to be minimal, portable, textual, an=
d
   a subset of JavaScript.
    [snip]

    - James

    On Tue, Sep 18, 2012 at = 9:57 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
    On 2012-09-18 18:47, Phillip Hallam-Baker wrote:
    How can you use tools 'correctly' without having a definition of wh= at
    'correct' is?

    I can't see a place in the JSON specification where it says that the following are equivalent:

    [ {"name": "foo", "value": "one"}, = {"name": "bar", "value": "two"}] [ {"name": "foo", "value": "two"}, = {"name": "bar", "value": "one"}]

    They are not equivalent.


    If you want them to be equivalent then you have to say so and this has
    to be something the WG discusses and comes to consensus on.

    This is what we do with RFC822 headers, there is an explicit statement
    in the spec that says that the order in which the headers are presented
    does not change the semantics.

    My opinion is that considering the elements to be lists of items rather
    than bags is better because it is less work using appropriate tools and
    the resulting representation is more compact.

    Again, you can't change application/json to have semantics that Javascr= ipt does not have.

    Best regards, Julian

    _______________________________________________
    apps-discuss mailing list
    apps-discuss@iet= f.org
    https://www.ietf.org/mailman/listinfo/apps-discuss




    --
    Website: http://hallambaker.com/



    --20cf301ee7c798265d04c9fd5cd4-- From hallam@gmail.com Tue Sep 18 10:39:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854EA21F8668 for ; Tue, 18 Sep 2012 10:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.058 X-Spam-Level: X-Spam-Status: No, score=-4.058 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvrnTpgYlJCC for ; Tue, 18 Sep 2012 10:39:21 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id B35B721F85EF for ; Tue, 18 Sep 2012 10:39:21 -0700 (PDT) Received: by oagk14 with SMTP id k14so133616oag.31 for ; Tue, 18 Sep 2012 10:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CpTe5qa8bHeta/3QIjgQG9NVzZjroTLc8v+6yNZ0pk0=; b=UosTZzirAmkFNtr5f+aufsEgzbfupdPaNf4dsl0p1d2E1ctYq5YuUQFcQKP73NvImi /UGLxIQG5CLQz6o0G7gWR0nRq+JV7XANGI53fvQM+8sLIs2E4wkxH6dgF2WpX9sL5GTq SAq0TALCy1Bs2sSk3zO7opEiaHlKHyPngEE5Q3GuIWHqagD+PDZ2Q6JtikavdaThCkl0 kPCAlSgUc8vuDAO7x5pm2s4/ZMDdgNP9yapHDE8DUob88+zdfYTo0byhvkoPP3qr0vIQ jaoBv51i+i5ncMLb2BlJs+5eE2ZbRmLfXGWsHCJVRqgVQe4mX4TB0wvpgU7RrilC80XD GBkA== MIME-Version: 1.0 Received: by 10.182.174.100 with SMTP id br4mr862166obc.62.1347989956923; Tue, 18 Sep 2012 10:39:16 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Tue, 18 Sep 2012 10:39:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Sep 2012 13:39:16 -0400 Message-ID: From: Phillip Hallam-Baker To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=e89a8f647b1d8b127704c9fd5e50 Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 17:39:22 -0000 --e89a8f647b1d8b127704c9fd5e50 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 18, 2012 at 1:26 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 9/18/12 10:23 AM, "Phillip Hallam-Baker" wrote: > > >I don't think you can have a SHOULD there in a standard of this type. > >Either the spec allows for non-unique names or it does not. > > Agree with that. It does not, so MUST is appropriate. > > >It would seem reasonable to require names to be unique since the case of > >repeated names can be addressed using arrays. > > No, they aren't. Please don't complicate something simple because you > don't want to change your syntax to match the simplicity. ?? what I am saying is that someone who feels the need to write { "A": 1, "A": 2, "B": 3 } Should instead write { "A" : [1, 2], "B": 3 } Since every use case for a repeated tag can be met by a tag with a list of items, there is no need for the repeated tag. Thus it is reasonable to change the SHOULD to a MUST in a BIS to be used as a normative reference in protocol specs. So the changes to section 2.2 are: 1) State that the order of the taged entries does not matter (no, putting that in the introduction does not count). 2) Change the SHOULD only occur once to MUST NOT occur more than once. That still leaves open what an implementation may do when it encounters an unexpected, unknown or illegal tag. Which is the sort of thing that the security section should address. At any rate, I think this means that the idea of trying to use JSON syntax to describe JSON schemas is not going to work. I for one can't imagine wanting to use a schema notation where blocks are sometimes denoted using {} and sometimes by [] and the difference is essential to the semantics. -- Website: http://hallambaker.com/ --e89a8f647b1d8b127704c9fd5e50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Tue, Sep 18, 2012 at 1:26 PM, Joe Hil= debrand (jhildebr) <jhildebr@cisco.com> wrote:
    On 9/18/12 10:23 AM, "Phillip Hallam-Baker" <= ;hallam@gmail.com> wrote:

    >I don't think you can have a SHOULD there in a standard of this typ= e.
    >Either the spec allows for non-unique names or it does not.

    Agree with that. =A0It does not, so MUST is appropriate.

    >It would seem reasonable to require names to be unique since the case o= f
    >repeated names can be addressed using arrays.

    No, they aren't. =A0Please don't complicate something simple = because you
    don't want to change your syntax to match the simplicity.<= div>
    ?? what I am saying is that someone who feels the need t= o write

    { &q= uot;A": 1, "A": 2, "B": 3 }

    Should instead write=A0

    { "A" : [1, 2],=A0"B": 3 }
    =A0=A0
    Since every use case for a repeated tag can be met b= y a tag with a list of items, there is no need for the repeated tag.
    Thus it is reasonable to change the SHOULD to a MUST in a BIS = to be used as a normative reference in protocol specs.

    So the changes to section 2.2 are:

    =
    1) State that the order of the taged entries does not matter (no, putt= ing that in the introduction does not count).

    2) Change the SHOULD only occur once to MUST NOT occur more than once.


    That still leaves open what an implemen= tation may do when it encounters an unexpected, unknown or illegal tag. Whi= ch is the sort of thing that the security section should address.=A0

    At any rate, I think this means that the idea o= f trying to use JSON syntax to describe JSON schemas is not going to work. = I for one can't imagine wanting to use a schema notation where blocks a= re sometimes denoted using {} and sometimes by [] and the difference is ess= ential to the semantics.

    --
    Website: http://h= allambaker.com/

    --e89a8f647b1d8b127704c9fd5e50-- From pbryan@anode.ca Tue Sep 18 10:42:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3A921F85FC for ; Tue, 18 Sep 2012 10:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jb64sbM-t8i8 for ; Tue, 18 Sep 2012 10:42:17 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8B321F85EF for ; Tue, 18 Sep 2012 10:42:17 -0700 (PDT) Received: from [10.71.13.58] (adsl-75-55-201-218.dsl.pltn13.sbcglobal.net [75.55.201.218]) by maple.anode.ca (Postfix) with ESMTPSA id A7D1F648E; Tue, 18 Sep 2012 17:42:14 +0000 (UTC) Message-ID: <1347990131.4734.37.camel@polyglot> From: "Paul C. Bryan" To: Mark Nottingham Date: Tue, 18 Sep 2012 10:42:11 -0700 In-Reply-To: <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347553816.23081.17.camel@pbryan-wsl.interna l.salesforce.com> <5 0546893.4080704@archive.org> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> Content-Type: multipart/alternative; boundary="=-PwjwGwzZUzp0tAA/18kz" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 17:42:18 -0000 --=-PwjwGwzZUzp0tAA/18kz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Tue, 2012-09-18 at 10:27 -0700, Mark Nottingham wrote: > James is right that the document is currently silent about extra > properties on the operation. Do people have strong feelings about > whether this should result in an error condition, or be ignored? It was definitely intended to be an error condition. On this point, the specification reads: "It is an error condition if an operation object contains no recognized operation member or more than one operation member." I suppose it would be stronger to say something like: "It is an error condition if an operation object does not contain an operation member documented herein, or more than one operation member." Paul --=-PwjwGwzZUzp0tAA/18kz Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 2012-09-18 at 10:27 -0700, Mark Nottingham wrote:

    James is right that the document is currently silent about extra properties on the operation. Do people have strong feelings about whether this should result in an error condition, or be ignored?

    It was definitely intended to be an error condition. On this point, the specification reads:

        "It is an error condition if an operation object contains no recognized operation member or more than one operation member."

    I suppose it would be stronger to say something like:

        "It is an error condition if an operation object does not contain an operation member documented herein, or more than one operation member."

    Paul --=-PwjwGwzZUzp0tAA/18kz-- From jasnell@gmail.com Tue Sep 18 10:49:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEEE21F85C4 for ; Tue, 18 Sep 2012 10:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFyUkxkVmZUW for ; Tue, 18 Sep 2012 10:49:31 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id A85D921F85B4 for ; Tue, 18 Sep 2012 10:49:30 -0700 (PDT) Received: by wibhq12 with SMTP id hq12so5892467wib.1 for ; Tue, 18 Sep 2012 10:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=z+N8oAfNQ7UlpTZ9FIxtZGbHJTzOgycRXPAugwd45aI=; b=Kcp1vr+bz2ZsN72mNtWKmrvPnC7BQu1vjDjf8M3aOyh4i3AB9hY4wnygoFZYT9bVcb ros6RnGAY6HaAEW0lubvxEI68X4NEMeVqTb7dy7oA+RLjGGKScIkUPsj61pTBuLsIivH tNG1JGaRrWeBSuZkv0qNfxq8joXmZtoMGJGXF3Lse1/DeIF488iy5kW7ktB8T37iySJs fr4zES/X57uidGDsh/QUEdCb0CG5rpNM9WP/jhdSMz4TqEB323vDmsBFHon6lqoLbl18 +zWd5dPUl6Vv7EzS+yBdHLD16aHJrqlvPqvyQErTDjcbwLSchZTQC2OT9NiIixFbOk+9 FSDg== Received: by 10.180.98.200 with SMTP id ek8mr1126452wib.0.1347990569887; Tue, 18 Sep 2012 10:49:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.96.2 with HTTP; Tue, 18 Sep 2012 10:49:09 -0700 (PDT) In-Reply-To: <1347990131.4734.37.camel@polyglot> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> From: James M Snell Date: Tue, 18 Sep 2012 10:49:09 -0700 Message-ID: To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=f46d0442886014272004c9fd8358 Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 17:49:31 -0000 --f46d0442886014272004c9fd8358 Content-Type: text/plain; charset=UTF-8 +1 on having it be an error condition. Because of the potentially significant negative impact that an improperly applied patch operation could have on the target resource, any not-understood operation, object or member MUST result in an error condition being reported and the patch rejected. - James On Tue, Sep 18, 2012 at 10:42 AM, Paul C. Bryan wrote: > ** > On Tue, 2012-09-18 at 10:27 -0700, Mark Nottingham wrote: > > James is right that the document is currently silent about extra > properties on the operation. Do people have strong feelings about whether > this should result in an error condition, or be ignored? > > > It was definitely intended to be an error condition. On this point, the > specification reads: > > "It is an error condition if an operation object contains no > recognized operation member or more than one operation member." > > I suppose it would be stronger to say something like: > > "It is an error condition if an operation object does not contain an > operation member documented herein, or more than one operation member." > > Paul > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d0442886014272004c9fd8358 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 on having it be an error condition.= =C2=A0

    Because of the potentially significa= nt negative impact that an improperly applied patch operation could have on= the target resource, any not-understood operation, object or member MUST r= esult in an error condition being reported and the patch rejected.=C2=A0

    - James

    On Tue, Sep 18, 2012 at 10:42 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
    =20 =20
    On Tue, 2012-09-18 at 10:27 -0700, Mark Nottingham wrote:

    James is right that the document is currently silent about extra proper= ties on the operation. Do people have strong feelings about whether this sh= ould result in an error condition, or be ignored?

    It was definitely intended to be an error condition. On this point, the spe= cification reads:

    =C2=A0=C2=A0=C2=A0 "It is an error condition if an operation object co= ntains no recognized operation member or more than one operation member.&qu= ot;

    I suppose it would be stronger to say something like:

    =C2=A0=C2=A0=C2=A0 "It is an error condition if an operation object do= es not contain an operation member documented herein, or more than one oper= ation member."

    Paul

    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss


    --f46d0442886014272004c9fd8358-- From jhildebr@cisco.com Tue Sep 18 10:51:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F5321F85EF for ; Tue, 18 Sep 2012 10:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvZBQG03iGMO for ; Tue, 18 Sep 2012 10:51:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6D021F85E6 for ; Tue, 18 Sep 2012 10:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1899; q=dns/txt; s=iport; t=1347990659; x=1349200259; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=azmSSSt+8Y/lxQXSVgNB3+neBzlm+5RSGp3mgBnYX/I=; b=R46he6b7ZLyv+3uO7woHWqmOcnevkxxReTdEX0duIYLaTIzry4fmYfWc pty2V6pgUeb0eziFGXjjhuF7IkKKJopC+bW7zuckeUbing1W+/NDcrgip 5z0olMGK459hm3/boKvF6w4MaNj08vB3gvKTSY3pS+6yYwPp0crNfNzi6 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPOzWFCtJV2a/2dsb2JhbABFvEKBCIInEgEnPxIBCDYxESUCBA4FIodPAwyaIpZXDYlTijmHUgOSMoFcgVWLF4MhgWmCZoIX X-IronPort-AV: E=Sophos;i="4.80,444,1344211200"; d="scan'208";a="122865025" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 18 Sep 2012 17:50:59 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8IHoxLW001423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 17:50:59 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Tue, 18 Sep 2012 12:50:58 -0500 From: "Joe Hildebrand (jhildebr)" To: Phillip Hallam-Baker Thread-Topic: [apps-discuss] Guidance on RFC 4627 as reference Thread-Index: AQHNlY3s9Yj5xKrn7EGS9IZMvZhKt5eQTCqAgAAivACAADBTAP//jIQAgAB3pYCAAALFAIAAA32AgAADlAD//4u0gIAAeNYA//+N6QA= Date: Tue, 18 Sep 2012 17:50:57 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.132.51] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19190.004 x-tm-as-result: No--33.164500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <252F10F91947B243BBD847AADFFCA609@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 17:51:01 -0000 On 9/18/12 10:39 AM, "Phillip Hallam-Baker" wrote: >?? what I am saying is that someone who feels the need to write > >{ "A": 1, "A": 2, "B": 3 } > >Should instead write > >{ "A" : [1, 2], "B": 3 } > =20 >Since every use case for a repeated tag can be met by a tag with a list >of items, there is no need for the repeated tag. +1. >Thus it is reasonable to change the SHOULD to a MUST in a BIS to be used >as a normative reference in protocol specs. James Snell gave a good chapter/verse on this in his last message. From a JSON-only point of view, I understand the SHOULD now (although I like SHOULD's to explain the cases when you wouldn't), but for many *protocol* uses of JSON, we should specify what a receiver should do with repeated keys. By default, the answer is likely "undefined/choose-one". >So the changes to section 2.2 are: > > >1) State that the order of the taged entries does not matter (no, putting >that in the introduction does not count). Doesn't hurt anything. >2) Change the SHOULD only occur once to MUST NOT occur more than once. That's the easiest change; we could discuss whether the slight difference to the nuance provided by James is important. >That still leaves open what an implementation may do when it encounters >an unexpected, unknown or illegal tag. Which is the sort of thing that >the security section should address. +1 >At any rate, I think this means that the idea of trying to use JSON >syntax to describe JSON schemas is not going to work. I for one can't >imagine wanting to use a schema notation where blocks are sometimes >denoted using {} and sometimes by [] and the difference is essential to >the semantics. I do not agree with your conclusion in any way. draft-zyp-json-schema has it's nits, but seems like a reasonable starting point. --=20 Joe Hildebrand From paul.hoffman@vpnc.org Tue Sep 18 11:18:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCD521E80EC for ; Tue, 18 Sep 2012 11:18:58 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MLCD0r-ufin for ; Tue, 18 Sep 2012 11:18:57 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8F37721E803A for ; Tue, 18 Sep 2012 11:18:55 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q8IIIqZ6003688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Sep 2012 11:18:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Paul Hoffman In-Reply-To: Date: Tue, 18 Sep 2012 11:18:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> To: John C Klensin X-Mailer: Apple Mail (2.1486) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 18:18:58 -0000 On Sep 18, 2012, at 9:13 AM, John C Klensin wrote: > To say on this list, as requested, what has been said in other > places, the Security Considerations section of 4627 is, to be > much more polite than it deserves, not up to the standard for > IETF Standards Track documents. =20 I would be interested to hear where those "other places" are. The = security considerations seem fine to me, but you obviously have thought = of additions you want (or at least you think others have). Listing them = here would be useful for the discussion. --Paul Hoffman From hallam@gmail.com Tue Sep 18 11:50:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217FA21E80FF for ; Tue, 18 Sep 2012 11:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.042 X-Spam-Level: X-Spam-Status: No, score=-4.042 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8aF9t8oPr2h for ; Tue, 18 Sep 2012 11:50:42 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7D7421E8034 for ; Tue, 18 Sep 2012 11:50:40 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so225335obb.31 for ; Tue, 18 Sep 2012 11:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0aFuHB3wlU0XYtFjVSgtMUMIEaFU18qzGgRjTQjpqGg=; b=Z73gQ/wkQ/XzKBYiTXiSFgK/iKa6+4/oyvk+en4ZcenTJPVoLPXPT3BWsM55T5Z/TW vi5erCoTol/yiDNqVzd0R8L5qLlUkkJlJlJZ3sFlHpiLa9qFvl/OfkE+LkCrqZYTCVCC EYNfNAbPW06rUMoh5wXRgp1LS8CgieIY0KKNslL3lYz4zvFwKraNmhO64YTknz1HuKQo MbcmUSXVgY3PKrlUmuaJKydB6l1zi2dxEKzVUq1RwVlBJEtXf5GuiVPdnHIjxbKM7MTi EfSAlBZoeMYhYUis0/w5A3FLcdfkW8Jl/fAx1p1qIMKFHJnM66SBdk88WtZAYNdzTFZQ h8eQ== MIME-Version: 1.0 Received: by 10.60.25.129 with SMTP id c1mr1174734oeg.36.1347994240050; Tue, 18 Sep 2012 11:50:40 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Tue, 18 Sep 2012 11:50:40 -0700 (PDT) In-Reply-To: References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> Date: Tue, 18 Sep 2012 14:50:40 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=e89a8ff1c6ced6657d04c9fe5d98 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 18:50:43 -0000 --e89a8ff1c6ced6657d04c9fe5d98 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 18, 2012 at 2:18 PM, Paul Hoffman wrote: > On Sep 18, 2012, at 9:13 AM, John C Klensin wrote: > > > To say on this list, as requested, what has been said in other > > places, the Security Considerations section of 4627 is, to be > > much more polite than it deserves, not up to the standard for > > IETF Standards Track documents. > > I would be interested to hear where those "other places" are. The security > considerations seem fine to me, but you obviously have thought of additions > you want (or at least you think others have). Listing them here would be > useful for the discussion. > I would like to see John's list as well. My treatment would be something along the following: 1) Code injection attacks [This is what the rather opaque language in the existing text seems to be attempting to address] 2) Data overflow attacks [Parsers need to consider cases such as buffer overrun, integer overflow, etc] 3) Message size limitations [Separate from the question of buffer overrun there is the issue of sending messages that are so long that they cause resource exhaustion and a DoS attack] 4) Error handling [What should a parser do if it encounters malformed JSON, 5) Resynchronization [How does a receiver that has received one malformed JSON message identify the start of the next item] 6) Integrity [JSON does not provide for integrity checking and this needs to be considered in the framing protocol] -- Website: http://hallambaker.com/ --e89a8ff1c6ced6657d04c9fe5d98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Tue, Sep 18, 2012 at 2:18 PM, Paul Ho= ffman <paul.hoffman@vpnc.org> wrote:
    On Sep 18, 2012, at 9:13 AM, John C Klensin <john-ietf@jck.com> wrote:

    > To say on this list, as requested, what has been said in other
    > places, the Security Considerations section of 4627 is, to be
    > much more polite than it deserves, not up to the standard for
    > IETF Standards Track documents.

    I would be interested to hear where those "other places" ar= e. The security considerations seem fine to me, but you obviously have thou= ght of additions you want (or at least you think others have). Listing them= here would be useful for the discussion.


    I would like to see John= 9;s list as well. My treatment would be something along the following:

    1) Code injection attacks

    [This is what the rather opaque language in the existing text seems to be a= ttempting to address]

    2) Data overflow attacks

    [Parsers need to consider cases such as buffer overru= n, integer overflow, etc]

    3) Message size limitations

    [S= eparate from the question of buffer overrun there is the issue of sending m= essages that are so long that they cause=A0resource=A0exhaustion and a DoS = attack]

    4) Error handling

    [What should= a parser do if it encounters malformed JSON,=A0

    5= ) Resynchronization

    [How does a receiver that has = received one malformed JSON message identify the start of the next item]

    6) Integrity

    [JSON does not pr= ovide for integrity checking and this needs to be considered in the framing= protocol]

    =A0
    --
    Website: http://hallambaker.com/

    --e89a8ff1c6ced6657d04c9fe5d98-- From jasnell@gmail.com Tue Sep 18 12:31:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFF511E809A for ; Tue, 18 Sep 2012 12:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERg5lhOMAyf7 for ; Tue, 18 Sep 2012 12:31:06 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E99B11E808E for ; Tue, 18 Sep 2012 12:31:05 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so112001wgb.13 for ; Tue, 18 Sep 2012 12:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6TeseYZZNRyxT8PU5KBm8G2ZIxT0ed2maSMf4ZgRTfQ=; b=rBXB8jpv5UbE2LvXaBFVqUsMuCF2RxHcYnJIMbwHsjHod37M6Y0NSNv9OE0WxlUKyK 7l8AnRLNSAXxxhOVB9FwgI13Vom4wNsjai14hoKKfduSgli425iDjVkfRJQwWnfF5Aak BqjpWJIHQe+L0fiOGM62Z+w1fHqBBJ2FyGCz0ySYSy8vTrbgspBxxVXUNuaZcA+4povh 2TOZm3VUHN9mbmJ/S7Z5XjvCyeKLMpNbJcVTpPHn1yjrDS4Q+Iw1ibFzVezUgLShBF9S KgFuObHA4yBJ5lDqps+I1aeGYQViumuxhV0Dl9O2mCdz4Kg1lEsiezwI444Pe2NL8/wm 2ROA== Received: by 10.217.1.79 with SMTP id m57mr379198wes.121.1347996663087; Tue, 18 Sep 2012 12:31:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.96.2 with HTTP; Tue, 18 Sep 2012 12:30:42 -0700 (PDT) In-Reply-To: References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> From: James M Snell Date: Tue, 18 Sep 2012 12:30:42 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=20cf302077dc43027404c9feee17 Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 19:31:07 -0000 --20cf302077dc43027404c9feee17 Content-Type: text/plain; charset=UTF-8 I can readily agree that the security considerations a quite lacking and you're right that there are areas where the language could be tightened up editorially (though I am -1 on making normative syntax and 2119 changes). Overall, I would be +1 on a rfc4627bis effort and could volunteer my time as an editor for such an effort. - James On Tue, Sep 18, 2012 at 11:50 AM, Phillip Hallam-Baker wrote: > > > On Tue, Sep 18, 2012 at 2:18 PM, Paul Hoffman wrote: > >> On Sep 18, 2012, at 9:13 AM, John C Klensin wrote: >> >> > To say on this list, as requested, what has been said in other >> > places, the Security Considerations section of 4627 is, to be >> > much more polite than it deserves, not up to the standard for >> > IETF Standards Track documents. >> >> I would be interested to hear where those "other places" are. The >> security considerations seem fine to me, but you obviously have thought of >> additions you want (or at least you think others have). Listing them here >> would be useful for the discussion. >> > > > I would like to see John's list as well. My treatment would be something > along the following: > > 1) Code injection attacks > > [This is what the rather opaque language in the existing text seems to be > attempting to address] > > 2) Data overflow attacks > > [Parsers need to consider cases such as buffer overrun, integer overflow, > etc] > > 3) Message size limitations > > [Separate from the question of buffer overrun there is the issue of > sending messages that are so long that they cause resource exhaustion and a > DoS attack] > > 4) Error handling > > [What should a parser do if it encounters malformed JSON, > > 5) Resynchronization > > [How does a receiver that has received one malformed JSON message identify > the start of the next item] > > 6) Integrity > > [JSON does not provide for integrity checking and this needs to be > considered in the framing protocol] > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --20cf302077dc43027404c9feee17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I can readily agree that the security = considerations a quite lacking and you're right that there are areas wh= ere the language could be tightened up editorially (though I am -1 on makin= g normative syntax and 2119 changes). Overall, I would be +1 on a rfc4627bi= s effort and could volunteer my time as an editor for such an effort.

    - James

    On Tu= e, Sep 18, 2012 at 11:50 AM, Phillip Hallam-Baker <hallam@gmail.com>= wrote:


    On Tue, Sep 18, 2012 at 2:18 PM, Paul Hoffman &l= t;paul.hoffman@v= pnc.org> wrote:
    On Sep 18, 2012, at 9:13 AM, John C Klensin <john-ietf@jck.com> wrote:

    > To say on this list, as requested, what has been said in other
    > places, the Security Considerations section of 4627 is, to be
    > much more polite than it deserves, not up to the standard for
    > IETF Standards Track documents.

    I would be interested to hear where those "other places" ar= e. The security considerations seem fine to me, but you obviously have thou= ght of additions you want (or at least you think others have). Listing them= here would be useful for the discussion.


    I would like to see J= ohn's list as well. My treatment would be something along the following= :

    1) Code injection attacks

    [This is what the rather opaque language in the existing text seems to be a= ttempting to address]

    2) Data overflow attacks

    [Parsers need to consider cases such as buffer overru= n, integer overflow, etc]

    3) Message size limitations

    [S= eparate from the question of buffer overrun there is the issue of sending m= essages that are so long that they cause=C2=A0resource=C2=A0exhaustion and = a DoS attack]

    4) Error handling

    [What should= a parser do if it encounters malformed JSON,=C2=A0

    5) Resynchronization

    [How does a receiver that h= as received one malformed JSON message identify the start of the next item]=

    6) Integrity

    [JSON does not pr= ovide for integrity checking and this needs to be considered in the framing= protocol]

    =C2=A0
    --
    Website: http://hallambaker.com/


    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss


    --20cf302077dc43027404c9feee17-- From paul.hoffman@vpnc.org Tue Sep 18 13:22:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7340921E8050 for ; Tue, 18 Sep 2012 13:22:10 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4j9aEl4hEwu for ; Tue, 18 Sep 2012 13:22:10 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DE15A21E8040 for ; Tue, 18 Sep 2012 13:22:09 -0700 (PDT) Received: from [165.227.249.211] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q8IKM7xq008152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 18 Sep 2012 13:22:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Paul Hoffman In-Reply-To: Date: Tue, 18 Sep 2012 13:22:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> To: "apps-discuss@ietf.org Discuss" X-Mailer: Apple Mail (2.1486) Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 20:22:10 -0000 On Sep 18, 2012, at 11:50 AM, Phillip Hallam-Baker = wrote: > I would like to see John's list as well. My treatment would be = something along the following: >=20 > 1) Code injection attacks >=20 > [This is what the rather opaque language in the existing text seems to = be attempting to address] >=20 > 2) Data overflow attacks >=20 > [Parsers need to consider cases such as buffer overrun, integer = overflow, etc] >=20 > 3) Message size limitations >=20 > [Separate from the question of buffer overrun there is the issue of = sending messages that are so long that they cause resource exhaustion = and a DoS attack] Are any of these specific to JSON? They apply to any format, yes? I'm = fine with adding them, but in doing so, we aren't talking about JSON. > 4) Error handling >=20 > [What should a parser do if it encounters malformed JSON,=20 That's not a security consideration, that's a protocol implementation = issue. I don't think we should specify it, give the wildly different = environments where JSON parsing happens. > 5) Resynchronization >=20 > [How does a receiver that has received one malformed JSON message = identify the start of the next item] Same as 4. > 6) Integrity >=20 > [JSON does not provide for integrity checking and this needs to be = considered in the framing protocol] Sure, I guess that is a "security consideration" for any format. --Paul Hoffman= From mnot@mnot.net Tue Sep 18 16:56:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4984921F8551 for ; Tue, 18 Sep 2012 16:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVwAUCdKntoc for ; Tue, 18 Sep 2012 16:56:03 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5409F21F854A for ; Tue, 18 Sep 2012 16:56:03 -0700 (PDT) Received: from [172.30.66.198] (unknown [72.247.151.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 68FCC22E256; Tue, 18 Sep 2012 19:55:56 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: Date: Tue, 18 Sep 2012 16:55:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> To: James M Snell X-Mailer: Apple Mail (2.1486) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 23:56:04 -0000 Going with: > It is an error condition if an operation object does not contain an > operation member, contains an operation member other than one of > those defined by this document, or more than one operation member. >=20 > Likewise, it is an error condition if an operation object has a > member that is not explicitly allowed by this document. On 18/09/2012, at 10:49 AM, James M Snell wrote: > +1 on having it be an error condition.=20 >=20 > Because of the potentially significant negative impact that an = improperly applied patch operation could have on the target resource, = any not-understood operation, object or member MUST result in an error = condition being reported and the patch rejected.=20 >=20 > - James >=20 > On Tue, Sep 18, 2012 at 10:42 AM, Paul C. Bryan = wrote: > On Tue, 2012-09-18 at 10:27 -0700, Mark Nottingham wrote: >=20 >> James is right that the document is currently silent about extra = properties on the operation. Do people have strong feelings about = whether this should result in an error condition, or be ignored? >=20 > It was definitely intended to be an error condition. On this point, = the specification reads: >=20 > "It is an error condition if an operation object contains no = recognized operation member or more than one operation member." >=20 > I suppose it would be stronger to say something like: >=20 > "It is an error condition if an operation object does not contain = an operation member documented herein, or more than one operation = member." >=20 > Paul >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Sep 18 16:57:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCE221F8551 for ; Tue, 18 Sep 2012 16:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.199 X-Spam-Level: X-Spam-Status: No, score=-104.199 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNo6DCPN9K7g for ; Tue, 18 Sep 2012 16:57:02 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8E80821F854A for ; Tue, 18 Sep 2012 16:57:02 -0700 (PDT) Received: from [172.30.66.198] (unknown [72.247.151.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A950122E25B; Tue, 18 Sep 2012 19:56:55 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: <1347936793.2920.1.camel@polyglot> Date: Tue, 18 Sep 2012 16:56:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9BF45E77-6488-4EB6-A9AC-32D0C4EECE80@mnot.net> References: <20120917062225.31160.89210.idtracker@ietfa.amsl.com> <1347920475.19756.39.camel@pbryan-wsl.internal.salesforce.com> <1347922222.19756.67.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114FD10E3C3@WSMSG3153V.srv.dir.telstra.com> <1347936793.2920.1.camel@polyglot> To: Paul C. Bryan X-Mailer: Apple Mail (2.1486) Cc: Apps Discuss Subject: Re: [apps-discuss] New Version Notification for draft-ietf-appsawg-json-patch-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 23:57:03 -0000 So, do we need any spec changes / clarifications here? More examples? = Nothing? On 17/09/2012, at 7:53 PM, Paul C. Bryan wrote: > You're right, thanks! So, "/" would be a valid move-to location. "" = would yield an error condition. >=20 > Paul >=20 > On Tue, 2012-09-18 at 12:33 +1000, Manger, James H wrote: >> "/" is not the root. It is an item in the root object with an empty = string as its name. >>=20 >> Hence, Martin=92s example =93old=94 and =93patch=94 values are valid, = but they don=92t produce his =93new=94 value, nor Paul=92s error. They = produce { "a": {}, "":"foo" }. >>=20 >> =20 >>=20 >> old: >>=20 >> { "a": { "b": "foo" } } >>=20 >> patch: >>=20 >> { "move": "/a/b", "to": "/" } >>=20 >> new: >>=20 >> { "a": {}, "":"foo" } >>=20 >> =20 >>=20 >> =20 >>=20 >> P.S. The empty string "" is the JSON-Pointer to the root, which will = often be an object, or an array, but could also be a string, or number = etc. I guess {"remove":""} is valid. It leaves an empty document (eg a = resource with 0 bytes), though that isn=92t a valid JSON value. >>=20 >> =20 >>=20 >> -- >>=20 >> James Manger >>=20 >>=20 >> =20 >>=20 >> From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul C. Bryan >> Sent: Tuesday, 18 September 2012 8:50 AM >> To: Martin Thomson >> Cc: Apps Discuss; Mark Nottingham >> Subject: Re: [apps-discuss] Fwd: New Version Notification for = draft-ietf-appsawg-json-patch-04.txt >>=20 >>=20 >> =20 >>=20 >> Okay, I take it back; I was referring to an object, which root cannot = be inferred to be. So we have a hole where the root value of the = document is neither an array nor an object; it's merely a value. Perhaps = language stating that the root is an invalid "to" target, because it = always exists. >>=20 >> Paul=20 >>=20 >> On Mon, 2012-09-17 at 15:21 -0700, Paul C. Bryan wrote: >>=20 >>=20 >>=20 >> On Mon, 2012-09-17 at 15:15 -0700, Martin Thomson wrote:=20 >>=20 >> =20 >> Reading the description of "move", I can infer that the intent is to >> specify the name of the node such that, olddoc#{move} =3D=3D = newdoc#{to} >> =20 >> This is unlike other "move" or "mv" commands where you are able to >> identify a container as the target of a move. >> =20 >> old: >> { "a": { "b": "foo" } } >> patch: >> { "move": "/a/b", "to": "/" } >> new: >> { "a": {}, "b":"foo" } >>=20 >>=20 >>=20 >> This attempt at the "move" operation above will fail because there is = already a value at "/", namely an object containing a sole "a" member. >>=20 >>=20 >>=20 >>=20 >> =20 >> I assume that it is entirely intentional that this is not supported, >> but it would be nice to clarify that this is not a feature that is >> provided. >>=20 >>=20 >>=20 >> Not only is it entirely intentional that it's not supported, it's = actually documented as such. To wit in =A74.4: >>=20 >> "If the location in the 'to' member references a member of an = existing object in the target document, it is an error condition if a = value at the specified location already exists..." Hence, it will fail = as indicated above. >>=20 >> Paul >>=20 >>=20 >>=20 >>=20 >> =20 >> =20 >> --Martin >> =20 >> On 16 September 2012 23:24, Mark Nottingham < >> mnot@mnot.net >> > wrote: >> > This draft incorporated some minor feedback from James and made a = few error conditions explicit. >> >=20 >> > With it -- assuming that the decision to keep "test" in as-is -- I = *think* we're ready for WGLC for both json-pointer and json-patch. >> >=20 >> > Cheers, >> >=20 >> >=20 >> > Begin forwarded message: >> >=20 >> >> From:=20 >> internet-drafts@ietf.org >>=20 >> >> Subject: New Version Notification for = draft-ietf-appsawg-json-patch-04.txt >> >> Date: 17 September 2012 6:22:25 PM NZST >> >> To:=20 >> mnot@mnot.net >>=20 >> >> Cc:=20 >> pbryan@anode.ca >>=20 >> >>=20 >> >>=20 >> >> A new version of I-D, draft-ietf-appsawg-json-patch-04.txt >> >> has been successfully submitted by Mark Nottingham and posted to = the >> >> IETF repository. >> >>=20 >> >> Filename: draft-ietf-appsawg-json-patch >> >> Revision: 04 >> >> Title: JSON Patch >> >> Creation date: 2012-09-17 >> >> WG ID: appsawg >> >> Number of pages: 15 >> >> URL: =20 >> = http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-04.txt >>=20 >> >> Status: =20 >> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch >>=20 >> >> Htmlized: =20 >> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04 >>=20 >> >> Diff: =20 >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-patch-04 >>=20 >> >>=20 >> >> Abstract: >> >> JSON Patch defines the media type "application/json-patch", a = JSON >> >> document structure for expressing a sequence of operations to = apply >> >> to a JSON document. >> >>=20 >> >>=20 >> >>=20 >> >>=20 >> >> The IETF Secretariat >> >>=20 >> >=20 >> > -- >> > Mark Nottingham >> >=20 >> http://www.mnot.net/ >>=20 >> >=20 >> >=20 >> >=20 >> >=20 >> > _______________________________________________ >> > apps-discuss mailing list >> >=20 >> apps-discuss@ietf.org >>=20 >> >=20 >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> _______________________________________________ >> apps-discuss mailing list >>=20 >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> =20 >>=20 >> =20 >> _______________________________________________ >> apps-discuss mailing list >>=20 >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> =20 >>=20 >>=20 >=20 -- Mark Nottingham http://www.mnot.net/ From duerst@it.aoyama.ac.jp Tue Sep 18 19:51:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D0221E8084 for ; Tue, 18 Sep 2012 19:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.092 X-Spam-Level: X-Spam-Status: No, score=-103.092 tagged_above=-999 required=5 tests=[AWL=-3.302, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yN6tDthrOxW0 for ; Tue, 18 Sep 2012 19:51:27 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id EC00011E80D2 for ; Tue, 18 Sep 2012 19:51:26 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q8J2pGCo007625 for ; Wed, 19 Sep 2012 11:51:16 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 5f47_5df8_e1e29afc_0204_11e2_9160_001d096c566a; Wed, 19 Sep 2012 11:51:16 +0900 Received: from [IPv6:::1] ([133.2.210.1]:33757) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 19 Sep 2012 11:51:16 +0900 Message-ID: <50593322.2050106@it.aoyama.ac.jp> Date: Wed, 19 Sep 2012 11:51:14 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 02:51:30 -0000 On 2012/09/19 1:47, Phillip Hallam-Baker wrote: > How can you use tools 'correctly' without having a definition of what > 'correct' is? > > I can't see a place in the JSON specification where it says that the > following are equivalent: > > [ {"name": "foo", "value": "one"}, {"name": "bar", "value": "two"}] > [ {"name": "foo", "value": "two"}, {"name": "bar", "value": "one"}] Maybe that was obvious to most, but these two are of course not equivalent, the first one has a value of "one" for a name of "foo", the second one has a value of "two". To fix the example, a better question would have been whether the following two are equivalent: [ {"name": "foo", "value": "one"}, {"name": "bar", "value": "two"}] [ {"name": "bar", "value": "two"}, {"name": "foo", "value": "one"}] Now we have two arrays, both with the same two element, and only the order is different. The answer to whether they are equivalent or not has already been given: They are not, because order is significant in arrays. Whether it's the intro or some later section (or both) that say that arrays are ordered and objects/hashes are unordered is definitely a question of spec quality, but claiming that there's no definition is overblown. Regards, Martin. From duerst@it.aoyama.ac.jp Tue Sep 18 19:59:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D57811E80DC for ; Tue, 18 Sep 2012 19:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=-2.642, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pD7CCk1nX91R for ; Tue, 18 Sep 2012 19:59:45 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8B37111E80D2 for ; Tue, 18 Sep 2012 19:59:45 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q8J2xXJB013200 for ; Wed, 19 Sep 2012 11:59:35 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 5f47_5fa6_0a1fd1b4_0206_11e2_9160_001d096c566a; Wed, 19 Sep 2012 11:59:33 +0900 Received: from [IPv6:::1] ([133.2.210.1]:53560) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 19 Sep 2012 11:59:32 +0900 Message-ID: <50593513.4030303@it.aoyama.ac.jp> Date: Wed, 19 Sep 2012 11:59:31 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 02:59:46 -0000 On 2012/09/19 2:50, Joe Hildebrand (jhildebr) wrote: > On 9/18/12 10:39 AM, "Phillip Hallam-Baker" wrote: >> Thus it is reasonable to change the SHOULD to a MUST in a BIS to be used >> as a normative reference in protocol specs. > > James Snell gave a good chapter/verse on this in his last message. From a > JSON-only point of view, I understand the SHOULD now (although I like > SHOULD's to explain the cases when you wouldn't), but for many *protocol* > uses of JSON, we should specify what a receiver should do with repeated > keys. By default, the answer is likely "undefined/choose-one". This answer should not be defined by protocol. It would mean that it's no longer possible to use generic JSON parsers. >> So the changes to section 2.2 are: >> >> >> 1) State that the order of the taged entries does not matter (no, putting >> that in the introduction does not count). > > Doesn't hurt anything. > >> 2) Change the SHOULD only occur once to MUST NOT occur more than once. > > That's the easiest change; we could discuss whether the slight difference > to the nuance provided by James is important. I'd definitely suggest a very strong MUST NOT send. We may need some checks on existing implementations to decide whether it's better to define this as an error on the receiver side (but the current SHOULD seems to indicate it's not), or to leave it undefined. Regards, Martin. From hallam@gmail.com Tue Sep 18 20:52:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4991721E8084 for ; Tue, 18 Sep 2012 20:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88bYwPHeiqbU for ; Tue, 18 Sep 2012 20:52:19 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7917211E80E7 for ; Tue, 18 Sep 2012 20:52:19 -0700 (PDT) Received: by oagn5 with SMTP id n5so5566oag.31 for ; Tue, 18 Sep 2012 20:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JFEPKTiXUpcRvBgE1rB92vA8U0OEXsCV+9+ZomwCUHw=; b=cN0w3ulPmeIfWR2+Qmp05b8PuTRdqYyWOcNk5l80toMIPxakuEwI+K/YRXhe77GOMA qoxR9KxFiIoRcUzFwdsJSEH0P7vNIDXAp8SAEz2O+Tj+7a4m47EjuJbP5CF2MloI1OIP JBI/szA6PI95Q0ggPpvX6ygfeYhhprK/ZMRqZJm1WYZzo7D6KyI64NbI3Luj//E1MY31 G43UAcpwS0J75pB0vWarBEKDhCs0r90JDlAJcDzPSIrOObt2QRuP2mkxo5MfPEeOdCEF 1wM2e3hMS9JSMANyoAROsvZLPHi0hNxOOzUYNvBhRLomTXuEN+NG7uED7+zK/TKj68Ig U1Ag== MIME-Version: 1.0 Received: by 10.60.172.236 with SMTP id bf12mr2102078oec.23.1348026738961; Tue, 18 Sep 2012 20:52:18 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Tue, 18 Sep 2012 20:52:18 -0700 (PDT) In-Reply-To: <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> Date: Tue, 18 Sep 2012 23:52:18 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=bcaec54d4768ec6d1e04ca05ee14 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 03:52:20 -0000 --bcaec54d4768ec6d1e04ca05ee14 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 18, 2012 at 4:22 PM, Paul Hoffman wrote: > On Sep 18, 2012, at 11:50 AM, Phillip Hallam-Baker > wrote: > > > I would like to see John's list as well. My treatment would be something > along the following: > > > > 1) Code injection attacks > > > > [This is what the rather opaque language in the existing text seems to > be attempting to address] > > > > 2) Data overflow attacks > > > > [Parsers need to consider cases such as buffer overrun, integer > overflow, etc] > > > > 3) Message size limitations > > > > [Separate from the question of buffer overrun there is the issue of > sending messages that are so long that they cause resource exhaustion and a > DoS attack] > > Are any of these specific to JSON? They apply to any format, yes? I'm fine > with adding them, but in doing so, we aren't talking about JSON. If the syntax is sufficiently general, the statements in the SC section should be applicable to anything else. But that does not mean that they can or should be omitted. If someone is writing a parser/emitter module, they need to think about how the developer using the module can address those concerns and whether that code belongs inside or outside their module. > > 4) Error handling > > > > [What should a parser do if it encounters malformed JSON, > > That's not a security consideration, that's a protocol implementation > issue. I don't think we should specify it, give the wildly different > environments where JSON parsing happens Security considerations are just that, considerations. The SC set should tell the implementer what issues they need to be thinking about when they write code. -- Website: http://hallambaker.com/ --bcaec54d4768ec6d1e04ca05ee14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Tue, Sep 18, 2012 at 4:22 PM, Paul Ho= ffman <paul.hoffman@vpnc.org> wrote:
    On Sep 18, 2012, at 11:50 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:

    > I would like to see John's list as well. My treatment would be som= ething along the following:
    >
    > 1) Code injection attacks
    >
    > [This is what the rather opaque language in the existing text seems to= be attempting to address]
    >
    > 2) Data overflow attacks
    >
    > [Parsers need to consider cases such as buffer overrun, integer overfl= ow, etc]
    >
    > 3) Message size limitations
    >
    > [Separate from the question of buffer overrun there is the issue of se= nding messages that are so long that they cause resource exhaustion and a D= oS attack]

    Are any of these specific to JSON? They apply to any format, yes? I&#= 39;m fine with adding them, but in doing so, we aren't talking about JS= ON.

    If the syntax is sufficiently general, = the statements in the SC section should be applicable to anything else. But= that does not mean that they can or should be omitted.=A0

    If someone is writing a parser/emitter module, they nee= d to think about how the developer using the module can address those conce= rns and whether that code belongs inside or outside their module.

    =A0
    > 4) Error handling
    >
    > [What should a parser do if it encounters malformed JSON,

    That's not a security consideration, that's a protocol implem= entation issue. I don't think we should specify it, give the wildly dif= ferent environments where JSON parsing happens

    Security considerations are just that, considerations.=A0
    The SC set should tell the implementer what issues they need t= o be thinking about when they write code.

    =A0

    --
    Website: ht= tp://hallambaker.com/

    --bcaec54d4768ec6d1e04ca05ee14-- From James.H.Manger@team.telstra.com Wed Sep 19 07:52:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A51421F8682 for ; Wed, 19 Sep 2012 07:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzYmzk1oZgvO for ; Wed, 19 Sep 2012 07:52:50 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id D31C121F8681 for ; Wed, 19 Sep 2012 07:52:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,448,1344175200"; d="scan'208";a="93521553" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 20 Sep 2012 00:52:47 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6839"; a="88864054" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcbvi.tcif.telstra.com.au with ESMTP; 20 Sep 2012 00:52:47 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Thu, 20 Sep 2012 00:52:46 +1000 From: "Manger, James H" To: Mark Nottingham , James M Snell Date: Thu, 20 Sep 2012 00:52:38 +1000 Thread-Topic: [apps-discuss] JSON Patch: extensibility Thread-Index: Ac2V+S2zlSGcGI23S76Y+aQA9LyIDgAeFHmQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> In-Reply-To: <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 14:52:51 -0000 VGhlIGNvbnNlbnN1cyBzb3VuZHMgbGlrZSAiTVVTVCB1bmRlcnN0YW5kIGV2ZXJ5dGhpbmciOyBu byBpZ25vcmluZyB1bnJlY29nbml6ZWQgZmllbGRzLiBUaGF0IGlzIG9rLCBidXQgd2UgaGF2ZW4n dCBwaWNrZWQgYSBnb29kIHN5bnRheCB0byBtYXRjaCB0aGF0IHJ1bGUuDQoNClRoZSAib2J2aW91 cyIgd2F5IHRvIHBhcnNlIGEgcGF0Y2ggb3BlcmF0aW9uIG9iamVjdCAoZWcgeyJhZGQiOiIvZm9v IiwidmFsdWUiOiJiYXIifSkgaXMgdG86DQoNCjEuIExvb3AgdGhyb3VnaCB0aGUga2V5cyBpbiB0 aGUgb2JqZWN0IHVudGlsIHlvdSBmaW5kIG9uZSB0aGF0IGlzIGluIHRoZSBzZXQgb2Yga25vd24g b3BlcmF0aW9uczogImFkZCIsICJyZW1vdmUiLCAidGVzdCLigKYNCg0KMi4gRXh0cmFjdCB0aGUg ZWxlbWVudHMgYXNzb2NpYXRlZCB3aXRoIHRoYXQgc3BlY2lmaWMgb3BlcmF0aW9uLCBlZyB0aGUg InZhbHVlIiBmb3IgYW4gImFkZCIgb3BlcmF0aW9uLg0KDQpUaGF0ICJvYnZpb3VzIiBwcm9jZXNz IHdpbGwgbm90IGRldGVjdCB0d28gb3BlcmF0aW9ucyBpbiBhbiBvYmplY3QsIG9yIHVuZXhwZWN0 ZWQgZXh0cmEgZmllbGRzLiBJbXBsZW1lbnRhdGlvbnMgd2lsbCBoYXZlIHRvIGRvIG5vbi10cml2 aWFsIGV4dHJhIHdvcmsgdG8gbWFrZSB0aG9zZSBjaGVja3MuIE1hbnkgd2lsbCBub3QgZG8gdGhh dCwgb3Igd2lsbCBkbyBpdCBpbmNvcnJlY3RseSwgc2ltcGx5IGJlY2F1c2UgdmFsaWQgY2FzZXMg d2lsbCB3b3JrIHJlZ2FyZGxlc3Mgb2YgdGhhdCBleHRyYSBjb2RlLiBUaGUgcmVzdWx0IGlzIGxp a2VseSB0byBiZSBzZWN1cml0eSBwcm9ibGVtcy4gRm9yIGluc3RhbmNlLCBvbmUgaW1wbGVtZW50 YXRpb24gcGFyc2luZyB7InZhbHVlIjoiYmFyIiwgImFkZCI6Ii9mb28iLCAicmVtb3ZlIjoiL2Zv byJ9IHdpbGwgc2VlIGFuICJhZGQiIG9wZXJhdGlvbiwgYW5vdGhlciB3aWxsIHNlZSBhICJyZW1v dmUiIG9wZXJhdGlvbiAoYW5kIGEgdGhpcmQgd2lsbCByZXBvcnQgYW4gZXJyb3IpLCBzaW1wbHkg YmFzZWQgb24gaG93IGltcGxlbWVudGF0aW9uLXNwZWNpZmljIHN0cmluZyBoYXNoIGNvZGVzIGFy ZSBjYWxjdWxhdGVkLg0KDQpUaGUgbmljZSB0aGluZyBhYm91dCBhIEpTT04gb2JqZWN0IGlzIHRo YXQgeW91IGNhbiBhZGQgYWxsIHNvcnRzIG9mIGV4dHJhIGVsZW1lbnRzIHdpdGhvdXQgYWZmZWN0 aW5nIGV4aXN0aW5nIGVsZW1lbnRzLiBHaXZlbiB3ZSBleHBsaWNpdGx5IGRvbid0IHdhbnQgdGhp cyBmZWF0dXJlLCBwZXJoYXBzIGEgYmV0dGVyIHN5bnRheCB3b3VsZCBiZSBhIEpTT04gYXJyYXk6 IHN0YXJ0aW5nIHdpdGggdGhlIG9wZXJhdGlvbiBuYW1lLCB0aGVuIHRoZSBvcGVyYXRpb24tc3Bl Y2lmaWMgcGFyYW1ldGVycy4NCg0KRm9yIGV4YW1wbGU6DQppbnN0ZWFkIG9mICB7ImFkZCI6Ii9m b28iLCAidmFsdWUiOiJiYXIifQ0KaGF2ZSAgICAgICAgWyJhZGQiLCAiL2ZvbyIsICJiYXIiXQ0K DQpEdXBsaWNhdGUgb3BlcmF0aW9ucyBjYW5ub3Qgb2NjdXIgKHRoZXJlIGNhbiBvbmx5IGJlIG9u ZSBmaXJzdCBlbGVtZW50IGluIGFuIGFycmF5KS4gUHJldmVudGluZyB1bmV4cGVjdGVkIHBhcmFt ZXRlcnMgaXMgYXMgc2ltcGxlIGFzIGVuc3VyaW5nIHRoZSBhcnJheSBpcyB0aGUgcmlnaHQgbGVu Z3RoIGZvciB0aGUgc3BlY2lmaWMgb3BlcmF0aW9uLg0KDQpUaGUgYXJyYXkgYXBwcm9hY2ggc2hv dWxkIGFsc28gYmUgc2ltcGxlciB0byBtYXAgdG8gYSBwZXItb3BlcmF0aW9uIGZ1bmN0aW9uIGNh bGwgd2l0aCBhcmd1bWVudHMuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86YXBwcy1kaXNjdXNzLQ0KPiBib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFy ayBOb3R0aW5naGFtDQo+IFNlbnQ6IFdlZG5lc2RheSwgMTkgU2VwdGVtYmVyIDIwMTIgOTo1NiBB TQ0KPiBUbzogSmFtZXMgTSBTbmVsbA0KPiBDYzogYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBKU09OIFBhdGNoOiBleHRlbnNpYmlsaXR5DQo+IA0K PiBHb2luZyB3aXRoOg0KPiANCj4gPiAgICBJdCBpcyBhbiBlcnJvciBjb25kaXRpb24gaWYgYW4g b3BlcmF0aW9uIG9iamVjdCBkb2VzIG5vdCBjb250YWluIGFuDQo+ID4gICAgb3BlcmF0aW9uIG1l bWJlciwgY29udGFpbnMgYW4gb3BlcmF0aW9uIG1lbWJlciBvdGhlciB0aGFuIG9uZSBvZg0KPiA+ ICAgIHRob3NlIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCwgb3IgbW9yZSB0aGFuIG9uZSBvcGVy YXRpb24gbWVtYmVyLg0KPiA+DQo+ID4gICAgTGlrZXdpc2UsIGl0IGlzIGFuIGVycm9yIGNvbmRp dGlvbiBpZiBhbiBvcGVyYXRpb24gb2JqZWN0IGhhcyBhDQo+ID4gICAgbWVtYmVyIHRoYXQgaXMg bm90IGV4cGxpY2l0bHkgYWxsb3dlZCBieSB0aGlzIGRvY3VtZW50Lg0KPiANCj4gDQo+IE9uIDE4 LzA5LzIwMTIsIGF0IDEwOjQ5IEFNLCBKYW1lcyBNIFNuZWxsIDxqYXNuZWxsQGdtYWlsLmNvbT4g d3JvdGU6DQo+IA0KPiA+ICsxIG9uIGhhdmluZyBpdCBiZSBhbiBlcnJvciBjb25kaXRpb24uDQo+ ID4NCj4gPiBCZWNhdXNlIG9mIHRoZSBwb3RlbnRpYWxseSBzaWduaWZpY2FudCBuZWdhdGl2ZSBp bXBhY3QgdGhhdCBhbg0KPiBpbXByb3Blcmx5IGFwcGxpZWQgcGF0Y2ggb3BlcmF0aW9uIGNvdWxk IGhhdmUgb24gdGhlIHRhcmdldCByZXNvdXJjZSwNCj4gYW55IG5vdC11bmRlcnN0b29kIG9wZXJh dGlvbiwgb2JqZWN0IG9yIG1lbWJlciBNVVNUIHJlc3VsdCBpbiBhbiBlcnJvcg0KPiBjb25kaXRp b24gYmVpbmcgcmVwb3J0ZWQgYW5kIHRoZSBwYXRjaCByZWplY3RlZC4NCj4gPg0KPiA+IC0gSmFt ZXMNCj4gPg0KPiA+IE9uIFR1ZSwgU2VwIDE4LCAyMDEyIGF0IDEwOjQyIEFNLCBQYXVsIEMuIEJy eWFuIDxwYnJ5YW5AYW5vZGUuY2E+DQo+IHdyb3RlOg0KPiA+IE9uIFR1ZSwgMjAxMi0wOS0xOCBh dCAxMDoyNyAtMDcwMCwgTWFyayBOb3R0aW5naGFtIHdyb3RlOg0KPiA+DQo+ID4+IEphbWVzIGlz IHJpZ2h0IHRoYXQgdGhlIGRvY3VtZW50IGlzIGN1cnJlbnRseSBzaWxlbnQgYWJvdXQgZXh0cmEN Cj4gcHJvcGVydGllcyBvbiB0aGUgb3BlcmF0aW9uLiBEbyBwZW9wbGUgaGF2ZSBzdHJvbmcgZmVl bGluZ3MgYWJvdXQNCj4gd2hldGhlciB0aGlzIHNob3VsZCByZXN1bHQgaW4gYW4gZXJyb3IgY29u ZGl0aW9uLCBvciBiZSBpZ25vcmVkPw0KPiA+DQo+ID4gSXQgd2FzIGRlZmluaXRlbHkgaW50ZW5k ZWQgdG8gYmUgYW4gZXJyb3IgY29uZGl0aW9uLiBPbiB0aGlzIHBvaW50LA0KPiB0aGUgc3BlY2lm aWNhdGlvbiByZWFkczoNCj4gPg0KPiA+ICAgICAiSXQgaXMgYW4gZXJyb3IgY29uZGl0aW9uIGlm IGFuIG9wZXJhdGlvbiBvYmplY3QgY29udGFpbnMgbm8NCj4gcmVjb2duaXplZCBvcGVyYXRpb24g bWVtYmVyIG9yIG1vcmUgdGhhbiBvbmUgb3BlcmF0aW9uIG1lbWJlci4iDQo+ID4NCj4gPiBJIHN1 cHBvc2UgaXQgd291bGQgYmUgc3Ryb25nZXIgdG8gc2F5IHNvbWV0aGluZyBsaWtlOg0KPiA+DQo+ ID4gICAgICJJdCBpcyBhbiBlcnJvciBjb25kaXRpb24gaWYgYW4gb3BlcmF0aW9uIG9iamVjdCBk b2VzIG5vdCBjb250YWluDQo+IGFuIG9wZXJhdGlvbiBtZW1iZXIgZG9jdW1lbnRlZCBoZXJlaW4s IG9yIG1vcmUgdGhhbiBvbmUgb3BlcmF0aW9uDQo+IG1lbWJlci4iDQo+ID4NCj4gPiBQYXVsDQoN Cg== From jhildebr@cisco.com Tue Sep 18 09:39:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145E421F86FA for ; Tue, 18 Sep 2012 09:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXaKuuJbcwbs for ; Tue, 18 Sep 2012 09:39:41 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3008521F86F9 for ; Tue, 18 Sep 2012 09:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1618; q=dns/txt; s=iport; t=1347986381; x=1349195981; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Lt2761zIR1yckyp61sPFaT9wMeJDbyocD13qsy3pw6w=; b=H8ik1yKJfv7KE253x+BhYlCl0i4nRyuBNmSfA/NMM+MDWDq3sunIU4Iv HwIURlyJVBClvINPVydmboJqk5DDZWkJgq0oR76sup2gMJr8DsNvGINL1 qwZfGel8Twy81KItqMq+8yobySZKGOMJMR2PfjOGk2ec+340fbtC70RG9 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKqiWFCtJV2b/2dsb2JhbABFvD+BCIInEgEnPxIBCDYxESUCBAENBSKHTwMMmiqWXA2JU4o5h1IDkjKBXIFVixeDIYFpgmaCFw X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="119830728" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 18 Sep 2012 16:39:39 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8IGddJx003027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 16:39:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Tue, 18 Sep 2012 11:39:39 -0500 From: "Joe Hildebrand (jhildebr)" To: Phillip Hallam-Baker , Julian Reschke Thread-Topic: [apps-discuss] Guidance on RFC 4627 as reference Thread-Index: AQHNlY3s9Yj5xKrn7EGS9IZMvZhKt5eQTCqAgAAivACAADBTAP//jIQA Date: Tue, 18 Sep 2012 16:39:38 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.132.51] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19190.004 x-tm-as-result: No--39.857500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 19 Sep 2012 08:06:29 -0700 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:39:42 -0000 On 9/18/12 9:32 AM, "Phillip Hallam-Baker" wrote: >In my protocol I am sending a JSON structure that contains an ordered >list of potential choices for a connection to a service endpoint. In >other words the order darn well matters in that case and anyone who >simply throws the data into a hash tree is going > to end up with the wrong result. If it's possible, I'd suggest exploring other design patterns. Instead of the order mattering in: { "foo": "one", "bar": "two" } You could use: [ {"name": "foo", "value": "one"}, {"name": "bar", "value": "two"}] Or some other non-ambiguous approach. >If the draft is going to be revised and become a Proposed Standard, I >would like to see it mention these issue as choices that a protocol using >JSON syntax must address clearly. It seems reasonable to give guidelines to protocol implementors. Whether that belongs in this document or not is a separate question. If we can come to consensus on what those guidelines are quickly, it wouldn't hurt to include them -- but that seems unlikely. >Simply deciding to use JSON does not remove the obligation to be precise >when stating what is acceptable and what is not. If you are going to have >a specification that says order does not matter then you are going to >have to test for that when you do interop > testing. Contrawise if you decide that order does matter then you are >going to have to test for that. Or: use the tools correctly according to the guidelines that may exist one day, and you won't have this interop issue. --=20 Joe Hildebrand From jhildebr@cisco.com Tue Sep 18 10:22:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A4321E80D9 for ; Tue, 18 Sep 2012 10:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dODvHTmltIdc for ; Tue, 18 Sep 2012 10:22:49 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1379821E80CA for ; Tue, 18 Sep 2012 10:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=853; q=dns/txt; s=iport; t=1347988969; x=1349198569; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1BsCTskDC+RQ6zLOgB2p1TeLM6QKzrOhv1vDs0zbhuk=; b=cFXZxjz/bXe0qNp7BRULSBcuonC5FjQIzg65FRcYBQ9rh+2f7PUizaAq hrT/nRMx7XHVl7orzmj5oM3u2MvTEpEjsKFuQG+Uv2egTeeMgm9dCz0HU 2/BBq388C2zKLqLMxcrtVDAHaYhkxJqVhCGkypSfN2fPDogFx9PthjLE/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAIOtWFCtJV2d/2dsb2JhbABFhUK3AIEIgicSASc/EgEINjERJQIEAQ0FIodPAwyaJpZaDYlTijmHUgOSMoFcgVWLF4MhgWmCZoIX X-IronPort-AV: E=Sophos;i="4.80,444,1344211200"; d="scan'208";a="122627994" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 18 Sep 2012 17:22:48 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8IHMmjN030390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 17:22:48 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Tue, 18 Sep 2012 12:22:48 -0500 From: "Joe Hildebrand (jhildebr)" To: Phillip Hallam-Baker , Julian Reschke Thread-Topic: [apps-discuss] Guidance on RFC 4627 as reference Thread-Index: AQHNlY3s9Yj5xKrn7EGS9IZMvZhKt5eQTCqAgAAivACAADBTAIAAA4SAgAABw4CAAADjAIAABgUA//+MZoA= Date: Tue, 18 Sep 2012 17:22:48 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.132.51] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19190.004 x-tm-as-result: No--28.955500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <1A1B2558F83C33498B84194917B40C7F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 19 Sep 2012 08:06:49 -0700 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 17:22:50 -0000 On 9/18/12 10:16 AM, "Phillip Hallam-Baker" wrote: >When I use language, I try to be precise. The order of objects and the >order of entries within objects are not the same. Please *read* 4627 before asking for changes? >In another part of the schema compiler I allow objects with repeated >elements: > >{ "A": 1, "A": 2, "B": 3 } Then it's not JSON, at least according to the spirit. From section 2.2: "The names within an object SHOULD be unique." I'd argue that ought to be MUST, but you don't have a good reason to ignore the SHOULD.=20 I'd also be ok with adding language that says that describes what you you do if you receive an invalid object like that; one possibility would be to return an error, another would be to pick a random instance, there are likely others. --=20 Joe Hildebrand From jasnell@gmail.com Wed Sep 19 08:09:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF3221F8681 for ; Wed, 19 Sep 2012 08:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUuOF75mCsgy for ; Wed, 19 Sep 2012 08:09:50 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA2921F860B for ; Wed, 19 Sep 2012 08:09:41 -0700 (PDT) Received: by lboj14 with SMTP id j14so662390lbo.31 for ; Wed, 19 Sep 2012 08:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Lg0cgwRgPx8E308lsqOBC9yMXwEtDfpJ2Cc4gqdodDQ=; b=EyPJNBy3W9olEVB98n9z7BbvULAiKz/qGABlTc3kfLY+Iq0Mza0xtFXP7/ln/IrpmC kUA7JewzktSZVU+e785wgzIuwBgiIcJ4G7ckzhMeXh/3cmFsCIHpQYLf0QxKCRRcdtrt OZRKfW6BlYoPvEAKQY6imtRfIKf5it4pCjU7RAsJJbcl/IfOjS06FFIPUz/XOpDvhZ6y +/RgDA0x22zBS9sGK3iTcayvEsCyCGDOkbthbyZ4l6FBk6a9BNvvcOtthEmVyqvzsUS/ 0/7BSNv40qY/XEfNBpxjaX/tFu7XIz5L1z6x+dT4+0lABkLcNAbpsEnPEu5N37CAIOYK pQ5Q== Received: by 10.152.104.102 with SMTP id gd6mr2659481lab.33.1348067381083; Wed, 19 Sep 2012 08:09:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.26.200 with HTTP; Wed, 19 Sep 2012 08:09:20 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Wed, 19 Sep 2012 08:09:20 -0700 Message-ID: To: "Manger, James H" Content-Type: multipart/alternative; boundary=f46d04088e1561fdb204ca0f65be Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 15:09:51 -0000 --f46d04088e1561fdb204ca0f65be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable An array based approach carries along many of it's own issues, especially if we do decide to extend things later on. What likely would have been ideal (albeit more verbose) are distinct "op" and "ref" codes to identify the patch operation and json-pointer -- e.g. {"op":"add", "ref":"/a/b/c", "value": "123"}. This helps us to enforce the single operation rule, simplifies processing and maintains better long term extensibility at the cost of a few extra bits on the wire. - James On Wed, Sep 19, 2012 at 7:52 AM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > The consensus sounds like "MUST understand everything"; no ignoring > unrecognized fields. That is ok, but we haven't picked a good syntax to > match that rule. > > The "obvious" way to parse a patch operation object (eg > {"add":"/foo","value":"bar"}) is to: > > 1. Loop through the keys in the object until you find one that is in the > set of known operations: "add", "remove", "test"=E2=80=A6 > > 2. Extract the elements associated with that specific operation, eg the > "value" for an "add" operation. > > That "obvious" process will not detect two operations in an object, or > unexpected extra fields. Implementations will have to do non-trivial extr= a > work to make those checks. Many will not do that, or will do it > incorrectly, simply because valid cases will work regardless of that extr= a > code. The result is likely to be security problems. For instance, one > implementation parsing {"value":"bar", "add":"/foo", "remove":"/foo"} wil= l > see an "add" operation, another will see a "remove" operation (and a thir= d > will report an error), simply based on how implementation-specific string > hash codes are calculated. > > The nice thing about a JSON object is that you can add all sorts of extra > elements without affecting existing elements. Given we explicitly don't > want this feature, perhaps a better syntax would be a JSON array: startin= g > with the operation name, then the operation-specific parameters. > > For example: > instead of {"add":"/foo", "value":"bar"} > have ["add", "/foo", "bar"] > > Duplicate operations cannot occur (there can only be one first element in > an array). Preventing unexpected parameters is as simple as ensuring the > array is the right length for the specific operation. > > The array approach should also be simpler to map to a per-operation > function call with arguments. > > -- > James Manger > > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of Mark Nottingham > > Sent: Wednesday, 19 September 2012 9:56 AM > > To: James M Snell > > Cc: apps-discuss@ietf.org > > Subject: Re: [apps-discuss] JSON Patch: extensibility > > > > Going with: > > > > > It is an error condition if an operation object does not contain a= n > > > operation member, contains an operation member other than one of > > > those defined by this document, or more than one operation member. > > > > > > Likewise, it is an error condition if an operation object has a > > > member that is not explicitly allowed by this document. > > > > > > On 18/09/2012, at 10:49 AM, James M Snell wrote: > > > > > +1 on having it be an error condition. > > > > > > Because of the potentially significant negative impact that an > > improperly applied patch operation could have on the target resource, > > any not-understood operation, object or member MUST result in an error > > condition being reported and the patch rejected. > > > > > > - James > > > > > > On Tue, Sep 18, 2012 at 10:42 AM, Paul C. Bryan > > wrote: > > > On Tue, 2012-09-18 at 10:27 -0700, Mark Nottingham wrote: > > > > > >> James is right that the document is currently silent about extra > > properties on the operation. Do people have strong feelings about > > whether this should result in an error condition, or be ignored? > > > > > > It was definitely intended to be an error condition. On this point, > > the specification reads: > > > > > > "It is an error condition if an operation object contains no > > recognized operation member or more than one operation member." > > > > > > I suppose it would be stronger to say something like: > > > > > > "It is an error condition if an operation object does not contain > > an operation member documented herein, or more than one operation > > member." > > > > > > Paul > > --f46d04088e1561fdb204ca0f65be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable An array based approach carries along = many of it's own issues, especially if we do decide to extend things la= ter on. What likely would have been ideal (albeit more verbose) are distinc= t "op" and "ref" codes to identify the patch operation = and json-pointer -- e.g. {"op":"add", "ref":&= quot;/a/b/c", "value": "123"}. This helps us to en= force the single operation rule, simplifies processing and maintains better= long term extensibility at the cost of a few extra bits on the wire.=C2=A0=

    - James

    On We= d, Sep 19, 2012 at 7:52 AM, Manger, James H <James.H.Mange= r@team.telstra.com> wrote:
    The consensus sounds like "MUST underst= and everything"; no ignoring unrecognized fields. That is ok, but we h= aven't picked a good syntax to match that rule.

    The "obvious" way to parse a patch operation object (eg {"ad= d":"/foo","value":"bar"}) is to:

    1. Loop through the keys in the object until you find one that is in the se= t of known operations: "add", "remove", "test"= ;=E2=80=A6

    2. Extract the elements associated with that specific operation, eg the &qu= ot;value" for an "add" operation.

    That "obvious" process will not detect two operations in an objec= t, or unexpected extra fields. Implementations will have to do non-trivial = extra work to make those checks. Many will not do that, or will do it incor= rectly, simply because valid cases will work regardless of that extra code.= The result is likely to be security problems. For instance, one implementa= tion parsing {"value":"bar", "add":"/foo= ", "remove":"/foo"} will see an "add" op= eration, another will see a "remove" operation (and a third will = report an error), simply based on how implementation-specific string hash c= odes are calculated.

    The nice thing about a JSON object is that you can add all sorts of extra e= lements without affecting existing elements. Given we explicitly don't = want this feature, perhaps a better syntax would be a JSON array: starting = with the operation name, then the operation-specific parameters.

    For example:
    instead of =C2=A0{"add":"/foo", "value":"= ;bar"}
    have =C2=A0 =C2=A0 =C2=A0 =C2=A0["add", "/foo", "b= ar"]

    Duplicate operations cannot occur (there can only be one first element in a= n array). Preventing unexpected parameters is as simple as ensuring the arr= ay is the right length for the specific operation.

    The array approach should also be simpler to map to a per-operation functio= n call with arguments.

    --
    James Manger


    > -----Original Message-----
    > From: apps-discuss-bo= unces@ietf.org [mailto:apps-discuss-
    >     bounces@ietf.org] On Behalf Of= Mark Nottingham
    > Sent: Wednesday, 19 September 2012 9:56 AM
    > To: James M Snell
    > Cc: apps-discuss@ietf.org=
    > Subject: Re: [apps-discuss] JSON Patch: extensibility
    >
    > Going with:
    >
    > > =C2=A0 =C2=A0It is an error condition if an operation object does= not contain an
    > > =C2=A0 =C2=A0operation member, contains an operation member other= than one of
    > > =C2=A0 =C2=A0those defined by this document, or more than one ope= ration member.
    > >
    > > =C2=A0 =C2=A0Likewise, it is an error condition if an operation o= bject has a
    > > =C2=A0 =C2=A0member that is not explicitly allowed by this docume= nt.
    >
    >
    > On 18/09/2012, at 10:49 AM, James M Snell <jasnell@gmail.com> wrote:
    >
    > > +1 on having it be an error condition.
    > >
    > > Because of the potentially significant negative impact that an > improperly applied patch operation could have on the target resource,<= br> > any not-understood operation, object or member MUST result in an error=
    > condition being reported and the patch rejected.
    > >
    > > - James
    > >
    > > On Tue, Sep 18, 2012 at 10:42 AM, Paul C. Bryan <pbryan@anode.ca>
    > wrote:
    > > On Tue, 2012-09-18 at 10:27 -0700, Mark Nottingham wrote:
    > >
    > >> James is right that the document is currently silent about ex= tra
    > properties on the operation. Do people have strong feelings about
    > whether this should result in an error condition, or be ignored?
    > >
    > > It was definitely intended to be an error condition. On this poin= t,
    > the specification reads:
    > >
    > > =C2=A0 =C2=A0 "It is an error condition if an operation obje= ct contains no
    > recognized operation member or more than one operation member." > >
    > > I suppose it would be stronger to say something like:
    > >
    > > =C2=A0 =C2=A0 "It is an error condition if an operation obje= ct does not contain
    > an operation member documented herein, or more than one operation
    > member."
    > >
    > > Paul


    --f46d04088e1561fdb204ca0f65be-- From evan@status.net Wed Sep 19 08:17:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDF421F8745 for ; Wed, 19 Sep 2012 08:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrukL6iw+OK3 for ; Wed, 19 Sep 2012 08:16:57 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADFE21F873E for ; Wed, 19 Sep 2012 08:16:57 -0700 (PDT) Received: from [192.168.0.113] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 4BE508D662C for ; Wed, 19 Sep 2012 15:27:10 +0000 (UTC) Message-ID: <5059E1E8.6040704@status.net> Date: Wed, 19 Sep 2012 11:16:56 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary="------------060603000206000408060604" Subject: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 15:17:00 -0000 This is a multi-part message in MIME format. --------------060603000206000408060604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I find it funny that JSON Pointer syntax doesn't map more closely to object syntax in JavaScript. I'd expect that {"foo": {"bar": {"baz": 2}}} would be addressed as something familiar like "foo.bar.baz" rather than "foo/bar/baz", and {"foo": {"bar.baz": 2}} would be addressed as something like 'foo["bar.baz"]'. I've seen the dotted notation in other contexts, like MongoDB queries: http://www.mongodb.org/display/DOCS/Advanced+Queries#AdvancedQueries-ValueinanEmbeddedObject -Evan --------------060603000206000408060604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I find it funny that JSON Pointer syntax doesn't map more closely to object syntax in JavaScript.

    I'd expect that {"foo": {"bar": {"baz": 2}}} would be addressed as something familiar like "foo.bar.baz" rather than "foo/bar/baz", and {"foo": {"bar.baz": 2}} would be addressed as something like 'foo["bar.baz"]'.

    I've seen the dotted notation in other contexts, like MongoDB queries:

    http://www.mongodb.org/display/DOCS/Advanced+Queries#AdvancedQueries-ValueinanEmbeddedObject

    -Evan



    --------------060603000206000408060604-- From fgaliegue@gmail.com Wed Sep 19 08:27:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9970421F8665 for ; Wed, 19 Sep 2012 08:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUXECg6pShEo for ; Wed, 19 Sep 2012 08:27:45 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A68DE21F861A for ; Wed, 19 Sep 2012 08:27:44 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1386207vcb.31 for ; Wed, 19 Sep 2012 08:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lisUBgWMM4q5rUrDxJsUTMnxAQnm8/fk531kBFiCcoM=; b=X2GkEbDwhtC1gJw6p/HrlCTn+a/QB8+50iHNXusuMTgWKeGTZw+GAninODMEZUwcM4 nIyjm5xkMqy+JXLMLfwgi18nfpLMqT8hY6I6F++v8GT7+JTIKZVuglgY4Y75Tmhbu609 /UB82f41jm5XHo/gGL9vBPqrlhg0NCmOqvVI7zx0s0W/WwQ1V3DkMg/BQ0e58H7WsOcA 7/LCqI5sYm7qVe62DuD5MgdttW8iMl8rWnYJg55po53wclJxDqTeozdMjM9spJWc+tpa KGOCZckaptEOe0QHZUfRYd33GtQk/Qi0eIxZ4vVwX/jdGLePZjF46ZxrWbJW06qto8PV 5rNg== MIME-Version: 1.0 Received: by 10.58.0.7 with SMTP id 7mr2212323vea.18.1348068464172; Wed, 19 Sep 2012 08:27:44 -0700 (PDT) Received: by 10.52.23.103 with HTTP; Wed, 19 Sep 2012 08:27:44 -0700 (PDT) In-Reply-To: <5059E1E8.6040704@status.net> References: <5059E1E8.6040704@status.net> Date: Wed, 19 Sep 2012 17:27:44 +0200 Message-ID: From: Francis Galiegue To: Evan Prodromou Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 15:27:45 -0000 On Wed, Sep 19, 2012 at 5:16 PM, Evan Prodromou wrote: > I find it funny that JSON Pointer syntax doesn't map more closely to obje= ct > syntax in JavaScript. > JSON is not JavaScript! / has been chosen because it is the most commonly used path separator, and note as well that JSON Pointer does not make differences between objects and arrays. > I'd expect that {"foo": {"bar": {"baz": 2}}} would be addressed as someth= ing > familiar like "foo.bar.baz" rather than "foo/bar/baz", and {"foo": > {"bar.baz": 2}} would be addressed as something like 'foo["bar.baz"]'. > That'd be "/foo/bar/baz" (note the initial /) and "/foo/bar.baz". Unambiguous, unlike your notation. And accessing the first element of this array: [ 1, 2, 3 ] is written /0. So is accessing key 0 in this object: { "0": 1 } JSON Pointer has been written like this on purpose. It is unambiguous, impervious to programming languages pecularities and encodings... All advantages and none of the drawbacks :) --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From evan@status.net Wed Sep 19 09:06:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A4B21F8764 for ; Wed, 19 Sep 2012 09:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bqdSJ-qHcvb for ; Wed, 19 Sep 2012 09:06:15 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 75F1721F8763 for ; Wed, 19 Sep 2012 09:06:15 -0700 (PDT) Received: from [192.168.0.113] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 844028D63D4 for ; Wed, 19 Sep 2012 16:16:28 +0000 (UTC) Message-ID: <5059ED76.50202@status.net> Date: Wed, 19 Sep 2012 12:06:14 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <5059E1E8.6040704@status.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 16:06:16 -0000 On 12-09-19 11:27 AM, Francis Galiegue wrote: > JSON Pointer has been written like this on purpose. It is unambiguous, > impervious to programming languages pecularities and encodings... All > advantages and none of the drawbacks :) It conspicuously lacks the advantage of being familiar for people who know JavaScript or JavaScript-based syntaxes like the MongoDB example I linked to. That said, I appreciate the response, and I'm just glad the subject has been discussed. -Evan From fgaliegue@gmail.com Wed Sep 19 09:44:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D808721F85F7 for ; Wed, 19 Sep 2012 09:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPLalTG3tW6x for ; Wed, 19 Sep 2012 09:44:45 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 14CA521F846F for ; Wed, 19 Sep 2012 09:44:44 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1504736vcb.31 for ; Wed, 19 Sep 2012 09:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=W0MBwdikPq7Qw7k/UGk51ma693CxvyjSA5/UZ9cpWx0=; b=TLkhpkjaSzo1VzyZsnh0+0/yzJYcmKdIjQAMGt3nYVgxuY5T2aaqp5yhKQGFPV6sfM /Xqx/QGFB+7dB/463HAT4vRsV/qrrv+SnBnaCYJvATJru+Y1kmZQDLadXRhbGnq2NeNm zWyoLgM1ZsAa4hma0ALIla4cxgmFKHsio/0TbYp1/8rARlWLXMLgUw1wIEiyQNsL+GCx oMOubRs5Z0Pk/IoqTaq2bPoNNfBX0sXUjkf3z7l+IOGRnD8JPDOIMZoDbOMOc78y9Qk3 fDk8/vg4Yw6qrF7vqndEOD72UDeudcPp/mNmTWXfZ59c+QWDyBrIa/BXDUj8+1wp9P1r njEQ== MIME-Version: 1.0 Received: by 10.52.35.99 with SMTP id g3mr1867712vdj.21.1348073084494; Wed, 19 Sep 2012 09:44:44 -0700 (PDT) Received: by 10.52.23.103 with HTTP; Wed, 19 Sep 2012 09:44:44 -0700 (PDT) In-Reply-To: <5059ED76.50202@status.net> References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> Date: Wed, 19 Sep 2012 18:44:44 +0200 Message-ID: From: Francis Galiegue To: Evan Prodromou Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 16:44:46 -0000 On Wed, Sep 19, 2012 at 6:06 PM, Evan Prodromou wrote: > On 12-09-19 11:27 AM, Francis Galiegue wrote: >> >> JSON Pointer has been written like this on purpose. It is unambiguous, >> impervious to programming languages pecularities and encodings... All >> advantages and none of the drawbacks :) > > It conspicuously lacks the advantage of being familiar for people who kno= w > JavaScript or JavaScript-based syntaxes like the MongoDB example I linked > to. > Sure, but again, JSON Pointer has not been conceived with any programming language in mind. It, and JSON Reference, are the only two existing mechanisms able to unambiguously address any subset of any JSON value anywhere, by anyone, at any time. Tying this kind of specification to a programming language/a particular protocol/whatever would be shortsighted and counterproductive. And consider this: { "": { "/": { "~": [ 1, 2 ] } } } With JSON Pointer, you address the first element of the inner array using //~0/~1/0. This is even shorter to write than it is in JavaScript. _And_ more portable ;) --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From hallam@gmail.com Wed Sep 19 09:59:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B52921F8615 for ; Wed, 19 Sep 2012 09:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4e3zUJaz34m for ; Wed, 19 Sep 2012 09:59:17 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC5E021F8499 for ; Wed, 19 Sep 2012 09:59:17 -0700 (PDT) Received: by oagn5 with SMTP id n5so769348oag.31 for ; Wed, 19 Sep 2012 09:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uhEWGtjG/rs+hxo1JtrUVvpaN4qMQUXEA8Ftyx61Vrs=; b=ezPWTU9SEug3qBzpudEq5rgM5DQX2UMkTtMtwdBTxZikTdhU9kqaGAwQGyzfQRLAIP hIHb5QJiBJohW2FykEQ0luwupsWu2+gpA1BVFpES8+1H3m4A+a/JEDazZMSq4nTOexhq jTgqvTpgp/prL1kYF7BWw99wgHmwMZ0mB/JC57AQGlpZqyp4JJ8/yr8R6g3VIP0u24lW h+gkRzPiKikLif7/2cDog2MLHA3JAK94+vNV3luZ7Q4HO2HpLXMtHQIo+uiO5cCjWlF9 dCwvHGK/tNYvVAJODtGWtTbiJVK2wn1rP1rGnDNSn8zCEFETsJBIX0cFfzfSLc1pK3ev VTww== MIME-Version: 1.0 Received: by 10.182.75.33 with SMTP id z1mr3607924obv.9.1348073957309; Wed, 19 Sep 2012 09:59:17 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Wed, 19 Sep 2012 09:59:17 -0700 (PDT) In-Reply-To: References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> Date: Wed, 19 Sep 2012 12:59:17 -0400 Message-ID: From: Phillip Hallam-Baker To: Francis Galiegue Content-Type: multipart/alternative; boundary=14dae93994e75b3b1804ca10edfc Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 16:59:18 -0000 --14dae93994e75b3b1804ca10edfc Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 19, 2012 at 12:44 PM, Francis Galiegue wrote: > On Wed, Sep 19, 2012 at 6:06 PM, Evan Prodromou wrote: > > On 12-09-19 11:27 AM, Francis Galiegue wrote: > >> > >> JSON Pointer has been written like this on purpose. It is unambiguous, > >> impervious to programming languages pecularities and encodings... All > >> advantages and none of the drawbacks :) > > > > It conspicuously lacks the advantage of being familiar for people who > know > > JavaScript or JavaScript-based syntaxes like the MongoDB example I linked > > to. > > > > Sure, but again, JSON Pointer has not been conceived with any > programming language in mind. It, and JSON Reference, are the only two > existing mechanisms able to unambiguously address any subset of any > JSON value anywhere, by anyone, at any time. > > Tying this kind of specification to a programming language/a > particular protocol/whatever would be shortsighted and > counterproductive. And consider this: > > { "": { "/": { "~": [ 1, 2 ] } } } > > With JSON Pointer, you address the first element of the inner array > using //~0/~1/0. This is even shorter to write than it is in > JavaScript. _And_ more portable ;) Just where is JSON Pointer intended to be used? Who is using it? Pretty much every modern programming language has adopted a notation that uses dots for member extraction and square braces for array indices. I don't see a particularly good reason to invent another way to extract information from a data structure. In C# and Java the notation would be x.y[1]. There are different answers in C and C++ of course but I don't think anyone wants to copy from those examples at this point. Trying to use all dots comes up with the problem that x and y are labels and an array index is a value so using a format like x.y.1 becomes difficult to interpret when using a variable for an index, x.y.z is confusing as x and y are member names and z is an index. This gets even worse when z is also a member name (and could lead to attacks). I can't see why I would want to have a different syntax to extract elements after a data object has been JSON encoded. What is the value of such a standard meant to be? This looks like an attempt to reinvent a wheel that has already been tried and tested. -- Website: http://hallambaker.com/ --14dae93994e75b3b1804ca10edfc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Sep 19, 2012 at 12:44 PM, Francis Galiegue <fgaliegue@gmail.com<= /a>> wrote:
    On Wed, Sep 19, 2012 at 6:06 PM, Evan Prodromou <evan@status.net> wrote:
    > On 12-09-19 11:27 AM, Francis Galiegue wrote:
    >>
    >> JSON Pointer has been written like this on purpose. It is unambigu= ous,
    >> impervious to programming languages pecularities and encodings... = All
    >> advantages and none of the drawbacks :)
    >
    > It conspicuously lacks the advantage of being familiar for people who = know
    > JavaScript or JavaScript-based syntaxes like the MongoDB example I lin= ked
    > to.
    >

    Sure, but again, JSON Pointer has not been conceived with any
    programming language in mind. It, and JSON Reference, are the only two
    existing mechanisms able to unambiguously address any subset of any
    JSON value anywhere, by anyone, at any time.

    Tying this kind of specification to a programming language/a
    particular protocol/whatever would be shortsighted and
    counterproductive. And consider this:

    { "": { "/": { "~": [ 1, 2 ] } } }

    With JSON Pointer, you address the first element of the inner array
    using //~0/~1/0. This is even shorter to write than it is in
    JavaScript. _And_ more portable ;)

    Just whe= re is=A0JSON Pointer intended to be used? Who is using it?

    Pretty much every modern programming language has adopted a notati= on that uses dots for member extraction and square braces for array indices= . I don't see a particularly good reason to invent another way to extra= ct information from a data structure.

    In C# and Java the notation would be x.y[1].
    =
    There are different answers in C and C++ of course but I don= 't think anyone wants to copy from those examples at this point.

    Trying to use all dots comes up with the problem that x= and y are labels and an array index is a value so using a format like x.y.= 1 becomes difficult to interpret when using a variable for an index, x.y.z = is confusing as x and y are member names and z is an index. This gets even = worse when z is also a member name (and could lead to attacks).


    I can't see why I would want to hav= e a different syntax to extract elements after a data object has been JSON = encoded. What is the value of such a standard meant to be?

    This looks like an attempt to reinvent a wheel that has already been t= ried and tested.=A0
    --14dae93994e75b3b1804ca10edfc-- From fgaliegue@gmail.com Wed Sep 19 10:05:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098DA21F870A for ; Wed, 19 Sep 2012 10:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUxAjePHd-8C for ; Wed, 19 Sep 2012 10:05:17 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E30421F8704 for ; Wed, 19 Sep 2012 10:05:17 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1532770vcb.31 for ; Wed, 19 Sep 2012 10:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=woFP/qw5Lt/twjaQAUt7vQsJw1x3gj8XdEI008My9Pg=; b=LAZhVPwnJ9WHO6UwUBJqtj+uOwzcdSNNvsrjfwCaeHEUmu4WVP3DGMFZIhGyhKvVJM uIHntJh8UNqZuoEa1ea2+M7spFL8JaFR4rzwOC/JihRus6mOgR6zRZ0UKTpTV6OCkNic 12DQwzc1rQ9hNgNB87h6K6+3Dd5S+OdmNun+SnUn3Ey5NvkxoU0QeMD5MR90x/EVzEd2 K0wbz8SjI9VhezpR7odDhhql/3BcVxm19TigOGPb8DLuW9dnzdthNmLpSayw+yWX6hDc qH0RqdP9GEKVpP2stRvH+q8F6mVQ9EcXB4Lqk9r9M20jyXYPAiCPSmMRHoFvP3/BlnxP 58cw== MIME-Version: 1.0 Received: by 10.52.64.209 with SMTP id q17mr1866737vds.32.1348074316923; Wed, 19 Sep 2012 10:05:16 -0700 (PDT) Received: by 10.52.23.103 with HTTP; Wed, 19 Sep 2012 10:05:16 -0700 (PDT) In-Reply-To: References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> Date: Wed, 19 Sep 2012 19:05:16 +0200 Message-ID: From: Francis Galiegue To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 17:05:19 -0000 On Wed, Sep 19, 2012 at 6:59 PM, Phillip Hallam-Baker wr= ote: [...] > > > Just where is JSON Pointer intended to be used? Who is using it? > JSON Schema, for instance, even though only implicitly for now. The next version will mandate JSON Reference support and, as such, JSON Pointer (which is the fragment part of a JSON Reference). > > Pretty much every modern programming language has adopted a notation that > uses dots for member extraction and square braces for array indices. I do= n't > see a particularly good reason to invent another way to extract informati= on > from a data structure. > > In C# and Java the notation would be x.y[1]. > Again, programming languages do not enter the picture. What is wanted is an unambiguous way to address any part of a JSON value. Oh, and "." is a valid object member name. And so is "/" for that matter. And so is "", and so is "\x00". [...] > > I can't see why I would want to have a different syntax to extract elemen= ts > after a data object has been JSON encoded. What is the value of such a > standard meant to be? > Language-proof, future-proof, covers all corner cases. If these are not arguments, I don't know what is. Oh, and the fact that it can be used in URI fragments. > This looks like an attempt to reinvent a wheel that has already been trie= d > and tested. > Tried and tested _by a few subset of programming languages_. --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From hallam@gmail.com Wed Sep 19 10:30:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1F021F8746 for ; Wed, 19 Sep 2012 10:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.963 X-Spam-Level: X-Spam-Status: No, score=-3.963 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zc8H7uirGUaf for ; Wed, 19 Sep 2012 10:30:33 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E39821F8745 for ; Wed, 19 Sep 2012 10:30:33 -0700 (PDT) Received: by oagn5 with SMTP id n5so804269oag.31 for ; Wed, 19 Sep 2012 10:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=y0ASv6FyYxP1u2ehZeUpq9dYFKxIJJnHocRYZ/o+2cY=; b=bHndkoEYbNCZ1nHSkiZar3ziuvCT8t5o3fQ/rKT0njdNvzLqOT3QfcwA2g2rT9CITR ex3JOxHXrL3AGd4czU0ygeS3dBYe+/GR69Owmi8F3PKqmVu2PPmns76wRSEHkhq5Adw2 ik9E7q60ZQcplT3gBz8wqzkgYed3b0yjA/4mYA7HNhUlTuHfmjBUfcNMu5k5eZu3ib1U JiZn5CMbycyV796ItlVaBJUCKHqCL5yupubNSW2uuzGDYcqqd8xcZFOifhr/AhGzT9tT Sw8xKpWXS9ab30Fo2104k7inG4LmDM31ngbDayV60Csk96lsWsIqEC9tQad5uhUZzRgZ vmNg== MIME-Version: 1.0 Received: by 10.60.29.72 with SMTP id i8mr3538422oeh.26.1348075833232; Wed, 19 Sep 2012 10:30:33 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Wed, 19 Sep 2012 10:30:33 -0700 (PDT) Date: Wed, 19 Sep 2012 13:30:33 -0400 Message-ID: From: Phillip Hallam-Baker To: Francis Galiegue Content-Type: multipart/alternative; boundary=e89a8fb1f8062b8e6604ca115d3b Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 17:30:34 -0000 --e89a8fb1f8062b8e6604ca115d3b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One of the biggest mistakes that was made in the XML world was to allow one group of authors to develop a specification and call it 'XML Schema'. I think we are at risk of making the same mistake here. The more I hear about this effort, the less I like it. The approach seems to be needlessly complex for a start. There should be no need to have a pointer structure in a modern data modelling language, none. C# and Java don't use pointers, so why are they needed in JSON Schema? I think people should be allowed to go off and develop a spec but they should not be allowed to grab a false sense of authority through an inappropriate name grab. That had bad results in the XML world and I can't see this effort working out any better. Using a schema to develop a protocol is a very good idea but each and every schema language I have had to use has been botched. XML schema has two separate type systems. ASN.1 schema is arcane. We must not let that happen to JSON. It should be possible to have a schema language that is essentially language neutral and encoding neutral. Pretty much every programming language in current use has the same set of intrinsic types (bytes, int16, int32, int64, strings (unicode), chars (unicode), real32, real64, boolean), and at least one form of enumerated collection (arrays, lists, sets). For protocol design it is very useful to add in standard representations for Binary and DateTime intrinsict types as base64 encoded strings are easier to deal with than arrays of decimal bytes and we already have an IETF string representation for time. It should be possible to use a schema to map a data structure that can be represented conveniently in any sensible modern programming language (i.e. anything from Perl to Java, C# but not necessarily FORTRAN, COBOL or the like) to at least a subset of any sensible encoding (JSON, XML, ASN.1) Where the XML Schema effort went wrong was they tried to support every feature of DTDs and they gave the schema designer the ability to map a data structure onto multiple different encodings. Which is pretty weird. Making standards is the process of making design choices that don't matter. Providing multiple ways to serialize the same data structure is a harmful option. At any rate I suggest that either 1) the authors of JSON Schema start using a different name or 2) Everyone else with ideas for a schema for JSON busilly pollute the name space by introducing their own plans named JSON Schema until the authors back down. Since there is no consensus that JSON needs a schema, I can't see how there can be a consensus for one particular proposal. In fact I don't think JSON does need a schema either. We need a schema for describing protocol data structures that can be reified as JSON or other data formats. On Wed, Sep 19, 2012 at 1:05 PM, Francis Galiegue wrot= e: > On Wed, Sep 19, 2012 at 6:59 PM, Phillip Hallam-Baker > wrote: > [...] > > > > > > Just where is JSON Pointer intended to be used? Who is using it? > > > > JSON Schema, for instance, even though only implicitly for now. The > next version will mandate JSON Reference support and, as such, JSON > Pointer (which is the fragment part of a JSON Reference). > > > > > Pretty much every modern programming language has adopted a notation th= at > > uses dots for member extraction and square braces for array indices. I > don't > > see a particularly good reason to invent another way to extract > information > > from a data structure. > > > > In C# and Java the notation would be x.y[1]. > > > > Again, programming languages do not enter the picture. What is wanted > is an unambiguous way to address any part of a JSON value. > > Oh, and "." is a valid object member name. And so is "/" for that > matter. And so is "", and so is "\x00". > > [...] > > > > I can't see why I would want to have a different syntax to extract > elements > > after a data object has been JSON encoded. What is the value of such a > > standard meant to be? > > > > Language-proof, future-proof, covers all corner cases. If these are > not arguments, I don't know what is. > > Oh, and the fact that it can be used in URI fragments. > > > This looks like an attempt to reinvent a wheel that has already been > tried > > and tested. > > > > Tried and tested _by a few subset of programming languages_. > > -- > Francis Galiegue, fgaliegue@gmail.com > JSON Schema: https://github.com/json-schema > "It seems obvious [...] that at least some 'business intelligence' > tools invest so much intelligence on the business side that they have > nothing left for generating SQL queries" (St=E9phane Faroult, in "The > Art of SQL", ISBN 0-596-00894-5) > --=20 Website: http://hallambaker.com/ --e89a8fb1f8062b8e6604ca115d3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One of the biggest mistakes that was made in the XML world was to allow one= group of authors to develop a specification and call it 'XML Schema= 9;. I think we are at risk of making the same mistake here.

    The more I hear about this effort, the less I like it. The approach se= ems to be needlessly complex for a start. There should be no need to have a= pointer structure in a modern data modelling language, none. C# and Java d= on't use pointers, so why are they needed in JSON Schema?

    I think people should be allowed to go off and develop = a spec but they should not be allowed to grab a false sense of authority th= rough an inappropriate name grab. That had bad results in the XML world and= I can't see this effort working out any better.


    Using a schema to develop a protocol is = a very good idea but each and every schema language I have had to use has b= een botched. XML schema has two separate type systems. ASN.1 schema is arca= ne. We must not let that happen to JSON.

    It should be possible to have a schema language that is= essentially language neutral and encoding neutral. Pretty much every progr= amming language in current use has the same set of intrinsic types (bytes, = int16, int32, int64, strings (unicode), chars (unicode), real32, real64, bo= olean), and at least one form of enumerated collection (arrays, lists, sets= ). For protocol design it is very useful to add in standard representations= for Binary and DateTime intrinsict types as base64 encoded strings are eas= ier to deal with than arrays of decimal bytes and we already have an IETF s= tring representation for time.

    It should be possible to use a schema to map a data str= ucture that can be represented conveniently in any sensible modern programm= ing language (i.e. anything from Perl to Java, C# but not necessarily FORTR= AN, COBOL or the like) to at least a subset of any sensible encoding (JSON,= XML, ASN.1)


    Where the XML Schema effort went wrong w= as they tried to support every feature of DTDs and they gave the schema des= igner the ability to map a data structure onto multiple different encodings= . Which is pretty weird. Making standards is the process of making design c= hoices that don't matter. Providing multiple ways to serialize the same= data structure is a harmful option.


    At any rate I suggest that either
    <= div>
    1) the authors of JSON Schema start using a different na= me or
    2) Everyone else with ideas for a schema for JSON busilly p= ollute the name space by introducing their own plans named JSON Schema unti= l the authors back down.


    Since there is no consensus that JSON ne= eds a schema, I can't see how there can be a consensus for one particul= ar proposal.

    In fact I don't think JSON does n= eed a schema either. We need a schema for describing protocol data structur= es that can be reified as JSON or other data formats.

    On Wed, Sep 19, 2012 at 1:05 PM, F= rancis Galiegue <fgaliegue@gmail.com> wrote:
    On Wed, Sep 19, 2012 at 6:59 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
    [...]
    >
    >
    > Just where is JSON Pointer intended to be used? Who is using it?
    >

    JSON Schema, for instance, even though only implicitly for now. The next version will mandate JSON Reference support and, as such, JSON
    Pointer (which is the fragment part of a JSON Reference).

    >
    > Pretty much every modern programming language has adopted a notation t= hat
    > uses dots for member extraction and square braces for array indices. I= don't
    > see a particularly good reason to invent another way to extract inform= ation
    > from a data structure.
    >
    > In C# and Java the notation would be x.y[1].
    >

    Again, programming languages do not enter the picture. What is wanted=
    is an unambiguous way to address any part of a JSON value.

    Oh, and "." is a valid object member name. And so is "/"= ; for that
    matter. And so is "", and so is "\x00".

    [...]
    >
    > I can't see why I would want to have a different syntax to extract= elements
    > after a data object has been JSON encoded. What is the value of such a=
    > standard meant to be?
    >

    Language-proof, future-proof, covers all corner cases. If these are not arguments, I don't know what is.

    Oh, and the fact that it can be used in URI fragments.

    > This looks like an attempt to reinvent a wheel that has already been t= ried
    > and tested.
    >

    Tried and tested _by a few subset of programming languages_.

    --
    Francis Galiegue, fgaliegue@gmail.co= m
    JSON Schema: h= ttps://github.com/json-schema
    "It seems obvious [...] that at least some 'business intelligence&= #39;
    tools invest so much intelligence on the business side that they have
    nothing left for generating SQL queries" (St=E9phane Faroult, in "= ;The
    Art of SQL", ISBN 0-596-00894-5)



    --
    = Website: http://hallambaker.com/
    --e89a8fb1f8062b8e6604ca115d3b-- From jasnell@gmail.com Wed Sep 19 10:39:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294CB21F86AD for ; Wed, 19 Sep 2012 10:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghudGslrKhrH for ; Wed, 19 Sep 2012 10:39:24 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1CC21F8618 for ; Wed, 19 Sep 2012 10:39:23 -0700 (PDT) Received: by weyx48 with SMTP id x48so790185wey.31 for ; Wed, 19 Sep 2012 10:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YtYMEShVTE1LxPBpPRUVqb/FPfpM+YnUgkhLgmftz5s=; b=hNi0ivsL8cFHI3YVTUDXXmO5UgFaYMH9AWBdB2RyAb1shDKT6Oi2DpKQgi5RfgNanz 13lNziegOM6Es2elb4XcENTPIRQc0qdnm1fDhbZRfAfhpE3X3w87pcrU1oaODvsPZrD6 dVKzMYqEFAADOrVulV32m6DVKB3V5nuF2wikYGwllW8Cri3pHNLO7+p/LU+ZTUfIT7fY 1rhYzSEUPuZQtno5MzZoedMlWzlpv9Z4T0Q+cC10MZGJlpEp+EPtU0IOtvSBrP+SxOMw VUEKoiEv0Sd+nGhXEuZ4MFfHUfpfdRKVGO5c7zZamaOvxJFw0tuPYrDVtssJKt338roS AA4Q== Received: by 10.180.99.196 with SMTP id es4mr92593wib.18.1348076362560; Wed, 19 Sep 2012 10:39:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Wed, 19 Sep 2012 10:39:02 -0700 (PDT) In-Reply-To: References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> From: James M Snell Date: Wed, 19 Sep 2012 10:39:02 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=f46d04428370b8741b04ca117ce2 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 17:39:25 -0000 --f46d04428370b8741b04ca117ce2 Content-Type: text/plain; charset=UTF-8 In general, I agree. While simple, the existing JSON Pointer syntax is not particularly good and does not appear to have any advantage over existing JavaScript syntax except, perhaps when it comes to handling escaped characters (as Francis points out). For example, JSON Pointer is currently used by the JSON Patch specification to reference locations within a JSON document that is being modified. Supposing the following example document, { "a": { "b": { "c": "test", "d": [1,2,3] } } } Using JSON Patch, I can describe a number of changes to make to this document: [ {"replace":"/a/b/c", "value": "foobar" }, {"move":"/a/b/c", "to": "/c" }, {"move":"/a/b/d/0, "to": "/a/b/c/1" } ] After applying these changes, the document would be: { "a": { "b": { "d": [2,1,3] } }, "c": "foobar" } Using a dot syntax instead of the slashes demonstrates that there is really nothing gained by the slashes. [ {"replace":"a.b.c", "value": "foobar" }, {"move":"a.b.c", "to": "c" }, {"move":"a.b.d[0]", "to": "a.b.d[1]" } ] With regards to oddly named members (e.g. "."), the existing JSON Pointer syntax does provide a bit of a simplicity advantage. For instance, given the following exceedingly awful but perfectly valid JSON document: { ".": { "/": { "": ["foo"] } } } The current JSON Pointer syntax for referencing the "foo" value would be: /./~1//0 Using JavaScript notation, however, it would be something along the lines of... ["."]["/"][""][0] To be fair, both are ugly. The former is less complicated lexically but the latter has the advantage of being directly processable within multiple languages without any special handling. For example: # Ruby require 'json' m = JSON.parse('{".":{"/":{"":["foo"]}}}') m["."]["/"][""][0] It Just Works(tm), right out of the box. Where the JavaScript syntax falls down, of course, is when the Pointer is to be used as a component of a URI... which, of course, is one of the major motivating use cases for JSON Pointer in the first place. Obviously, the square brackets [ and ] are explicitly required to be pct-encoded within a URI, making the URI significantly less than human readable. http://example.org/foo.json#%5B%22.%22%5D%5B%22%2F%22%5D%5B%22%22%5D%5B0%5D As opposed to: http://example.org/foo.json#/./~1//0 In short, there are obvious advantages and disadvantages to either syntax approach. Personally, I'd tend to favor the JavaScript syntax because it's easier to process despite being more verbose, but the slash syntax is simple and get's the job done. - James On Wed, Sep 19, 2012 at 9:59 AM, Phillip Hallam-Baker wrote: > On Wed, Sep 19, 2012 at 12:44 PM, Francis Galiegue wrote: > >> On Wed, Sep 19, 2012 at 6:06 PM, Evan Prodromou wrote: >> > On 12-09-19 11:27 AM, Francis Galiegue wrote: >> >> >> >> JSON Pointer has been written like this on purpose. It is unambiguous, >> >> impervious to programming languages pecularities and encodings... All >> >> advantages and none of the drawbacks :) >> > >> > It conspicuously lacks the advantage of being familiar for people who >> know >> > JavaScript or JavaScript-based syntaxes like the MongoDB example I >> linked >> > to. >> > >> >> Sure, but again, JSON Pointer has not been conceived with any >> programming language in mind. It, and JSON Reference, are the only two >> existing mechanisms able to unambiguously address any subset of any >> JSON value anywhere, by anyone, at any time. >> >> Tying this kind of specification to a programming language/a >> particular protocol/whatever would be shortsighted and >> counterproductive. And consider this: >> >> { "": { "/": { "~": [ 1, 2 ] } } } >> >> With JSON Pointer, you address the first element of the inner array >> using //~0/~1/0. This is even shorter to write than it is in >> JavaScript. _And_ more portable ;) > > > Just where is JSON Pointer intended to be used? Who is using it? > > Pretty much every modern programming language has adopted a notation that > uses dots for member extraction and square braces for array indices. I > don't see a particularly good reason to invent another way to extract > information from a data structure. > > In C# and Java the notation would be x.y[1]. > > There are different answers in C and C++ of course but I don't think > anyone wants to copy from those examples at this point. > > Trying to use all dots comes up with the problem that x and y are labels > and an array index is a value so using a format like x.y.1 becomes > difficult to interpret when using a variable for an index, x.y.z is > confusing as x and y are member names and z is an index. This gets even > worse when z is also a member name (and could lead to attacks). > > > I can't see why I would want to have a different syntax to extract > elements after a data object has been JSON encoded. What is the value of > such a standard meant to be? > > This looks like an attempt to reinvent a wheel that has already been tried > and tested. > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d04428370b8741b04ca117ce2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In general, I agree. While simple, the= existing JSON Pointer syntax is not particularly good and does not appear = to have any advantage over existing JavaScript syntax except, perhaps when = it comes to handling escaped characters (as Francis points out).=C2=A0

    For example, JSON Pointer is currently used by the J= SON Patch specification to reference locations within a JSON document that = is being modified.=C2=A0

    Supposing the fol= lowing example document,

    =C2=A0 {
    =C2=A0 =C2=A0 "a": {
    =C2=A0 =C2=A0 =C2=A0 = "b": {
    =C2= =A0 =C2=A0 =C2=A0 =C2=A0 "c": "test",
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 &quo= t;d": [1,2,3]
    = =C2=A0 =C2=A0 =C2=A0 }
    =C2=A0 =C2=A0 }
    = =C2=A0 }

    Using JSON Patch, I can describe a number of ch= anges to make to this document:

    =C2=A0 [
    =C2=A0 =C2=A0 {"replace&q= uot;:"/a/b/c", "value": "foobar" },
    =C2=A0 =C2=A0 {"move&quo= t;:"/a/b/c", "to": "/c" },
    =C2=A0 =C2=A0 {"move":= "/a/b/d/0, "to": "/a/b/c/1" }
    =C2=A0 ]

    After applying thes= e changes, the document would be:

    =C2=A0 {
    =C2=A0 =C2=A0 "a": {
    =C2=A0 =C2=A0 =C2=A0 = "b": {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 "d": [2,1,3]
    =C2=A0 =C2=A0 =C2=A0 }
    =C2=A0 =C2=A0 },
    =
    =C2=A0 =C2= =A0 "c": "foobar"
    =C2=A0 }
    =
    Using a dot syntax instead of the slashes demonstrat= es that there is really nothing gained by the slashes.

    =C2=A0 [
    =C2=A0 =C2=A0 {"replace":"a.b.c",= "value": "foobar" },
    =C2=A0 =C2=A0 {"move":= "a.b.c", "to": "c" },
    =C2=A0 =C2=A0 {"move":"a.b.d= [0]", "to": "a.b.d[1]" }
    =C2=A0 ]
    =
    With regards to oddly named members (e.g. ".&qu= ot;), the existing JSON Pointer syntax does provide a bit of a simplicity a= dvantage.=C2=A0For instance, given the following exceedingly awful but perfectly va= lid JSON document:

    =C2=A0 {
    =C2=A0 =C2=A0 ".": {
    =C2=A0 =C2=A0 =C2=A0 "/": {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 &quo= t;": ["foo"]
    =C2=A0 =C2=A0 =C2=A0 }
    =C2=A0 =C2=A0 }
    =C2=A0 }

    The current JSON Pointer syntax for referencing= the "foo" value would be:

    =C2=A0 /./~1//0

    <= font face=3D"courier new, monospace">Using JavaScript notation, however, it= would be something along the lines of...

    =C2=A0 ["."]["/"]["&qu= ot;][0]

    <= /div>
    To be fair, both are ugly. The former= is less complicated lexically but the latter has the advantage of being di= rectly processable within multiple languages without any special handling. = For example:

    =C2=A0 # Ruby
    =C2=A0 require 'json'
    =C2=A0 m =3D=C2=A0JSON.parse('{".&= quot;:{"/":{"":["foo"]}}}')
    =C2=A0 m["."]["/"][&= quot;"][0]

    It Just Works(tm), = right out of the box.=C2=A0

    Where the JavaScript syntax falls down, of course, i= s when the Pointer is to be used as a component of a URI... which, of cours= e, is one of the major motivating use cases for JSON Pointer in the first p= lace. Obviously, the square brackets [ and ] are explicitly required to be = pct-encoded within a URI, making the URI significantly less than human read= able.


    As opposed to:


    In short, there are obvious advantages and disa= dvantages to either syntax approach. Personally, I'd tend to favor the = JavaScript syntax because it's easier to process despite being more ver= bose, but the slash syntax is simple and get's the job done.=C2=A0

    - James





    O= n Wed, Sep 19, 2012 at 9:59 AM, Phillip Hallam-Baker <= hallam@gmail.com&= gt; wrote:
    On Wed, Sep 19, 2012 at 12= :44 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:
    On Wed, Sep 19, 2012 at 6:06 PM, Evan Prodromou <evan@status.net> wrote:
    > On 12-09-19 11:27 AM, Francis Galiegue wrote:
    >>
    >> JSON Pointer has been written like this on purpose. It is unambigu= ous,
    >> impervious to programming languages pecularities and encodings... = All
    >> advantages and none of the drawbacks :)
    >
    > It conspicuously lacks the advantage of being familiar for people who = know
    > JavaScript or JavaScript-based syntaxes like the MongoDB example I lin= ked
    > to.
    >

    Sure, but again, JSON Pointer has not been conceived with any
    programming language in mind. It, and JSON Reference, are the only two
    existing mechanisms able to unambiguously address any subset of any
    JSON value anywhere, by anyone, at any time.

    Tying this kind of specification to a programming language/a
    particular protocol/whatever would be shortsighted and
    counterproductive. And consider this:

    { "": { "/": { "~": [ 1, 2 ] } } }

    With JSON Pointer, you address the first element of the inner array
    using //~0/~1/0. This is even shorter to write than it is in
    JavaScript. _And_ more portable ;)

    Ju= st where is=C2=A0JSON Pointer intended to be used? Who is using it?

    Pretty much every modern programming language has adopted= a notation that uses dots for member extraction and square braces for arra= y indices. I don't see a particularly good reason to invent another way= to extract information from a data structure.

    In C# and Java the notation would be x.y[1].
    =
    There are different answers in C and C++ of course but I don= 't think anyone wants to copy from those examples at this point.

    Trying to use all dots comes up with the problem that x= and y are labels and an array index is a value so using a format like x.y.= 1 becomes difficult to interpret when using a variable for an index, x.y.z = is confusing as x and y are member names and z is an index. This gets even = worse when z is also a member name (and could lead to attacks).


    I can't see why I would want to hav= e a different syntax to extract elements after a data object has been JSON = encoded. What is the value of such a standard meant to be?

    This looks like an attempt to reinvent a wheel that has already been t= ried and tested.=C2=A0
    =
    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss


    --f46d04428370b8741b04ca117ce2-- From mnot@mnot.net Wed Sep 19 10:44:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B07421F86F7 for ; Wed, 19 Sep 2012 10:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSxsix1mfv+4 for ; Wed, 19 Sep 2012 10:44:44 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id CC93421F86EA for ; Wed, 19 Sep 2012 10:44:44 -0700 (PDT) Received: from [172.30.66.198] (unknown [72.247.151.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1770A22E256; Wed, 19 Sep 2012 13:44:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Mark Nottingham In-Reply-To: Date: Wed, 19 Sep 2012 10:44:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> To: James M Snell X-Mailer: Apple Mail (2.1486) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 17:44:45 -0000 On 19/09/2012, at 10:39 AM, James M Snell wrote: > In short, there are obvious advantages and disadvantages to either = syntax approach. Personally, I'd tend to favor the JavaScript syntax = because it's easier to process despite being more verbose, but the slash = syntax is simple and get's the job done.=20 So, this is a great conversation, but without someone sitting down and = writing the specification text, verifying that it behaves well in = various languages (so that we don't leave attractive nuisances around -- = a significant risk when you specify something that *looks* like it = should work "out of the box"), and proposes it to the group, I don't see = where it's going. Any takers? -- Mark Nottingham http://www.mnot.net/ From hallam@gmail.com Wed Sep 19 10:45:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E421821F875C for ; Wed, 19 Sep 2012 10:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xIMNrmgWpu2 for ; Wed, 19 Sep 2012 10:45:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1A221F8759 for ; Wed, 19 Sep 2012 10:45:11 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1464011obb.31 for ; Wed, 19 Sep 2012 10:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TYYLVVMYZJw2lAhYZKmAQEhoNfoGODzjOrAEFMEYdMU=; b=y6ASg2V7z+UTIVO8LyYIGZfLElpW7ZFIjtXqrICWJZZ4BmmkJPuhprfoyDhFewFjwt 9wmUkoJ9WEmavg7LIGlVs/5OcB0fisbeJorOrQ8uHt4KtSkQvI3HMm+XGHFkx6Qd4399 Z3vm/m9B8RJS740Xa43c1OlQbQNu0N+Ec1rCJFLNTKyCA2odiVF/rHTKgMBMMYqEptu2 IXK5+adnReEy+da10W8DcCz17xbbPjpO4MGeCN5AD6JxdW9HgA5dAzbpDpXEq5vZuQVZ +T+rLHxfyHHpWyqLv2uoQe85BqdoWpIV5xUPCBQgpbutbXpEQ8YYpPIPUNbiJU7GMQod PSMA== MIME-Version: 1.0 Received: by 10.60.172.236 with SMTP id bf12mr3611055oec.23.1348076711057; Wed, 19 Sep 2012 10:45:11 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Wed, 19 Sep 2012 10:45:11 -0700 (PDT) In-Reply-To: References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> Date: Wed, 19 Sep 2012 13:45:11 -0400 Message-ID: From: Phillip Hallam-Baker To: James M Snell Content-Type: multipart/alternative; boundary=bcaec54d47687e1a2d04ca1191be Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 17:45:13 -0000 --bcaec54d47687e1a2d04ca1191be Content-Type: text/plain; charset=ISO-8859-1 It seems to me that if unrestricted chars are permitted, a simpler approach would be to require tags to be specified as JSON strings. "a"."b"."/" That approach supports any tag that is a legal JSON tag including dots. As an option, the encoding could permit the quotes to be omitted if the label only consisted of 'safe' characters. i.e. a-z, A-Z, 0-9, -, _ and any UNICODE char > 255. On Wed, Sep 19, 2012 at 1:39 PM, James M Snell wrote: > In general, I agree. While simple, the existing JSON Pointer syntax is not > particularly good and does not appear to have any advantage over existing > JavaScript syntax except, perhaps when it comes to handling escaped > characters (as Francis points out). > > For example, JSON Pointer is currently used by the JSON Patch > specification to reference locations within a JSON document that is being > modified. > > Supposing the following example document, > > { > "a": { > "b": { > "c": "test", > "d": [1,2,3] > } > } > } > > Using JSON Patch, I can describe a number of changes to make to this > document: > > [ > {"replace":"/a/b/c", "value": "foobar" }, > {"move":"/a/b/c", "to": "/c" }, > {"move":"/a/b/d/0, "to": "/a/b/c/1" } > ] > > After applying these changes, the document would be: > > { > "a": { > "b": { > "d": [2,1,3] > } > }, > "c": "foobar" > } > > Using a dot syntax instead of the slashes demonstrates that there is > really nothing gained by the slashes. > > [ > {"replace":"a.b.c", "value": "foobar" }, > {"move":"a.b.c", "to": "c" }, > {"move":"a.b.d[0]", "to": "a.b.d[1]" } > ] > > With regards to oddly named members (e.g. "."), the existing JSON Pointer > syntax does provide a bit of a simplicity advantage. For instance, given > the following exceedingly awful but perfectly valid JSON document: > > { > ".": { > "/": { > "": ["foo"] > } > } > } > > The current JSON Pointer syntax for referencing the "foo" value would be: > > /./~1//0 > > Using JavaScript notation, however, it would be something along the lines > of... > > ["."]["/"][""][0] > > To be fair, both are ugly. The former is less complicated lexically but > the latter has the advantage of being directly processable within multiple > languages without any special handling. For example: > > # Ruby > require 'json' > m = JSON.parse('{".":{"/":{"":["foo"]}}}') > m["."]["/"][""][0] > > It Just Works(tm), right out of the box. > > Where the JavaScript syntax falls down, of course, is when the Pointer is > to be used as a component of a URI... which, of course, is one of the major > motivating use cases for JSON Pointer in the first place. Obviously, the > square brackets [ and ] are explicitly required to be pct-encoded within a > URI, making the URI significantly less than human readable. > > > http://example.org/foo.json#%5B%22.%22%5D%5B%22%2F%22%5D%5B%22%22%5D%5B0%5D > > As opposed to: > > http://example.org/foo.json#/./~1//0 > > In short, there are obvious advantages and disadvantages to either syntax > approach. Personally, I'd tend to favor the JavaScript syntax because it's > easier to process despite being more verbose, but the slash syntax is > simple and get's the job done. > > - James > > > > > > On Wed, Sep 19, 2012 at 9:59 AM, Phillip Hallam-Baker wrote: > >> On Wed, Sep 19, 2012 at 12:44 PM, Francis Galiegue wrote: >> >>> On Wed, Sep 19, 2012 at 6:06 PM, Evan Prodromou wrote: >>> > On 12-09-19 11:27 AM, Francis Galiegue wrote: >>> >> >>> >> JSON Pointer has been written like this on purpose. It is unambiguous, >>> >> impervious to programming languages pecularities and encodings... All >>> >> advantages and none of the drawbacks :) >>> > >>> > It conspicuously lacks the advantage of being familiar for people who >>> know >>> > JavaScript or JavaScript-based syntaxes like the MongoDB example I >>> linked >>> > to. >>> > >>> >>> Sure, but again, JSON Pointer has not been conceived with any >>> programming language in mind. It, and JSON Reference, are the only two >>> existing mechanisms able to unambiguously address any subset of any >>> JSON value anywhere, by anyone, at any time. >>> >>> Tying this kind of specification to a programming language/a >>> particular protocol/whatever would be shortsighted and >>> counterproductive. And consider this: >>> >>> { "": { "/": { "~": [ 1, 2 ] } } } >>> >>> With JSON Pointer, you address the first element of the inner array >>> using //~0/~1/0. This is even shorter to write than it is in >>> JavaScript. _And_ more portable ;) >> >> >> Just where is JSON Pointer intended to be used? Who is using it? >> >> Pretty much every modern programming language has adopted a notation that >> uses dots for member extraction and square braces for array indices. I >> don't see a particularly good reason to invent another way to extract >> information from a data structure. >> >> In C# and Java the notation would be x.y[1]. >> >> There are different answers in C and C++ of course but I don't think >> anyone wants to copy from those examples at this point. >> >> Trying to use all dots comes up with the problem that x and y are labels >> and an array index is a value so using a format like x.y.1 becomes >> difficult to interpret when using a variable for an index, x.y.z is >> confusing as x and y are member names and z is an index. This gets even >> worse when z is also a member name (and could lead to attacks). >> >> >> I can't see why I would want to have a different syntax to extract >> elements after a data object has been JSON encoded. What is the value of >> such a standard meant to be? >> >> This looks like an attempt to reinvent a wheel that has already been >> tried and tested. >> >> -- >> Website: http://hallambaker.com/ >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > -- Website: http://hallambaker.com/ --bcaec54d47687e1a2d04ca1191be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It seems to me that if unrestricted chars are permitted, a simpler approach= would be to require tags to be specified as JSON strings.

    "a"."b"."/"

    That = approach supports any tag that is a legal JSON tag including dots.

    As an option, the encoding could permit the quotes to b= e omitted if the label only consisted of 'safe' characters. i.e. a-= z, A-Z, 0-9, -, _ and any UNICODE char > 255.


    On Wed, Sep 19, 2012 at 1:39 PM, James M Snell <jasnell@gmail.com><= /span> wrote:
    In general, I agree. While simple, the= existing JSON Pointer syntax is not particularly good and does not appear = to have any advantage over existing JavaScript syntax except, perhaps when = it comes to handling escaped characters (as Francis points out).=A0<= div>
    For example, JSON Pointer is currently used by the J= SON Patch specification to reference locations within a JSON document that = is being modified.=A0

    Supposing the fol= lowing example document,

    =A0 {
    =A0 =A0 "a": {<= /div>
    =A0 =A0 =A0 "b": = {
    =A0 =A0 =A0 =A0 &q= uot;c": "test",
    =A0 =A0 =A0 =A0 "d": [= 1,2,3]
    =A0 =A0 =A0 }=
    =A0 =A0 }
    =A0 }

    Using JSON Patch, I can describe a number of ch= anges to make to this document:

    =A0 [
    <= div>=A0 =A0 {"replace":&quo= t;/a/b/c", "value": "foobar" },
    <= font face=3D"courier new, monospace">=A0 =A0 {"move":"/a/b/c= ", "to": "/c" },
    =A0 =A0 {"move":"= /a/b/d/0, "to": "/a/b/c/1" }
    =A0 ]

    After applying thes= e changes, the document would be:

    =A0 {
    =A0 =A0 "a": {<= /div>
    =A0 =A0 =A0 "b": = {
    =A0 =A0 =A0 =A0 "d": [2,1,3]
    =A0 =A0 =A0 }
    <= font face=3D"courier new, monospace">=A0 =A0 },
    =A0 =A0 "c": &q= uot;foobar"
    =A0 }

    Using a dot syntax instead of the slashes demonstrates = that there is really nothing gained by the slashes.

    =A0 [
    =A0 =A0 {"replace":"a.b.c", "va= lue": "foobar" },
    =A0 =A0 {"move":"= a.b.c", "to": "c" },
    =A0 =A0 {"move":"a.b.d[0]",= "to": "a.b.d[1]" }
    =A0 ]

    With regards to oddly named members (e.g. "."= ), the existing JSON Pointer syntax does provide a bit of a simplicity adva= ntage.=A0For instance, given the following exceedingly awful but perfectly valid JS= ON document:

    =A0 {
    =A0 =A0 ".": {
    =A0 =A0 =A0 "/": {
    =A0 =A0 =A0 =A0 "": [&= quot;foo"]
    =A0 = =A0 =A0 }
    =A0 =A0 }<= /font>
    =A0 }

    The current JSON Pointer syntax for referencing= the "foo" value would be:

    =A0 /./~1//0=

    Using JavaScript notation, however, it wo= uld be something along the lines of...

    =A0 ["."]["/"][""= ][0]

    To be fair, both are ugly. The former= is less complicated lexically but the latter has the advantage of being di= rectly processable within multiple languages without any special handling. = For example:

    =A0 # Ruby
    =A0 require 'json'
    =A0 m =3D=A0JSON.parse('{".":{&qu= ot;/":{"":["foo"]}}}')
    =A0 m["."]["/"][&quo= t;"][0]

    It Just Works(tm), = right out of the box.=A0

    Where the JavaScript syntax falls down, of course, is w= hen the Pointer is to be used as a component of a URI... which, of course, = is one of the major motivating use cases for JSON Pointer in the first plac= e. Obviously, the square brackets [ and ] are explicitly required to be pct= -encoded within a URI, making the URI significantly less than human readabl= e.

    =A0 http://examp= le.org/foo.json#%5B%22.%22%5D%5B%22%2F%22%5D%5B%22%22%5D%5B0%5D<= /div>

    As opposed to:


    In short, there are obvious advantages and disa= dvantages to either syntax approach. Personally, I'd tend to favor the = JavaScript syntax because it's easier to process despite being more ver= bose, but the slash syntax is simple and get's the job done.=A0<= /div>

    - James





    On Wed, Sep 19, 2012 at 9:59 AM, Phillip Hallam-Bake= r <hallam@gmail.com> wrote:
    On W= ed, Sep 19, 2012 at 12:44 PM, Francis Galiegue <fgaliegue@gmail.com&= gt; wrote:
    On Wed, Sep 19, 2012 at 6:06 PM, Evan Prodromou <evan@status.net> wrote:
    > On 12-09-19 11:27 AM, Francis Galiegue wrote:
    >>
    >> JSON Pointer has been written like this on purpose. It is unambigu= ous,
    >> impervious to programming languages pecularities and encodings... = All
    >> advantages and none of the drawbacks :)
    >
    > It conspicuously lacks the advantage of being familiar for people who = know
    > JavaScript or JavaScript-based syntaxes like the MongoDB example I lin= ked
    > to.
    >

    Sure, but again, JSON Pointer has not been conceived with any
    programming language in mind. It, and JSON Reference, are the only two
    existing mechanisms able to unambiguously address any subset of any
    JSON value anywhere, by anyone, at any time.

    Tying this kind of specification to a programming language/a
    particular protocol/whatever would be shortsighted and
    counterproductive. And consider this:

    { "": { "/": { "~": [ 1, 2 ] } } }

    With JSON Pointer, you address the first element of the inner array
    using //~0/~1/0. This is even shorter to write than it is in
    JavaScript. _And_ more portable ;)

    Ju= st where is=A0JSON Pointer intended to be used? Who is using it?
    =
    Pretty much every modern programming language has adopted a = notation that uses dots for member extraction and square braces for array i= ndices. I don't see a particularly good reason to invent another way to= extract information from a data structure.

    In C# and Java the notation would be x.y[1].
    =
    There are different answers in C and C++ of course but I don= 't think anyone wants to copy from those examples at this point.

    Trying to use all dots comes up with the problem that x= and y are labels and an array index is a value so using a format like x.y.= 1 becomes difficult to interpret when using a variable for an index, x.y.z = is confusing as x and y are member names and z is an index. This gets even = worse when z is also a member name (and could lead to attacks).


    I can't see why I would want to hav= e a different syntax to extract elements after a data object has been JSON = encoded. What is the value of such a standard meant to be?

    This looks like an attempt to reinvent a wheel that has already been t= ried and tested.=A0

    ___________________________= ____________________
    apps-discuss mailing list
    apps-discuss@iet= f.org
    https://www.ietf.org/mailman/listinfo/apps-discuss





    --
    Website: http://hallambaker.com/

    --bcaec54d47687e1a2d04ca1191be-- From hallam@gmail.com Wed Sep 19 10:48:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AF921F8468 for ; Wed, 19 Sep 2012 10:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.942 X-Spam-Level: X-Spam-Status: No, score=-3.942 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZ1H2cJ-Icgv for ; Wed, 19 Sep 2012 10:48:03 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B97021F8467 for ; Wed, 19 Sep 2012 10:48:03 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1466943obb.31 for ; Wed, 19 Sep 2012 10:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/0upe970bfBnnuz0Q5O4VF8+pRqyIv/kZ2Khw8ZN1hE=; b=RTVgpd22xl62Tlr/rE9UbI9td28HxHCFmBsazPLDBVButQw8z7En969U3ZUVTeUIj+ IXuCmWBVYZO4DVHFtVmSkw2Dh4BXzHZ16PEFmy/OLgPYhLXU7PQcgxNii0Pf0975h/zE JNPAYGGP9cKaOmQkww/pl43z+3E/I7z34xuJh5bqm/80c4ZGIvOlzyPcnNiK8vAOCHiw 2lBFOcG1effZ5QCNTCqQ5Z5OCB+aGhl1lfenOnroomDoAolEp/OXVSp24iHizeK0xkmI o4GlCb+Y25PAIqPUTWjFDc/2/XKYb++4NBCQOL3n+gSU+DMROaHze6/j1pDm+RYZ6ZFJ XbrA== MIME-Version: 1.0 Received: by 10.60.170.138 with SMTP id am10mr3418088oec.115.1348076882772; Wed, 19 Sep 2012 10:48:02 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Wed, 19 Sep 2012 10:48:02 -0700 (PDT) In-Reply-To: References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> Date: Wed, 19 Sep 2012 13:48:02 -0400 Message-ID: From: Phillip Hallam-Baker To: Mark Nottingham Content-Type: multipart/alternative; boundary=bcaec517a4a0ba440b04ca119bcb Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 17:48:03 -0000 --bcaec517a4a0ba440b04ca119bcb Content-Type: text/plain; charset=ISO-8859-1 I have _a_ schema proposal that does just that but is not limited to JSON. I have mappings for C# and I have a tool chain that allows people to play around and extend the mapping for their own favorite language pretty easily. Seems to me that looking at all the 'REST' protocols that use url forms encoding for requests, a JSON schema that does not also address forms encoding is not going to be particularly useful. On Wed, Sep 19, 2012 at 1:44 PM, Mark Nottingham wrote: > > On 19/09/2012, at 10:39 AM, James M Snell wrote: > > > In short, there are obvious advantages and disadvantages to either > syntax approach. Personally, I'd tend to favor the JavaScript syntax > because it's easier to process despite being more verbose, but the slash > syntax is simple and get's the job done. > > So, this is a great conversation, but without someone sitting down and > writing the specification text, verifying that it behaves well in various > languages (so that we don't leave attractive nuisances around -- a > significant risk when you specify something that *looks* like it should > work "out of the box"), and proposes it to the group, I don't see where > it's going. > > Any takers? > > > -- > Mark Nottingham > http://www.mnot.net/ > > > > > -- Website: http://hallambaker.com/ --bcaec517a4a0ba440b04ca119bcb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have _a_ schema proposal that does just that but is not limited to JSON. = I have mappings for C# and I have a tool chain that allows people to play a= round and extend the mapping for their own favorite language pretty easily.=

    Seems to me that looking at all the 'REST' protocols= that use url forms encoding for requests, a JSON schema that does not also= address forms encoding is not going to be particularly useful.


    On Wed, Sep 19, 2012 at 1:44 PM, Mark No= ttingham <mnot@mnot.net> wrote:

    On 19/09/2012, at 10:39 AM, James M Snell <jasnell@gmail.com> wrote:

    > In short, there are obvious advantages and disadvantages to either syn= tax approach. Personally, I'd tend to favor the JavaScript syntax becau= se it's easier to process despite being more verbose, but the slash syn= tax is simple and get's the job done.

    So, this is a great conversation, but without someone sitting down an= d writing the specification text, verifying that it behaves well in various= languages (so that we don't leave attractive nuisances around -- a sig= nificant risk when you specify something that *looks* like it should work &= quot;out of the box"), and proposes it to the group, I don't see w= here it's going.

    Any takers?


    --
    Mark Nottingham
    http://www.mnot.net/=







    --
    Website: http://hallambaker.com/

    --bcaec517a4a0ba440b04ca119bcb-- From fgaliegue@gmail.com Wed Sep 19 10:48:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4017F21F8469 for ; Wed, 19 Sep 2012 10:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.483 X-Spam-Level: X-Spam-Status: No, score=-4.483 tagged_above=-999 required=5 tests=[AWL=1.116, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNzUmysSafl8 for ; Wed, 19 Sep 2012 10:48:53 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C25421F8467 for ; Wed, 19 Sep 2012 10:48:53 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1590457vcb.31 for ; Wed, 19 Sep 2012 10:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lkb8A5MjMTcTxzkD+QG/mDmqFZ+P+5/x+tuX32EJPi4=; b=c3HfodQ6yUMteJul4DvmayIKR4xWIN3h2/n/kb8p/tDP0D32LJDZlK2z/Pu+s7yQh3 Yq5dLZnnL6ghKdnzrGGUi9YoEP8nvoXI/6VLjBOenz67uapj8mhxLynkTOiuKN8dpKHR sk78YD3MvdCFT/a4nb/d9+y6Os+hii8XFXhLggSXEVwN9TMSqOfi+sh7tP88J6br7FLh 2/tNaFJLtFhVClxSqh0zS+lmOH/p8mVLWpNKymJEJ8bkuemap0U7qpWfCJDsjcfDxUon hlJFmFDMgboxgWhUu4Cl0RyoZiXZqNgmzKMATNEFtNaPzX8GKJ24z/FPQoQeJkAXIyBH 0A6Q== MIME-Version: 1.0 Received: by 10.220.16.9 with SMTP id m9mr2281840vca.72.1348076932769; Wed, 19 Sep 2012 10:48:52 -0700 (PDT) Received: by 10.52.23.103 with HTTP; Wed, 19 Sep 2012 10:48:52 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 19:48:52 +0200 Message-ID: From: Francis Galiegue To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 17:48:54 -0000 On Wed, Sep 19, 2012 at 7:30 PM, Phillip Hallam-Baker wr= ote: > One of the biggest mistakes that was made in the XML world was to allow o= ne > group of authors to develop a specification and call it 'XML Schema'. I > think we are at risk of making the same mistake here. > > The more I hear about this effort, the less I like it. The approach seems= to > be needlessly complex for a start. There should be no need to have a poin= ter > structure in a modern data modelling language, none. C# and Java don't us= e > pointers, so why are they needed in JSON Schema? > OK, sorry, but that is a _very limited view of JSON Schema_. JSON Schema was there _far_before the GitHub group came into the picture, and FYI, JSON Reference and JSON Pointer came into light _before the GitHub group took over_. Go read both the JSON Reference and JSON Pointer I-Ds: do you see my name in them as an author? NO. Only as a side note for JSON Reference because I highlighted the dangers of a loop. And please get a grip: before you say the approach is "needlessly complex", have a look at what is being done. It is _precisely_ because JSON Schema needs input that no drafts are submitted at the moment. They are still in the process of being written. And JSON Schema, even in its latest incarnation, is used: consider the Google discovery API. > > Using a schema to develop a protocol is a very good idea but each and eve= ry > schema language I have had to use has been botched. XML schema has two > separate type systems. ASN.1 schema is arcane. We must not let that happe= n > to JSON. > Go read the proposed specs. Do you see ASN.1 anywhere? Link: https://github.com/json-schema/json-schema > It should be possible to have a schema language that is essentially langu= age > neutral and encoding neutral. Yes, and that is _precisely_ what the GitHub group is aiming for. And you contradict yourself ohsomuch by saying that dot should be preferred to solidus, for one. > Pretty much every programming language in > current use has the same set of intrinsic types (bytes, int16, int32, int= 64, > strings (unicode), chars (unicode), real32, real64, boolean), and at leas= t > one form of enumerated collection (arrays, lists, sets). For protocol des= ign > it is very useful to add in standard representations for Binary and DateT= ime > intrinsict types as base64 encoded strings are easier to deal with than > arrays of decimal bytes and we already have an IETF string representation > for time. > You obvioulsy haven't read neither the past nor the present. [...] > > Where the XML Schema effort went wrong was they tried to support every > feature of DTDs and they gave the schema designer the ability to map a da= ta > structure onto multiple different encodings. Which is pretty weird. Makin= g > standards is the process of making design choices that don't matter. > Providing multiple ways to serialize the same data structure is a harmful > option. > Oh dear. You really HAVE NOT read anything of the work being done by the GitHub organization, have you? Schema, Pointer. Those are just names. Please go carefully read the current productions at said organization. I certainly DO NOT want to replicate XSD. XSD and LSD have only one letter apart, and I, and the GitHub organization, DO NOT want to go there. Sorry for being so blunt, but I cannot stand this kind of "feedback" from people who DO NOT EVEN TRY AND SEE WHAT IS BEING DONE. --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From pbryan@anode.ca Wed Sep 19 10:55:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF4721F8487 for ; Wed, 19 Sep 2012 10:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pF9fN0YTNltD for ; Wed, 19 Sep 2012 10:55:40 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 07A3321F84F0 for ; Wed, 19 Sep 2012 10:55:40 -0700 (PDT) Received: from [10.71.13.58] (adsl-75-55-201-218.dsl.pltn13.sbcglobal.net [75.55.201.218]) by maple.anode.ca (Postfix) with ESMTPSA id E5DAD65B1; Wed, 19 Sep 2012 17:55:38 +0000 (UTC) Message-ID: <1348077337.2880.3.camel@polyglot> From: "Paul C. Bryan" To: Evan Prodromou Date: Wed, 19 Sep 2012 10:55:37 -0700 In-Reply-To: <5059ED76.50202@status.net> References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> Content-Type: multipart/alternative; boundary="=-k1aeuM86YBr9Qk1oEL9K" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 17:55:41 -0000 --=-k1aeuM86YBr9Qk1oEL9K Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit For fun reading—and a bit of a history lesson—see http://tools.ietf.org/html/draft-pbryan-json-patch-00 and check out its proposed path notation. Path/pointer notation was then discussed a fair amount, and slash notation would up being favoured over the dot/bracket notation. Paul On Wed, 2012-09-19 at 12:06 -0400, Evan Prodromou wrote: > On 12-09-19 11:27 AM, Francis Galiegue wrote: > > JSON Pointer has been written like this on purpose. It is unambiguous, > > impervious to programming languages pecularities and encodings... All > > advantages and none of the drawbacks :) > It conspicuously lacks the advantage of being familiar for people who > know JavaScript or JavaScript-based syntaxes like the MongoDB example I > linked to. > > That said, I appreciate the response, and I'm just glad the subject has > been discussed. > > -Evan > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-k1aeuM86YBr9Qk1oEL9K Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit For fun reading—and a bit of a history lesson—see http://tools.ietf.org/html/draft-pbryan-json-patch-00 and check out its proposed path notation. Path/pointer notation was then discussed a fair amount, and slash notation would up being favoured over the dot/bracket notation. 

    Paul

    On Wed, 2012-09-19 at 12:06 -0400, Evan Prodromou wrote: 
    On 12-09-19 11:27 AM, Francis Galiegue wrote:
> JSON Pointer has been written like this on purpose. It is unambiguous, 
> impervious to programming languages pecularities and encodings... All 
> advantages and none of the drawbacks :) 
It conspicuously lacks the advantage of being familiar for people who 
know JavaScript or JavaScript-based syntaxes like the MongoDB example I 
linked to.

That said, I appreciate the response, and I'm just glad the subject has 
been discussed.

-Evan

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

    --=-k1aeuM86YBr9Qk1oEL9K-- From hallam@gmail.com Wed Sep 19 10:59:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A3211E8091 for ; Wed, 19 Sep 2012 10:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.932 X-Spam-Level: X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2ncg-a8s1ie for ; Wed, 19 Sep 2012 10:59:13 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCA711E808A for ; Wed, 19 Sep 2012 10:59:13 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1478342obb.31 for ; Wed, 19 Sep 2012 10:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SiXG+JLbhevXI15aXYqQyG4lQ78AzZYwyOZDew1j/o4=; b=00c7Nwrw93JJy+8fGhd45GCGib30VyKhcmzBYZrUmwE2MTzS95omPcbF90b/dXgVfV R/kEnZTPZ8wUMMOPXfnCTR82RQH4uwKFsbsS/x62FH5NlumbuOmaGST5+XP+YawPyi5I 3k0nrwjbs6StPhfceUK3jgKW++ViroC1zk9cTqdq/4I1Hdch7N3kkmGkXK7+Bn4ARNqt 9LOoGWUwXAhHNJUFinfUf7omtRzuPsJ9eB14nvn3nmRpd5Mnr1LUieI1lHs3G76k+Lw7 7iw1p3oDsu9ChvD5lxiB4aBTx7qxHNx1sCUCexg5IOUs848IYbeLUiove+NPVbIrGSHP PWlg== MIME-Version: 1.0 Received: by 10.60.11.34 with SMTP id n2mr3643431oeb.18.1348077552824; Wed, 19 Sep 2012 10:59:12 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Wed, 19 Sep 2012 10:59:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 13:59:12 -0400 Message-ID: From: Phillip Hallam-Baker To: Francis Galiegue Content-Type: multipart/alternative; boundary=e89a8fb206e6aa717604ca11c30f Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 17:59:14 -0000 --e89a8fb206e6aa717604ca11c30f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You keep raising JSON Schema here referring to it as if it was a done deal. In fact you just told me that JSON Pointer is needed by JSON Schema which is why I said, whooa, if you need a pointer spec for a schema language then you are doing it wrong. My observation about XML Schema and ASN.1 schema is that the groups producing them should not have been allowed a monopoly. The ASN.1 case is actually understandable as it was a schema design group that developed the encodings. But even so it was design by a committee. As for 'Github', isn't that a place where people start up communities? So calling something the Github community makes it sound as if you have the endorsement of GitHub which I am pretty sure you don't. In fact that is precisely what my complaint was about. I don't think you should be aggrandizing yourself by claiming the endorsement of the JSON community or the GitHub community. The only organization that should be accrediting a JSON Schema or JSON Pointer is the standards body for JSON which seems to now be IETF since ECMA seem to be citing the IETF RFC as normative. Until there is an IETF working group set up to develop one you should call it something else. On Wed, Sep 19, 2012 at 1:48 PM, Francis Galiegue wrot= e: > On Wed, Sep 19, 2012 at 7:30 PM, Phillip Hallam-Baker > wrote: > > One of the biggest mistakes that was made in the XML world was to allow > one > > group of authors to develop a specification and call it 'XML Schema'. I > > think we are at risk of making the same mistake here. > > > > The more I hear about this effort, the less I like it. The approach > seems to > > be needlessly complex for a start. There should be no need to have a > pointer > > structure in a modern data modelling language, none. C# and Java don't > use > > pointers, so why are they needed in JSON Schema? > > > > OK, sorry, but that is a _very limited view of JSON Schema_. > > JSON Schema was there _far_before the GitHub group came into the > picture, and FYI, JSON Reference and JSON Pointer came into light > _before the GitHub group took over_. Go read both the JSON Reference > and JSON Pointer I-Ds: do you see my name in them as an author? NO. > Only as a side note for JSON Reference because I highlighted the > dangers of a loop. > > And please get a grip: before you say the approach is "needlessly > complex", have a look at what is being done. It is _precisely_ because > JSON Schema needs input that no drafts are submitted at the moment. > They are still in the process of being written. > > And JSON Schema, even in its latest incarnation, is used: consider the > Google discovery API. > > > > > Using a schema to develop a protocol is a very good idea but each and > every > > schema language I have had to use has been botched. XML schema has two > > separate type systems. ASN.1 schema is arcane. We must not let that > happen > > to JSON. > > > > Go read the proposed specs. Do you see ASN.1 anywhere? > > Link: https://github.com/json-schema/json-schema > > > It should be possible to have a schema language that is essentially > language > > neutral and encoding neutral. > > Yes, and that is _precisely_ what the GitHub group is aiming for. And > you contradict yourself ohsomuch by saying that dot should be > preferred to solidus, for one. > > > Pretty much every programming language in > > current use has the same set of intrinsic types (bytes, int16, int32, > int64, > > strings (unicode), chars (unicode), real32, real64, boolean), and at > least > > one form of enumerated collection (arrays, lists, sets). For protocol > design > > it is very useful to add in standard representations for Binary and > DateTime > > intrinsict types as base64 encoded strings are easier to deal with than > > arrays of decimal bytes and we already have an IETF string representati= on > > for time. > > > > You obvioulsy haven't read neither the past nor the present. > > [...] > > > > Where the XML Schema effort went wrong was they tried to support every > > feature of DTDs and they gave the schema designer the ability to map a > data > > structure onto multiple different encodings. Which is pretty weird. > Making > > standards is the process of making design choices that don't matter. > > Providing multiple ways to serialize the same data structure is a harmf= ul > > option. > > > > Oh dear. You really HAVE NOT read anything of the work being done by > the GitHub organization, have you? > > Schema, Pointer. Those are just names. Please go carefully read the > current productions at said organization. I certainly DO NOT want to > replicate XSD. XSD and LSD have only one letter apart, and I, and the > GitHub organization, DO NOT want to go there. > > Sorry for being so blunt, but I cannot stand this kind of "feedback" > from people who DO NOT EVEN TRY AND SEE WHAT IS BEING DONE. > > -- > Francis Galiegue, fgaliegue@gmail.com > JSON Schema: https://github.com/json-schema > "It seems obvious [...] that at least some 'business intelligence' > tools invest so much intelligence on the business side that they have > nothing left for generating SQL queries" (St=E9phane Faroult, in "The > Art of SQL", ISBN 0-596-00894-5) > --=20 Website: http://hallambaker.com/ --e89a8fb206e6aa717604ca11c30f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You keep raising JSON Schema here referring to it as if it was a done deal.= In fact you just told me that JSON Pointer is needed by JSON Schema which = is why I said, whooa, if you need a pointer spec for a schema language then= you are doing it wrong.

    My observation about XML Schema and ASN.1 schema is that the= groups producing them should not have been allowed a monopoly. The ASN.1 c= ase is actually understandable as it was a schema design group that develop= ed the encodings. But even so it was design by a committee.

    As for 'Github', isn't that a place where p= eople start up communities? So calling something the Github community makes= it sound as if you have the endorsement of GitHub which I am pretty sure y= ou don't. In fact that is precisely what my complaint was about. I don&= #39;t think you should be aggrandizing yourself by claiming the endorsement= of the JSON community or the GitHub community.=A0

    The only organization that should be accrediting a JSON= Schema or JSON Pointer is the standards body for JSON which seems to now b= e IETF since ECMA seem to be citing the IETF RFC as normative.

    Until there is an IETF working group set up to develop one y= ou should call it something else.


    On = Wed, Sep 19, 2012 at 1:48 PM, Francis Galiegue <fgaliegue@gmail.com&= gt; wrote:
    On Wed, Sep 19, 2012 at 7:= 30 PM, Phillip Hallam-Baker <hallam@= gmail.com> wrote:
    > One of the biggest mistakes that was made in the XML world was to allo= w one
    > group of authors to develop a specification and call it 'XML Schem= a'. I
    > think we are at risk of making the same mistake here.
    >
    > The more I hear about this effort, the less I like it. The approach se= ems to
    > be needlessly complex for a start. There should be no need to have a p= ointer
    > structure in a modern data modelling language, none. C# and Java don&#= 39;t use
    > pointers, so why are they needed in JSON Schema?
    >

    OK, sorry, but that is a _very limited view of JSON Schema_.

    JSON Schema was there _far_before the GitHub group came into the
    picture, and FYI, JSON Reference and JSON Pointer came into light
    _before the GitHub group took over_. Go read both the JSON Reference
    and JSON Pointer I-Ds: do you see my name in them as an author? NO.
    Only as a side note for JSON Reference because I highlighted the
    dangers of a loop.

    And please get a grip: before you say the approach is "needlessly
    complex", have a look at what is being done. It is _precisely_ because=
    JSON Schema needs input that no drafts are submitted at the moment.
    They are still in the process of being written.

    And JSON Schema, even in its latest incarnation, is used: consider the
    Google discovery API.

    >
    > Using a schema to develop a protocol is a very good idea but each and = every
    > schema language I have had to use has been botched. XML schema has two=
    > separate type systems. ASN.1 schema is arcane. We must not let that ha= ppen
    > to JSON.
    >

    Go read the proposed specs. Do you see ASN.1 anywhere?

    Link: https://github.com/json-schema/json-schema

    > It should be possible to have a schema language that is essentially la= nguage
    > neutral and encoding neutral.

    Yes, and that is _precisely_ what the GitHub group is aiming for. And=
    you contradict yourself ohsomuch by saying that dot should be
    preferred to solidus, for one.

    > Pretty much every programming language in
    > current use has the same set of intrinsic types (bytes, int16, int32, = int64,
    > strings (unicode), chars (unicode), real32, real64, boolean), and at l= east
    > one form of enumerated collection (arrays, lists, sets). For protocol = design
    > it is very useful to add in standard representations for Binary and Da= teTime
    > intrinsict types as base64 encoded strings are easier to deal with tha= n
    > arrays of decimal bytes and we already have an IETF string representat= ion
    > for time.
    >

    You obvioulsy haven't read neither the past nor the present.

    [...]
    >
    > Where the XML Schema effort went wrong was they tried to support every=
    > feature of DTDs and they gave the schema designer the ability to map a= data
    > structure onto multiple different encodings. Which is pretty weird. Ma= king
    > standards is the process of making design choices that don't matte= r.
    > Providing multiple ways to serialize the same data structure is a harm= ful
    > option.
    >

    Oh dear. You really HAVE NOT read anything of the work being done by<= br> the GitHub organization, have you?

    Schema, Pointer. Those are just names. Please go carefully read the
    current productions at said organization. I certainly DO NOT want to
    replicate XSD. XSD and LSD have only one letter apart, and I, and the
    GitHub organization, DO NOT want to go there.

    Sorry for being so blunt, but I cannot stand this kind of "feedback&qu= ot;
    from people who DO NOT EVEN TRY AND SEE WHAT IS BEING DONE.

    --
    Francis Galiegue, fgaliegue@gmail.co= m
    JSON Schema: h= ttps://github.com/json-schema
    "It seems obvious [...] that at least some 'business intelligence&= #39;
    tools invest so much intelligence on the business side that they have
    nothing left for generating SQL queries" (St=E9phane Faroult, in "= ;The
    Art of SQL", ISBN 0-596-00894-5)



    --
    = Website: http://hallambaker.com/
    --e89a8fb206e6aa717604ca11c30f-- From pbryan@anode.ca Wed Sep 19 11:03:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7A621F84CF for ; Wed, 19 Sep 2012 11:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCa0wmOzHa74 for ; Wed, 19 Sep 2012 11:03:42 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 2561E21F8667 for ; Wed, 19 Sep 2012 11:03:42 -0700 (PDT) Received: from [10.71.13.58] (adsl-75-55-201-218.dsl.pltn13.sbcglobal.net [75.55.201.218]) by maple.anode.ca (Postfix) with ESMTPSA id F28BA65B1; Wed, 19 Sep 2012 18:03:39 +0000 (UTC) Message-ID: <1348077816.2880.9.camel@polyglot> From: "Paul C. Bryan" To: James M Snell Date: Wed, 19 Sep 2012 11:03:36 -0700 In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="=-pDgzCgmCs+JHnxIAqIU3" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 18:03:45 -0000 --=-pDgzCgmCs+JHnxIAqIU3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Check out the op/path/value notation in http://tools.ietf.org/html/draft-pbryan-json-patch-00 and note its similarity to what you're proposing. Consensus was that separate op/path was too verbose, and in response was collapsed into operator becoming member name. I suggest that the MUST definitely applies to the client submitting the patch document. I don't think that the server MUST ensure that the client conformed to the spec. If the client constructs something like: { "add": "/some/path", "remove": "/some/other/path", "value": "some value" }, then the client is clearly violating the spec, the the results will be unpredictable on the server. If you want your server to be paranoid, then it should account for all members in the operation object and reject non-conformance, but I don't expect every server to do so. Paul On Wed, 2012-09-19 at 08:09 -0700, James M Snell wrote: > An array based approach carries along many of it's own issues, > especially if we do decide to extend things later on. What likely > would have been ideal (albeit more verbose) are distinct "op" and > "ref" codes to identify the patch operation and json-pointer -- e.g. > {"op":"add", "ref":"/a/b/c", "value": "123"}. This helps us to enforce > the single operation rule, simplifies processing and maintains better > long term extensibility at the cost of a few extra bits on the wire. > > > > - James > > > On Wed, Sep 19, 2012 at 7:52 AM, Manger, James H > wrote: > > The consensus sounds like "MUST understand everything"; no > ignoring unrecognized fields. That is ok, but we haven't > picked a good syntax to match that rule. > > The "obvious" way to parse a patch operation object (eg > {"add":"/foo","value":"bar"}) is to: > > 1. Loop through the keys in the object until you find one that > is in the set of known operations: "add", "remove", "test"… > > 2. Extract the elements associated with that specific > operation, eg the "value" for an "add" operation. > > That "obvious" process will not detect two operations in an > object, or unexpected extra fields. Implementations will have > to do non-trivial extra work to make those checks. Many will > not do that, or will do it incorrectly, simply because valid > cases will work regardless of that extra code. The result is > likely to be security problems. For instance, one > implementation parsing {"value":"bar", "add":"/foo", > "remove":"/foo"} will see an "add" operation, another will see > a "remove" operation (and a third will report an error), > simply based on how implementation-specific string hash codes > are calculated. > > The nice thing about a JSON object is that you can add all > sorts of extra elements without affecting existing elements. > Given we explicitly don't want this feature, perhaps a better > syntax would be a JSON array: starting with the operation > name, then the operation-specific parameters. > > For example: > instead of {"add":"/foo", "value":"bar"} > have ["add", "/foo", "bar"] > > Duplicate operations cannot occur (there can only be one first > element in an array). Preventing unexpected parameters is as > simple as ensuring the array is the right length for the > specific operation. > > The array approach should also be simpler to map to a > per-operation function call with arguments. > > -- > James Manger > > > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of Mark Nottingham > > Sent: Wednesday, 19 September 2012 9:56 AM > > To: James M Snell > > Cc: apps-discuss@ietf.org > > Subject: Re: [apps-discuss] JSON Patch: extensibility > > > > Going with: > > > > > It is an error condition if an operation object does > not contain an > > > operation member, contains an operation member other > than one of > > > those defined by this document, or more than one > operation member. > > > > > > Likewise, it is an error condition if an operation > object has a > > > member that is not explicitly allowed by this document. > > > > > > On 18/09/2012, at 10:49 AM, James M Snell > wrote: > > > > > +1 on having it be an error condition. > > > > > > Because of the potentially significant negative impact > that an > > improperly applied patch operation could have on the target > resource, > > any not-understood operation, object or member MUST result > in an error > > condition being reported and the patch rejected. > > > > > > - James > > > > > > On Tue, Sep 18, 2012 at 10:42 AM, Paul C. Bryan > > > wrote: > > > On Tue, 2012-09-18 at 10:27 -0700, Mark Nottingham wrote: > > > > > >> James is right that the document is currently silent > about extra > > properties on the operation. Do people have strong feelings > about > > whether this should result in an error condition, or be > ignored? > > > > > > It was definitely intended to be an error condition. On > this point, > > the specification reads: > > > > > > "It is an error condition if an operation object > contains no > > recognized operation member or more than one operation > member." > > > > > > I suppose it would be stronger to say something like: > > > > > > "It is an error condition if an operation object does > not contain > > an operation member documented herein, or more than one > operation > > member." > > > > > > Paul > > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-pDgzCgmCs+JHnxIAqIU3 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Check out the op/path/value notation in http://tools.ietf.org/html/draft-pbryan-json-patch-00 and note its similarity to what you're proposing. Consensus was that separate op/path was too verbose, and in response was collapsed into operator becoming member name.

    I suggest that the MUST definitely applies to the client submitting the patch document. I don't think that the server MUST ensure that the client conformed to the spec. If the client constructs something like: { "add": "/some/path", "remove": "/some/other/path", "value": "some value" }, then the client is clearly violating the spec, the the results will be unpredictable on the server. If you want your server to be paranoid, then it should account for all members in the operation object and reject non-conformance, but I don't expect every server to do so.

    Paul

    On Wed, 2012-09-19 at 08:09 -0700, James M Snell wrote:
    An array based approach carries along many of it's own issues, especially if we do decide to extend things later on. What likely would have been ideal (albeit more verbose) are distinct "op" and "ref" codes to identify the patch operation and json-pointer -- e.g. {"op":"add", "ref":"/a/b/c", "value": "123"}. This helps us to enforce the single operation rule, simplifies processing and maintains better long term extensibility at the cost of a few extra bits on the wire. 


    - James

    On Wed, Sep 19, 2012 at 7:52 AM, Manger, James H <James.H.Manger@team.telstra.com> wrote:
    The consensus sounds like "MUST understand everything"; no ignoring unrecognized fields. That is ok, but we haven't picked a good syntax to match that rule.

    The "obvious" way to parse a patch operation object (eg {"add":"/foo","value":"bar"}) is to:

    1. Loop through the keys in the object until you find one that is in the set of known operations: "add", "remove", "test"…

    2. Extract the elements associated with that specific operation, eg the "value" for an "add" operation.

    That "obvious" process will not detect two operations in an object, or unexpected extra fields. Implementations will have to do non-trivial extra work to make those checks. Many will not do that, or will do it incorrectly, simply because valid cases will work regardless of that extra code. The result is likely to be security problems. For instance, one implementation parsing {"value":"bar", "add":"/foo", "remove":"/foo"} will see an "add" operation, another will see a "remove" operation (and a third will report an error), simply based on how implementation-specific string hash codes are calculated.

    The nice thing about a JSON object is that you can add all sorts of extra elements without affecting existing elements. Given we explicitly don't want this feature, perhaps a better syntax would be a JSON array: starting with the operation name, then the operation-specific parameters.

    For example:
    instead of  {"add":"/foo", "value":"bar"}
    have        ["add", "/foo", "bar"]

    Duplicate operations cannot occur (there can only be one first element in an array). Preventing unexpected parameters is as simple as ensuring the array is the right length for the specific operation.

    The array approach should also be simpler to map to a per-operation function call with arguments.

    --
    James Manger


    > -----Original Message-----
    > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
    > bounces@ietf.org] On Behalf Of Mark Nottingham
    > Sent: Wednesday, 19 September 2012 9:56 AM
    > To: James M Snell
    > Cc: apps-discuss@ietf.org
    > Subject: Re: [apps-discuss] JSON Patch: extensibility
    >
    > Going with:
    >
    > >    It is an error condition if an operation object does not contain an
    > >    operation member, contains an operation member other than one of
    > >    those defined by this document, or more than one operation member.
    > >
    > >    Likewise, it is an error condition if an operation object has a
    > >    member that is not explicitly allowed by this document.
    >
    >
    > On 18/09/2012, at 10:49 AM, James M Snell <jasnell@gmail.com> wrote:
    >
    > > +1 on having it be an error condition.
    > >
    > > Because of the potentially significant negative impact that an
    > improperly applied patch operation could have on the target resource,
    > any not-understood operation, object or member MUST result in an error
    > condition being reported and the patch rejected.
    > >
    > > - James
    > >
    > > On Tue, Sep 18, 2012 at 10:42 AM, Paul C. Bryan <pbryan@anode.ca>
    > wrote:
    > > On Tue, 2012-09-18 at 10:27 -0700, Mark Nottingham wrote:
    > >
    > >> James is right that the document is currently silent about extra
    > properties on the operation. Do people have strong feelings about
    > whether this should result in an error condition, or be ignored?
    > >
    > > It was definitely intended to be an error condition. On this point,
    > the specification reads:
    > >
    > >     "It is an error condition if an operation object contains no
    > recognized operation member or more than one operation member."
    > >
    > > I suppose it would be stronger to say something like:
    > >
    > >     "It is an error condition if an operation object does not contain
    > an operation member documented herein, or more than one operation
    > member."
    > >
    > > Paul




    _______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

    --=-pDgzCgmCs+JHnxIAqIU3-- From jasnell@gmail.com Wed Sep 19 11:05:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84B621F867F for ; Wed, 19 Sep 2012 11:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GOhpYM1+m3J for ; Wed, 19 Sep 2012 11:05:37 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B43AB21F8681 for ; Wed, 19 Sep 2012 11:05:36 -0700 (PDT) Received: by weyx48 with SMTP id x48so806333wey.31 for ; Wed, 19 Sep 2012 11:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fxfO3Bt4iPXxfFSKufBcmlhO7j+YlfsIAiG7upRBiQE=; b=HX+uOrHGat/45FIJLCiGEcZr4kjmwGg6Xuvik87kEmN7Z2LEf8Ga9Jj7e2Vzlyt4n7 C9Mwg1I4soCjj+Z6odTGHje8POB7GFvgvOXQu1Kfk+I2i6W236x/KMhckb5gnORCseh4 tJsZ5bIaS2mzD0TE/iiLdMCTkcDSzKDgyRnGOVaseiU3L1855ovv2bVkZoYKLTPiUyeN EM3tzVy5rvRlEXxuS7FrEpECEH6w7oLY+R6HJxUrl0WmcnBhimHXMd/X8fj1vTMWISjD IFyOuGJ+dZFMGJQxAx7hxlt/F0HlrQi9fyJMFMvp+/KeDUhMeJur0N0hW1BKoUUNMO42 nuHw== Received: by 10.180.99.196 with SMTP id es4mr217214wib.18.1348077929478; Wed, 19 Sep 2012 11:05:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Wed, 19 Sep 2012 11:05:09 -0700 (PDT) In-Reply-To: <1348077337.2880.3.camel@polyglot> References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> <1348077337.2880.3.camel@polyglot> From: James M Snell Date: Wed, 19 Sep 2012 11:05:09 -0700 Message-ID: To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=f46d044283701dbb8304ca11dae3 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 18:05:38 -0000 --f46d044283701dbb8304ca11dae3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paul, do you happen to have a link referencing the path/pointer discussion readily available? I (and I'm sure others) would appreciate being able to review what specific arguments were made. I could go hunting for them myself but figured it might be faster just to ask. On Wed, Sep 19, 2012 at 10:55 AM, Paul C. Bryan wrote: > ** > For fun reading=E2=80=94and a bit of a history lesson=E2=80=94see > http://tools.ietf.org/html/draft-pbryan-json-patch-00 and check out its > proposed path notation. Path/pointer notation was then discussed a fair > amount, and slash notation would up being favoured over the dot/bracket > notation. > > Paul > > > On Wed, 2012-09-19 at 12:06 -0400, Evan Prodromou wrote: > > On 12-09-19 11:27 AM, Francis Galiegue wrote: > > JSON Pointer has been written like this on purpose. It is unambiguous, > > impervious to programming languages pecularities and encodings... All > > advantages and none of the drawbacks :) > It conspicuously lacks the advantage of being familiar for people who > know JavaScript or JavaScript-based syntaxes like the MongoDB example I > linked to. > > That said, I appreciate the response, and I'm just glad the subject has > been discussed. > > -Evan > > _______________________________________________ > apps-discuss mailing listapps-discuss@ietf.orghttps://www.ietf.org/mailma= n/listinfo/apps-discuss > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d044283701dbb8304ca11dae3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paul, do you happen to have a link ref= erencing the path/pointer discussion readily available? I (and I'm sure= others) would appreciate being able to review what specific arguments were= made. I could go hunting for them myself but figured it might be faster ju= st to ask.

    On Wed, Sep 19, 2012 at 10:55 AM, Paul C. Br= yan <pbryan@anode.ca> wrote:
    =20 =20
    For fun reading=E2=80=94and a bit of a history lesson=E2=80=94see http://tools.ietf.org/html/draft-pbryan-json-patch-00 and check out i= ts proposed path notation. Path/pointer notation was then discussed a fair = amount, and slash notation would up being favoured over the dot/bracket not= ation.=C2=A0

    Paul


    On Wed, 2012-09-19 at 12:06 -0400, Evan Prodromou wrote: 
    On 12-09-19 11:27 AM, Francis Galiegue wrote:
> JSON Pointer has been written like this on purpose. It is unambiguous,=
=20
> impervious to programming languages pecularities and encodings... All=
=20
> advantages and none of the drawbacks :)=20
It conspicuously lacks the advantage of being familiar for people who=20
know JavaScript or JavaScript-based syntaxes like the MongoDB example I=20
linked to.

That said, I appreciate the response, and I'm just glad the subject has=
=20
been discussed.

-Evan

_______________________________________________
apps-discuss mailing list
apps-discuss@iet=
f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss


    --f46d044283701dbb8304ca11dae3-- From fgaliegue@gmail.com Wed Sep 19 11:09:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF4C21F8685 for ; Wed, 19 Sep 2012 11:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.607 X-Spam-Level: X-Spam-Status: No, score=-3.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iw0EwTHeMNP for ; Wed, 19 Sep 2012 11:09:18 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F56521F8681 for ; Wed, 19 Sep 2012 11:09:18 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1617589vcb.31 for ; Wed, 19 Sep 2012 11:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3g2LXSCgP9l1zvsQgK35Yf6Qhe9sBpKdiyvCBiY+Un0=; b=NS9gQ0IdwfgB4HeIU9wd0e4xyb3xZnE/4mv/0t3BPpHIb5M+ebbe9wLahzWR+2FwkL c5GM8BOtEL+seQpH2yCkn6tQEDG1lev7GAsDzYUs77aJmC0p8j/di539CQ7v3fx4R1cu C3BPDSz4qQcO9v6XcLCLhy8QAkhG5H7FyGaY0AEd9/ncqp4pLH3r17jILhITq0AJBn2S hmqYTmcGtz0S91UbZUlybullcabbFtmqpPO2E/5voKwgVHdLvsv4T8ewh0nQEFcsLJmD V8XCbyRihFr8FlF3xsppe/awfp493dFgKHziNz4vWkY1M2/ybtR3kIf9olZ87E/aX5En s5Rg== MIME-Version: 1.0 Received: by 10.52.88.18 with SMTP id bc18mr1902146vdb.99.1348078158013; Wed, 19 Sep 2012 11:09:18 -0700 (PDT) Received: by 10.52.23.103 with HTTP; Wed, 19 Sep 2012 11:09:17 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 20:09:17 +0200 Message-ID: From: Francis Galiegue To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 18:09:19 -0000 On Wed, Sep 19, 2012 at 7:59 PM, Phillip Hallam-Baker wr= ote: > You keep raising JSON Schema here referring to it as if it was a done dea= l. > In fact you just told me that JSON Pointer is needed by JSON Schema which= is > why I said, whooa, if you need a pointer spec for a schema language then = you > are doing it wrong. > What I say is that an unambiguous way of accessing ANY path in a JSON value, whatever that value is, is needed, and JSON Pointer is that. Try as hard as you want, I fail to see how you can do any better. I didn't even design that. Out of the light of pure reason, JSON Pointer _makes sense_. [...] > As for 'Github', isn't that a place where people start up communities? So > calling something the Github community makes it sound as if you have the > endorsement of GitHub which I am pretty sure you don't. In fact that is > precisely what my complaint was about. I don't think you should be > aggrandizing yourself by claiming the endorsement of the JSON community o= r > the GitHub community. > > The only organization that should be accrediting a JSON Schema or JSON > Pointer is the standards body for JSON which seems to now be IETF since E= CMA > seem to be citing the IETF RFC as normative. > > Until there is an IETF working group set up to develop one you should cal= l > it something else. > Read about the history of JSON Schema. Please. I have NEVER, EVER, pretended to have endorsement from ANYONE. The GitHub JSON Schema group is an ad-hoc organization aimed at reviving JSON Schema, and that is all there is to it. And the principles behind this ad-hoc organization are: collect existing uses (and there are); propose solutions (and there are); reach a consensus (in process); AND THEN submit to the IETF. Did I ever claim being backed by GitHub? No. Did I ever claim being backed by the IETF (what a foolish notion to begin with)? No. Do I claim to be working to get JSON Schema into something to be considered for an I-D (note, an I-D)? Definitely, yes. On behalf of all people involved with this organization, which is an ad-ho group of VOLUNTEERS. But, damnit, I have known the subject for long enough to KNOW, just KNOW, that addressing JSON today, in an unambiguous way, involves two things: JSON Reference, and JSON Pointer. However "unlikeable" JSON Pointer may look to people who are too used to JavaScript. JSON is NOT Javascript. --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From jasnell@gmail.com Wed Sep 19 11:21:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB8F21F86A3 for ; Wed, 19 Sep 2012 11:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cylk2B1Hgxyv for ; Wed, 19 Sep 2012 11:21:49 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C82221F8667 for ; Wed, 19 Sep 2012 11:21:46 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so711801wgb.13 for ; Wed, 19 Sep 2012 11:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5QQjgmn2TlFhmV91H8fyPekeiWSIPcraI4mlfa47ABA=; b=y0uiLKRBFk65HiUnpqMvbzTxGZLcm9iVJFNyJWNpFu1emdjI+33+s4G8KPXiFe++sB Ne1olRgDSRKtRoKFFWxPM6WZdtgnzCE62+us5lFrPMRZ+pJdcGBTjq0i+lkcm5JuVm57 UEXXTz1nLMtlXo/hLvXufAtoS+fCJ52erDUGeOlHjbGKRaClRHphtP1HVBCgDk5WE7dR NCb67k5sD+4Uh6xnwbYPSaONHQHP2TvcvX/sxxV/S0vUobxr19FBaDT4Z25siiPs5Avs zXl5zxx1Lh1z4NKTV37PBzQYSih44g2I1SM/wV93Ze93VcYct3OjViEQxtzlPbmn/rSX OCIg== Received: by 10.216.243.74 with SMTP id j52mr2016838wer.108.1348078905938; Wed, 19 Sep 2012 11:21:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Wed, 19 Sep 2012 11:21:24 -0700 (PDT) In-Reply-To: <1348077816.2880.9.camel@polyglot> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <1348077816.2880.9.camel@polyglot> From: James M Snell Date: Wed, 19 Sep 2012 11:21:24 -0700 Message-ID: To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=e0cb4e43cf1f5151d804ca1214d2 Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 18:21:51 -0000 --e0cb4e43cf1f5151d804ca1214d2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, it is a clear violation of the spec but the server needs to be able to defend the resource against potentially ambiguous change operations. Also, even if the MUST applies to the client creating and submitting the patch, the only place we can be sure the MUST level requirement is being properly implemented is on the server where the patch document is being consumed and processed. Also consider that there is an outside chance of a security risk posed by malicious clients. For example, consider the case where a malicious client sends a patch operation: {"add":"a/b/harmless","replace":"/a/b/harmful","value":"some_value"}. Now consider a server implementation composed of multiple tiered processes. The first tier is responsible for basic validation of the request. Through experimentation, the malicious client is able to determine that this first tier processes the payload in such a way that it sees only the initial "add" operation and path. Based on the business rules for validation, the server determines that adding the "some_value" to location "a/b/harmless" is ok and the validation passes. However, the client discovers that the lower tiers in the system calculates hashes differently, causing it to see the "replace" operation before the "add". Assuming the "obvious" processing model discussed previously, this lower processing tier, assuming the operation has already passed inspection by the validation tier, applies the potentially harmful "replace" operation. Yes, this is rather contrived example but, as we have seen in many real world examples, malicious parties love to take advantage of various spec ambiguities and differences in the way various application components come together to process data. Use of a single op member mitigates this particular issue by ensuring that that validation and processing tiers are always looking at the same piece of data. It's never left up to chance based on the arbitrary ordering of members in a parsed JSON object. - James On Wed, Sep 19, 2012 at 11:03 AM, Paul C. Bryan wrote: > ** > Check out the op/path/value notation in > http://tools.ietf.org/html/draft-pbryan-json-patch-00 and note its > similarity to what you're proposing. Consensus was that separate op/path > was too verbose, and in response was collapsed into operator becoming > member name. > > I suggest that the MUST definitely applies to the client submitting the > patch document. I *don't* think that the server MUST ensure that the > client conformed to the spec. If the client constructs something like: { > "add": "/some/path", "remove": "/some/other/path", "value": "some value" = }, > then the client is *clearly* violating the spec, the the results will be > unpredictable on the server. If you want your server to be paranoid, then > it should account for all members in the operation object and reject > non-conformance, but I don't expect every server to do so. > > Paul > > > On Wed, 2012-09-19 at 08:09 -0700, James M Snell wrote: > > An array based approach carries along many of it's own issues, especially > if we do decide to extend things later on. What likely would have been > ideal (albeit more verbose) are distinct "op" and "ref" codes to identify > the patch operation and json-pointer -- e.g. {"op":"add", "ref":"/a/b/c", > "value": "123"}. This helps us to enforce the single operation rule, > simplifies processing and maintains better long term extensibility at the > cost of a few extra bits on the wire. > > > > - James > > On Wed, Sep 19, 2012 at 7:52 AM, Manger, James H < > James.H.Manger@team.telstra.com> wrote: > > The consensus sounds like "MUST understand everything"; no ignoring > unrecognized fields. That is ok, but we haven't picked a good syntax to > match that rule. > > The "obvious" way to parse a patch operation object (eg > {"add":"/foo","value":"bar"}) is to: > > 1. Loop through the keys in the object until you find one that is in the > set of known operations: "add", "remove", "test"=E2=80=A6 > > 2. Extract the elements associated with that specific operation, eg the > "value" for an "add" operation. > > That "obvious" process will not detect two operations in an object, or > unexpected extra fields. Implementations will have to do non-trivial extr= a > work to make those checks. Many will not do that, or will do it > incorrectly, simply because valid cases will work regardless of that extr= a > code. The result is likely to be security problems. For instance, one > implementation parsing {"value":"bar", "add":"/foo", "remove":"/foo"} wil= l > see an "add" operation, another will see a "remove" operation (and a thir= d > will report an error), simply based on how implementation-specific string > hash codes are calculated. > > The nice thing about a JSON object is that you can add all sorts of extra > elements without affecting existing elements. Given we explicitly don't > want this feature, perhaps a better syntax would be a JSON array: startin= g > with the operation name, then the operation-specific parameters. > > For example: > instead of {"add":"/foo", "value":"bar"} > have ["add", "/foo", "bar"] > > Duplicate operations cannot occur (there can only be one first element in > an array). Preventing unexpected parameters is as simple as ensuring the > array is the right length for the specific operation. > > The array approach should also be simpler to map to a per-operation > function call with arguments. > > -- > James Manger > > > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of Mark Nottingham > > Sent: Wednesday, 19 September 2012 9:56 AM > > To: James M Snell > > Cc: apps-discuss@ietf.org > > Subject: Re: [apps-discuss] JSON Patch: extensibility > > > > Going with: > > > > > It is an error condition if an operation object does not contain a= n > > > operation member, contains an operation member other than one of > > > those defined by this document, or more than one operation member. > > > > > > Likewise, it is an error condition if an operation object has a > > > member that is not explicitly allowed by this document. > > > > > > On 18/09/2012, at 10:49 AM, James M Snell wrote: > > > > > +1 on having it be an error condition. > > > > > > Because of the potentially significant negative impact that an > > improperly applied patch operation could have on the target resource, > > any not-understood operation, object or member MUST result in an error > > condition being reported and the patch rejected. > > > > > > - James > > > > > > On Tue, Sep 18, 2012 at 10:42 AM, Paul C. Bryan > > wrote: > > > On Tue, 2012-09-18 at 10:27 -0700, Mark Nottingham wrote: > > > > > >> James is right that the document is currently silent about extra > > properties on the operation. Do people have strong feelings about > > whether this should result in an error condition, or be ignored? > > > > > > It was definitely intended to be an error condition. On this point, > > the specification reads: > > > > > > "It is an error condition if an operation object contains no > > recognized operation member or more than one operation member." > > > > > > I suppose it would be stronger to say something like: > > > > > > "It is an error condition if an operation object does not contain > > an operation member documented herein, or more than one operation > > member." > > > > > > Paul > > > > > _______________________________________________ > apps-discuss mailing listapps-discuss@ietf.orghttps://www.ietf.org/mailma= n/listinfo/apps-discuss > > > --e0cb4e43cf1f5151d804ca1214d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, it is a clear violation of the sp= ec but the server needs to be able to defend the resource against potential= ly ambiguous change operations. Also, even if the MUST applies to the clien= t creating and submitting the patch, the only place we can be sure the MUST= level requirement is being properly implemented is on the server where the= patch document is being consumed and processed.=C2=A0

    Also consider that there is an outside chance of a sec= urity risk posed by malicious clients. For example, consider the case where= a malicious client sends a patch operation:=C2=A0

    =C2=A0 {"add":"a/b/harmless"= ,"replace":"/a/b/harmful","value":"some_= value"}.

    Now consider a server implementation composed of= multiple tiered processes. The first tier is responsible for basic validat= ion of the request. Through experimentation, the malicious client is able t= o determine that this first tier processes the payload in such a way that i= t sees only the initial "add" operation and path. Based on the bu= siness rules for validation, the server determines that adding the "so= me_value" to location "a/b/harmless" is ok and the validatio= n passes. However, the client discovers that the lower tiers in the system = calculates hashes differently, causing it to see the "replace" op= eration before the "add". Assuming the "obvious" proces= sing model discussed previously, this lower processing tier, assuming the o= peration has already passed inspection by the validation tier, applies the = potentially harmful "replace" operation.=C2=A0

    Yes, this is rather contrived example but, as we= have seen in many real world examples, malicious parties love to take adva= ntage of various spec ambiguities and differences in the way various applic= ation components come together to process data. Use of a single op member m= itigates this particular issue by ensuring that that validation and process= ing tiers are always looking at the same piece of data. It's never left= up to chance based on the arbitrary ordering of members in a parsed JSON o= bject.

    - James

    On Wed, Sep 19, 2012 at 11:03 AM, Paul C. Bryan = <pbryan@anode.ca> wrote:
    =20 =20
    Check out the op/path/value notation in http://tools.ietf.org/html= /draft-pbryan-json-patch-00 and note its similarity to what you're = proposing. Consensus was that separate op/path was too verbose, and in resp= onse was collapsed into operator becoming member name.

    I suggest that the MUST definitely applies to the client submitting the pat= ch document. I don't think that the server MUST ensure that the = client conformed to the spec. If the client constructs something like: { &q= uot;add": "/some/path", "remove": "/some/othe= r/path", "value": "some value" }, then the client = is clearly violating the spec, the the results will be unpredictable= on the server. If you want your server to be paranoid, then it should acco= unt for all members in the operation object and reject non-conformance, but= I don't expect every server to do so.

    Paul


    On Wed, 2012-09-19 at 08:09 -0700, James M Snell wrote:
    An array based approach carries along many of it's own issues, espe= cially if we do decide to extend things later on. What likely would have be= en ideal (albeit more verbose) are distinct "op" and "ref&qu= ot; codes to identify the patch operation and json-pointer -- e.g. {"o= p":"add", "ref":"/a/b/c", "value&qu= ot;: "123"}. This helps us to enforce the single operation rule, = simplifies processing and maintains better long term extensibility at the c= ost of a few extra bits on the wire.=C2=A0


    - James

    On Wed, Sep 19, 2012 at 7:52 AM, Manger, James H <James.H.Manger@team.tels= tra.com> wrote:
    The consensus sounds like "MUST understand everything"; n= o ignoring unrecognized fields. That is ok, but we haven't picked a goo= d syntax to match that rule.

    The "obvious" way to parse a patch operation object (eg {= "add":"/foo","value":"bar"}) is to:=

    1. Loop through the keys in the object until you find one that is i= n the set of known operations: "add", "remove", "t= est"=E2=80=A6

    2. Extract the elements associated with that specific operation, eg= the "value" for an "add" operation.

    That "obvious" process will not detect two operations in = an object, or unexpected extra fields. Implementations will have to do non-= trivial extra work to make those checks. Many will not do that, or will do = it incorrectly, simply because valid cases will work regardless of that ext= ra code. The result is likely to be security problems. For instance, one im= plementation parsing {"value":"bar", "add":&q= uot;/foo", "remove":"/foo"} will see an "add&= quot; operation, another will see a "remove" operation (and a thi= rd will report an error), simply based on how implementation-specific strin= g hash codes are calculated.

    The nice thing about a JSON object is that you can add all sorts of= extra elements without affecting existing elements. Given we explicitly do= n't want this feature, perhaps a better syntax would be a JSON array: s= tarting with the operation name, then the operation-specific parameters.
    For example:
    instead of =C2=A0{"add":"/foo", "value&quo= t;:"bar"}
    have =C2=A0 =C2=A0 =C2=A0 =C2=A0["add", "/foo",= "bar"]

    Duplicate operations cannot occur (there can only be one first elem= ent in an array). Preventing unexpected parameters is as simple as ensuring= the array is the right length for the specific operation.

    The array approach should also be simpler to map to a per-operation= function call with arguments.

    --
    James Manger


    > -----Original Message-----
    > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
    > bounces@= ietf.org] On Behalf Of Mark Nottingham
    > Sent: Wednesday, 19 September 2012 9:56 AM
    > To: James M Snell
    > Cc: apps-discuss@ietf.org
    > Subject: Re: [apps-discuss] JSON Patch: extensibility
    >
    > Going with:
    >
    > > =C2=A0 =C2=A0It is an error condition if an operation obj= ect does not contain an
    > > =C2=A0 =C2=A0operation member, contains an operation memb= er other than one of
    > > =C2=A0 =C2=A0those defined by this document, or more than= one operation member.
    > >
    > > =C2=A0 =C2=A0Likewise, it is an error condition if an ope= ration object has a
    > > =C2=A0 =C2=A0member that is not explicitly allowed by thi= s document.
    >
    >
    > On 18/09/2012, at 10:49 AM, James M Snell <jasnell@gmail.com> wrote:
    >
    > > +1 on having it be an error condition.
    > >
    > > Because of the potentially significant negative impact th= at an
    > improperly applied patch operation could have on the target re= source,
    > any not-understood operation, object or member MUST result in = an error
    > condition being reported and the patch rejected.
    > >
    > > - James
    > >
    > > On Tue, Sep 18, 2012 at 10:42 AM, Paul C. Bryan <pbryan@anode.ca>
    > wrote:
    > > On Tue, 2012-09-18 at 10:27 -0700, Mark Nottingham wrote:=
    > >
    > >> James is right that the document is currently silent = about extra
    > properties on the operation. Do people have strong feelings ab= out
    > whether this should result in an error condition, or be ignore= d?
    > >
    > > It was definitely intended to be an error condition. On t= his point,
    > the specification reads:
    > >
    > > =C2=A0 =C2=A0 "It is an error condition if an operat= ion object contains no
    > recognized operation member or more than one operation member.= "
    > >
    > > I suppose it would be stronger to say something like:
    > >
    > > =C2=A0 =C2=A0 "It is an error condition if an operat= ion object does not contain
    > an operation member documented herein, or more than one operat= ion
    > member."
    > >
    > > Paul




    _______________________________________________
apps-discuss mailing list
apps-discuss@iet=
f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


    --e0cb4e43cf1f5151d804ca1214d2-- From fgaliegue@gmail.com Wed Sep 19 11:26:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6C021F849C for ; Wed, 19 Sep 2012 11:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.606 X-Spam-Level: X-Spam-Status: No, score=-3.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtKqesxYQ7qr for ; Wed, 19 Sep 2012 11:26:29 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AEC5E21F8493 for ; Wed, 19 Sep 2012 11:26:29 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so1702353vbb.31 for ; Wed, 19 Sep 2012 11:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ykcGU4NvUo5DBaVSbgm4lNM2RVdCbrz6cvf9dNLVe6w=; b=nADRbd4xKww1F1aj0YdJMu3ExGJRQiMU4hvkxt7ln3Fy5xSINJGnvww7u31N7m7fk5 PPy/CkdFg1IPOnLnzjxCs4UqAkHgEmGBPDj6WDyizbommZD2giJhgwCXI5FQXOiPWK93 gPf1EnXHy2PwnPGeiK7ueM8mvNlozum5znhzUnH944syfxzxK4oteeMwMzXS4SKRBCMT 6lcQhlwkircnbT/Vu35Y3ObW2slvBg3ZxV7W5qaKDdwjI4zb41nTdQT3UnRFDMg8Bq/u hKXRgt0vHqkdIwmEqbCV3QKRDlCEphfhWzp9Y3SoCN51mCwp0VTFJDA8vjYYWqczlPvP Ssxw== MIME-Version: 1.0 Received: by 10.52.27.229 with SMTP id w5mr1902690vdg.126.1348079189100; Wed, 19 Sep 2012 11:26:29 -0700 (PDT) Received: by 10.52.23.103 with HTTP; Wed, 19 Sep 2012 11:26:28 -0700 (PDT) In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <1348077816.2880.9.camel@polyglot> Date: Wed, 19 Sep 2012 20:26:28 +0200 Message-ID: From: Francis Galiegue To: James M Snell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 18:26:33 -0000 On Wed, Sep 19, 2012 at 8:21 PM, James M Snell wrote: > Yes, it is a clear violation of the spec but the server needs to be able = to > defend the resource against potentially ambiguous change operations. Also= , > even if the MUST applies to the client creating and submitting the patch, > the only place we can be sure the MUST level requirement is being properl= y > implemented is on the server where the patch document is being consumed a= nd > processed. > > Also consider that there is an outside chance of a security risk posed by > malicious clients. For example, consider the case where a malicious clien= t > sends a patch operation: > > {"add":"a/b/harmless","replace":"/a/b/harmful","value":"some_value"}. > > Now consider a server implementation composed of multiple tiered processe= s. > The first tier is responsible for basic validation of the request. Throug= h > experimentation, the malicious client is able to determine [...] Sorry to jump into the discussion like this, but... Isn't JSON Patch supposed to be a way of _processing_ JSON values? What gains, if any, would there be for JSON Patch proper to acknowledge security concerns? /me runs away, --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From pbryan@anode.ca Wed Sep 19 11:30:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5F921F843F for ; Wed, 19 Sep 2012 11:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDSv3fMTa0nu for ; Wed, 19 Sep 2012 11:30:19 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 3549D21F843E for ; Wed, 19 Sep 2012 11:30:19 -0700 (PDT) Received: from [10.71.13.58] (adsl-75-55-201-218.dsl.pltn13.sbcglobal.net [75.55.201.218]) by maple.anode.ca (Postfix) with ESMTPSA id BA732648E; Wed, 19 Sep 2012 18:30:17 +0000 (UTC) Message-ID: <1348079072.2880.18.camel@polyglot> From: "Paul C. Bryan" To: James M Snell Date: Wed, 19 Sep 2012 11:24:32 -0700 In-Reply-To: References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> <1348077337.2880.3.camel@polyglot> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 18:30:19 -0000 I don't have a specific thread in hand I can point you to right now. Back in the early days, the lists we discussed this on were: JSON Schema, JSON Patch and CouchDB. I can probably (later) also dig-up some email exchanges with Kris Zyp regarding his decision to abandon dot notation in favour of slash. Paul On Wed, 2012-09-19 at 11:05 -0700, James M Snell wrote: > Paul, do you happen to have a link referencing the path/pointer > discussion readily available? I (and I'm sure others) would appreciate > being able to review what specific arguments were made. I could go > hunting for them myself but figured it might be faster just to ask. > > On Wed, Sep 19, 2012 at 10:55 AM, Paul C. Bryan > wrote: > For fun reading—and a bit of a history lesson—see > http://tools.ietf.org/html/draft-pbryan-json-patch-00 and > check out its proposed path notation. Path/pointer notation > was then discussed a fair amount, and slash notation would up > being favoured over the dot/bracket notation. > > Paul > > > On Wed, 2012-09-19 at 12:06 -0400, Evan Prodromou wrote: > > On 12-09-19 11:27 AM, Francis Galiegue wrote: > > > JSON Pointer has been written like this on purpose. It is unambiguous, > > > impervious to programming languages pecularities and encodings... All > > > advantages and none of the drawbacks :) > > It conspicuously lacks the advantage of being familiar for people who > > know JavaScript or JavaScript-based syntaxes like the MongoDB example I > > linked to. > > > > That said, I appreciate the response, and I'm just glad the subject has > > been discussed. > > > > -Evan > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > From jasnell@gmail.com Wed Sep 19 11:37:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4192321E803A for ; Wed, 19 Sep 2012 11:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFl2UCNUdu9I for ; Wed, 19 Sep 2012 11:37:33 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 18A7D21F8472 for ; Wed, 19 Sep 2012 11:37:32 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1232130wib.13 for ; Wed, 19 Sep 2012 11:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LAvHmNwDjo59hR450zlLB62KJWeTwHlsS1qwEyVxjf4=; b=abcC/pRCdYr2rmCh0SGSaMbEQGYHg/VJdEeqsLwkQ7ttmIwsiZNTVxud3f4Ygv4CT4 KivNpYp75kMimai/rYXSYmdSKeLLuq9yFVQ9plEDUnAP/ZT8jndAbGBw6aUFToMryKfd S8wAggh7y3yubrSziNwt5qCYmnr4FtADB2hyyfjvgslK/8hAuVxG5v4AGBc/anps9Zhv 2HF9LQcjq4txqbJemJKYDvA3hUOqtnil1Ew28DEl1oaSsouA2jyMzS2CovITixXs+wCt XW7SMRabq4wewnhzBjCqvpPSfOgfbRoBLuvOVWlHZg+EwUyQV0SYoEvFiUpYRTc8LDb1 2tTg== Received: by 10.216.243.74 with SMTP id j52mr2034626wer.108.1348079852156; Wed, 19 Sep 2012 11:37:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Wed, 19 Sep 2012 11:37:12 -0700 (PDT) In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <1348077816.2880.9.camel@polyglot> From: James M Snell Date: Wed, 19 Sep 2012 11:37:12 -0700 Message-ID: To: Francis Galiegue Content-Type: multipart/alternative; boundary=e0cb4e43cf1fb7771504ca124cf0 Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 18:37:34 -0000 --e0cb4e43cf1fb7771504ca124cf0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable By it's own description, JSON Patch is "a ... document structure for expressing a sequence of operations to apply to a JSON document." As such, if that document structure allows for potentially ambiguous conditions to arise in the identification and processing of those operations, and such ambiguities can potentially have security ramifications, then those security concerns must absolutely be discussed. Simply stating that there MUST only be one operation member in the object is not quite enough. It is also critical to describe what could happen if the requirement is not enforced. It is also important to deal with the fact that the ambiguity could be eliminated entirely by choosing an alternative, slightly more verbose syntax for the expression of the operation and pointer. I get that a decision was made previously to go with the less verbose option; but what's not yet clear is whether that was the best option to take. Personally, when it comes to describing change operations, I'd prefer precise and verbose over ambiguous. - James On Wed, Sep 19, 2012 at 11:26 AM, Francis Galiegue wro= te: > On Wed, Sep 19, 2012 at 8:21 PM, James M Snell wrote: > > Yes, it is a clear violation of the spec but the server needs to be abl= e > to > > defend the resource against potentially ambiguous change operations. > Also, > > even if the MUST applies to the client creating and submitting the patc= h, > > the only place we can be sure the MUST level requirement is being > properly > > implemented is on the server where the patch document is being consumed > and > > processed. > > > > Also consider that there is an outside chance of a security risk posed = by > > malicious clients. For example, consider the case where a malicious > client > > sends a patch operation: > > > > {"add":"a/b/harmless","replace":"/a/b/harmful","value":"some_value"}. > > > > Now consider a server implementation composed of multiple tiered > processes. > > The first tier is responsible for basic validation of the request. > Through > > experimentation, the malicious client is able to determine [...] > > Sorry to jump into the discussion like this, but... > > Isn't JSON Patch supposed to be a way of _processing_ JSON values? > What gains, if any, would there be for JSON Patch proper to > acknowledge security concerns? > > /me runs away, > -- > Francis Galiegue, fgaliegue@gmail.com > JSON Schema: https://github.com/json-schema > "It seems obvious [...] that at least some 'business intelligence' > tools invest so much intelligence on the business side that they have > nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The > Art of SQL", ISBN 0-596-00894-5) > --e0cb4e43cf1fb7771504ca124cf0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable By it's own description, JSON Patc= h is "a ...=C2=A0document structure for expressing a sequence of operations to apply= =C2=A0to= a JSON document." As such, if that document structure allows for pote= ntially ambiguous conditions to arise in the identification and processing = of those operations, and such ambiguities can potentially have security ram= ifications, then those security concerns must absolutely be discussed. Simp= ly stating that there MUST only be one operation member in the object is no= t quite enough. It is also critical to describe what could happen if the re= quirement is not enforced.

    It is also important to deal with the fact that the am= biguity could be eliminated entirely by choosing an alternative, slightly m= ore verbose syntax for the expression of the operation and pointer. I get t= hat a decision was made previously to go with the less verbose option; but = what's not yet clear is whether that was the best option to take. Perso= nally, when it comes to describing change operations, I'd prefer precis= e and verbose over ambiguous.

    - James

    On Wed, Sep 19, 2012 at 11:26 AM, Francis Galiegue <<= a href=3D"mailto:fgaliegue@gmail.com" target=3D"_blank">fgaliegue@gmail.com= > wrote:
    On Wed, Sep 19, 2012 at 8:= 21 PM, James M Snell <jasnell@gmail= .com> wrote:
    > Yes, it is a clear violation of the spec but the server needs to be ab= le to
    > defend the resource against potentially ambiguous change operations. A= lso,
    > even if the MUST applies to the client creating and submitting the pat= ch,
    > the only place we can be sure the MUST level requirement is being prop= erly
    > implemented is on the server where the patch document is being consume= d and
    > processed.
    >
    > Also consider that there is an outside chance of a security risk posed= by
    > malicious clients. For example, consider the case where a malicious cl= ient
    > sends a patch operation:
    >
    > =C2=A0 {"add":"a/b/harmless","replace":&= quot;/a/b/harmful","value":"some_value"}.
    >
    > Now consider a server implementation composed of multiple tiered proce= sses.
    > The first tier is responsible for basic validation of the request. Thr= ough
    > experimentation, the malicious client is able to determine [...]=

    Sorry to jump into the discussion like this, but...

    Isn't JSON Patch supposed to be a way of _processing_ JSON values?
    What gains, if any, would there be for JSON Patch proper to
    acknowledge security concerns?

    /me runs away,
    --
    Francis Galiegue, fgaliegue@gmail.co= m
    JSON Schema: h= ttps://github.com/json-schema
    "It seems obvious [...] that at least some 'business intelligence&= #39;
    tools invest so much intelligence on the business side that they have
    nothing left for generating SQL queries" (St=C3=A9phane Faroult, in &q= uot;The
    Art of SQL", ISBN 0-596-00894-5)

    --e0cb4e43cf1fb7771504ca124cf0-- From pbryan@anode.ca Wed Sep 19 11:52:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C328F21F84CF for ; Wed, 19 Sep 2012 11:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2bny7CA8JpS for ; Wed, 19 Sep 2012 11:52:50 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id EB31221F849D for ; Wed, 19 Sep 2012 11:52:47 -0700 (PDT) Received: from [10.71.13.58] (adsl-75-55-201-218.dsl.pltn13.sbcglobal.net [75.55.201.218]) by maple.anode.ca (Postfix) with ESMTPSA id D76BC64A6; Wed, 19 Sep 2012 18:52:42 +0000 (UTC) Message-ID: <1348080756.2880.32.camel@polyglot> From: "Paul C. Bryan" To: James M Snell Date: Wed, 19 Sep 2012 11:52:36 -0700 In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <1348077816.2880.9.camel@polyglot> Content-Type: multipart/alternative; boundary="=-wvQ7YkJnaisKQZpyOzYC" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 18:52:51 -0000 --=-wvQ7YkJnaisKQZpyOzYC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2012-09-19 at 11:21 -0700, James M Snell wrote: > Yes, it is a clear violation of the spec but the server needs to be > able to defend the resource against potentially ambiguous change > operations. Also, even if the MUST applies to the client creating and > submitting the patch, the only place we can be sure the MUST level > requirement is being properly implemented is on the server where the > patch document is being consumed and processed. Some server implementations may elect to reject ambiguous change operations. It is an error condition; evaluation of the JSON patch document SHOULD terminate. > Also consider that there is an outside chance of a security risk posed > by malicious clients. For example, consider the case where a malicious > client sends a patch operation: > > {"add":"a/b/harmless","replace":"/a/b/harmful","value":"some_value"}. > > Now consider a server implementation composed of multiple tiered > processes. The first tier is responsible for basic validation of the > request. Through experimentation, the malicious client is able to > determine that this first tier processes the payload in such a way > that it sees only the initial "add" operation and path. Based on the > business rules for validation, the server determines that adding the > "some_value" to location "a/b/harmless" is ok and the validation > passes. However, the client discovers that the lower tiers in the > system calculates hashes differently, causing it to see the "replace" > operation before the "add". Assuming the "obvious" processing model > discussed previously, this lower processing tier, assuming the > operation has already passed inspection by the validation tier, > applies the potentially harmful "replace" operation. It is an error condition, and processing SHOULD terminate. In this particular case, it seems particularly important that it does terminate. And this all implies that the client must not create such constructs if it expects it to be processed successfully. > Yes, this is rather contrived example but, as we have seen in many > real world examples, malicious parties love to take advantage of > various spec ambiguities and differences in the way various > application components come together to process data. Use of a single > op member mitigates this particular issue by ensuring that that > validation and processing tiers are always looking at the same piece > of data. It's never left up to chance based on the arbitrary ordering > of members in a parsed JSON object. I agree that an "op" member solves this, at the expense of verbosity that was dismissed at the time. And when I considered it, I didn't see as much complexity in validation: if I find and "add" member, I check for a "value" member and confirm that there are only 2 members in the object. If I find a "remove" member, I confirm there is only one member in the object. Paul --=-wvQ7YkJnaisKQZpyOzYC Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 2012-09-19 at 11:21 -0700, James M Snell wrote:
    Yes, it is a clear violation of the spec but the server needs to be able to defend the resource against potentially ambiguous change operations. Also, even if the MUST applies to the client creating and submitting the patch, the only place we can be sure the MUST level requirement is being properly implemented is on the server where the patch document is being consumed and processed.

    Some server implementations may elect to reject ambiguous change operations. It is an error condition; evaluation of the JSON patch document SHOULD terminate.
    Also consider that there is an outside chance of a security risk posed by malicious clients. For example, consider the case where a malicious client sends a patch operation: 
      {"add":"a/b/harmless","replace":"/a/b/harmful","value":"some_value"}.

    Now consider a server implementation composed of multiple tiered processes. The first tier is responsible for basic validation of the request. Through experimentation, the malicious client is able to determine that this first tier processes the payload in such a way that it sees only the initial "add" operation and path. Based on the business rules for validation, the server determines that adding the "some_value" to location "a/b/harmless" is ok and the validation passes. However, the client discovers that the lower tiers in the system calculates hashes differently, causing it to see the "replace" operation before the "add". Assuming the "obvious" processing model discussed previously, this lower processing tier, assuming the operation has already passed inspection by the validation tier, applies the potentially harmful "replace" operation.

    It is an error condition, and processing SHOULD terminate. In this particular case, it seems particularly important that it does terminate. And this all implies that the client must not create such constructs if it expects it to be processed successfully.

    Yes, this is rather contrived example but, as we have seen in many real world examples, malicious parties love to take advantage of various spec ambiguities and differences in the way various application components come together to process data. Use of a single op member mitigates this particular issue by ensuring that that validation and processing tiers are always looking at the same piece of data. It's never left up to chance based on the arbitrary ordering of members in a parsed JSON object.

    I agree that an "op" member solves this, at the expense of verbosity that was dismissed at the time. And when I considered it, I didn't see as much complexity in validation: if I find and "add" member, I check for a "value" member and confirm that there are only 2 members in the object. If I find a "remove" member, I confirm there is only one member in the object.

    Paul
    --=-wvQ7YkJnaisKQZpyOzYC-- From jasnell@gmail.com Wed Sep 19 12:14:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABB221F84EE for ; Wed, 19 Sep 2012 12:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSSakf1uDz3K for ; Wed, 19 Sep 2012 12:14:06 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 27D6021E80A0 for ; Wed, 19 Sep 2012 12:14:04 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1266757wib.13 for ; Wed, 19 Sep 2012 12:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Qen2LP8uJI3ZhnjDn9hYIkpBb7bmmhxy+sp/2Fzs6m0=; b=pF6PgAr5xFVokgoehlBxrEQu2Pbi9HHsUn/GYtTetzv4bYZOtF/d/wg2Yd5D25JS2G l/gu/eBF2SDnDo2asy5Ch3vOuwCEC6tiN3cEPu2LV72xPGTzpyphx2HYeH7zZpbgfuj5 nGFoQB2aZipYmOrIGkQQLEt4cQBGobBWP7VYQdzRt7/RmSozVbZZIgC2tNCsqxXvORFl aZxsU5tBDw/ALADuVdvQ81AdhvVjaZRjfWuAMLW9kqpRnFv+vuS1SClTR7d47t2VVylU gOe9TFLLbHOOLKiMPIMp80wrqtmH3Ey5aeItNkglu240JxXr5/3J4+MW16LSo+3lecC8 mnCA== Received: by 10.216.194.143 with SMTP id m15mr2242858wen.128.1348082033655; Wed, 19 Sep 2012 12:13:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Wed, 19 Sep 2012 12:13:33 -0700 (PDT) In-Reply-To: <1348080756.2880.32.camel@polyglot> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <1348077816.2880.9.camel@polyglot> <1348080756.2880.32.camel@polyglot> From: James M Snell Date: Wed, 19 Sep 2012 12:13:33 -0700 Message-ID: To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=0016e6da2e7fbe7f8104ca12ce83 Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 19:14:07 -0000 --0016e6da2e7fbe7f8104ca12ce83 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 19, 2012 at 11:52 AM, Paul C. Bryan wrote: > ** > On Wed, 2012-09-19 at 11:21 -0700, James M Snell wrote: > > Yes, it is a clear violation of the spec but the server needs to be able > to defend the resource against potentially ambiguous change operations. > Also, even if the MUST applies to the client creating and submitting the > patch, the only place we can be sure the MUST level requirement is being > properly implemented is on the server where the patch document is being > consumed and processed. > > > *Some* server implementations may elect to reject ambiguous change > operations. It *is* an error condition; evaluation of the JSON patch > document *SHOULD* terminate. > The point here is that server implementations ought to be *required* to reject ambiguous change operations... not only "Some". It MUST NOT be left up to implementations to choose on this particular point. I can see no justifiable reason for this to be a SHOULD rather than a MUST. > > Also consider that there is an outside chance of a security risk posed by > malicious clients. For example, consider the case where a malicious client > sends a patch operation: > > {"add":"a/b/harmless","replace":"/a/b/harmful","value":"some_value"}. > > Now consider a server implementation composed of multiple tiered > processes. The first tier is responsible for basic validation of the > request. Through experimentation, the malicious client is able to determine > that this first tier processes the payload in such a way that it sees only > the initial "add" operation and path. Based on the business rules for > validation, the server determines that adding the "some_value" to location > "a/b/harmless" is ok and the validation passes. However, the client > discovers that the lower tiers in the system calculates hashes differently, > causing it to see the "replace" operation before the "add". Assuming the > "obvious" processing model discussed previously, this lower processing > tier, assuming the operation has already passed inspection by the > validation tier, applies the potentially harmful "replace" operation. > > > It *is* an error condition, and processing *SHOULD* terminate. In this > particular case, it seems particularly important that it does terminate. > And this all implies that the client must not create such constructs if it > expects it to be processed successfully. > > Agreed. The more important point, however, is that servers are required to validate the change operation to ensure that the client is doing it's job correctly, and current syntax makes such validation more difficult than it really ought to be, especially in the long term if we decide to extend the possible range of operations. When using something like "op":"replace" as an alternative, however, this additional validation check becomes entirely unnecessary and the possibility of ambiguity dissolves completely. For me, this is much more advantageous than saving a few bytes on the wire. - James Yes, this is rather contrived example but, as we have seen in many real > world examples, malicious parties love to take advantage of various spec > ambiguities and differences in the way various application components come > together to process data. Use of a single op member mitigates this > particular issue by ensuring that that validation and processing tiers are > always looking at the same piece of data. It's never left up to chance > based on the arbitrary ordering of members in a parsed JSON object. > > > I agree that an "op" member solves this, at the expense of verbosity that > was dismissed at the time. And when I considered it, I didn't see as much > complexity in validation: if I find and "add" member, I check for a "value" > member and confirm that there are only 2 members in the object. If I find a > "remove" member, I confirm there is only one member in the object. > Paul > --0016e6da2e7fbe7f8104ca12ce83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    On Wed, Sep 19, 2012 at 11:52 AM, Paul C. Bryan <<= a href=3D"mailto:pbryan@anode.ca" target=3D"_blank">pbryan@anode.ca>= wrote:
    =20 =20
    On Wed, 2012-09-19 at 11:21 -0700, James M Snell wrote:
    Yes, it is a clear violation of the spec but the server needs to be abl= e to defend the resource against potentially ambiguous change operations. A= lso, even if the MUST applies to the client creating and submitting the pat= ch, the only place we can be sure the MUST level requirement is being prope= rly implemented is on the server where the patch document is being consumed= and processed.

    Some server implementations may elect to reject ambiguous chan= ge operations. It is an error condition; evaluation of the JSON patc= h document SHOULD terminate.

    The point here is that server implementations ought to be *required* t= o reject ambiguous change operations... not only "Some". It MUST = NOT be left up to implementations to choose on this particular point. I can= see no justifiable reason for this to be a SHOULD rather than a MUST.=C2= =A0
    =C2=A0

    Also consider that there is an outside chance of a security risk posed = by malicious clients. For example, consider the case where a malicious clie= nt sends a patch operation:=C2=A0
    =C2=A0 {"add":"a/b/harmless","replace":&q= uot;/a/b/harmful","value":"some_value"}.

    Now consider a server implementation composed of multiple tiered proces= ses. The first tier is responsible for basic validation of the request. Thr= ough experimentation, the malicious client is able to determine that this f= irst tier processes the payload in such a way that it sees only the initial= "add" operation and path. Based on the business rules for valida= tion, the server determines that adding the "some_value" to locat= ion "a/b/harmless" is ok and the validation passes. However, the = client discovers that the lower tiers in the system calculates hashes diffe= rently, causing it to see the "replace" operation before the &quo= t;add". Assuming the "obvious" processing model discussed pr= eviously, this lower processing tier, assuming the operation has already pa= ssed inspection by the validation tier, applies the potentially harmful &qu= ot;replace" operation.

    It is an error condition, and processing SHOULD terminate. In= this particular case, it seems particularly important that it does termina= te. And this all implies that the client must not create such constructs if= it expects it to be processed successfully.


    Agreed. The more important= point, however, is that servers are required to validate the change operat= ion to ensure that the client is doing it's job correctly, and current = syntax makes such validation more difficult than it really ought to be, esp= ecially in the long term if we decide to extend the possible range of opera= tions.
    =C2=A0
    When using something like "op":"replac= e" as an alternative, however, this additional validation check become= s entirely unnecessary and the possibility of ambiguity dissolves completel= y. For me, this is much more advantageous than saving a few bytes on the wi= re.=C2=A0
    =C2=A0
    - James

    Yes, this is rather contrived example but, as we have seen in many real= world examples, malicious parties love to take advantage of various spec a= mbiguities and differences in the way various application components come t= ogether to process data. Use of a single op member mitigates this particula= r issue by ensuring that that validation and processing tiers are always lo= oking at the same piece of data. It's never left up to chance based on = the arbitrary ordering of members in a parsed JSON object.

    I agree that an "op" member solves this, at the expense of verbos= ity that was dismissed at the time. And when I considered it, I didn't = see as much complexity in validation: if I find and "add" member,= I check for a "value" member and confirm that there are only 2 m= embers in the object. If I find a "remove" member, I confirm ther= e is only one member in the object.=C2=A0
    Paul

    --0016e6da2e7fbe7f8104ca12ce83-- From hallam@gmail.com Wed Sep 19 12:14:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF6021F8551 for ; Wed, 19 Sep 2012 12:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCGWkXAsd+I2 for ; Wed, 19 Sep 2012 12:14:06 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D65CF21F847C for ; Wed, 19 Sep 2012 12:14:05 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1558974obb.31 for ; Wed, 19 Sep 2012 12:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8Go7RGuYPjlX0VC4NqRyCJ3eQV2ajLZXd/1fHD33P1s=; b=iDCH4UREUe1cWkVAu4jnvcdtm7mYmWfzfthiRQjext5PExrzOIBNqIVoD7Lm4NpaUM Wf/KlvLgZ2iS76ETDpPvhGimaf0IX4dfIf55FYFjFxledzumAOmCGI8mJzdn3G6YuKE1 dydExRhIggFstg9k2aeROzE2O1CFqZr7quPfrR4Lq9O81cYhxpFNIxtSEPacSdopEu3l DQI5ta60HkCgOVSDisJMVh5leqPmVtrLEJA6yjPn0riEP8I7eb9jiLL46rm6vINFmExX Zobkw74XA4p3TXWZHq6CPU9zG1ZNOPXjckFS8Aeq4Aowyxs1Ty+D+FrWdi0Lz0Idh5vm qHqw== MIME-Version: 1.0 Received: by 10.60.170.229 with SMTP id ap5mr3647141oec.101.1348082041528; Wed, 19 Sep 2012 12:14:01 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Wed, 19 Sep 2012 12:14:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 15:14:01 -0400 Message-ID: From: Phillip Hallam-Baker To: Francis Galiegue Content-Type: multipart/alternative; boundary=bcaec54b4ac036a00b04ca12cf1f Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 19:14:07 -0000 --bcaec54b4ac036a00b04ca12cf1f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Excuse me but you just did refer to the 'Github JSON Schema group' And yes, I have read the purported JSON Schema spec. It is far too complex with far too many options. Having written protocols using schemas, I can tell you for example that you don't need maxOccurs or minOccurs, the only options that make sense 95% of the time are one or none [0..], exactly one [1..1], at least one [1..MAXINT] or any [0...MAXINT]. The spec replicates XML Schema in JSON. I don't think that has any value. If people want to have that type of validation and see value in it then they are going to use XML Schema. The reason some of us are interested in a redo is that we want something that is simple like JSON is simple. On Wed, Sep 19, 2012 at 2:09 PM, Francis Galiegue wrot= e: > On Wed, Sep 19, 2012 at 7:59 PM, Phillip Hallam-Baker > wrote: > > You keep raising JSON Schema here referring to it as if it was a done > deal. > > In fact you just told me that JSON Pointer is needed by JSON Schema > which is > > why I said, whooa, if you need a pointer spec for a schema language the= n > you > > are doing it wrong. > > > > What I say is that an unambiguous way of accessing ANY path in a JSON > value, whatever that value is, is needed, and JSON Pointer is that. > Try as hard as you want, I fail to see how you can do any better. I > didn't even design that. Out of the light of pure reason, JSON Pointer > _makes sense_. > > [...] > > > As for 'Github', isn't that a place where people start up communities? = So > > calling something the Github community makes it sound as if you have th= e > > endorsement of GitHub which I am pretty sure you don't. In fact that is > > precisely what my complaint was about. I don't think you should be > > aggrandizing yourself by claiming the endorsement of the JSON community > or > > the GitHub community. > > > > The only organization that should be accrediting a JSON Schema or JSON > > Pointer is the standards body for JSON which seems to now be IETF since > ECMA > > seem to be citing the IETF RFC as normative. > > > > Until there is an IETF working group set up to develop one you should > call > > it something else. > > > > Read about the history of JSON Schema. Please. > > I have NEVER, EVER, pretended to have endorsement from ANYONE. The > GitHub JSON Schema group is an ad-hoc organization aimed at reviving > JSON Schema, and that is all there is to it. And the principles behind > this ad-hoc organization are: collect existing uses (and there are); > propose solutions (and there are); reach a consensus (in process); AND > THEN submit to the IETF. > > Did I ever claim being backed by GitHub? No. Did I ever claim being > backed by the IETF (what a foolish notion to begin with)? No. Do I > claim to be working to get JSON Schema into something to be considered > for an I-D (note, an I-D)? Definitely, yes. On behalf of all people > involved with this organization, which is an ad-ho group of > VOLUNTEERS. > > But, damnit, I have known the subject for long enough to KNOW, just > KNOW, that addressing JSON today, in an unambiguous way, involves two > things: JSON Reference, and JSON Pointer. However "unlikeable" JSON > Pointer may look to people who are too used to JavaScript. JSON is NOT > Javascript. > > -- > Francis Galiegue, fgaliegue@gmail.com > JSON Schema: https://github.com/json-schema > "It seems obvious [...] that at least some 'business intelligence' > tools invest so much intelligence on the business side that they have > nothing left for generating SQL queries" (St=E9phane Faroult, in "The > Art of SQL", ISBN 0-596-00894-5) > --=20 Website: http://hallambaker.com/ --bcaec54b4ac036a00b04ca12cf1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Excuse me but you just did refer to the 'Github JSON Schema group'<= div>
    And yes, I have read the purported JSON Schema spec. It = is far too complex with far too many options.

    Havi= ng written protocols using schemas, I can tell you for example that you don= 't need maxOccurs or minOccurs, the only options that make sense 95% of= the time are one or none [0..], exactly one [1..1], at least one [1..MAXIN= T] or any [0...MAXINT].

    The spec replicates XML Schema in JSON. I don't thi= nk that has any value. If people want to have that type of validation and s= ee value in it then they are going to use XML Schema. The reason some of us= are interested in a redo is that we want something that is simple like JSO= N is simple.


    On Wed, Sep 19, 2012 at 2:09 PM, Fr= ancis Galiegue <fgaliegue@gmail.com> wrote:
    On Wed, Sep 19, 2012 at 7:59 PM, Phillip Hallam-Baker <= ;hallam@gmail.com> wrote:
    > You keep raising JSON Schema here referring to it as if it was a done = deal.
    > In fact you just told me that JSON Pointer is needed by JSON Schema wh= ich is
    > why I said, whooa, if you need a pointer spec for a schema language th= en you
    > are doing it wrong.
    >

    What I say is that an unambiguous way of accessing ANY path in a JSON=
    value, whatever that value is, is needed, and JSON Pointer is that.
    Try as hard as you want, I fail to see how you can do any better. I
    didn't even design that. Out of the light of pure reason, JSON Pointer<= br> _makes sense_.

    [...]

    > As for 'Github', isn't that a place where people start up = communities? So
    > calling something the Github community makes it sound as if you have t= he
    > endorsement of GitHub which I am pretty sure you don't. In fact th= at is
    > precisely what my complaint was about. I don't think you should be=
    > aggrandizing yourself by claiming the endorsement of the JSON communit= y or
    > the GitHub community.
    >
    > The only organization that should be accrediting a JSON Schema or JSON=
    > Pointer is the standards body for JSON which seems to now be IETF sinc= e ECMA
    > seem to be citing the IETF RFC as normative.
    >
    > Until there is an IETF working group set up to develop one you should = call
    > it something else.
    >

    Read about the history of JSON Schema. Please.

    I have NEVER, EVER, pretended to have endorsement from ANYONE. The
    GitHub JSON Schema group is an ad-hoc organization aimed at reviving
    JSON Schema, and that is all there is to it. And the principles behind
    this ad-hoc organization are: collect existing uses (and there are);
    propose solutions (and there are); reach a consensus (in process); AND
    THEN submit to the IETF.

    Did I ever claim being backed by GitHub? No. Did I ever claim being
    backed by the IETF (what a foolish notion to begin with)? No. Do I
    claim to be working to get JSON Schema into something to be considered
    for an I-D (note, an I-D)? Definitely, yes. On behalf of all people
    involved with this organization, which is an ad-ho group of
    VOLUNTEERS.

    But, damnit, I have known the subject for long enough to KNOW, just
    KNOW, that addressing JSON today, in an unambiguous way, involves two
    things: JSON Reference, and JSON Pointer. However "unlikeable" JS= ON
    Pointer may look to people who are too used to JavaScript. JSON is NOT
    Javascript.

    --
    Francis Galiegue, fgaliegue@gmail.co= m
    JSON Schema: h= ttps://github.com/json-schema
    "It seems obvious [...] that at least some 'business intelligence&= #39;
    tools invest so much intelligence on the business side that they have
    nothing left for generating SQL queries" (St=E9phane Faroult, in "= ;The
    Art of SQL", ISBN 0-596-00894-5)



    --
    = Website: http://hallambaker.com/
    --bcaec54b4ac036a00b04ca12cf1f-- From fgaliegue@gmail.com Wed Sep 19 13:49:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E239A21E8064 for ; Wed, 19 Sep 2012 13:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.305 X-Spam-Level: X-Spam-Status: No, score=-3.305 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLHT3S-DUniY for ; Wed, 19 Sep 2012 13:49:58 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 21C3421E8034 for ; Wed, 19 Sep 2012 13:49:58 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so1888420vbb.31 for ; Wed, 19 Sep 2012 13:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=h6UfAc3jtHn/isE3AmGnsu7u5nNgRPyf1WoFskYv3rE=; b=efQJTTmVhuB9AyTD3jkKIcDv6N0KEHn/FeNTYRnBTEdong25hdKADg+we/5IxV8rYB JVwLK6bDq1ee5UQERk/pgkZ6kvmjxj6WG5dzb0pCwnFJAijm6jOxC78MFIr8cX4xkuUQ G5JcpDwla2yXMd85wgxSWgK3f4tWLKHTRBvEo12B/G+mjn48u+nsPgEpNIs/rHmiIrki AcfD89Nd6PJ2zTSc088bj/Q5AhBlkO+fsbi6girBKTGKOxv0rciG9eS+Xu6Bji0EUiRN s2jIpbc384i5h60lPesQGg+2IYQIBG0kBb2lGTN+X6dXbXcWqA0MABpab3V6CzxHuOug zF0Q== MIME-Version: 1.0 Received: by 10.52.27.229 with SMTP id w5mr2089143vdg.126.1348087797333; Wed, 19 Sep 2012 13:49:57 -0700 (PDT) Received: by 10.52.23.103 with HTTP; Wed, 19 Sep 2012 13:49:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 22:49:57 +0200 Message-ID: From: Francis Galiegue To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 20:49:59 -0000 On Wed, Sep 19, 2012 at 9:14 PM, Phillip Hallam-Baker wr= ote: > Excuse me but you just did refer to the 'Github JSON Schema group' > > And yes, I have read the purported JSON Schema spec. It is far too comple= x > with far too many options. > > Having written protocols using schemas, I can tell you for example that y= ou > don't need maxOccurs or minOccurs, the only options that make sense 95% o= f > the time are one or none [0..], exactly one [1..1], at least one [1..MAXI= NT] > or any [0...MAXINT]. > There is no maxOccurs, no minOccurs. Where on earth did you see that? No, you decidedly DID NOT make even an ATTEMPT to read the proposed specifications. It's in the README.md on the main page, damnit! > The spec replicates XML Schema in JSON. Yet another proof of my statement above. Read what is proposed before making any comments, and if you have any _constructive_ criticism, I'd be glad to hear it. Not before. --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From hallam@gmail.com Wed Sep 19 14:28:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A2821E8042 for ; Wed, 19 Sep 2012 14:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.641 X-Spam-Level: X-Spam-Status: No, score=-3.641 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCgn6m5TJIrp for ; Wed, 19 Sep 2012 14:28:39 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1340021E8034 for ; Wed, 19 Sep 2012 14:28:39 -0700 (PDT) Received: by oagn5 with SMTP id n5so1065211oag.31 for ; Wed, 19 Sep 2012 14:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EriydpaF90YMEQhIogoY2MEHgC/gUkzRTy5D+k/VslM=; b=pfWEsGXcEQZSgantJMB2/MOLHmKck2Rx24LjfNs+rBrHnzbChTRWT+4TROgPMSZLjz JbrhxdfVQOHaUhFnYMZthMUgL4AQSC0q/hLDbGN4hECNV9ACrInPfg4iF7GQ/EutlsmK xFvgcJCGtqWalYn2OhZdGyL7ACvn+D0+iTT8zZlmxyZ8rVdj/C8b2Rb18jXa6YSnV+id VpW5LqhstBZOnq6inhHyAfl+oKIqHA09nOwGvTaWmZBwo/jWWD/4bo0aGyHl9luxkYNW IicZJFYyia2qchifX9vEXCQCOSaFNSkqITokmRzccYaT6iv0ZDX3jv9IO1yTM2LcjVrE 0Twg== MIME-Version: 1.0 Received: by 10.60.29.72 with SMTP id i8mr4008110oeh.26.1348090118626; Wed, 19 Sep 2012 14:28:38 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Wed, 19 Sep 2012 14:28:38 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 17:28:38 -0400 Message-ID: From: Phillip Hallam-Baker To: Francis Galiegue Content-Type: multipart/alternative; boundary=e89a8fb1f806a55b9b04ca14b057 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 21:28:40 -0000 --e89a8fb1f806a55b9b04ca14b057 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 19, 2012 at 4:49 PM, Francis Galiegue wrote: > On Wed, Sep 19, 2012 at 9:14 PM, Phillip Hallam-Baker > wrote: > > Excuse me but you just did refer to the 'Github JSON Schema group' > > > > And yes, I have read the purported JSON Schema spec. It is far too > complex > > with far too many options. > > > > Having written protocols using schemas, I can tell you for example that > you > > don't need maxOccurs or minOccurs, the only options that make sense 95% > of > > the time are one or none [0..], exactly one [1..1], at least one > [1..MAXINT] > > or any [0...MAXINT]. > > > > There is no maxOccurs, no minOccurs. Where on earth did you see that? > http://tools.ietf.org/html/draft-zyp-json-schema-03 5.13 . minItems . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.14 . maxItems . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.13 . minItems This attribute defines the minimum number of values in an array when the array is the instance value. 5.14 . maxItems This attribute defines the maximum number of values in an array when the array is the instance value. That would seem to be the same as the XML Schema constraints only someone changed the name. No, you decidedly DID NOT make even an ATTEMPT to read the proposed > specifications. It's in the README.md on the main page, damnit! I read the Internet draft. If you are refering to a different spec then we have an even bigger problem. > > The spec replicates XML Schema in JSON. > > Yet another proof of my statement above. > > Read what is proposed before making any comments, and if you have any > _constructive_ criticism, I'd be glad to hear it. > > Not before. I think that you folk are giving a good idea a bad name here. You are producing the ADA of schema languages. -- Website: http://hallambaker.com/ --e89a8fb1f806a55b9b04ca14b057 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Wed, Sep 19, 2012 at 4:49 PM, Francis= Galiegue <fgaliegue@gmail.com> wrote:
    On Wed, Sep 19, 2012 at 9:14 PM, Phillip Hallam-Baker <= ;hallam@gmail.com> wrote:
    > Excuse me but you just did refer to the 'Github JSON Schema group&= #39;
    >
    > And yes, I have read the purported JSON Schema spec. It is far too com= plex
    > with far too many options.
    >
    > Having written protocols using schemas, I can tell you for example tha= t you
    > don't need maxOccurs or minOccurs, the only options that make sens= e 95% of
    > the time are one or none [0..], exactly one [1..1], at least one [1..M= AXINT]
    > or any [0...MAXINT].
    >

    There is no maxOccurs, no minOccurs. Where on earth did you see that?= 


        5.13. minItems . . . . . . . . . .=
 . . . . . . . . . . . . . . . 11
     5.14. maxItems . . . . . . . . . . . . . . . . . . . . . . . . .=
 11=


    
5.13.  minItems
    

   This attribute defines the minimum number of values in an array when
   the array is the instance value.


    =
5.14.  maxItems
    
    

   This attribute defines the maximum number of values in an array when
   the array is the instance value.
    =A0
    That woul= d seem to be the same as the XML Schema constraints only someone changed th= e name.

    No, you decidedly DID NOT make even an ATTEMPT to read the proposed
    specifications. It's in the README.md on the main page, damnit!

    I read the Internet draft. If you are refering to = a different spec then we have an even bigger problem.

    =A0
    > The spec replicates XML Schema in JSON.

    Yet another proof of my statement above.

    Read what is proposed before making any comments, and if you have any
    _constructive_ criticism, I'd be glad to hear it.

    Not before.


    I think that you= folk are giving a good idea a bad name here.

    You = are producing the ADA of schema languages. =A0


    --
    Website: http://h= allambaker.com/

    --e89a8fb1f806a55b9b04ca14b057-- From sm@resistor.net Wed Sep 19 14:35:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3836721E80AB for ; Wed, 19 Sep 2012 14:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k1r9vJMJAY6 for ; Wed, 19 Sep 2012 14:35:06 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD1921E8042 for ; Wed, 19 Sep 2012 14:35:06 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8JLZ1w4019063 for ; Wed, 19 Sep 2012 14:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1348090505; bh=AbCs79+oa+zc2W8YOm3lZ1MC0crAgNG41dH3gzqNUfg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=hfgaVBYHoDw6YFBgeBefObbZw6ahFddEE1/Nlc1DgEoTm6KQYrT8DdvsXIS01Q//p gWR1uFzk769ClWO8GNfYcbMffMNA9/keMio5dm4eIzvp6+A2BslHeaBvsAew129SRB 1DaUoIGfm9SMvIAW+F7wiZOGCUEaFRVln7cD/FTI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1348090505; i=@resistor.net; bh=AbCs79+oa+zc2W8YOm3lZ1MC0crAgNG41dH3gzqNUfg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=oMUli1aUW5sZR72oyoPJzE9/oLGVs6GHGRes1mB+xEmDqaBwHpFPbPDnzJIGcdrov bwglDszr02rpFwKTgxPRnuniFoWunaxgHMI358Vc0QcuOPMnF38o02Yabg3xKlMerP EQNKQYe7ZMmJckjffVj6oBh97jY3xMwYsQc/6/MA= Message-Id: <6.2.5.6.2.20120919140051.0a168870@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 19 Sep 2012 14:20:53 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 21:35:07 -0000 At 06:11 18-09-2012, Barry Leiba wrote: >Apart from that, Your Friendly ADs have been discussing the >possibility of reclassifying it as Proposed Standard. Comments about >such a move are welcome on this thread. There is an erratum. A reclassification would require ignoring it. I'd suggest a quick open and shut path. My guess is that it might not be quick*. The Security Considerations section of RFC 4627 seems to be on the economical side. Regards, -sm * JSON seems to be the IETF secret sauce these days. From fgaliegue@gmail.com Wed Sep 19 14:36:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BE721E80B2 for ; Wed, 19 Sep 2012 14:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.28 X-Spam-Level: X-Spam-Status: No, score=-3.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwhGHIMVaXKH for ; Wed, 19 Sep 2012 14:36:11 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF25221E8042 for ; Wed, 19 Sep 2012 14:36:11 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so1938878vbb.31 for ; Wed, 19 Sep 2012 14:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LiW/biN2zkOWv4R2Vk7zBMLXycctDdNn7HtjchIMNPg=; b=wuC7Q9VkoMRTVpStpB6pp1pGqeGcnnNOMM34pQwHDSnFrZmStE43hy8FZ0Hc6xacvG 3TwYDOGIrvJddrszgV32c22/dJ7PBvT3Trc9l2FaoPtWT+AFgUed8J2MrFFEZh31eDuG It/0G+bi4zZjV/Vz7p7VPdb6Nzi/TI88zeqdeAuDy4YylAd7mzrUArHUqBhkY2sR0H/w kV9N7GyzGDjNtFomql//I1yA9MqXyKXejjpCzwtVboz5+bCZDC4x4UY2rRLXnhTJTdxA wV1rDUjpxhNkv+6RuDsqz5cO6dJ2Aum00qaWrARBRrKyOO53SwY9S3HdGQ9TpOjVP4/G KTvA== MIME-Version: 1.0 Received: by 10.220.221.72 with SMTP id ib8mr2694081vcb.25.1348090571112; Wed, 19 Sep 2012 14:36:11 -0700 (PDT) Received: by 10.52.23.103 with HTTP; Wed, 19 Sep 2012 14:36:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 23:36:11 +0200 Message-ID: From: Francis Galiegue To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 21:36:12 -0000 On Wed, Sep 19, 2012 at 11:28 PM, Phillip Hallam-Baker w= rote: [...] >> >> There is no maxOccurs, no minOccurs. Where on earth did you see that? > > > http://tools.ietf.org/html/draft-zyp-json-schema-03 > > 5.13. minItems . . . . . . . . . . . . . . . . . . . . . . . . . 11 > 5.14. maxItems . . . . . . . . . . . . . . . . . . . . . . . . . 11 > [...] > > That would seem to be the same as the XML Schema constraints only someone > changed the name. > This is the old specification. It is being redone. And you don't understand JSON at all, do you? Can you tell a JSON array from a JSON object? From what I read: no... >> No, you decidedly DID NOT make even an ATTEMPT to read the proposed >> specifications. It's in the README.md on the main page, damnit! > > > I read the Internet draft. If you are refering to a different spec then w= e > have an even bigger problem. > YOU have a problem. You don't know how to read. --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From hallam@gmail.com Wed Sep 19 14:49:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8304721E80B6 for ; Wed, 19 Sep 2012 14:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.625 X-Spam-Level: X-Spam-Status: No, score=-3.625 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0NDeDVBUA6L for ; Wed, 19 Sep 2012 14:49:10 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B22621E80B4 for ; Wed, 19 Sep 2012 14:49:10 -0700 (PDT) Received: by oagn5 with SMTP id n5so1083370oag.31 for ; Wed, 19 Sep 2012 14:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pQwj+cAvJavmGFwKo1mfBDrI3ErTTBZ6mRUmaJIBHNA=; b=0LaoGPvMDRgemjIZh1ikCgmYapc/5oy0Eem6KKdQl7Eo+3fYxVzN0vfWvEUbbBZbme mYeuFndqInnl94ValJnRfPsNbfuEqxW1Cr+7HxegO1qgO2UnKiLDo2zWcuQQ93zluyRW +UiW9iAD6w9jxL1+lCf3AZHSxMb6xHABpHJXjMiZB1gko3pvVMuICApIwx6X5MCK5d6l F1QtI5dgdrE67htp9HZSNXufpEgIZtC8Q0x2icV/9ouWk2qRILMwekTOLbKHRjV1E/FZ Cr7zPmv80z33WoaKioykp2mF9NHwTvYjaV6Zl3L4LsxDBI6K6FRzLg2KaPFvVXgTU1CS CSAQ== MIME-Version: 1.0 Received: by 10.60.170.229 with SMTP id ap5mr3947880oec.101.1348091350219; Wed, 19 Sep 2012 14:49:10 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Wed, 19 Sep 2012 14:49:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 17:49:10 -0400 Message-ID: From: Phillip Hallam-Baker To: Francis Galiegue Content-Type: multipart/alternative; boundary=bcaec54b4ac00dfacd04ca14fa20 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 21:49:11 -0000 --bcaec54b4ac00dfacd04ca14fa20 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 19, 2012 at 5:36 PM, Francis Galiegue wrote: > On Wed, Sep 19, 2012 at 11:28 PM, Phillip Hallam-Baker > wrote: > [...] > >> > >> There is no maxOccurs, no minOccurs. Where on earth did you see that? > > > > > > http://tools.ietf.org/html/draft-zyp-json-schema-03 > > > > 5.13. minItems . . . . . . . . . . . . . . . . . . . . . . . . . 11 > > 5.14. maxItems . . . . . . . . . . . . . . . . . . . . . . . . . 11 > > > [...] > > > > That would seem to be the same as the XML Schema constraints only someone > > changed the name. > > > > This is the old specification. It is being redone. > So when you were attacking me for not reading the specification you were referring to a version that has not yet been submitted as a draft? You really are a piece of work. And you don't understand JSON at all, do you? Can you tell a JSON > array from a JSON object? From what I read: no... I think that we are reaching the point where I suggest that you no longer be heard. You keep making these personal attacks. In fact I think they have somewhat marred your whole approach from the start. You really don't have standing to lecture other people on what they do or do not understand. I didn't say I was referring to objects when I mentioned the maxItems thing. I used the XML Schema terminology but that hardly changes my case that the feature is unnecessary in XML Schema and almost certainly unnecessary here. Before you dig yourself in deeper I suggest you find out who you are directing your attacks at and decide whether my being unable to understand you would be a fault of mine, a defect in your presentation or a confusion in the case you present. > >> No, you decidedly DID NOT make even an ATTEMPT to read the proposed > >> specifications. It's in the README.md on the main page, damnit! > > > > > > I read the Internet draft. If you are refering to a different spec then > we > > have an even bigger problem. > > > > YOU have a problem. You don't know how to read. I don't know how to read documents that have not been submitted. Argument from undisclosed specification is not exactly convincing. -- Website: http://hallambaker.com/ --bcaec54b4ac00dfacd04ca14fa20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Wed, Sep 19, 2012 at 5:36 PM, Francis= Galiegue <fgaliegue@gmail.com> wrote:
    On Wed, Sep 19, 2012 at 11:28 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
    [...]
    >>
    >> There is no maxOccurs, no minOccurs. Where on earth did you see th= at?
    >
    >
    > http://tools.ietf.org/html/draft-zyp-json-schema-03
    >
    > =A0 =A0 5.13. minItems . . . . . . . . . . . . . . . . . . . . . . . .= . 11
    > =A0 =A0 =A05.14. maxItems . . . . . . . . . . . . . . . . . . . . . . = . . . 11
    >
    [...]
    >
    > That would seem to be the same as the XML Schema constraints only some= one
    > changed the name.
    >

    This is the old specification. It is being redone.

    So when you were attacking me for not reading the specifi= cation you were referring to a version that has not yet been submitted as a= draft?

    You really are a piece of work.


    And you don't understand JSON at all, do you? Can you tell a JSON
    array from a JSON object? From what I read: no...

    I think that we are reaching the point where I suggest that you no l= onger be heard. You keep making these personal attacks. In fact I think the= y have somewhat marred your whole approach from the start.

    You really don't have standing to lecture other peo= ple on what they do or do not understand.=A0

    I did= n't say I was referring to objects when I mentioned the maxItems thing.= I used the XML Schema terminology but that hardly changes my case that the= feature is unnecessary in XML Schema and almost certainly unnecessary here= .


    Before you dig yourself in deeper I sugg= est you find out who you are directing your attacks at and decide whether m= y being unable to understand you would be a fault of mine, a defect in your= presentation or a confusion in the case you present.

    =A0
    >> No, you decidedly DID NOT make even an ATTEMPT to read the propose= d
    >> specifications. It's in the README.md on the main page, damnit= !
    >
    >
    > I read the Internet draft. If you are refering to a different spec the= n we
    > have an even bigger problem.
    >

    YOU have a problem. You don't know how to read.
    =
    I don't know how to read documents that have not been su= bmitted.

    Argument from undisclosed specification i= s not exactly convincing.

    --
    Website: ht= tp://hallambaker.com/

    --bcaec54b4ac00dfacd04ca14fa20-- From fgaliegue@gmail.com Wed Sep 19 14:49:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179E721F845E for ; Wed, 19 Sep 2012 14:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2AMv0HPOfoh for ; Wed, 19 Sep 2012 14:49:34 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B45521F8452 for ; Wed, 19 Sep 2012 14:49:33 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1888824vcb.31 for ; Wed, 19 Sep 2012 14:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nAeGQB2zdJ+ijpDFdVy6X1mxlj5xp0V1ECMhr5y8fe4=; b=JWdPmsQyc9pGm2q+Vjlw47xv/k2LyALH/k6rwQIztHo+e+hkw9rkhoZsuPz2Tz2MUW g58tOXW0ec9jr5pRe9UbXAAP2EjLSzT4VJHzeuAZG9TVNv7f51EcFn+7vF5uA9KoyBYc v7gyZ0J+XBXqIZx3M6U7Uv1L+HSOViA0uGgoGU4UBqiq0Q9MJz1Heweem/ghzi0UrHtf zf2LdpKY0X0MUCW5MxpSPmVwlmGDW2bTjBaIvKrfbZmDkx1faogvp/naSKSnUR9h8CnG Fyg3nqpfqNZWiZcZP1X20Ceur+axr/xH0oIHWLi3A7Eekp3zOPCBf7jdAfKOkOlf54hJ QHmQ== MIME-Version: 1.0 Received: by 10.52.64.209 with SMTP id q17mr2232018vds.32.1348091371743; Wed, 19 Sep 2012 14:49:31 -0700 (PDT) Received: by 10.52.23.103 with HTTP; Wed, 19 Sep 2012 14:49:31 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 23:49:31 +0200 Message-ID: From: Francis Galiegue To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 21:49:35 -0000 On Wed, Sep 19, 2012 at 11:36 PM, Francis Galiegue wr= ote: > On Wed, Sep 19, 2012 at 11:28 PM, Phillip Hallam-Baker = wrote: > [...] >>> >>> There is no maxOccurs, no minOccurs. Where on earth did you see that? >> >> >> http://tools.ietf.org/html/draft-zyp-json-schema-03 >> >> 5.13. minItems . . . . . . . . . . . . . . . . . . . . . . . . . 11 >> 5.14. maxItems . . . . . . . . . . . . . . . . . . . . . . . . . 11 >> > [...] >> >> That would seem to be the same as the XML Schema constraints only someon= e >> changed the name. >> > > This is the old specification. It is being redone. > > And you don't understand JSON at all, do you? Can you tell a JSON > array from a JSON object? From what I read: no... > Hint: this is a proposed text for the next version of the specification: "JSON Schema does not mandate that an instance be of a particular type: JSON Schema can process any JSON value, including null" maxOccurs and minOccurs are _meaningless_ to JSON. --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From hallam@gmail.com Wed Sep 19 14:56:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FC821E80AF for ; Wed, 19 Sep 2012 14:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.909 X-Spam-Level: X-Spam-Status: No, score=-3.909 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHeV3SlxfBc2 for ; Wed, 19 Sep 2012 14:56:39 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED6721E8034 for ; Wed, 19 Sep 2012 14:56:39 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1720578obb.31 for ; Wed, 19 Sep 2012 14:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ECabNUyx1Wm55vR5kzFhR016qrsSG5dmfdheLtQAMyg=; b=iSs7rMw9KeYd3jEyCGXPLjN/RNm9RqV4JnZVcWekoHaFrT+sZmoB11ywqisls3H5Hz hiAMSyxd59lhe4NfatVGeUWYHxrLGB2uf2Cl6+9oBcu/n+R8oXYpIqU3H6wXjBkwIdk4 wtjCVCxzj85MIM8Ddb3SZkMfP4xuXtMo/EPxcGhEUjtoSTPSe/LHGC5VefmROCWnhPch objNkAucWJrj4IZ0ZCF90goyYw3irmi8L6tQjLJy4u6BkThJRA5PizUzVoAOAsj0OaX1 2kVCT72Ik4tezXfh02G/wsHr4nclgN0zOxE1kv2tP2Yz/SY5CKE4PrncOx8uVd1Vd7Xf rryw== MIME-Version: 1.0 Received: by 10.60.11.34 with SMTP id n2mr4109105oeb.18.1348091798853; Wed, 19 Sep 2012 14:56:38 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Wed, 19 Sep 2012 14:56:38 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120919140051.0a168870@resistor.net> References: <6.2.5.6.2.20120919140051.0a168870@resistor.net> Date: Wed, 19 Sep 2012 17:56:38 -0400 Message-ID: From: Phillip Hallam-Baker To: SM Content-Type: multipart/alternative; boundary=e89a8fb206e6cb991604ca151446 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 21:56:40 -0000 --e89a8fb206e6cb991604ca151446 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 19, 2012 at 5:20 PM, SM wrote: > At 06:11 18-09-2012, Barry Leiba wrote: > >> Apart from that, Your Friendly ADs have been discussing the >> possibility of reclassifying it as Proposed Standard. Comments about >> such a move are welcome on this thread. >> > > There is an erratum. A reclassification would require ignoring it. I'd > suggest a quick open and shut path. My guess is that it might not be > quick*. The Security Considerations section of RFC 4627 seems to be on the > economical side. > > Regards, > -sm > The security considerations is definitely light to the point of being non existent. But as with many specs, there really isn't a set of security considerations that it specific to JSON data format. If the spec has to be rewritten then I would like to see the security considerations address the general security issues so that we can do it once and not have to repeat it in other documents. I would also like some clarifications. But I don't see that as a reason for blocking uprating the spec as is if that is an option. We still get a second bite at the revisions cherry in the Proposed to Standard move. I think a new RFC would be necessary for that. -- Website: http://hallambaker.com/ --e89a8fb206e6cb991604ca151446 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Wed, Sep 19, 2012 at 5:20 PM, SM <sm@r= esistor.net> wrote:
    At 06:11 18-09-2012, Barry Leiba wrote:
    Apart from that, Your Friendly ADs have been discussing the
    possibility of reclassifying it as Proposed Standard. =A0Comments about
    such a move are welcome on this thread.

    There is an erratum. =A0A reclassification would require ignoring it. =A0I&= #39;d suggest a quick open and shut path. =A0My guess is that it might not = be quick*. =A0The Security Considerations section of RFC 4627 seems to be o= n the economical side.

    Regards,
    -sm

    The security considerations is defi= nitely light to the point of being non existent. But as with many specs, th= ere really isn't a set of security considerations that it specific to J= SON data format.=A0

    If the spec has to be rewritten then I would like to se= e the security considerations address the general security issues so that w= e can do it once and not have to repeat it in other documents. I would also= like some clarifications. But I don't see that as a reason for blockin= g uprating the spec as is if that is an option.

    We still get a second bite at the revisions cherry in the Propose= d to Standard move. I think a new RFC would be necessary for that.

    --
    Website: http://hallambaker.com/

    --e89a8fb206e6cb991604ca151446-- From nico@cryptonector.com Wed Sep 19 14:56:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B4B21E80B6 for ; Wed, 19 Sep 2012 14:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ml6wP8Zpdin for ; Wed, 19 Sep 2012 14:56:51 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 0E56721E8034 for ; Wed, 19 Sep 2012 14:56:51 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id D4E39264060 for ; Wed, 19 Sep 2012 14:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=PJNPyjKSscyLyN4zhbgH 2G6RarI=; b=fLrH/GuSSHAwH0D8wseznXm6AvkHRyq3U/I0qA5+vxMQ1dASA0cY tR4RWsIItvvgbVpxGpHEHnYiREaAkC9JctlBO3eBFVXcEKopKrhi9Z8ZRbs6iC4M 792lewt7k9eEFP+sMgY0NiFUxTMxppBvmzFJLjYS456/auvzutwnYuU= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id B6A2826405D for ; Wed, 19 Sep 2012 14:56:50 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so1141274pbb.31 for ; Wed, 19 Sep 2012 14:56:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.228.234 with SMTP id sl10mr1618283pbc.25.1348091810422; Wed, 19 Sep 2012 14:56:50 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 14:56:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 16:56:50 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 21:56:51 -0000 On Wed, Sep 19, 2012 at 12:59 PM, Phillip Hallam-Baker wrote: > My observation about XML Schema and ASN.1 schema is that the groups > producing them should not have been allowed a monopoly. The ASN.1 case is Huh? What's the complaint here? That you weren't there? Or in the committee? Or that a committee (or WG, or whatever) was involved? Why bother standardizing anything if there are to be no committees/WGs? How would we do that? Would there be SDOs that only rubber-stamp standards proposals brought to them but which can make no changes to those proposals, just yay/nay? > actually understandable as it was a schema design group that developed the > encodings. But even so it was design by a committee. wat? First you complain about someone having a monopoly, but then you say that as long as it's the same people that developed some other related standard it's OK? But then... you're asking for a monopoly and thus contradicting yourself. If you have comments on proposals, or as to how to improve existing standards, then state them. If you want a different process to apply to standardization of JSON Schema, well, say so, but this is the IETF, and the IETF process will apply at the IETF. If you want to change the IETF process then make proposals to that effect. Nico -- From fgaliegue@gmail.com Wed Sep 19 15:04:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0326121F84FC for ; Wed, 19 Sep 2012 15:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.561 X-Spam-Level: X-Spam-Status: No, score=-4.561 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttfZpZPPzuaZ for ; Wed, 19 Sep 2012 15:04:38 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0380521F84F9 for ; Wed, 19 Sep 2012 15:04:35 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so1965239vbb.31 for ; Wed, 19 Sep 2012 15:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/5kaDE8UeulbyP7+/rl8WcbTTK+TXVqVUNf2DYBnKkI=; b=DWNsThfVqFlvZHImDuU01AptiPrJg8rBFyxfb7y47rrOFnkq1IxEKdqvsH7tb0DIch Gh7jatkuyPHMhpTY4sl2xUjk85q3tmJFA3gToMyNfHs9VNVmRDsiJU1WyAZYW5M4yEpv SNuNS5xYQP6oF69arln3FJvBpdDVl9f/4V26nhVC6BeO1Zcvnt3sH6+zg8692RrLWHVn 0fCSNNZ/ZMzWfRUS9+8wAGSjK65YN1hhLAA8bP1RnleOW67RHehaX/Y9W4jKleRaWGne 6E10utILDuhwtbpLp2KBPWpdRIPvGeoyFocxW5je7Nkt9ez+dtLKzay8GrDfBSAXudYp fSsw== MIME-Version: 1.0 Received: by 10.58.209.73 with SMTP id mk9mr2837408vec.25.1348092266023; Wed, 19 Sep 2012 15:04:26 -0700 (PDT) Received: by 10.52.23.103 with HTTP; Wed, 19 Sep 2012 15:04:25 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Sep 2012 00:04:25 +0200 Message-ID: From: Francis Galiegue To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 22:04:39 -0000 On Wed, Sep 19, 2012 at 11:49 PM, Phillip Hallam-Baker w= rote: > > > On Wed, Sep 19, 2012 at 5:36 PM, Francis Galiegue > wrote: >> >> On Wed, Sep 19, 2012 at 11:28 PM, Phillip Hallam-Baker >> wrote: >> [...] >> >> >> >> There is no maxOccurs, no minOccurs. Where on earth did you see that? >> > >> > >> > http://tools.ietf.org/html/draft-zyp-json-schema-03 >> > >> > 5.13. minItems . . . . . . . . . . . . . . . . . . . . . . . . . 1= 1 >> > 5.14. maxItems . . . . . . . . . . . . . . . . . . . . . . . . . = 11 >> > >> [...] >> > >> > That would seem to be the same as the XML Schema constraints only >> > someone >> > changed the name. >> > >> >> This is the old specification. It is being redone. > > > So when you were attacking me for not reading the specification you were > referring to a version that has not yet been submitted as a draft? > > You really are a piece of work. > So are you, sir, not to understand that minItems and maxItems relate to the _number of elements of an array instance_. Had you read the proposed specifications, you'd see that they say exactly that. To the letter. And you'd have remembered, also, that I _explicitly said_ that they were not submitted yet because feedback was needed. > >> And you don't understand JSON at all, do you? Can you tell a JSON >> array from a JSON object? From what I read: no... > > > I think that we are reaching the point where I suggest that you no longer= be > heard. I think that we are reaching a point where you should go and read RFC 4627. > You keep making these personal attacks. In fact I think they have > somewhat marred your whole approach from the start. > > You really don't have standing to lecture other people on what they do or= do > not understand. > Go see who is on the member board of the GitHub organization. I just happen to be the one who does most of the work out there. And standing or not, who cares? You keep going on with senseless arguments, who is not to be heard? I want to get work done _right_, and this is _precisely_ for this reason that specs are not submitted yet. [...] > > Before you dig yourself in deeper I suggest you find out who you are > directing your attacks at and decide whether my being unable to understan= d > you would be a fault of mine, a defect in your presentation or a confusio= n > in the case you present. > I know the answer to that already. --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From nico@cryptonector.com Wed Sep 19 15:11:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64E321F8503 for ; Wed, 19 Sep 2012 15:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxU1DlgR4tRX for ; Wed, 19 Sep 2012 15:11:44 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 2F00021F8501 for ; Wed, 19 Sep 2012 15:11:44 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id BF29D67C06E for ; Wed, 19 Sep 2012 15:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=6cE1MvlYOLduAO8+TvMA q4OfiXg=; b=sHVuAg2OqctR4pC7Gyi9qG8uBAO3pcDA1ZIwnISvvOZa3Vf6QRvu /rEoMAgv+Mtti8xlEqpcSO75A7TabCVqN3KUle7/JFC+iI+xG1Xq8/P885GWVdf3 rbdaUdtqDH6FV3jBtJ5x80BeEDi5FbH7jw3ZeoDn0jXZ/OrkZsCLbi0= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id A5A0867C06B for ; Wed, 19 Sep 2012 15:11:43 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so1163885pbb.31 for ; Wed, 19 Sep 2012 15:11:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.195 with SMTP id ru3mr1361554pbc.149.1348092703353; Wed, 19 Sep 2012 15:11:43 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 15:11:43 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 17:11:43 -0500 Message-ID: From: Nico Williams To: Francis Galiegue Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 22:11:44 -0000 On Wed, Sep 19, 2012 at 5:04 PM, Francis Galiegue wrote: > And you'd have remembered, also, that I _explicitly said_ that they > were not submitted yet because feedback was needed. Well, we submit Internet-Drafts because feedback is needed :) It's quite OK to submit a badly incomplete/unfinished I-D; indeed, I'd say that that's the only way to get started and make progress towards a Standards-Track RFC. Nico -- From jasnell@gmail.com Wed Sep 19 15:17:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6EC21F84AE for ; Wed, 19 Sep 2012 15:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDX93Op2NvCO for ; Wed, 19 Sep 2012 15:17:36 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1EE121E8034 for ; Wed, 19 Sep 2012 15:17:35 -0700 (PDT) Received: by weyx48 with SMTP id x48so945138wey.31 for ; Wed, 19 Sep 2012 15:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mIVq4gwsKF9ZsQaD2yAC6KiVfE8Sg98u5+//muL5KMs=; b=tCCkOttvuWziDVSm0XzcCpTbxRV2UfBjEQkkKXyx8vQHHsRop6qzakxpCfI9nCq7KD sf+Yj+jy+Pv0hJPMl7AN6i1drQM4Ydy7U19D5KZUz5RgXcupQbGTVB+9wgdqHpf01Nan tKxlVpc3ZzV/hkvZP+zGepjIPg/o5iIdIlucgsieqaN4cOYcwLljo2Y1WS4OIB5gJj2A iGCVQVlpgL5EGTeX4wMdQdt+IrSXpMSjCBvrgKj7YbwP64O5+w/ngpXINVIHj4oKNj8Z dfiRfeXwuIudH+Rmk1JgLmGfLu9UtpGmU8eWvJFBbKwdSdHjgoKunkFu8zPv7i1pVd3S Ku2w== MIME-Version: 1.0 Received: by 10.216.194.143 with SMTP id m15mr2460605wen.128.1348093054916; Wed, 19 Sep 2012 15:17:34 -0700 (PDT) Received: by 10.223.182.4 with HTTP; Wed, 19 Sep 2012 15:17:34 -0700 (PDT) Received: by 10.223.182.4 with HTTP; Wed, 19 Sep 2012 15:17:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 15:17:34 -0700 Message-ID: From: James M Snell To: Nico Williams Content-Type: multipart/alternative; boundary=0016e6da2e7fa9984304ca155f1b Cc: IETF Apps Discuss Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 22:17:36 -0000 --0016e6da2e7fa9984304ca155f1b Content-Type: text/plain; charset=UTF-8 +1 ... as much as I would hate to jump into the middle of this pissing match, let's not forget that IDs are not finished products. If there have been incremental updates to the spec since it was last published, please post the update so it can be properly reviewed.... even if its not yet done. On Sep 19, 2012 3:11 PM, "Nico Williams" wrote: > On Wed, Sep 19, 2012 at 5:04 PM, Francis Galiegue > wrote: > > And you'd have remembered, also, that I _explicitly said_ that they > > were not submitted yet because feedback was needed. > > Well, we submit Internet-Drafts because feedback is needed :) It's > quite OK to submit a badly incomplete/unfinished I-D; indeed, I'd say > that that's the only way to get started and make progress towards a > Standards-Track RFC. > > Nico > -- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --0016e6da2e7fa9984304ca155f1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    +1 ... as much as I would hate to jump into the middle of th= is pissing match, let's not forget that IDs are not finished products. = If there have been incremental updates to the spec since it was last publis= hed, please post the update so it can be properly reviewed.... even if its = not yet done.

    On Sep 19, 2012 3:11 PM, "Nico Williams&quo= t; <nico@cryptonector.com&g= t; wrote:
    On Wed, Sep 19, 2012 at 5:04 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:
    > And you'd have remembered, also, that I _explicitly said_ that the= y
    > were not submitted yet because feedback was needed.

    Well, we submit Internet-Drafts because feedback is needed :) =C2=A0It'= s
    quite OK to submit a badly incomplete/unfinished I-D; indeed, I'd say that that's the only way to get started and make progress towards a
    Standards-Track RFC.

    Nico
    --
    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss
    --0016e6da2e7fa9984304ca155f1b-- From hallam@gmail.com Wed Sep 19 16:06:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE81621F8510 for ; Wed, 19 Sep 2012 16:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFkjkbyG1pW3 for ; Wed, 19 Sep 2012 16:06:56 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D2B0521F84FA for ; Wed, 19 Sep 2012 16:06:55 -0700 (PDT) Received: by iabz21 with SMTP id z21so1343505iab.31 for ; Wed, 19 Sep 2012 16:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ig5bef46DfV8/uYJ26fDY8eIZiOEdTN+UaRdCjWak9A=; b=Pqrk43GZfL/iMPsuwbX8BwBUwumf5wc+OPvrdm0oJU3T3agKinBKcp2vIp+v1vLK+x 8WJlZxn4ouZnhx3QjSXgKPEXwUO9Fzeaes8QmDOJ0F+pdQ+5+E2VcnRztO2b9kst6pG/ wDISos4VkqylGmJPS0N4iYsJuaNR2XImeMoa3NeVJ6rNJsBbyg4SakfkOBfDhNYNq8M2 oGpKZbEF9rNSxgdbtNBbCARMlQ3m86qAoAPfrV1nCuLHlO7aHQ4hHflsj1WeOtSTV2Ai urozfZVIUkuhXCe2nFRh+xaa1nhb6mHwwKZYV6tvchM/1RJcQBRRbLr/V5k8h72JZzYo R/hg== MIME-Version: 1.0 Received: by 10.182.145.35 with SMTP id sr3mr3983098obb.98.1348096015226; Wed, 19 Sep 2012 16:06:55 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Wed, 19 Sep 2012 16:06:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 19:06:55 -0400 Message-ID: From: Phillip Hallam-Baker To: James M Snell Content-Type: multipart/alternative; boundary=f46d044630781c559004ca1610ac Cc: IETF Apps Discuss Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 23:06:57 -0000 --f46d044630781c559004ca1610ac Content-Type: text/plain; charset=ISO-8859-1 IDs are not finished products but that does not entitle Mr insults-a-lot to attack me for not having read a version of the ID that has not been submitted yet. I made comments on the version of the ID they submitted. It is overly complex and solves a problem that in my experience does not exist. In response I was attacked as an imbecile and accused of not reading their spec. Now it might just be me but I think that being a board member of Github does not entitle people to go round calling people imbeciles if they are not capable of mind reading. Now I did overlook the statement in the introduction to RFC 4627 stating that objects can appear in any order. But that is not where I would expect to find a normative statement and I don't think many others would. I don't think that excuses Mr Galiegue's behavior. A schema is a useful tool for writing specifications and as an input to coding tools. The spec in question seems to be designed to support schema validation and nothing else. Which is really weird since schema validation has not been found to be particularly useful in the XML world. The constraints that can be described in a schema tend to be a subset of the constraints that are needed by applications. So applications tend to end up having to repeat the schema validation. On Wed, Sep 19, 2012 at 6:17 PM, James M Snell wrote: > +1 ... as much as I would hate to jump into the middle of this pissing > match, let's not forget that IDs are not finished products. If there have > been incremental updates to the spec since it was last published, please > post the update so it can be properly reviewed.... even if its not yet done. > On Sep 19, 2012 3:11 PM, "Nico Williams" wrote: > >> On Wed, Sep 19, 2012 at 5:04 PM, Francis Galiegue >> wrote: >> > And you'd have remembered, also, that I _explicitly said_ that they >> > were not submitted yet because feedback was needed. >> >> Well, we submit Internet-Drafts because feedback is needed :) It's >> quite OK to submit a badly incomplete/unfinished I-D; indeed, I'd say >> that that's the only way to get started and make progress towards a >> Standards-Track RFC. >> >> Nico >> -- >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- Website: http://hallambaker.com/ --f46d044630781c559004ca1610ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable IDs are not finished products but that does not entitle Mr insults-a-lot to= attack me for not having read a version of the ID that has not been submit= ted yet. I made comments on the version of the ID they submitted. It is ove= rly complex and solves a problem that in my experience does not exist.

    In response I was attacked as an imbecile and accused of not= reading their spec. Now it might just be me but I think that being a board= member of Github does not entitle people to go round calling people imbeci= les if they are not capable of mind reading.


    Now I did overlook the statement in the = introduction to RFC 4627 stating that objects can appear in any order. But = that is not where I would expect to find a normative statement and I don= 9;t think many others would. I don't think that excuses Mr=A0Galiegue's behavior.=


    A schema is a useful tool for writing specific= ations and as an input to coding tools. The spec in question seems to be de= signed to support schema validation and nothing else. Which is really weird= since schema validation has not been found to be particularly useful in th= e XML world. The constraints that can be described in a schema tend to be a= subset of the constraints that are needed by applications. So applications= tend to end up having to repeat the schema validation.


    On Wed, Sep 19, 2012 at = 6:17 PM, James M Snell <jasnell@gmail.com> wrote:

    +1 ... as much as I would hate to jump into the middle of th= is pissing match, let's not forget that IDs are not finished products. = If there have been incremental updates to the spec since it was last publis= hed, please post the update so it can be properly reviewed.... even if its = not yet done.

    On Sep 19, 2012 3:11 PM, = "Nico Williams" <nico@cryptonector.com> wrote:
    =
    On Wed, Sep 19, 2012 at 5:04 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:
    > And you'd have remembered, also, that I _explicitly said_ that the= y
    > were not submitted yet because feedback was needed.

    Well, we submit Internet-Drafts because feedback is needed :) =A0It's quite OK to submit a badly incomplete/unfinished I-D; indeed, I'd say that that's the only way to get started and make progress towards a
    Standards-Track RFC.

    Nico
    --
    _______________________________________________
    apps-discuss mailing list
    apps-discuss@iet= f.org
    https://www.ietf.org/mailman/listinfo/apps-discuss

    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss




    --
    Website:= http://hallambaker.com/

    --f46d044630781c559004ca1610ac-- From hallam@gmail.com Wed Sep 19 16:21:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576A121E804E for ; Wed, 19 Sep 2012 16:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.894 X-Spam-Level: X-Spam-Status: No, score=-3.894 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAJ6J8EXfMnW for ; Wed, 19 Sep 2012 16:21:46 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B63621E8048 for ; Wed, 19 Sep 2012 16:21:46 -0700 (PDT) Received: by iec9 with SMTP id 9so2786524iec.31 for ; Wed, 19 Sep 2012 16:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BejpM1FzYfCXQa/QX+tu4hXmyHPeYn9y/zpKNgs7e2Q=; b=CC7BhtpobvNiUnXXFKy8yd+UqySZ1F0p01Clkow7Guh5038ZB/eBgnQx8ohTzWgesR ANg1ZSnHJSuFSlDWieqfrBHlDIMO0A2nlhc5r1Dg3b2E0T9rCscHvA6BhX/AcEq/NH6i f5/5SW2PFOUHnGhHfZQhNhoTNYSuEiHWw7rukfjr7vOjBhF863A/0pxKR1AKu1bxGDy8 ET3ug7eQSSWJlQ5gFn5VUfYSr/opDUDFwCya5Mt2R5YRDEPO0RrNIBz1FqCNcHiypymn qw5lSpYjcXXNyyL/D/tmYAbxecnGRuJR04jBTrEQG0uzn2MfJS6SIPzUfMWl4FnjhFL/ kGJw== MIME-Version: 1.0 Received: by 10.60.172.236 with SMTP id bf12mr19295oec.23.1348096905999; Wed, 19 Sep 2012 16:21:45 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Wed, 19 Sep 2012 16:21:45 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 19:21:45 -0400 Message-ID: From: Phillip Hallam-Baker To: Francis Galiegue Content-Type: multipart/alternative; boundary=bcaec54d47683476ef04ca164568 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 23:21:47 -0000 --bcaec54d47683476ef04ca164568 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 19, 2012 at 5:49 PM, Francis Galiegue wrote: > On Wed, Sep 19, 2012 at 11:36 PM, Francis Galiegue > wrote: > > On Wed, Sep 19, 2012 at 11:28 PM, Phillip Hallam-Baker > wrote: > > [...] > >>> > >>> There is no maxOccurs, no minOccurs. Where on earth did you see that? > >> > >> > >> http://tools.ietf.org/html/draft-zyp-json-schema-03 > >> > >> 5.13. minItems . . . . . . . . . . . . . . . . . . . . . . . . . 11 > >> 5.14. maxItems . . . . . . . . . . . . . . . . . . . . . . . . . 11 > >> > > [...] > >> > >> That would seem to be the same as the XML Schema constraints only > someone > >> changed the name. > >> > > > > This is the old specification. It is being redone. > > > > And you don't understand JSON at all, do you? Can you tell a JSON > > array from a JSON object? From what I read: no... > > > > Hint: this is a proposed text for the next version of the specification: > > "JSON Schema does not mandate that an instance be of a particular > type: JSON Schema can process any JSON value, including null" > I have no clue as to what you intend to mean with that statement. > maxOccurs and minOccurs are _meaningless_ to JSON. They serve the same function as minItems and maxItems. XML encoding just has a different method of encoding arrays. If you have an array of 2 foo objects you would have to specify them as something like 12 If you have something like class fred { list foos; list bars; } This would serialize as ... ... We have established that the JSON equivalent SHOULD be (and I think it should be a MUST) "fred" { "foos" [ {} {} {} ] "bars" [ {} {} ... ] } The clunkiness of the XML approach is the reason that XML is not a particularly good choice for encoding data structures. -- Website: http://hallambaker.com/ --bcaec54d47683476ef04ca164568 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Wed, Sep 19, 2012 at 5:49 PM, Francis= Galiegue <fgaliegue@gmail.com> wrote:
    On Wed, Sep 19, 2012 at 11:36 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:
    > On Wed, Sep 19, 2012 at 11:28 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
    > [...]
    >>>
    >>> There is no maxOccurs, no minOccurs. Where on earth did you se= e that?
    >>
    >>
    >> http://tools.ietf.org/html/draft-zyp-json-schema-03
    >>
    >> =A0 =A0 5.13. minItems . . . . . . . . . . . . . . . . . . . . . .= . . . 11
    >> =A0 =A0 =A05.14. maxItems . . . . . . . . . . . . . . . . . . . . = . . . . . 11
    >>
    > [...]
    >>
    >> That would seem to be the same as the XML Schema constraints only = someone
    >> changed the name.
    >>
    >
    > This is the old specification. It is being redone.
    >
    > And you don't understand JSON at all, do you? Can you tell a JSON<= br> > array from a JSON object? From what I read: no...
    >

    Hint: this is a proposed text for the next version of the specificati= on:

    "JSON Schema does not mandate that an instance be of a particular
    type: JSON Schema can process any JSON value, including null"

    I have no clue as to what you intend to mean wi= th that statement.

    =A0
    maxOccurs and minOccurs are _meaningless_ to JSON.

    They serve the same function as minItems and maxItems.
    XML encoding just has a different method of encoding arrays. I= f you have an array of 2 foo objects you would have to specify them as some= thing like <array><foo>1</foo><foo>2</foo> &l= t;/array>

    If you have something like=A0

    = class fred {
    =A0 =A0list <foo> foos;
    =A0 =A0list = <bar> bars;
    =A0 =A0}

    This would se= rialize as

    <fred> <foo/> <foo/>... <bar/> = <bar/>... </fred>

    We have established = that the JSON equivalent SHOULD be (and I think it should be a MUST)

    "fred" {=A0
    =A0 =A0 =A0"foos&q= uot; [ {} {} {} ]
    =A0 =A0 =A0"bars" [ {} {} ... ] }

    The clunkiness of the XML approach is the reason that= XML is not a particularly good choice for encoding data structures.=A0


    --
    Website: http://hallambaker.com/

    --bcaec54d47683476ef04ca164568-- From superuser@gmail.com Wed Sep 19 16:34:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A8A21E804E for ; Wed, 19 Sep 2012 16:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVYASUow0wdk for ; Wed, 19 Sep 2012 16:34:37 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DEA9221E8044 for ; Wed, 19 Sep 2012 16:34:36 -0700 (PDT) Received: by lboj14 with SMTP id j14so1276708lbo.31 for ; Wed, 19 Sep 2012 16:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YfaniC7hze9LHvTHmTUYnWl8pdj2KEV92m7Iq7Sceuo=; b=URTEu6X8rAHaAOeF5Vth0JEP1gC0GtW2eJ1AsNV9IqRkCp23lWMkYogUBsH+oe0qDA iYKL0h9gVSVGZgja7b/5ffaKZUajNqP7Q2kr+wonBK5L3UK0NqH99QO0MmX+Y8LauR58 D7+wPccSgh1GtpLrSuo4CxYYUoJqGzYyjMvKCjfkqcZ1J5vOsEG3F82GpL1DD1fFzQdB ngiPKdMsUKdQTjB4Ublpi6+bSZYxPr0dR01MNISrqDLxkHJVIU6VzSvgLG3/xz34GDW1 1mEtwsFs7TBrSv2tpbTCvf8ZKRmzb38IcH8FJcJ/atrR8hMCbIYPW68QDcfZqM5oat32 /TUw== MIME-Version: 1.0 Received: by 10.112.24.101 with SMTP id t5mr67594lbf.123.1348097675743; Wed, 19 Sep 2012 16:34:35 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Wed, 19 Sep 2012 16:34:35 -0700 (PDT) Date: Wed, 19 Sep 2012 16:34:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Decorum (was Re: JSON Schema considered harmful) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 23:34:37 -0000 Gentlemen, Please take the tone on this down a notch or three. I've no problem with discussing technical or procedural issues in this forum, but this personal stuff is unacceptable. So far as I'm aware, this is not work that's been taken up by APPSAWG, so I'm not sure we need to continue this discussion here unless we're being asked that question in a more formal sense. Thank you, -MSK, APPSAWG co-chair From pbryan@anode.ca Wed Sep 19 16:42:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE4421F8523 for ; Wed, 19 Sep 2012 16:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQvArbe53uvt for ; Wed, 19 Sep 2012 16:42:06 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id B055F21F8522 for ; Wed, 19 Sep 2012 16:42:06 -0700 (PDT) Received: from [10.71.13.58] (adsl-75-55-201-218.dsl.pltn13.sbcglobal.net [75.55.201.218]) by maple.anode.ca (Postfix) with ESMTPSA id 2E58D648E; Wed, 19 Sep 2012 23:42:04 +0000 (UTC) Message-ID: <1348098123.5269.8.camel@polyglot> From: "Paul C. Bryan" To: James M Snell Date: Wed, 19 Sep 2012 16:42:03 -0700 In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <1348077816.2880.9.camel@polyglot> <1348080756.2880.32.camel@polyglot> Content-Type: multipart/alternative; boundary="=-kdau+RWwkrmQ8ZHsz7d9" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 23:42:07 -0000 --=-kdau+RWwkrmQ8ZHsz7d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Wed, 2012-09-19 at 12:13 -0700, James M Snell wrote: [snip] > The point here is that server implementations ought to be *required* > to reject ambiguous change operations... not only "Some". It MUST NOT > be left up to implementations to choose on this particular point. I > can see no justifiable reason for this to be a SHOULD rather than a > MUST. So, I interpret your recommendation to be to change the text in §5 to: If an error condition occurs, evaluation of the JSON Patch document MUST terminate and application of the entire patch document SHALL NOT be deemed successful. Frankly, I don't have a problem with this. Any objections from others in the working group? If not, I'll support it. [snip] > When using something like "op":"replace" as an alternative, however, > this additional validation check becomes entirely unnecessary and the > possibility of ambiguity dissolves completely. For me, this is much > more advantageous than saving a few bytes on the wire. Well, there was significant feedback against separate operation and path members at the time. Personally, I'm ambivalent on this; I like both approaches for different reasons, though the current method wins out by a small margin. That said, if strong consensus to change to bifurcating to separate op/path were to be established, I wouldn't resist. Paul --=-kdau+RWwkrmQ8ZHsz7d9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 2012-09-19 at 12:13 -0700, James M Snell wrote:

    [snip]
    The point here is that server implementations ought to be *required* to reject ambiguous change operations... not only "Some". It MUST NOT be left up to implementations to choose on this particular point. I can see no justifiable reason for this to be a SHOULD rather than a MUST.

    So, I interpret your recommendation to be to change the text in §5 to:

        If an error condition occurs, evaluation of the JSON Patch document MUST terminate and application of the entire patch document SHALL NOT be deemed successful.

    Frankly, I don't have a problem with this. Any objections from others in the working group? If not, I'll support it.

    [snip]

    When using something like "op":"replace" as an alternative, however, this additional validation check becomes entirely unnecessary and the possibility of ambiguity dissolves completely. For me, this is much more advantageous than saving a few bytes on the wire.

    Well, there was significant feedback against separate operation and path members at the time. Personally, I'm ambivalent on this; I like both approaches for different reasons, though the current method wins out by a small margin. That said, if strong consensus to change to bifurcating to separate op/path were to be established, I wouldn't resist.

    Paul
    --=-kdau+RWwkrmQ8ZHsz7d9-- From andy@hxr.us Wed Sep 19 17:22:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6220021F84F3 for ; Wed, 19 Sep 2012 17:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHHC-bS6r9IL for ; Wed, 19 Sep 2012 17:22:32 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B15121F84F2 for ; Wed, 19 Sep 2012 17:22:31 -0700 (PDT) Received: by lboj14 with SMTP id j14so1313159lbo.31 for ; Wed, 19 Sep 2012 17:22:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=mBsPLxcow6/KN3VJmoE1Ls8zNjV24xi+oh+Xd8iF1rA=; b=EcLuJBNx4zliKVCp69O5uDYbYnOiSwkbMUknp8PGszolP4fs7gZajA4jvX7eGgkzZM UNDJ6vrIu/LiwJCkKuoCWXP8YpJCMu/OyA64p5hdzl2qhj8KWJTmPj70FQYzcD6iL2Pe S6LuyDfLTO5EhyqOSXwLV4ma388p1h6UBSBGiA8jtYvygFOcusfxpkf3yTz4kaLycrCD GsPQbEGNzsOmLMyp0j7Jo+DEqCflQLkDXVxcWN9bamsVIi3B1AOFm2RIkYlsS8BNh7mf s6/TEDkOGkpXgQONFsFo1nRM/HbqLUyi8mEcHSu9HXKj1rrpiy+O5np38R9aUNAF7xt6 pSEQ== MIME-Version: 1.0 Received: by 10.112.25.167 with SMTP id d7mr108793lbg.74.1348100550350; Wed, 19 Sep 2012 17:22:30 -0700 (PDT) Received: by 10.112.7.67 with HTTP; Wed, 19 Sep 2012 17:22:30 -0700 (PDT) X-Originating-IP: [71.191.219.28] In-Reply-To: References: Date: Wed, 19 Sep 2012 20:22:30 -0400 Message-ID: From: Andrew Newton To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkMUZ1+csSjEhn/7HoRp7emx+00Ok8lw7N6qTTFKHZ+ZVFzFElzKlsGAs7o+HcMPktvEn+6 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Decorum (was Re: JSON Schema considered harmful) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 00:22:32 -0000 On Wed, Sep 19, 2012 at 7:34 PM, Murray S. Kucherawy wrote: > So far as I'm aware, this is not work that's been taken up by APPSAWG, > so I'm not sure we need to continue this discussion here unless we're > being asked that question in a more formal sense. Not that I advocate the continuation of that thread, but I didn't realize this list was for APPSAWG work only. If so, where did the old Apps discuss list go? Just curious. -andy ps. maybe the IETF Architecture discuss list is the appropriate place, but that's a really dead list. From James.H.Manger@team.telstra.com Wed Sep 19 17:35:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33A821E804E for ; Wed, 19 Sep 2012 17:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.029 X-Spam-Level: X-Spam-Status: No, score=0.029 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-lGTAHRFWV8 for ; Wed, 19 Sep 2012 17:35:46 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id D52AD21E8041 for ; Wed, 19 Sep 2012 17:35:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,452,1344175200"; d="scan'208";a="93918214" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 20 Sep 2012 10:35:36 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6840"; a="125383423" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcavi.tcif.telstra.com.au with ESMTP; 20 Sep 2012 10:35:35 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Thu, 20 Sep 2012 10:35:35 +1000 From: "Manger, James H" To: James M Snell Date: Thu, 20 Sep 2012 10:35:34 +1000 Thread-Topic: [apps-discuss] JSON Patch: extensibility Thread-Index: Ac2WeM2eQhalG/zMRE+yM5u8th0SDAARjR5Q Message-ID: <255B9BB34FB7D647A506DC292726F6E114FD2316D2@WSMSG3153V.srv.dir.telstra.com> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 00:35:46 -0000 PiBBbiBhcnJheSBiYXNlZCBhcHByb2FjaCBjYXJyaWVzIGFsb25nIG1hbnkgb2YgaXQncyBvd24g aXNzdWVzLCBlc3BlY2lhbGx5IGlmIHdlIGRvIGRlY2lkZSB0byBleHRlbmQgdGhpbmdzIGxhdGVy IG9uLg0KDQpKYW1lcyBTbmVsbCwgY291bGQgeW91IGV4cGFuZCBvbiB0aG9zZSBpc3N1ZXMgYSBi aXQ/DQpFeHRlbmRpbmcgZG9lcyBub3Qgc2VlbSB0aGF0IGhhcmQgd2l0aCB0aGUgYXJyYXkgYXBw cm9hY2guDQpJZiBhIGZ1dHVyZSBvcGVyYXRpb24gbmVlZHMgYSBidW5jaCBvZiBvcHRpb25hbCBw YXJhbWV0ZXJzIGZvciBpbnN0YW5jZSAoc28gbmFtaW5nIHRoZW0gaXMgbW9yZSBjb252ZW5pZW50 IHRoYW4gcmVtZW1iZXJpbmcgdGhlaXIgcG9zaXRpb24gaW4gYW4gYXJndW1lbnQgbGlzdCksIHRo YXQgaXMgZWFzeSB0byBzdXBwb3J0OiBkZWZpbmUgb25lIGl0ZW0gaW4gdGhlIGFycmF5IGZvciB0 aGF0IG9wZXJhdGlvbiB0byBiZSBhIEpTT04gb2JqZWN0IHRoYXQgaG9sZHMgdGhvc2UgcGFyYW1l dGVycy4NCg0KVGhlIDEwIHBhdGNoIGV4YW1wbGVzIGZyb20gZHJhZnQtaWV0Zi1hcHBzYXdnLWpz b24tcGF0Y2gtMDQjYXBwZW5kaXgtQSBpbiBhcnJheSBzeW50YXg6DQoNCkEuMS4gIFtbImFkZCIs ICIvYmF6IiwgInF1eCJdXQ0KQS4yLiAgW1siYWRkIiwgIi9mb28vMSIsICJxdXgiXV0gDQpBLjMu ICBbWyJyZW1vdmUiLCAiL2JheiJdXQ0KQS40LiAgW1sicmVtb3ZlIiwgIi9mb28vMSJdXQ0KQS41 LiAgW1sicmVwbGFjZSIsICIvYmF6IiwgImJvbyJdXQ0KQS42LiAgW1sibW92ZSIsICIvZm9vL3dh bGRvIiwgIi9xdXgvdGh1ZCJdXQ0KQS43LiAgW1sibW92ZSIsICIvZm9vLzEiLCAiL2Zvby8zIl1d DQpBLjguICBbWyJ0ZXN0IiwgIi9iYXoiLCAicXV4Il0sIFsidGVzdCIsICIvZm9vLzEiLCAyXV0N CkEuOS4gIFtbInRlc3QiLCAiL2JheiIsICJiYXIiXV0NCkEuMTAuIFtbImFkZCIsICIvY2hpbGQi LCB7ImdyYW5kY2hpbGQiOnt9fV1dDQoNClRoZXNlIGFsbCBsb29rIHNpbXBsZSB0byB1bmRlcnN0 YW5kIGFuZCBwYXJzZS9wcm9jZXNzLiBJIGFtIG11Y2ggbW9yZSBjb25maWRlbnQgdGhhdCBhbnkg dmFndWVseSByZWFzb25hYmxlIGltcGxlbWVudGF0aW9uIGNhbm5vdCBjb25mdXNlIHRoZXNlIG9w ZXJhdGlvbnMsIG9yIGZhaWwgdG8gcmVqZWN0IGFuIHVucmVjb2duaXplZCBvcGVyYXRpb24sIGV2 ZW4gd2l0aCBhIG1hbGljaW91c2x5LWNvbnN0cnVjdGVkIGludmFsaWQgcGF0Y2guDQoNCk9uZSBk b3duc2lkZSBpcyB0aGF0IHlvdSBoYXZlIHRvIHJlbWVtYmVyIGl0IGlzIFsiY29weSIsIGZyb20s IHRvXSwgbm90IFsiY29weSIsIHRvLCBmcm9tXSAtLSB5b3UgZG9uJ3QgaGF2ZSB0aGUgInRvIiBs YWJlbCB0byByZW1pbmQgeW91LiBUaGF0IGZlZWxzIGxpa2UgYSBiZXR0ZXIgY29tcHJvbWlzZSB0 aGFuIHRoZSBjdXJyZW50IHN5bnRheCAobGl0dGxlIGNvbmZpZGVuY2UgdGhhdCBtYW55IGltcGxl bWVudGF0aW9ucyB3aWxsIHByb3Blcmx5IGNoZWNrIHZhbGlkaXR5KSBvciB0aGUgdmVyYm9zaXR5 IG9mIEphbWVzIFNuZWxsJ3MgaWRlYWwgc3ludGF4IHsib3AiOiJhZGQiLCAicmVmIjoiL2JheiIs ICJ2YWx1ZSI6InF1eCJ9Lg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg== From superuser@gmail.com Wed Sep 19 17:36:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F077E21E805D for ; Wed, 19 Sep 2012 17:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIHfL4bzjp-T for ; Wed, 19 Sep 2012 17:36:11 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 497CC21E8041 for ; Wed, 19 Sep 2012 17:36:10 -0700 (PDT) Received: by lboj14 with SMTP id j14so1322805lbo.31 for ; Wed, 19 Sep 2012 17:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZOL/1mxdtD8u5K3adDpSQO9xkyL5/Fv46lQk8o7ABxc=; b=vp82YjtsHjPTiKdSAx5XvE8SR/Iz6b24+qWjdy1nKJNI3B01XM2u+jk5gODSRQH9lN 5PgsXPog4dUbsbjPOEXvuabpXnuS0oa50SbVnxcp2Gt3KTIntQMzeq+ZD+LOddsrxpn4 l4BNMXnaEfTetx67k8kIlnlyA375CCyVHNrvApUNePwc841iPGhLiCNPewPUwo19G5EW WL+s6Asa0H/QgH/ONoKMJQerJaa0Gn8D/BAIzjJAiOapUxMdAmyt1f67OIoRBj80Lqy+ AB+MWkPDMzeklJbhRZz6HY12ubOkBxbEoU2JvFDb65cj6EdOOtDkrvIDuT+MSD5qqC9e oZjw== MIME-Version: 1.0 Received: by 10.112.84.101 with SMTP id x5mr131493lby.28.1348101369270; Wed, 19 Sep 2012 17:36:09 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Wed, 19 Sep 2012 17:36:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 17:36:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Newton Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Decorum (was Re: JSON Schema considered harmful) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 00:36:12 -0000 On Wed, Sep 19, 2012 at 5:22 PM, Andrew Newton wrote: > Not that I advocate the continuation of that thread, but I didn't > realize this list was for APPSAWG work only. If so, where did the old > Apps discuss list go? Just curious. > > -andy > > ps. maybe the IETF Architecture discuss list is the appropriate place, > but that's a really dead list. I stand corrected. This is the right venue for general applications discussion, so it's a valid topic. So roll back what I said to being a message about decorum only, please. -MSK From ned.freed@mrochek.com Wed Sep 19 18:26:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220ED21F851E for ; Wed, 19 Sep 2012 18:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSg-CTwmaPlV for ; Wed, 19 Sep 2012 18:26:33 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8C17E21F851C for ; Wed, 19 Sep 2012 18:26:33 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKG6ZY0CN4009UZO@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 19 Sep 2012 18:21:28 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Wed, 19 Sep 2012 18:21:23 -0700 (PDT) Message-id: <01OKG6ZUUXKY0006TF@mauve.mrochek.com> Date: Wed, 19 Sep 2012 18:15:55 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 19 Sep 2012 17:56:38 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <6.2.5.6.2.20120919140051.0a168870@resistor.net> To: Phillip Hallam-Baker Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 01:26:34 -0000 > On Wed, Sep 19, 2012 at 5:20 PM, SM wrote: > > At 06:11 18-09-2012, Barry Leiba wrote: > > > >> Apart from that, Your Friendly ADs have been discussing the > >> possibility of reclassifying it as Proposed Standard. Comments about > >> such a move are welcome on this thread. > >> > > > > There is an erratum. A reclassification would require ignoring it. I'd > > suggest a quick open and shut path. My guess is that it might not be > > quick*. The Security Considerations section of RFC 4627 seems to be on the > > economical side. > > > > Regards, > > -sm > > > The security considerations is definitely light to the point of being non > existent. But as with many specs, there really isn't a set of security > considerations that it specific to JSON data format. Quite correct, and so that's what the security considerations need to say: They depend on what's being represented, and here are some of the potential issues that could arise. This is NOT hard to do; we've done it many times before. > If the spec has to be rewritten then I would like to see the security > considerations address the general security issues so that we can do it > once and not have to repeat it in other documents. I would also like some > clarifications. But I don't see that as a reason for blocking uprating the > spec as is if that is an option. Simple reclassification really isn't an option at this point, because as it is the media type registration in the current document violates the rules for such things. (And this has nothing to do with document status.) It should never have been published with this text in the first place, and given the chance to fix it that a change in standards grade presents, we are obliged to do so. > We still get a second bite at the revisions cherry in the Proposed to > Standard move. I think a new RFC would be necessary for that. It's necessary now. Whether or not it's necessary later will depend on how good a job we do. Ned From hallam@gmail.com Wed Sep 19 19:55:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD1A21E8037 for ; Wed, 19 Sep 2012 19:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.03 X-Spam-Level: X-Spam-Status: No, score=-4.03 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKPYKVIvOMLZ for ; Wed, 19 Sep 2012 19:55:51 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id E37B711E808E for ; Wed, 19 Sep 2012 19:55:50 -0700 (PDT) Received: by oagn5 with SMTP id n5so1233409oag.31 for ; Wed, 19 Sep 2012 19:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EQAjyJeQH2mY8kQ9qWSlZE6USFoA8vvT5g/avonzuco=; b=zXX2dIdWRzQJGn4ufa+MdedFuBQg+b6HhnPDP9XmbDg4fXQLZsl72dH+/ZM1b8MCVU XcSQYebiMvpa/jVQ/ncJXW9vbwX5JZ9DtntMHaXXujqR1Dvg+Thj4ABdSXlMUWBs+gHO cP4PumHbyuXggHOcmOqReVLM6ok3vx4B3FLz5iNYVsPaOx/FvLr83cJCkZ22zdiF5wM6 4H67UJuP6bfehYG+i6qwxAJTGK9liqEG5w9dFygtETOryww098jh6XzOKIaLY2vafFDP BV5tvFTGj1KXf/rtVX81fCPvafc4RwJcUrtDGhyb6ZBcPVAuDbXGPpD0Y0NJ0C8rlABu Emjg== MIME-Version: 1.0 Received: by 10.182.145.35 with SMTP id sr3mr260969obb.98.1348109750387; Wed, 19 Sep 2012 19:55:50 -0700 (PDT) Received: by 10.76.29.50 with HTTP; Wed, 19 Sep 2012 19:55:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 22:55:50 -0400 Message-ID: From: Phillip Hallam-Baker To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=f46d04463078ca434a04ca194269 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Decorum (was Re: JSON Schema considered harmful) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 02:55:51 -0000 --f46d04463078ca434a04ca194269 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 19, 2012 at 8:36 PM, Murray S. Kucherawy wrote: > On Wed, Sep 19, 2012 at 5:22 PM, Andrew Newton wrote: > > Not that I advocate the continuation of that thread, but I didn't > > realize this list was for APPSAWG work only. If so, where did the old > > Apps discuss list go? Just curious. > > > > -andy > > > > ps. maybe the IETF Architecture discuss list is the appropriate place, > > but that's a really dead list. > > I stand corrected. This is the right venue for general applications > discussion, so it's a valid topic. Hopefully discussing tools for describing protocols is in scope here. That is my interest at least. A lot of the discussion seems to stray far from being a tool for designing, developing or documenting a protocol. I have used XML Schema and I think there is a lot of value to it. But that value is concentrated in about 10% of the spec and the rest detracts from the value. So I do sympathize with a lot of the folk saying that they don't need a schema at all for JSON, but an RFC is a sort of schema in that it defines the data flows and that is the sort of tool I want. What I think should be out of scope is discussion of 'document formats' (other than RFC doc format :). Protocols consist of message exchanges, not document exchanges. And we already have a document markup in any case. XML is the way it is because it is designed to support document exchange which is why it turns out to be a crappy data exchange language. JSON would make an equally crappy document markup. -- Website: http://hallambaker.com/ --f46d04463078ca434a04ca194269 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Wed, Sep 19, 2012 at 8:36 PM, Murray = S. Kucherawy <superuser@gmail.com> wrote:
    On Wed, Sep 19, 2012 at 5:22 PM, Andrew Newton <andy@hxr.us> wrote:
    > Not that I advocate the continuation of that thread, but I didn't<= br> > realize this list was for APPSAWG work only. If so, where did the old<= br> > Apps discuss list go? Just curious.
    >
    > -andy
    >
    > ps. maybe the IETF Architecture discuss list is the appropriate place,=
    > but that's a really dead list.

    I stand corrected. =A0This is the right venue for general application= s
    discussion, so it's a valid topic.

    Hope= fully discussing tools for describing protocols is in scope here. That is m= y interest at least.

    A lot of the discussion seems= to stray far from being a tool for designing, developing or documenting a = protocol.=A0

    I have used XML Schema and I think there is a lot of va= lue to it. But that value is concentrated in about 10% of the spec and the = rest detracts from the value. So I do sympathize with a lot of the folk say= ing that they don't need a schema at all for JSON, but an RFC is a sort= of schema in that it defines the data flows and that is the sort of tool I= want.


    What I think should be out of scope is d= iscussion of 'document formats' (other than RFC doc format :).

    Protocols consist of message exchanges, not document e= xchanges. And we already have a document markup in any case. XML is the way= it is because it is designed to support document exchange which is why it = turns out to be a crappy data exchange language. JSON would make an equally= crappy document markup.=A0



    --
    Website: http://hallambaker.com/

    --f46d04463078ca434a04ca194269-- From sm@elandsys.com Wed Sep 19 21:51:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC5A21F84EC for ; Wed, 19 Sep 2012 21:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBtCvpysgPq3 for ; Wed, 19 Sep 2012 21:51:15 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A7221F84D4 for ; Wed, 19 Sep 2012 21:51:15 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.13]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8K4oroZ006605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2012 21:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1348116666; bh=loJOsK+YPb2/CdmJEsexMl1FdF9GPxKWhn6VggGfAEw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tTBP8VhhBAqtKGrI7BaIxyvVr0Vt9asV7BPjjhrW7mItHNLemca0Gg9Jbqp1ukAQn rGr/uui1G7dZlahPdCmftRvbpqb38ui2MqiHwlYkp/L9DuP/YUpTRDhYX02UfD7AYT R3lowB8cZauKKb4QdFk6qJ1G0HgKAoJeUuXHSPb8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1348116666; i=@elandsys.com; bh=loJOsK+YPb2/CdmJEsexMl1FdF9GPxKWhn6VggGfAEw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Qesk5bmVR7nqbN1IH309tnSMa1CmYiKu6csW/Q1MOnT/M2YVOC/1FQx88BJizAAzK R+Mf/QftEsKRvSanAQK8HxBob0OlXhQUc5wLZKfpneysRsSvY/I7SCVBvj/D5CBotu +F0JqXc/GMtJDAwhReqf9YGDZLd2+LWT5goQGI7Y= Message-Id: <6.2.5.6.2.20120919212435.0a403380@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 19 Sep 2012 21:38:06 -0700 To: IETF Apps Discuss From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Decorum (was Re: JSON Schema considered harmful) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 04:51:16 -0000 This list is for discussion of matters related to the Applications Area of the IETF, as well as the APPSAWG. In particular, discussions of area-wide concerns or technical issues, and ideas for new Applications Area working groups, are appropriate. At present anyone can post to the list; however, messages from non-subscribers are reviewed by a moderator before being distributed to list members. The Application Area Directors reserve the right to moderate the list to filter inappropriate messages, or to automatically filter messages from those who habitually post inappropriate messages. Here, inappropriate means either 'abusive' or 'wildly off topic'. Regards, S. Moonesamy From lear@cisco.com Wed Sep 19 22:02:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E0021F84F0; Wed, 19 Sep 2012 22:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.649 X-Spam-Level: X-Spam-Status: No, score=-110.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNSd1CR-4lMp; Wed, 19 Sep 2012 22:02:48 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id B0F8F21F846A; Wed, 19 Sep 2012 22:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=476; q=dns/txt; s=iport; t=1348117368; x=1349326968; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=PwHYxXpTh5aU6hXeEfjp9jdp0aUhvYVWq/QMWUN/zFc=; b=c5YM5wnBLsbCzHQa8t3yAe2AXJMyoK+JQe5H6L6qSTUPh+zqd8M9j1aw jv2rLvPF6yzrR9QlMJkB2C8O1FQ83pAsmf1fePjt+dPZPTr9qW5EI3tOn XivYmjAk2aQ/VMKRnJlt2IU2cTwBvrYncN5GTDGJ68FMPH+P82vNvhf96 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAH2iWlCQ/khL/2dsb2JhbABFhUNHtnaBCII5ARBVNgIFFgsCCwMCAQIBSwEMCAEBEA6HYQuZeI0bkmyBIY8qgRIDlWSOOIFpgmg X-IronPort-AV: E=Sophos;i="4.80,452,1344211200"; d="scan'208";a="8167974" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 20 Sep 2012 05:02:46 +0000 Received: from ams3-vpn-dhcp6699.cisco.com (ams3-vpn-dhcp6699.cisco.com [10.61.90.42]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8K52jPx003763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2012 05:02:46 GMT Message-ID: <505AA377.3050003@cisco.com> Date: Thu, 20 Sep 2012 07:02:47 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , "saag@ietf.org" X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] The passing of Dr. John Larmouth X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 05:02:49 -0000 Earlier this month Dr. John Larmouth, who was the father of ASN.1 passed away. He was an active leader within the ITU-T, and the Internet community has made great use of ASN.1 in SNMP and X.509 certificates, to name a few. The ITU has published a memorial page, which you can find at http://www.itu.int/ITU-T/newslog/In+Memoriam+John+Larmouth.aspx. Russ has signed the condolence book on behalf of the IETF. Eliot (in my role as IETF Liaison Manager to the ITU-T) From jasnell@gmail.com Wed Sep 19 22:53:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFBB21F8665 for ; Wed, 19 Sep 2012 22:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaAZMOktmXiG for ; Wed, 19 Sep 2012 22:53:54 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3399B21F865B for ; Wed, 19 Sep 2012 22:53:54 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so77719wgb.13 for ; Wed, 19 Sep 2012 22:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FacdjPCxyYrgtyhsZLZ0+07k/929IE6K8pdjrym54hg=; b=Xjp2ulRUWWTjOTCaDymVh2Nd2o7GuXBaDQY4spq4D8fEoWeDy7y8lfY65AKEdGHvjU NYQ3e35l46QhQnyE+PsSxw5iGsfNvlJ7EXO0zaTo4pSkEmH8ejFowOg6z15HjN10QFox Y6VyLDdldgJUHRMOBBC9x4iSskcpr7M/alEyGqBgZAwRmdx1ZcDUyD+ehWqBYD2/6p+s 2Sp1Eqqk4NL/XG33YcKGOARHcOXiULegFVwSVjVqrSbXFKChD4+vmQEFM3f8JyNJzJas YUwYQYkY9oxkcBuiDt9C0L/nwiQ9yICuBvsgdpmfrIVNT3DoSL/XMb02uyY1H5M/3D8k wJpA== Received: by 10.216.243.74 with SMTP id j52mr453580wer.108.1348120428421; Wed, 19 Sep 2012 22:53:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Wed, 19 Sep 2012 22:53:28 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FD2316D2@WSMSG3153V.srv.dir.telstra.com> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FD2316D2@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Wed, 19 Sep 2012 22:53:28 -0700 Message-ID: To: "Manger, James H" Content-Type: multipart/alternative; boundary=e0cb4e43cf1f4021ff04ca1bbff3 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 05:53:55 -0000 --e0cb4e43cf1f4021ff04ca1bbff3 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 19, 2012 at 5:35 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > > An array based approach carries along many of it's own issues, > especially if we do decide to extend things later on. > > James Snell, could you expand on those issues a bit? > Extending does not seem that hard with the array approach. > If a future operation needs a bunch of optional parameters for instance > (so naming them is more convenient than remembering their position in an > argument list), that is easy to support: define one item in the array for > that operation to be a JSON object that holds those parameters. > > The main issue, aside from the basic possible extensibility ramifications is that it just *feels* like an entirely pointless optimization... a change that buys us absolutely nothing in terms of real functionality and simply trades one set of potential issues for another. The spec version of code smell. To be honest, I'm still wondering what's wrong with my slightly more verbose option. - James > The 10 patch examples from draft-ietf-appsawg-json-patch-04#appendix-A in > array syntax: > > A.1. [["add", "/baz", "qux"]] > A.2. [["add", "/foo/1", "qux"]] > A.3. [["remove", "/baz"]] > A.4. [["remove", "/foo/1"]] > A.5. [["replace", "/baz", "boo"]] > A.6. [["move", "/foo/waldo", "/qux/thud"]] > A.7. [["move", "/foo/1", "/foo/3"]] > A.8. [["test", "/baz", "qux"], ["test", "/foo/1", 2]] > A.9. [["test", "/baz", "bar"]] > A.10. [["add", "/child", {"grandchild":{}}]] > > These all look simple to understand and parse/process. I am much more > confident that any vaguely reasonable implementation cannot confuse these > operations, or fail to reject an unrecognized operation, even with a > maliciously-constructed invalid patch. > > One downside is that you have to remember it is ["copy", from, to], not > ["copy", to, from] -- you don't have the "to" label to remind you. That > feels like a better compromise than the current syntax (little confidence > that many implementations will properly check validity) or the verbosity of > James Snell's ideal syntax {"op":"add", "ref":"/baz", "value":"qux"}. > > -- > James Manger > > --e0cb4e43cf1f4021ff04ca1bbff3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    On Wed, Sep 19, 2012 at 5:35 PM, Manger, James H <= James.= H.Manger@team.telstra.com> wrote:
    > An array based approa= ch carries along many of it's own issues, especially if we do decide to= extend things later on.

    James Snell, could you expand on those issues a bit?
    Extending does not seem that hard with the array approach.
    If a future operation needs a bunch of optional parameters for instance (so= naming them is more convenient than remembering their position in an argum= ent list), that is easy to support: define one item in the array for that o= peration to be a JSON object that holds those parameters.


    The main issue, aside from the basic p= ossible extensibility ramifications is that it just *feels* like an entirel= y pointless optimization... a change that buys us absolutely nothing in ter= ms of real functionality and simply trades one set of potential issues for = another. The spec version of code smell.

    To be honest, I'm still wondering what's wrong = with my slightly more verbose option.

    - James
    =C2=A0
    The 10 patch examples from draft-ietf-appsawg-json-patch-04#appendix-A in a= rray syntax:

    A.1. =C2=A0[["add", "/baz", "qux"]]
    A.2. =C2=A0[["add", "/foo/1", "qux"]]
    A.3. =C2=A0[["remove", "/baz"]]
    A.4. =C2=A0[["remove", "/foo/1"]]
    A.5. =C2=A0[["replace", "/baz", "boo"]]
    A.6. =C2=A0[["move", "/foo/waldo", "/qux/thud"= ;]]
    A.7. =C2=A0[["move", "/foo/1", "/foo/3"]]
    A.8. =C2=A0[["test", "/baz", "qux"], ["t= est", "/foo/1", 2]]
    A.9. =C2=A0[["test", "/baz", "bar"]]
    A.10. [["add", "/child", {"grandchild":{}}]]<= br>
    These all look simple to understand and parse/process. I am much more confi= dent that any vaguely reasonable implementation cannot confuse these operat= ions, or fail to reject an unrecognized operation, even with a maliciously-= constructed invalid patch.

    One downside is that you have to remember it is ["copy", from, to= ], not ["copy", to, from] -- you don't have the "to"= ; label to remind you. That feels like a better compromise than the current= syntax (little confidence that many implementations will properly check va= lidity) or the verbosity of James Snell's ideal syntax {"op":= "add", "ref":"/baz", "value":"= qux"}.

    --
    James Manger


    --e0cb4e43cf1f4021ff04ca1bbff3-- From duck@kronkltd.net Wed Sep 19 22:59:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73E721F865F for ; Wed, 19 Sep 2012 22:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rhnd-PTeVNGM for ; Wed, 19 Sep 2012 22:59:06 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8816721F8634 for ; Wed, 19 Sep 2012 22:59:05 -0700 (PDT) Received: by wibhq12 with SMTP id hq12so224557wib.1 for ; Wed, 19 Sep 2012 22:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kronkltd.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xUqNBWW1qfxKUsqESYEtTBUvD2XxMLpz3ApT8zA+D6k=; b=UMELbNMQky+5xds5XTpgaztCY2rHhuzw7yS7ilaGxKZSGr194Lyw9S2e2pEHFJ2Z7W 240Qjz9CqL39to9XDTrdVc/Js7ERh2bedC8ZL8S8yPG4IvDrpLMXrHU+dZchuhkNV8UF P6VCPHECNon2vM7P8oo6YFOYjuEfeYD2Owg0A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=xUqNBWW1qfxKUsqESYEtTBUvD2XxMLpz3ApT8zA+D6k=; b=OEHlsGpJCjAjo+fh72UvEzb6d3Qh4x+jc9d7aVIBUAWOqvFtY2F+Evo8d9XZWvX9Ug I/Ysm6mlnKRd5ikpo5T3RzTPBHoEqShx4CGu6KMQrbNp2uQBwDKuuoUmqBbu4m+Nb39l mjQ3eeI8xypAYvL2SPnsxksAhCEuWDe1UV79xgZqdb0DqvtvdZLjGqphHahFCL5VgULD SpKoMcriucCbuz/2TMGb9j0H9lg5SGrU0HOraQwuXO33Y+qSq22mc6ypfXniwBr9dtZd wT0oNqZqxf5EYUHuCUEX6LwY477cxwHF7eVsPfNavNEcQd7yKenqb/gEA2R7XeHgMjpX qkGg== Received: by 10.216.214.91 with SMTP id b69mr482022wep.70.1348120744326; Wed, 19 Sep 2012 22:59:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.113.198 with HTTP; Wed, 19 Sep 2012 22:58:44 -0700 (PDT) In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FD2316D2@WSMSG3153V.srv.dir.telstra.com> From: Daniel Renfer Date: Thu, 20 Sep 2012 01:58:44 -0400 Message-ID: To: James M Snell Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnbt5OAj1QGPIYNAYeGOUL3d/zUILcm6NI5Qw2W9gSYDUYOVAEbwl7pFY8lyjaZwAmCtuj5 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 05:59:07 -0000 I'm going to have to give a +1 to the separate op/ref approach from an implementation standpoint. I've just been playing around with what it would take to implement this in clojure and discovered that parsing would be a lot easier if I had just 1 key to check to get my operation. This would allow me to have an open-ended implementation where I could easily add new ops as they come up. I also think it makes the story for extension properties much easier. For instance, how about an "optional" key for operations that are allowed to fail without failing the whole operation? Just an example. On Thu, Sep 20, 2012 at 1:53 AM, James M Snell wrote: > > > On Wed, Sep 19, 2012 at 5:35 PM, Manger, James H > wrote: >> >> > An array based approach carries along many of it's own issues, >> > especially if we do decide to extend things later on. >> >> James Snell, could you expand on those issues a bit? >> Extending does not seem that hard with the array approach. >> If a future operation needs a bunch of optional parameters for instance >> (so naming them is more convenient than remembering their position in an >> argument list), that is easy to support: define one item in the array for >> that operation to be a JSON object that holds those parameters. >> > > The main issue, aside from the basic possible extensibility ramifications is > that it just *feels* like an entirely pointless optimization... a change > that buys us absolutely nothing in terms of real functionality and simply > trades one set of potential issues for another. The spec version of code > smell. > > To be honest, I'm still wondering what's wrong with my slightly more verbose > option. > > - James > >> >> The 10 patch examples from draft-ietf-appsawg-json-patch-04#appendix-A in >> array syntax: >> >> A.1. [["add", "/baz", "qux"]] >> A.2. [["add", "/foo/1", "qux"]] >> A.3. [["remove", "/baz"]] >> A.4. [["remove", "/foo/1"]] >> A.5. [["replace", "/baz", "boo"]] >> A.6. [["move", "/foo/waldo", "/qux/thud"]] >> A.7. [["move", "/foo/1", "/foo/3"]] >> A.8. [["test", "/baz", "qux"], ["test", "/foo/1", 2]] >> A.9. [["test", "/baz", "bar"]] >> A.10. [["add", "/child", {"grandchild":{}}]] >> >> These all look simple to understand and parse/process. I am much more >> confident that any vaguely reasonable implementation cannot confuse these >> operations, or fail to reject an unrecognized operation, even with a >> maliciously-constructed invalid patch. >> >> One downside is that you have to remember it is ["copy", from, to], not >> ["copy", to, from] -- you don't have the "to" label to remind you. That >> feels like a better compromise than the current syntax (little confidence >> that many implementations will properly check validity) or the verbosity of >> James Snell's ideal syntax {"op":"add", "ref":"/baz", "value":"qux"}. >> >> -- >> James Manger >> > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From hannes.tschofenig@nsn.com Wed Sep 19 23:27:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AC721F868A for ; Wed, 19 Sep 2012 23:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.35 X-Spam-Level: X-Spam-Status: No, score=-106.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGIEoOlpdqxr for ; Wed, 19 Sep 2012 23:27:04 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 915CA21F8686 for ; Wed, 19 Sep 2012 23:27:03 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q8K6QxaI018645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Sep 2012 08:26:59 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q8K6Qvj7015034; Thu, 20 Sep 2012 08:26:59 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Sep 2012 08:26:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD96F8.EFDF6D7A" Date: Thu, 20 Sep 2012 09:26:57 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [apps-discuss] JSON Schema considered harmful Thread-Index: Ac2WjIUxJJ87pqrCRxO8aqscjj5ybgAaNeiw References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Phillip Hallam-Baker" , "Francis Galiegue" X-OriginalArrivalTime: 20 Sep 2012 06:26:58.0232 (UTC) FILETIME=[EFC4CB80:01CD96F8] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 10646 X-purgate-ID: 151667::1348122420-00006F5F-EB97186D/0-0/0-0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 06:27:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD96F8.EFDF6D7A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My 5 cents to this topic.=20 =20 Even though many folks, including Tim Bray, educated the community that it is not necessary to produce XML schemas when writing specifications that use XML, everyone did. They felt that the specification was not complete without the schema. =20 The consequence was that=20 * The XML replaced text in specifications leaving important semantic unspecified. Look at many of the OASIS document, for example CAP, and you know what I am talking about. The authors somehow thought that the schema is a replacement for a description of what the protocol actually does. Wrong! Interoperability problems are the consequence. * Sometimes the XML schema was provided in addition to a textual description. Nice idea but then they often get out of sync.=20 * Extensibility thoughts were left behind. XML by itself meant extensible, at least that's what many thought, and hence there was no story about how the protocol would get extended in a smooth way and what the policies are for extensions. =20 The worst thing was, however, that the entire protocol development was guided by the (lack of) understanding of the XML schema language rather than the requirements for the actual protocol.=20 =20 Funny enough the schema did not really help anyone: it did not help a person reading the specification (who does not want to implement it) since they typically care about an entire level of detail nor the guy who wants to implements it. Just using the schema for an implementation was never enough because you had to consider all the other special case as well (which can typically only be found elsewhere in the specification). If you managed to encode all the special cases into the schema then it became unreadable. The instance validation against concept was also useless once you included the proper extension points.=20 =20 In a nutshell, I think that XML (& Relax NG) schemas are harmful. Unfortunately, it is already too late for fixing that in the IETF. I believe we should not introduce schemas into JSON in the IETF. Everything will be fine without using it.=20 =20 Ciao Hannes =20 ------_=_NextPart_001_01CD96F8.EFDF6D7A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    My 5 cents to this topic.

     

    Even though many folks, including Tim Bray, educated the community = that it is not necessary to produce XML schemas when writing = specifications that use XML, everyone did. They felt that the = specification was not complete without the = schema.

     

    The consequence was that

    ·        = The XML replaced text in specifications leaving important semantic = unspecified. Look at many of the OASIS document, for example CAP, and = you know what I am talking about. The authors somehow thought that the = schema is a replacement for a description of what the protocol actually = does. Wrong! Interoperability problems are the = consequence.

    ·        = Sometimes the XML schema was provided in addition to a textual = description. Nice idea but then they often get out of sync. =

    ·        = Extensibility thoughts were left behind. XML by itself meant = extensible, at least that’s what many thought, and hence there was = no story about how the protocol would get extended in a smooth way and = what the policies are for extensions.

     

    The worst thing was, however, that the entire protocol development = was guided by the (lack of) understanding of the XML schema language = rather than the requirements for the actual protocol. =

     

    Funny enough the schema did not really help anyone: it did not help a = person reading the specification (who does not want to implement it) = since they typically care about an entire level of detail nor the guy = who wants to implements it. Just using the schema for an implementation = was never enough because you had to consider all the other special case = as well (which can typically only be found elsewhere in the = specification). If you managed to encode all the special cases into the = schema then it became unreadable. The instance validation against = concept was also useless once you included the proper extension points. =

     

    In a nutshell, I think that XML (& Relax NG) schemas are harmful. = Unfortunately, it is already too late for fixing that in the IETF. I = believe we should not introduce schemas into JSON in the IETF. = Everything will be fine without using it.

     

    Ciao

    Hannes

     

    ------_=_NextPart_001_01CD96F8.EFDF6D7A-- From James.H.Manger@team.telstra.com Thu Sep 20 00:40:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF88621F845B for ; Thu, 20 Sep 2012 00:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_33=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GjTGVEtIOTB for ; Thu, 20 Sep 2012 00:40:29 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 5506821F8469 for ; Thu, 20 Sep 2012 00:40:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,453,1344175200"; d="scan'208";a="92282784" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 20 Sep 2012 17:40:28 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6840"; a="84466099" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcdni.tcif.telstra.com.au with ESMTP; 20 Sep 2012 17:40:27 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Thu, 20 Sep 2012 17:40:27 +1000 From: "Manger, James H" To: James M Snell Date: Thu, 20 Sep 2012 17:40:26 +1000 Thread-Topic: [apps-discuss] JSON Patch: extensibility Thread-Index: Ac2W9QxXcXGW1g89R/OHb2UpqKa2ygAA2Tpg Message-ID: <255B9BB34FB7D647A506DC292726F6E114FD2A9600@WSMSG3153V.srv.dir.telstra.com> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FD2316D2@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 07:40:30 -0000 PiA+PiA+IEFuIGFycmF5IGJhc2VkIGFwcHJvYWNoIA0KDQo+ID4gVGhlIG1haW4gaXNzdWUsIGFz aWRlIGZyb20gdGhlIGJhc2ljIHBvc3NpYmxlIGV4dGVuc2liaWxpdHkNCj4gPiByYW1pZmljYXRp b25zIGlzIHRoYXQgaXQganVzdCAqZmVlbHMqIGxpa2UgYW4gZW50aXJlbHkgcG9pbnRsZXNzDQo+ ID4gb3B0aW1pemF0aW9uLi4uIGEgY2hhbmdlIHRoYXQgYnV5cyB1cyBhYnNvbHV0ZWx5IG5vdGhp bmcgaW4gdGVybXMgb2YNCj4gPiByZWFsIGZ1bmN0aW9uYWxpdHkgYW5kIHNpbXBseSB0cmFkZXMg b25lIHNldCBvZiBwb3RlbnRpYWwgaXNzdWVzIGZvcg0KPiA+IGFub3RoZXIuIFRoZSBzcGVjIHZl cnNpb24gb2YgY29kZSBzbWVsbC4NCg0KR2l2ZW4gdGhhdCBlYWNoIG9wZXJhdGlvbiBpcyBsaWtl bHkgdG8gYmUgbWFwcGVkIHRvIGEgZnVuY3Rpb24gY2FsbCBzdWNoIGFzIGFkZChwdHIsIHZhbCks IGFuIGFycmF5IGFwcHJvYWNoIFsiYWRkIiwgcHRyLCB2YWxdIHNlZW1zIHF1aXRlIG5hdHVyYWwu IFRoZSBvYmplY3QtYmFzZWQgYXBwcm9hY2ggKmZlZWxzKiBsaWtlIGFuIGVudGlyZWx5IHBvaW50 bGVzcyBvcHRpbWl6YXRpb24uLi4gYW4gb3B0aW1pemF0aW9uIHRvIHN1cHBvcnQgc29tZSBwb3Rl bnRpYWwgZXh0ZW5zaWJpbGl0eSB0aGF0IHdlIGV4cGxpY2l0bHkgZG9uJ3Qgd2FudC4NCg0KRXh0 ZW5zaW9ucyBieSBhZGRpbmcgbmV3IG9wZXJhdGlvbnMgaXMgcG90ZW50aWFsbHkgdXNlZnVsIC0t IGl0IGlzIGVxdWFsbHkgZWFzeSB3aXRoIGFuIGFycmF5IGFwcHJvYWNoIG9yIGFuIG9iamVjdC13 aXRoLW9wLW1lbWJlciBhcHByb2FjaC4NCg0KRXh0ZW5zaW9ucyBieSBhZGRpbmcgbmV3IHBhcmFt ZXRlcnMgdG8gcHJldmlvdXNseSBkZWZpbmVkIG9wZXJhdGlvbnMgc291bmRzIGJhZCAtLSBzbyB0 aGUgZmFjdCB0aGF0IHRoYXQgbWF5IGJlIGVhc2llciB3aXRoIGFuIG9iamVjdC13aXRoLW9wLW1l bWJlciBhcHByb2FjaCBpcyBub3QgYWN0dWFsbHkgYW4gYWR2YW50YWdlLg0KDQoNCj4gPiBUbyBi ZSBob25lc3QsIEknbSBzdGlsbCB3b25kZXJpbmcgd2hhdCdzIHdyb25nIHdpdGggbXkgc2xpZ2h0 bHkgbW9yZQ0KPiA+IHZlcmJvc2Ugb3B0aW9uLg0KDQpJdHMgdmVyYm9zaXR5IDspDQpBIGtleSB3 aXRoIHRoZSB0b3RhbGx5LWdlbmVyaWMgbmFtZSAidmFsdWUiIGlzIG5vdCBhIGdvb2Qgc2lnbiB0 aGF0IHRoZSBzeW50YXggbWF0Y2hlcyB0aGUgbW9kZWwgd2VsbC4NCg0KDQpJIHN1Z2dlc3QgdGhh dCB0aGUgcGF0Y2ggc3BlYyBzaG91bGQgc2F5Og0KMS4gIml0IGlzIGFuIGVycm9yIGNvbmRpdGlv biBpZiBhbiBvcGVyYXRpb24gbmFtZSBpcyB1bnJlY29nbml6ZWQiDQoyLiAidW5yZWNvZ25pemVk IHBhcmFtZXRlcnMgTVVTVCBiZSBpZ25vcmVkIg0KSXQgaXMgc28gbGlrZWx5IHRoYXQgc29tZS9t YW55IGltcGxlbWVudGF0aW9ucyB3aWxsIG5vdCBib3RoZXIgdG8gY2hlY2sgdGhhdCB0aGVyZSBh cmUgbm8gdW5yZWNvZ25pemVkIHBhcmFtZXRlcnMgdGhhdCB0aGUgc3BlYyBzaG91bGQgbm90IGlt cGx5IHRoYXQgYW55b25lIGNhbiByZWx5IG9uIHRob3NlIGNoZWNrcyBvY2N1cnJpbmcuDQoNClRo ZSBzeW50YXggbmVlZHMgdG8gYmUgY2hhbmdlZCBmcm9tIHRoZSBjdXJyZW50IGZvcm0gKG9iamVj dC13aXRoLW9wLW5hbWUtYXMta2V5KSB0byBlaXRoZXIgYXJyYXkgb3Igb2JqZWN0LXdpdGgtb3At bWVtYmVyIGZvciB0aGlzIHBhaXIgb2Ygc3RhdGVtZW50cyB0byB3b3JrLg0KDQotLQ0KSmFtZXMg TWFuZ2VyDQo= From evan@status.net Thu Sep 20 03:36:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5387D21F87D6 for ; Thu, 20 Sep 2012 03:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEsXMmaIR5hN for ; Thu, 20 Sep 2012 03:36:28 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 79A9721F87AF for ; Thu, 20 Sep 2012 03:36:28 -0700 (PDT) Received: from [192.168.69.112] (modemcable107.194-202-24.mc.videotron.ca [24.202.194.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id AF0028D6BB8; Thu, 20 Sep 2012 10:46:42 +0000 (UTC) Message-ID: <505AF1AA.6080601@status.net> Date: Thu, 20 Sep 2012 06:36:26 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "Paul C. Bryan" References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> <1348077337.2880.3.camel@polyglot> In-Reply-To: <1348077337.2880.3.camel@polyglot> Content-Type: multipart/alternative; boundary="------------090906080507020106050308" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 10:36:29 -0000 This is a multi-part message in MIME format. --------------090906080507020106050308 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Thanks! Good link here, too: http://goessner.net/articles/JsonPath/ -Evan On 12-09-19 01:55 PM, Paul C. Bryan wrote: > For fun reading—and a bit of a history lesson—see > http://tools.ietf.org/html/draft-pbryan-json-patch-00 and check out > its proposed path notation. Path/pointer notation was then discussed a > fair amount, and slash notation would up being favoured over the > dot/bracket notation. > > Paul > > On Wed, 2012-09-19 at 12:06 -0400, Evan Prodromou wrote: >> On 12-09-19 11:27 AM, Francis Galiegue wrote: >> > JSON Pointer has been written like this on purpose. It is unambiguous, >> > impervious to programming languages pecularities and encodings... All >> > advantages and none of the drawbacks :) >> It conspicuously lacks the advantage of being familiar for people who >> know JavaScript or JavaScript-based syntaxes like the MongoDB example I >> linked to. >> >> That said, I appreciate the response, and I'm just glad the subject has >> been discussed. >> >> -Evan >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > --------------090906080507020106050308 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
    Thanks! Good link here, too:

    http://goessner.net/articles/JsonPath/

    -Evan

    On 12-09-19 01:55 PM, Paul C. Bryan wrote:
    For fun reading—and a bit of a history lesson—see http://tools.ietf.org/html/draft-pbryan-json-patch-00 and check out its proposed path notation. Path/pointer notation was then discussed a fair amount, and slash notation would up being favoured over the dot/bracket notation. 

    Paul

    On Wed, 2012-09-19 at 12:06 -0400, Evan Prodromou wrote: 
    On 12-09-19 11:27 AM, Francis Galiegue wrote:
> JSON Pointer has been written like this on purpose. It is unambiguous, 
> impervious to programming languages pecularities and encodings... All 
> advantages and none of the drawbacks :) 
It conspicuously lacks the advantage of being familiar for people who 
know JavaScript or JavaScript-based syntaxes like the MongoDB example I 
linked to.

That said, I appreciate the response, and I'm just glad the subject has 
been discussed.

-Evan

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


    --------------090906080507020106050308-- From hallam@gmail.com Thu Sep 20 06:04:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7332321F87D5 for ; Thu, 20 Sep 2012 06:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.086 X-Spam-Level: X-Spam-Status: No, score=-4.086 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcpLd0+jNRPv for ; Thu, 20 Sep 2012 06:04:43 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A67821F87FF for ; Thu, 20 Sep 2012 06:04:43 -0700 (PDT) Received: by oagn5 with SMTP id n5so1728461oag.31 for ; Thu, 20 Sep 2012 06:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hDc1TqvknoSr4V6ANAFvJ9pkCA7le7an42Y65ZYFOrA=; b=hjSiT475/Ne7TaEspyDAw9HU9ehVdR8llq978pfvnttk+h6M03iAqPIbI7fEZKOkn0 NutBpJBM7QO9hIW2yU4iEDhpbHFTvxxa9cwKWDcf5Os8yzqI2xQTfGZOM4rExfsM/qzH vYWdQ+4if79bwm1jBAWT8WuBld9BTVBzVlzm3hsanyGh53k3Tdusiio3V1hCdaJpGpuh n+jgeXg2RgeU2M0noUnXhQ7z/XSAqSTMozz0Wqei92w6KPKjJ9vKkRfuk8Aq3LdW7qqL Y33gwUGLObdnAGrr2z0gn2Gqw8pi/Ex0uLwLTz0ih/aOz2w7K/C3Z+f1OuG/xI0MdWPj 1nog== MIME-Version: 1.0 Received: by 10.60.170.229 with SMTP id ap5mr1211698oec.101.1348146281712; Thu, 20 Sep 2012 06:04:41 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 06:04:41 -0700 (PDT) In-Reply-To: <505AF1AA.6080601@status.net> References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> <1348077337.2880.3.camel@polyglot> <505AF1AA.6080601@status.net> Date: Thu, 20 Sep 2012 09:04:41 -0400 Message-ID: From: Phillip Hallam-Baker To: Evan Prodromou Content-Type: multipart/alternative; boundary=bcaec54b4ac03a0a9204ca21c4b3 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 13:04:44 -0000 --bcaec54b4ac03a0a9204ca21c4b3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The notation here does look easier to understand than the slashes. Though they don't seem to appreciate that you need dots and brackets for different purposes. A member label and an array index are two very different things and the syntax should differentiate between them. But there still seems to be the approach of 'lets copy all the functionality of XPath' rather than 'how much XPath functionality is actually necessary'. Might just be a bias on my part here but my college tutor was Tony Hoare and so the idea that you can improve a language by taking unnecessary stuff out tends to come to mind. I don't think we can improve JSON by repeating all the mistakes of XML. I consider the ability to reference a sub-structure to be a programming language concern rather than a data format concern. So the dot notation looks better from that point of view. But programming language bindings don't need to be standardized across languages. If I am writing in C# then it would make sense to use the C# path extractor which might be very different from the Perl or Python extractor (but will probably be the same) The main reason for preferring the dot notation is that the slash character is a reserved character in URLs, in particular HTTP URLs. The only case where I see a need for an interoperable standard is if the path identifier is being used in a URL query or fragment http://www.example.com/whatever? or http://www.example.com/whatever# Now fragment identifiers are actually a document format thing and I need to chase down the reference for it but the slash character is quite definitely reserved in . So it would have to be escaped. Given the choice of a character that has to be escaped vs one that does not we take the one that does not. Array indices are more problematic as [ and ] were declared 'unsafe'. I am not sure that they really are unsafe at this point. ( and ) should be safe but using them instead of the familiar indexes can be confusing. The trickiest part is dealing with the fact that JSON tags can include any character at all and the quoting characters " and ' are definitively unsafe. One approach would be to 'simply' decide that the quotes can be omitted if no ambiguity arises and that the tags much be quoted otherwise. On Thu, Sep 20, 2012 at 6:36 AM, Evan Prodromou wrote: > Thanks! Good link here, too: > > http://goessner.net/articles/JsonPath/ > > -Evan > > > On 12-09-19 01:55 PM, Paul C. Bryan wrote: > > For fun reading=97and a bit of a history lesson=97see > http://tools.ietf.org/html/draft-pbryan-json-patch-00 and check out its > proposed path notation. Path/pointer notation was then discussed a fair > amount, and slash notation would up being favoured over the dot/bracket > notation. > > Paul > > On Wed, 2012-09-19 at 12:06 -0400, Evan Prodromou wrote: > > On 12-09-19 11:27 AM, Francis Galiegue wrote: > > JSON Pointer has been written like this on purpose. It is unambiguous, > > impervious to programming languages pecularities and encodings... All > > advantages and none of the drawbacks :) > It conspicuously lacks the advantage of being familiar for people who > know JavaScript or JavaScript-based syntaxes like the MongoDB example I > linked to. > > That said, I appreciate the response, and I'm just glad the subject has > been discussed. > > -Evan > > _______________________________________________ > apps-discuss mailing listapps-discuss@ietf.orghttps://www.ietf.org/mailma= n/listinfo/apps-discuss > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --=20 Website: http://hallambaker.com/ --bcaec54b4ac03a0a9204ca21c4b3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The notation here does look easier to understand than the slashes. Though t= hey don't seem to appreciate that you need dots and brackets for differ= ent purposes. A member label and an array index are two very different thin= gs and the syntax should differentiate between them.

    But there still seems to be the approach of 'lets copy a= ll the functionality of XPath' rather than 'how much XPath function= ality is actually necessary'.

    Might just be a = bias on my part here but my college tutor was Tony Hoare and so the idea th= at you can improve a language by taking unnecessary stuff out tends to come= to mind. I don't think we can improve JSON by repeating all the mistak= es of XML.


    I consider the ability to reference a su= b-structure to be a programming language concern rather than a data format = concern. So the dot notation looks better from that point of view. But prog= ramming language bindings don't need to be standardized across language= s. If I am writing in C# then it would make sense to use the C# path extrac= tor which might be very different from the Perl or Python extractor (but wi= ll probably be the same)

    The main reason for preferring the dot notation is that= the slash character is a reserved character in URLs, in particular HTTP UR= Ls.=A0

    The only case where I see a need for an int= eroperable standard is if the path identifier is being used in a =A0URL que= ry or fragment


    o= r

    htt= p://www.example.com/whatever#<path-expression>

    Now fragment identifiers are actually a document format thing and I nee= d to chase down the reference for it but the slash character is quite defin= itely reserved in <path-expression>. So it would have to be escaped. = Given the choice of a character that has to be escaped vs one that does not= we take the one that does not.

    Array indices are more problematic as [ and ] were decl= ared 'unsafe'. I am not sure that they really are unsafe at this po= int. ( and ) should be safe but using them instead of the familiar indexes = can be confusing.

    The trickiest part is dealing with the fact that JSON t= ags can include any character at all and the quoting characters " and = ' are definitively unsafe. One approach would be to 'simply' de= cide that the quotes can be omitted if no ambiguity arises and that the tag= s much be quoted otherwise.=A0




    On Thu, Sep 20, 2012 at 6:3= 6 AM, Evan Prodromou <evan@status.net> wrote:
    =20 =20 =20
    Thanks! Good link here, too:

    =20 = http://goessner.net/articles/JsonPath/

    -Evan


    On 12-09-19 01:55 PM, Paul C. Bryan wrote:
    =20 =20 For fun reading=97and a bit of a history lesson=97see http:/= /tools.ietf.org/html/draft-pbryan-json-patch-00 and check out its proposed path notation. Path/pointer notation was then discussed a fair amount, and slash notation would up being favoured over the dot/bracket notation.=A0

    Paul

    On Wed, 2012-09-19 at 12:06 -0400, Evan Prodromou wrote: 
    On 12-09-19 11:27 AM, Francis Galiegue wrote:
> JSON Pointer has been written like this on purpose. It is unambiguous,=
=20
> impervious to programming languages pecularities and encodings... All=
=20
> advantages and none of the drawbacks :)=20
It conspicuously lacks the advantage of being familiar for people who=20
know JavaScript or JavaScript-based syntaxes like the MongoDB example I=20
linked to.

That said, I appreciate the response, and I'm just glad the subject has=
=20
been discussed.

-Evan

_______________________________________________
apps-discuss mailing list
apps-discuss@iet=
f.org
https://www.ietf.org/mailman/listinfo/apps-discuss



    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss




    --
    Website:= http://hallambaker.com/

    --bcaec54b4ac03a0a9204ca21c4b3-- From julian.reschke@gmx.de Thu Sep 20 06:25:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E9B21F87EA for ; Thu, 20 Sep 2012 06:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.122 X-Spam-Level: X-Spam-Status: No, score=-103.122 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64E0ZETjOXZf for ; Thu, 20 Sep 2012 06:25:50 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B003021F87E9 for ; Thu, 20 Sep 2012 06:25:49 -0700 (PDT) Received: (qmail invoked by alias); 20 Sep 2012 13:25:48 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp034) with SMTP; 20 Sep 2012 15:25:48 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/4y8oa66X4vwFDAyudRe+GGQB89Am+P/zvWx8cRA Nt+fwGffj6lsTu Message-ID: <505B194D.9080002@gmx.de> Date: Thu, 20 Sep 2012 15:25:33 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> <1348077337.2880.3.camel@polyglot> <505AF1AA.6080601@status.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 13:25:50 -0000 On 2012-09-20 15:04, Phillip Hallam-Baker wrote: > The notation here does look easier to understand than the slashes. > Though they don't seem to appreciate that you need dots and brackets for > different purposes. A member label and an array index are two very > different things and the syntax should differentiate between them. Does it need to? > But there still seems to be the approach of 'lets copy all the > functionality of XPath' rather than 'how much XPath functionality is > actually necessary'. How so, except for the choice of separators????? > Might just be a bias on my part here but my college tutor was Tony Hoare > and so the idea that you can improve a language by taking unnecessary > stuff out tends to come to mind. I don't think we can improve JSON by > repeating all the mistakes of XML. I don't think this is the case here at all. > I consider the ability to reference a sub-structure to be a programming > language concern rather than a data format concern. So the dot notation > looks better from that point of view. But programming language bindings > don't need to be standardized across languages. If I am writing in C# > then it would make sense to use the C# path extractor which might be > very different from the Perl or Python extractor (but will probably be > the same) > > The main reason for preferring the dot notation is that the slash > character is a reserved character in URLs, in particular HTTP URLs. How is that a problem? It's reserved for hierarchical notations, and that's exactly what it's been used for here. > The only case where I see a need for an interoperable standard is if the > path identifier is being used in a URL query or fragment > > http://www.example.com/whatever? > > or > > http://www.example.com/whatever# The main use case I see actually is http://www.example.com/ > ... Best regards, Julian From hallam@gmail.com Thu Sep 20 06:52:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F4221F841B for ; Thu, 20 Sep 2012 06:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.076 X-Spam-Level: X-Spam-Status: No, score=-4.076 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ve19xwkrLqzC for ; Thu, 20 Sep 2012 06:52:53 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB61C21F8417 for ; Thu, 20 Sep 2012 06:52:51 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2397358obb.31 for ; Thu, 20 Sep 2012 06:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oGtCaEk3S8XdjuGDuFnARU5zl4pRSQFUkKmFIx7oVW8=; b=l0snXBwhHt152nOJU0Zb/CaVYiu+Ek46B+7PMExn1GO9a6xcdGUK8QZ9/7pkiO4Zwo 0CG3nKwIePkSY1DyWA4/520c/MM9I6/CTkWVtoTcz+a1G7uqfu8f0AJDaiMhuManlQ8x cCa3Npbhp3IaW+LTNKKcM60p/JK3zl1RCqz/dBKI68HrRDRt3iG8rLG/E2lAmrYmc/1j pmNr+3XfXFezrAhMnlJo7kKwsXFagBJm2s7n4pPdCpP/lfkYoIyVaga187S+fexT2T7m OP5I0PdAnWMAgjshHvaXEdnw2msv1B9puBBnKF7ytnzqdCWE44eAzZI6EegWm/JeuX3P /MqA== MIME-Version: 1.0 Received: by 10.60.170.229 with SMTP id ap5mr1325711oec.101.1348149170045; Thu, 20 Sep 2012 06:52:50 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 06:52:49 -0700 (PDT) In-Reply-To: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> Date: Thu, 20 Sep 2012 09:52:49 -0400 Message-ID: From: Phillip Hallam-Baker To: "Tschofenig, Hannes (NSN - FI/Espoo)" Content-Type: multipart/alternative; boundary=bcaec54b4ac062813f04ca22706b Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 13:52:54 -0000 --bcaec54b4ac062813f04ca22706b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Actually I agree with most of what Hannes says here. I found using a schema helpful in writing the SAML spec but I didn't use XML schema. I used a tool and generated the XML Schema and the text from my own schema language. That addressed the problem of the spec and schema being out of sync which was a real bear as the SAML TC made major changes to the schema, adding and dropping items at each con-call What I think we need for the IETF is a tool to help document protocols. Now that might be a schema done right or it might be a protocol description tool. Extensibility is certainly problematic. I have seen pretty much every WG using XML end up in rat hole after rat hole as people try to consider what v 1.1 of the spec might look like. XML Schema looks like it should answer that question but it does not. And not many other tools do so either. This problem crops up in a JSON protocol as well. Should unknown tags be ignored or cause an error? Should there be a mechanism that allows intentional breaking of backwards compatibility in cases where doing so may cause applications to do the wrong thing? Even the terminology can be disastrous. There is a feature in X,509v3 that is designed to allow a certificate to say 'if you don't understand and process this extension then reject this certificate'. The original intention was to allow extensions to specify new revocation/status checking schemes. RPs that did not understand the scheme could not use the certificate. Unfortunately that feature was called 'critical' which also means 'important'. And so people started using 'critical' to mean 'I think this is important' and not 'I think this so important that you should break backwards compatibility'. This is why I called the same feature 'Conditions' in the SAML specification and disguised it so that it didn't look like a criticality flag. But Conditions and Criticality are the exact same thing. The SAML assertion structure began life as part of a design to re-do X.509 in XML which is why it had to have some equivalent of criticality. What we need in my view is a way to identify the places where additional items can be added into protocol messages and a default that additional items are prohibited everywhere else. So in my Simple JSON Schema I would represent a SAML assertion like thing something like: Type Assertion Description "Assertion container yada yada" DateTime Issued DateTime NotBefore DateTime NotOnOrAfter List Any Statements List Any Conditions List Any Advice [I have left out the descriptions of the member elements but everything is documented, that is the point in fact.] The Any type is an intrinsic type that refers to an object that is tagged with the object type. So an authentication assertion would be tagged with a "authentication" an authorization assertion with "authorization" and so on. So the JSON structures compatible with the above signature would be { "Assertion" { "Issued": "RFC3339Time", "NotBefore": "RFC3339Time", "NotOnOrAfter": "RFC3339Time", "Statements" : [ {"Authentication": {whatever}}, {"NewAssertion" : {}}], "Conditions" : [ { "Audience" : {}} ], "Advice" : [ {"Proof" : {}} ] } The explicit extension model here is that any new elements of any type can be added in to the Statement, Conditions and Advice lists, just tag each member with its type. Depending on the circumstance the Assertion object itself might be open or closed, that is it might be permissible to add in additional members or receivers might be required to reject them. Note that my tool does not use JSON syntax to describe the schema. This is intentional since the primary design goal is to make editing easy. I find XML to be a tiresome format to edit by hand and JSON looks rather worse. I am not that fond of C style either, the semicolons are unnecessary and so are the braces if you use indentation properly. Removing all the clutter makes the spec much easier to read. A protocol design schema can be very much simpler than XML schema as it does not have to support the ability to describe every possible JSON or XML encoding. It only needs to be sufficiently descriptive to specify the messages we want to use. So it is not necessary to consider corner cases like non alphanumeric tags or tags with spaces. They are legal JSON tags but they are not going to be accepted as protocol tags by an IETF WG. It is not necessary to specify every possible encoding of time as we have decided we are only going to use RFC3339. We can even build into the compiler additional nits restrictions such as 'don't allow the tags to have the same name as the reserved words in C#, C++, Java or Python. "for" is a perfectly legal JSON tag but trying to use "for" as a tag in a protocol message would be an act of stupidity, malice or both. On Thu, Sep 20, 2012 at 2:26 AM, Tschofenig, Hannes (NSN - FI/Espoo) < hannes.tschofenig@nsn.com> wrote: > My 5 cents to this topic. **** > > ** ** > > Even though many folks, including Tim Bray, educated the community that i= t > is not necessary to produce XML schemas when writing specifications that > use XML, everyone did. They felt that the specification was not complete > without the schema.**** > > ** ** > > The consequence was that **** > > **=B7 **The XML replaced text in specifications leaving important > semantic unspecified. Look at many of the OASIS document, for example CAP= , > and you know what I am talking about. The authors somehow thought that th= e > schema is a replacement for a description of what the protocol actually > does. Wrong! Interoperability problems are the consequence.**** > > **=B7 **Sometimes the XML schema was provided in addition to a > textual description. Nice idea but then they often get out of sync. **** > > **=B7 **Extensibility thoughts were left behind. XML by itself mea= nt > extensible, at least that=92s what many thought, and hence there was no s= tory > about how the protocol would get extended in a smooth way and what the > policies are for extensions.**** > > ** ** > > The worst thing was, however, that the entire protocol development was > guided by the (lack of) understanding of the XML schema language rather > than the requirements for the actual protocol. **** > > ** ** > > Funny enough the schema did not really help anyone: it did not help a > person reading the specification (who does not want to implement it) sinc= e > they typically care about an entire level of detail nor the guy who wants > to implements it. Just using the schema for an implementation was never > enough because you had to consider all the other special case as well > (which can typically only be found elsewhere in the specification). If yo= u > managed to encode all the special cases into the schema then it became > unreadable. The instance validation against concept was also useless once > you included the proper extension points. **** > > ** ** > > In a nutshell, I think that XML (& Relax NG) schemas are harmful. > Unfortunately, it is already too late for fixing that in the IETF. I > believe we should not introduce schemas into JSON in the IETF. Everything > will be fine without using it. **** > > ** ** > > Ciao**** > > Hannes**** > > ** ** > --=20 Website: http://hallambaker.com/ --bcaec54b4ac062813f04ca22706b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Actually I agree with most of what Hannes says here.

    I f= ound using a schema helpful in writing the SAML spec but I didn't use X= ML schema. I used a tool and generated the XML Schema and the text from my = own schema language. That addressed the problem of the spec and schema bein= g out of sync which was a real bear as the SAML TC made major changes to th= e schema, adding and dropping items at each con-call

    What I think we need for the IETF is a tool to help doc= ument protocols. Now that might be a schema done right or it might be a pro= tocol description tool.=A0


    Extensib= ility is certainly problematic. I have seen pretty much every WG using XML = end up in rat hole after rat hole as people try to consider what v 1.1 of t= he spec might look like. XML Schema looks like it should answer that questi= on but it does not. And not many other tools do so either.

    This problem crops up in a JSON protocol as well. Shoul= d unknown tags be ignored or cause an error? Should there be a mechanism th= at allows intentional breaking of backwards compatibility in cases where do= ing so may cause applications to do the wrong thing?

    Even the terminology can be disastrous. There is a feat= ure in X,509v3 that is designed to allow a certificate to say 'if you d= on't understand and process this extension then reject this certificate= '. The original intention was to allow extensions to specify new revoca= tion/status checking schemes. RPs that did not understand the scheme could = not use the certificate.=A0

    Unfortunately that feature was called 'critical'= ; which also means 'important'. And so people started using 'cr= itical' to mean 'I think this is important' and not 'I thin= k this so important that you should break backwards compatibility'. Thi= s is why I called the same feature 'Conditions' in the SAML specifi= cation and disguised it so that it didn't look like a criticality flag.= But Conditions and Criticality are the exact same thing. The SAML assertio= n structure began life as part of a design to re-do X.509 in XML which is w= hy it had to have some equivalent of criticality.


    What we need in my view is a way to iden= tify the places where additional items can be added into protocol messages = and a default that additional items are prohibited everywhere else. So in m= y Simple JSON Schema I would represent a SAML assertion like thing somethin= g like:

    Type Assertion
    =A0 =A0 Description "Assertion conta= iner yada yada"
    =A0 =A0 DateTime Issued=A0
    =A0 =A0= DateTime NotBefore
    =A0 =A0 DateTime NotOnOrAfter
    =A0 = =A0 List Any Statements
    =A0 =A0 List Any Conditions
    =A0 =A0 List Any Advice

    [I have = left out the descriptions of the member elements but everything is document= ed, that is the point in fact.]

    The Any type is an intrinsic type th= at refers to an object that is tagged with the object type. So an authentic= ation assertion would be tagged with a "authentication" an author= ization assertion with "authorization" and so on.

    So the JSON structures compatible with the above signat= ure would be

    { "Assertion" {
    = =A0 =A0 "Issued": "RFC3339Time",
    =A0 =A0 &quo= t;NotBefore":=A0=A0"RFC3339Time",
    =A0 =A0=A0"NotOnOrAfter":=A0=A0"RFC3339Time",
    = =A0 =A0 "Statements" : [=A0
    =A0 =A0 =A0 =A0 {"Auth= entication": {whatever}},
    =A0 =A0 =A0 =A0 {"NewAssertio= n" : {<any valid JSON can go here>}}],
    =A0 =A0 "Conditions" : [ { "Audience" : {<any v= alid JSON can go here>}}=A0],
    =A0 =A0 "Advice" : [ {= "Proof" : {<any valid JSON can go here>}}=A0]
    =A0= =A0 }

    The explicit extension model here is that any new elements of any type can = be added in to the Statement, Conditions and Advice lists, just tag each me= mber with its type.

    Depending on the circumstance = the Assertion object itself might be open or closed, that is it might be pe= rmissible to add in additional members or receivers might be required to re= ject them.

    Note that my tool does not use JSON syntax to describe = the schema. This is intentional since the primary design goal is to make ed= iting easy. I find XML to be a tiresome format to edit by hand and JSON loo= ks rather worse. I am not that fond of C style either, the semicolons are u= nnecessary and so are the braces if you use indentation properly. Removing = all the clutter makes the spec much easier to read.


    A protocol design schema can be very much simpler than XML sch= ema as it does not have to support the ability to describe every possible J= SON or XML encoding. It only needs to be sufficiently descriptive to specif= y the messages we want to use.

    So it is not necessary to consider corner cases like no= n alphanumeric tags or tags with spaces. They are legal JSON tags but they = are not going to be accepted as protocol tags by an IETF WG. It is not nece= ssary to specify every possible encoding of time as we have decided we are = only going to use RFC3339.=A0

    We can even build into the compiler additional nits res= trictions such as 'don't allow the tags to have the same name as th= e reserved words in C#, C++, Java or Python. "for" is a perfectly= legal JSON tag but trying to use "for" as a tag in a protocol me= ssage would be an act of stupidity, malice or both.


    On Thu, Sep 20, 2012 at 2:26 AM, Tschofe= nig, Hannes (NSN - FI/Espoo) <hannes.tschofenig@nsn.com> wrote:

    My 5 cents to= this topic.

    =A0<= /p>

    Even though many folks= , including Tim Bray, educated the community that it is not necessary to pr= oduce XML schemas when writing specifications that use XML, everyone did. T= hey felt that the specification was not complete without the schema.=

    =A0<= /p>

    The consequence was th= at

    =B7=A0=A0=A0= =A0=A0=A0=A0 The XML= replaced text in specifications leaving important semantic unspecified. Lo= ok at many of the OASIS document, for example CAP, and you know what I am t= alking about. The authors somehow thought that the schema is a replacement = for a description of what the protocol actually does. Wrong! Interoperabili= ty problems are the consequence.

    =B7=A0=A0=A0= =A0=A0=A0=A0 Sometim= es the XML schema was provided in addition to a textual description. Nice i= dea but then they often get out of sync.

    =B7=A0=A0=A0= =A0=A0=A0=A0 Extensi= bility thoughts were left behind. XML by itself meant extensible, at least = that=92s what many thought, and hence there was no story about how the prot= ocol would get extended in a smooth way and what the policies are for exten= sions.

    =A0<= /p>

    The worst thing was, h= owever, that the entire protocol development was guided by the (lack of) un= derstanding of the XML schema language rather than the requirements for the= actual protocol.

    =A0<= /p>

    Funny enough the schem= a did not really help anyone: it did not help a person reading the specific= ation (who does not want to implement it) since they typically care about a= n entire level of detail nor the guy who wants to implements it. Just using= the schema for an implementation was never enough because you had to consi= der all the other special case as well (which can typically only be found e= lsewhere in the specification). If you managed to encode all the special ca= ses into the schema then it became unreadable. The instance validation agai= nst concept was also useless once you included the proper extension points.=

    =A0<= /p>

    In a nutshell, I think= that XML (& Relax NG) schemas are harmful. Unfortunately, it is alread= y too late for fixing that in the IETF. I believe we should not introduce s= chemas into JSON in the IETF. Everything will be fine without using it. =

    =A0<= /p>

    Ciao

    Hannes

    =A0<= u>



    --
    Website: http://hallambaker.com/

    --bcaec54b4ac062813f04ca22706b-- From hallam@gmail.com Thu Sep 20 07:07:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8610A21F8468 for ; Thu, 20 Sep 2012 07:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.066 X-Spam-Level: X-Spam-Status: No, score=-4.066 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj8q8o5Oi4Y6 for ; Thu, 20 Sep 2012 07:07:45 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8686521F8460 for ; Thu, 20 Sep 2012 07:07:45 -0700 (PDT) Received: by oagn5 with SMTP id n5so1813267oag.31 for ; Thu, 20 Sep 2012 07:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DEz8+uvkXzNuBUsEMcanfixrNv3CfCnOycOCrh1/Qrg=; b=TtV29P7/TYVCR97YIU6YecoryzoUx1D7dPCeLsGDFKCPk3Xt14RLWfY1mXBi299Lgs mLInNuycLuhAUltdUqS80+wT0XXQLtsSatHUJ2huWf8ipVrkUBYNwdvbwRNJLHlqxIm8 TmWkNFSk7RfwYKCMPoQ26MDENZW/JH7E1QoMfiloOdfDh5OV/5RlexHkxtME92Ta3Kk9 CaK+Vs1kerTL+iMrxpBbduMNc0IgIsirpqPVHH9vt29Cmlro8l4rX1OrIlY3DS3wwkdq 5mPfG+s7D6jmmZ3roHLz6lS7BGEvZwtQVyCVXr+DdeXMfN22I36jYz9z9CfoNFyQ/Kz4 pRbA== MIME-Version: 1.0 Received: by 10.60.25.129 with SMTP id c1mr1354355oeg.36.1348150065069; Thu, 20 Sep 2012 07:07:45 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 07:07:44 -0700 (PDT) In-Reply-To: <505B194D.9080002@gmx.de> References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> <1348077337.2880.3.camel@polyglot> <505AF1AA.6080601@status.net> <505B194D.9080002@gmx.de> Date: Thu, 20 Sep 2012 10:07:44 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=e89a8ff1c6cebb7ff004ca22a5e4 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 14:07:46 -0000 --e89a8ff1c6cebb7ff004ca22a5e4 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 20, 2012 at 9:25 AM, Julian Reschke wrote: > On 2012-09-20 15:04, Phillip Hallam-Baker wrote: > >> The notation here does look easier to understand than the slashes. >> Though they don't seem to appreciate that you need dots and brackets for >> different purposes. A member label and an array index are two very >> different things and the syntax should differentiate between them. >> > > Does it need to? Yes, it does consider: { "alice" : { "bob" : [ 10, 20, 30] } } Let us imagine we have code that is stepping through each element of an array using an index i. The path looks like alice.bob.i Iterating the loop produces 10, 20, 30 When evaluating that expression in a scripting language or such we have alice and bob which are tag names and we have i which is a bound variable being used as an index. That leads to confusion. Now imagine that mallet knows that the index variable used is i, she creates the following message: { "alice" : { "bob" : [ 10, 20, 30] , "i" : 42 } } Depending on the implementation the iteration may now produce 10, 20, 30 as before or 42 or even 42, 42, 42. This is why languages like Java and C# kept the concept of array indices when the jettisoned all the rest of the baroque C++ syntax. It is an important difference with real security implications. This is also why folk like me never want to use type unsafe scripting languages designed by people who didn't appreciate this type of issue. > But there still seems to be the approach of 'lets copy all the >> functionality of XPath' rather than 'how much XPath functionality is >> actually necessary'. >> > > How so, except for the choice of separators????? Reading the original post cited, the author suggests that XPath functionality is the goal. It really should not be. > I consider the ability to reference a sub-structure to be a programming >> language concern rather than a data format concern. So the dot notation >> looks better from that point of view. But programming language bindings >> don't need to be standardized across languages. If I am writing in C# >> then it would make sense to use the C# path extractor which might be >> very different from the Perl or Python extractor (but will probably be >> the same) >> >> The main reason for preferring the dot notation is that the slash >> character is a reserved character in URLs, in particular HTTP URLs. >> > > How is that a problem? It's reserved for hierarchical notations, and > that's exactly what it's been used for here. No, it is RESERVED as in do not use it after the query. We are not talking about a change to the HTTP URL spec here. So we MUST NOT use that character. It is out of bounds. The only case where I see a need for an interoperable standard is if the >> path identifier is being used in a URL query or fragment >> >> http://www.example.com/**whatever >> ? >> >> or >> >> http://www.example.com/**whatever# >> >> > > The main use case I see actually is > > http://www.example.com/ > OK, if you are going to do that then you can use the / separator. But I rather suspect that not distinguishing the boundary between the file system and the document is going to be problematic. There may even be security issues. -- Website: http://hallambaker.com/ --e89a8ff1c6cebb7ff004ca22a5e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Thu, Sep 20, 2012 at 9:25 AM, Julian = Reschke <julian.reschke@gmx.de> wrote:
    On 2012-09-20 15:04, Phillip Hallam-Baker wrote:
    The notation here does look easier to understand than the slashes.
    Though they don't seem to appreciate that you need dots and brackets fo= r
    different purposes. A member label and an array index are two very
    different things and the syntax should differentiate between them.

    Does it need to?

    Yes, it does consider:

    { "alice" : { "bob" : [ 10, 20, 3= 0] } }


    Let us imagine we have code = that is stepping through each element of an array using an index i. The pat= h looks like =A0alice.bob.i

    Iterating the loop produces 10, 20, 30

    When evaluating that expression in a scripting language or such we= have alice and bob which are tag names and we have i which is a bound vari= able being used as an index. That leads to confusion.

    Now imagine that mallet knows that the index variable u= sed is i, she creates the following message:


    <= /div>
    { "alice" : { "bob" : [ 10, 20, 30] , "i= " : 42 } }

    Depending on the implementation the iteration may now p= roduce 10, 20, 30 as before or 42 or even 42, 42, 42.

    <= div>This is why languages like Java and C# kept the concept of array indice= s when the jettisoned all the rest of the baroque C++ syntax. It is an impo= rtant difference with real security implications.

    This is also why folk like me never want to use type un= safe scripting languages designed by people who didn't appreciate this = type of issue.


    =A0
    But there still seems to be the approach of 'lets copy all the
    functionality of XPath' rather than 'how much XPath functionality i= s
    actually necessary'.

    How so, except for the choice of separators?????

    Reading the original post cited, the author suggests that XPath funct= ionality is the goal. It really should not be.

    =A0
    I consider the ability to reference a sub-structure to be a programming
    language concern rather than a data format concern. So the dot notation
    looks better from that point of view. But programming language bindings
    don't need to be standardized across languages. If I am writing in C# then it would make sense to use the C# path extractor which might be
    very different from the Perl or Python extractor (but will probably be
    the same)

    The main reason for preferring the dot notation is that the slash
    character is a reserved character in URLs, in particular HTTP URLs.

    How is that a problem? It's reserved for hierarchical notations, and th= at's exactly what it's been used for here.

    No, it is RESERVED as in do not use it after the query.

    We are not talking about a change to the HTTP URL spec here.= So we MUST NOT use that character. It is out of bounds.


    The only case where I see a need for an interoperable standard is if the path identifier is being used in a =A0URL query or fragment

    http://www.ex= ample.com/whatever?<path-expression>

    or

    http://www.e= xample.com/whatever#<path-expression>

    The main use case I see actually is

    http://www.example.co= m/<path-expression>

    OK= , if you are going to do that then you can use the / separator. =A0But I ra= ther suspect that not distinguishing the boundary between the file system a= nd the document is going to be problematic. There may even be security issu= es.=A0


    --
    Website: http://hallambaker.com/

    --e89a8ff1c6cebb7ff004ca22a5e4-- From julian.reschke@gmx.de Thu Sep 20 07:16:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF4321F877E for ; Thu, 20 Sep 2012 07:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.084 X-Spam-Level: X-Spam-Status: No, score=-103.084 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpn21YbdnmmQ for ; Thu, 20 Sep 2012 07:16:10 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id BF6B021F86E5 for ; Thu, 20 Sep 2012 07:16:09 -0700 (PDT) Received: (qmail invoked by alias); 20 Sep 2012 14:16:08 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp019) with SMTP; 20 Sep 2012 16:16:08 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19GoxMRJ81Gi12KG7S6d5vwjR3v1kXZYn8Z006/to PAeYXHVYX0Yu8T Message-ID: <505B2513.8000900@gmx.de> Date: Thu, 20 Sep 2012 16:15:47 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> <1348077337.2880.3.camel@polyglot> <505AF1AA.6080601@status.net> <505B194D.9080002@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 14:16:11 -0000 On 2012-09-20 16:07, Phillip Hallam-Baker wrote: > > > On Thu, Sep 20, 2012 at 9:25 AM, Julian Reschke > wrote: > > On 2012-09-20 15:04, Phillip Hallam-Baker wrote: > > The notation here does look easier to understand than the slashes. > Though they don't seem to appreciate that you need dots and > brackets for > different purposes. A member label and an array index are two very > different things and the syntax should differentiate between them. > > > Does it need to? > > > Yes, it does consider: > > { "alice" : { "bob" : [ 10, 20, 30] } } > > > Let us imagine we have code that is stepping through each element of an > array using an index i. The path looks like alice.bob.i > > Iterating the loop produces 10, 20, 30 > > When evaluating that expression in a scripting language or such we have > alice and bob which are tag names and we have i which is a bound > variable being used as an index. That leads to confusion. > > Now imagine that mallet knows that the index variable used is i, she > creates the following message: > > > { "alice" : { "bob" : [ 10, 20, 30] , "i" : 42 } } > > Depending on the implementation the iteration may now produce 10, 20, 30 > as before or 42 or even 42, 42, 42. > > This is why languages like Java and C# kept the concept of array indices > when the jettisoned all the rest of the baroque C++ syntax. It is an > important difference with real security implications. > > This is also why folk like me never want to use type unsafe scripting > languages designed by people who didn't appreciate this type of issue. Well, JSON Pointer has: If a reference token is being evaluated against a JSON document, implementations will evaluate each token against the document's contents, and terminate evaluation with an error condition if it fails to resolve a concrete value for any of the JSON pointer's reference tokens. See Section 7 for details. So for any given pointer and object syntax, it's clear whether it's an array or not. > But there still seems to be the approach of 'lets copy all the > functionality of XPath' rather than 'how much XPath functionality is > actually necessary'. > > > How so, except for the choice of separators????? > > > Reading the original post cited, the author suggests that XPath > functionality is the goal. It really should not be. I personally think that XPath is awesome. But that being said, JSON Pointer as specified in the internet draft is really only a sequence of identifiers separated by "/". That's it. I don't think it is productive to question things that are actually not in the Internet Draft- > I consider the ability to reference a sub-structure to be a > programming > language concern rather than a data format concern. So the dot > notation > looks better from that point of view. But programming language > bindings > don't need to be standardized across languages. If I am writing > in C# > then it would make sense to use the C# path extractor which might be > very different from the Perl or Python extractor (but will > probably be > the same) > > The main reason for preferring the dot notation is that the slash > character is a reserved character in URLs, in particular HTTP URLs. > > > How is that a problem? It's reserved for hierarchical notations, and > that's exactly what it's been used for here. > > > No, it is RESERVED as in do not use it after the query. > > We are not talking about a change to the HTTP URL spec here. So we MUST > NOT use that character. It is out of bounds. BS. Nobody is proposing to change the URI syntax, which happens to say: query = *( pchar / "/" / "?" ) (). > The only case where I see a need for an interoperable standard > is if the > path identifier is being used in a URL query or fragment > > http://www.example.com/__whatever > ? > > or > > http://www.example.com/__whatever# > > > > The main use case I see actually is > > http://www.example.com/ > > > OK, if you are going to do that then you can use the / separator. But I > rather suspect that not distinguishing the boundary between the file > system and the document is going to be problematic. There may even be > security issues. There's no "file system" in my server. And even if there was, it wouldn't matter because we're defining message formats and identifier syntax, not how a server implements those. And yes, there are always security issues. Best regards, Julian From hallam@gmail.com Thu Sep 20 07:59:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D922221F879C for ; Thu, 20 Sep 2012 07:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.057 X-Spam-Level: X-Spam-Status: No, score=-4.057 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SH-OzYrPhBL5 for ; Thu, 20 Sep 2012 07:59:02 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 706F721F877E for ; Thu, 20 Sep 2012 07:59:01 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2487261obb.31 for ; Thu, 20 Sep 2012 07:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1JWHxNBpQXLIAPJUgJnWXnjrMBOJd4XKCS59voTODNE=; b=brpCOhZpBkezCgfTdJYVa6IpuL4MwgY2GtaESUQnqSRVr2ei/NAalSaSostajjKlAR guYSkYveVDb/hyReAi56p/+Hgimhz1fCEaq4ZeInf7iNQnimNNmnDzouiCUkoiJBIPmS 1V11sDwtPt9ooCWPz+VCUbcVYDGMoZdeiNc5UN27i8Ywq1OdShb6s5k29pCyvr331ZFa AaeXy8yhTtAd/j2lzM2DrapV0mWnu+BHARv6U1qG7620EhJhD9TMvww8ciBr1QGVAB/0 KsqfOrmVUdL+TcYexBI2yzyTVz1ShDFteWcyei7XEhvbQ4ziHSu81UwPhLSJGRaRRQN9 kEGw== MIME-Version: 1.0 Received: by 10.182.207.6 with SMTP id ls6mr1523510obc.36.1348153139553; Thu, 20 Sep 2012 07:58:59 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 07:58:59 -0700 (PDT) In-Reply-To: <505B2513.8000900@gmx.de> References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> <1348077337.2880.3.camel@polyglot> <505AF1AA.6080601@status.net> <505B194D.9080002@gmx.de> <505B2513.8000900@gmx.de> Date: Thu, 20 Sep 2012 10:58:59 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=e89a8f646e2bfc65e504ca235c02 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 14:59:06 -0000 --e89a8f646e2bfc65e504ca235c02 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 20, 2012 at 10:15 AM, Julian Reschke wrote: > On 2012-09-20 16:07, Phillip Hallam-Baker wrote: > >> >> >> On Thu, Sep 20, 2012 at 9:25 AM, Julian Reschke > **> wrote: >> >> On 2012-09-20 15:04, Phillip Hallam-Baker wrote: >> >> The notation here does look easier to understand than the slashes. >> Though they don't seem to appreciate that you need dots and >> brackets for >> different purposes. A member label and an array index are two very >> different things and the syntax should differentiate between them. >> >> >> Does it need to? >> >> >> Yes, it does consider: >> >> { "alice" : { "bob" : [ 10, 20, 30] } } >> >> >> Let us imagine we have code that is stepping through each element of an >> array using an index i. The path looks like alice.bob.i >> >> Iterating the loop produces 10, 20, 30 >> >> When evaluating that expression in a scripting language or such we have >> alice and bob which are tag names and we have i which is a bound >> variable being used as an index. That leads to confusion. >> >> Now imagine that mallet knows that the index variable used is i, she >> creates the following message: >> >> >> { "alice" : { "bob" : [ 10, 20, 30] , "i" : 42 } } >> >> Depending on the implementation the iteration may now produce 10, 20, 30 >> as before or 42 or even 42, 42, 42. >> >> This is why languages like Java and C# kept the concept of array indices >> when the jettisoned all the rest of the baroque C++ syntax. It is an >> important difference with real security implications. >> >> This is also why folk like me never want to use type unsafe scripting >> languages designed by people who didn't appreciate this type of issue. >> > > Well, JSON Pointer has: > > If a reference token is being evaluated against a JSON document, > implementations will evaluate each token against the document's > contents, and terminate evaluation with an error condition if it > fails to resolve a concrete value for any of the JSON pointer's > reference tokens. See Section 7 for details. > I do not understand that text. It is completely opaque to me. Or rather, I cannot decide on one single unambiguous interpretation. I certainly don't see it as something that can be quoted to resolve ambiguity of the type I raised. Which one of the outcomes do you think it requires? I certainly can't tell and I have a doctorate on formal methods. So if I can't tell I think the likelihood of the statement meaning something to an implementer is rather small. > So for any given pointer and object syntax, it's clear whether it's an > array or not. How do you resolve the example I quote? I am asking questions of interpretation here and your response is always 'go read the spec'. Well that is the whole issue, the spec is not clear and it cannot be clear on this issue unless it raises it and addresses it as a specific case. If people can't explain how a spec should be interpreted then the spec fails. And yes, I have had to redesign a protocol because I could not explain something clearly more often than I can recall. > I personally think that XPath is awesome. But that being said, JSON > Pointer as specified in the internet draft is really only a sequence of > identifiers separated by "/". That's it. I don't think it is productive to > question things that are actually not in the Internet Draft- It is awesomely powerful if you need power. As a mechanism for identifying sections of a document covered by XML Signature it is a catastrophe. > No, it is RESERVED as in do not use it after the query. >> >> We are not talking about a change to the HTTP URL spec here. So we MUST >> NOT use that character. It is out of bounds. >> > > BS. Nobody is proposing to change the URI syntax, which happens to say: > > query = *( pchar / "/" / "?" ) > It goes on to say: The characters slash ("/") and question mark ("?") may represent data within the query component. Beware that some older, erroneous implementations may not handle such data correctly when it is used as the base URI for relative references (Section 5.1), apparently because they fail to distinguish query data from path data when looking for hierarchical separators. However, as query components are often used to carry identifying information in the form of "key=value" pairs and one frequently used value is a reference to another URI, it is sometimes better for usability to avoid percent-encoding those characters. This would not be something I would see as critical if there was not another choice here. Probably the safest approach is to permit either separator to be used in the path expression and make them interchangeable which is what we did with " and '. That still leaves the question of what to do with []. It looks like they should be safe but it is something I would want to see tested. -- Website: http://hallambaker.com/ --e89a8f646e2bfc65e504ca235c02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Thu, Sep 20, 2012 at 10:15 AM, Julian= Reschke <julian.reschke@gmx.de> wrote:
    On 2012-09-20 16:07, Phillip Hallam-Baker wrote:


    On Thu, Sep 20, 2012 at 9:25 AM, Julian Reschke <julian.reschke@gmx.de
    <mailto:julia= n.reschke@gmx.de>> wrote:

    =A0 =A0 On 2012-09-20 15:04, Phillip Hallam-Baker wrote:

    =A0 =A0 =A0 =A0 The notation here does look easier to understand than the s= lashes.
    =A0 =A0 =A0 =A0 Though they don't seem to appreciate that you need dots= and
    =A0 =A0 =A0 =A0 brackets for
    =A0 =A0 =A0 =A0 different purposes. A member label and an array index are t= wo very
    =A0 =A0 =A0 =A0 different things and the syntax should differentiate betwee= n them.


    =A0 =A0 Does it need to?


    Yes, it does consider:

    { "alice" : { "bob" : [ 10, 20, 30] } }


    Let us imagine we have code that is stepping through each element of an
    array using an index i. The path looks like =A0alice.bob.i

    Iterating the loop produces 10, 20, 30

    When evaluating that expression in a scripting language or such we have
    alice and bob which are tag names and we have i which is a bound
    variable being used as an index. That leads to confusion.

    Now imagine that mallet knows that the index variable used is i, she
    creates the following message:


    { "alice" : { "bob" : [ 10, 20, 30] , "i" : 4= 2 } }

    Depending on the implementation the iteration may now produce 10, 20, 30 as before or 42 or even 42, 42, 42.

    This is why languages like Java and C# kept the concept of array indices when the jettisoned all the rest of the baroque C++ syntax. It is an
    important difference with real security implications.

    This is also why folk like me never want to use type unsafe scripting
    languages designed by people who didn't appreciate this type of issue.<= br>

    Well, JSON Pointer has:

    =A0 =A0If a reference token is being evaluated against a JSON document,
    =A0 =A0implementations will evaluate each token against the document's<= br> =A0 =A0contents, and terminate evaluation with an error condition if it
    =A0 =A0fails to resolve a concrete value for any of the JSON pointer's<= br> =A0 =A0reference tokens. =A0See Section 7 for details.

    I do not understand that text. It is completely opaque to m= e. Or rather, I cannot decide on one single unambiguous interpretation.

    I certainly don't see it as something that can be q= uoted to resolve ambiguity of the type I raised. Which one of the outcomes = do you think it requires? I certainly can't tell and I have a doctorate= on formal methods. So if I can't tell I think the likelihood of the st= atement meaning something to an implementer is rather small.

    =A0
    So for any given pointer and object syntax, it's clear whether it's= an array or not.

    How do you resolve the ex= ample I quote?

    I am asking questions of interpreta= tion here and your response is always 'go read the spec'. Well that= is the whole issue, the spec is not clear and it cannot be clear on this i= ssue unless it raises it and addresses it as a specific case.

    If people can't explain how a spec should be interp= reted then the spec fails.

    And yes, I have had to = redesign a protocol because I could not explain something clearly more ofte= n than I can recall.=A0
    =A0
    I personally think that XPath is awesome. But that being said, JSON Pointer= as specified in the internet draft is really only a sequence of identifier= s separated by "/". That's it. I don't think it is produc= tive to question things that are actually not in the Internet Draft-

    It is awesomely powerful if you need power. As a mechan= ism for identifying sections of a document covered by XML Signature it is a= catastrophe.

    =A0
    No, it is RESERVED as in do not use it after the query.

    We are not talking about a change to the HTTP URL spec here. So we MUST
    NOT use that character. It is out of bounds.

    BS. Nobody is proposing to change the URI syntax, which happens to say:

    =A0 =A0query =A0 =A0 =A0 =3D *( pchar / "/" / "?" )
    =

    It goes on to say:

    The characters slash ("/") and question mark= ("?") may represent data within the query component. Beware that= some older, erroneous implementations may not handle such data correctly w= hen it is used as the base URI for relative references (Section=A05.1), apparently because they fail to distinguish query data from pat= h data when looking for hierarchical separators. However, as query componen= ts are often used to carry identifying information in the form of "key= =3Dvalue" pairs and one frequently used value is a reference to anothe= r URI, it is sometimes better for usability to avoid percent-encoding those= characters.

    This would not be something I would see as critic= al if there was not another choice here.

    Probably = the safest approach is to permit either separator to be used in the path ex= pression and make them interchangeable which is what we did with " and= '.=A0

    That still leaves the question of what to do with []. It looks li= ke they should be safe but it is something I would want to see tested.

    --
    Website: http://hallambaker.com/

    --e89a8f646e2bfc65e504ca235c02-- From julian.reschke@gmx.de Thu Sep 20 08:13:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E5121F87F7 for ; Thu, 20 Sep 2012 08:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.052 X-Spam-Level: X-Spam-Status: No, score=-103.052 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJdeAYH15eve for ; Thu, 20 Sep 2012 08:13:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B4CB421F87ED for ; Thu, 20 Sep 2012 08:13:44 -0700 (PDT) Received: (qmail invoked by alias); 20 Sep 2012 15:13:43 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp028) with SMTP; 20 Sep 2012 17:13:43 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX188qNVG8ps8rLl8UCcD0/i+7P0B3jw09JwMZeMuJD z9BLFOCtFjAp4N Message-ID: <505B3291.4060907@gmx.de> Date: Thu, 20 Sep 2012 17:13:21 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> <1348077337.2880.3.camel@polyglot> <505AF1AA.6080601@status.net> <505B194D.9080002@gmx.de> <505B2513.8000900@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 15:13:46 -0000 On 2012-09-20 16:58, Phillip Hallam-Baker wrote: > > > On Thu, Sep 20, 2012 at 10:15 AM, Julian Reschke > wrote: > > On 2012-09-20 16:07, Phillip Hallam-Baker wrote: > > > > On Thu, Sep 20, 2012 at 9:25 AM, Julian Reschke > > >__> > wrote: > > On 2012-09-20 15:04, Phillip Hallam-Baker wrote: > > The notation here does look easier to understand than > the slashes. > Though they don't seem to appreciate that you need dots and > brackets for > different purposes. A member label and an array index > are two very > different things and the syntax should differentiate > between them. > > > Does it need to? > > > Yes, it does consider: > > { "alice" : { "bob" : [ 10, 20, 30] } } > > > Let us imagine we have code that is stepping through each > element of an > array using an index i. The path looks like alice.bob.i > > Iterating the loop produces 10, 20, 30 > > When evaluating that expression in a scripting language or such > we have > alice and bob which are tag names and we have i which is a bound > variable being used as an index. That leads to confusion. > > Now imagine that mallet knows that the index variable used is i, she > creates the following message: > > > { "alice" : { "bob" : [ 10, 20, 30] , "i" : 42 } } > > Depending on the implementation the iteration may now produce > 10, 20, 30 > as before or 42 or even 42, 42, 42. How so? There's is only one object named "alice.bob" here, and it is an array. There's also "alice.i", but how does that matter? > This is why languages like Java and C# kept the concept of array > indices > when the jettisoned all the rest of the baroque C++ syntax. It is an > important difference with real security implications. > > This is also why folk like me never want to use type unsafe > scripting > languages designed by people who didn't appreciate this type of > issue. > > > Well, JSON Pointer has: > > If a reference token is being evaluated against a JSON document, > implementations will evaluate each token against the document's > contents, and terminate evaluation with an error condition if it > fails to resolve a concrete value for any of the JSON pointer's > reference tokens. See Section 7 for details. > > > I do not understand that text. It is completely opaque to me. Or rather, > I cannot decide on one single unambiguous interpretation. > > I certainly don't see it as something that can be quoted to resolve > ambiguity of the type I raised. Which one of the outcomes do you think > it requires? I certainly can't tell and I have a doctorate on formal > methods. So if I can't tell I think the likelihood of the statement > meaning something to an implementer is rather small. > > So for any given pointer and object syntax, it's clear whether it's > an array or not. > > > How do you resolve the example I quote? I don't understand your example. Can you rephrase it in a way so that it becomes a question about JSON Pointer? > I am asking questions of interpretation here and your response is always > 'go read the spec'. Well that is the whole issue, the spec is not clear > and it cannot be clear on this issue unless it raises it and addresses > it as a specific case. > > If people can't explain how a spec should be interpreted then the spec > fails. > > And yes, I have had to redesign a protocol because I could not explain > something clearly more often than I can recall. > > I personally think that XPath is awesome. But that being said, JSON > Pointer as specified in the internet draft is really only a sequence > of identifiers separated by "/". That's it. I don't think it is > productive to question things that are actually not in the Internet > Draft- > > > It is awesomely powerful if you need power. As a mechanism for > identifying sections of a document covered by XML Signature it is a > catastrophe. Maybe. Is this a problem of XPath or XML Signature? > No, it is RESERVED as in do not use it after the query. > > We are not talking about a change to the HTTP URL spec here. So > we MUST > NOT use that character. It is out of bounds. > > > BS. Nobody is proposing to change the URI syntax, which happens to say: > > query = *( pchar / "/" / "?" ) > > > It goes on to say: > > The characters slash ("/") and question mark ("?") may represent data > within the query component. Beware that some older, erroneous > implementations may not handle such data correctly when it is used as > the base URI for relative references (Section 5.1 > ), apparently > because they fail to distinguish query data from path data when looking > for hierarchical separators. However, as query components are often used > to carry identifying information in the form of "key=value" pairs and > one frequently used value is a reference to another URI, it is sometimes > better for usability to avoid percent-encoding those characters. > > This would not be something I would see as critical if there was not > another choice here. I don't see it as critical. > Probably the safest approach is to permit either separator to be used in > the path expression and make them interchangeable which is what we did > with " and '. I don't believe that allowing two different notations is actually helpful. > That still leaves the question of what to do with []. It looks like they > should be safe but it is something I would want to see tested. That would be relevant if JSON Pointer actually needed them. They are in RFC 3986's gen-delims, so strict URI parsers are likely to be unhappy when seeing them in unescaped form (in the wrong place). Best regards, Julian Best regards, Julian From ned.freed@mrochek.com Thu Sep 20 08:24:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA7721F86DE for ; Thu, 20 Sep 2012 08:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3k5XBVkePHD for ; Thu, 20 Sep 2012 08:24:03 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B8D7D21F8753 for ; Thu, 20 Sep 2012 08:24:02 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKH097OWSW00818Q@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 20 Sep 2012 08:18:54 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Thu, 20 Sep 2012 08:18:52 -0700 (PDT) Message-id: <01OKH096DL180006TF@mauve.mrochek.com> Date: Thu, 20 Sep 2012 08:01:43 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 18 Sep 2012 13:22:08 -0700" <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> To: Paul Hoffman Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 15:24:05 -0000 > On Sep 18, 2012, at 11:50 AM, Phillip Hallam-Baker wrote: > > I would like to see John's list as well. My treatment would be something along the following: > > > > 1) Code injection attacks > > > > [This is what the rather opaque language in the existing text seems to be attempting to address] > > > > 2) Data overflow attacks > > > > [Parsers need to consider cases such as buffer overrun, integer overflow, etc] > > > > 3) Message size limitations > > > > [Separate from the question of buffer overrun there is the issue of sending messages that are so long that they cause resource exhaustion and a DoS attack] > Are any of these specific to JSON? They apply to any format, yes? I'm fine > with adding them, but in doing so, we aren't talking about JSON. If I understand you correctly, it's unnecessary to call out a security consideration if it's something that is common to the class of things something belongs in? If that's the case, then words really fail me. Just as one example, there is a broad class of scripting langauges which, if executed, can completely compromise and even destroy the machine they run on, and which therefore require the use of external authentication, access control and integrity checking. But because these concerns apply to such langauges as a class we don't need to bother to warn people about them? I'm sorry, but that just doesn't fly. And BTW, the answer to your question is no, there are abundant examples of completely passive formats that are not vulnerable to, say, code injection attacks. > > 4) Error handling > > > > [What should a parser do if it encounters malformed JSON, > That's not a security consideration, that's a protocol implementation issue. > I don't think we should specify it, give the wildly different environments > where JSON parsing happens. Whether or not it's a security consideration depends on what the JSON is being used for. The fact that JSON is a container format that can be used for almost any purpose broadens the security considerations considerably, and that absolutely needs to be discussed. > > 5) Resynchronization > > > > [How does a receiver that has received one malformed JSON message identify the start of the next item] > Same as 4. Same response. > > 6) Integrity > > > > [JSON does not provide for integrity checking and this needs to be considered in the framing protocol] > Sure, I guess that is a "security consideration" for any format. Wrong again. The obvious counterexample is a format that provides all the integrity checking it needs internally and thus doesn't require any sort of external integrity service. But more generally, while you can of course invent uses for pretty much any format imagineable that require integrity (or confidentiality) protection, there are formats which are designed for destributing public information and which do not involve active or executable content or pointers to other stuff. In such cases there really are no integrity concerns worth talking about. Ned From paul.hoffman@vpnc.org Thu Sep 20 08:53:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2205321F846F for ; Thu, 20 Sep 2012 08:53:00 -0700 (PDT) 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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8oNh9spU7CX for ; Thu, 20 Sep 2012 08:52:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9B68621F843F for ; Thu, 20 Sep 2012 08:52:57 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q8KFqtZ4014082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Sep 2012 08:52:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Paul Hoffman In-Reply-To: <01OKH096DL180006TF@mauve.mrochek.com> Date: Thu, 20 Sep 2012 08:52:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1498) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 15:53:00 -0000 On Sep 20, 2012, at 8:01 AM, Ned Freed wrote: >> Are any of these specific to JSON? They apply to any format, yes? I'm = fine >> with adding them, but in doing so, we aren't talking about JSON. >=20 > If I understand you correctly, it's unnecessary to call out a security=20= > consideration if it's something that is common to the class of things = something > belongs in? You do not understand me correctly. Note that I said that I was fine = with adding them. If we add them, we should point out that they are not = about JSON, but any format. > If that's the case, then words really fail me. Just as one example, = there is a > broad class of scripting langauges which, if executed, can completely=20= > compromise and even destroy the machine they run on, and which = therefore > require the use of external authentication, access control and = integrity > checking. But because these concerns apply to such langauges as a = class we > don't need to bother to warn people about them? >=20 > I'm sorry, but that just doesn't fly. And BTW, the answer to your = question is > no, there are abundant examples of completely passive formats that are = not > vulnerable to, say, code injection attacks. Can you give your best example? I'm completely missing it. If you can = put "code" in JSON, I expect you can put "code" in any format. >>> 4) Error handling >>>=20 >>> [What should a parser do if it encounters malformed JSON, >=20 >> That's not a security consideration, that's a protocol implementation = issue. >> I don't think we should specify it, give the wildly different = environments >> where JSON parsing happens. >=20 > Whether or not it's a security consideration depends on what the JSON = is being > used for. The fact that JSON is a container format that can be used = for almost > any purpose broadens the security considerations considerably, and = that > absolutely needs to be discussed. Fully agree that it should be discussed. Note that Phill said "What = should a parser do", not "discuss the topic". I support the second (as = you do), but I object to the first. >>> 5) Resynchronization >>>=20 >>> [How does a receiver that has received one malformed JSON message = identify the start of the next item] >=20 >> Same as 4. >=20 > Same response. >=20 >>> 6) Integrity >>>=20 >>> [JSON does not provide for integrity checking and this needs to be = considered in the framing protocol] >=20 >> Sure, I guess that is a "security consideration" for any format. >=20 > Wrong again. The obvious counterexample is a format that provides all = the > integrity checking it needs internally and thus doesn't require any = sort of > external integrity service. Which formats do that? > But more generally, while you can of course invent > uses for pretty much any format imagineable that require integrity (or > confidentiality) protection, there are formats which are designed for > destributing public information and which do not involve active or = executable > content or pointers to other stuff. In such cases there really are no = integrity > concerns worth talking about. Errr, right. Are you saying JSON involves active or executable content? = Or pointers to other stuff? If so, I agree that those are security = considerations. I'm not seeing it in the JSON definition, however. What = am I missing? --Paul Hoffman= From nico@cryptonector.com Thu Sep 20 09:03:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC56521F84B2 for ; Thu, 20 Sep 2012 09:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvssYj7TjROm for ; Thu, 20 Sep 2012 09:03:00 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8508521F849B for ; Thu, 20 Sep 2012 09:03:00 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 07B9E36006F for ; Thu, 20 Sep 2012 09:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=mOt4usf5Mi+oPngrdIQw yyABBKA=; b=kl1dI4y+Sxh04+6Ne6EhhUJG2c9JjWnfYTXgenSPCWwmxDZQeBnd mN/zLdLOIAgTGM/eSHa6pLowMX/apkXvutnkRYzlfQ+KO/bA0KefaINL+HiUHWrq a5qpQloj/NYzBFIKe3jhw8UDOiD4xI+1PrjBpj3BRRRm4lRqbk9FcNc= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id E28ED36006B for ; Thu, 20 Sep 2012 09:02:59 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so3105199pbb.31 for ; Thu, 20 Sep 2012 09:02:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.220.104 with SMTP id pv8mr7897532pbc.119.1348156978998; Thu, 20 Sep 2012 09:02:58 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 20 Sep 2012 09:02:58 -0700 (PDT) In-Reply-To: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> Date: Thu, 20 Sep 2012 11:02:58 -0500 Message-ID: From: Nico Williams To: "Tschofenig, Hannes (NSN - FI/Espoo)" Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 16:03:01 -0000 Hannes, I find the use of ASN.1, XDR, XML Schema, ... to be useful in providing a desirable degree of formalism for encoding of complex structured data. As you say, these schema languages do not describe semantics (either at all or to any useful degree), but we often handle this by either a) embedding comments in the ASN.1/whatever, b) text in the I-D/RFC outside the ASN.1/..., c) both (a) and (b). I don't think there's any problem with this approach, frankly. And I prefer a higher degree of formalism to a lesser degree of formalism because the former promotes the use of automated tools (such as code generators and validators). So, while I have no problem with specific complaints about shortcomings of one or another schema language, I do object to the idea that because they fail to denote semantics we should not use them. Regarding specific complaints... I am not very familiar with XML Schema, so I can't say much about it and extensibility. ASN.1 has extensibility rules nowadays, and often uses of ASN.1 predating extensibility rules are nonetheless extensibile (sometimes we need to resort to negotiation of extensions, but that's OK). I suspect that the situation w.r.t. XML Schema extensibility is not as dire as you paint it. Nico -- From jasnell@gmail.com Thu Sep 20 09:25:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4235B21F87FF for ; Thu, 20 Sep 2012 09:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=-1.324, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esW2rZ+uaAH4 for ; Thu, 20 Sep 2012 09:25:06 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B239321F87FA for ; Thu, 20 Sep 2012 09:25:05 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so390163wgb.13 for ; Thu, 20 Sep 2012 09:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MXJ9eZ0KZhJbDIRI9Fz8NMnSNDF/A23JkfYcWMRnyvs=; b=ug2CgMcVHZCEPL10JvFgMBbS/49kFnaQJ8RzCR0OH98XawREKnjMMpm2gi5EpB+Nk3 kbXntIqTYiSt9TtQ4R3pLUkZBdLykz2+9nZoHdSRqEyrgdqVDj/rcTD+N906FjHlJeZB SpymYIIV/aqhqO4c/CB0ZPcAlog8rEmxZVCmfPcfL9IT4NC7T6KjZNYBCChWfWvP9GIe lNoEkoWKce4s5tJjbaor/7JWSSm9CT2LxOZNy35sYqt7q0uYEuV7PVlmi5j17pYvT1Pa F225Pmidhna/pVgHzTP5S8BHRPHg7xVOzX/PbMEukZ8AsH8xdut34LFyi2cIhWjaFYqV ySig== Received: by 10.180.97.33 with SMTP id dx1mr5494134wib.18.1348158304739; Thu, 20 Sep 2012 09:25:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Thu, 20 Sep 2012 09:24:44 -0700 (PDT) In-Reply-To: <505B3291.4060907@gmx.de> References: <5059E1E8.6040704@status.net> <5059ED76.50202@status.net> <1348077337.2880.3.camel@polyglot> <505AF1AA.6080601@status.net> <505B194D.9080002@gmx.de> <505B2513.8000900@gmx.de> <505B3291.4060907@gmx.de> From: James M Snell Date: Thu, 20 Sep 2012 09:24:44 -0700 Message-ID: To: Julian Reschke Content-Type: multipart/alternative; boundary=f46d04428f0cdadfbe04ca249050 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 16:25:07 -0000 --f46d04428f0cdadfbe04ca249050 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 20, 2012 at 8:13 AM, Julian Reschke wrote: > >> Yes, it does consider: >> >> { "alice" : { "bob" : [ 10, 20, 30] } } >> >> >> Let us imagine we have code that is stepping through each >> element of an >> array using an index i. The path looks like alice.bob.i >> >> Huh? If we're iterating through this using JavaScript code it would be something like for (i in m.alice.bob) print(m.alice.bob[i] If I was going to use a JSON Pointer to iterate through, it would look like for (i in m.alice.bob) print(eval_pointer( "m.alice.bob." + i )) Iterating the loop produces 10, 20, 30 >> >> When evaluating that expression in a scripting language or such >> we have >> alice and bob which are tag names and we have i which is a bound >> variable being used as an index. That leads to confusion. >> >> I'm sorry, but there is no confusion when the code example actually makes sense. No disrespect intended, but the example you give here, Phil, does not appear to make much sense. > Now imagine that mallet knows that the index variable used is i, >> she >> creates the following message: >> >> >> { "alice" : { "bob" : [ 10, 20, 30] , "i" : 42 } } >> >> Depending on the implementation the iteration may now produce >> 10, 20, 30 >> as before or 42 or even 42, 42, 42. >> > > How so? There's is only one object named "alice.bob" here, and it is an > array. There's also "alice.i", but how does that matter? > > The full set of valid JSON Pointers I see in this example are: /alice /alice/bob /alice/bob/0 /alice/bob/1 /alice/bob/2 /alice/i Which in dot notation, of course, would be: alice alice.bob alice.bob.0 alice.bob.1 alice.bob.2 alice.i I see absolutely no confusion here. > [snip] > >> I am asking questions of interpretation here and your response is always >> 'go read the spec'. Well that is the whole issue, the spec is not clear >> and it cannot be clear on this issue unless it raises it and addresses >> it as a specific case. >> >> If people can't explain how a spec should be interpreted then the spec >> fails. >> >> Yes.. and again, no disrespect intended here Phil, but I think the issue at hand right now is that, so far, none of the examples and feedback you have provided, thus far, have made any sense at all. > [snip] > > No, it is RESERVED as in do not use it after the query. >> >> We are not talking about a change to the HTTP URL spec here. So >> we MUST >> NOT use that character. It is out of bounds. >> >> >> BS. Nobody is proposing to change the URI syntax, which happens to >> say: >> >> query = *( pchar / "/" / "?" ) >> >> >> It goes on to say: >> >> The characters slash ("/") and question mark ("?") may represent data >> within the query component. Beware that some older, erroneous >> implementations may not handle such data correctly when it is used as >> the base URI for relative references (Section 5.1 >> >> >)**, apparently >> >> because they fail to distinguish query data from path data when looking >> for hierarchical separators. However, as query components are often used >> to carry identifying information in the form of "key=value" pairs and >> one frequently used value is a reference to another URI, it is sometimes >> better for usability to avoid percent-encoding those characters. >> >> This would not be something I would see as critical if there was not >> another choice here. >> > > I don't see it as critical. > > > Probably the safest approach is to permit either separator to be used in >> the path expression and make them interchangeable which is what we did >> with " and '. >> > > I don't believe that allowing two different notations is actually helpful. > > +1 .. Pick One. > > That still leaves the question of what to do with []. It looks like they >> should be safe but it is something I would want to see tested. >> > > That would be relevant if JSON Pointer actually needed them. They are in > RFC 3986's gen-delims, so strict URI parsers are likely to be unhappy when > seeing them in unescaped form (in the wrong place). > > I have run into a number of very real issues in various places with the use of errant square brackets in query string parameters and fragment identifiers. 3986 is actually quite clear on the fact that square brackets are ONLY allowed when delimiting IPv6 addresses. Specifically, section 3.2.2: A host identified by an Internet Protocol literal address, version 6 [RFC3513] or later, is distinguished by enclosing the IP literal within square brackets ("[" and "]"). This is the only place where square bracket characters are allowed in the URI syntax. I'll say again that I personally prefer the JavaScript notation, even with square brackets and I don't generally see a problem with escaping those within the URI. But the square brackets are not strictly required to make things work. The existing / delimited syntax does work in practice and it's simple to implement. - James > Best regards, Julian > > > Best regards, Julian > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --f46d04428f0cdadfbe04ca249050 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    On Thu, Sep 20, 2012 at 8:13 AM, Julian Reschke <<= a href=3D"mailto:julian.reschke@gmx.de" target=3D"_blank">julian.reschke@gm= x.de> wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes, it does consider:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "alice" : { "bob" : [ 10,= 20, 30] } }


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Let us imagine we have code that is stepping th= rough each
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 element of an
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 array using an index i. The path looks like =C2= =A0alice.bob.i


    Huh? If we're i= terating through this using JavaScript code it would be something like

    =C2=A0 for (i in m.alice.bob)=C2=A0
    =C2=A0 = =C2=A0 print(m.alice.bob[i]
    =C2=A0
    If I was going to use a JSON Pointer to iterate throu= gh, it would look like

    =C2=A0 for (i in m.alice.bo= b)
    =C2=A0 =C2=A0 print(eval_pointer( "m.alice.bob." + i= ))


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Iterating the loop produces 10, 20, 30

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 When evaluating that expression in a scripting = language or such
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 we have
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 alice and bob which are tag names and we have i= which is a bound
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 variable being used as an index. That leads to = confusion.


    I'm sorry, but = there is no confusion when the code example actually makes sense. No disres= pect intended, but the example you give here, Phil, does not appear to make= much sense.
    =C2=A0
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Now imagine that mallet knows that the index va= riable used is i, she
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 creates the following message:


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "alice" : { "bob" : [ 10,= 20, 30] , "i" : 42 } }

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Depending on the implementation the iteration m= ay now produce
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 10, 20, 30
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 as before or 42 or even 42, 42, 42.

    How so? There's is only one object named "alice.bob" here, an= d it is an array. There's also "alice.i", but how does that m= atter?


    The full= set of valid JSON Pointers I see in this example are:

    =C2=A0 /alice
    =C2=A0 /alice/bob
    =C2= =A0 /alice/bob/0
    =C2=A0 /alice/bob/1
    =C2=A0 /alice/bob/= 2
    =C2=A0 /alice/i

    Which in dot notation,= of course, would be:

    =C2=A0 alice
    =C2=A0 alice.bob
    =C2= =A0 alice.bob.0
    =C2=A0 alice.bob.1
    =C2=A0 alice.bob.2
    =C2=A0 alice.i

    I see absolutely no confus= ion here.
    =C2=A0
    [snip]
    I am asking questions of interpretation here and your response is always 'go read the spec'. Well that is the whole issue, the spec is not c= lear
    and it cannot be clear on this issue unless it raises it and addresses
    it as a specific case.

    If people can't explain how a spec should be interpreted then the spec<= br> fails.


    Yes.. and again, no= disrespect intended here Phil, but I think the issue at hand right now is = that, so far, none of the examples and feedback you have provided, thus far= , have made any sense at all.=C2=A0
    =C2=A0
    [snip]
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 No, it is RESERVED as in do not use it after th= e query.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 We are not talking about a change to the HTTP U= RL spec here. So
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 we MUST
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 NOT use that character. It is out of bounds.

    =C2=A0 =C2=A0 BS. Nobody is proposing to change the URI syntax, which happe= ns to say:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 query =C2=A0 =C2=A0 =C2=A0 =3D *( pchar / "= ;/" / "?" )


    It goes on to say:

    The characters slash ("/") and question mark ("?") may = represent data
    within the query component. Beware that some older, erroneous
    implementations may not handle such data correctly when it is used as
    the base URI for relative references (Section 5.1
    <http://greenbytes.de/tech/webdav/rfc3986.html#base-uri= >), apparently

    because they fail to distinguish query data from path data when looking
    for hierarchical separators. However, as query components are often used to carry identifying information in the form of "key=3Dvalue" pai= rs and
    one frequently used value is a reference to another URI, it is sometimes better for usability to avoid percent-encoding those characters.

    This would not be something I would see as critical if there was not
    another choice here.

    I don't see it as critical.


    Probably the safest approach is to permit either separator to be used in the path expression and make them interchangeable which is what we did
    with " and '.

    I don't believe that allowing two different notations is actually helpf= ul.


    +1 .. Pick = One.=C2=A0

    That still leaves the question of what to do with []. It looks like they should be safe but it is something I would want to see tested.

    That would be relevant if JSON Pointer actually needed them. They are in RF= C 3986's gen-delims, so strict URI parsers are likely to be unhappy whe= n seeing them in unescaped form (in the wrong place).


    I have run into a number of very real = issues in various places with the use of errant square brackets in query st= ring parameters and fragment identifiers. 3986 is actually quite clear on t= he fact that square brackets are ONLY allowed when delimiting IPv6 addresse= s.=C2=A0

    Specifically, section 3.2.2:

    <= div>=C2=A0 =C2=A0A host identified by an Internet Protocol literal address,= version 6
    =C2=A0 =C2=A0[RFC3513] or later, is distinguished by e= nclosing the IP literal
    =C2=A0 =C2=A0within square brackets ("[" and "]").= =C2=A0This is the only place where
    =C2=A0 =C2=A0square bracket c= haracters are allowed in the URI syntax.

    I&#= 39;ll say again that I personally prefer the JavaScript notation, even with= square brackets and I don't generally see a problem with escaping thos= e within the URI. But the square brackets are not strictly required to make= things work. The existing / delimited syntax does work in practice and it&= #39;s simple to implement.=C2=A0

    - James
    =C2=A0
    Best regards, Julian


    Best regards, Julian

    _______________________________________________
    apps-discuss mailing list
    apps-discuss@iet= f.org
    https://www.ietf.org/mailman/listinfo/apps-discuss

    --f46d04428f0cdadfbe04ca249050-- From dret@berkeley.edu Thu Sep 20 09:26:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C7921F8809 for ; Thu, 20 Sep 2012 09:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xupF12nSI6vD for ; Thu, 20 Sep 2012 09:26:33 -0700 (PDT) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6D52A21F8804 for ; Thu, 20 Sep 2012 09:26:33 -0700 (PDT) Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.67]) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TEjaA-0005i9-8p; Thu, 20 Sep 2012 09:26:32 -0700 Message-ID: <505B43B3.7050503@berkeley.edu> Date: Thu, 20 Sep 2012 09:26:27 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 16:26:36 -0000 hello all. On 2012-09-20 09:02 , Nico Williams wrote: > So, while I have no problem with specific complaints about > shortcomings of one or another schema language, I do object to the > idea that because they fail to denote semantics we should not use > them. that's my general feeling as well. schemas are not able to and not designed to completely capture protocol semantics, but they provide a good starting point, and allow some level of formalism which then needs to be augmented with documentation. > Regarding specific complaints... I am not very familiar with XML > Schema, so I can't say much about it and extensibility. ASN.1 has > extensibility rules nowadays, and often uses of ASN.1 predating > extensibility rules are nonetheless extensibile (sometimes we need to > resort to negotiation of extensions, but that's OK). I suspect that > the situation w.r.t. XML Schema extensibility is not as dire as you > paint it. imho, the real challenge is to *design* a good extension model for a language; coding it in a schema language then is just an exercise in figuring out what can be done in that specific language. in XSD, all you can do is to use wildcards (possibly refined by namespace specifications for them), and then you have to add documentation saying how processors are supposed to handle wildcards (ignore, interpret, stop, ...). extension rules cannot be fully captured (such as saying that extensions are not allowed to change the semantics of any fields in the base format), but at least the schema describes the base syntax, and also validates instances containing extensions. i have to admit that i am really curious why the seasoned spec writers that have voiced general concerns about the usefulness of schema languages are feeling this way, but so far i have not really understood what they are saying. could somebody please try again, i'd really like to understand why the general idea of describing protocol syntax in a semi-formal (as opposed to non-formal) way is considered a bad idea. thanks a lot and kind regards, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nico@cryptonector.com Thu Sep 20 09:29:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB9121F876A for ; Thu, 20 Sep 2012 09:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mfMDSwteAG0 for ; Thu, 20 Sep 2012 09:29:47 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 209F821F871A for ; Thu, 20 Sep 2012 09:29:47 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id CFBA736006F for ; Thu, 20 Sep 2012 09:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=5PX3LoUaHnBM+qxHedlr 9P51BDU=; b=G5l3a9U8GSihR/hhgXia50DjURmoc1xfyq/EL+xUS46Cx7sKNUfK Xaccmpeu1QC2h/MLH+RaTrxEHE7NCJZusQDkEFSmFrJmsuV5Do8EzH+NIKeKOaCO LBepbIHkRyUuEUoqMF/A47HTYSeYadm5MWHCMts3uaY6x5jrrGFa5+8= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 9117336006D for ; Thu, 20 Sep 2012 09:29:42 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so3156257pbb.31 for ; Thu, 20 Sep 2012 09:29:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.82.101 with SMTP id h5mr6738831pay.15.1348158582249; Thu, 20 Sep 2012 09:29:42 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 20 Sep 2012 09:29:42 -0700 (PDT) In-Reply-To: References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> Date: Thu, 20 Sep 2012 11:29:42 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 16:29:48 -0000 On Thu, Sep 20, 2012 at 8:52 AM, Phillip Hallam-Baker wrote: > I found using a schema helpful in writing the SAML spec but I didn't use XML > schema. I used a tool and generated the XML Schema and the text from my own > schema language. That addressed the problem of the spec and schema being out > of sync which was a real bear as the SAML TC made major changes to the > schema, adding and dropping items at each con-call OK, we're getting to the meat of the complaint. It's not about how or who but about failures of the end product (XML Schema, JSON Schema). > What I think we need for the IETF is a tool to help document protocols. Now > that might be a schema done right or it might be a protocol description > tool. I agree. I don't know that this is a realistic expectation (but see below), and in particular I'm skeptical that enough code can be generated from such a tool (as compared to merely data encoding/decoding) that it would be anywhere near as useful as data description languages have been. But I'd like to be proven wrong! (Or even to prove myself wrong.) The ITU-T would say that SDL should be it, no doubt :), but SDL is weirdly incompatible with ASN.1 (SDL is case-insensitive(!) while ASN.1 is case-sensitive), and anyways, I don't think I care for SDL. That said, and as has been demonstrated before, there's a large degree of duality between the various data description languages that we have. Thus we have XER (XML Encoding Rules for ASN.1), and FastInfoSet (PER encoding applied to XML) and so on. And I think the proposition that XDR is a subset of ASN.1/PER with 4-octet alignment and non-packed encoding of optional/defaulted fields, is defensible. Therefore I think at least a unified data description language is possible. What is difficult to manage is protocol flows, particularly when there is cryptography involved. We might be able to use any of various high-level programming languages (e.g., Haskell, Python, Scheme, ...) in combination with a) a generic data description language and b) some functions left undefined (defined in English language prose rather than a formal language). (I would prefer to use a LISP or Scheme with a powerful macro language so as to make it easier to generate code from the specification by just defining a suitable set of macros.) Maybe we could experiment with this? > Extensibility is certainly problematic. I have seen pretty much every WG > using XML end up in rat hole after rat hole as people try to consider what v > 1.1 of the spec might look like. XML Schema looks like it should answer that > question but it does not. And not many other tools do so either. > > This problem crops up in a JSON protocol as well. Should unknown tags be > ignored or cause an error? Should there be a mechanism that allows > intentional breaking of backwards compatibility in cases where doing so may > cause applications to do the wrong thing? This shows up in ASN.1 as well. ASN.1 lets you say that extensions "go here" and are to be ignored by decoders that don't expect them, but, so what, it's not enough. We always end up having to signal or negotiate the use of extensions, and I don't find that to be particularly problematic. Perhaps XML Schema is particularly disastrous w.r.t. extensibility? But I doubt it. Instead I suspect that some wish that extensibility were simpler and more automatic, but I'm afraid that it simply cannot be. > Even the terminology can be disastrous. There is a feature in X,509v3 that > is designed to allow a certificate to say 'if you don't understand and > process this extension then reject this certificate'. The original intention > was to allow extensions to specify new revocation/status checking schemes. > RPs that did not understand the scheme could not use the certificate. > > Unfortunately that feature was called 'critical' which also means > 'important'. And so people started using 'critical' to mean 'I think this is > important' and not 'I think this so important that you should break > backwards compatibility'. This is why I called the same feature 'Conditions' > in the SAML specification and disguised it so that it didn't look like a > criticality flag. But Conditions and Criticality are the exact same thing. > The SAML assertion structure began life as part of a design to re-do X.509 > in XML which is why it had to have some equivalent of criticality. Criticality is a big deal. We don't want to render extant implementations vulnerable when we extend a protocol, but we don't want to break interop with them either, and sometimes you just cannot have both of those. It mostly behooves us to get things like PKI right from day zero, and yet that also is wishful thinking. I wish I had an actual, better answer here; I don't. > What we need in my view is a way to identify the places where additional > items can be added into protocol messages and a default that additional > items are prohibited everywhere else. So in my Simple JSON Schema I would > represent a SAML assertion like thing something like: OK, like ASN.1 extensibility markers then. (Really, we only keep re-inventing the wheel :) Maybe we need JER -- JSON Encoding Rules for ASN.1 :) > The Any type is an intrinsic type that refers to an object that is tagged > with the object type. So an authentication assertion would be tagged with a > "authentication" an authorization assertion with "authorization" and so on. So, like typed holes in ASN.1 (including the Information Object Set, a very difficult to use syntax extension to ASN.1 that adds very useful formalism). Nico -- From hallam@gmail.com Thu Sep 20 09:33:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A017921F870B for ; Thu, 20 Sep 2012 09:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.215 X-Spam-Level: X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d51ZnhFiQoR3 for ; Thu, 20 Sep 2012 09:33:16 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC27621F86DE for ; Thu, 20 Sep 2012 09:33:16 -0700 (PDT) Received: by oagn5 with SMTP id n5so2018496oag.31 for ; Thu, 20 Sep 2012 09:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KM4mT0VxMv2BZcy2AoePzFcCWAwU2KPaz953F7/gaXg=; b=QQBJwb5Znoqc7TveRNem0lzf8zU72/ykgbbctRalI9EQOU4gGAtWwRp7qdnIXQGPqb Wf6KHq2BvpeABhcRQQb0/lNj/SPmJKu2es0uZ/g2dn+OyMV0/6g+nUV8An58I0/z8evh /ExiH/R8fzBCVzriX6R9Iikyb+MRCCCEAvcYK6nLxe2T58f7Rx2mKwBz9Bg4WgmIgwV2 I12DMOyw/gbY/expl1I/qm9rCMlJ6kCcBRFSqSkoWD5x6p3n1PScjkfL0Z5BtZC5juCc MJzZh6uGXFDfJ+ucEv7e31fcyRMdoEO/+0l7WpLJixRYyElfIcmuIFznAyy+jjc0ju/T qaBA== MIME-Version: 1.0 Received: by 10.60.29.72 with SMTP id i8mr1718958oeh.26.1348158796313; Thu, 20 Sep 2012 09:33:16 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 09:33:16 -0700 (PDT) In-Reply-To: <505B43B3.7050503@berkeley.edu> References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> Date: Thu, 20 Sep 2012 12:33:16 -0400 Message-ID: From: Phillip Hallam-Baker To: Erik Wilde Content-Type: multipart/alternative; boundary=e89a8fb1f80627b3ea04ca24aeed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 16:33:17 -0000 --e89a8fb1f80627b3ea04ca24aeed Content-Type: text/plain; charset=ISO-8859-1 Actually you can do a lot more than Wildcards in XML Schema. And no, it is not a good idea to try. That is why SAML 2.0 became necessary as people had told me to use model groups in SAML 1.0. On Thu, Sep 20, 2012 at 12:26 PM, Erik Wilde wrote: > hello all. > > > On 2012-09-20 09:02 , Nico Williams wrote: > >> So, while I have no problem with specific complaints about >> shortcomings of one or another schema language, I do object to the >> idea that because they fail to denote semantics we should not use >> them. >> > > that's my general feeling as well. schemas are not able to and not > designed to completely capture protocol semantics, but they provide a good > starting point, and allow some level of formalism which then needs to be > augmented with documentation. > > > Regarding specific complaints... I am not very familiar with XML >> Schema, so I can't say much about it and extensibility. ASN.1 has >> extensibility rules nowadays, and often uses of ASN.1 predating >> extensibility rules are nonetheless extensibile (sometimes we need to >> resort to negotiation of extensions, but that's OK). I suspect that >> the situation w.r.t. XML Schema extensibility is not as dire as you >> paint it. >> > > imho, the real challenge is to *design* a good extension model for a > language; coding it in a schema language then is just an exercise in > figuring out what can be done in that specific language. in XSD, all you > can do is to use wildcards (possibly refined by namespace specifications > for them), and then you have to add documentation saying how processors are > supposed to handle wildcards (ignore, interpret, stop, ...). extension > rules cannot be fully captured (such as saying that extensions are not > allowed to change the semantics of any fields in the base format), but at > least the schema describes the base syntax, and also validates instances > containing extensions. > > i have to admit that i am really curious why the seasoned spec writers > that have voiced general concerns about the usefulness of schema languages > are feeling this way, but so far i have not really understood what they are > saying. could somebody please try again, i'd really like to understand why > the general idea of describing protocol syntax in a semi-formal (as opposed > to non-formal) way is considered a bad idea. > > thanks a lot and kind regards, > > dret. > > -- > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > -- Website: http://hallambaker.com/ --e89a8fb1f80627b3ea04ca24aeed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Actually you can do a lot more than Wildcards in XML Schema.

    =
    And no, it is not a good idea to try. That is why SAML 2.0 became nece= ssary as people had told me to use model groups in SAML 1.0.

    On Thu, Sep 20, 2012 at 12:26 PM, Erik Wilde <dret@berkeley.edu> wrote:
    hello all.


    On 2012-09-20 09:02 , Nico Williams wrote:
    So, while I have no problem with specific complaints about
    shortcomings of one or another schema language, I do object to the
    idea that because they fail to denote semantics we should not use
    them.

    that's my general feeling as well. schemas are not able to and not desi= gned to completely capture protocol semantics, but they provide a good star= ting point, and allow some level of formalism which then needs to be augmen= ted with documentation.


    Regarding specific complaints... =A0I am not very familiar with XML
    Schema, so I can't say much about it and extensibility. =A0ASN.1 has extensibility rules nowadays, and often uses of ASN.1 predating
    extensibility rules are nonetheless extensibile (sometimes we need to
    resort to negotiation of extensions, but that's OK). =A0I suspect that<= br> the situation w.r.t. XML Schema extensibility is not as dire as you
    paint it.

    imho, the real challenge is to *design* a good extension model for a langua= ge; coding it in a schema language then is just an exercise in figuring out= what can be done in that specific language. in XSD, all you can do is to u= se wildcards (possibly refined by namespace specifications for them), and t= hen you have to add documentation saying how processors are supposed to han= dle wildcards (ignore, interpret, stop, ...). extension rules cannot be ful= ly captured (such as saying that extensions are not allowed to change the s= emantics of any fields in the base format), but at least the schema describ= es the base syntax, and also validates instances containing extensions.

    i have to admit that i am really curious why the seasoned spec writers that= have voiced general concerns about the usefulness of schema languages are = feeling this way, but so far i have not really understood what they are say= ing. could somebody please try again, i'd really like to understand why= the general idea of describing protocol syntax in a semi-formal (as oppose= d to non-formal) way is considered a bad idea.

    thanks a lot and kind regards,

    dret.

    --
    erik wilde | mailto:= dret@berkeley.edu =A0- =A0tel:+1-510-2061079 |
    =A0 =A0 =A0 =A0 =A0 =A0| UC Berkeley =A0- =A0School of Information (ISchool= ) |
    =A0 =A0 =A0 =A0 =A0 =A0| http://dret.net/netdret http://twitter.com/dret |

    _______________________________________________
    apps-discuss mailing list
    apps-discuss@iet= f.org
    https://www.ietf.org/mailman/listinfo/apps-discuss



    --
    = Website: http://hallambaker.com/
    --e89a8fb1f80627b3ea04ca24aeed-- From dret@berkeley.edu Thu Sep 20 09:44:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAC021F847C for ; Thu, 20 Sep 2012 09:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTBcfASDOOLS for ; Thu, 20 Sep 2012 09:44:05 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 66D9B21F87D8 for ; Thu, 20 Sep 2012 09:44:05 -0700 (PDT) Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.67]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TEjr0-0002Vn-FI; Thu, 20 Sep 2012 09:43:56 -0700 Message-ID: <505B47C8.7000600@berkeley.edu> Date: Thu, 20 Sep 2012 09:43:52 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 16:44:06 -0000 hello phillip. On 2012-09-20 09:33 , Phillip Hallam-Baker wrote: > Actually you can do a lot more than Wildcards in XML Schema. > And no, it is not a good idea to try. That is why SAML 2.0 became > necessary as people had told me to use model groups in SAML 1.0. thanks for this clarification, i think now i understand better where you're coming from. instead of just specifying extension points and semantics, you also tried to specify models that people could or maybe even would have to use when actually designing extensions. i absolutely agree that this is not something one should even try to do in a loosely coupled setting such as protocols and possible extensions. also, this part of XSD is just riddled with weird design choices and random limitations of what's possible and what not. but i think the real problem there is that you're trying to define a metamodel for extensions (and therefore condemning all of them to use XSD as well), instead of just trying to clearly and fully specify the basic protocol format. assuming you stayed away from defining the extension model itself in XSD by providing model groups that people that would have to use for defining actual extensions, would you still say that using a schema language for specifying the general syntax (including extension points using simple wildcards) is a bad approach? and if so, why? thanks a lot and kind regards, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From tbray@textuality.com Thu Sep 20 09:53:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB2021F853B for ; Thu, 20 Sep 2012 09:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.727 X-Spam-Level: X-Spam-Status: No, score=-4.727 tagged_above=-999 required=5 tests=[AWL=-1.751, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g3pIllQRA5s for ; Thu, 20 Sep 2012 09:53:16 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 794CE21F850C for ; Thu, 20 Sep 2012 09:53:16 -0700 (PDT) Received: by weyx48 with SMTP id x48so1519908wey.31 for ; Thu, 20 Sep 2012 09:53:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=iYsexOz4qajkPReeMVyi8/oKHc5LC+L5Rr5wv4KW68E=; b=SFOYdbnq7eSaqJomsVuTaGF5gqpnm7E/kPtH+IlvFvcLWFaPylBry4HxwrdZfXhCI3 D3XpCZVl6Yokik6CBrbFWIHLVSHB1QWV+GtB9gpY6QFWHi5+yvcAV9Ful3GXYkh9eK2h qvHDTup34OHvuQWVFydEVM4bU01cZ3Rh/UVcuk258VXbB3GawYi7LIuvxLwyavpF3MoW 85ToVDHDE8vND0iG5d0D5hwRYbanZGJGsg/WY2HKBgQKAmzpQuHI+LXrEjMkNE/FH6vN bP/ybUH/WzW6snMYzKRagwvhbaEUM6cedTE2VspkrQYCGZzBQ3K08mQM3TKPJL5sMJ8C VVDA== MIME-Version: 1.0 Received: by 10.180.84.164 with SMTP id a4mr5654444wiz.12.1348159995521; Thu, 20 Sep 2012 09:53:15 -0700 (PDT) Received: by 10.195.13.200 with HTTP; Thu, 20 Sep 2012 09:53:15 -0700 (PDT) X-Originating-IP: [24.84.208.217] In-Reply-To: <505B43B3.7050503@berkeley.edu> References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> Date: Thu, 20 Sep 2012 09:53:15 -0700 Message-ID: From: Tim Bray To: Erik Wilde Content-Type: multipart/alternative; boundary=f46d043c06e6a2295a04ca24f57b X-Gm-Message-State: ALoCoQn1pXMVJP2sU869otdQtBb+X3jlytLau5CcEUQmAzc5O7mOxyeunwESz1eabsw0h95vzzj5 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 16:53:17 -0000 --f46d043c06e6a2295a04ca24f57b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Sep 20, 2012 at 9:26 AM, Erik Wilde wrote: > i have to admit that i am really curious why the seasoned spec writers that > have voiced general concerns about the usefulness of schema languages are > feeling this way, but so far i have not really understood what they are > saying. could somebody please try again, i'd really like to understand wh= y > the general idea of describing protocol syntax in a semi-formal (as opposed > to non-formal) way is considered a bad idea. I gave a preso at IETF70 in Vancouver a few years ago which is advertised as being XML-centric, but has (I think) useful things to say about plain-text/binary/ASN.1/JSON/XML, and discusses about the proper place of schemas: http://www.ietf.org/proceedings/70/slides/xmltut-0.pdf I believe: - ASN.1 has been bypassed by history and has truly horrible tooling. Just don=92t go there. - If you=92re interchanging documents, use XML; if (much more common) you= =92re interchanging data structures, use JSON. - Do not use multiple syntaxes for the same protocol. Pick one of XML or JSON and stick with it. - The most important thing in defining a protocol is good clean comprehensible human-readable prose. - All the protocols I=92ve ever seen have important constraints that can=92= t be expressed usefully in declarative schema languages. - Therefore, the next most important thing is an automated validator/test-suite. - A schema is a nice-to-have. - If you=92re in XML and want schema-ware, use RelaxNG. For an example, see RFC4287. - If your protocol is JSON, investment in a validator/test-suite has much higher ROI than chasing schema unicorns. > > thanks a lot and kind regards, > > dret. > > -- > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --f46d043c06e6a2295a04ca24f57b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Sep 20, 2012 at 9:26 AM, Erik Wilde <dret@berkeley.edu> wrote:

    > i have to admit that= i am really curious why the seasoned spec writers that
    > have voiced= general concerns about the usefulness of schema languages are
    > feeling this way, but so far i have not really understood what they ar= e
    > saying. could somebody please try again, i'd really like to u= nderstand why
    > the general idea of describing protocol syntax in a s= emi-formal (as opposed
    > to non-formal) way is considered a bad idea.

    I gave a preso at = IETF70 in Vancouver a few years ago which is advertised as being XML-centri= c, but has (I think) useful things to say about plain-text/binary/ASN.1/JSO= N/XML, and discusses about the proper place of schemas: http://www.ietf.org/proceed= ings/70/slides/xmltut-0.pdf

    I believe:
    - ASN.1 has been bypassed by history and has truly horrib= le tooling. Just don=92t go there.
    - If you=92re interchanging documents= , use XML; if (much more common) you=92re interchanging data structures, us= e JSON.
    - Do not use multiple syntaxes for the same protocol. Pick one of XML or JS= ON and stick with it.
    - The most important thing in defining a protocol = is good clean comprehensible human-readable prose.
    - All the protocols I= =92ve ever seen have important constraints that can=92t be expressed useful= ly in declarative schema languages.
    - Therefore, the next most important thing is an automated validator/test-s= uite.
    - A schema is a nice-to-have.
    - If you=92re in XML and want sch= ema-ware, use RelaxNG. For an example, see RFC4287.
    - If your protocol i= s JSON, investment in a validator/test-suite has much higher ROI than chasi= ng schema unicorns.



    >
    > thanks a lot and kind regards,
    >
    > dre= t.
    >
    > --
    > erik wilde | mailto:dret@berkeley.edu =A0- =A0tel:+1-510-2061079 |
    > =A0 = =A0 =A0 =A0 =A0 =A0| UC Berkeley =A0- =A0School of Information (ISchool) |<= br> > =A0 =A0 =A0 =A0 =A0 =A0| http://dr= et.net/netdret http://twitter.com/d= ret |
    > _______________________________________________
    > a= pps-discuss mailing list
    > apps-discuss@ietf.org
    = > https:/= /www.ietf.org/mailman/listinfo/apps-discuss

    --f46d043c06e6a2295a04ca24f57b-- From bobwyman@gmail.com Thu Sep 20 10:08:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5021321F8815 for ; Thu, 20 Sep 2012 10:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYGPiKZokuCq for ; Thu, 20 Sep 2012 10:08:40 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B853121F87F7 for ; Thu, 20 Sep 2012 10:08:39 -0700 (PDT) Received: by iec9 with SMTP id 9so4342361iec.31 for ; Thu, 20 Sep 2012 10:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2oBUWxul0H1uxIxbvepzay3G/v6+GaC7IOqIKnbidzw=; b=HOgT+/60vit7VFh/Nf2T7PpFfBO+OLT/PUUUSbMbOZCoTsKeY13OeU6N4qiUYs/Ime zKfCN0JSobd1QkzGZVMK3itUAkUlq/TL6W7kQU6HlSoSFlVxpU5X6osZv6B9TxiUbcE4 qko09ooV+tBA6Hmvzzwsi5+EGzkhLR2cz6WKvIouYrOFFs/Qkea3QctCmsm9RViPbueX kkMjeykN0KHnXpXYzHJmde9vBUnbjpQHYAWSJB42cy08wXyefReikbd+nKNvueKHDcav l5zOxL4AtZd1Dcn9I3UsYMsZiB6Wq5ZgwlV2sohlTkPH5Y9EevrrqyAN9UoKFfuvLGWe HQLA== MIME-Version: 1.0 Received: by 10.50.15.132 with SMTP id x4mr2249685igc.58.1348160919322; Thu, 20 Sep 2012 10:08:39 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.64.55.34 with HTTP; Thu, 20 Sep 2012 10:08:39 -0700 (PDT) In-Reply-To: References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> Date: Thu, 20 Sep 2012 13:08:39 -0400 X-Google-Sender-Auth: VgGfWUV_NT4afiwdcZJcica2H_0 Message-ID: From: Bob Wyman To: Tim Bray Content-Type: multipart/alternative; boundary=14dae934032db2400a04ca252c47 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 17:08:43 -0000 --14dae934032db2400a04ca252c47 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Sep 20, 2012 at 12:53 PM, Tim Bray wrote: > On Thu, Sep 20, 2012 at 9:26 AM, Erik Wilde wrote: > > > i have to admit that i am really curious why the seasoned spec writers > that > > have voiced general concerns about the usefulness of schema languages a= re > > feeling this way, but so far i have not really understood what they are > > saying. could somebody please try again, i'd really like to understand > why > > the general idea of describing protocol syntax in a semi-formal (as > opposed > > to non-formal) way is considered a bad idea. > > I gave a preso at IETF70 in Vancouver a few years ago which is advertised > as being XML-centric, but has (I think) useful things to say about > plain-text/binary/ASN.1/JSON/XML, and discusses about the proper place of > schemas: http://www.ietf.org/proceedings/70/slides/xmltut-0.pdf > > I believe: > - ASN.1 has been bypassed by history and has truly horrible tooling. Just > don=92t go there. > Perhaps what we need is "Abstract Syntax Notation V2.0 (i.e. ASN.2)" which would do what ASN.1 was trying to do but benefit from all that we've learned since the mid-80's... > - If you=92re interchanging documents, use XML; if (much more common) you= =92re > interchanging data structures, use JSON. > - Do not use multiple syntaxes for the same protocol. Pick one of XML or > JSON and stick with it. > - The most important thing in defining a protocol is good clean > comprehensible human-readable prose. > - All the protocols I=92ve ever seen have important constraints that can= =92t > be expressed usefully in declarative schema languages. > - Therefore, the next most important thing is an automated > validator/test-suite. > - A schema is a nice-to-have. > - If you=92re in XML and want schema-ware, use RelaxNG. For an example, s= ee > RFC4287. > - If your protocol is JSON, investment in a validator/test-suite has much > higher ROI than chasing schema unicorns. > > > > > > > > thanks a lot and kind regards, > > > > dret. > > > > -- > > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > > | UC Berkeley - School of Information (ISchool) | > > | http://dret.net/netdret http://twitter.com/dret | > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --14dae934032db2400a04ca252c47 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

    On Thu, Sep 20, 2012 at 12:53 PM, Tim Br= ay <tbray@textuality.com> wrote:
    On Thu, Sep 20, 2012 at 9:26 AM, Erik Wilde <dret@berkeley.edu> w= rote:

    > i have to admit that i am really curious why the seasoned= spec writers that
    > have voiced general concerns about the usefulness of schema languages = are
    > feeling this way, but so far i have not really understood what they ar= e
    > saying. could somebody please try again, i'd really like to u= nderstand why
    > the general idea of describing protocol syntax in a s= emi-formal (as opposed
    > to non-formal) way is considered a bad idea.

    I gave a pre= so at IETF70 in Vancouver a few years ago which is advertised as being XML-= centric, but has (I think) useful things to say about plain-text/binary/ASN= .1/JSON/XML, and discusses about the proper place of schemas: htt= p://www.ietf.org/proceedings/70/slides/xmltut-0.pdf

    I believe:
    - ASN.1 has been bypassed by history and has truly horrib= le tooling. Just don=92t go there.
    Perhaps what we nee= d is "Abstract Syntax Notation V2.0 (i.e. ASN.2)" which would do = what ASN.1 was trying to do but benefit from all that we've learned sin= ce the mid-80's...
    =A0
    - If you=92re interchanging do= cuments, use XML; if (much more common) you=92re interchanging data structu= res, use JSON.
    - Do not use multiple syntaxes for the same protocol. Pick one of XML or JS= ON and stick with it.
    - The most important thing in defining a protocol = is good clean comprehensible human-readable prose.
    - All the protocols I= =92ve ever seen have important constraints that can=92t be expressed useful= ly in declarative schema languages.
    - Therefore, the next most important thing is an automated validator/test-s= uite.
    - A schema is a nice-to-have.
    - If you=92re in XML and want sch= ema-ware, use RelaxNG. For an example, see RFC4287.
    - If your protocol i= s JSON, investment in a validator/test-suite has much higher ROI than chasi= ng schema unicorns.




    >
    > thanks a lot and kind regards,
    >
    > dre= t.
    >
    > --
    > erik wilde | mailto:dret@berkeley.edu =A0- =A0tel:+1-510-20610= 79 |
    > =A0 =A0 =A0 =A0 =A0 =A0| UC Berkeley =A0- =A0School of Information (IS= chool) |
    > =A0 =A0 =A0 =A0 =A0 =A0| http://dret.net/netdret http://twitter.com/dret |
    > _____________________= __________________________
    > apps-discuss mailing list
    > apps-discus= s@ietf.org
    > https://www.ietf.org/mailman/listinfo/apps-dis= cuss


    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss


    --14dae934032db2400a04ca252c47-- From jasnell@gmail.com Thu Sep 20 10:10:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AE421F8817 for ; Thu, 20 Sep 2012 10:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMNSo-blnTOD for ; Thu, 20 Sep 2012 10:10:11 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 36BEC21F8816 for ; Thu, 20 Sep 2012 10:10:06 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so774637wib.13 for ; Thu, 20 Sep 2012 10:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4AuxEu1fDScJVORev9c5HcDv+eXBVH3yPa0CXHhTLJk=; b=ipV38ge78pr1EZZJBhU7CWAD4ByvX6jWLrFTb1Biuj5SDtctJETYw0jxKTYRuWtQdR MCq6udlbmwdIF1voJe6uaPw8XwlVZd27X+jYFvl4hSxW45kytT7pJuTalOeZ3WQ6yELI IYc6x7n47sQvR3PuHwwHC74UEqofs2lsC4szvwehxOn5Sd6MZCwF9KRKj1VykG55Mm3b 7KnXxSwzJPvkbJWaC5if36+352TyR3DbORn6oFa7j/eyTDe3Y1D0VBFmtTioo08c3uY7 DPkGBFhX214bS/R6zOZ5vPLDWCOKCdGUKH20vHm8kCF/Und9em7F9VrFUKGmmDMEXsO9 SyjQ== Received: by 10.216.243.74 with SMTP id j52mr1373331wer.108.1348161005510; Thu, 20 Sep 2012 10:10:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Thu, 20 Sep 2012 10:09:44 -0700 (PDT) In-Reply-To: References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> From: James M Snell Date: Thu, 20 Sep 2012 10:09:44 -0700 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=e0cb4e43cf1fd5603704ca25316f Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 17:10:12 -0000 --e0cb4e43cf1fd5603704ca25316f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Sep 20, 2012 at 9:53 AM, Tim Bray wrote: > On Thu, Sep 20, 2012 at 9:26 AM, Erik Wilde wrote: > > > i have to admit that i am really curious why the seasoned spec writers > that > > have voiced general concerns about the usefulness of schema languages a= re > > feeling this way, but so far i have not really understood what they are > > saying. could somebody please try again, i'd really like to understand > why > > the general idea of describing protocol syntax in a semi-formal (as > opposed > > to non-formal) way is considered a bad idea. > > I gave a preso at IETF70 in Vancouver a few years ago which is advertised > as being XML-centric, but has (I think) useful things to say about > plain-text/binary/ASN.1/JSON/XML, and discusses about the proper place of > schemas: http://www.ietf.org/proceedings/70/slides/xmltut-0.pdf > > I believe: > - ASN.1 has been bypassed by history and has truly horrible tooling. Just > don=E2=80=99t go there. > - If you=E2=80=99re interchanging documents, use XML; if (much more commo= n) you=E2=80=99re > interchanging data structures, use JSON. > - Do not use multiple syntaxes for the same protocol. Pick one of XML or > JSON and stick with it. > - The most important thing in defining a protocol is good clean > comprehensible human-readable prose. > - All the protocols I=E2=80=99ve ever seen have important constraints tha= t can=E2=80=99t > be expressed usefully in declarative schema languages. > - Therefore, the next most important thing is an automated > validator/test-suite. > - A schema is a nice-to-have. > - If you=E2=80=99re in XML and want schema-ware, use RelaxNG. For an exam= ple, see > RFC4287. > - If your protocol is JSON, investment in a validator/test-suite has much > higher ROI than chasing schema unicorns. > > > +1 on every point. I would venture one step further in that a consistent RelaxNG-esque model for describing the data model for JSON structures **in spec documents** would be helpful as a tool for spec writers to use when describing a vocabulary. Something that would play the same fundamental role as ABNF, but that is absolutely as far as I would go with it. example, ABNF: value :=3D TOKEN Foo =3D object { bar =3D string value, baz =3D array int } - James > > > > > thanks a lot and kind regards, > > > > dret. > > > > -- > > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > > | UC Berkeley - School of Information (ISchool) | > > | http://dret.net/netdret http://twitter.com/dret | > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --e0cb4e43cf1fd5603704ca25316f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    On Thu, Sep 20, 2012 at 9:53 AM, Tim Bray <tbray@textuality.com= > wrote:
    On Thu, Sep 20, 2012 at 9:= 26 AM, Erik Wilde <dret@berkeley.edu> wrote:

    > i have to admit that i am really curious why the seasoned spec wri= ters that
    > have voiced general concerns about the usefulness of sche= ma languages are
    > feeling this way, but so far i have not really understood what they ar= e
    > saying. could somebody please try again, i'd really like to u= nderstand why
    > the general idea of describing protocol syntax in a s= emi-formal (as opposed
    > to non-formal) way is considered a bad idea.

    I gave a pre= so at IETF70 in Vancouver a few years ago which is advertised as being XML-= centric, but has (I think) useful things to say about plain-text/binary/ASN= .1/JSON/XML, and discusses about the proper place of schemas: htt= p://www.ietf.org/proceedings/70/slides/xmltut-0.pdf

    I believe:
    - ASN.1 has been bypassed by history and has truly horrib= le tooling. Just don=E2=80=99t go there.
    - If you=E2=80=99re interchangi= ng documents, use XML; if (much more common) you=E2=80=99re interchanging d= ata structures, use JSON.
    - Do not use multiple syntaxes for the same protocol. Pick one of XML or JS= ON and stick with it.
    - The most important thing in defining a protocol = is good clean comprehensible human-readable prose.
    - All the protocols I= =E2=80=99ve ever seen have important constraints that can=E2=80=99t be expr= essed usefully in declarative schema languages.
    - Therefore, the next most important thing is an automated validator/test-s= uite.
    - A schema is a nice-to-have.
    - If you=E2=80=99re in XML and wa= nt schema-ware, use RelaxNG. For an example, see RFC4287.
    - If your prot= ocol is JSON, investment in a validator/test-suite has much higher ROI than= chasing schema unicorns.



    +1 on every point.=C2=A0

    I would venture one step further in that a consiste= nt RelaxNG-esque model for describing the data model for JSON structures **= in spec documents** would be helpful as a tool for spec writers to use when= describing a vocabulary. Something that would play the same fundamental ro= le as ABNF, but that is absolutely as far as I would go with it.

    example,

    ABNF:
    =C2=A0 value :=3D TOKEN

    Foo =3D object {
    =C2=A0 bar =3D string value,
    =C2=A0 baz =3D array int
    }

    - James




    >
    > thanks a lot and kind regards,
    &g= t;
    > dret.
    >
    > --
    > erik wilde | mailto:dret@berkeley.edu =C2=A0- = =C2=A0tel:+1-510-2061079 |
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| UC Berkeley =C2=A0- =C2=A0S= chool of Information (ISchool) |
    > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://dret.net/netdret http://twitter.com/dret |
    > ___= ____________________________________________
    > apps-discuss mailing list
    > apps-discus= s@ietf.org
    > https://www.ietf.org/mailman/listinfo/apps-dis= cuss


    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss


    --e0cb4e43cf1fd5603704ca25316f-- From evan@status.net Thu Sep 20 10:35:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E359021F86A3 for ; Thu, 20 Sep 2012 10:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9bL018DvtAb for ; Thu, 20 Sep 2012 10:35:49 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 30C3621F869A for ; Thu, 20 Sep 2012 10:35:48 -0700 (PDT) Received: from [25.44.85.199] (unknown [74.198.164.199]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id A345CE8008; Thu, 20 Sep 2012 17:45:55 +0000 (UTC) User-Agent: K-9 Mail for Android In-Reply-To: References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----D3IBZBW96PWFH8188OYJYMHOPTTCE3" From: "evan@status.net" Date: Thu, 20 Sep 2012 13:34:19 -0400 To: Tim Bray ,Erik Wilde Message-ID: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 17:35:50 -0000 ------D3IBZBW96PWFH8188OYJYMHOPTTCE3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Can we engrave these rules on a big rock somewhere? Tim Bray wrote: >On Thu, Sep 20, 2012 at 9:26 AM, Erik Wilde wrote: > >> i have to admit that i am really curious why the seasoned spec >writers >that >> have voiced general concerns about the usefulness of schema languages >are >> feeling this way, but so far i have not really understood what they >are >> saying. could somebody please try again, i'd really like to >understand why >> the general idea of describing protocol syntax in a semi-formal (as >opposed >> to non-formal) way is considered a bad idea. > >I gave a preso at IETF70 in Vancouver a few years ago which is >advertised >as being XML-centric, but has (I think) useful things to say about >plain-text/binary/ASN.1/JSON/XML, and discusses about the proper place >of >schemas: http://www.ietf.org/proceedings/70/slides/xmltut-0.pdf > >I believe: >- ASN.1 has been bypassed by history and has truly horrible tooling. >Just >don’t go there. >- If you’re interchanging documents, use XML; if (much more common) >you’re >interchanging data structures, use JSON. >- Do not use multiple syntaxes for the same protocol. Pick one of XML >or >JSON and stick with it. >- The most important thing in defining a protocol is good clean >comprehensible human-readable prose. >- All the protocols I’ve ever seen have important constraints that >can’t be >expressed usefully in declarative schema languages. >- Therefore, the next most important thing is an automated >validator/test-suite. >- A schema is a nice-to-have. >- If you’re in XML and want schema-ware, use RelaxNG. For an example, >see >RFC4287. >- If your protocol is JSON, investment in a validator/test-suite has >much >higher ROI than chasing schema unicorns. > > > >> >> thanks a lot and kind regards, >> >> dret. >> >> -- >> erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | >> | UC Berkeley - School of Information (ISchool) | >> | http://dret.net/netdret http://twitter.com/dret | >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > >------------------------------------------------------------------------ > >_______________________________________________ >apps-discuss mailing list >apps-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/apps-discuss -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------D3IBZBW96PWFH8188OYJYMHOPTTCE3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Can we engrave these rules on a big rock somewhere?

    Tim Bray <tbray@textuality.com> wrote:
    On Thu, Sep 20, 2012 at 9:26 AM, Erik Wilde <dret@berkeley.edu> wrote:

    > i have to admit that i am really curious why the seasoned spec writers that
    > have voiced general concerns about the usefulness of schema languages are
    > feeling this way, but so far i have not really understood what they are
    > saying. could somebody please try again, i'd really like to understand why
    > the general idea of describing protocol syntax in a semi-formal (as opposed
    > to non-formal) way is considered a bad idea.

    I gave a preso at IETF70 in Vancouver a few years ago which is advertised as being XML-centric, but has (I think) useful things to say about plain-text/binary/ASN.1/JSON/XML, and discusses about the proper place of schemas: http://www.ietf.org/proceedings/70/slides/xmltut-0.pdf

    I believe:
    - ASN.1 has been bypassed by history and has truly horrible tooling. Just don’t go there.
    - If you’re interchanging documents, use XML; if (much more common) you’re interchanging data structures, use JSON.
    - Do not use multiple syntaxes for the same protocol. Pick one of XML or JSON and stick with it.
    - The most important thing in defining a protocol is good clean comprehensible human-readable prose.
    - All the protocols I’ve ever seen have important constraints that can’t be expressed usefully in declarative schema languages.
    - Therefore, the next most important thing is an automated validator/test-suite.
    - A schema is a nice-to-have.
    - If you’re in XML and want schema-ware, use RelaxNG. For an example, see RFC4287.
    - If your protocol is JSON, investment in a validator/test-suite has much higher ROI than chasing schema unicorns.



    >
    > thanks a lot and kind regards,
    >
    > dret.
    >
    > --
    > erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
    >            | UC Berkeley  -  School of Information (ISchool) |
    >            | http://dret.net/netdret http://twitter.com/dret |
    > _______________________________________________
    > apps-discuss mailing list
    > apps-discuss@ietf.org
    > https://www.ietf.org/mailman/listinfo/apps-discuss


    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss

    --
    Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------D3IBZBW96PWFH8188OYJYMHOPTTCE3-- From hallam@gmail.com Thu Sep 20 10:42:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04ECF21F87FC for ; Thu, 20 Sep 2012 10:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.023 X-Spam-Level: X-Spam-Status: No, score=-4.023 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7uZP76G-viv for ; Thu, 20 Sep 2012 10:42:58 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFC2A21F87F7 for ; Thu, 20 Sep 2012 10:42:57 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2695617obb.31 for ; Thu, 20 Sep 2012 10:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pnKdKUuDHVRelDN3WLjreDuKIVooHUdo1vBT+PjbnDg=; b=piE9sxi8iuA+Yk6l02f0pfTMI1gp+GD6rbtXj6spNB0jNURfv0ykY9JYvx1FFkpfic J/ZgkqnabEM1dF+qZd7ZViIFUe7KhG3bj86PJZkKKReoY8DhpYSjRg8GjifEcGWXkkcy Od/cSSxlJQPLZ3MIFgEwxDo/HsOoOis341rnzAZwJeXchWa5KjVMMnxVunbNDC/kpUwi NexB1KGAvPcZQ5tvNZy7oevB+XZJegMT/d9lrZk1umpjHrSH8YwtvNipGWb0wOdTQ/lR WG84zjSJCqsolKNiZLvKQkBQ2kgbq3S584wXpzVk4ecvqQPEc8FGl2cbzMQTngokpMVT xWow== MIME-Version: 1.0 Received: by 10.182.174.100 with SMTP id br4mr1879560obc.62.1348162977495; Thu, 20 Sep 2012 10:42:57 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 10:42:57 -0700 (PDT) In-Reply-To: <505B47C8.7000600@berkeley.edu> References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> <505B47C8.7000600@berkeley.edu> Date: Thu, 20 Sep 2012 13:42:57 -0400 Message-ID: From: Phillip Hallam-Baker To: Erik Wilde Content-Type: multipart/alternative; boundary=e89a8f647b1d5f7ba204ca25a704 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 17:42:59 -0000 --e89a8f647b1d5f7ba204ca25a704 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 20, 2012 at 12:43 PM, Erik Wilde wrote: > hello phillip. > > > On 2012-09-20 09:33 , Phillip Hallam-Baker wrote: > >> Actually you can do a lot more than Wildcards in XML Schema. >> And no, it is not a good idea to try. That is why SAML 2.0 became >> necessary as people had told me to use model groups in SAML 1.0. >> > > thanks for this clarification, i think now i understand better where > you're coming from. instead of just specifying extension points and > semantics, you also tried to specify models that people could or maybe even > would have to use when actually designing extensions. i absolutely agree > that this is not something one should even try to do in a loosely coupled > setting such as protocols and possible extensions. also, this part of XSD > is just riddled with weird design choices and random limitations of what's > possible and what not. but i think the real problem there is that you're > trying to define a metamodel for extensions (and therefore condemning all > of them to use XSD as well), instead of just trying to clearly and fully > specify the basic protocol format. > > assuming you stayed away from defining the extension model itself in XSD > by providing model groups that people that would have to use for defining > actual extensions, would you still say that using a schema language for > specifying the general syntax (including extension points using simple > wildcards) is a bad approach? and if so, why? I think a simple schema is a good thing and a complex one is a bad thing. A schema does need to be a little more complex than data structure declarations in C# or Java or any other reasonable typed language as it has to cope with things like extensions and you want the documentation to be part of the type definitions. Another big issue is that modern programming languages have pointers (they may not be exposed in C# and Java but they are there). So if you have a data structure that indexes the same list of objects in two different ways you have to consider things like pointer swizzling or object identifiers. The differences are small and manageable but they do exist. A schema does not need to be a validation tool. I have yet to find an instance where one is useful because the fact that a message has valid syntax is no guarantee of it having valid semantics. I always check the two at the same time. So 1000000000000000000000000000000000000000 is a valid JSON integer but it probably isn't going to be a valid array index. The other big slam on XML Schema nobody has mentioned yet is that prefixes are a stupid idea. Schemas should be composable without the stiches showing like Frankenstien's monster. If you write a specification that uses XML Encryption then your data structure is going to have at least three prefixes in use, the prefix for its own tags, the prefix for the XML Encryption tags and the XML Signature spec that is called by reference. But But! If I am writing a STANDARD then I am not going to choose element tags that overlap anyway. Only a moron is going to write a protocol with a protocol element that is the same as the XML Signature / Encryption elements. And in any case XML Schema actually makes it possible to vary the type of elements according to context. So given that I am going to write my protocol so that it is not going to be ambiguous, why can't I simply have a schema that says #include "XML Schema" and then incorporate all those elements and types as native to my spec. Why am I forced to introduce a new namespace? -- Website: http://hallambaker.com/ --e89a8f647b1d5f7ba204ca25a704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Thu, Sep 20, 2012 at 12:43 PM, Erik W= ilde <dret@berkeley.edu> wrote:
    hello phillip.


    On 2012-09-20 09:33 , Phillip Hallam-Baker wrote:
    Actually you can do a lot more than Wildcards in XML Schema.
    And no, it is not a good idea to try. That is why SAML 2.0 became
    necessary as people had told me to use model groups in SAML 1.0.

    thanks for this clarification, i think now i understand better where you= 9;re coming from. instead of just specifying extension points and semantics= , you also tried to specify models that people could or maybe even would ha= ve to use when actually designing extensions. i absolutely agree that this = is not something one should even try to do in a loosely coupled setting suc= h as protocols and possible extensions. also, this part of XSD is just ridd= led with weird design choices and random limitations of what's possible= and what not. but i think the real problem there is that you're trying= to define a metamodel for extensions (and therefore condemning all of them= to use XSD as well), instead of just trying to clearly and fully specify t= he basic protocol format.

    assuming you stayed away from defining the extension model itself in XSD by= providing model groups that people that would have to use for defining act= ual extensions, would you still say that using a schema language for specif= ying the general syntax (including extension points using simple wildcards)= is a bad approach? and if so, why?

    I think a simple schema is a good thing and a complex o= ne is a bad thing. A schema does need to be a little more complex than data= structure declarations in C# or Java or any other reasonable typed languag= e as it has to cope with things like extensions and you want the documentat= ion to be part of the type definitions. Another big issue is that modern pr= ogramming languages have pointers (they may not be exposed in C# and Java b= ut they are there). So if you have a data structure that indexes the same l= ist of objects in two different ways you have to consider things like point= er swizzling or object identifiers.

    The differences are small and manageable but they do ex= ist.

    A schema does not need to be a validation too= l. I have yet to find an instance where one is useful because the fact that= a message has valid syntax is no guarantee of it having valid semantics. I= always check the two at the same time. So 10000000000000000000000000000000= 00000000 is a valid JSON integer but it probably isn't going to be a va= lid array index.


    The other big slam on XML Schema nobody = has mentioned yet is that prefixes are a stupid idea. Schemas should be com= posable without the stiches showing like Frankenstien's monster.

    If you write a specification that uses XML Encryption t= hen your data structure is going to have at least three prefixes in use, th= e prefix for its own tags, the prefix for the XML Encryption tags and the X= ML Signature spec that is called by reference.

    But But! If I am writing a STANDARD then I am not going= to choose element tags that overlap anyway. Only a moron is going to write= a protocol with a protocol element that is the same as the XML Signature /= Encryption elements. And in any case XML Schema actually makes it possible= to vary the type of elements according to context.

    So given that I am going to write my protocol so that i= t is not going to be ambiguous, why can't I simply have a schema that s= ays #include "XML Schema" and then incorporate all those elements= and types as native to my spec. Why am I forced to introduce a new namespa= ce?
    =A0
    --
    Website: htt= p://hallambaker.com/

    --e89a8f647b1d5f7ba204ca25a704-- From hallam@gmail.com Thu Sep 20 10:47:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB0621F881D for ; Thu, 20 Sep 2012 10:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.015 X-Spam-Level: X-Spam-Status: No, score=-4.015 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKT+RqGMcY4q for ; Thu, 20 Sep 2012 10:47:12 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4756B21F881B for ; Thu, 20 Sep 2012 10:47:12 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2700462obb.31 for ; Thu, 20 Sep 2012 10:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ik6MehKXkf3CiZ4Jaxw3eY4HbrIlMfBkRYhgaCqoiB4=; b=PoP2XianHQhDttpOtKomDSDSP7xXO6IZoNfYPEctxkm6nK7meoqm1pRmAXtM5S+g2G 2/PRzQJ7+qJdZZg/V0Qk3sUCQ1mbgCa6OfoltSpA7OgpdgYVlPYSL4kWoypmtsZ00BE9 Aa5xGeEXo5oKY90gyLkyFFkiU2V3aenbJe3eYK1cnCHMDoRLOxX/9zCCX/XgOL8xMxrK lb6pvCJNCjPaz/FdELojLzEQqu3O2TUDVXJd4fD1Pq9tFAImuqpiGzJkmolu3Ajnxhvv 2mh7bpz6gNM/AQotxdOX65hYToSQ6JPS4vXsuUgScb5k2SyrvAeq0mv0JreZB9vl7F72 vymw== MIME-Version: 1.0 Received: by 10.182.145.35 with SMTP id sr3mr1879607obb.98.1348163231898; Thu, 20 Sep 2012 10:47:11 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 10:47:11 -0700 (PDT) In-Reply-To: References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> Date: Thu, 20 Sep 2012 13:47:11 -0400 Message-ID: From: Phillip Hallam-Baker To: Tim Bray Content-Type: multipart/alternative; boundary=f46d04463078895c6904ca25b6e5 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 17:47:13 -0000 --f46d04463078895c6904ca25b6e5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Sep 20, 2012 at 12:53 PM, Tim Bray wrote: > On Thu, Sep 20, 2012 at 9:26 AM, Erik Wilde wrote: > > > i have to admit that i am really curious why the seasoned spec writers > that > > have voiced general concerns about the usefulness of schema languages a= re > > feeling this way, but so far i have not really understood what they are > > saying. could somebody please try again, i'd really like to understand > why > > the general idea of describing protocol syntax in a semi-formal (as > opposed > > to non-formal) way is considered a bad idea. > > I gave a preso at IETF70 in Vancouver a few years ago which is advertised > as being XML-centric, but has (I think) useful things to say about > plain-text/binary/ASN.1/JSON/XML, and discusses about the proper place of > schemas: http://www.ietf.org/proceedings/70/slides/xmltut-0.pdf > > I believe: > - ASN.1 has been bypassed by history and has truly horrible tooling. Just > don=92t go there. > Agree > - If you=92re interchanging documents, use XML; if (much more common) you= =92re > interchanging data structures, use JSON. > Agree > - Do not use multiple syntaxes for the same protocol. Pick one of XML or > JSON and stick with it. > Agree but note that this conflicts with the REST notion of using URL encoded requests and JSON responses. Which I think is yucky but some insist on. > - The most important thing in defining a protocol is good clean > comprehensible human-readable prose. > Agree [hence I do not want to see a JSON or an XML syntax] > - All the protocols I=92ve ever seen have important constraints that can= =92t > be expressed usefully in declarative schema languages. > Agree and furthermore I have found a good use for the constraints they do provide. > - Therefore, the next most important thing is an automated > validator/test-suite. > Agree and want to lock that to the schema and the specification (which I have done in ProtoGen) > - A schema is a nice-to-have. > - If you=92re in XML and want schema-ware, use RelaxNG. For an example, s= ee > RFC4287. > - If your protocol is JSON, investment in a validator/test-suite has much > higher ROI than chasing schema unicorns. Unless you have a tool that will produce the test-suite and the spec (and other schemas if you really must). --=20 Website: http://hallambaker.com/ --f46d04463078895c6904ca25b6e5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

    On Thu, Sep 20, 2012 at 12:53 PM, Tim Br= ay <tbray@textuality.com> wrote:
    On Thu, Sep 20, 2012 at 9:26 AM, Erik Wilde <dret@berkeley.edu> w= rote:

    > i have to admit that i am really curious why the seasoned= spec writers that
    > have voiced general concerns about the usefulness of schema languages = are
    > feeling this way, but so far i have not really understood what they ar= e
    > saying. could somebody please try again, i'd really like to u= nderstand why
    > the general idea of describing protocol syntax in a s= emi-formal (as opposed
    > to non-formal) way is considered a bad idea.

    I gave a pre= so at IETF70 in Vancouver a few years ago which is advertised as being XML-= centric, but has (I think) useful things to say about plain-text/binary/ASN= .1/JSON/XML, and discusses about the proper place of schemas: htt= p://www.ietf.org/proceedings/70/slides/xmltut-0.pdf

    I believe:
    - ASN.1 has been bypassed by history and has truly horrib= le tooling. Just don=92t go there.

    Agre= e
    =A0
    - If you=92re interchanging documents, use XML; if (much more common) you= =92re interchanging data structures, use JSON.

    Agree
    =A0
    - Do not use multiple syntaxes for the same protocol. Pick one of XML or JS= ON and stick with it.

    Agree but note th= at this conflicts with the REST notion of using URL encoded requests and JS= ON responses. Which I think is yucky but some insist on.
    =A0
    - The most important thing in = defining a protocol is good clean comprehensible human-readable prose.
    <= /blockquote>

    Agree [hence I do not want to see a JSON or an XML synt= ax]
    =A0
    - All the protocols I= =92ve ever seen have important constraints that can=92t be expressed useful= ly in declarative schema languages.

    Agree and furthermore I have found a good = use for the constraints they do provide.=A0
    =A0
    - Therefore, the next most important thing is an automated validator/test-s= uite.

    Agree and want to lock that to th= e schema and the specification (which I have done in ProtoGen)
    =A0
    - A schema is a nice-to-have.
    - = If you=92re in XML and want schema-ware, use RelaxNG. For an example, see R= FC4287.
    - If your protocol is JSON, investment in a validator/test-suite has much h= igher ROI than chasing schema unicorns.

    Unl= ess you have a tool that will produce the test-suite and the spec (and othe= r schemas if you really must).


    --
    Website: http://hallambaker.com/

    --f46d04463078895c6904ca25b6e5-- From ned.freed@mrochek.com Thu Sep 20 10:48:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C402A21F84F9 for ; Thu, 20 Sep 2012 10:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZFR+obTLTjR for ; Thu, 20 Sep 2012 10:48:06 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id CD1D521F84B6 for ; Thu, 20 Sep 2012 10:48:05 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKH59Y3C2O009GVC@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 20 Sep 2012 10:43:03 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Thu, 20 Sep 2012 10:43:01 -0700 (PDT) Message-id: <01OKH59WL0SW0006TF@mauve.mrochek.com> Date: Thu, 20 Sep 2012 10:18:09 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 20 Sep 2012 08:52:56 -0700" <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> To: Paul Hoffman Cc: Ned Freed , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 17:48:06 -0000 > On Sep 20, 2012, at 8:01 AM, Ned Freed wrote: > >> Are any of these specific to JSON? They apply to any format, yes? I'm fine > >> with adding them, but in doing so, we aren't talking about JSON. > > > > If I understand you correctly, it's unnecessary to call out a security > > consideration if it's something that is common to the class of things something > > belongs in? > You do not understand me correctly. Note that I said that I was fine with > adding them. If we add them, we should point out that they are not about JSON, > but any format. OK, but that's still incorrect, just in a different way. See below. > > If that's the case, then words really fail me. Just as one example, there is a > > broad class of scripting langauges which, if executed, can completely > > compromise and even destroy the machine they run on, and which therefore > > require the use of external authentication, access control and integrity > > checking. But because these concerns apply to such langauges as a class we > > don't need to bother to warn people about them? > > > > I'm sorry, but that just doesn't fly. And BTW, the answer to your question is > > no, there are abundant examples of completely passive formats that are not > > vulnerable to, say, code injection attacks. > Can you give your best example? I'm completely missing it. If you can put > "code" in JSON, I expect you can put "code" in any format. Given that "code" and "data" are effectively equivalent (thank you von Neumann), and given the existence of steaganography, sure, "code", for some value of the word, can appear in any format. But being able to put code into a format doesn't necessarily translate into an injection attack. An injection attack occurs during some sort of subsitution operation where the substituted material is inadequately checked or quoted. For that to occur there necessarily has to be some sort of substitution operation that is a regular part of processing the material. Given these constraints, it's probably easier to list formats that are vulnerable to code injection attacks, but if you insist on specific examples, most image formats or even text/plain qualify. And yes, you can describe highly unlikely scenarios where some moron inserts raw image data directly into SQL or HTML or whatever. But there has to be some amount of common sense applied to writing security considerations, because if there isn't it ends up that since any concievable usage is possible everything is vulnerable to everything. So if you're describing a format where substitution operations are a regular part of its use, then you need to talk about code injection attacks. And if you aren't, you don't. > >>> 4) Error handling > >>> > >>> [What should a parser do if it encounters malformed JSON, > > > >> That's not a security consideration, that's a protocol implementation issue. > >> I don't think we should specify it, give the wildly different environments > >> where JSON parsing happens. > > > > Whether or not it's a security consideration depends on what the JSON is being > > used for. The fact that JSON is a container format that can be used for almost > > any purpose broadens the security considerations considerably, and that > > absolutely needs to be discussed. > Fully agree that it should be discussed. Note that Phill said "What should a > parser do", not "discuss the topic". I support the second (as you do), but I > object to the first. But that's sort of my point. What a parser should do depends on the usage semantics. So no, getting into specifics of what a parser should do isn't appropriate, but it's important to note that different usages require different sorts of error handling and maybe list some of the possibilities and generally when some approach is appropriate. > >>> 5) Resynchronization > >>> > >>> [How does a receiver that has received one malformed JSON message identify the start of the next item] > > > >> Same as 4. > > > > Same response. > > > >>> 6) Integrity > >>> > >>> [JSON does not provide for integrity checking and this needs to be considered in the framing protocol] > > > >> Sure, I guess that is a "security consideration" for any format. > > > > Wrong again. The obvious counterexample is a format that provides all the > > integrity checking it needs internally and thus doesn't require any sort of > > external integrity service. > Which formats do that? An obvious example would be multipart/signed. The entire point of multipart/signed to sign the content, which of course involves an integrity check. More specific examples would be any XML format that uses XML's signature capabilities. And while I can't name a specific JSON-based format that has built in integrity checks, it's entirely possible to define one. As it happens I'm working on the registration of an ASN.1-based format right now that incorporates an incredibly elaborate multi-level signature mechanism. And for that matter, integrity check doesn't necessarily mean signed. There are lots of formats that incorporate hashes and CRC checks. > > But more generally, while you can of course invent > > uses for pretty much any format imagineable that require integrity (or > > confidentiality) protection, there are formats which are designed for > > destributing public information and which do not involve active or executable > > content or pointers to other stuff. In such cases there really are no integrity > > concerns worth talking about. > Errr, right. Are you saying JSON involves active or executable content? It most definitely can and in practice is used that way. And that possibility also need to be mentioned. > Or pointers to other stuff? If so, I agree that those are security > considerations. I'm not seeing it in the JSON definition, however. What am I > missing? You're missing the fact that JSON is a container format that admits a wide range of specific uses, and the security considerations need to encompass that range of potential uses. In effect the security considerations for container formats become a guide for what to look at when evaluating security for specific applications of the format. It is necessarily the case that writing security considerations for container formats is more difficult than for a format intended for a specific application. But it's entirely doable. Ned From jasnell@gmail.com Thu Sep 20 10:51:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0006F21F8780 for ; Thu, 20 Sep 2012 10:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nl544Wz7KuOW for ; Thu, 20 Sep 2012 10:51:51 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F12C921F8512 for ; Thu, 20 Sep 2012 10:51:50 -0700 (PDT) Received: by weyx48 with SMTP id x48so1555268wey.31 for ; Thu, 20 Sep 2012 10:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IHKJw1lyIBm2/XV1NxcS95XYtKovqlT5hiSWYF1w6Lc=; b=iVl8zPvSQGHIY9gQ5Pw5j8sFFnvpelvB/ZmwQrX3tC4f3KZePXEFXcegX3qC94JBBS j7NAdu58AAn8OZzVAs51UYbF1mKt9uOQuBy5FJhrSPcz3/hltZQKgMeD+1WqvMKcW+K3 KQnZ+4PRqw4fx+FezAdHP9iPjsONzvEj82f85D1uZ06f6PFun+75RjpUk+IGo/P8RRMi 8ktwaphI6t3RKN3oh5eGh55TzI/uPsujS0iHsj3a+W6g0b7T+X5brC6/4PndyYSvHAaB XB4LGGg+TVHeNI04HcYH6kb88YPmUOwY47d6/omcLvMrNo6V8qHsFp9odHPXjkKCTXj+ r5Gw== Received: by 10.180.91.163 with SMTP id cf3mr5930866wib.13.1348163509836; Thu, 20 Sep 2012 10:51:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Thu, 20 Sep 2012 10:51:29 -0700 (PDT) In-Reply-To: <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> From: James M Snell Date: Thu, 20 Sep 2012 10:51:29 -0700 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=f46d0438956f1a5b4d04ca25c730 Cc: Ned Freed , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 17:51:52 -0000 --f46d0438956f1a5b4d04ca25c730 Content-Type: text/plain; charset=UTF-8 I believe the specific concern for JSON is that, in many environments -- especially browsers -- JSON is often parsed using the JavaScript eval function, which allows for the execution of arbitrary JavaScript code. While the JSON specification itself restricts the syntax to non-executable data, a malicious party could intentionally construct an invalid-JSON object such that arbitrary code is executed within the browser. This particular concern is unique for JavaScript relative to other formats (XML, HTML) and really ought be addressed within the security considerations of rfc4627. Specifically, implementors need to be warned against passing unvalidated JSON to the eval function. On Thu, Sep 20, 2012 at 8:52 AM, Paul Hoffman wrote: > [snip] > > > But more generally, while you can of course invent > > uses for pretty much any format imagineable that require integrity (or > > confidentiality) protection, there are formats which are designed for > > destributing public information and which do not involve active or > executable > > content or pointers to other stuff. In such cases there really are no > integrity > > concerns worth talking about. > > > Errr, right. Are you saying JSON involves active or executable content? Or > pointers to other stuff? If so, I agree that those are security > considerations. I'm not seeing it in the JSON definition, however. What am > I missing? > > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d0438956f1a5b4d04ca25c730 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe the specific concern for JSO= N is that, in many environments -- especially browsers -- JSON is often par= sed using the JavaScript eval function, which allows for the execution of a= rbitrary JavaScript code. While the JSON specification itself restricts the= syntax to non-executable data, a malicious party could intentionally const= ruct an invalid-JSON object such that arbitrary code is executed within the= browser. This particular concern is unique for JavaScript relative to othe= r formats (XML, HTML) and really ought be addressed within the security con= siderations of rfc4627. Specifically, implementors need to be warned agains= t passing unvalidated JSON to the eval function.

    On Thu, Sep 20, 2012 at 8:52 AM, Paul= Hoffman <paul.hoffman@vpnc.org> wrote:
    [snip]

    > But more generally, while you can of course invent
    > uses for pretty much any format imagineable that require integrity (or=
    > confidentiality) protection, there are formats which are designed for<= br> > destributing public information and which do not involve active or exe= cutable
    > content or pointers to other stuff. In such cases there really are no = integrity
    > concerns worth talking about.


    Errr, right. Are you saying JSON involves active or executable conten= t? Or pointers to other stuff? If so, I agree that those are security consi= derations. I'm not seeing it in the JSON definition, however. What am I= missing?

    --Paul Hoffman
    _____________________= __________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss

    --f46d0438956f1a5b4d04ca25c730-- From hallam@gmail.com Thu Sep 20 10:53:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5922421F8757 for ; Thu, 20 Sep 2012 10:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.007 X-Spam-Level: X-Spam-Status: No, score=-4.007 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjthXlRMySFl for ; Thu, 20 Sep 2012 10:53:40 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 390FE21F8752 for ; Thu, 20 Sep 2012 10:53:40 -0700 (PDT) Received: by oagn5 with SMTP id n5so2116615oag.31 for ; Thu, 20 Sep 2012 10:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UXPBrPnCpXuhYURwnkx5/wqMtPQFiUJWz6ihRyHCR94=; b=pQ6IDJFtX1soZYlyRLlexK6MzIXxt0BNFmJwOqkl71pFXycvOvl3LokJQcOuSBWTio qgjVbxm44KQzCXFZn8UbZb1yxM47WNzVDoOWTO6ginRO3LAZjY1SAWKoFV3Hyly3hLQY WLv34tiiszDaUw70fDM8m6sE3Jg/xOGJQ8kSerLYQ2z/8uxUH5FKpsxwtsp54TBuKXcp 9b88CBUASvoBhdmklUVEmbwqQGXnjrPbHTDTVDdlRm2m/MEvIyZrUlIDhJNT4454WtMZ kyVk7oyaSq70DKdj5p5sBv76qR2TgUgY9MFtNNIJgAefp6aMVavqyrF8l1w70GuSQ5eY emHw== MIME-Version: 1.0 Received: by 10.60.29.72 with SMTP id i8mr1901033oeh.26.1348163619788; Thu, 20 Sep 2012 10:53:39 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 10:53:39 -0700 (PDT) In-Reply-To: References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> Date: Thu, 20 Sep 2012 13:53:39 -0400 Message-ID: From: Phillip Hallam-Baker To: "evan@status.net" Content-Type: multipart/alternative; boundary=e89a8fb1f806a8162804ca25cd81 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 17:53:42 -0000 --e89a8fb1f806a8162804ca25cd81 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I could try to upload my Goedel and ProtoGen toolset to Github. this is the specification I am currently working on. http://tools.ietf.org/html/draft-hallambaker-omnibroker-02 ProtoGen is a tool that is designed to help write specifications that also emits code that may be used in either a validator or a test suite or examples or production code. You would want to use different back ends for each case though. Now I did one thing which is a bit of a cheat and that is that I pushed the integrity checking information into the HTTP wrapper rather than try to use something like a JSON Signature approach. So that means that I do not have to worry about how to define an integrity checking constraint at the protocol level, I assume that to be done for me in the HTTP framing. But looking how simple this approach turns out and how complex the alternatives are, I think it is the right way forward. On Thu, Sep 20, 2012 at 1:34 PM, evan@status.net wrote: > Can we engrave these rules on a big rock somewhere? > > > Tim Bray wrote: >> >> On Thu, Sep 20, 2012 at 9:26 AM, Erik Wilde wrote: >> >> > i have to admit that i am really curious why the seasoned spec writers >> that >> > have voiced general concerns about the usefulness of schema languages >> are >> > feeling this way, but so far i have not really understood what they ar= e >> > saying. could somebody please try again, i'd really like to understand >> why >> > the general idea of describing protocol syntax in a semi-formal (as >> opposed >> > to non-formal) way is considered a bad idea. >> >> I gave a preso at IETF70 in Vancouver a few years ago which is advertise= d >> as being XML-centric, but has (I think) useful things to say about >> plain-text/binary/ASN.1/JSON/XML, and discusses about the proper place o= f >> schemas: http://www.ietf.org/proceedings/70/slides/xmltut-0.pdf >> >> I believe: >> - ASN.1 has been bypassed by history and has truly horrible tooling. Jus= t >> don=92t go there. >> - If you=92re interchanging documents, use XML; if (much more common) >> you=92re interchanging data structures, use JSON. >> - Do not use multiple syntaxes for the same protocol. Pick one of XML or >> JSON and stick with it. >> - The most important thing in defining a protocol is good clean >> comprehensible human-readable prose. >> - All the protocols I=92ve ever seen have important constraints that can= =92t >> be expressed usefully in declarative schema languages. >> - Therefore, the next most important thing is an automated >> validator/test-suite. >> - A schema is a nice-to-have. >> - If you=92re in XML and want schema-ware, use RelaxNG. For an example, = see >> RFC4287. >> - If your protocol is JSON, investment in a validator/test-suite has muc= h >> higher ROI than chasing schema unicorns. >> >> >> >> > >> > thanks a lot and kind regards, >> > >> > dret. >> > >> > -- >> > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | >> > | UC Berkeley - School of Information (ISchool) | >> > | http://dret.net/netdret http://twitter.com/dret | >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss >> >> ------------------------------ >> >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --=20 Website: http://hallambaker.com/ --e89a8fb1f806a8162804ca25cd81 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I could try to upload my Goedel and ProtoGen toolset to Github.

    this is the specification I am currently working on.

    =
    http://tools.ietf.org/html/draft-hallambaker-omnibroker-02=A0
    ProtoGen is a tool that is designed to help write specifications that a= lso emits code that may be used in either a validator or a test suite or ex= amples or production code.

    You would want to use d= ifferent back ends for each case though.=A0


    Now I did one thing which is a bit of a cheat and that is that I pu= shed the integrity checking information into the HTTP wrapper rather than t= ry to use something like a JSON Signature approach. So that means that I do= not have to worry about how to define an integrity checking constraint at = the protocol level, I assume that to be done for me in the HTTP framing.

    But looking how simple this approach turns out and how = complex the alternatives are, I think it is the right way forward.=A0
    On Thu, Sep 20, 2012 at 1:34 PM, evan@status.net <evan@status.net> wr= ote:
    Can we engrave these rules on a bi= g rock somewhere?


    = Tim Bray <tbra= y@textuality.com> wrote:
    On Thu, Sep 20, 2012 at 9:26 AM, Erik Wilde <dret@berkeley.edu> wrote:

    > i = have to admit that i am really curious why the seasoned spec writers that > have voiced general concerns about the usefulness of schema languages = are
    > feeling this way, but so far i have not really understood what they ar= e
    > saying. could somebody please try again, i'd really like to u= nderstand why
    > the general idea of describing protocol syntax in a s= emi-formal (as opposed
    > to non-formal) way is considered a bad idea.

    I gave a preso at = IETF70 in Vancouver a few years ago which is advertised as being XML-centri= c, but has (I think) useful things to say about plain-text/binary/ASN.1/JSO= N/XML, and discusses about the proper place of schemas: http://ww= w.ietf.org/proceedings/70/slides/xmltut-0.pdf

    I believe:
    - ASN.1 has been bypassed by history and has truly horrib= le tooling. Just don=92t go there.
    - If you=92re interchanging documents= , use XML; if (much more common) you=92re interchanging data structures, us= e JSON.
    - Do not use multiple syntaxes for the same protocol. Pick one of XML or JS= ON and stick with it.
    - The most important thing in defining a protocol = is good clean comprehensible human-readable prose.
    - All the protocols I= =92ve ever seen have important constraints that can=92t be expressed useful= ly in declarative schema languages.
    - Therefore, the next most important thing is an automated validator/test-s= uite.
    - A schema is a nice-to-have.
    - If you=92re in XML and want sch= ema-ware, use RelaxNG. For an example, see RFC4287.
    - If your protocol i= s JSON, investment in a validator/test-suite has much higher ROI than chasi= ng schema unicorns.



    >
    > thanks a lot and kind regards,
    >
    > dre= t.
    >
    > --
    > erik wilde | mailto:dret@berkeley.edu =A0- =A0tel:+1-510-20610= 79 |
    > =A0 =A0 =A0 =A0 =A0 =A0| UC Berkeley =A0- =A0School of Information (IS= chool) |
    > =A0 =A0 =A0 =A0 =A0 =A0| http://dret.net/netdret http://twitter.com/dret |
    > _____________________= __________________________
    > apps-discuss mailing list
    > apps-discus= s@ietf.org
    > https://www.ietf.org/mailman/listinfo/apps-dis= cuss


    apps-discuss mailing list
    apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss

    --
    Sent from my Android phone with K-9 Mail. Please excuse my brevity.    <= /span>

    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss




    --
    Website:= http://hallambaker.com/

    --e89a8fb1f806a8162804ca25cd81-- From julian.reschke@gmx.de Thu Sep 20 10:54:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4B321F875A for ; Thu, 20 Sep 2012 10:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfklY6Lf+V6I for ; Thu, 20 Sep 2012 10:54:43 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8162021F8752 for ; Thu, 20 Sep 2012 10:54:42 -0700 (PDT) Received: (qmail invoked by alias); 20 Sep 2012 17:54:41 -0000 Received: from p54BB26CF.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.38.207] by mail.gmx.net (mp010) with SMTP; 20 Sep 2012 19:54:41 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/df499dODdM/2bMBrcCCYJE+yqvHrqZGFGVKoumn AQ4rUhY/xYMXR2 Message-ID: <505B585D.3050401@gmx.de> Date: Thu, 20 Sep 2012 19:54:37 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 17:54:45 -0000 On 2012-09-20 19:47, Phillip Hallam-Baker wrote: > ... > ... > - Do not use multiple syntaxes for the same protocol. Pick one of > XML or JSON and stick with it. > > > Agree but note that this conflicts with the REST notion of using URL > encoded requests and JSON responses. Which I think is yucky but some > insist on. > ... Where does that notion come from? I don't see what this has to with being restful or not (there, I said it; I'll probably regret it :-). Best regards, Julian From julian.reschke@gmx.de Thu Sep 20 10:58:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43D321F87E9 for ; Thu, 20 Sep 2012 10:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aganYbwsn-a for ; Thu, 20 Sep 2012 10:58:00 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id DC51C21F8783 for ; Thu, 20 Sep 2012 10:57:59 -0700 (PDT) Received: (qmail invoked by alias); 20 Sep 2012 17:57:58 -0000 Received: from p54BB26CF.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.38.207] by mail.gmx.net (mp017) with SMTP; 20 Sep 2012 19:57:58 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+gACxXvRegFE6S6UlwRre+e4RC9cHZ6uxebEVNqG y5HxWhKEZTzfa5 Message-ID: <505B5922.5020704@gmx.de> Date: Thu, 20 Sep 2012 19:57:54 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ned Freed References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> In-Reply-To: <01OKH59WL0SW0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 17:58:00 -0000 On 2012-09-20 19:18, Ned Freed wrote: > ... > Errr, right. Are you saying JSON involves active or executable content? > > It most definitely can and in practice is used that way. And that possibility > also need to be mentioned. > ... But that's not JSON; it's just something that remotely looks like it. I have nothing against warning people to *always* use strict JSON parsers (not JS eval) to process JSON, but we should be clear about what's JSON and what is not. Best regards, Julian From julian.reschke@gmx.de Thu Sep 20 11:01:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA11621F8814 for ; Thu, 20 Sep 2012 11:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZFWA7FgAhBH for ; Thu, 20 Sep 2012 11:01:26 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id B467A21F880D for ; Thu, 20 Sep 2012 11:01:25 -0700 (PDT) Received: (qmail invoked by alias); 20 Sep 2012 18:01:24 -0000 Received: from p54BB26CF.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.38.207] by mail.gmx.net (mp037) with SMTP; 20 Sep 2012 20:01:24 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/NYVcwY/HNeckJcXCe8L7MP6Pe3IjryZC89vkblQ 0MvfnbZsLBlE4s Message-ID: <505B59F0.5020404@gmx.de> Date: Thu, 20 Sep 2012 20:01:20 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: James M Snell References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:01:26 -0000 On 2012-09-20 19:51, James M Snell wrote: > I believe the specific concern for JSON is that, in many environments -- > especially browsers -- JSON is often parsed using the JavaScript eval > function, which allows for the execution of arbitrary JavaScript code. > While the JSON specification itself restricts the syntax to > non-executable data, a malicious party could intentionally construct an > invalid-JSON object such that arbitrary code is executed within the > browser. This particular concern is unique for JavaScript relative to > other formats (XML, HTML) and really ought be addressed within the > security considerations of rfc4627. Specifically, implementors need to > be warned against passing unvalidated JSON to the eval function. > ... ...need to be warned not to ever pass JSON to eval. If you can validate it, you have already parsed it, and there's no point anymore to use eval(). Best regards, Julian From hallam@gmail.com Thu Sep 20 11:05:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0985721F8814 for ; Thu, 20 Sep 2012 11:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[AWL=-1.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqLoyLZm1Fk1 for ; Thu, 20 Sep 2012 11:05:08 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46B3821F8810 for ; Thu, 20 Sep 2012 11:05:08 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2720293obb.31 for ; Thu, 20 Sep 2012 11:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EJkxpBH5wzZoiZYThtO6kXeMCF2uFE9QUes/i1BN/J4=; b=owJEZOYdairjuUQ9zkf99ydEZ8s9CYoG/LixDOhf5/itkVQ6xXd2VJ8oRAgj21oVF+ fI4pRXB9cUCLLdDNeErGZY6s/FRb9FpqYxZ6mvNy52YRzX7BgUbwdJuw/5N2lP9d0wGj 6sNOv1AfgfqNthfrrUc3QNDa2g1ORGSSJEF6ySIbmlPfQHuF+k6R8oUPkr9LkePJAhfp i6mLaK4xpPU4XUaebMiD54iDB1YvZQymD6EvuHPU2642PPKYzbS2f/6I5gX7fMIrRv6H ZD3NmR32gimloiy+SjAbjpTagLFor0jM7XWaaGyL4EWF9KAr8JpMkvRFLBSxR0RFAo8W HRGQ== MIME-Version: 1.0 Received: by 10.60.170.138 with SMTP id am10mr1912860oec.115.1348164307724; Thu, 20 Sep 2012 11:05:07 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 11:05:07 -0700 (PDT) In-Reply-To: <505B5922.5020704@gmx.de> References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> Date: Thu, 20 Sep 2012 14:05:07 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=bcaec517a4a0a927af04ca25f690 Cc: Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:05:09 -0000 --bcaec517a4a0a927af04ca25f690 Content-Type: text/plain; charset=ISO-8859-1 I think the real problem with the vague references to 'code' in the JSON RFC is that they mean absolutely nothing. I am not sure that they even bear mention. The real problem with interpreted languages is that they make it easy to mix the control and data channel which is of course what makes code injection attacks possible. SQL mixes the two in convoluted ways. What the security statement needs to say than is that encoders need to ensure that strings are appropriately escaped in all cases and that code does not simply do things like printf ("{ \"tag\" : \"%0\" }", foo); It has to be printf ("{ \"tag\" : \"%0\" }", StringPrep (foo)); I think that is the problem the language is hinting at but failing to make clear. If people use JSON to carry data that is SQL commands, shell commands or similar then these issues are going to be security considerations. That is why the types of encoding we prefer in a security sensitive application tend to use either an explicit length encoding (ASN.1 approach) or randomized guard values or both. The real objective is to make sure that nobody can try to just wing it like you can in a scripting language. If you write code to be used in very dangerous environments then you have a different approach. On Thu, Sep 20, 2012 at 1:57 PM, Julian Reschke wrote: > On 2012-09-20 19:18, Ned Freed wrote: > > ... > > > Errr, right. Are you saying JSON involves active or executable content? > >> >> It most definitely can and in practice is used that way. And that >> possibility >> also need to be mentioned. >> ... >> > > But that's not JSON; it's just something that remotely looks like it. > > I have nothing against warning people to *always* use strict JSON parsers > (not JS eval) to process JSON, but we should be clear about what's JSON and > what is not. > > Best regards, Julian > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > -- Website: http://hallambaker.com/ --bcaec517a4a0a927af04ca25f690 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    I think the real problem with the vag= ue references to 'code' in the JSON RFC is that they mean absolutel= y nothing. I am not sure that they even bear mention.

    The real problem with interpreted languages is that they make it easy to mi= x the control and data channel which is of course what makes code injection= attacks possible. SQL mixes the two in convoluted ways.


    What the security statement needs to say than is that encoders need to ensu= re that strings are appropriately escaped in all cases and that code does n= ot simply do things like

    printf ("{ \"tag\= " : \"%0\" }", foo);

    It has to be=A0

    printf ("{ \"tag\= " : \"%0\" }", StringPrep (foo));


    I think that is the problem the language is hinting at but failing to make = clear.=A0

    If people use JSON to carry data that is SQL commands, shell commands or si= milar then these issues are going to be security considerations.
    =

    That is why the types of encoding we prefer i= n a security sensitive application tend to use either an explicit length en= coding (ASN.1 approach) or randomized guard values or both.

    The real objective is to make sure that nobody can try = to just wing it like you can in a scripting language.

    <= div>If you write code to be used in very dangerous environments then you ha= ve a different approach.=A0


    On Thu, Sep 20, 2012 at 1:57 = PM, Julian Reschke <julian.reschke@gmx.de> wrote:
    On 2012-09-20 19:18, Ned Freed wrote:
    > ...

    > Errr, right. Are you saying JSON involves active or executable content= ?

    It most definitely can and in practice is used that way. And that possibili= ty
    also need to be mentioned.
    ...

    But that's not JSON; it's just something that remotely looks like i= t.

    I have nothing against warning people to *always* use strict JSON parsers (= not JS eval) to process JSON, but we should be clear about what's JSON = and what is not.

    Best regards, Julian

    _______________________________________________
    apps-discuss mailing list
    apps-discuss@iet= f.org
    https://www.ietf.org/mailman/listinfo/apps-discuss



    --
    = Website: http://hallambaker.com/
    --bcaec517a4a0a927af04ca25f690-- From julian.reschke@gmx.de Thu Sep 20 11:12:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F4B21F871E for ; Thu, 20 Sep 2012 11:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqAR1SeRWD8P for ; Thu, 20 Sep 2012 11:12:17 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 35A9E21F871A for ; Thu, 20 Sep 2012 11:12:16 -0700 (PDT) Received: (qmail invoked by alias); 20 Sep 2012 18:12:15 -0000 Received: from p54BB26CF.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.38.207] by mail.gmx.net (mp034) with SMTP; 20 Sep 2012 20:12:15 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+MXfVkqtGMOTbJKhZL+wBsg1NvvOvmvPDIJorUVi 4ZYWQC0Ieb04Xe Message-ID: <505B5C7B.1010005@gmx.de> Date: Thu, 20 Sep 2012 20:12:11 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:12:18 -0000 On 2012-09-20 20:05, Phillip Hallam-Baker wrote: > I think the real problem with the vague references to 'code' in the JSON > RFC is that they mean absolutely nothing. I am not sure that they even > bear mention. > ... RFC 4627 doesn't mention "code" in the sense of programming code at all. > The real problem with interpreted languages is that they make it easy to > mix the control and data channel which is of course what makes code > injection attacks possible. SQL mixes the two in convoluted ways. > > > What the security statement needs to say than is that encoders need to > ensure that strings are appropriately escaped in all cases and that code > does not simply do things like > > printf ("{ \"tag\" : \"%0\" }", foo); > > It has to be > > printf ("{ \"tag\" : \"%0\" }", StringPrep (foo)); > > > I think that is the problem the language is hinting at but failing to > make clear. > ... I think that security considerations for *recipients* are much more important; and guess what, RFC 4627 has some. It's nice if senders are not vulnerable to code injection, but if recipients parse JSON as JSON, they are by definition not vulnerable. > If people use JSON to carry data that is SQL commands, shell commands or > similar then these issues are going to be security considerations. > > > That is why the types of encoding we prefer in a security sensitive > application tend to use either an explicit length encoding (ASN.1 > approach) or randomized guard values or both. > ... That's all very interesting, but how does that affect JSON? I would recommend that anybody who wants something specifically changed in RFC 4627 first checks whether it might there already (me guilty of that as well (*)), and then makes a *concrete* proposal. Best regards, Julian (*) RFC 4627 explains how to use a regexp to validate that a given octet sequence is safe to be passed to JS eval(). From barryleiba.mailing.lists@gmail.com Thu Sep 20 11:13:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8687B21F86F5 for ; Thu, 20 Sep 2012 11:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlSMqwXvfl72 for ; Thu, 20 Sep 2012 11:13:25 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA39021F8646 for ; Thu, 20 Sep 2012 11:13:24 -0700 (PDT) Received: by lboj14 with SMTP id j14so2518116lbo.31 for ; Thu, 20 Sep 2012 11:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=5W9WuOjRslmetSutTfoV53TpUKiSdbVaJw4nK8xhZHw=; b=HkLVrOw/23YLrEP8N6bjFH6MtFaap4SmM6u9+uqVnHar3USEOwEDO0h3MG8xVmQ49w CWGw1u+J45/Cv6KDbLdMbV5BuF6P2gl2TxDv/WxJfWT+OfkuQuW+eMuO6SSibIt5newE hj/sfPpaDQmH1e+lzrRvR5iHyfeC/jYGzznPJWz91/fX//E/PFOuFNrtA0NPO2xdnPok Z1GyC6uDZ1uA3w+jLzHM/rJEaVmtoF7zb1Lwol31Elcc+j4jELQyypFkogOzWDOIU5ZB idJI9JXMiY93LPIOV8QLhPgvl6ENTvEiiy5Jxf7DdBVENVnzLHYSCayzt0AqqqTdlqMR Vsag== MIME-Version: 1.0 Received: by 10.152.132.168 with SMTP id ov8mr2270590lab.0.1348164803698; Thu, 20 Sep 2012 11:13:23 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Thu, 20 Sep 2012 11:13:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Sep 2012 14:13:23 -0400 X-Google-Sender-Auth: mKTsyAQi1bVjnrx187MxUZq3w7E Message-ID: From: Barry Leiba To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:13:25 -0000 > Apart from that, Your Friendly ADs have been discussing the > possibility of reclassifying it as Proposed Standard. Comments about > such a move are welcome on this thread. Someone mentioned to me that my use of the term "reclassify" might have been unclear. To be completely clear: we aren't considering changing the classification of RFC 4627 as it stands. It would only be done by updating the document and publishing a new RFC at Proposed Standard. Barry, Applications AD From paul.hoffman@vpnc.org Thu Sep 20 11:15:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C4121F879C for ; Thu, 20 Sep 2012 11:15:52 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmIMP97UoxLn for ; Thu, 20 Sep 2012 11:15:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 765D521F86F5 for ; Thu, 20 Sep 2012 11:15:51 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q8KIFn15020855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Sep 2012 11:15:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Paul Hoffman In-Reply-To: <01OKH59WL0SW0006TF@mauve.mrochek.com> Date: Thu, 20 Sep 2012 11:15:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <58D58DEF-9606-499A-A51D-935EA69AA2A1@vpnc.org> References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1498) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:15:52 -0000 On Sep 20, 2012, at 10:18 AM, Ned Freed wrote: > Given that "code" and "data" are effectively equivalent (thank you von > Neumann), and given the existence of steaganography, sure, "code", for = some > value of the word, can appear in any format. I'm glad we agree on that. > But being able to put code into a > format doesn't necessarily translate into an injection attack. An = injection > attack occurs during some sort of subsitution operation where the = substituted > material is inadequately checked or quoted. For that to occur there = necessarily > has to be some sort of substitution operation that is a regular part = of > processing the material. That is a very good definition. > Given these constraints, it's probably easier to list formats that are > vulnerable to code injection attacks, but if you insist on specific > examples, most image formats or even text/plain qualify. We fully disagree about text/plain, then. Text/plain is often used for = configuration files that are slurped in with inadequate checking.=20 > And yes, you can describe highly unlikely scenarios where some moron = inserts > raw image data directly into SQL or HTML or whatever. But there has to = be some > amount of common sense applied to writing security considerations, = because if > there isn't it ends up that since any concievable usage is possible = everything > is vulnerable to everything. So if you're describing a format where > substitution operations are a regular part of its use, then you need = to talk > about code injection attacks. And if you aren't, you don't. Fully agree. But it seems we disagree about which formats those are. >>>>> 5) Resynchronization >>>>>=20 >>>>> [How does a receiver that has received one malformed JSON message = identify the start of the next item] >>>=20 >>>> Same as 4. >>>=20 >>> Same response. >>>=20 >>>>> 6) Integrity >>>>>=20 >>>>> [JSON does not provide for integrity checking and this needs to be = considered in the framing protocol] >>>=20 >>>> Sure, I guess that is a "security consideration" for any format. >>>=20 >>> Wrong again. The obvious counterexample is a format that provides = all the >>> integrity checking it needs internally and thus doesn't require any = sort of >>> external integrity service. >=20 >> Which formats do that? >=20 > An obvious example would be multipart/signed. The entire point of > multipart/signed to sign the content, which of course involves an = integrity > check. More specific examples would be any XML format that uses XML's = signature > capabilities. And while I can't name a specific JSON-based format that = has > built in integrity checks, it's entirely possible to define one. Of course. But I thought we were talking about formats like JSON, not = profiles of that format.=20 > As it happens I'm working on the registration of an ASN.1-based format = right > now that incorporates an incredibly elaborate multi-level signature = mechanism.=20 Been there, done that. Have fun. > And for that matter, integrity check doesn't necessarily mean signed. = There are > lots of formats that incorporate hashes and CRC checks. If they are not protected with a cryptographic key, then they don't have = integrity checking. The attacker simply replaces both the text and the = hash/CRC. >>> But more generally, while you can of course invent >>> uses for pretty much any format imagineable that require integrity = (or >>> confidentiality) protection, there are formats which are designed = for >>> destributing public information and which do not involve active or = executable >>> content or pointers to other stuff. In such cases there really are = no integrity >>> concerns worth talking about. >=20 >> Errr, right. Are you saying JSON involves active or executable = content? >=20 > It most definitely can and in practice is used that way. And that = possibility > also need to be mentioned. OK, I think I see what I missed. You are conflating active and = executable content. JSON does not have direct support for active = content. JavaScript and Python (and probably others) can treat a JSON = object as an executable assignment. It makes good sense to have a = security consideration that says "don't do that". >> Or pointers to other stuff? If so, I agree that those are security >> considerations. I'm not seeing it in the JSON definition, however. = What am I >> missing? >=20 > You're missing the fact that JSON is a container format that admits a > wide range of specific uses, and the security considerations need to > encompass that range of potential uses. And you're missing the point that formats like text/plain and text/html = have the same property. > In effect the security considerations > for container formats become a guide for what to look at when = evaluating > security for specific applications of the format. Correct. > It is necessarily the case that writing security considerations for = container > formats is more difficult than for a format intended for a specific=20 > application. But it's entirely doable. Fully agree. --Paul Hoffman= From paul.hoffman@vpnc.org Thu Sep 20 11:15:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3ED21F8747 for ; Thu, 20 Sep 2012 11:15:59 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ejw+48Z7Ffvb for ; Thu, 20 Sep 2012 11:15:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 05BA021F881A for ; Thu, 20 Sep 2012 11:15:58 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q8KIFn16020855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Sep 2012 11:15:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Paul Hoffman In-Reply-To: Date: Thu, 20 Sep 2012 11:15:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <90989D99-831E-45E7-A836-88A7CE9C2674@vpnc.org> References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> To: James M Snell X-Mailer: Apple Mail (2.1498) Cc: Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:15:59 -0000 On Sep 20, 2012, at 10:51 AM, James M Snell wrote: > I believe the specific concern for JSON is that, in many environments = -- especially browsers -- JSON is often parsed using the JavaScript eval = function, which allows for the execution of arbitrary JavaScript code. = While the JSON specification itself restricts the syntax to = non-executable data, a malicious party could intentionally construct an = invalid-JSON object such that arbitrary code is executed within the = browser. This particular concern is unique for JavaScript relative to = other formats (XML, HTML) and really ought be addressed within the = security considerations of rfc4627. Specifically, implementors need to = be warned against passing unvalidated JSON to the eval function. Yes, definitely. --Paul Hoffman= From jasnell@gmail.com Thu Sep 20 11:26:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C179921F86A2 for ; Thu, 20 Sep 2012 11:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=-0.963, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkDYgjPVgB6m for ; Thu, 20 Sep 2012 11:26:13 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 08D2621F84F9 for ; Thu, 20 Sep 2012 11:26:12 -0700 (PDT) Received: by weyx48 with SMTP id x48so1574958wey.31 for ; Thu, 20 Sep 2012 11:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=P1NlYHuJd8RMf9rAD2vqRuokg8R+vOskqYUeik6/lbs=; b=L8GwFQ6xD9gtPolACRI5I6exlfjsEd8yWwpcaxANYMXcaeYqM4GJAWxrtmH4JeM7NW R8ccKdNnV0kTNV9I8uU+8Vj3Td8a1UxZ1e0jRm/7PXuOa3BKwPoG7Eczrv6J4VcFGVkl 86/o8URuR6gVLs85J00svh7OC14HgYL7PEurRqvkQfbukxMhnP18vbQVbcinduaFcQO2 U4ONSPBnaRdmapxcdksd1VkV4Cmf5eitBGR98zXMR65UCTuxIJdjADjfXeEbpSYum3FS vbSgP/z857TYX2KFL2vhNfg8WhM7p1vMMkcSGk4sjc07WT5LImB5LtQMj12xyBZrj0Sk XqTw== Received: by 10.216.135.148 with SMTP id u20mr1489844wei.137.1348165572052; Thu, 20 Sep 2012 11:26:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Thu, 20 Sep 2012 11:25:51 -0700 (PDT) In-Reply-To: <505B5C7B.1010005@gmx.de> References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> From: James M Snell Date: Thu, 20 Sep 2012 11:25:51 -0700 Message-ID: To: Julian Reschke Content-Type: multipart/alternative; boundary=0016e6dd992005459604ca2642a0 Cc: Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:26:13 -0000 --0016e6dd992005459604ca2642a0 Content-Type: text/plain; charset=UTF-8 Agreed. The one specific change that I can see right off hand is an explicit recommendation to utilize JavaScript's JSON.parse function instead of eval in all cases, despite the fact that JSON can be checked by regex first. The latter is, by far, the more reliable and secure approach. - James On Thu, Sep 20, 2012 at 11:12 AM, Julian Reschke wrote: > [snip] > > I would recommend that anybody who wants something specifically changed in > RFC 4627 first checks whether it might there already (me guilty of that as > well (*)), and then makes a *concrete* proposal. > > Best regards, Julian > > (*) RFC 4627 explains how to use a regexp to validate that a given octet > sequence is safe to be passed to JS eval(). > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --0016e6dd992005459604ca2642a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed. The one specific change that I= can see right off hand is an explicit recommendation to utilize JavaScript= 's JSON.parse function instead of eval in all cases, despite the fact t= hat JSON can be checked by regex first. The latter is, by far, the more rel= iable and secure approach.

    --0016e6dd992005459604ca2642a0-- From julian.reschke@gmx.de Thu Sep 20 11:35:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F82B21E808B for ; Thu, 20 Sep 2012 11:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.97 X-Spam-Level: X-Spam-Status: No, score=-103.97 tagged_above=-999 required=5 tests=[AWL=-1.971, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKxzgjUd+FIa for ; Thu, 20 Sep 2012 11:35:44 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 7A87C21E8089 for ; Thu, 20 Sep 2012 11:35:43 -0700 (PDT) Received: (qmail invoked by alias); 20 Sep 2012 18:35:42 -0000 Received: from p5DD95893.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.88.147] by mail.gmx.net (mp031) with SMTP; 20 Sep 2012 20:35:42 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+cGIRzdficbNPbFBDWMR6AXg0X9UQs4qDMYo9XNy qsgd7uW7Q8Q1vM Message-ID: <505B61FA.6000008@gmx.de> Date: Thu, 20 Sep 2012 20:35:38 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: James M Snell References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:35:44 -0000 On 2012-09-20 20:25, James M Snell wrote: > Agreed. The one specific change that I can see right off hand is an > explicit recommendation to utilize JavaScript's JSON.parse function > instead of eval in all cases, despite the fact that JSON can be checked > by regex first. The latter is, by far, the more reliable and secure > approach. > ... Indeed. From hallam@gmail.com Thu Sep 20 11:38:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E73221F857E for ; Thu, 20 Sep 2012 11:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.978 X-Spam-Level: X-Spam-Status: No, score=-3.978 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVc9zpJSSJsw for ; Thu, 20 Sep 2012 11:38:04 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0FF21F8468 for ; Thu, 20 Sep 2012 11:38:04 -0700 (PDT) Received: by oagn5 with SMTP id n5so2167602oag.31 for ; Thu, 20 Sep 2012 11:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G2glq9lS1YeiaRdVSd5sLCSOjQtwQRF+6mzxAt02Kys=; b=zHobSHXNllNPZ1WpxkAD2CzinoWvKRx8WOwJpkzRHzqSKxZkzDryqO1uOYKZb0WaGL k/n4ZZWRUDZJ/dGTv0bvRIjZ9BHWmZt+ULzn3vzw9P69aihKoRySwQDfFKG8JF96fP9p +hyIlsIdefMkvd3MvXpmbrkOGMe60QNH3TvP3C1xXJvugn4uGwETsgVUPORkZyJyX4Mc ES6+K99G/ExXxjaxgVlIivmfUuX2qAHtcUjYI6h9BN0gN1Zn9dLtGzVsxeQTIKU0GDYm 7paCWsy3Ery2G9UGTN4dREiYk8RPmzczSPoCCJ+AbayZUQel6PTt3xHOg0ML3ANWB7oR z26w== MIME-Version: 1.0 Received: by 10.60.29.72 with SMTP id i8mr1994960oeh.26.1348166283907; Thu, 20 Sep 2012 11:38:03 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 11:38:03 -0700 (PDT) In-Reply-To: <505B585D.3050401@gmx.de> References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> <505B585D.3050401@gmx.de> Date: Thu, 20 Sep 2012 14:38:03 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=e89a8fb1f8067350e204ca266c24 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:38:05 -0000 --e89a8fb1f8067350e204ca266c24 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 20, 2012 at 1:54 PM, Julian Reschke wrote: > On 2012-09-20 19:47, Phillip Hallam-Baker wrote: > >> ... >> ... >> >> - Do not use multiple syntaxes for the same protocol. Pick one of >> XML or JSON and stick with it. >> >> >> Agree but note that this conflicts with the REST notion of using URL >> encoded requests and JSON responses. Which I think is yucky but some >> insist on. >> ... >> > > Where does that notion come from? I don't see what this has to with being > restful or not (there, I said it; I'll probably regret it :-). > I asked Roy Fielding that and he gave me much the same answer. But I am going to have to implement that to use my compiler to do OAUTH and specs already using that style. https://tools.ietf.org/html/draft-ietf-oauth-v2-30 As a practical matter, what I like about the schema approach is that it can help channel people into making the sensible choice or at least a consistent one. If the default switches on the compiler are for JSON requests and responses then people have to make a case for messing with them. -- Website: http://hallambaker.com/ --e89a8fb1f8067350e204ca266c24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Thu, Sep 20, 2012 at 1:54 PM, Julian = Reschke <julian.reschke@gmx.de> wrote:
    On 2012-09-20 19:47, Phillip Hallam-Baker wrote:
    ...
    ...

    =A0 =A0 - Do not use multiple syntaxes for the same protocol. Pick one of =A0 =A0 XML or JSON and stick with it.


    Agree but note that this conflicts with the REST notion of using URL
    encoded requests and JSON responses. Which I think is yucky but some
    insist on.
    ...

    Where does that notion come from? I don't see what this has to with bei= ng restful or not (there, I said it; I'll probably regret it :-).

    I asked Roy Fielding that and he gave me muc= h the same answer.

    But I am going to have to implement that to use my comp= iler to do OAUTH and specs already using that style.
    =A0
    https://to= ols.ietf.org/html/draft-ietf-oauth-v2-30


    As a practical matter, what I like about= the schema approach is that it can help channel people into making the sen= sible choice or at least a consistent one. If the default switches on the c= ompiler are for JSON requests and responses then people have to make a case= for messing with them.

    --
    Website: ht= tp://hallambaker.com/

    --e89a8fb1f8067350e204ca266c24-- From hallam@gmail.com Thu Sep 20 11:44:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C49421E8063 for ; Thu, 20 Sep 2012 11:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.971 X-Spam-Level: X-Spam-Status: No, score=-3.971 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LwllKesllyZ for ; Thu, 20 Sep 2012 11:44:15 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 68C3C21E804B for ; Thu, 20 Sep 2012 11:44:15 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2763468obb.31 for ; Thu, 20 Sep 2012 11:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VqEqDA13ihUsuHv9+PLhEq2eXV4ZVZ8wce+Uk6pVumE=; b=dCL1nq3mNLILmQJCJzYpkeBokcE+N5gwwWsKsVqovNxqY0OS5Uai2zfUGyK+mv44bd /42fwZcpX6vvFX/W8X5tGWCGoknwtffGfkf1P3oALTo4aZrpSgfylbkuwhbfxkFZn4Ru e7zolhMvDWjZEEomWEDQ//s9gPaKMtrOFW7ChAHrEWkSZWm0F3+/u3jsERxZxycrxFpC J1ix/meXjsqHlGhQdOhuQALk4NDHX5qKCz6YBJ5tSxx+v527D/MeKetdjLgzyzJPbFLB plsic8ZigcE2nSOx/C9rqWcxzVgBZKD0gfA81d4KsMPxoXNxL7Pdk0IXwAqqQ24Ddp77 GI8Q== MIME-Version: 1.0 Received: by 10.182.197.73 with SMTP id is9mr2040441obc.32.1348166655005; Thu, 20 Sep 2012 11:44:15 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 11:44:14 -0700 (PDT) In-Reply-To: <505B5C7B.1010005@gmx.de> References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> Date: Thu, 20 Sep 2012 14:44:14 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=14dae9399cad91d5f904ca268215 Cc: Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:44:16 -0000 --14dae9399cad91d5f904ca268215 Content-Type: text/plain; charset=ISO-8859-1 The issue here that the RFC seems to hint at (the language is next to meaningless) is that JSON does not provide the types of integrity checking that should be used if you are using it to wrap something like SQL commands or other data to be passed to a scripting language. There are encodings that are explicitly designed to make that type of use safe and there are ways of applying JSON that can make it safe but JSON does not provide an automatic check. If that is not the issue that the SC section is trying to explain then lets have someone else try to explain what the SC in the media type registration means. On Thu, Sep 20, 2012 at 2:12 PM, Julian Reschke wrote: > On 2012-09-20 20:05, Phillip Hallam-Baker wrote: > >> I think the real problem with the vague references to 'code' in the JSON >> RFC is that they mean absolutely nothing. I am not sure that they even >> bear mention. >> ... >> > > RFC 4627 doesn't mention "code" in the sense of programming code at all. > > The real problem with interpreted languages is that they make it easy to >> mix the control and data channel which is of course what makes code >> injection attacks possible. SQL mixes the two in convoluted ways. >> >> >> What the security statement needs to say than is that encoders need to >> ensure that strings are appropriately escaped in all cases and that code >> does not simply do things like >> >> printf ("{ \"tag\" : \"%0\" }", foo); >> >> It has to be >> >> printf ("{ \"tag\" : \"%0\" }", StringPrep (foo)); >> >> >> I think that is the problem the language is hinting at but failing to >> make clear. >> ... >> > > I think that security considerations for *recipients* are much more > important; and guess what, RFC 4627 has some. > > It's nice if senders are not vulnerable to code injection, but if > recipients parse JSON as JSON, they are by definition not vulnerable. > > If people use JSON to carry data that is SQL commands, shell commands or >> similar then these issues are going to be security considerations. >> >> >> That is why the types of encoding we prefer in a security sensitive >> application tend to use either an explicit length encoding (ASN.1 >> approach) or randomized guard values or both. >> ... >> > > That's all very interesting, but how does that affect JSON? > > I would recommend that anybody who wants something specifically changed in > RFC 4627 first checks whether it might there already (me guilty of that as > well (*)), and then makes a *concrete* proposal. > > Best regards, Julian > > (*) RFC 4627 explains how to use a regexp to validate that a given octet > sequence is safe to be passed to JS eval(). > -- Website: http://hallambaker.com/ --14dae9399cad91d5f904ca268215 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The issue here that the RFC seems to hint at (the language is next to meani= ngless) is that JSON does not provide the types of integrity checking that = should be used if you are using it to wrap something like SQL commands or o= ther data to be passed to a scripting language.

    There are encodings that are explicitly designed to make tha= t type of use safe and there are ways of applying JSON that can make it saf= e but JSON does not provide an automatic check.=A0


    If that is not the issue that the SC section is trying to ex= plain then lets have someone else try to explain what the SC in the media t= ype registration means.


    On Thu, Sep 20, 2012 at 2:12 PM, Julian Reschke <julian.reschke@gmx.de= > wrote:
    On 2012-09-20 20:05, Phillip Hallam-Baker wrote:
    I think the real problem with the vague references to 'code' in the= JSON
    RFC is that they mean absolutely nothing. I am not sure that they even
    bear mention.
    ...

    RFC 4627 doesn't mention "code" in the sense of programming c= ode at all.

    The real problem with interpreted languages is that they make it easy to mix the control and data channel which is of course what makes code
    injection attacks possible. SQL mixes the two in convoluted ways.


    What the security statement needs to say than is that encoders need to
    ensure that strings are appropriately escaped in all cases and that code does not simply do things like

    printf ("{ \"tag\" : \"%0\" }", foo);

    It has to be

    printf ("{ \"tag\" : \"%0\" }", StringPrep (f= oo));


    I think that is the problem the language is hinting at but failing to
    make clear.
    ...

    I think that security considerations for *recipients* are much more importa= nt; and guess what, RFC 4627 has some.

    It's nice if senders are not vulnerable to code injection, but if recip= ients parse JSON as JSON, they are by definition not vulnerable.

    If people use JSON to carry data that is SQL commands, shell commands or similar then these issues are going to be security considerations.


    That is why the types of encoding we prefer in a security sensitive
    application tend to use either an explicit length encoding (ASN.1
    approach) or randomized guard values or both.
    ...

    That's all very interesting, but how does that affect JSON?

    I would recommend that anybody who wants something specifically changed in = RFC 4627 first checks whether it might there already (me guilty of that as = well (*)), and then makes a *concrete* proposal.

    Best regards, Julian

    (*) RFC 4627 explains how to use a regexp to validate that a given octet se= quence is safe to be passed to JS eval().



    --
    Website: http://hallambaker.com/

    --14dae9399cad91d5f904ca268215-- From julian.reschke@gmx.de Thu Sep 20 11:46:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65B521E8084 for ; Thu, 20 Sep 2012 11:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.024 X-Spam-Level: X-Spam-Status: No, score=-104.024 tagged_above=-999 required=5 tests=[AWL=-1.425, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWo8taXuZOoF for ; Thu, 20 Sep 2012 11:46:01 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id CCC7421E8039 for ; Thu, 20 Sep 2012 11:46:00 -0700 (PDT) Received: (qmail invoked by alias); 20 Sep 2012 18:45:59 -0000 Received: from p5DD95893.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.88.147] by mail.gmx.net (mp041) with SMTP; 20 Sep 2012 20:45:59 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+os7tissioG6N+AwjYjJ3dfzV20KnY8Zmmwwd4Tr dAd90EGL7MYscS Message-ID: <505B6464.30908@gmx.de> Date: Thu, 20 Sep 2012 20:45:56 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> <505B585D.3050401@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:46:01 -0000 On 2012-09-20 20:38, Phillip Hallam-Baker wrote: > > > On Thu, Sep 20, 2012 at 1:54 PM, Julian Reschke > wrote: > > On 2012-09-20 19:47, Phillip Hallam-Baker wrote: > > ... > ... > > - Do not use multiple syntaxes for the same protocol. Pick > one of > XML or JSON and stick with it. > > > Agree but note that this conflicts with the REST notion of using URL > encoded requests and JSON responses. Which I think is yucky but some > insist on. > ... > > > Where does that notion come from? I don't see what this has to with > being restful or not (there, I said it; I'll probably regret it :-). > > > I asked Roy Fielding that and he gave me much the same answer. > > But I am going to have to implement that to use my compiler to do OAUTH > and specs already using that style. > https://tools.ietf.org/html/draft-ietf-oauth-v2-30 > ... You may or may not enjoy reading . Best regards, Julian From andy@hxr.us Thu Sep 20 11:58:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A134C21F870A for ; Thu, 20 Sep 2012 11:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OIS2DFFj7f6 for ; Thu, 20 Sep 2012 11:58:39 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 218F221F860B for ; Thu, 20 Sep 2012 11:58:38 -0700 (PDT) Received: by lboj14 with SMTP id j14so2580449lbo.31 for ; Thu, 20 Sep 2012 11:58:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=NgED0iUU4l2vgFd5TEzjFQ6Q9QelpP4qcpl5fZR5pyI=; b=iTPg6fwyvr6+f3xvHQnLWGNV6xz0UBhSgVwZFfYgL3patHFbUFyQtzqWPqxhBi6qjH wX2pcYtX0eXEtidqNKOQZo6mEl46/MfFsp5cIMv5d3VCpWbfrz9SXjivinivAyOp6vlM j+mMTB5KAUTtYoauleBLuZDE4OKiYn/Shaz5WJUloE0JxwaK80cCYK3ClT/lBcb5pm1j Je0TzhQ0+p2Zil1FSS7kXnKYfqWU/SLHy+rYZ645O0PVKJTa1DWT+/38oj7fKs+/Fumq 4FkCdu1Mntq67y0oT8Z1AvtxVmOjF7hjD/EmZZbd7Xhcm1ABDfvGH8Kabmd14Gvc8y0P e9pw== MIME-Version: 1.0 Received: by 10.112.102.68 with SMTP id fm4mr953758lbb.19.1348167518021; Thu, 20 Sep 2012 11:58:38 -0700 (PDT) Received: by 10.112.7.67 with HTTP; Thu, 20 Sep 2012 11:58:38 -0700 (PDT) X-Originating-IP: [2001:500:4:15:f53f:d67e:556a:1da5] Date: Thu, 20 Sep 2012 14:58:38 -0400 Message-ID: From: Andrew Newton To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm8g0Of1mUmZDu4y5vSXLNuH9Xwy8NxWuqiK6Gh37RmL75iyxgwnCVloDA3C2UmJ+PSiibJ Subject: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:58:40 -0000 All, Since the topics of JSON Schema and schema languages in general are being debated here, I thought I'd go ahead and publish a draft idea I had for formalizing expected JSON structures. The draft is here: http://www.ietf.org/id/draft-newton-json-content-rules-00.txt While the notion that this is better (or worse) than JSON Schema is subjective, I do think it turns out to be more concise. Also, I think it worth mentioning what the ALTO working group has done. They have a protocol to pass data in JSON, and to describe their JSON structures they have repurposed C struct syntax to describe it. You can find that draft here: http://www.ietf.org/id/draft-ietf-alto-protocol-13.txt While some see no value in schema languages for JSON (or schema languages in general), there does appear to be an interest in methods more formal than prose to describe expected content of JSON data. At the very least, they can provide clarity for protocol specifications. I'll note that while I was working up one of the examples for my draft, I found an error in the prose of another JSON protocol on which I had been working. -andy From mnot@mnot.net Thu Sep 20 13:05:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D1D21E804B for ; Thu, 20 Sep 2012 13:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.377 X-Spam-Level: X-Spam-Status: No, score=-104.377 tagged_above=-999 required=5 tests=[AWL=-1.778, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E26YY3uMfRbO for ; Thu, 20 Sep 2012 13:05:18 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id BD67321E803A for ; Thu, 20 Sep 2012 13:05:18 -0700 (PDT) Received: from [172.30.66.198] (unknown [72.247.151.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D2CC922E25D; Thu, 20 Sep 2012 16:05:11 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Mark Nottingham In-Reply-To: Date: Thu, 20 Sep 2012 13:05:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <77AFECFB-F63A-457F-9C7F-F715315C0651@mnot.net> References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> To: Tim Bray X-Mailer: Apple Mail (2.1498) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 20:05:19 -0000 On 20/09/2012, at 9:53 AM, Tim Bray wrote: > I believe: > - ASN.1 has been bypassed by history and has truly horrible tooling. = Just don=92t go there. > - If you=92re interchanging documents, use XML; if (much more common) = you=92re interchanging data structures, use JSON. > - Do not use multiple syntaxes for the same protocol. Pick one of XML = or JSON and stick with it. > - The most important thing in defining a protocol is good clean = comprehensible human-readable prose. > - All the protocols I=92ve ever seen have important constraints that = can=92t be expressed usefully in declarative schema languages. > - Therefore, the next most important thing is an automated = validator/test-suite. > - A schema is a nice-to-have. > - If you=92re in XML and want schema-ware, use RelaxNG. For an = example, see RFC4287. > - If your protocol is JSON, investment in a validator/test-suite has = much higher ROI than chasing schema unicorns. +1; somebody please give this a BCP#. -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Thu Sep 20 13:10:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6979A21E805F for ; Thu, 20 Sep 2012 13:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.866 X-Spam-Level: X-Spam-Status: No, score=-103.866 tagged_above=-999 required=5 tests=[AWL=-1.267, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOKsaXAIHchy for ; Thu, 20 Sep 2012 13:10:06 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 508AE21E804B for ; Thu, 20 Sep 2012 13:10:00 -0700 (PDT) Received: (qmail invoked by alias); 20 Sep 2012 20:09:58 -0000 Received: from p5DD95893.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.88.147] by mail.gmx.net (mp017) with SMTP; 20 Sep 2012 22:09:58 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+eJtZIbTeeRn6cJ4yl595GqK7T5kiCN/IVRUdrl6 hO6JCx++syCqci Message-ID: <505B7812.30702@gmx.de> Date: Thu, 20 Sep 2012 22:09:54 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 20:10:07 -0000 On 2012-09-20 20:44, Phillip Hallam-Baker wrote: > The issue here that the RFC seems to hint at (the language is next to > meaningless) is that JSON does not provide the types of integrity > checking that should be used if you are using it to wrap something like > SQL commands or other data to be passed to a scripting language. > ... WHICH language? As far as I can tell, the spec describes how to pass names strings, numbers and boolean around. It doesn't care at all what you put into strings (and it shouldn't). > There are encodings that are explicitly designed to make that type of > use safe and there are ways of applying JSON that can make it safe but > JSON does not provide an automatic check. Automatic checks of what? Strings are strings are strings. What do you want to check? > If that is not the issue that the SC section is trying to explain then > lets have someone else try to explain what the SC in the media type > registration means. It says: > Generally there are security issues with scripting languages. JSON > is a subset of JavaScript, but it is a safe subset that excludes > assignment and invocation. That sounds pretty clear to me. > A JSON text can be safely passed into JavaScript's eval() function > (which compiles and executes a string) if all the characters not > enclosed in strings are in the set of characters that form JSON > tokens. This can be quickly determined in JavaScript with two > regular expressions and calls to the test and replace methods. > > var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test( > text.replace(/"(\\.|[^"\\])*"/g, ''))) && > eval('(' + text + ')'); These are instructions how to prevent a a Javascript code injection in case you choose to use the JS eval() function to parse the JSON. Best regards, Julian From dhc@dcrocker.net Thu Sep 20 13:12:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B9821E8056 for ; Thu, 20 Sep 2012 13:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFbpF20C5WGy for ; Thu, 20 Sep 2012 13:12:44 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 19CAE21E804B for ; Thu, 20 Sep 2012 13:12:44 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8KKChBe004057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Sep 2012 13:12:43 -0700 Message-ID: <505B78B4.80309@dcrocker.net> Date: Thu, 20 Sep 2012 13:12:36 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mark Nottingham References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> <77AFECFB-F63A-457F-9C7F-F715315C0651@mnot.net> In-Reply-To: <77AFECFB-F63A-457F-9C7F-F715315C0651@mnot.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 20 Sep 2012 13:12:43 -0700 (PDT) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 20:12:44 -0000 On 9/20/2012 1:05 PM, Mark Nottingham wrote: > > On 20/09/2012, at 9:53 AM, Tim Bray wrote: > >> I believe: >> - ASN.1 has been bypassed by history and has truly horrible tooling. Just dont go there. >> - If youre interchanging documents, use XML; if (much more common) youre interchanging data structures, use JSON. >> - Do not use multiple syntaxes for the same protocol. Pick one of XML or JSON and stick with it. >> - The most important thing in defining a protocol is good clean comprehensible human-readable prose. >> - All the protocols Ive ever seen have important constraints that cant be expressed usefully in declarative schema languages. >> - Therefore, the next most important thing is an automated validator/test-suite. >> - A schema is a nice-to-have. >> - If youre in XML and want schema-ware, use RelaxNG. For an example, see RFC4287. >> - If your protocol is JSON, investment in a validator/test-suite has much higher ROI than chasing schema unicorns. > > +1; somebody please give this a BCP#. In its current form, perhaps not. On the other hand, something along this lines could provide exremely useful pedagogy in doing specifications work. It would, of course, need rather more verbose discussion/justification of its guidance. That is, something that says what the characteristics are of the better formal notation choices are and what the characteristics of the less better ones are. Then describes the better choices and their enticing features, perhaps in terms of tradeoffs. Then meta-points, such as "choose exactly one". Etc. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From tbray@textuality.com Thu Sep 20 13:20:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82E221F84B6 for ; Thu, 20 Sep 2012 13:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkrKhJOoW8Ak for ; Thu, 20 Sep 2012 13:20:28 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7882E21F85EA for ; Thu, 20 Sep 2012 13:20:28 -0700 (PDT) Received: by wibcb5 with SMTP id cb5so772219wib.1 for ; Thu, 20 Sep 2012 13:20:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=DYdLPV9NwJHin8SpjyVrPvCEfE2MIqUC5U2e1YpqK3M=; b=Ny6aK6Q8hPNyy0laK+FdjWyWr4WZvIvSmS6gUIAw03AsJpvoKMFGXU5YsR2BZgQBJq Rn0Q0XlAExCZfX4SkGKnYRM9g2hfbz+zu0J01+D8cuNx+xf136+XdM0YxWWHumJuUpbi j8PcycJAKt6r9IdlsmutZAGPUO2roAAgi8MyoUxU8Ba7IkJDnvePvSDwkmgmSR8PfqEj YFsqqTbDRVg4Y+/KkffGb3A8mJ9J85aWeE4vgkeuV82I5/N2dSmsYF7wW1o18jV6Rvjh iiWiSyCP7sH8gIGdQydRIXEpoT/vxR7fRwB9W+arNTun2vfUpBBYn/uMek7ZOccT2DL1 b4aA== MIME-Version: 1.0 Received: by 10.216.23.202 with SMTP id v52mr1674520wev.32.1348172427397; Thu, 20 Sep 2012 13:20:27 -0700 (PDT) Received: by 10.195.13.200 with HTTP; Thu, 20 Sep 2012 13:20:27 -0700 (PDT) X-Originating-IP: [24.84.208.217] In-Reply-To: <505B78B4.80309@dcrocker.net> References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> <77AFECFB-F63A-457F-9C7F-F715315C0651@mnot.net> <505B78B4.80309@dcrocker.net> Date: Thu, 20 Sep 2012 13:20:27 -0700 Message-ID: From: Tim Bray To: dcrocker@bbiw.net Content-Type: multipart/alternative; boundary=0016367f9838a18a6804ca27daf9 X-Gm-Message-State: ALoCoQnBh/bHO/QZIjtns000CzA7qeNcEv+tM9E2wVtap6FcneFBqYGxCHrGQTcCkRvdDum3WcNp Cc: Mark Nottingham , apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 20:20:29 -0000 --0016367f9838a18a6804ca27daf9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Frankly that notion had never crossed my mind, but is there a case for a =93Tao of network protocols=94 or an =93Informational BCP=94 or some such? = I could put some cycles into it. -T On Thu, Sep 20, 2012 at 1:12 PM, Dave Crocker wrote: > > > On 9/20/2012 1:05 PM, Mark Nottingham wrote: > >> >> On 20/09/2012, at 9:53 AM, Tim Bray wrote: >> >> I believe: >>> - ASN.1 has been bypassed by history and has truly horrible tooling. >>> Just don=92t go there. >>> - If you=92re interchanging documents, use XML; if (much more common) >>> you=92re interchanging data structures, use JSON. >>> - Do not use multiple syntaxes for the same protocol. Pick one of XML o= r >>> JSON and stick with it. >>> - The most important thing in defining a protocol is good clean >>> comprehensible human-readable prose. >>> - All the protocols I=92ve ever seen have important constraints that ca= n=92t >>> be expressed usefully in declarative schema languages. >>> - Therefore, the next most important thing is an automated >>> validator/test-suite. >>> - A schema is a nice-to-have. >>> - If you=92re in XML and want schema-ware, use RelaxNG. For an example, >>> see RFC4287. >>> - If your protocol is JSON, investment in a validator/test-suite has >>> much higher ROI than chasing schema unicorns. >>> >> >> +1; somebody please give this a BCP#. >> > > > In its current form, perhaps not. > > On the other hand, something along this lines could provide exremely > useful pedagogy in doing specifications work. > > It would, of course, need rather more verbose discussion/justification of > its guidance. > > That is, something that says what the characteristics are of the better > formal notation choices are and what the characteristics of the less bett= er > ones are. Then describes the better choices and their enticing features, > perhaps in terms of tradeoffs. > > Then meta-points, such as "choose exactly one". Etc. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --0016367f9838a18a6804ca27daf9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Frankly that notion had never crossed my mind, but is there a case for a = =93Tao of network protocols=94 or an =93Informational BCP=94 or some such?= =A0 I could put some cycles into it.=A0 -T

    On Thu, Sep 20, 2012 at 1:12 PM, Dave Crocker <dhc@dcrocker.net> wrote:


    On 9/20/2012 1:05 PM, Mark Nottingham wrote:

    On 20/09/2012, at 9:53 AM, Tim Bray <tbray@textuality.com> wrote:

    I believe:
    - ASN.1 has been bypassed by history and has truly horrible tooling. Just d= on=92t go there.
    - If you=92re interchanging documents, use XML; if (much more common) you= =92re interchanging data structures, use JSON.
    - Do not use multiple syntaxes for the same protocol. Pick one of XML or JS= ON and stick with it.
    - The most important thing in defining a protocol is good clean comprehensi= ble human-readable prose.
    - All the protocols I=92ve ever seen have important constraints that can=92= t be expressed usefully in declarative schema languages.
    - Therefore, the next most important thing is an automated validator/test-s= uite.
    - A schema is a nice-to-have.
    - If you=92re in XML and want schema-ware, use RelaxNG. For an example, see= RFC4287.
    - If your protocol is JSON, investment in a validator/test-suite has much h= igher ROI than chasing schema unicorns.

    +1; somebody please give this a BCP#.


    In its current form, perhaps not.

    On the other hand, something along this lines could provide exremely useful= pedagogy in doing specifications work.

    It would, of course, need rather more verbose discussion/justification of i= ts guidance.

    That is, something that says what the characteristics are of the better for= mal notation choices are and what the characteristics of the less better on= es are. =A0Then describes the better choices and their enticing features, p= erhaps in terms of tradeoffs.

    Then meta-points, such as "choose exactly one". =A0Etc.

    d/

    --
    =A0Dave Crocker
    =A0Brandenburg InternetWorking
    =A0bbiw.net

    --0016367f9838a18a6804ca27daf9-- From dcrocker@bbiw.net Thu Sep 20 13:25:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066EA21E803A for ; Thu, 20 Sep 2012 13:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsHQQDHnaMl0 for ; Thu, 20 Sep 2012 13:25:02 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6815321F8648 for ; Thu, 20 Sep 2012 13:25:02 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8KKP1dn004244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Sep 2012 13:25:01 -0700 Message-ID: <505B7B96.2010808@bbiw.net> Date: Thu, 20 Sep 2012 13:24:54 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Tim Bray References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> <77AFECFB-F63A-457F-9C7F-F715315C0651@mnot.net> <505B78B4.80309@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 20 Sep 2012 13:25:02 -0700 (PDT) Cc: Mark Nottingham , apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 20:25:03 -0000 On 9/20/2012 1:20 PM, Tim Bray wrote:> Frankly that notion had never crossed my mind, but is there a case for a > Tao of network protocols or an Informational BCP or some such? I > could put some cycles into it. -T That's a book, not a BCP. I was suggesting a small-but-useful subset, which I thought was nicely exemplified by the terse list of practical direction of the precipitating note about choosing a notation language. Very narrow topic. Very important. Often very religious and very confused. Just the stuff of a BCP, IMO... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hallam@gmail.com Thu Sep 20 13:35:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D95B21E8056 for ; Thu, 20 Sep 2012 13:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGuQFYl2oybN for ; Thu, 20 Sep 2012 13:35:28 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB6421E803A for ; Thu, 20 Sep 2012 13:35:28 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2881795obb.31 for ; Thu, 20 Sep 2012 13:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7qV1REzpTl5K8XgTzMUMQMRxgO0x3iTtOkDbZ4ZGcpM=; b=OwgF9PvPE4b73JUefzbggXZ7llBs1H4CF6ypllEoHvGKIiv3twvTwPpGJxpKOIVxM8 87YxzLKJhjiLol727j5+/JZBL4bEafmR36GHQ3sy3hF/eKUxf4zZ3dMfoiJZEb3expEd uFoUcc1YRgjXTk0AM3q4xXDrhI9FcQScPQSIh/HUEX/WbsS48TRYqc6VFF0CPDI4J7DC gV3XgjlWNvrJsL+m7A3qVML2O5BXja3670LxgVIIJfHCU5oc47JoOzPPd3JUi/6Ewkjn FtUuFVah482jB4AYGhbO6Y0TVDQfik226BCBuOZ9pwsfZ0dWAZszQN7vlawyUxPgRm/B T4Ww== MIME-Version: 1.0 Received: by 10.60.172.236 with SMTP id bf12mr2243298oec.23.1348173328004; Thu, 20 Sep 2012 13:35:28 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 13:35:27 -0700 (PDT) In-Reply-To: <505B7B96.2010808@bbiw.net> References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> <77AFECFB-F63A-457F-9C7F-F715315C0651@mnot.net> <505B78B4.80309@dcrocker.net> <505B7B96.2010808@bbiw.net> Date: Thu, 20 Sep 2012 16:35:27 -0400 Message-ID: From: Phillip Hallam-Baker To: Dave Crocker Content-Type: multipart/alternative; boundary=bcaec54d47684fb4ff04ca281008 Cc: Mark Nottingham , apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 20:35:29 -0000 --bcaec54d47684fb4ff04ca281008 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My plan was to give people a tool that had the BCP encoded into its DNA... On Thu, Sep 20, 2012 at 4:24 PM, Dave Crocker wrote: > > On 9/20/2012 1:20 PM, Tim Bray wrote:> Frankly that notion had never > crossed my mind, but is there a case for a > > > =93Tao of network protocols=94 or an =93Informational BCP=94 or some su= ch? I > > could put some cycles into it. -T > > > That's a book, not a BCP. > > I was suggesting a small-but-useful subset, which I thought was nicely > exemplified by the terse list of practical direction of the precipitating > note about choosing a notation language. > > Very narrow topic. Very important. Often very religious and very > confused. > > Just the stuff of a BCP, IMO... > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --=20 Website: http://hallambaker.com/ --bcaec54d47684fb4ff04ca281008 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My plan was to give people a tool that had the BCP encoded into its DNA...<= div>

    On Thu, Sep 20, 2012 at 4:24 PM= , Dave Crocker <dcrocker@bbiw.net> wrote:

    On 9/20/2012 1:20 PM, Tim Bray wrote:> Frankly that notion had never cro= ssed my mind, but is there a case for a

    > =93Tao of network protocols=94 or an =93Informational BCP=94 or some s= uch? =A0I
    > could put some cycles into it. =A0-T


    That's a book, not a BCP.

    I was suggesting a small-but-useful subset, which I thought was nicely exem= plified by the terse list of practical direction of the precipitating note = about choosing a notation language.

    Very narrow topic. =A0Very important. =A0Often very religious and very conf= used.

    Just the stuff of a BCP, IMO...


    d/

    --
    =A0Dave Crocker
    =A0Brandenburg InternetWorking
    =A0bbiw.net
    _______________________________________________
    apps-discuss mailing list
    apps-discuss@iet= f.org
    https://www.ietf.org/mailman/listinfo/apps-discuss



    --
    = Website: http://hallambaker.com/
    --bcaec54d47684fb4ff04ca281008-- From sm@resistor.net Thu Sep 20 13:52:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE8821E805F; Thu, 20 Sep 2012 13:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87nOn8CRpCiC; Thu, 20 Sep 2012 13:52:34 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9331321E803A; Thu, 20 Sep 2012 13:52:34 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8KKqSNn016508; Thu, 20 Sep 2012 13:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1348174353; bh=vBN6T6tn3UBzQ7i13Y3y472HRcjcr/K/xrsMMnwv7bo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=V88/r051ca6etoJiydkgGW4cXxZkMQ4odTufetBubNs/RTqcYpUNUqiAhF/tm+zXU c9GiN95uNygcsCvxpXlYu8oVyDJOo9C4duTio/OPXdZDXp9ufX6CHRBYweevG4bpyk RhU7NOgEoNUSywrjQEHJNebMR0yYtMeq6lnGqmRc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1348174353; i=@resistor.net; bh=vBN6T6tn3UBzQ7i13Y3y472HRcjcr/K/xrsMMnwv7bo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ACC5/0w48NHVm7VhVC3QjarYA8/6KmtBgeiJ1Gt9ZB0EZo7uqUSGdxXgc64EVD2dT Ogd5l+ZHROLMJ4V8dPGFE+TM+ZEyL7DfL/9hwE5SphTBPG7npw0AtiyKl2Krj05cI1 OW3CY9n8xUVhMohmzlcOE1MLb/+j/uYruS/Z8DlA= Message-Id: <6.2.5.6.2.20120920132829.0a17be88@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 20 Sep 2012 13:51:05 -0700 To: Tim Bray From: SM In-Reply-To: References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iab@iab.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 20:52:35 -0000 Hi Tim, [Cc to IAB. Please drop it if the thread is willfully wild.] At 09:53 20-09-2012, Tim Bray wrote: >I gave a preso at IETF70 in Vancouver a few years ago which is >advertised as being XML-centric, but has (I think) useful things to >say about plain-text/binary/ASN.1/JSON/XML, and discusses about the >proper place of schemas: http://www.ietf.org/proceedings/70/slides/xmltut-0.pdf I found the presentation informative. >I believe: >- ASN.1 has been bypassed by history and has truly horrible tooling. >Just don't go there. >- If you're interchanging documents, use XML; if (much more common) >you're interchanging data structures, use JSON. >- Do not use multiple syntaxes for the same protocol. Pick one of >XML or JSON and stick with it. >- The most important thing in defining a protocol is good clean >comprehensible human-readable prose. >- All the protocols I've ever seen have important constraints that >can't be expressed usefully in declarative schema languages. >- Therefore, the next most important thing is an automated >validator/test-suite. >- A schema is a nice-to-have. >- If you're in XML and want schema-ware, use RelaxNG. For an >example, see RFC4287. >- If your protocol is JSON, investment in a validator/test-suite has >much higher ROI than chasing schema unicorns. It might help to have a discussion of the above as part of an IAB document. Regards, -sm From fgaliegue@gmail.com Thu Sep 20 13:54:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6D721E803A for ; Thu, 20 Sep 2012 13:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.63 X-Spam-Level: X-Spam-Status: No, score=-3.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4o2I85zFWxF for ; Thu, 20 Sep 2012 13:54:45 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3497E21E805F for ; Thu, 20 Sep 2012 13:54:45 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so3355670vcb.31 for ; Thu, 20 Sep 2012 13:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Mlgfm6SMsQPym+L2IQcx6CZGb1aR2xP3PTO1XgGmG7w=; b=gi9TKNxa/AseCezoWCG6l+5HneMxasPu4rgysm+kPW9zpxd3n72Hh1z6Nx0t1YAZYX iC0Wb+6RG1MIdPZCfkd57iMtnWtmD1A/x2BPEMJASluh5I2fU2GsxJlhJbFj08lCiw9J xAnq4bQvCmrnHHVS3SwKs1Ird+kyXCQxBvmGgknVRlgarHJgq9bChuaNK6a8uB6jtmmC QlHDSrxzJJPOt87uLbBD1Fh3qhciGN01XoWSvyTCqWBSwYx1B2z/flzNvbcsDMz4dySA szsusxzWmZNA7podB5u5gMMDuoz2lHvhFE8UUJKcCsAoICIn/c7zGYW/9Kpxm/hHMC0I chfA== MIME-Version: 1.0 Received: by 10.52.64.209 with SMTP id q17mr1444328vds.32.1348174484734; Thu, 20 Sep 2012 13:54:44 -0700 (PDT) Received: by 10.52.72.137 with HTTP; Thu, 20 Sep 2012 13:54:44 -0700 (PDT) In-Reply-To: <505B7B96.2010808@bbiw.net> References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> <77AFECFB-F63A-457F-9C7F-F715315C0651@mnot.net> <505B78B4.80309@dcrocker.net> <505B7B96.2010808@bbiw.net> Date: Thu, 20 Sep 2012 22:54:44 +0200 Message-ID: From: Francis Galiegue To: Dave Crocker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Nottingham , apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 20:54:46 -0000 On Thu, Sep 20, 2012 at 10:24 PM, Dave Crocker wrote: [...] > > I was suggesting a small-but-useful subset, which I thought was nicely > exemplified by the terse list of practical direction of the precipitating > note about choosing a notation language. > > Very narrow topic. Very important. Often very religious and very confus= ed. > > Just the stuff of a BCP, IMO... > I-D 3 of JSON Schema has it: a "small-but-useful subset", which can be used to describe _any_ JSON value. It has sufficient intrinsic value that it is being used, for instance, by the Google discovery API. However, there was room for improvement. In particular, the fact that the core schema keywords were not fully defined, and also section 5.27 which has been a constant source of misinterpretation. And the fact that some "untold", but important stuff, was lurking behind. And this is precisely the goal that this ad-hoc organization "of no value" is pursuing, and why it takes time. But XSD is at best a goal NOT to pursue. And yes, all keywords are meant to define the _structure_ of JSON data anyway. Semantic validation keywords exist, but the goal is to make them optional. In any case, I-Ds will be submitted via the official mechanism. Some refining is needed before that. --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From ned.freed@mrochek.com Thu Sep 20 13:56:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD2A21F865F for ; Thu, 20 Sep 2012 13:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdnvA2ZCOJ1D for ; Thu, 20 Sep 2012 13:56:18 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0D73021F865D for ; Thu, 20 Sep 2012 13:56:18 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKHBUA088G001GVW@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 20 Sep 2012 13:51:15 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Thu, 20 Sep 2012 13:51:12 -0700 (PDT) Message-id: <01OKHBU81QWO0006TF@mauve.mrochek.com> Date: Thu, 20 Sep 2012 13:45:18 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 20 Sep 2012 19:57:54 +0200" <505B5922.5020704@gmx.de> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> To: Julian Reschke Cc: Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 20:56:18 -0000 > On 2012-09-20 19:18, Ned Freed wrote: > > ... > > Errr, right. Are you saying JSON involves active or executable content? > > > > It most definitely can and in practice is used that way. And that possibility > > also need to be mentioned. > > ... > But that's not JSON; it's just something that remotely looks like it. A while back we wrote an RFC explaining how to represent the Sieve mail filtering langauge in XML. At that time someone told me they had done the same thing using JSON. Syntactically this absolutely was JSON, but semantically it was Sieve, an executable language. Now, maybe to you that's not JSON but rather "something that remotely looks like it". But to me it most definitely *is* JSON, because abstract JSON without some attached semantics is both meaningless and useless. This is what I mean when I call JSON a container format. And there is long established precedent for describing both the security considerations inherent in the abstract format as well as those that are likely to arise when semantics are attached. > I have nothing against warning people to *always* use strict JSON > parsers (not JS eval) to process JSON, but we should be clear about > what's JSON and what is not. Well, if you're talking about having to violate syntax rules in order for executable semantics to attach, then I'm afraid you're talking nonsense. Ned From julian.reschke@gmx.de Thu Sep 20 14:09:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53B021F864D for ; Thu, 20 Sep 2012 14:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.739 X-Spam-Level: X-Spam-Status: No, score=-103.739 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkrC-qiHAywL for ; Thu, 20 Sep 2012 14:09:03 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id DAF3D21E803A for ; Thu, 20 Sep 2012 14:09:02 -0700 (PDT) Received: (qmail invoked by alias); 20 Sep 2012 21:09:02 -0000 Received: from p5DD95893.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.88.147] by mail.gmx.net (mp037) with SMTP; 20 Sep 2012 23:09:02 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19KT6JdJaFKEwS29TetzEeKxf66ciZUg6TFIx7MUy FddaR/OdNxlih4 Message-ID: <505B85EA.2080901@gmx.de> Date: Thu, 20 Sep 2012 23:08:58 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ned Freed References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <01OKHBU81QWO0006TF@mauve.mrochek.com> In-Reply-To: <01OKHBU81QWO0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 21:09:03 -0000 On 2012-09-20 22:45, Ned Freed wrote: >> On 2012-09-20 19:18, Ned Freed wrote: >> > ... >> > Errr, right. Are you saying JSON involves active or executable >> content? >> > >> > It most definitely can and in practice is used that way. And that >> possibility >> > also need to be mentioned. >> > ... > >> But that's not JSON; it's just something that remotely looks like it. > > A while back we wrote an RFC explaining how to represent the Sieve mail > filtering langauge in XML. At that time someone told me they had done > the same > thing using JSON. Syntactically this absolutely was JSON, but > semantically it > was Sieve, an executable language. > Now, maybe to you that's not JSON but rather "something that remotely looks > like it". But to me it most definitely *is* JSON, because abstract JSON > without > some attached semantics is both meaningless and useless. > > This is what I mean when I call JSON a container format. And there is long > established precedent for describing both the security considerations > inherent > in the abstract format as well as those that are likely to arise when > semantics > are attached. >> I have nothing against warning people to *always* use strict JSON >> parsers (not JS eval) to process JSON, but we should be clear about >> what's JSON and what is not. > > Well, if you're talking about having to violate syntax rules in order for > executable semantics to attach, then I'm afraid you're talking nonsense. Depends on the layer we look at. To make JSON code executable as JavaScript *code*, you need to violate the JSON syntax. Of course you can define uses of JSON (or text/plain, or text/xml, or ...) that have executable semantics on a different layer, but that's not what I was referring to. Best regards, Julian From hallam@gmail.com Thu Sep 20 14:23:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46DC21E809C for ; Thu, 20 Sep 2012 14:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.944 X-Spam-Level: X-Spam-Status: No, score=-3.944 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiI-oioYzEHP for ; Thu, 20 Sep 2012 14:23:01 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A2ABB21E805F for ; Thu, 20 Sep 2012 14:23:01 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2929893obb.31 for ; Thu, 20 Sep 2012 14:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jut25+MKW+y6A3b1rKl14XR2RVxid/DuGzULkyK2C1o=; b=QKa76IIOtzjEi2sODSouAk9V2SLwwSK8icS7TQxEq7JX3jwvOEQ3QMV/RInUqKQ4ax 6x8aqzZnyo9Q09uUM2E+kFDPoc3NVoLTyHVi5DbNqJcbg5sxmmOVWlawqmAMVVFRqFOA JaaRNB89gM2Q07J363KArvpX4b5AhwwIQGxQvNYHso4NsFZ60i9Bu0IFFkuKpIClBKVL +MJALOuAvfS81Bf4vyF/HwtOgg+8POJtnEsIIjJbXhRlvFPXW+KWk7a2ct/pOosJM7tj KwaFb/4HjDGQZBmSX//qTQ2dvA1zjLrRYO8tIASXEiJp6n2zCme2cPsRopLys+HXRllN Db8g== MIME-Version: 1.0 Received: by 10.60.29.72 with SMTP id i8mr2317466oeh.26.1348176177976; Thu, 20 Sep 2012 14:22:57 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 14:22:57 -0700 (PDT) In-Reply-To: <505B7812.30702@gmx.de> References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> Date: Thu, 20 Sep 2012 17:22:57 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=e89a8fb1f8062ed4c704ca28ba3f Cc: Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 21:23:03 -0000 --e89a8fb1f8062ed4c704ca28ba3f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 20, 2012 at 4:09 PM, Julian Reschke wrote: > On 2012-09-20 20:44, Phillip Hallam-Baker wrote: > >> The issue here that the RFC seems to hint at (the language is next to >> meaningless) is that JSON does not provide the types of integrity >> checking that should be used if you are using it to wrap something like >> SQL commands or other data to be passed to a scripting language. >> ... >> > > WHICH language? > Well the spec seems to have an assumption that the JSON data is being consumed by a JavaScript implementation (and I say seems because it is clear as mud). I would have to actually want to understand JavaScript to understand the point it tries to make. That is not exactly appropriate for an SC section (to put it mildly). This is one instance of code/data conflation which is the principal mechanism for attacking Web Services. Come to that it is the main method of attack on any system since the attackers usual objective is to execute code. The security of JSON depends on the encoder properly escaping strings. If this is not done an attacker can do an injection attack so code that thinks it is producing messages like the following: { "user" : "alice" } Can be tricked into producing a message like the following: { "user" : "alice", "privs" : "admin" } What the user did to create that was to set their username to the string There are encodings in use that are specifically designed to avoid that particular issue. ASN.1 does not have that problem as the data fields are length delimited rather than relying on escaping which is rather safer. Another way to avoid them as issues is to use a schema and a compiler to manage the mapping from one to another. The main reason I might want to use something other than JSON as a data encoding would probably be to achieve better efficiency or to ensure that issues like this are excluded in a systematic fashion. -- Website: http://hallambaker.com/ --e89a8fb1f8062ed4c704ca28ba3f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Thu, Sep 20, 2012 at 4:09 PM, Julian = Reschke <julian.reschke@gmx.de> wrote:
    On 2012-09-20 20:44, Phillip Hallam-Baker wrote:
    The issue here that the RFC seems to hint at (the language is next to
    meaningless) is that JSON does not provide the types of integrity
    checking that should be used if you are using it to wrap something like
    SQL commands or other data to be passed to a scripting language.
    ...

    WHICH language?

    Well the spec seems to = have an assumption that the JSON data is being consumed by a JavaScript imp= lementation (and I say seems because it is clear as mud).

    I would have to actually want to understand JavaScript to unders= tand the point it tries to make. That is not exactly appropriate for an SC = section (to put it mildly).

    This is one instance o= f code/data conflation which is the principal mechanism for attacking Web S= ervices. Come to that it is the main method of attack on any system since t= he attackers usual objective is to execute code.


    The security of JSON depends on the enco= der properly escaping strings. If this is not done an attacker can do an in= jection attack so code that thinks it is producing messages like the follow= ing:

    { "user" : "alice" }

    =
    Can be tricked into producing a message like the following:

    { "user" : "alice", "privs&qu= ot; : "admin" }

    What the user did to create that was to set their usern= ame to the string <alice", "privs" : "admin>


    There are encodings in use that are spe= cifically designed to avoid that particular issue. ASN.1 does not have that= problem as the data fields are length delimited rather than relying on esc= aping which is rather safer. Another way to avoid them as issues is to use = a schema and a compiler to manage the mapping from one to another.

    The main reason I might want to use something oth= er than JSON as a data encoding would probably be to achieve better efficie= ncy or to ensure that issues like this are excluded in a systematic fashion= .


    --
    Website: http://hallambaker.com/

    --e89a8fb1f8062ed4c704ca28ba3f-- From julian.reschke@gmx.de Thu Sep 20 14:33:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058E421F847C for ; Thu, 20 Sep 2012 14:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.635 X-Spam-Level: X-Spam-Status: No, score=-103.635 tagged_above=-999 required=5 tests=[AWL=-1.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmjUDBzi8WS0 for ; Thu, 20 Sep 2012 14:33:17 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B032921F8476 for ; Thu, 20 Sep 2012 14:33:16 -0700 (PDT) Received: (qmail invoked by alias); 20 Sep 2012 21:33:15 -0000 Received: from p5DD957E3.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.87.227] by mail.gmx.net (mp016) with SMTP; 20 Sep 2012 23:33:15 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/y5FUGdrDyXIF+fJwfEw5sUtB/3HB9126vrTeaVT tKA4H0G8ZObvPd Message-ID: <505B8B97.1080906@gmx.de> Date: Thu, 20 Sep 2012 23:33:11 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 21:33:18 -0000 On 2012-09-20 23:22, Phillip Hallam-Baker wrote: > > > On Thu, Sep 20, 2012 at 4:09 PM, Julian Reschke > wrote: > > On 2012-09-20 20:44, Phillip Hallam-Baker wrote: > > The issue here that the RFC seems to hint at (the language is > next to > meaningless) is that JSON does not provide the types of integrity > checking that should be used if you are using it to wrap > something like > SQL commands or other data to be passed to a scripting language. > ... > > > WHICH language? > > > Well the spec seems to have an assumption that the JSON data is being > consumed by a JavaScript implementation (and I say seems because it is > clear as mud). > > I would have to actually want to understand JavaScript to understand the > point it tries to make. That is not exactly appropriate for an SC > section (to put it mildly). > > This is one instance of code/data conflation which is the principal > mechanism for attacking Web Services. Come to that it is the main method > of attack on any system since the attackers usual objective is to > execute code. > > > The security of JSON depends on the encoder properly escaping strings. > If this is not done an attacker can do an injection attack so code that > thinks it is producing messages like the following: > > { "user" : "alice" } > > Can be tricked into producing a message like the following: > > { "user" : "alice", "privs" : "admin" } > > What the user did to create that was to set their username to the string > > > > There are encodings in use that are specifically designed to avoid that > particular issue. ASN.1 does not have that problem as the data fields > are length delimited rather than relying on escaping which is rather > safer. Another way to avoid them as issues is to use a schema and a > compiler to manage the mapping from one to another. > > The main reason I might want to use something other than JSON as a data > encoding would probably be to achieve better efficiency or to ensure > that issues like this are excluded in a systematic fashion. > ... I still have trouble following. If your have a broken sender, you can get broken messages. That's true for all formats, but I agree that some formats might be easier to exploit. Anyway: if you want the JSONbis RFC to be better, please make a concrete proposal. Best regards, Julian From ned.freed@mrochek.com Thu Sep 20 14:36:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A7021F861F for ; Thu, 20 Sep 2012 14:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bjyqio1Sy8PQ for ; Thu, 20 Sep 2012 14:36:08 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 19E7C21F85E7 for ; Thu, 20 Sep 2012 14:36:08 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKHD8NYZQ800ACQQ@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 20 Sep 2012 14:31:05 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Thu, 20 Sep 2012 14:31:03 -0700 (PDT) Message-id: <01OKHD8M71V80006TF@mauve.mrochek.com> Date: Thu, 20 Sep 2012 13:55:22 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 20 Sep 2012 11:15:28 -0700" <58D58DEF-9606-499A-A51D-935EA69AA2A1@vpnc.org> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <58D58DEF-9606-499A-A51D-935EA69AA2A1@vpnc.org> To: Paul Hoffman Cc: Ned Freed , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 21:36:09 -0000 > On Sep 20, 2012, at 10:18 AM, Ned Freed wrote: > > Given that "code" and "data" are effectively equivalent (thank you von > > Neumann), and given the existence of steaganography, sure, "code", for some > > value of the word, can appear in any format. > I'm glad we agree on that. > > But being able to put code into a > > format doesn't necessarily translate into an injection attack. An injection > > attack occurs during some sort of subsitution operation where the substituted > > material is inadequately checked or quoted. For that to occur there necessarily > > has to be some sort of substitution operation that is a regular part of > > processing the material. > That is a very good definition. > > Given these constraints, it's probably easier to list formats that are > > vulnerable to code injection attacks, but if you insist on specific > > examples, most image formats or even text/plain qualify. > We fully disagree about text/plain, then. Text/plain is often used for > configuration files that are slurped in with inadequate checking. Doesn't change the fact that text/plain is defined as *unformatted* material. So the correct term is "misused", not "used". The problem with label misuse is that the minute you start treating that as not only a serious security concern in and of itself (which of course it is), but also one whose ramifications must be fully elaborated at each and every turn you're back again to the problem of every conceivable security consideration appearing in every possible context. Not too long ago I did OCR on a PNG file to extract some configuration information. I could easily envision a system that automated this. That doesn't mean it's appropriate to talk about code injection attacks for image/png. What we do to address this is say "labels may be misleading" and ideally give examples of some of the more pernicious problems, and of course the problem of sensitive formatted material being shuffled around as plain text is a big one. > > An obvious example would be multipart/signed. The entire point of > > multipart/signed to sign the content, which of course involves an integrity > > check. More specific examples would be any XML format that uses XML's signature > > capabilities. And while I can't name a specific JSON-based format that has > > built in integrity checks, it's entirely possible to define one. > Of course. But I thought we were talking about formats like JSON, not > profiles of that format. But the point is profiles (to use your term) are going to exist where integrity protections is provided, just as profiles are going to exist where it isn't needed. And there will be some where it essentially it be applied externally. And the point is to describe these issues and tradeoffs in the security considerations. > If they are not protected with a cryptographic key, then they don't have > integrity checking. The attacker simply replaces both the text and the > hash/CRC. I'm well aware of the issues, thanks. Maybe you and perhaps others wish it were otherwise, but the term "integrity protection" doesn't necessarily mean cryptographic checks are involved. > OK, I think I see what I missed. You are conflating active and executable > content. JSON does not have direct support for active content. JavaScript and > Python (and probably others) can treat a JSON object as an executable > assignment. It makes good sense to have a security consideration that says > "don't do that". I never said anything about the direct executable case, so I don't see how I could be conflating them. All of this has been about the indirect case. > And you're missing the point that formats like text/plain and text/html have > the same property. Please don't put words in my mouth. I never said anything about text/html, and since text/html as defined supports a wide variety of both active and executable content any claim to the contrary would be absurd. But as for text/plain, you're the one conferring properities on the format *as* *defined* that it simply does not have. Again, misuse of this and almost everything else abounds, but the minute you start trying to account for every sort of misuse everywhere you're sunk. Ned From jasnell@gmail.com Thu Sep 20 14:43:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842C921F8694 for ; Thu, 20 Sep 2012 14:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzrrfXWuwwr7 for ; Thu, 20 Sep 2012 14:43:37 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 387BA21F864D for ; Thu, 20 Sep 2012 14:43:37 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so550366wgb.13 for ; Thu, 20 Sep 2012 14:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sg66wUMyPeCVFKYyAolOGbZL1pyc2pgVwzDwVT+1tA0=; b=zKBEzB4gt9/csugBDXIbIsINvknPnu6HeQYCrHWARPFfh8M0Mseo/xv9rjGJYlALg6 LHPBtBNR0TZdjyheHdfAAvCqgx2LxZ52hjX8S+0hXdlrwNUcECMg9qsZgt8WZrtG2lD2 3AQ5f1+iBlVMqwxLGqB3TVeIak7TeHd4fpZZOiOuxsesyPlDNlMzlQOr2QGYTG1neF5p UDX15FuDJkBewp9qh36e++z/FsDTM/8SMIN77fI3TMm1WtY+qjg1QZl1kw7JZ54usgSL 5pkHXay5WtuCHc28PNYXKjKLMVAsJ8Wz5PYAhJtSmVA/KEDXWqckpMY1Z/1C/wNIo1tp hgTg== MIME-Version: 1.0 Received: by 10.180.14.8 with SMTP id l8mr6919919wic.6.1348177416314; Thu, 20 Sep 2012 14:43:36 -0700 (PDT) Received: by 10.223.182.4 with HTTP; Thu, 20 Sep 2012 14:43:36 -0700 (PDT) Received: by 10.223.182.4 with HTTP; Thu, 20 Sep 2012 14:43:36 -0700 (PDT) In-Reply-To: References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> Date: Thu, 20 Sep 2012 14:43:36 -0700 Message-ID: From: James M Snell To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=f46d04138a59fe5e9304ca2903dd Cc: Julian Reschke , Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 21:43:38 -0000 --f46d04138a59fe5e9304ca2903dd Content-Type: text/plain; charset=UTF-8 On Sep 20, 2012 2:23 PM, "Phillip Hallam-Baker" wrote: > > > > On Thu, Sep 20, 2012 at 4:09 PM, Julian Reschke wrote: >> >> On 2012-09-20 20:44, Phillip Hallam-Baker wrote: >>> >>> The issue here that the RFC seems to hint at (the language is next to >>> meaningless) is that JSON does not provide the types of integrity >>> checking that should be used if you are using it to wrap something like >>> SQL commands or other data to be passed to a scripting language. >>> ... >> >> >> WHICH language? > > > Well the spec seems to have an assumption that the JSON data is being consumed by a JavaScript implementation (and I say seems because it is clear as mud). > Perhaps it's not clear because there is no such assumption being made at all in the spec. Perhaps the one point that can and should be made clearer is that despite json being defined as a subset of the JavaScript syntax, json must not be processed as JavaScript. > I would have to actually want to understand JavaScript to understand the point it tries to make. That is not exactly appropriate for an SC section (to put it mildly). > > This is one instance of code/data conflation which is the principal mechanism for attacking Web Services. Come to that it is the main method of attack on any system since the attackers usual objective is to execute code. > > > The security of JSON depends on the encoder properly escaping strings. If this is not done an attacker can do an injection attack so code that thinks it is producing messages like the following: > > { "user" : "alice" } > > Can be tricked into producing a message like the following: > > { "user" : "alice", "privs" : "admin" } > > What the user did to create that was to set their username to the string > I'm sorry, but I must have missed something. Are we playing a game of State the Obvious now? The existing json spec very clearly details escaping. Any implementation that fails to conform to the basic requirements of the spec should be expected to function incorrectly. Such issues are not the fault of the spec, however. - james > > There are encodings in use that are specifically designed to avoid that particular issue. ASN.1 does not have that problem as the data fields are length delimited rather than relying on escaping which is rather safer. Another way to avoid them as issues is to use a schema and a compiler to manage the mapping from one to another. > > The main reason I might want to use something other than JSON as a data encoding would probably be to achieve better efficiency or to ensure that issues like this are excluded in a systematic fashion. > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d04138a59fe5e9304ca2903dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On Sep 20, 2012 2:23 PM, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:
    >
    >
    >
    > On Thu, Sep 20, 2012 at 4:09 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
    >>
    >> On 2012-09-20 20:44, Phillip Hallam-Baker wrote:
    >>>
    >>> The issue here that the RFC seems to hint at (the language is = next to
    >>> meaningless) is that JSON does not provide the types of integr= ity
    >>> checking that should be used if you are using it to wrap somet= hing like
    >>> SQL commands or other data to be passed to a scripting languag= e.
    >>> ...
    >>
    >>
    >> WHICH language?
    >
    >
    > Well the spec seems to have an assumption that the JSON data is being = consumed by a JavaScript implementation (and I say seems because it is clea= r as mud).
    >

    Perhaps it's not clear because there is no such assumpti= on being made at all in the spec. Perhaps the one point that can and should= be made clearer is that despite json being defined as a subset of the Java= Script syntax, json must not be processed as JavaScript.

    > I would have to actually want to understand JavaScript = to understand the point it tries to make. That is not exactly appropriate f= or an SC section (to put it mildly).
    >
    > This is one instance of code/data conflation which is the principal me= chanism for attacking Web Services. Come to that it is the main method of a= ttack on any system since the attackers usual objective is to execute code.=
    >
    >
    > The security of JSON depends on the encoder properly escaping strings.= If this is not done an attacker can do an injection attack so code that th= inks it is producing messages like the following:
    >
    > { "user" : "alice" }
    >
    > Can be tricked into producing a message like the following:
    >
    > { "user" : "alice", "privs" : "admi= n" }
    >
    > What the user did to create that was to set their username to the stri= ng <alice", "privs" : "admin>
    >

    I'm sorry, but I must have missed something. Are we play= ing a game of State the Obvious now? The existing json spec very clearly de= tails escaping. Any implementation that fails to conform to the basic requi= rements of the spec should be expected to function incorrectly. Such issues= are not the fault of the spec, however.

    - james

    >
    > There are encodings in use that are specifically designed to avoid tha= t particular issue. ASN.1 does not have that problem as the data fields are= length delimited rather than relying on escaping which is rather safer. An= other way to avoid them as issues is to use a schema and a compiler to mana= ge the mapping from one to another.
    >
    > The main reason I might want to use something other than JSON as a dat= a encoding would probably be to achieve better efficiency or to ensure that= issues like this are excluded in a systematic fashion.
    >
    >
    > --
    > Website: http://hallambaker.com/
    >
    >
    > _______________________________________________
    > apps-discuss mailing list
    >     apps-discuss@ietf.org
    > https:/= /www.ietf.org/mailman/listinfo/apps-discuss
    >

    --f46d04138a59fe5e9304ca2903dd-- From nico@cryptonector.com Thu Sep 20 15:08:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EAE21F84AE for ; Thu, 20 Sep 2012 15:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZyvGZdHRCJv for ; Thu, 20 Sep 2012 15:08:15 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 07FA621F84A6 for ; Thu, 20 Sep 2012 15:08:15 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 618DC3B805C for ; Thu, 20 Sep 2012 15:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Pgvz2F77xqMjuEVkqSA2 XzrPbK8=; b=HNp6/TFxZnu3CL/z5+bHAUWiZfbSKjGl8MDoFotv1HDLXDSvCNqT aFrv6MmZQw8y6in6tm0SqDz2lXyLRd3eu6YTMKQobGLlj5GUQ/QfETpDA1Y6hYDH YDxlq6TT8XAqfduhq28Z28huYtUXWuRxYBBVOkVavlV5wueN/cePeEo= Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 47F363B800C for ; Thu, 20 Sep 2012 15:08:14 -0700 (PDT) Received: by padfb11 with SMTP id fb11so245958pad.31 for ; Thu, 20 Sep 2012 15:08:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.236.69 with SMTP id us5mr10356405pbc.59.1348178893826; Thu, 20 Sep 2012 15:08:13 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 20 Sep 2012 15:08:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Sep 2012 17:08:13 -0500 Message-ID: From: Nico Williams To: Andrew Newton Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 22:08:15 -0000 So, I really like JSON, but I do have some complaints, really, only one severe complaint: - There's no standard way to encode binary data. This is a big deal. If I wanted to design a protocol that uses crypto and JSON for encoding then I'd need binary data. Yeah, yeah, I can base64-encode binary data, but at the very least any schema language ought to be able to indicate that some field is expected to bear base64-encoded data. I'd rather have a length-and-raw-octet-string encoding available though... - Lack of arbitrary types for associative array keys. (This is only really a problem for me because of Core Foundation like APIs that have associative arrays that do allow arbitrary types as keys. So, this is not a serious complaint.) - ECMAScript Unicode issues... This isn't really about JSON so maybe I shouldn't bore you with these. Also, I do have a need to re-encode ASN.1 DER-encoded data in JSON for debugging/tracing/logging purposes. I'd like a JER for ASN.1. Yeah, I know, y'all are not gonna care, and given the purpose there's hardly a need to standardize this, but others may need it too. Besides, wouldn't it be nice to be able to re-encode certificates in JSON? CSRs in particular would be convenient to be able to convert to/from JSON... Nico -- From pbryan@anode.ca Thu Sep 20 15:09:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB2811E8091 for ; Thu, 20 Sep 2012 15:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHYp3Bivavg4 for ; Thu, 20 Sep 2012 15:09:55 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 1D40B21E803C for ; Thu, 20 Sep 2012 15:09:55 -0700 (PDT) Received: from [10.71.13.58] (adsl-75-55-201-218.dsl.pltn13.sbcglobal.net [75.55.201.218]) by maple.anode.ca (Postfix) with ESMTPSA id 685E6648C; Thu, 20 Sep 2012 22:09:54 +0000 (UTC) Message-ID: <1348178993.2900.0.camel@polyglot> From: "Paul C. Bryan" To: Nico Williams Date: Thu, 20 Sep 2012 15:09:53 -0700 In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-omPGxZxWrXRL91wm8hfG" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 22:09:55 -0000 --=-omPGxZxWrXRL91wm8hfG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2012-09-20 at 17:08 -0500, Nico Williams wrote: > So, I really like JSON, but I do have some complaints, really, only > one severe complaint: > > - There's no standard way to encode binary data. +1! One of my biggest pet peeves. > This is a big deal. If I wanted to design a protocol that uses > crypto and JSON for encoding then I'd need binary data. > > Yeah, yeah, I can base64-encode binary data, but at the very > least any schema language ought to be able to indicate that > some field is expected to bear base64-encoded data. I'd rather > have a length-and-raw-octet-string encoding available though... > > - Lack of arbitrary types for associative array keys. (This is only > really a problem for me because of Core Foundation like APIs > that have associative arrays that do allow arbitrary types as > keys. So, this is not a serious complaint.) > > - ECMAScript Unicode issues... This isn't really about JSON > so maybe I shouldn't bore you with these. > > Also, I do have a need to re-encode ASN.1 DER-encoded data in JSON for > debugging/tracing/logging purposes. I'd like a JER for ASN.1. Yeah, > I know, y'all are not gonna care, and given the purpose there's hardly > a need to standardize this, but others may need it too. Besides, > wouldn't it be nice to be able to re-encode certificates in JSON? > CSRs in particular would be convenient to be able to convert to/from > JSON... > > Nico Paul --=-omPGxZxWrXRL91wm8hfG Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 2012-09-20 at 17:08 -0500, Nico Williams wrote:

    So, I really like JSON, but I do have some complaints, really, only
one severe complaint:

 - There's no standard way to encode binary data.

    +1! One of my biggest pet peeves. 
    

       This is a big deal.  If I wanted to design a protocol that uses
   crypto and JSON for encoding then I'd need binary data.

   Yeah, yeah, I can base64-encode binary data, but at the very
   least any schema language ought to be able to indicate that
   some field is expected to bear base64-encoded data.  I'd rather
   have a length-and-raw-octet-string encoding available though...

 - Lack of arbitrary types for associative array keys.  (This is only
   really a problem for me because of Core Foundation like APIs
   that have associative arrays that do allow arbitrary types as
   keys.  So, this is not a serious complaint.)

 - ECMAScript Unicode issues...   This isn't really about JSON
   so maybe I shouldn't bore you with these.

Also, I do have a need to re-encode ASN.1 DER-encoded data in JSON for
debugging/tracing/logging purposes.  I'd like a JER for ASN.1.  Yeah,
I know, y'all are not gonna care, and given the purpose there's hardly
a need to standardize this, but others may need it too.  Besides,
wouldn't it be nice to be able to re-encode certificates in JSON?
CSRs in particular would be convenient to be able to convert to/from
JSON...

Nico

    Paul --=-omPGxZxWrXRL91wm8hfG-- From nico@cryptonector.com Thu Sep 20 15:18:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F2021E80A9 for ; Thu, 20 Sep 2012 15:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCCD-b7A1CLm for ; Thu, 20 Sep 2012 15:18:51 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD7421E80A8 for ; Thu, 20 Sep 2012 15:18:51 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 0155C35007A for ; Thu, 20 Sep 2012 15:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=xsI14+/fgoD1rCyyLkSo HNTm6DQ=; b=yL2+x0WqmO1IiAhM5HwDh3Xqp6pJZJVa9hiGwGJc/rUGpQr9yD3I SRmrNsP1WdMM0iwzuzbdtM2LWsyZWmwop/blaK7sQJPjuDa7NP5SVm86PA69DhD/ +pLk6zusmbbBwvLKDSTOoGyFUatdBRi5sUg2x6XHEbdCiS2zkxvqANs= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id DAD2D350072 for ; Thu, 20 Sep 2012 15:18:50 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so3726538pbb.31 for ; Thu, 20 Sep 2012 15:18:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.236.69 with SMTP id us5mr10411069pbc.59.1348179530570; Thu, 20 Sep 2012 15:18:50 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 20 Sep 2012 15:18:50 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Sep 2012 17:18:50 -0500 Message-ID: From: Nico Williams To: Andrew Newton Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 22:18:51 -0000 On Thu, Sep 20, 2012 at 5:08 PM, Nico Williams wrote: > So, I really like JSON, but I do have some complaints, really, only > one severe complaint: Crap, I forgot another important complaint: - There's no canonical ordering and encoding. This is very important for protocols using crypto! BTW, I get it that a lot of you have a visceral dislike for ASN.1 and its encoding rules, but at least it has had canonical ones for a very long time. XMLdsig and XMLenc have mostly left me wondering (e.g., the fact that XMLdsig doesn't (didn't?) have AEAD modes, by generic composition or otherwise, seems like asking for trouble). And there's no such thing for JSON anyways. Now, we don't need any fancy JSON crypto spec: just give us octet strings and a canonical ordering/encoding, and we can lift crypto from elsewhere. Nico -- From andy@hxr.us Thu Sep 20 15:21:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BF621E80B2 for ; Thu, 20 Sep 2012 15:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPGJP+Vs60n3 for ; Thu, 20 Sep 2012 15:21:12 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3B02421E80A8 for ; Thu, 20 Sep 2012 15:21:12 -0700 (PDT) Received: by lboj14 with SMTP id j14so2810249lbo.31 for ; Thu, 20 Sep 2012 15:21:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=w+MZaIdQt6iK7Uomrai5/govIwMv/ND2txKYCKI86g0=; b=Izl8yQJFShjBYWsJa5T6DpJ48Ljm/4i6P0mkUDFGkR3UHTFTlJamRIBZ0jdQrywrJV wPy2hGXfLWdLGdmGHrYUj8nqt2G05f7cG1QwfPHV3ecZTnyT7b6YEPBuiYEEt6eVENku xwA+JOTuxjZqFGxuznZ5NrdifNpMyx2V+DXgyOrF4TjpCyjp4zNWpn2uqJVQCT5Unf92 5botD44PlIou2KhPIc2lcIpfglrZoY4iN1IwFJKeMAJ6waRJp+36I+yL7+CdyalxMEUi Ly/0LLUYHmxHRH+1oGiW70LJ44GbW/XSUFy25zy6Vav4364M0Sw4iwP1G3NTe+NhlXLL p9Sw== MIME-Version: 1.0 Received: by 10.152.46.209 with SMTP id x17mr2662068lam.38.1348179671190; Thu, 20 Sep 2012 15:21:11 -0700 (PDT) Received: by 10.112.7.67 with HTTP; Thu, 20 Sep 2012 15:21:11 -0700 (PDT) X-Originating-IP: [71.191.219.28] In-Reply-To: <1348178993.2900.0.camel@polyglot> References: <1348178993.2900.0.camel@polyglot> Date: Thu, 20 Sep 2012 18:21:11 -0400 Message-ID: From: Andrew Newton To: "Paul C. Bryan" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQncl+rtUV8dT2BEX3JUv68zrduWK5HnoEntAO3O6rQuN1R9liozJ3D6OgNHVF+wRLalvzxP Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 22:21:13 -0000 On Thu, Sep 20, 2012 at 6:09 PM, Paul C. Bryan wrote: > On Thu, 2012-09-20 at 17:08 -0500, Nico Williams wrote: > > So, I really like JSON, but I do have some complaints, really, only > one severe complaint: > > - There's no standard way to encode binary data. > > > +1! One of my biggest pet peeves. Is there a text format that does this well? -andy From nico@cryptonector.com Thu Sep 20 15:23:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2BA21E80C3 for ; Thu, 20 Sep 2012 15:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAlvEqWCoW3Q for ; Thu, 20 Sep 2012 15:23:31 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 9D73A21E80A8 for ; Thu, 20 Sep 2012 15:23:31 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 7A33C508076 for ; Thu, 20 Sep 2012 15:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=gvxHEXm/K02E0in2xEkd YyF7TTs=; b=drMsYZ16B2J5shB/PgHjatPZz0aPqNKhUDNZrnUTuLRZ/r0bCmRJ Ati8DT3qce2MHrvG00fzd7nL6dEZJnqBld1A9GuwIGpz+/cmS0OVkxrb2ApjqzSu wQb/jGUl7o5KzbCY4S1mqYCpJgPILmXQSOyq55YBaWq+R3E38XIdwP8= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 605DB508071 for ; Thu, 20 Sep 2012 15:23:28 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so3733243pbb.31 for ; Thu, 20 Sep 2012 15:23:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.76.3 with SMTP id g3mr8624195paw.25.1348179808080; Thu, 20 Sep 2012 15:23:28 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 20 Sep 2012 15:23:28 -0700 (PDT) In-Reply-To: References: <1348178993.2900.0.camel@polyglot> Date: Thu, 20 Sep 2012 17:23:28 -0500 Message-ID: From: Nico Williams To: Andrew Newton Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 22:23:35 -0000 On Thu, Sep 20, 2012 at 5:21 PM, Andrew Newton wrote: > On Thu, Sep 20, 2012 at 6:09 PM, Paul C. Bryan wrote: >> On Thu, 2012-09-20 at 17:08 -0500, Nico Williams wrote: >> >> So, I really like JSON, but I do have some complaints, really, only >> one severe complaint: >> >> - There's no standard way to encode binary data. >> >> >> +1! One of my biggest pet peeves. > > Is there a text format that does this well? Dunno. But here's what I'm looking for: - strings: '...' - octet strings: x'' or b'' I'd love an option for not-really text JSON where octet strings are encoded as , but this is probably a stretch. Nico -- From andy@hxr.us Thu Sep 20 15:29:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D351E21E80A6 for ; Thu, 20 Sep 2012 15:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzH2J46Hg2-D for ; Thu, 20 Sep 2012 15:29:40 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0564621E809C for ; Thu, 20 Sep 2012 15:29:39 -0700 (PDT) Received: by lboj14 with SMTP id j14so2817735lbo.31 for ; Thu, 20 Sep 2012 15:29:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=gfkNXENvJSlAyq/uAf6H80OCpO7Sr6NUj6xTHhYqtZs=; b=W/VAhjJrzN1onl0dZVnl1BryC3PkYqWTOgP3CFB3yAOKd/JJ/7tZZu+CRuPGKxUpbG +qy0quvl3MjcLnLMKgYBylm8paEBIPLdvgGGrEmLxeLkPgPbjkDh85FZTdl9KE8HFKSB L+skXd2iiRgbaTfLBjt191Yzb0Vo4R4T0nePziJEOhPwOhmOtcuWREbGhNKvIoUw7TPQ Our07saTWaX7Dczb0PxMkUYOe7+ZpHxAhMLgz0jBgZLxJWlfpUaQo0kR1tmt1SysTfx6 KVc64IgRcrSWkqXAly7ecUwU503qugCAy0H0/YyAQucsGIh5VeCSijLRLHoQ6W8JFhqh fCsw== MIME-Version: 1.0 Received: by 10.152.113.165 with SMTP id iz5mr2630562lab.48.1348180178897; Thu, 20 Sep 2012 15:29:38 -0700 (PDT) Received: by 10.112.7.67 with HTTP; Thu, 20 Sep 2012 15:29:38 -0700 (PDT) X-Originating-IP: [71.191.219.28] In-Reply-To: References: Date: Thu, 20 Sep 2012 18:29:38 -0400 Message-ID: From: Andrew Newton To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlx0xtARM53C8jdhLlTeXHnbpH1xPN+T2bPwwwLiRq2TbWCIt7dhNUKJCDvnJcanVstp1fn Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 22:29:40 -0000 On Thu, Sep 20, 2012 at 6:18 PM, Nico Williams wrote: > BTW, I get it that a lot of you have a visceral dislike for ASN.1 and > its encoding rules, but at least it has had canonical ones for a very > long time. XMLdsig and XMLenc have mostly left me wondering (e.g., > the fact that XMLdsig doesn't (didn't?) have AEAD modes, by generic > composition or otherwise, seems like asking for trouble). And there's > no such thing for JSON anyways. Being that there is XER, perhaps JER would find some interest. Having worked on RPKI, I can tell you that ASN.1 DER is no fun because it needs specialized tools to even view a payload. Just emitting DER is an exercise. That's why text formats are more popular, I would guess. Also finding software developers who want ASN.1 as part of their career path is impossible. > > Now, we don't need any fancy JSON crypto spec: just give us octet > strings and a canonical ordering/encoding, and we can lift crypto from > elsewhere. > Have you looked at the JOSE working group? -andy From tbray@textuality.com Thu Sep 20 15:31:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AAE21E80C7 for ; Thu, 20 Sep 2012 15:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.476 X-Spam-Level: X-Spam-Status: No, score=-4.476 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHq+9AtdtXJK for ; Thu, 20 Sep 2012 15:31:10 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA7021E809C for ; Thu, 20 Sep 2012 15:31:09 -0700 (PDT) Received: by weyx48 with SMTP id x48so1703329wey.31 for ; Thu, 20 Sep 2012 15:31:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=uRGzpPxvFFfHNDx+Kuh/QyhX8oRcgM0t9JLhmQO9P8o=; b=gnV+GIH7Mgjsm/vBdfVHP7ToLd/CARNrq32m7lhrxkd3UTSsXLZDsAVeTAyQ19j9cr tw3LOuuaw4nUlxPjOuax8NDjaqGuZ99W54AflRhZYbcoi/m0IuvjxQjFR0vbjbq8dEms b1NhdqGgcrDUciFftNm4nAn6YVqoZnRS1GSNINsJ722j8Ez3yDJBOWNkKGxVd7XY7Ea1 Zfs5VN2XeO4XL7CgTU9a9HuE+qtA7Qzf2w/GAPWLBDR2WtW1YMBwJcAUQcM7JO/sGavH Sq8Y09XUKE1/mAH682Rxz9l07+tL/HnL4eh+dgff75BzhGgwWsTsa2e7kJIwDjhwNWcK sjAg== MIME-Version: 1.0 Received: by 10.180.100.35 with SMTP id ev3mr140925wib.7.1348180269279; Thu, 20 Sep 2012 15:31:09 -0700 (PDT) Received: by 10.195.13.200 with HTTP; Thu, 20 Sep 2012 15:31:09 -0700 (PDT) X-Originating-IP: [24.84.208.217] In-Reply-To: References: Date: Thu, 20 Sep 2012 15:31:09 -0700 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=f46d044282a60b2b1e04ca29aef6 X-Gm-Message-State: ALoCoQlCyXtSP27VptqN/CQE3l4WzhdCoSNAb3xd4dIcG90Dq033adGwIy5HVPb2cQjJPGZahf/b Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 22:31:11 -0000 --f46d044282a60b2b1e04ca29aef6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The lesson from XML is that canonicalization is hard and usually not worth the effort. For your binary, use base64, keys & certs aren=92t that big, a= nd vanish in the rounding error of the video & audio that=92s filling network pipes. The number of successful modern platform-agnostic data formats that allow raw binary is zero; there=92s a reason for that. JSON is not quite right for your purposes, but the huge amount of deployed software makes doing the extra work to use it a good trade-off. -T On Thu, Sep 20, 2012 at 3:18 PM, Nico Williams wrote= : > On Thu, Sep 20, 2012 at 5:08 PM, Nico Williams > wrote: > > So, I really like JSON, but I do have some complaints, really, only > > one severe complaint: > > Crap, I forgot another important complaint: > > - There's no canonical ordering and encoding. This is very > important for protocols using crypto! > > BTW, I get it that a lot of you have a visceral dislike for ASN.1 and > its encoding rules, but at least it has had canonical ones for a very > long time. XMLdsig and XMLenc have mostly left me wondering (e.g., > the fact that XMLdsig doesn't (didn't?) have AEAD modes, by generic > composition or otherwise, seems like asking for trouble). And there's > no such thing for JSON anyways. > > Now, we don't need any fancy JSON crypto spec: just give us octet > strings and a canonical ordering/encoding, and we can lift crypto from > elsewhere. > > Nico > -- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d044282a60b2b1e04ca29aef6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The lesson from XML is that canonicalization is hard and usually not worth = the effort.=A0 For your binary, use base64, keys & certs aren=92t that = big, and vanish in the rounding error of the video & audio that=92s fil= ling network pipes.=A0 The number of successful modern platform-agnostic da= ta formats that allow raw binary is zero; there=92s a reason for that.=A0 J= SON is not quite right for your purposes, but the huge amount of deployed s= oftware makes doing the extra work to use it a good trade-off. -T


    On Thu, Sep 20, 2012 at 3:18 PM, Nico Wi= lliams <nico@cryptonector.com> wrote:
    On Thu, Sep 20, 2012 at 5:08 PM, Nico Williams <nico@cryptonector.com> wrote:
    > So, I really like JSON, but I do have some complaints, really, only > one severe complaint:

    Crap, I forgot another important complaint:

    =A0- There's no canonical ordering and encoding. =A0This is very
    =A0 =A0important for protocols using crypto!

    BTW, I get it that a lot of you have a visceral dislike for ASN.1 and
    its encoding rules, but at least it has had canonical ones for a very
    long time. =A0XMLdsig and XMLenc have mostly left me wondering (e.g.,
    the fact that XMLdsig doesn't (didn't?) have AEAD modes, by generic=
    composition or otherwise, seems like asking for trouble). =A0And there'= s
    no such thing for JSON anyways.

    Now, we don't need any fancy JSON crypto spec: just give us octet
    strings and a canonical ordering/encoding, and we can lift crypto from
    elsewhere.

    Nico
    --
    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss

    --f46d044282a60b2b1e04ca29aef6-- From nico@cryptonector.com Thu Sep 20 15:32:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237BD21E80A6 for ; Thu, 20 Sep 2012 15:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kM9lIzdKVdE3 for ; Thu, 20 Sep 2012 15:32:02 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 67DF421E809C for ; Thu, 20 Sep 2012 15:32:02 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 6054A35001C for ; Thu, 20 Sep 2012 15:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=XisfwdjjN/paYFGzCu5u Jp5ELs8=; b=I72nQyQkmavj5nEopEOTM8MCHMSzG2n9ocuh5WtuVesX6K9Vk4FL abBUGtp6sUCT0L+rBoIBuRiBsSihfkP8Hu+qymMY0gkudvYf87iKQS8o0ujwIue3 F9eR+frDHiNQJPOqZ3lKIXkXHiZztHA+Fl9nqcfklwaSiFqPI9MnFyM= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 434FE35005B for ; Thu, 20 Sep 2012 15:32:00 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so3744972pbb.31 for ; Thu, 20 Sep 2012 15:31:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.83.68 with SMTP id o4mr6460257pby.25.1348180319929; Thu, 20 Sep 2012 15:31:59 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 20 Sep 2012 15:31:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Sep 2012 17:31:59 -0500 Message-ID: From: Nico Williams To: Andrew Newton Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 22:32:03 -0000 On Thu, Sep 20, 2012 at 5:29 PM, Andrew Newton wrote: > On Thu, Sep 20, 2012 at 6:18 PM, Nico Williams wrote: >> BTW, I get it that a lot of you have a visceral dislike for ASN.1 and >> its encoding rules, but at least it has had canonical ones for a very >> long time. XMLdsig and XMLenc have mostly left me wondering (e.g., >> the fact that XMLdsig doesn't (didn't?) have AEAD modes, by generic >> composition or otherwise, seems like asking for trouble). And there's >> no such thing for JSON anyways. > > Being that there is XER, perhaps JER would find some interest. > > Having worked on RPKI, I can tell you that ASN.1 DER is no fun because > it needs specialized tools to even view a payload. Just emitting DER > is an exercise. That's why text formats are more popular, I would > guess. Also finding software developers who want ASN.1 as part of > their career path is impossible. I won't dispute that. I don't mind having to use more tools. I don't necessarily care for every bit of on-the-wire payload to be human-readable (this may just be because I work in the security area, and once you bring in crypto you always need tools to view the messages anyways). >> >> Now, we don't need any fancy JSON crypto spec: just give us octet >> strings and a canonical ordering/encoding, and we can lift crypto from >> elsewhere. >> > > Have you looked at the JOSE working group? No. I will. Thanks for the tip! From pbryan@anode.ca Thu Sep 20 15:35:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFDB21F845B for ; Thu, 20 Sep 2012 15:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EHsbsCGLoub for ; Thu, 20 Sep 2012 15:35:04 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCF521F8456 for ; Thu, 20 Sep 2012 15:35:04 -0700 (PDT) Received: from [10.71.13.58] (adsl-75-55-201-218.dsl.pltn13.sbcglobal.net [75.55.201.218]) by maple.anode.ca (Postfix) with ESMTPSA id 7765D65ED; Thu, 20 Sep 2012 22:35:03 +0000 (UTC) Message-ID: <1348180501.2900.1.camel@polyglot> From: "Paul C. Bryan" To: Andrew Newton Date: Thu, 20 Sep 2012 15:35:01 -0700 In-Reply-To: References: <1348178993.2900.0.camel@polyglot> Content-Type: multipart/alternative; boundary="=-5qmeDj/oJjWzhkDM4v4s" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 22:35:04 -0000 --=-5qmeDj/oJjWzhkDM4v4s Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2012-09-20 at 18:21 -0400, Andrew Newton wrote: > On Thu, Sep 20, 2012 at 6:09 PM, Paul C. Bryan wrote: > > On Thu, 2012-09-20 at 17:08 -0500, Nico Williams wrote: > > > > So, I really like JSON, but I do have some complaints, really, only > > one severe complaint: > > > > - There's no standard way to encode binary data. > > > > > > +1! One of my biggest pet peeves. > > Is there a text format that does this well? I haven't seen one. :-| > > -andy Paul --=-5qmeDj/oJjWzhkDM4v4s Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 2012-09-20 at 18:21 -0400, Andrew Newton wrote: 
    On Thu, Sep 20, 2012 at 6:09 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
> On Thu, 2012-09-20 at 17:08 -0500, Nico Williams wrote:
>
> So, I really like JSON, but I do have some complaints, really, only
> one severe complaint:
>
>  - There's no standard way to encode binary data.
>
>
> +1! One of my biggest pet peeves.

Is there a text format that does this well?

    I haven't seen one. :-|

    
-andy

    Paul --=-5qmeDj/oJjWzhkDM4v4s-- From nico@cryptonector.com Thu Sep 20 15:40:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800EC11E80A3 for ; Thu, 20 Sep 2012 15:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.541 X-Spam-Level: X-Spam-Status: No, score=-1.541 tagged_above=-999 required=5 tests=[AWL=-0.564, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_24=1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzOwFbGQwExb for ; Thu, 20 Sep 2012 15:40:38 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id E2B0111E8099 for ; Thu, 20 Sep 2012 15:40:38 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 62F172AC078 for ; Thu, 20 Sep 2012 15:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=GV/01vXP2zWUKbuqqnC4wHkSUi8=; b=OBYU4zZFEQS +moahlZqF7057CbW3H+nXORh7wxWlwdp7fJV2uoxADGTubzpNrrQGtHgklZmrERq UQ3eNPUISKNvteDBrcEWln3bRe0KKBQdtQjOmzx1x1TebMy8hfdlf3mO1AFTUV4w sRhT5iuyxpM9Oc9v0cQDTcxD9cV518wU= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 524022AC072 for ; Thu, 20 Sep 2012 15:40:38 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so3756786pbb.31 for ; Thu, 20 Sep 2012 15:40:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.76.3 with SMTP id g3mr8701170paw.25.1348180837982; Thu, 20 Sep 2012 15:40:37 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 20 Sep 2012 15:40:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Sep 2012 17:40:37 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 22:40:39 -0000 On Thu, Sep 20, 2012 at 5:31 PM, Tim Bray wrote: > The lesson from XML is that canonicalization is hard and usually not wort= h > the effort. For your binary, use base64, keys & certs aren=E2=80=99t tha= t big, and > vanish in the rounding error of the video & audio that=E2=80=99s filling = network > pipes. The number of successful modern platform-agnostic data formats th= at > allow raw binary is zero; there=E2=80=99s a reason for that. JSON is not= quite Is that so? I don't think so, not for media data anyways. Also, real-time media protocol designers tend to want to minimize extraneous bits (so payloads fit in small packets), like authentication tags. Also, I've seen complaints about TLS not using alignments that are friendly to implementations in hardware. Text is nice, I know, but it's not the right tool for all cases. > right for your purposes, but the huge amount of deployed software makes > doing the extra work to use it a good trade-off. -T I'm not convinced. I do think JSON is right for at least some purposes: - to re-encode things like certificates and CSRs for human consumption (and in the case of CSRs possibly for UIs that allow editing, in which case we need re-encoding back into DER) - to programmatically manipulate complex data (e.g., in JS, or via CF<->JSON bridging or equivalent) - to log things like Kerberos KDC requests, CSRs, ... Is JSON right for protocols that need crypto? I'd say "not if you knew that on day zero", but if you later realize that your protocol is the correct layer to retrofit crypto into, then you'll be happy to find canonical encoding rules. But I'll agree to defer that as much as possible. Nico -- From hallam@gmail.com Thu Sep 20 16:07:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4882021E8050 for ; Thu, 20 Sep 2012 16:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.939 X-Spam-Level: X-Spam-Status: No, score=-3.939 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ius7LLWS1Mlh for ; Thu, 20 Sep 2012 16:07:46 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6672821E804D for ; Thu, 20 Sep 2012 16:07:46 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3011332obb.31 for ; Thu, 20 Sep 2012 16:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OASWw3+xBrNVzyM4SdLPLg1B1pXmkg0sakPPOTsjqMA=; b=lIGKkLzSnS0qPLheELuwjQCQtZakg03ZHQlpLjUuK+8jVpTzb25nX6jj64HDJG226U 8329pMIFKag/dkoHGVm2EgjUaP74p2HsFIfLg/kzy0+aiy574pfC3Gd2tX5fNMGhVdFh nUku0dI5tY+xBKyEFmlOWEBncgDkskpL2MJaxa2e8Zy5KAEKXKH7kDhM2/hQeDZHkkk6 G39zm2zN5m4ZIuBMhQU68xdWPCSmZL/81eqg//Sq92216xZBRNEd3KpRnOBjZWCxrCOl 94fXTioSaOixTsEOFSN23Aio+YopN6ezGNA4XDb8VhY4NmoyfhO6vTdfwtI6RcujoiYx 6KWA== MIME-Version: 1.0 Received: by 10.182.75.33 with SMTP id z1mr2565372obv.9.1348182466013; Thu, 20 Sep 2012 16:07:46 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 16:07:45 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Sep 2012 19:07:45 -0400 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=14dae93994e7faa98104ca2a3073 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 23:07:47 -0000 --14dae93994e7faa98104ca2a3073 Content-Type: text/plain; charset=ISO-8859-1 +1 on the Binary type, I think it is also useful to add in a DateTime type so that protocols do not attempt to roll their own. On Thu, Sep 20, 2012 at 6:18 PM, Nico Williams wrote: > On Thu, Sep 20, 2012 at 5:08 PM, Nico Williams > wrote: > > So, I really like JSON, but I do have some complaints, really, only > > one severe complaint: > > Crap, I forgot another important complaint: > > - There's no canonical ordering and encoding. This is very > important for protocols using crypto! > I disagree. I have never seen the need for DER encoding. VeriSign only switched to generating DER encoding about 5 or so years after they started business. That probably means there are still some non-DER roots. Now the bigger problem with DER is the particular approach they took with the definite encodings that use a length indicator of indefinite size. Its yuk city. But I still don't see any need or use for canonical encoding and I don't think that there is anything out there that will break if presented with non-canonical The idea that people are going to shred a certificate, store it in a directory and then recombine is just potty. > BTW, I get it that a lot of you have a visceral dislike for ASN.1 and > its encoding rules, but at least it has had canonical ones for a very > long time. XMLdsig and XMLenc have mostly left me wondering (e.g., > the fact that XMLdsig doesn't (didn't?) have AEAD modes, by generic > composition or otherwise, seems like asking for trouble). And there's > no such thing for JSON anyways. > It had canonical ones but they were ignored without detrimental effect for a very long time. > Now, we don't need any fancy JSON crypto spec: just give us octet > strings and a canonical ordering/encoding, and we can lift crypto from > elsewhere. > > Nico > -- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Website: http://hallambaker.com/ --14dae93994e7faa98104ca2a3073 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 on the Binary type, I think it is also useful to add in a DateTime type = so that protocols do not attempt to roll their own.

    On Thu, Sep 20, 2012 at 6:18 PM, Nico Williams <nico@crypto= nector.com> wrote:
    On Thu, Sep 20, 2012 at 5:= 08 PM, Nico Williams <nico@cryp= tonector.com> wrote:
    > So, I really like JSON, but I do have some complaints, really, only > one severe complaint:

    Crap, I forgot another important complaint:

    =A0- There's no canonical ordering and encoding. =A0This is very
    =A0 =A0important for protocols using crypto!

    I disagree. I have never seen the need for DER encoding.
    VeriSign only switched to generating DER encoding about 5 or s= o years after they started business. That probably means there are still so= me non-DER roots.

    Now the bigger problem with DER is the particular appro= ach they took with the definite encodings that use a length indicator of in= definite size. Its yuk city. But I still don't see any need or use for = canonical encoding and I don't think that there is anything out there t= hat will break if presented with non-canonical

    The idea that people are going to shred a certificate, = store it in a directory and then recombine is just potty.=A0

    =
    =A0
    BTW, I get it that a lot of you have a visceral dislike for ASN.1 and
    its encoding rules, but at least it has had canonical ones for a very
    long time. =A0XMLdsig and XMLenc have mostly left me wondering (e.g.,
    the fact that XMLdsig doesn't (didn't?) have AEAD modes, by generic=
    composition or otherwise, seems like asking for trouble). =A0And there'= s
    no such thing for JSON anyways.

    It had = canonical ones but they were ignored without detrimental effect for a very = long time.

    =A0
    Now, we don't need any fancy JSON crypto spec: just give us octet
    strings and a canonical ordering/encoding, and we can lift crypto from
    elsewhere.

    Nico
    --
    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss



    --
    = Website: http://hallambaker.com/
    --14dae93994e7faa98104ca2a3073-- From hallam@gmail.com Thu Sep 20 16:18:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B538E21E8034 for ; Thu, 20 Sep 2012 16:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.933 X-Spam-Level: X-Spam-Status: No, score=-3.933 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heqCqMwwmTg8 for ; Thu, 20 Sep 2012 16:18:25 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id C05B921E8047 for ; Thu, 20 Sep 2012 16:18:25 -0700 (PDT) Received: by oagn5 with SMTP id n5so2438309oag.31 for ; Thu, 20 Sep 2012 16:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WBZmPFmZDt7jYvdBy3QJjLTqSPpZlXMD9PMHMgtJ76c=; b=HvzD/u9hnm6FbVAFaeeFSUwgAilp+X3Z+UXXNs5Mm3fvpqSQxun2UD6p4eMDyigxh2 j8fWFVl9cdCFhRPPWHFarXh+Sj8Sivw5kXLJLB5EETBK4HqeObuOqKngPkl2EiKurY4a BDy6qA0JgFF8tkiQwVJDYHsUq7kcCcP4KkoiVNk/deDMLDXaswEFCGRVDwpKbb+a4ii8 63MVHi2+FtxeosiPM55gzUeiB46IdjYIXdRenE2ly3Ljf/tO6jroYiKkHwGK49oeLaHn MYxDodavDdCGE9YP6cooCGK6Blr2lHhKLIUFfWFkQhLgoSWOWoEIvqGdJ4liwSwVfPTL tvHQ== MIME-Version: 1.0 Received: by 10.60.171.114 with SMTP id at18mr1825939oec.24.1348183105393; Thu, 20 Sep 2012 16:18:25 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 16:18:25 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Sep 2012 19:18:25 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Newton Content-Type: multipart/alternative; boundary=bcaec54d414e16d26f04ca2a572d Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 23:18:26 -0000 --bcaec54d414e16d26f04ca2a572d Content-Type: text/plain; charset=ISO-8859-1 I am actually sensing a pretty wide sense of agreement here on quite a number of issues. A JER might well be useful as a way to migrate specs from ASN.1 to JSON. We have done this in reverse as well. KEYPROV had to define an ASN.1 binding as well as an XML because people who had a PKI that was 100% ASN.1 did not want to use XML just for key provisioning. But I had to respond here as the last time I wrote an ASN.1 decoder it was written in JavaScript... On Thu, Sep 20, 2012 at 6:29 PM, Andrew Newton wrote: > On Thu, Sep 20, 2012 at 6:18 PM, Nico Williams > wrote: > > BTW, I get it that a lot of you have a visceral dislike for ASN.1 and > > its encoding rules, but at least it has had canonical ones for a very > > long time. XMLdsig and XMLenc have mostly left me wondering (e.g., > > the fact that XMLdsig doesn't (didn't?) have AEAD modes, by generic > > composition or otherwise, seems like asking for trouble). And there's > > no such thing for JSON anyways. > > Being that there is XER, perhaps JER would find some interest. > > Having worked on RPKI, I can tell you that ASN.1 DER is no fun because > it needs specialized tools to even view a payload. Just emitting DER > is an exercise. That's why text formats are more popular, I would > guess. Also finding software developers who want ASN.1 as part of > their career path is impossible. > > > > > Now, we don't need any fancy JSON crypto spec: just give us octet > > strings and a canonical ordering/encoding, and we can lift crypto from > > elsewhere. > > > > Have you looked at the JOSE working group? > > -andy > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Website: http://hallambaker.com/ --bcaec54d414e16d26f04ca2a572d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am actually sensing a pretty wide sense of agreement here on quite a numb= er of issues.

    A JER might well be useful as a way to mig= rate specs from ASN.1 to JSON. We have done this in reverse as well. KEYPRO= V had to define an ASN.1 binding as well as an XML because people who had a= PKI that was 100% ASN.1 did not want to use XML just for key provisioning.=


    But I had to respond here as the last ti= me I wrote an ASN.1 decoder it was written in JavaScript...

    On Thu, Sep 20, 2012 at 6:29 PM, Andrew Newton <andy@hxr.us> wrote:
    On Thu, Sep 20, 2012 at 6:= 18 PM, Nico Williams <nico@cryp= tonector.com> wrote:
    > BTW, I get it that a lot of you have a visceral dislike for ASN.1 and<= br> > its encoding rules, but at least it has had canonical ones for a very<= br> > long time. =A0XMLdsig and XMLenc have mostly left me wondering (e.g.,<= br> > the fact that XMLdsig doesn't (didn't?) have AEAD modes, by ge= neric
    > composition or otherwise, seems like asking for trouble). =A0And there= 's
    > no such thing for JSON anyways.

    Being that there is XER, perhaps JER would find some interest.

    Having worked on RPKI, I can tell you that ASN.1 DER is no fun because
    it needs specialized tools to even view a payload. Just emitting DER
    is an exercise. That's why text formats are more popular, I would
    guess. Also finding software developers who want ASN.1 as part of
    their career path is impossible.

    >
    > Now, we don't need any fancy JSON crypto spec: just give us octet<= br> > strings and a canonical ordering/encoding, and we can lift crypto from=
    > elsewhere.
    >

    Have you looked at the JOSE working group?

    -andy
    ___________________________________= ____________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss



    --
    = Website: http://hallambaker.com/
    --bcaec54d414e16d26f04ca2a572d-- From hallam@gmail.com Thu Sep 20 16:26:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23E921F8619 for ; Thu, 20 Sep 2012 16:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.928 X-Spam-Level: X-Spam-Status: No, score=-3.928 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qc-VDp-n2wbm for ; Thu, 20 Sep 2012 16:26:56 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id E7FA421F8617 for ; Thu, 20 Sep 2012 16:26:55 -0700 (PDT) Received: by oagn5 with SMTP id n5so2444146oag.31 for ; Thu, 20 Sep 2012 16:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m7PDLBjJ0rfDsW9MdzFoRyDbuSXdgQITF2EkJYzWRxU=; b=WkM5XIJmyH7ww50PEJ0PkQA9p0NM64P6L1tfpeEktaUQ1PM7wOCbihz5qLz1Ifn/BX ieBPomKwXLl63zRfX5K5kWWFljX4uZCQdua3upUn/tHjynhaP9I3OPCDwrsjLFsqzzX/ tWTikgds+xAuluyLQk6UZTMUeO+tHn3jXgKvppRVV8YfJwxVNvHeavuvHaZw6P5twY1Q Uk2tRrA5D80h3I6apo450t4XqO/eWdXb4n2RpetOBD8VuHFD+e51ZxUeWlSwIZol3ZgW QZFpGkKXlewXKoHX9uBOhw2xg7ZHYd6iEjXq+b/1P0xFo2mhNHdOlU00wb9juPXjG4FO ikfg== MIME-Version: 1.0 Received: by 10.182.152.97 with SMTP id ux1mr2591877obb.13.1348183615509; Thu, 20 Sep 2012 16:26:55 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 16:26:55 -0700 (PDT) In-Reply-To: <505B8B97.1080906@gmx.de> References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> <505B8B97.1080906@gmx.de> Date: Thu, 20 Sep 2012 19:26:55 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=f46d04462c0a7e963804ca2a752c Cc: Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 23:26:57 -0000 --f46d04462c0a7e963804ca2a752c Content-Type: text/plain; charset=ISO-8859-1 What makes it a security consideration is the possibility that an ATTACKER might intentionally create a malicious encoding. It is like the fact that C uses a braindead array scheme makes it easy to create buffer overrun errors that are impossible in BASIC, FORTRAN, Pascal, C#, Java and pretty much every other language. Relying on programmers to write correct code without security holes is a bad security practice. Using a schema tool to generate encoders is usually a sufficient control. It is not a big security concern but it is a concern. On Thu, Sep 20, 2012 at 5:33 PM, Julian Reschke wrote: > On 2012-09-20 23:22, Phillip Hallam-Baker wrote: > >> >> >> On Thu, Sep 20, 2012 at 4:09 PM, Julian Reschke > **> wrote: >> >> On 2012-09-20 20:44, Phillip Hallam-Baker wrote: >> >> The issue here that the RFC seems to hint at (the language is >> next to >> meaningless) is that JSON does not provide the types of integrity >> checking that should be used if you are using it to wrap >> something like >> SQL commands or other data to be passed to a scripting language. >> ... >> >> >> WHICH language? >> >> >> Well the spec seems to have an assumption that the JSON data is being >> consumed by a JavaScript implementation (and I say seems because it is >> clear as mud). >> >> I would have to actually want to understand JavaScript to understand the >> point it tries to make. That is not exactly appropriate for an SC >> section (to put it mildly). >> >> This is one instance of code/data conflation which is the principal >> mechanism for attacking Web Services. Come to that it is the main method >> of attack on any system since the attackers usual objective is to >> execute code. >> >> >> The security of JSON depends on the encoder properly escaping strings. >> If this is not done an attacker can do an injection attack so code that >> thinks it is producing messages like the following: >> >> { "user" : "alice" } >> >> Can be tricked into producing a message like the following: >> >> { "user" : "alice", "privs" : "admin" } >> >> What the user did to create that was to set their username to the string >> >> >> >> There are encodings in use that are specifically designed to avoid that >> particular issue. ASN.1 does not have that problem as the data fields >> are length delimited rather than relying on escaping which is rather >> safer. Another way to avoid them as issues is to use a schema and a >> compiler to manage the mapping from one to another. >> >> The main reason I might want to use something other than JSON as a data >> encoding would probably be to achieve better efficiency or to ensure >> that issues like this are excluded in a systematic fashion. >> ... >> > > I still have trouble following. > > If your have a broken sender, you can get broken messages. That's true for > all formats, but I agree that some formats might be easier to exploit. > > Anyway: if you want the JSONbis RFC to be better, please make a concrete > proposal. > > Best regards, Julian > -- Website: http://hallambaker.com/ --f46d04462c0a7e963804ca2a752c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What makes it a security consideration is the possibility that an ATTACKER = might intentionally create a malicious encoding.

    It is l= ike the fact that C uses a braindead array scheme makes it easy to create b= uffer overrun errors that are impossible in BASIC, FORTRAN, Pascal, C#, Jav= a and pretty much every other language. Relying on programmers to write cor= rect code without security holes is a bad security practice.

    Using a schema tool to generate encoders is usually a s= ufficient control.


    It is not a big = security concern but it is a concern.=A0


    On Thu, Sep 20, 2012 at 5:33 PM, Julian Reschke <julian.reschke@gmx.de= > wrote:
    On 2012-09-20 23:22, Phillip Hallam-Baker wrote:


    On Thu, Sep 20, 2012 at 4:09 PM, Julian Reschke <julian.reschke@gmx.de
    <mailto:julia= n.reschke@gmx.de>> wrote:

    =A0 =A0 On 2012-09-20 20:44, Phillip Hallam-Baker wrote:

    =A0 =A0 =A0 =A0 The issue here that the RFC seems to hint at (the language = is
    =A0 =A0 =A0 =A0 next to
    =A0 =A0 =A0 =A0 meaningless) is that JSON does not provide the types of int= egrity
    =A0 =A0 =A0 =A0 checking that should be used if you are using it to wrap =A0 =A0 =A0 =A0 something like
    =A0 =A0 =A0 =A0 SQL commands or other data to be passed to a scripting lang= uage.
    =A0 =A0 =A0 =A0 ...


    =A0 =A0 WHICH language?


    Well the spec seems to have an assumption that the JSON data is being
    consumed by a JavaScript implementation (and I say seems because it is
    clear as mud).

    I would have to actually want to understand JavaScript to understand the point it tries to make. That is not exactly appropriate for an SC
    section (to put it mildly).

    This is one instance of code/data conflation which is the principal
    mechanism for attacking Web Services. Come to that it is the main method of attack on any system since the attackers usual objective is to
    execute code.


    The security of JSON depends on the encoder properly escaping strings.
    If this is not done an attacker can do an injection attack so code that
    thinks it is producing messages like the following:

    { "user" : "alice" }

    Can be tricked into producing a message like the following:

    { "user" : "alice", "privs" : "admin&quo= t; }

    What the user did to create that was to set their username to the string <alice", "privs" : "admin>


    There are encodings in use that are specifically designed to avoid that
    particular issue. ASN.1 does not have that problem as the data fields
    are length delimited rather than relying on escaping which is rather
    safer. Another way to avoid them as issues is to use a schema and a
    compiler to manage the mapping from one to another.

    The main reason I might want to use something other than JSON as a data
    encoding would probably be to achieve better efficiency or to ensure
    that issues like this are excluded in a systematic fashion.
    ...

    I still have trouble following.

    If your have a broken sender, you can get broken messages. That's true = for all formats, but I agree that some formats might be easier to exploit.<= br>
    Anyway: if you want the JSONbis RFC to be better, please make a concrete pr= oposal.

    Best regards, Julian



    --
    Website: http://hallambaker.com/

    --f46d04462c0a7e963804ca2a752c-- From hallam@gmail.com Thu Sep 20 16:35:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B923511E80A3 for ; Thu, 20 Sep 2012 16:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.922 X-Spam-Level: X-Spam-Status: No, score=-3.922 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A30FJk7kPkLe for ; Thu, 20 Sep 2012 16:35:19 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2E5411E8099 for ; Thu, 20 Sep 2012 16:35:19 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3029554obb.31 for ; Thu, 20 Sep 2012 16:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ce7clRGb72MnOuFIBoqFDtti4EkOQzMEHjcwfkC6m+Q=; b=BTWJ+/XfPrDf6HoYGxPm1is+n2dh6yZcqE/jrMM21Bg031/Pq8dhE+fbyTOPZe8+Gv iYy1XNk5wrV4a/GkranD4GLsZWT6dywEn6fi49NkngKUMI0KMbOeCcJ5RG4nEAj8QyDr tjX5Iglko02fquMqwI1pJ+ebYcN1xHUVLCPv4XkTn1CDypCV11VrP7MIJXc/KTVUXO8y boEMb3B+GhyCj2VJMsr9bI7sG4/FfJ79U6Xp6T1jOiRuwXHaCvRGuvAIeGqPy9nz4Teo GqCbyaFHntxxvEM4ON9WyuiTNiTzrUqO3NAvOcp6sS3/KBY7oLL69QWoWbGd5tIY6fEO lPgg== MIME-Version: 1.0 Received: by 10.182.207.6 with SMTP id ls6mr2599153obc.36.1348184119282; Thu, 20 Sep 2012 16:35:19 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 16:35:19 -0700 (PDT) In-Reply-To: References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> Date: Thu, 20 Sep 2012 19:35:19 -0400 Message-ID: From: Phillip Hallam-Baker To: James M Snell Content-Type: multipart/alternative; boundary=e89a8f646e2b858b1204ca2a9399 Cc: Julian Reschke , Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 23:35:20 -0000 --e89a8f646e2b858b1204ca2a9399 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 20, 2012 at 5:43 PM, James M Snell wrote: > > On Sep 20, 2012 2:23 PM, "Phillip Hallam-Baker" wrote: > > > > > > > > On Thu, Sep 20, 2012 at 4:09 PM, Julian Reschke > wrote: > >> > >> On 2012-09-20 20:44, Phillip Hallam-Baker wrote: > >>> > >>> The issue here that the RFC seems to hint at (the language is next to > >>> meaningless) is that JSON does not provide the types of integrity > >>> checking that should be used if you are using it to wrap something like > >>> SQL commands or other data to be passed to a scripting language. > >>> ... > >> > >> > >> WHICH language? > > > > > > Well the spec seems to have an assumption that the JSON data is being > consumed by a JavaScript implementation (and I say seems because it is > clear as mud). > > > > Perhaps it's not clear because there is no such assumption being made at > all in the spec. Perhaps the one point that can and should be made clearer > is that despite json being defined as a subset of the JavaScript syntax, > json must not be processed as JavaScript. > > > I would have to actually want to understand JavaScript to understand the > point it tries to make. That is not exactly appropriate for an SC section > (to put it mildly). > > > > This is one instance of code/data conflation which is the principal > mechanism for attacking Web Services. Come to that it is the main method of > attack on any system since the attackers usual objective is to execute code. > > > > > > The security of JSON depends on the encoder properly escaping strings. > If this is not done an attacker can do an injection attack so code that > thinks it is producing messages like the following: > > > > { "user" : "alice" } > > > > Can be tricked into producing a message like the following: > > > > { "user" : "alice", "privs" : "admin" } > > > > What the user did to create that was to set their username to the string > > > > > I'm sorry, but I must have missed something. Are we playing a game of > State the Obvious now? > Bingo! Yes, we are playing a game of state the obvious because that is what most security issues tend to end up being. If you have a million lines of code then the chance of at least one of them having an obvious error is pretty much 100%. It is rather obvious that a buffer overrun is likely to be a bad thing but it took over a decade for people to realize that it allowed people to smash the stack and pown the machine. And given that it has taken us the best part of a day to get to the point where the explanation is obvious I think that the problem itself is far from obvious. This attack vector (in different incarnations) is currently the most commonly used attack against Web Services. -- Website: http://hallambaker.com/ --e89a8f646e2b858b1204ca2a9399 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Thu, Sep 20, 2012 at 5:43 PM, James M= Snell <jasnell@gmail.com> wrote:


    On Sep 20, 2012 2:23 PM, "Phillip Hallam-Baker" <hallam@gmail.com> wrote: >
    >
    >
    > On Thu, Sep 20, 2012 at 4:09 PM, Julian Reschke <julian.reschke@gmx.de> wrot= e:
    >>
    >> On 2012-09-20 20:44, Phillip Hallam-Baker wrote:
    >>>
    >>> The issue here that the RFC seems to hint at (the language is = next to
    >>> meaningless) is that JSON does not provide the types of integr= ity
    >>> checking that should be used if you are using it to wrap somet= hing like
    >>> SQL commands or other data to be passed to a scripting languag= e.
    >>> ...
    >>
    >>
    >> WHICH language?
    >
    >
    > Well the spec seems to have an assumption that the JSON data is being = consumed by a JavaScript implementation (and I say seems because it is clea= r as mud).
    >

    Perhaps it's not clear because there is no such as= sumption being made at all in the spec. Perhaps the one point that can and = should be made clearer is that despite json being defined as a subset of th= e JavaScript syntax, json must not be processed as JavaScript.

    > I would have to actually want to understand JavaScript = to understand the point it tries to make. That is not exactly appropriate f= or an SC section (to put it mildly).
    >
    > This is one instance of code/data conflation which is the principal me= chanism for attacking Web Services. Come to that it is the main method of a= ttack on any system since the attackers usual objective is to execute code.=
    >
    >
    > The security of JSON depends on the encoder properly escaping strings.= If this is not done an attacker can do an injection attack so code that th= inks it is producing messages like the following:
    >
    > { "user" : "alice" }
    >
    > Can be tricked into producing a message like the following:
    >
    > { "user" : "alice", "privs" : "admi= n" }
    >
    > What the user did to create that was to set their username to the stri= ng <alice", "privs" : "admin>
    >

    I'm sorry, but I must have missed something. Are w= e playing a game of State the Obvious now?=A0

    Bingo!

    Yes, we are playing a game of state the obvious bec= ause that is what most security issues tend to end up being. If you have a = million lines of code then the chance of at least one of them having an obv= ious error is pretty much 100%. It is rather obvious that a buffer overrun = is likely to be a bad thing but it took over a decade for people to realize= that it allowed people to smash the stack and pown the machine.
    =A0
    And given that it has taken us the best part of a day to= get to the point where the explanation is obvious I think that the problem= itself is far from obvious.


    This a= ttack vector (in different incarnations) is currently the most commonly use= d attack against Web Services.=A0



    --
    Website: http://hallambaker.com/

    --e89a8f646e2b858b1204ca2a9399-- From nico@cryptonector.com Thu Sep 20 16:37:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C651111E80C5 for ; Thu, 20 Sep 2012 16:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXxZS++ns-fw for ; Thu, 20 Sep 2012 16:37:34 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 351CB11E8099 for ; Thu, 20 Sep 2012 16:37:34 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id B17FA1B4061 for ; Thu, 20 Sep 2012 16:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=3DnGBEXZxJq04TNnTMlW M7+Pfmk=; b=uTg5EqlFee1MRAGH+X0TaUEBa5wCPT+OTJe7ab/lOlM46299BbPG Dqja/B+9mO6yLa9EqYFvWz1q8TGoZUIW0DdpGfTCua2zNSzvgqGN9BnBgcADd7ut JDlwKLW+SSa7sJ3g4YCkTGSzh+JBPs5uTFd9lkjh5xRobF25DzOHT4k= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 941861B405F for ; Thu, 20 Sep 2012 16:37:33 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so3834613pbb.31 for ; Thu, 20 Sep 2012 16:37:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.213.228 with SMTP id nv4mr10847751pbc.67.1348184253286; Thu, 20 Sep 2012 16:37:33 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 20 Sep 2012 16:37:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Sep 2012 18:37:33 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 23:37:34 -0000 On Thu, Sep 20, 2012 at 6:18 PM, Phillip Hallam-Baker wrote: > I am actually sensing a pretty wide sense of agreement here on quite a > number of issues. That had me doing a double take, but I think that's right. > A JER might well be useful as a way to migrate specs from ASN.1 to JSON. We > have done this in reverse as well. KEYPROV had to define an ASN.1 binding as > well as an XML because people who had a PKI that was 100% ASN.1 did not want > to use XML just for key provisioning. There are a number of decent open source ASN.1 tools nowadays (yeah, yeah, not nearly as many as XML tools), and it might not be hard to add JER support to some of them (I'm thinking of asn1c and Heimdal's ASN.1 compiler). > But I had to respond here as the last time I wrote an ASN.1 decoder it was > written in JavaScript... That's another thing: JS needs better binary data handling. Nico -- From ned.freed@mrochek.com Thu Sep 20 16:40:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70B221E8047 for ; Thu, 20 Sep 2012 16:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKsHDSGoL-aQ for ; Thu, 20 Sep 2012 16:40:59 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id D5C8A11E80A2 for ; Thu, 20 Sep 2012 16:40:58 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKHHLE2BO000AAJ1@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 20 Sep 2012 16:35:53 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Thu, 20 Sep 2012 16:35:50 -0700 (PDT) Message-id: <01OKHHLBYOU60006TF@mauve.mrochek.com> Date: Thu, 20 Sep 2012 16:28:55 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 20 Sep 2012 14:43:36 -0700" MIME-version: 1.0 Content-type: message/rfc822 References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> To: James M Snell Cc: Julian Reschke , Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 23:40:59 -0000 > I'm sorry, but I must have missed something. Are we playing a game of State > the Obvious now? Yes, in point of fact that's exactly what security considerations sections often end up doing. At least from the perspective of some. But not everyone has the same experience or is able to draw conclusions that others see as obvious. The implications of substituting strings into SQL are obvious to anyone who is familiar with the syntax. But that has not exactly eliminated SQL injections attacks. And no, detailing this stuff in the security considerations for application/json won't prevent it from happening for JSON. But it might help a little. As seems to always be the case in matters of security, there are tradeoffs and a balance must be struck. Detailing every conceivable thing no matter how unlikely is not the answer, but neither is some rather cryptic directions about what functions to use, which is what is there now. > The existing json spec very clearly details escaping. Any > implementation that fails to conform to the basic requirements of the spec > should be expected to function incorrectly. Such issues are not the fault > of the spec, however. This is about producing the best outcome, not finding fault. Ned From ned.freed@mrochek.com Thu Sep 20 16:41:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DAF21E8053 for ; Thu, 20 Sep 2012 16:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSPrBtQ0kbkD for ; Thu, 20 Sep 2012 16:41:00 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0F87111E8099 for ; Thu, 20 Sep 2012 16:41:00 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKHHN4KUF400AAJ1@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 20 Sep 2012 16:37:17 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Thu, 20 Sep 2012 16:37:14 -0700 (PDT) Message-id: <01OKHHN30INI0006TF@mauve.mrochek.com> Date: Thu, 20 Sep 2012 16:36:40 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 20 Sep 2012 23:08:58 +0200" <505B85EA.2080901@gmx.de> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <01OKHBU81QWO0006TF@mauve.mrochek.com> <505B85EA.2080901@gmx.de> To: Julian Reschke Cc: Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 23:41:01 -0000 > On 2012-09-20 22:45, Ned Freed wrote: > >> On 2012-09-20 19:18, Ned Freed wrote: > >> > ... > >> > Errr, right. Are you saying JSON involves active or executable > >> content? > >> > > >> > It most definitely can and in practice is used that way. And that > >> possibility > >> > also need to be mentioned. > >> > ... > > > >> But that's not JSON; it's just something that remotely looks like it. > > > > A while back we wrote an RFC explaining how to represent the Sieve mail > > filtering langauge in XML. At that time someone told me they had done > > the same > > thing using JSON. Syntactically this absolutely was JSON, but > > semantically it > > was Sieve, an executable language. > > Now, maybe to you that's not JSON but rather "something that remotely looks > > like it". But to me it most definitely *is* JSON, because abstract JSON > > without > > some attached semantics is both meaningless and useless. > > > > This is what I mean when I call JSON a container format. And there is long > > established precedent for describing both the security considerations > > inherent > > in the abstract format as well as those that are likely to arise when > > semantics > > are attached. > >> I have nothing against warning people to *always* use strict JSON > >> parsers (not JS eval) to process JSON, but we should be clear about > >> what's JSON and what is not. > > > > Well, if you're talking about having to violate syntax rules in order for > > executable semantics to attach, then I'm afraid you're talking nonsense. > Depends on the layer we look at. > To make JSON code executable as JavaScript *code*, you need to violate > the JSON syntax. > Of course you can define uses of JSON (or text/plain, or text/xml, or > ...) that have executable semantics on a different layer, but that's not > what I was referring to. But it isn't what was being discussed in the message you were responding to. If you want to change the subject, you need to say as much. Ned From cabo@tzi.org Thu Sep 20 16:46:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D92B21E8047 for ; Thu, 20 Sep 2012 16:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfCk3ZmY5EEc for ; Thu, 20 Sep 2012 16:46:45 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDF221F8674 for ; Thu, 20 Sep 2012 16:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q8KNkUxQ012601; Fri, 21 Sep 2012 01:46:30 +0200 (CEST) Received: from [192.168.217.105] (p5489283B.dip.t-dialin.net [84.137.40.59]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6AB78A3E; Fri, 21 Sep 2012 01:46:30 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 21 Sep 2012 01:46:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08D741A0-6449-41BD-9C10-FA67942B91E4@tzi.org> References: <1348178993.2900.0.camel@polyglot> To: Nico Williams X-Mailer: Apple Mail (2.1498) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 23:46:45 -0000 On Sep 21, 2012, at 00:23, Nico Williams wrote: > Dunno. But here's what I'm looking for: >=20 > - strings: '...' > - octet strings: x'' or b'' Indeed. The problem is not that the binary data has to be carried = around in some encoded text form, but that it is not identified as = binary data. (Lose the hex idea, though. Unneeded choice.) Which raises the question: What is the status on binary data (really: = byte strings) in ECMAscript? Gr=FC=DFe, Carsten From pbryan@anode.ca Thu Sep 20 16:49:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1EF21E8050 for ; Thu, 20 Sep 2012 16:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8GJ92asTddh for ; Thu, 20 Sep 2012 16:49:55 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 29A6E21E8047 for ; Thu, 20 Sep 2012 16:49:55 -0700 (PDT) Received: from [10.71.13.58] (adsl-75-55-201-218.dsl.pltn13.sbcglobal.net [75.55.201.218]) by maple.anode.ca (Postfix) with ESMTPSA id 4A65C65EF; Thu, 20 Sep 2012 23:49:50 +0000 (UTC) Message-ID: <1348184984.2900.16.camel@polyglot> From: "Paul C. Bryan" To: Phillip Hallam-Baker Date: Thu, 20 Sep 2012 16:49:44 -0700 In-Reply-To: References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> <505B8B97.1080906@gmx.de> Content-Type: multipart/alternative; boundary="=-ALEqxYZ0tBxOPaz1pjZH" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: Julian Reschke , Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 23:49:56 -0000 --=-ALEqxYZ0tBxOPaz1pjZH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2012-09-20 at 19:26 -0400, Phillip Hallam-Baker wrote: > What makes it a security consideration is the possibility that an > ATTACKER might intentionally create a malicious encoding. What malicious encoding? Your example wouldn't have been parsed by any JSON parser I'm familiar with, accidentally or otherwise. > It is like the fact that C uses a braindead array scheme makes it easy > to create buffer overrun errors that are impossible in BASIC, FORTRAN, > Pascal, C#, Java and pretty much every other language. Relying on > programmers to write correct code without security holes is a bad > security practice. So, you're proposing we indicate under security considerations that relying on programmers to write correct code without security holes is a bad security practice? > Using a schema tool to generate encoders is usually a sufficient > control. You don't need a schema tool to encode well-formed JSON. > It is not a big security concern but it is a concern. So you raised it why then? Paul --=-ALEqxYZ0tBxOPaz1pjZH Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 2012-09-20 at 19:26 -0400, Phillip Hallam-Baker wrote:

    What makes it a security consideration is the possibility that an ATTACKER might intentionally create a malicious encoding.
    What malicious encoding? Your example wouldn't have been parsed by any JSON parser I'm familiar with, accidentally or otherwise.

    It is like the fact that C uses a braindead array scheme makes it easy to create buffer overrun errors that are impossible in BASIC, FORTRAN, Pascal, C#, Java and pretty much every other language. Relying on programmers to write correct code without security holes is a bad security practice.
    So, you're proposing we indicate under security considerations that relying on programmers to write correct code without security holes is a bad security practice?

    Using a schema tool to generate encoders is usually a sufficient control.
    You don't need a schema tool to encode well-formed JSON.

    It is not a big security concern but it is a concern.
    So you raised it why then?

    Paul
    --=-ALEqxYZ0tBxOPaz1pjZH-- From andy@hxr.us Thu Sep 20 17:08:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BC421E804D for ; Thu, 20 Sep 2012 17:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uBtY7diCBsT for ; Thu, 20 Sep 2012 17:08:43 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1667F21E8047 for ; Thu, 20 Sep 2012 17:08:42 -0700 (PDT) Received: by lboj14 with SMTP id j14so2893372lbo.31 for ; Thu, 20 Sep 2012 17:08:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ifhgg4Gffv0u7thCS9dDwYbnM2pU3IGd5JLJzLrmky0=; b=CrEFTHDdoFGqpsM3Fw/+3tVwOmD0CxK6nTN3aAdBPdDQSSRxqV4KhD1XvPV0rOJ5WA +k+JLkoDQzCmD7g2PW0tIXI0MOLYlRNDypRYAYB+YF3TUzImoJHust6QUtyegmb5mGmJ F+y+9zRbxHTfs+NGWhvYzwKWHeNPh1bOLb1KQP9acOSPAjH/XOddG3vD5e2F/HfxUE5S jSj3gk3JePEKZVuY40JAeCLx6UjrYsj/W2SLQ4UTH8OO7lwv8r3xbUm1w83cOHZh16Yx Fko47k3r2pTUWthr2BnABaublVTXq2/RUd73ekcZsPZtpv3hSRTzcalQ4V7zcxIA35sl bmIQ== MIME-Version: 1.0 Received: by 10.112.36.138 with SMTP id q10mr1162652lbj.63.1348186121908; Thu, 20 Sep 2012 17:08:41 -0700 (PDT) Received: by 10.112.7.67 with HTTP; Thu, 20 Sep 2012 17:08:41 -0700 (PDT) X-Originating-IP: [71.191.219.28] In-Reply-To: References: Date: Thu, 20 Sep 2012 20:08:41 -0400 Message-ID: From: Andrew Newton To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmnjvBV0iGyaxWbWbk+fAFEYwI97u/gT0HkIxFPMJw+Mhc9/0+CpaHEOeNRl/ehvnrx78gD Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 00:08:43 -0000 On Thu, Sep 20, 2012 at 7:07 PM, Phillip Hallam-Baker wrote: > +1 on the Binary type, I think it is also useful to add in a DateTime type > so that protocols do not attempt to roll their own. Given that both JSON Content Rules and JSON Schema have both base64 and dateTime, what's the difference between the base text format saying a string is base64 or dateTime vs a schema for JSON saying a string is base64 or dateTime? -andy From hallam@gmail.com Thu Sep 20 18:32:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F4921E8041 for ; Thu, 20 Sep 2012 18:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.917 X-Spam-Level: X-Spam-Status: No, score=-3.917 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyRKx8Vociii for ; Thu, 20 Sep 2012 18:32:32 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEF121E8047 for ; Thu, 20 Sep 2012 18:32:26 -0700 (PDT) Received: by oagn5 with SMTP id n5so2524114oag.31 for ; Thu, 20 Sep 2012 18:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CQ4kk+mweMyC6yaFiYSeLi+sG8XP7WQ3uUrVVku1dwE=; b=e1WyJsranbZClKFuMP24/zzzgSkW5nHxKLuuRNlMVtO70tiWD5006jlVLfCgmfwyt6 fIWQzHqOfkMpxs8UYEQjkuuvJ/7QsrxSyiJKhfv7XgUMub3C5AYpbyFgK04TySiKBoTE p47CCq6ZksIeoGz85hQSf9UB8kvm5ZqJB1aWlcXyX9eLGQoTf8cSnyurbygcGwdr/QgO pHeqPyGpVDj21J6g7gAVBt3GZGUq/h8s5rLZUSTdI3s38j1/oIV5/pUap9DnTeY+GR5O Ck0e+KOWa/h43OagYK/NCA/Y31Nbs2hPjzJnXk/rgqJWPk1SAtiDoriQZ+kri33ilVyA vb/w== MIME-Version: 1.0 Received: by 10.60.170.138 with SMTP id am10mr2690416oec.115.1348191146690; Thu, 20 Sep 2012 18:32:26 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 18:32:26 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Sep 2012 21:32:26 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Newton Content-Type: multipart/alternative; boundary=bcaec517a4a063480b04ca2c3672 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 01:32:38 -0000 --bcaec517a4a063480b04ca2c3672 Content-Type: text/plain; charset=ISO-8859-1 My problem with "Proposed JSON Schema" is not a lack of features but an overabundance of pointless and unnecessary ones. JSON Content Rules looks like a better approach. I am not sure how useful the URI, phone number or email types are but they are probably harmless. Domain names and IP address formats are probably useful. I would probably lose the range constraints on integers, I have not found them remotely useful in a protocol except for things like IPv4 port numbers and even there the constraint probably doesn't help very much. On Thu, Sep 20, 2012 at 8:08 PM, Andrew Newton wrote: > On Thu, Sep 20, 2012 at 7:07 PM, Phillip Hallam-Baker > wrote: > > +1 on the Binary type, I think it is also useful to add in a DateTime > type > > so that protocols do not attempt to roll their own. > > Given that both JSON Content Rules and JSON Schema have both base64 > and dateTime, what's the difference between the base text format > saying a string is base64 or dateTime vs a schema for JSON saying a > string is base64 or dateTime? > > -andy > -- Website: http://hallambaker.com/ --bcaec517a4a063480b04ca2c3672 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My problem with "Proposed JSON Schema" is not a lack of features = but an overabundance of pointless and unnecessary ones.

    = JSON Content Rules looks like a better approach. I am not sure how useful t= he URI, phone number or email types are but they are probably harmless. Dom= ain names and IP address formats are probably useful.

    I would probably lose the range constraints on integers= , I have not found them remotely useful in a protocol except for things lik= e IPv4 port numbers and even there the constraint probably doesn't help= very much.


    On Thu, Sep 20, 2012 at = 8:08 PM, Andrew Newton <andy@hxr.us> wrote:
    On Thu, Sep 20, 2012 at 7:07 PM, Phillip Hallam-Baker <= ;hallam@gmail.com> wrote:
    > +1 on the Binary type, I think it is also useful to add in a DateTime = type
    > so that protocols do not attempt to roll their own.

    Given that both JSON Content Rules and JSON Schema have both base64 and dateTime, what's the difference between the base text format
    saying a string is base64 or dateTime vs a schema for JSON saying a
    string is base64 or dateTime?

    -andy



    --
    Website: http://hallambaker.com/

    --bcaec517a4a063480b04ca2c3672-- From hallam@gmail.com Thu Sep 20 18:45:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9FA21E80A6 for ; Thu, 20 Sep 2012 18:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.912 X-Spam-Level: X-Spam-Status: No, score=-3.912 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzOyDhOnnnRP for ; Thu, 20 Sep 2012 18:45:41 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id D27D621E80A5 for ; Thu, 20 Sep 2012 18:45:40 -0700 (PDT) Received: by oagn5 with SMTP id n5so2532859oag.31 for ; Thu, 20 Sep 2012 18:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fucFNTBcsAKJSIAbcn8kckT2johh+cLPl751oyvp1WU=; b=ocOcCgvmJUx3bwBUDEXmzr13tkI8uS2Q4zYalh/W44mNNNscO7bErwUoAJmy5IyC8X nYY40Pep4JcvQ9jf7toCd3e9FXwvp0I5/S7KrHPzcbPWtEYdKwrmKxlQAPtgibZcgCr8 W7cJCRFWuvnErbX2IVyznT1j90Bm7o5cWlo9QyONE+n2fBdijjy+XgEqE2bSdyu8z23+ w4Aa5LlEUwmrVb9XnBrJtmiKlFxh9OJKe8SO0r4kj7rEB+xjzAx/y32NCubXuETz6pi9 Qg02TKKE3rsB6Y13KU0/IObnefXd8r9rpu0zmIrEvs0oAXlHVyOT/3BdEd8nWRwdfQQD P+jw== MIME-Version: 1.0 Received: by 10.60.25.129 with SMTP id c1mr2700766oeg.36.1348191940365; Thu, 20 Sep 2012 18:45:40 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 18:45:40 -0700 (PDT) In-Reply-To: <1348184984.2900.16.camel@polyglot> References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> <505B8B97.1080906@gmx.de> <1348184984.2900.16.camel@polyglot> Date: Thu, 20 Sep 2012 21:45:40 -0400 Message-ID: From: Phillip Hallam-Baker To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=e89a8ff1c6ceb1ce3f04ca2c65fe Cc: Julian Reschke , Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 01:45:41 -0000 --e89a8ff1c6ceb1ce3f04ca2c65fe Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 20, 2012 at 7:49 PM, Paul C. Bryan wrote: > ** > On Thu, 2012-09-20 at 19:26 -0400, Phillip Hallam-Baker wrote: > > What makes it a security consideration is the possibility that an > ATTACKER might intentionally create a malicious encoding. > > What malicious encoding? Your example wouldn't have been parsed by any > JSON parser I'm familiar with, accidentally or otherwise. > If you have an encoding that depends on correct escaping for safety then the attack is possible. The attack is on the encoder, not the parser. > It is like the fact that C uses a braindead array scheme makes it easy to > create buffer overrun errors that are impossible in BASIC, FORTRAN, Pascal, > C#, Java and pretty much every other language. Relying on programmers to > write correct code without security holes is a bad security practice. > So, you're proposing we indicate under security considerations that > relying on programmers to write correct code without security holes is a > bad security practice? > It is certainly a security concern and in many environments it is not an acceptable practice. The point of having Security Concerns is that they should list the issues that should be verified in a code review. The rules for writing a Security Consideration are that it has to specify all the Security Considerations regardless of whether they are raised elsewhere. That is the point of having it as a mandatory section. > Using a schema tool to generate encoders is usually a sufficient control. > > You don't need a schema tool to encode well-formed JSON. > It is probably a less costly control than code review which is the only alternative I am familiar with. Telling people to just hire competent coders is not an answer, programming is like sex, everybody thinks that they are good at it. It is not a big security concern but it is a concern. > > So you raised it why then? > Because people asked what should go in the security considerations section and I am on the Security Directorate so I was telling people the type of comments I would make if I was reviewing. -- Website: http://hallambaker.com/ --e89a8ff1c6ceb1ce3f04ca2c65fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Thu, Sep 20, 2012 at 7:49 PM, Paul C.= Bryan <pbryan@anode.ca> wrote:
    =20 =20
    On Thu, 2012-09-20 at 19:26 -0400, Phillip Hallam-Baker wrote:

    What makes it a security consideration is the possibility that an ATTAC= KER might intentionally create a malicious encoding.
    What malicious encoding? Your example wouldn't have been parsed by any = JSON parser I'm familiar with, accidentally or otherwise.

    If you have an encoding th= at depends on correct escaping for safety then the attack is possible. The = attack is on the encoder, not the parser.=A0

    =A0
    It is like the fact that C uses a braindead array scheme makes it e= asy to create buffer overrun errors that are impossible in BASIC, FORTRAN, = Pascal, C#, Java and pretty much every other language. Relying on programme= rs to write correct code without security holes is a bad security practice.=
    So, you're proposing we indicate under security considerations that rel= ying on programmers to write correct code without security holes is a bad s= ecurity practice?

    It is certainly a s= ecurity concern and in many environments it is not an acceptable practice.<= /div>

    The point of having Security Concerns is that they shou= ld list the issues that should be verified in a code review.=A0
    <= br>
    The rules for writing a Security Consideration are that it ha= s to specify all the Security Considerations regardless of whether they are= raised elsewhere. That is the point of having it as a mandatory section.
    =A0
    Using a schema tool to generate encoders is usually a sufficient contro= l.
    You don't need a schema tool to encode well-formed JSON.

    It is probably a less costly control than code revi= ew which is the only alternative I am familiar with. Telling people to just= hire competent coders is not an answer, programming is like sex, everybody= thinks that they are good at it.

    It is not a big security concern but it is a concern.
    So you raised it why then?

    Because pe= ople asked what should go in the security considerations section and I am o= n the Security Directorate so I was telling people the type of comments I w= ould make if I was reviewing.=A0


    --
    Website: http://hallambaker.com/

    --e89a8ff1c6ceb1ce3f04ca2c65fe-- From pbryan@anode.ca Thu Sep 20 19:18:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C53C21F8639 for ; Thu, 20 Sep 2012 19:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahf7MSgRbQZ0 for ; Thu, 20 Sep 2012 19:18:52 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2C121F8634 for ; Thu, 20 Sep 2012 19:18:52 -0700 (PDT) Received: from [10.71.13.58] (adsl-75-55-201-218.dsl.pltn13.sbcglobal.net [75.55.201.218]) by maple.anode.ca (Postfix) with ESMTPSA id 15653648C; Fri, 21 Sep 2012 02:18:46 +0000 (UTC) Message-ID: <1348193923.2900.46.camel@polyglot> From: "Paul C. Bryan" To: Phillip Hallam-Baker Date: Thu, 20 Sep 2012 19:18:43 -0700 In-Reply-To: References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> <505B8B97.1080906@gmx.de> <1348184984.2900.16.camel@polyglot> Content-Type: multipart/alternative; boundary="=-w0wBHiLhA2a34oT1DPM5" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: Julian Reschke , Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 02:18:53 -0000 --=-w0wBHiLhA2a34oT1DPM5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2012-09-20 at 21:45 -0400, Phillip Hallam-Baker wrote: > > > > On Thu, Sep 20, 2012 at 7:49 PM, Paul C. Bryan > wrote: > > On Thu, 2012-09-20 at 19:26 -0400, Phillip Hallam-Baker wrote: > > > > What makes it a security consideration is the possibility > > that an ATTACKER might intentionally create a malicious > > encoding. > > What malicious encoding? Your example wouldn't have been > parsed by any JSON parser I'm familiar with, accidentally or > otherwise. > > > > > If you have an encoding that depends on correct escaping for safety > then the attack is possible. The attack is on the encoder, not the > parser. Your example wouldn't have been improperly encoded by any JSON encoder I'm familiar with, accidentally or otherwise. Can you provide a concrete example of this attack? > It is like the fact that C uses a braindead array scheme makes > it easy to create buffer overrun errors that are impossible in > BASIC, FORTRAN, Pascal, C#, Java and pretty much every other > language. Relying on programmers to write correct code without > security holes is a bad security practice. > > So, you're proposing we indicate under security considerations > that relying on programmers to write correct code without > security holes is a bad security practice? > > > It is certainly a security concern and in many environments it is not > an acceptable practice. So your answer is, yes, you're recommending such an addition? Is there precedence in an RFC where such text exists under security considerations? > The point of having Security Concerns is that they should list the > issues that should be verified in a code review. Is this purpose documented somewhere normative, or your professional opinion? I don't see anything about code reviews in RFC 2223 or 3552. > The rules for writing a Security Consideration are that it has to > specify all the Security Considerations regardless of whether they are > raised elsewhere. That is the point of having it as a mandatory > section. Are such rules documented somewhere, or your opinion? I don't see anything about needing to specify ALL security considerations, no matter where they are raised, or how pertinent they may (or may not!) be. > > Using a schema tool to generate encoders is usually a > > sufficient control. > > You don't need a schema tool to encode well-formed JSON. > > > It is probably a less costly control than code review which is the > only alternative I am familiar with. Telling people to just hire > competent coders is not an answer, programming is like sex, everybody > thinks that they are good at it. It's unclear to me how this anecdote may be relevant to the topic at hand. Are you suggesting others here are advocating telling people to just hire competent coders? I've not heard anyone take such a position on this list. > > It is not a big security concern but it is a concern. > > So you raised it why then? > > > Because people asked what should go in the security considerations > section and I am on the Security Directorate so I was telling people > the type of comments I would make if I was reviewing. Is there a security consideration that you would consider unsuitable for inclusion in the security considerations section? If, for example, I were to hypothesize of a vector of attack against JSON that only works should its text is encoded on punched cards in a character encoding of my own invention, would you consider this worthy of inclusion? Paul --=-w0wBHiLhA2a34oT1DPM5 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 2012-09-20 at 21:45 -0400, Phillip Hallam-Baker wrote:


    On Thu, Sep 20, 2012 at 7:49 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
    On Thu, 2012-09-20 at 19:26 -0400, Phillip Hallam-Baker wrote:

    What makes it a security consideration is the possibility that an ATTACKER might intentionally create a malicious encoding.
    What malicious encoding? Your example wouldn't have been parsed by any JSON parser I'm familiar with, accidentally or otherwise.



    If you have an encoding that depends on correct escaping for safety then the attack is possible. The attack is on the encoder, not the parser. 

    Your example wouldn't have been improperly encoded by any JSON encoder I'm familiar with, accidentally or otherwise. Can you provide a concrete example of this attack?

    It is like the fact that C uses a braindead array scheme makes it easy to create buffer overrun errors that are impossible in BASIC, FORTRAN, Pascal, C#, Java and pretty much every other language. Relying on programmers to write correct code without security holes is a bad security practice.
    So, you're proposing we indicate under security considerations that relying on programmers to write correct code without security holes is a bad security practice?


    It is certainly a security concern and in many environments it is not an acceptable practice.

    So your answer is, yes, you're recommending such an addition? Is there precedence in an RFC where such text exists under security considerations? 

    The point of having Security Concerns is that they should list the issues that should be verified in a code review.

    Is this purpose documented somewhere normative, or your professional opinion? I don't see anything about code reviews in RFC 2223 or 3552.

    The rules for writing a Security Consideration are that it has to specify all the Security Considerations regardless of whether they are raised elsewhere. That is the point of having it as a mandatory section.

    Are such rules documented somewhere, or your opinion? I don't see anything about needing to specify ALL security considerations, no matter where they are raised, or how pertinent they may (or may not!) be.   


    Using a schema tool to generate encoders is usually a sufficient control.
    You don't need a schema tool to encode well-formed JSON.


    It is probably a less costly control than code review which is the only alternative I am familiar with. Telling people to just hire competent coders is not an answer, programming is like sex, everybody thinks that they are good at it.

    It's unclear to me how this anecdote may be relevant to the topic at hand. Are you suggesting others here are advocating telling people to just hire competent coders? I've not heard anyone take such a position on this list.

    It is not a big security concern but it is a concern.
    So you raised it why then?


    Because people asked what should go in the security considerations section and I am on the Security Directorate so I was telling people the type of comments I would make if I was reviewing.

    Is there a security consideration that you would consider unsuitable for inclusion in the security considerations section? If, for example, I were to hypothesize of a vector of attack against JSON that only works should its text is encoded on punched cards in a character encoding of my own invention, would you consider this worthy of inclusion?
    Paul --=-w0wBHiLhA2a34oT1DPM5-- From hallam@gmail.com Thu Sep 20 19:32:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E0D21F8674 for ; Thu, 20 Sep 2012 19:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.908 X-Spam-Level: X-Spam-Status: No, score=-3.908 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6I62Vl1Rpne for ; Thu, 20 Sep 2012 19:32:09 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5508E21F866E for ; Thu, 20 Sep 2012 19:32:09 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3141345obb.31 for ; Thu, 20 Sep 2012 19:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UwUcDfABlcpBvm1aVI+eQxd9Z/GgKho7styZmfwGZr4=; b=zzaYlk5bOQL6zwwgUj5NW3PAenLnBqDDpxZ17vaOzePZlQnuWRRXiM01b2WebUkbIN BCOaRCSq0Gl7qIW760OubHFRFhSra3NbtEAdFaUkoLMjnXqfKDfcdyclyoyCw/AXGfdH bohWwFn4Dngviggxcln3jezkQj2RbbQ/SiGFQkvBUmRMDFG09vGy+/rofkyiZTxY7iz2 1IXE2EBmuS0U/aaL6RiqrW2l+RUAQNjsuLjA/uaQskph4K1Iqk22XLr2Z52Xpi4SuPcW ZSOlHcnyITIywWfZOGCbja6zFPNTZ2CgXIaUZpZELGIaGuumlJeguvPLPcorYtvi1mum aj+A== MIME-Version: 1.0 Received: by 10.60.172.236 with SMTP id bf12mr2801572oec.23.1348194728987; Thu, 20 Sep 2012 19:32:08 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Thu, 20 Sep 2012 19:32:08 -0700 (PDT) In-Reply-To: <1348193923.2900.46.camel@polyglot> References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> <505B8B97.1080906@gmx.de> <1348184984.2900.16.camel@polyglot> <1348193923.2900.46.camel@polyglot> Date: Thu, 20 Sep 2012 22:32:08 -0400 Message-ID: From: Phillip Hallam-Baker To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=bcaec54d4768e8cd1504ca2d0bb7 Cc: Julian Reschke , Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 02:32:10 -0000 --bcaec54d4768e8cd1504ca2d0bb7 Content-Type: text/plain; charset=ISO-8859-1 Do your encoding with a call to printf as I originally suggested and fail to wrap the data value with a call to a routine to escape the string and you will get the vulnerability I cite. This is really not an obscure attack. It is the JSON equivalent of attacks that account for a huge proportion of attacks right now. In fact with the deployment of DEP and similar and the easy ways to do a buffer overrun bug being closed [1] they are probably the most common form of vulnerability right now. [1] Yeah there is still re-entrant code but most hackers haven't got the chops for that, code injection is a much easier game. On Thu, Sep 20, 2012 at 10:18 PM, Paul C. Bryan wrote: > ** > On Thu, 2012-09-20 at 21:45 -0400, Phillip Hallam-Baker wrote: > > > > On Thu, Sep 20, 2012 at 7:49 PM, Paul C. Bryan wrote: > > On Thu, 2012-09-20 at 19:26 -0400, Phillip Hallam-Baker wrote: > > What makes it a security consideration is the possibility that an > ATTACKER might intentionally create a malicious encoding. > > What malicious encoding? Your example wouldn't have been parsed by any > JSON parser I'm familiar with, accidentally or otherwise. > > > > > If you have an encoding that depends on correct escaping for safety then > the attack is possible. The attack is on the encoder, not the parser. > > > Your example wouldn't have been improperly encoded by any JSON encoder I'm > familiar with, accidentally or otherwise. Can you provide a concrete > example of this attack? > > > It is like the fact that C uses a braindead array scheme makes it easy > to create buffer overrun errors that are impossible in BASIC, FORTRAN, > Pascal, C#, Java and pretty much every other language. Relying on > programmers to write correct code without security holes is a bad security > practice. > > So, you're proposing we indicate under security considerations that > relying on programmers to write correct code without security holes is a > bad security practice? > > > > It is certainly a security concern and in many environments it is not an > acceptable practice. > > > So your answer is, yes, you're recommending such an addition? Is there > precedence in an RFC where such text exists under security considerations? > > The point of having Security Concerns is that they should list the issues > that should be verified in a code review. > > > Is this purpose documented somewhere normative, or your professional > opinion? I don't see anything about code reviews in RFC 2223 or 3552. > > > The rules for writing a Security Consideration are that it has to specify > all the Security Considerations regardless of whether they are raised > elsewhere. That is the point of having it as a mandatory section. > > > Are such rules documented somewhere, or your opinion? I don't see anything > about needing to specify ALL security considerations, no matter where they > are raised, or how pertinent they may (or may not!) be. > > > Using a schema tool to generate encoders is usually a sufficient > control. > > You don't need a schema tool to encode well-formed JSON. > > > > It is probably a less costly control than code review which is the only > alternative I am familiar with. Telling people to just hire competent > coders is not an answer, programming is like sex, everybody thinks that > they are good at it. > > > It's unclear to me how this anecdote may be relevant to the topic at hand. > Are you suggesting others here are advocating telling people to just hire > competent coders? I've not heard anyone take such a position on this list. > > > It is not a big security concern but it is a concern. > > So you raised it why then? > > > > Because people asked what should go in the security considerations > section and I am on the Security Directorate so I was telling people the > type of comments I would make if I was reviewing. > > > Is there a security consideration that you would consider unsuitable for > inclusion in the security considerations section? If, for example, I were > to hypothesize of a vector of attack against JSON that only works should > its text is encoded on punched cards in a character encoding of my own > invention, would you consider this worthy of inclusion? > Paul > -- Website: http://hallambaker.com/ --bcaec54d4768e8cd1504ca2d0bb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Do your encoding with a call to printf as I originally suggested and fail t= o wrap the data value with a call to a routine to escape the string and you= will get the vulnerability I cite.

    This is really not a= n obscure attack. It is the JSON equivalent of attacks that account for a h= uge proportion of attacks right now. In fact with the deployment of DEP and= similar and the easy ways to do a buffer overrun bug being closed [1] they= are probably the most common form of vulnerability right now.=A0


    [1] Yeah there is still re-entrant code but most hackers haven'= t got the chops for that, code injection is a much easier game.

    On Thu, Sep 20, 2012 at 10:18 PM, Paul C. Bryan <pbry= an@anode.ca> wrote:
    =20 =20
    On Thu, 2012-09-20 at 21:45 -0400, Phillip Hallam-Baker wrote:


    On Thu, Sep 20, 2012 at 7:49 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
    On Thu, 2012-09-20 at 19:26 -0400, Phillip Hallam-Baker wrote:

    What makes it a security consideration is the possibility that = an ATTACKER might intentionally create a malicious encoding.
    What malicious encoding? Your example wouldn't have been parsed= by any JSON parser I'm familiar with, accidentally or otherwise.



    If you have an encoding that depends on correct escaping for safety the= n the attack is possible. The attack is on the encoder, not the parser.=A0

    Your example wouldn't have been improperly encoded by any JSON encoder = I'm familiar with, accidentally or otherwise. Can you provide a concret= e example of this attack?


    It is like the fact that C uses a braindead array scheme makes it e= asy to create buffer overrun errors that are impossible in BASIC, FORTRAN, = Pascal, C#, Java and pretty much every other language. Relying on programme= rs to write correct code without security holes is a bad security practice.
    So, you're proposing we indicate under security considerations = that relying on programmers to write correct code without security holes is= a bad security practice?


    It is certainly a security concern and in many environments it is not a= n acceptable practice.

    So your answer is, yes, you're recommending such an addition? Is there = precedence in an RFC where such text exists under security considerations?= =A0

    The point of having Security Concerns is that they should list the issu= es that should be verified in a code review.

    Is this purpose documented somewhere normative, or your professional opinio= n? I don't see anything about code reviews in RFC 2223 or 3552.


    The rules for writing a Security Consideration are that it has to speci= fy all the Security Considerations regardless of whether they are raised el= sewhere. That is the point of having it as a mandatory section.

    Are such rules documented somewhere, or your opinion? I don't see anyth= ing about needing to specify ALL security considerations, no matter where t= hey are raised, or how pertinent they may (or may not!) be.=A0=A0=A0


    Using a schema tool to generate encoders is usually a sufficien= t control.
    You don't need a schema tool to encode well-formed JSON.


    It is probably a less costly control than code review which is the only= alternative I am familiar with. Telling people to just hire competent code= rs is not an answer, programming is like sex, everybody thinks that they ar= e good at it.

    It's unclear to me how this anecdote may be relevant to the topic at ha= nd. Are you suggesting others here are advocating telling people to just hi= re competent coders? I've not heard anyone take such a position on this= list.


    It is not a big security concern but it is a concern.
    So you raised it why then?


    Because people asked what should go in the security considerations sect= ion and I am on the Security Directorate so I was telling people the type o= f comments I would make if I was reviewing.

    Is there a security consideration that you would consider unsuitable for in= clusion in the security considerations section? If, for example, I were to = hypothesize of a vector of attack against JSON that only works should its t= ext is encoded on punched cards in a character encoding of my own invention= , would you consider this worthy of inclusion?
    Paul



    --
    Website: http://hallambaker.com/

    --bcaec54d4768e8cd1504ca2d0bb7-- From pbryan@anode.ca Thu Sep 20 20:08:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6080F11E8099 for ; Thu, 20 Sep 2012 20:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdKG2RZTUrfu for ; Thu, 20 Sep 2012 20:08:56 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 649AF11E808A for ; Thu, 20 Sep 2012 20:08:56 -0700 (PDT) Received: from [10.71.13.58] (adsl-75-55-201-218.dsl.pltn13.sbcglobal.net [75.55.201.218]) by maple.anode.ca (Postfix) with ESMTPSA id 5F14B6156; Fri, 21 Sep 2012 03:08:48 +0000 (UTC) Message-ID: <1348196927.2900.71.camel@polyglot> From: "Paul C. Bryan" To: Phillip Hallam-Baker Date: Thu, 20 Sep 2012 20:08:47 -0700 In-Reply-To: References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> <505B8B97.1080906@gmx.de> <1348184984.2900.16.camel@polyglot> <1348193923.2900.46.camel@polyglot> Content-Type: multipart/alternative; boundary="=-bW6htcGP6BYw5PM02IFd" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: Julian Reschke , Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 03:08:59 -0000 --=-bW6htcGP6BYw5PM02IFd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Thu, 2012-09-20 at 22:32 -0400, Phillip Hallam-Baker wrote: > Do your encoding with a call to printf as I originally suggested and > fail to wrap the data value with a call to a routine to escape the > string and you will get the vulnerability I cite. So if I understand your position correctly, a vulnerability in the use of C's printf function is worthy of publication under JSON's security considerations. By this logic, this same vulnerability should be cited in the security considerations section of every conceivable protocol where one may ever possibly (even unreasonably) use C's printf function, which means virtually any text-encoding protocol. Is this correct? > This is really not an obscure attack. It is the JSON equivalent of > attacks that account for a huge proportion of attacks right now. In > fact with the deployment of DEP and similar and the easy ways to do a > buffer overrun bug being closed [1] they are probably the most common > form of vulnerability right now. I don't quarrel with your assertion that bad formatting functions in languages can expose security vulnerabilities. However, I don't think your voluminous and strongly worded suggestions that we should cite every conceivable vulnerability—despite the nature or relevance to the protocol specifically—is either realistic or helpful. > [1] Yeah there is still re-entrant code but most hackers haven't got > the chops for that, code injection is a much easier game. Uh huh. Paul > On Thu, Sep 20, 2012 at 10:18 PM, Paul C. Bryan > wrote: > > On Thu, 2012-09-20 at 21:45 -0400, Phillip Hallam-Baker wrote: > > > > > > > On Thu, Sep 20, 2012 at 7:49 PM, Paul C. Bryan > > wrote: > > > > On Thu, 2012-09-20 at 19:26 -0400, Phillip > > Hallam-Baker wrote: > > > > > > > What makes it a security consideration is the > > > possibility that an ATTACKER might intentionally > > > create a malicious encoding. > > > > What malicious encoding? Your example wouldn't have > > been parsed by any JSON parser I'm familiar with, > > accidentally or otherwise. > > > > > > > > > > If you have an encoding that depends on correct escaping for > > safety then the attack is possible. The attack is on the > > encoder, not the parser. > > > > > Your example wouldn't have been improperly encoded by any JSON > encoder I'm familiar with, accidentally or otherwise. Can you > provide a concrete example of this attack? > > > > > > It is like the fact that C uses a braindead array > > scheme makes it easy to create buffer overrun errors > > that are impossible in BASIC, FORTRAN, Pascal, C#, > > Java and pretty much every other language. Relying > > on programmers to write correct code without > > security holes is a bad security practice. > > So, you're proposing we indicate under security > > considerations that relying on programmers to write > > correct code without security holes is a bad > > security practice? > > > > > > > > It is certainly a security concern and in many environments > > it is not an acceptable practice. > > > > > So your answer is, yes, you're recommending such an addition? > Is there precedence in an RFC where such text exists under > security considerations? > > > > > The point of having Security Concerns is that they should > > list the issues that should be verified in a code review. > > > > > Is this purpose documented somewhere normative, or your > professional opinion? I don't see anything about code reviews > in RFC 2223 or 3552. > > > > > > The rules for writing a Security Consideration are that it > > has to specify all the Security Considerations regardless of > > whether they are raised elsewhere. That is the point of > > having it as a mandatory section. > > > > > Are such rules documented somewhere, or your opinion? I don't > see anything about needing to specify ALL security > considerations, no matter where they are raised, or how > pertinent they may (or may not!) be. > > > > > > > Using a schema tool to generate encoders is > > > usually a sufficient control. > > > > You don't need a schema tool to encode well-formed > > JSON. > > > > > > > > It is probably a less costly control than code review which > > is the only alternative I am familiar with. Telling people > > to just hire competent coders is not an answer, programming > > is like sex, everybody thinks that they are good at it. > > > > > It's unclear to me how this anecdote may be relevant to the > topic at hand. Are you suggesting others here are advocating > telling people to just hire competent coders? I've not heard > anyone take such a position on this list. > > > > > > > It is not a big security concern but it is a > > > concern. > > > > So you raised it why then? > > > > > > > > Because people asked what should go in the security > > considerations section and I am on the Security Directorate > > so I was telling people the type of comments I would make if > > I was reviewing. > > > > > Is there a security consideration that you would consider > unsuitable for inclusion in the security considerations > section? If, for example, I were to hypothesize of a vector of > attack against JSON that only works should its text is encoded > on punched cards in a character encoding of my own invention, > would you consider this worthy of inclusion? > Paul > > > > > > > > -- > Website: http://hallambaker.com/ > > --=-bW6htcGP6BYw5PM02IFd Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 2012-09-20 at 22:32 -0400, Phillip Hallam-Baker wrote:
    Do your encoding with a call to printf as I originally suggested and fail to wrap the data value with a call to a routine to escape the string and you will get the vulnerability I cite.

    So if I understand your position correctly, a vulnerability in the use of C's printf function is worthy of publication under JSON's security considerations. By this logic, this same vulnerability should be cited in the security considerations section of every conceivable protocol where one may ever possibly (even unreasonably) use C's printf function, which means virtually any text-encoding protocol. Is this correct?
    This is really not an obscure attack. It is the JSON equivalent of attacks that account for a huge proportion of attacks right now. In fact with the deployment of DEP and similar and the easy ways to do a buffer overrun bug being closed [1] they are probably the most common form of vulnerability right now.

    I don't quarrel with your assertion that bad formatting functions in languages can expose security vulnerabilities. However, I don't think your voluminous and strongly worded suggestions that we should cite every conceivable vulnerability—despite the nature or relevance to the protocol specifically—is either realistic or helpful.

    [1] Yeah there is still re-entrant code but most hackers haven't got the chops for that, code injection is a much easier game.

    Uh huh.

    Paul

    On Thu, Sep 20, 2012 at 10:18 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
    On Thu, 2012-09-20 at 21:45 -0400, Phillip Hallam-Baker wrote:


    On Thu, Sep 20, 2012 at 7:49 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
    On Thu, 2012-09-20 at 19:26 -0400, Phillip Hallam-Baker wrote:

    What makes it a security consideration is the possibility that an ATTACKER might intentionally create a malicious encoding.
    What malicious encoding? Your example wouldn't have been parsed by any JSON parser I'm familiar with, accidentally or otherwise.



    If you have an encoding that depends on correct escaping for safety then the attack is possible. The attack is on the encoder, not the parser. 


    Your example wouldn't have been improperly encoded by any JSON encoder I'm familiar with, accidentally or otherwise. Can you provide a concrete example of this attack?


    It is like the fact that C uses a braindead array scheme makes it easy to create buffer overrun errors that are impossible in BASIC, FORTRAN, Pascal, C#, Java and pretty much every other language. Relying on programmers to write correct code without security holes is a bad security practice.
    So, you're proposing we indicate under security considerations that relying on programmers to write correct code without security holes is a bad security practice?


    It is certainly a security concern and in many environments it is not an acceptable practice.


    So your answer is, yes, you're recommending such an addition? Is there precedence in an RFC where such text exists under security considerations? 

    The point of having Security Concerns is that they should list the issues that should be verified in a code review.


    Is this purpose documented somewhere normative, or your professional opinion? I don't see anything about code reviews in RFC 2223 or 3552.


    The rules for writing a Security Consideration are that it has to specify all the Security Considerations regardless of whether they are raised elsewhere. That is the point of having it as a mandatory section.


    Are such rules documented somewhere, or your opinion? I don't see anything about needing to specify ALL security considerations, no matter where they are raised, or how pertinent they may (or may not!) be.   


    Using a schema tool to generate encoders is usually a sufficient control.
    You don't need a schema tool to encode well-formed JSON.


    It is probably a less costly control than code review which is the only alternative I am familiar with. Telling people to just hire competent coders is not an answer, programming is like sex, everybody thinks that they are good at it.


    It's unclear to me how this anecdote may be relevant to the topic at hand. Are you suggesting others here are advocating telling people to just hire competent coders? I've not heard anyone take such a position on this list.


    It is not a big security concern but it is a concern.
    So you raised it why then?


    Because people asked what should go in the security considerations section and I am on the Security Directorate so I was telling people the type of comments I would make if I was reviewing.


    Is there a security consideration that you would consider unsuitable for inclusion in the security considerations section? If, for example, I were to hypothesize of a vector of attack against JSON that only works should its text is encoded on punched cards in a character encoding of my own invention, would you consider this worthy of inclusion?
    Paul




    --
    Website: http://hallambaker.com/



    --=-bW6htcGP6BYw5PM02IFd-- From James.H.Manger@team.telstra.com Thu Sep 20 21:43:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF9A21E80B0 for ; Thu, 20 Sep 2012 21:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKzdH+v6cNiR for ; Thu, 20 Sep 2012 21:43:40 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6BA21E80AF for ; Thu, 20 Sep 2012 21:43:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,459,1344175200"; d="scan'208";a="93828884" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 21 Sep 2012 14:43:37 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6841"; a="126100247" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcavi.tcif.telstra.com.au with ESMTP; 21 Sep 2012 14:43:37 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Fri, 21 Sep 2012 14:43:35 +1000 From: "Manger, James H" To: "Paul C. Bryan" , Phillip Hallam-Baker Date: Fri, 21 Sep 2012 14:43:34 +1000 Thread-Topic: [apps-discuss] Guidance on RFC 4627 as reference Thread-Index: Ac2XpnfEUhJbSs3gQayRnLdglHhacAADI5RA Message-ID: <255B9BB34FB7D647A506DC292726F6E114FD2AA194@WSMSG3153V.srv.dir.telstra.com> References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> <505B8B97.1080906@gmx.de> <1348184984.2900.16.camel@polyglot> <1348193923.2900.46.camel@polyglot> <1348196927.2900.71.camel@polyglot> In-Reply-To: <1348196927.2900.71.camel@polyglot> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 04:43:41 -0000 PiBEbyB5b3VyIGVuY29kaW5nIHdpdGggYSBjYWxsIHRvIHByaW50ZiBhcyBJIG9yaWdpbmFsbHkg c3VnZ2VzdGVkIGFuZA0KPiBmYWlsIHRvIHdyYXAgdGhlIGRhdGEgdmFsdWUgd2l0aCBhIGNhbGwg dG8gYSByb3V0aW5lIHRvIGVzY2FwZSB0aGUNCj4gc3RyaW5nIGFuZCB5b3Ugd2lsbCBnZXQgdGhl IHZ1bG5lcmFiaWxpdHkgSSBjaXRlLg0KDQo+PiBZb3VyIGV4YW1wbGUgd291bGRuJ3QgaGF2ZSBi ZWVuIGltcHJvcGVybHkgZW5jb2RlZCBieSBhbnkgSlNPTiBlbmNvZGVyDQo+PiBJJ20gZmFtaWxp YXIgd2l0aCwgYWNjaWRlbnRhbGx5IG9yIG90aGVyd2lzZS4NCg0KSGVuY2UgdGhlIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gc2hvdWxkIHRlbGwgcGVvcGxlIHRvIHVzZSBhIGRlZGlj YXRlZCBKU09OIGVuY29kZXIgaW5zdGVhZCBvZiB3cml0aW5nIEpTT04gYnkgaGFuZCB3aXRoIHBy aW50ZiBjYWxscywgc2luY2UgaXQgaXMgdG9vIGVhc3kgdG8gbWFrZSBlc2NhcGluZyBlcnJvciB3 aXRoIHRoZSBsYXR0ZXIgYXBwcm9hY2guDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From julian.reschke@gmx.de Thu Sep 20 23:57:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DD421F8692 for ; Thu, 20 Sep 2012 23:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hNqyxpHwdab for ; Thu, 20 Sep 2012 23:57:32 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 066BE21F8661 for ; Thu, 20 Sep 2012 23:57:31 -0700 (PDT) Received: (qmail invoked by alias); 21 Sep 2012 06:57:30 -0000 Received: from p5DD957E3.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.87.227] by mail.gmx.net (mp028) with SMTP; 21 Sep 2012 08:57:30 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18xbTwKAXUx0TaMjNTTwZhxj2kML/mnMc7rDsjIXS TkwObfV0G89y5f Message-ID: <505C0FCA.6010409@gmx.de> Date: Fri, 21 Sep 2012 08:57:14 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ned Freed References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <01OKHBU81QWO0006TF@mauve.mrochek.com> <505B85EA.2080901@gmx.de> <01OKHHN30INI0006TF@mauve.mrochek.com> In-Reply-To: <01OKHHN30INI0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 06:57:33 -0000 On 2012-09-21 01:36, Ned Freed wrote: > ... >> Of course you can define uses of JSON (or text/plain, or text/xml, or >> ...) that have executable semantics on a different layer, but that's not >> what I was referring to. > > But it isn't what was being discussed in the message you were responding > to. > If you want to change the subject, you need to say as much. > ... For the record: I didn't want to change the topic (nor did I, I think). Best regards, Julian From julian.reschke@gmx.de Fri Sep 21 00:02:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63B421F869F for ; Fri, 21 Sep 2012 00:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.476 X-Spam-Level: X-Spam-Status: No, score=-103.476 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdAX5EPuInVt for ; Fri, 21 Sep 2012 00:02:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E911A21F8692 for ; Fri, 21 Sep 2012 00:02:04 -0700 (PDT) Received: (qmail invoked by alias); 21 Sep 2012 07:02:03 -0000 Received: from p5DD957E3.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.87.227] by mail.gmx.net (mp030) with SMTP; 21 Sep 2012 09:02:03 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19HC8pRBrJH11C6q9CF10kTjf8WO4p6bb4wpj4vGB yhJwifo7gPe6TE Message-ID: <505C10DB.5080401@gmx.de> Date: Fri, 21 Sep 2012 09:01:47 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 07:02:05 -0000 On 2012-09-21 01:35, Phillip Hallam-Baker wrote: > ... > I'm sorry, but I must have missed something. Are we playing a game > of State the Obvious now? > > Bingo! > > Yes, we are playing a game of state the obvious because that is what > most security issues tend to end up being. If you have a million lines > of code then the chance of at least one of them having an obvious error > is pretty much 100%. It is rather obvious that a buffer overrun is > likely to be a bad thing but it took over a decade for people to realize > that it allowed people to smash the stack and pown the machine. > And given that it has taken us the best part of a day to get to the > point where the explanation is obvious I think that the problem itself > is far from obvious. > > > This attack vector (in different incarnations) is currently the most > commonly used attack against Web Services. > ... I personally don't believe that "stating the obvious" is something we should do in Security Considerations. First, because those implementers who even get the obvious things wrong are unlikely to even look at the spec. Second, because adding tons of "obvious" things to the SC totally distracts from the *non-obvious* things. Now what's obvious and what's not of course depends on the background. Anybody who has dealt with HTML and XML professionally should know that constructing messages with simple string operations is dangerous. Maybe that's something that's not was obvious in the JSON world yet. Best regards, Julian From duerst@it.aoyama.ac.jp Fri Sep 21 01:45:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4263C21F8679 for ; Fri, 21 Sep 2012 01:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.963 X-Spam-Level: X-Spam-Status: No, score=-101.963 tagged_above=-999 required=5 tests=[AWL=-2.173, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rf75M+8sDgsH for ; Fri, 21 Sep 2012 01:45:07 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id BD6A921F8661 for ; Fri, 21 Sep 2012 01:45:05 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q8L8itNt006005 for ; Fri, 21 Sep 2012 17:44:55 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 5a32_ae29_9dcb5a0a_03c8_11e2_987a_001d096c566a; Fri, 21 Sep 2012 17:44:54 +0900 Received: from [IPv6:::1] ([133.2.210.1]:50783) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 21 Sep 2012 17:44:56 +0900 Message-ID: <505C2901.1030902@it.aoyama.ac.jp> Date: Fri, 21 Sep 2012 17:44:49 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tim Bray References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> <77AFECFB-F63A-457F-9C7F-F715315C0651@mnot.net> <505B78B4.80309@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Mark Nottingham , dcrocker@bbiw.net, apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 08:45:08 -0000 On 2012/09/21 5:20, Tim Bray wrote: > Frankly that notion had never crossed my mind, but is there a case for a > “Tao of network protocols” or an “Informational BCP” or some such? I could > put some cycles into it. -T What about doing it in the style of http://tools.ietf.org/html/rfc3470, or maybe even as an update of tha document? Regards, Martin. > On Thu, Sep 20, 2012 at 1:12 PM, Dave Crocker wrote: > >> >> >> On 9/20/2012 1:05 PM, Mark Nottingham wrote: >> >>> >>> On 20/09/2012, at 9:53 AM, Tim Bray wrote: >>> >>> I believe: >>>> - ASN.1 has been bypassed by history and has truly horrible tooling. >>>> Just don’t go there. >>>> - If you’re interchanging documents, use XML; if (much more common) >>>> you’re interchanging data structures, use JSON. >>>> - Do not use multiple syntaxes for the same protocol. Pick one of XML or >>>> JSON and stick with it. >>>> - The most important thing in defining a protocol is good clean >>>> comprehensible human-readable prose. >>>> - All the protocols I’ve ever seen have important constraints that can’t >>>> be expressed usefully in declarative schema languages. >>>> - Therefore, the next most important thing is an automated >>>> validator/test-suite. >>>> - A schema is a nice-to-have. >>>> - If you’re in XML and want schema-ware, use RelaxNG. For an example, >>>> see RFC4287. >>>> - If your protocol is JSON, investment in a validator/test-suite has >>>> much higher ROI than chasing schema unicorns. >>>> >>> >>> +1; somebody please give this a BCP#. >>> >> >> >> In its current form, perhaps not. >> >> On the other hand, something along this lines could provide exremely >> useful pedagogy in doing specifications work. >> >> It would, of course, need rather more verbose discussion/justification of >> its guidance. >> >> That is, something that says what the characteristics are of the better >> formal notation choices are and what the characteristics of the less better >> ones are. Then describes the better choices and their enticing features, >> perhaps in terms of tradeoffs. >> >> Then meta-points, such as "choose exactly one". Etc. >> >> d/ >> >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From duerst@it.aoyama.ac.jp Fri Sep 21 02:17:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F5021F875C for ; Fri, 21 Sep 2012 02:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[AWL=-1.901, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sn4SbhzxtABx for ; Fri, 21 Sep 2012 02:17:31 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8535721F871C for ; Fri, 21 Sep 2012 02:17:28 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q8L9HH78028558 for ; Fri, 21 Sep 2012 18:17:18 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 5a30_baf6_23d8905a_03cd_11e2_b11e_001d096c566a; Fri, 21 Sep 2012 18:17:17 +0900 Received: from [IPv6:::1] ([133.2.210.1]:40067) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 21 Sep 2012 18:17:19 +0900 Message-ID: <505C3098.3030209@it.aoyama.ac.jp> Date: Fri, 21 Sep 2012 18:17:12 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Carsten Bormann References: <1348178993.2900.0.camel@polyglot> <08D741A0-6449-41BD-9C10-FA67942B91E4@tzi.org> In-Reply-To: <08D741A0-6449-41BD-9C10-FA67942B91E4@tzi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 09:17:32 -0000 On 2012/09/21 8:46, Carsten Bormann wrote: > On Sep 21, 2012, at 00:23, Nico Williams wrote: > >> Dunno. But here's what I'm looking for: >> >> - strings: '...' >> - octet strings: x'' or b'' > > Indeed. The problem is not that the binary data has to be carried around in some encoded text form, but that it is not identified as binary data. > (Lose the hex idea, though. Unneeded choice.) > Which raises the question: What is the status on binary data (really: byte strings) in ECMAscript? Last I heard (that was in a WebSocket discussion, so it must be a year or two ago), it was being worked on. WebSocket has both text (UTF-8) and binary messages, and in order to handle binary messages in JavaScript, a binary datatype is needed. Just checked a bit now, found e.g. https://developer.mozilla.org/en-US/docs/JavaScript_typed_arrays/ArrayBuffer. It looks like rather than using a very simple datatype with a literal syntax, they went for a rather complex architecture. They must have had their reasons, but please don't ask me why. If the above is true, then introducing something like b'' would mean JSON is no longer a subset of JS. Regards, Martin. From hannes.tschofenig@gmx.net Fri Sep 21 02:18:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C0721F8652 for ; Fri, 21 Sep 2012 02:18:40 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzfO0kGnS05K for ; Fri, 21 Sep 2012 02:18:40 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 02CC221F8646 for ; Fri, 21 Sep 2012 02:18:39 -0700 (PDT) Received: (qmail invoked by alias); 21 Sep 2012 09:18:37 -0000 Received: from unknown (EHLO [10.255.133.193]) [194.251.119.201] by mail.gmx.net (mp010) with SMTP; 21 Sep 2012 11:18:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/ZU3wncMvZjyHV5gTOueUyLyaFO6p59A8wyv8Vm+ txpi9U3685N5v+ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <505B43B3.7050503@berkeley.edu> Date: Fri, 21 Sep 2012 12:18:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> To: Erik Wilde X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 09:18:41 -0000 On Sep 20, 2012, at 7:26 PM, Erik Wilde wrote: > i have to admit that i am really curious why the seasoned spec writers = that have voiced general concerns about the usefulness of schema = languages are feeling this way, but so far i have not really understood = what they are saying. could somebody please try again, i'd really like = to understand why the general idea of describing protocol syntax in a = semi-formal (as opposed to non-formal) way is considered a bad idea. I don't think that arguing are against the usage of formal or = semi-formal ways to describe protocols. Pseudo code may be a useful way = to describe an algorithm, for example. The issue is just that they have = to be applied selectively and carefully. There has to be a real benefit.=20= In the context of this discussion I had been arguing that XML schemas = (and Relax NG schemas) had not been useful for the target audience = compared to the benefits they claimed to provide. For that reason I = argued that we should discourage people from using them since they cause = problems for extensibility, specification quality, and readability.=20 I like the tool idea that PhB and Tim had brought up. I also think that = examples are the most valuable tool for implementers.=20 Ciao Hannes From andy@hxr.us Fri Sep 21 06:00:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D8621F870B for ; Fri, 21 Sep 2012 06:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ox9eA7AFLiP for ; Fri, 21 Sep 2012 06:00:53 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BFECA21F8705 for ; Fri, 21 Sep 2012 06:00:52 -0700 (PDT) Received: by lboj14 with SMTP id j14so3664364lbo.31 for ; Fri, 21 Sep 2012 06:00:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=G2QBhmYpOr+HiTIFJPifKXaaIMyYmZ8VCAwIwamqmdc=; b=lX+DBSvCoepHgNG7jeE/iq0amnquYzs3ecdWqFfJTAkRBiDgDben2KuAWBFerllNfI mbY2GFx+ryKo7mUKKBxJlTXzINqUZnIgYdgGqcgBJ7xTQ+zUXMtFySl1VTleokg3+oig eG2V0jeCo+PkvamkXWIYUkfPm3QB9d/7EfXiZKPPsepIBL0NsGjxMay4DAXN6Jvg6sj9 K/1WdKpypz2Iuj58jc8ofoYWmQ1Cggl49ZHYemNe8r9K+SKOX1yXcPyaKKWj2bIpvd+L T5FzWFlUjbpHeJnB4q0MyWjdmQt8/Ampun5T6n8Ncqa9cZJDs65I2pTcUhZtYP5/kzd2 ICYQ== MIME-Version: 1.0 Received: by 10.152.114.5 with SMTP id jc5mr4286028lab.36.1348232451688; Fri, 21 Sep 2012 06:00:51 -0700 (PDT) Received: by 10.112.7.67 with HTTP; Fri, 21 Sep 2012 06:00:51 -0700 (PDT) X-Originating-IP: [192.149.252.11] In-Reply-To: References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> Date: Fri, 21 Sep 2012 09:00:51 -0400 Message-ID: From: Andrew Newton To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkV2YRTGQhlDA39nVtGX5p/lGdfbdP0RiiAoyfsjwVqsBM8qcWXGjBrWWqbo/T/ILm5wCJJ Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:00:53 -0000 On Fri, Sep 21, 2012 at 5:18 AM, Hannes Tschofenig wrote: > > I don't think that arguing are against the usage of formal or semi-formal= ways to describe protocols. Pseudo code may be a useful way to describe an= algorithm, for example. The issue is just that they have to be applied sel= ectively and carefully. There has to be a real benefit. > > In the context of this discussion I had been arguing that XML schemas (an= d Relax NG schemas) had not been useful for the target audience compared to= the benefits they claimed to provide. For that reason I argued that we sho= uld discourage people from using them since they cause problems for extensi= bility, specification quality, and readability. As far as extensibility goes, I think that's an issue more with Namespaces in XML than with the schema languages. However, there could be improvement. From a spec quality and readability point of view, I think this is more true of XML Schema than RelaxNG. Regarding utility for a target audience, from what I have experienced the problem is that tools vendors convince programmers that as long as they drop their XSDs or WSDL in spot X, magic will happen and they don't have to worry about all that nasty protocol crap (including talking to the network engineers about firewalls)... that is until they drop an XML document in a string and the whole thing blows up. But the issue isn't with XML Schema itself, it is with the magic-happens-here and computers-will-learn grand architecture in which XML Schema was drafted. > > I like the tool idea that PhB and Tim had brought up. I also think that e= xamples are the most valuable tool for implementers. +1 on the examples. Perhaps Phillip could get some time in Atlanta in Apps or maybe get a room for a BoF to demonstrate his idea. Though tools, including diagramming languages and schema languages, for writing better specifications seems like a topic for more than just Apps. -andy From dcrocker@bbiw.net Fri Sep 21 07:48:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1566521F8810 for ; Fri, 21 Sep 2012 07:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC2ubJA2pXES for ; Fri, 21 Sep 2012 07:48:32 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADA221F8797 for ; Fri, 21 Sep 2012 07:48:32 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8LEmUGQ019713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Sep 2012 07:48:31 -0700 Message-ID: <505C7E35.7010805@bbiw.net> Date: Fri, 21 Sep 2012 07:48:21 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <999913AB42CC9341B05A99BBF358718D01DF0684@FIESEXC035.nsn-intra.net> <505B43B3.7050503@berkeley.edu> <77AFECFB-F63A-457F-9C7F-F715315C0651@mnot.net> <505B78B4.80309@dcrocker.net> <505C2901.1030902@it.aoyama.ac.jp> In-Reply-To: <505C2901.1030902@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 21 Sep 2012 07:48:32 -0700 (PDT) Cc: Mark Nottingham , apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Schema considered harmful X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:48:33 -0000 On 9/21/2012 1:44 AM, "Martin J. Dürst" wrote: > On 2012/09/21 5:20, Tim Bray wrote: >> Frankly that notion had never crossed my mind, but is there a case for a >> “Tao of network protocols” or an “Informational BCP” or some such? I >> could >> put some cycles into it. -T > > What about doing it in the style of http://tools.ietf.org/html/rfc3470, > or maybe even as an update of tha document? This might be overly elaborate, but I actually had something a level above that in mind. Docs like RFC 3470 are excellent for the /details/ of a particular package. We ought to have one of those for each language in common use for IETF docs. However the one I was suggesting was an /umbrella/ over this class of documents. It would talk about the common issues across such languages (or whatever they should be called) and the issues that might help choose among them. What was triggering my suggestion was that Tim's bullet list was exactly the type of semantics I mean: basic rules that are common across our use of xml, json, abnf, whatever. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nico@cryptonector.com Fri Sep 21 08:07:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7138421F8858 for ; Fri, 21 Sep 2012 08:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqRvpjeZwLyy for ; Fri, 21 Sep 2012 08:06:57 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id AE46221F884F for ; Fri, 21 Sep 2012 08:06:56 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 2F6843B8069 for ; Fri, 21 Sep 2012 08:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=NC37gc4qfzVEj5EgY3QVmJDQtE4=; b=eQhwU7uuoQ/ cDZwA/yGSk5xkPd5LOk9nuxk0ZFx61ac2Xcp8Qy/LWWrMSb9ewn06Rp30NX8/jOd Xm2e19RvTmWnromuGAS0xkhjnP6guX1eAUhaX/dNzvxBy5XFwCABkGy1XWxCjZmU w6JVI+VKYCIEGgjJ+hr1OHTUWBVLJJPY= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 140E13B805B for ; Fri, 21 Sep 2012 08:06:55 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so5442023pbb.31 for ; Fri, 21 Sep 2012 08:06:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.203.70 with SMTP id ko6mr743536pbc.164.1348240015534; Fri, 21 Sep 2012 08:06:55 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 21 Sep 2012 08:06:55 -0700 (PDT) In-Reply-To: <505C3098.3030209@it.aoyama.ac.jp> References: <1348178993.2900.0.camel@polyglot> <08D741A0-6449-41BD-9C10-FA67942B91E4@tzi.org> <505C3098.3030209@it.aoyama.ac.jp> Date: Fri, 21 Sep 2012 10:06:55 -0500 Message-ID: From: Nico Williams To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 15:07:01 -0000 On Fri, Sep 21, 2012 at 4:17 AM, "Martin J. D=C3=BCrst" wrote: > On 2012/09/21 8:46, Carsten Bormann wrote: >> >> On Sep 21, 2012, at 00:23, Nico Williams wrote: >> >>> Dunno. But here's what I'm looking for: >>> >>> - strings: '...' >>> - octet strings: x'' or b'' >> >> >> Indeed. The problem is not that the binary data has to be carried aroun= d >> in some encoded text form, but that it is not identified as binary data. >> (Lose the hex idea, though. Unneeded choice.) >> Which raises the question: What is the status on binary data (really: by= te >> strings) in ECMAscript? > > > Last I heard (that was in a WebSocket discussion, so it must be a year or > two ago), it was being worked on. WebSocket has both text (UTF-8) and bin= ary > messages, and in order to handle binary messages in JavaScript, a binary > datatype is needed. > > Just checked a bit now, found e.g. > https://developer.mozilla.org/en-US/docs/JavaScript_typed_arrays/ArrayBuf= fer. > It looks like rather than using a very simple datatype with a literal > syntax, they went for a rather complex architecture. They must have had > their reasons, but please don't ask me why. > > If the above is true, then introducing something like > b'' would mean JSON is no longer a subset of JS. That would probably be their reason: an octet string literal can't be had without changing ECMAScript, or, in our case, without making JSON no longer a subset of ECMAScript. For some protocols that's something I'm willing to live with. I doubt we'd reach consensus on that, so we may have to settle for "the schema tells you if a string is actually intended to be a base64 encoding of an octet string", in which case this will continue to be my biggest pet peeve about JSON. Nico -- From nico@cryptonector.com Fri Sep 21 08:08:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0591E21F86B5 for ; Fri, 21 Sep 2012 08:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zepN5l4uKxDc for ; Fri, 21 Sep 2012 08:08:16 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 343C221F86A8 for ; Fri, 21 Sep 2012 08:08:16 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id D48B3B806D for ; Fri, 21 Sep 2012 08:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=6bhtOyju5biDEsQ4EsQ4 X3rXjck=; b=KLxoTKtbIRBg6s8HzIkJVFzP7fIF1fkssth6Kje3Xdj3MQvKqhbw mkpjwmhBYzn4gfr8w1w4GC7cCMNLe8m790oiuuBUFCH2EAjfAyac/9LV8KPWcn9S nDtifpydWj9k99BN/saKDny9+qzf4lSw9PoNVH0QZRpyWNFO3HA1Lbs= Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id BA732B8057 for ; Fri, 21 Sep 2012 08:08:15 -0700 (PDT) Received: by padfb11 with SMTP id fb11so468619pad.31 for ; Fri, 21 Sep 2012 08:08:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.213.228 with SMTP id nv4mr16602930pbc.67.1348240095429; Fri, 21 Sep 2012 08:08:15 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 21 Sep 2012 08:08:15 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Sep 2012 10:08:15 -0500 Message-ID: From: Nico Williams To: Andrew Newton Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 15:08:17 -0000 On Thu, Sep 20, 2012 at 7:08 PM, Andrew Newton wrote: > On Thu, Sep 20, 2012 at 7:07 PM, Phillip Hallam-Baker wrote: >> +1 on the Binary type, I think it is also useful to add in a DateTime type >> so that protocols do not attempt to roll their own. > > Given that both JSON Content Rules and JSON Schema have both base64 > and dateTime, what's the difference between the base text format > saying a string is base64 or dateTime vs a schema for JSON saying a > string is base64 or dateTime? I don't always want to use a schema, and when I don't, I like the data types to be self-describing. And in JSON types are self-describing, except for the lack of an octet string literal. From nico@cryptonector.com Fri Sep 21 08:10:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2536321F8819 for ; Fri, 21 Sep 2012 08:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ej90x9Ie355 for ; Fri, 21 Sep 2012 08:10:18 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id A2ED721F87A9 for ; Fri, 21 Sep 2012 08:10:18 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 7FF223B8062 for ; Fri, 21 Sep 2012 08:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=bK03ncw+Y+4/B2dOlUEW E0ydGzE=; b=d0IR7uGjao6zG6IyGdvcsdiqCYLaksM6SiE2ymukxHQDpfFAsYeU XDt4LsKS9/uBujTgS8itRsQXE1nUlA9xaIrAcTwYbhDpJcUS0pet6ykmjeqszbTy HqX6ddyo3afGfZAQ7FhPtvU/y8GFX3OTwS40hsBPgEveCh1AIdWRZMc= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 5BF6B3B8076 for ; Fri, 21 Sep 2012 08:10:18 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so5448580pbb.31 for ; Fri, 21 Sep 2012 08:10:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.195 with SMTP id ru3mr16146854pbc.149.1348240218004; Fri, 21 Sep 2012 08:10:18 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 21 Sep 2012 08:10:17 -0700 (PDT) In-Reply-To: References: <1348178993.2900.0.camel@polyglot> <08D741A0-6449-41BD-9C10-FA67942B91E4@tzi.org> <505C3098.3030209@it.aoyama.ac.jp> Date: Fri, 21 Sep 2012 10:10:17 -0500 Message-ID: From: Nico Williams To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 15:10:19 -0000 I should note that one JSON encoding/decoding (to/from CF-like objects) library I've used/hacked on has flags for specifying how strictly to adhere to JSON and can encode things that JSON cannot by extending JSON. Nico -- From hallam@gmail.com Fri Sep 21 08:32:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E1F21F878E for ; Fri, 21 Sep 2012 08:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.903 X-Spam-Level: X-Spam-Status: No, score=-3.903 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wJ65H-rvCuQ for ; Fri, 21 Sep 2012 08:32:51 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B106121F872D for ; Fri, 21 Sep 2012 08:32:51 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3799971obb.31 for ; Fri, 21 Sep 2012 08:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=L/cO+deCoFiteyy2lMcJjF/rxQyygMzI7cKA2UCbQsk=; b=pigqDFFZvaueq5FkjCwTzMyAimfFezii6k3Xi3RMbENP0O95AW/EeHrByILky9y1/A Dt6oeUGznFLMXoJktJXTVcmlKtlWeDTJUCiUdjT2F75lQQ1szA3iLPy5zj3YCTipz9zy /0s+2QkV0TVA3VOcHfrbA5hwf6kagDseLZ/b0UEoMSMcVIp4FzoyMbroThBAU7wvFJxN 5QbcOt7Gy1GGOD1D2yRGan3rHo83esbIArj+GsOrh2Q9bIhdrcpb2jqpPguYsUHHv8AO M9mX9yn7ReZyS6l1VGwkkRkvjtdnCmiQlX81jujcABTR1FINvsA1WfcZE9/yF/Lgx2Ko kOsg== MIME-Version: 1.0 Received: by 10.182.145.35 with SMTP id sr3mr4079859obb.98.1348241571225; Fri, 21 Sep 2012 08:32:51 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Fri, 21 Sep 2012 08:32:51 -0700 (PDT) Date: Fri, 21 Sep 2012 11:32:51 -0400 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/mixed; boundary=f46d04463078eca0dd04ca37f3a2 Cc: apps-discuss@ietf.org Subject: [apps-discuss] JSON encoding of binary objects X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 15:32:53 -0000 --f46d04463078eca0dd04ca37f3a2 Content-Type: multipart/alternative; boundary=f46d04463078eca0d004ca37f3a0 --f46d04463078eca0d004ca37f3a0 Content-Type: text/plain; charset=ISO-8859-1 Here is what I do in Omnibroker, an example message is: HTTP/1.1 203 Passcode Content-Type: application/json;charset=UTF-8 Content-Length: 500 { "OpenResponse": { "Status": 203, "StatusDescription": "Passcode", "Cryptographic": [{ "Secret": "xlE2Bu6cMf3Y9x29tsP5WQ==", "Encryption": "A128CBC", "Authentication": "HS256", "Ticket": "hyBNCDyVadjnkSzNp4goyQ+QR9jw/TnF5jQrkl66QhQbcfxSfTj+kxjzWt 3s6z9X2KMziSerHpLmw7DPoCg8OM1MHSt5PHHssfPvH6eaU+PxREiqMMFSI 7k9MFh53dTWJ8Sp6Q+/dN9LnvwgZ5P83w=="}], "Challenge": "PrE0hkZefumcw17yuYHz+w==", "ChallengeResponse": "0lXrJqm6JmeWoCGmoV3Yhg=="}} The values 'secret' and 'ticket', 'Challenge' and 'ChallengeResponse' are defined as binary data in the schema and represented as strings containing Base64 encoded data. [Note that the secret is currently required to be passed over a TLS channel, may well add further protection such as a DH exchange later so as to guarantee end-to-endness] I see no need to change JSON encoding rules to add binary. The data format does not need to be self describing. The schema for the message is: Message OpenResponse Inherits BindResponse Binary Challenge Description |Challenge value to be used by the client to respond |to the server authentication challenge. Binary ChallengeResponse Description |Server response to authentication challenge by the client |as described in section Struct ImageLink VerificationImage Multiple Description |Link to an image to be used in an image verification mechanism. Description |An Open request MAY be accepted immediately or be held pending |completion of an inband or out-of-band authentication process. Description |The OpenResponse returns a ticket and a set of cryptographic |connection parameters in either case. If the Status Complete |The OpenRequest was accepted and the binding parameters |specified are now active. Status Pending |The OpenRequest is being held pending offline verification |of the parameters. Status Passcode |The OpenRequest is being held pending completion of the |passcode authentication mechanism. Note that the schema supports inheritance, I have left out the parent class for brevity but it is in the (attached) definition file. This is a tool that I have written mostly for my own use so it is possibly a little rougher than it should be. I think that it is probably useful to be able to distinguish request messages from response messages. I did think about defining protocol flows as a state machine. But 95% of protocol messages end up as request-response queries. The C# class that is generated looks like the following: public partial class OpenResponse : BindResponse { public byte[] Challenge; public byte[] ChallengeResponse; public List VerificationImage; static string _Tag = "OpenResponse"; public override string Tag () { return _Tag; } public OpenResponse () { } public OpenResponse (JSONReader JSONReader) { Deserialize (JSONReader); } public OpenResponse (string _String) { Deserialize (_String); } public override string ToString () { ... } public new void Serialize (Writer Writer) { Serialize (Writer, false); } public new void Serialize (Writer Writer, bool tag) { ... } public new void Serialize (Writer Writer, bool wrap, ref bool first) { ... } } Converting the tool to generate Java would be pretty simple. The only part that would be a little clunky is that Java does not have the concept of a partial class which C# has. This is very useful for developing code generation tools as it means that the programmer can extend the automatically generated class in a separate file. Working with code generation tools in Java is a lot less friendly. Converting to generate C would mean flattening out the inheritance tree for each structure. The generator itself consists of a schema file (220 lines) and a script (750 lines). So the total code generator is less than 1000 lines. There is also another 2000 or so lines of generic support library code to do things like call up the DateTime conversion, escape strings and the lexer for the parser. The generator is in turn generated using Goedel which is about the same size. --f46d04463078eca0d004ca37f3a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here is what I do in Omnibroker, an example message is:

    HTTP/1.1 203 Passcode
    Content-Type: appl= ication/json;charset=3DUTF-8
    Content-Length: 500

    {
    =A0 "OpenResponse": {
    =A0 =A0 &quo= t;Status": 203,
    =A0 =A0 "StatusDescription": "Passcode",
    =A0 =A0 "Cryptographic": [{
    =A0 =A0 =A0 =A0 "Secr= et": "xlE2Bu6cMf3Y9x29tsP5WQ=3D=3D",
    =A0 =A0 =A0 = =A0 "Encryption": "A128CBC",
    =A0 =A0 =A0 =A0 "Authentication": "HS256",
    =A0 =A0 =A0 =A0 "Ticket":
    =A0 =A0 =A0 =A0 "hyBN= CDyVadjnkSzNp4goyQ+QR9jw/TnF5jQrkl66QhQbcfxSfTj+kxjzWt
    =A0 =A0 = =A0 =A0 3s6z9X2KMziSerHpLmw7DPoCg8OM1MHSt5PHHssfPvH6eaU+PxREiqMMFSI
    =A0 =A0 =A0 =A0 7k9MFh53dTWJ8Sp6Q+/dN9LnvwgZ5P83w=3D=3D"}],
    =
    =A0 =A0 "Challenge": "PrE0hkZefumcw17yuYHz+w=3D=3D"= ;,
    =A0 =A0 "ChallengeResponse": "0lXrJqm6JmeWoCGmo= V3Yhg=3D=3D"}}


    The values 'secret' and &#= 39;ticket', 'Challenge' and 'ChallengeResponse'=A0are d= efined as binary data in the schema and represented as strings containing B= ase64 encoded data. [Note that the secret is currently required to be passe= d over a TLS channel, may well add further protection such as a DH exchange= later so as to guarantee end-to-endness]

    I see no need to change JSON encoding rules to add bina= ry. The data format does not need to be self describing.

    The schema for the message is:

    Message OpenRespo= nse
    Inhe= rits BindRe= sponse

    Binary Challenge
    Des= cription
    |Challenge value to be used by the client to respond
    = |to the= server authentication challenge.
    Bina= ry ChallengeResponse
    Description
    |S= erver response to authentication challenge by the client
    |as described i= n section <xref target=3D"ChallengeResponse"/>
    Stru= ct ImageLink VerificationImage
    Multiple
    Des= cription
    |Link to an image to be used in an image verification mechanism= .
    Desc= ription
    = |An Open request MAY be accepted immediately or be held pending
    |co= mpletion of an inband or out-of-band authentication process.
    Description
    |Th= e OpenResponse returns a ticket and a set of cryptographic
    |connection pa= rameters in either case. If the=A0
    Stat= us Complet= e
    |The OpenRequest was accepted and the binding parameters
    |sp= ecified are now active.
    Status Pending
    |Th= e OpenRequest is being held pending offline verification=A0
    |of the param= eters.
    Stat= us Passcod= e
    |The OpenRequest is being held pending completion of the
    |pa= sscode authentication mechanism.

    Note that t= he schema supports inheritance, I have left out the parent class for brevit= y but it is in the (attached) definition file.

    This is a tool that I have written mostly for my own us= e so it is possibly a little rougher than it should be. I think that it is = probably useful to be able to distinguish request messages from response me= ssages.

    I did think about defining protocol flows as a state ma= chine. But 95% of protocol messages end up as request-response queries.


    The C# class that is generated looks l= ike the following:

    public partial class OpenResponse : BindResponse {
    public b= yte[] = Challenge;
    publ= ic byte[] ChallengeResponse;
    public List<ImageLink> VerificationImage;

    static string _Tag =3D "OpenResponse";
    public overrid= e string Tag () {
    ret= urn _Tag;
    }

    public OpenResponse () {
    }
    = public OpenResponse (JSONReader JSONReader) {
    Deserialize (JSONReader);
    }
    = public OpenResponse (string _String) {
    Deserialize (_String);
    }

    public override string ToString () {
    ...
    }

    public new void Serialize (Writer Writer) {
    Serialize (Writer,= false);
    }

    public new void Serialize (Writer Writer, bool tag) {
    <= div> ...
    <= /span>}

    public new void Serialize (Writer Writer, bool wrap, ref b= ool first) {
    ...
    }
    }

    Converting the tool to generate Java would be = pretty simple. The only part that would be a little clunky is that Java doe= s not have the concept of a partial class which C# has. This is very useful= for developing code generation tools as it means that the programmer can e= xtend the automatically generated class in a separate file. Working with co= de generation tools in Java is a lot less friendly.

    Converting to generate C would mean flattening out the = inheritance tree for each structure.

    The generator= itself consists of a schema file (220 lines) and a script (750 lines). So = the total code generator is less than 1000 lines. There is also another 200= 0 or so lines of generic support library code to do things like call up the= DateTime conversion, escape strings and the lexer for the parser.

    The generator is in turn generated using Goedel which i= s about the same size.
    --f46d04463078eca0d004ca37f3a0-- --f46d04463078eca0dd04ca37f3a2 Content-Type: application/octet-stream; name="OBP-Connection.protocol" Content-Disposition: attachment; filename="OBP-Connection.protocol" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h7dfknoh0 UHJvdG9jb2wgT0JQQ29ubmVjdGlvbiBPQlANCg0KCU1lc3NhZ2UgTWVzc2FnZQ0KCQlBYnN0cmFj dA0KDQoJTWVzc2FnZSBSZXNwb25zZSAgIA0KCQlBYnN0cmFjdA0KCQlJbmhlcml0cyBNZXNzYWdl DQoJCUludGVnZXIgU3RhdHVzDQoJCQlEZXNjcmlwdGlvbg0KCQkJCXxBcHBsaWNhdGlvbiBsYXll ciBzZXJ2ZXIgc3RhdHVzIGNvZGUNCgkJU3RyaW5nIFN0YXR1c0Rlc2NyaXB0aW9uDQoJCQlEZXNj cmlwdGlvbg0KCQkJCXxEZXNjcmliZXMgdGhlIHN0YXR1cyBjb2RlIChpZ25vcmVkIGJ5IHByb2Nl c3NvcnMpDQoJCVN0YXR1cyBTdWNjZXNzDQoJCQlEZXNjcmlwdGlvbg0KCQkJCXxUaGUgb3BlcmF0 aW9uIHN1Y2NlZWRlZC4NCg0KCU1lc3NhZ2UgRXJyb3JSZXNwb25zZQ0KCQlJbmhlcml0cyBSZXNw b25zZQ0KCQlEZXNjcmlwdGlvbg0KCQkJfEFuIGVycm9yIHJlc3BvbnNlIE1BWSBiZSByZXR1cm5l ZCBpbiByZXNwb25zZSB0byBhbnkgcmVxdWVzdC4NCgkJRGVzY3JpcHRpb24NCgkJCXxOb3RlIHRo YXQgcmVxdWVzdHMgTUFZIGJlIHJlamVjdGVkIGJ5IHRoZSBjb2RlIGltcGxlbWVudGluZw0KCQkJ fHRoZSB0cmFuc3BvcnQgYmluZGluZyBiZWZvcmUgYXBwbGljYXRpb24gcHJvY2Vzc2luZyBiZWdp bnMNCgkJCXxhbmQgc28gYSBzZXJ2ZXIgaXMgbm90IGd1YXJhbnRlZWQgdG8gcHJvdmlkZSBhbiBl cnJvciByZXNwb25zZQ0KCQkJfG1lc3NhZ2UuDQoJCVN0YXR1cyBVbmtub3duDQoNCglNZXNzYWdl IFJlcXVlc3QgICANCgkJQWJzdHJhY3QNCgkJSW5oZXJpdHMgTWVzc2FnZQ0KDQoNCglTdHJ1Y3R1 cmUgQ3J5cHRvZ3JhcGhpYwkNCgkJTGFiZWwgUHJvdG9jb2wNCgkJCURlc2NyaXB0aW9uDQoJCQkJ fE9CUCB0aWNrZXRzIE1BWSBiZSByZXN0cmljdGVkIHRvIHVzZSB3aXRoIGVpdGhlciB0aGUgbWFu YWdlbWVudA0KCQkJCXxwcm90b2NvbCAoTWFuYWdlbWVudCkgb3IgdGhlIHF1ZXJ5IHByb3RvY29s IChRdWVyeSkuIElmIHNvIGEgDQoJCQkJfHNlcnZpY2Ugd291bGQgdHlwaWNhbGx5IA0KCQkJCXxz cGVjaWZ5IGEgdGlja2V0IHdpdGggYSBsb25nIGV4cGlyeSB0aW1lIG9yIG5vIGV4cGlyeSBmb3Ig dXNlIHdpdGggDQoJCQkJfHRoZSBtYW5hZ2VtZW50IHByb3RvY29sIGFuZCBhIHNlcGFyYXRlIHRp Y2tldCBmb3IgdXNlIHdpdGggdGhlIA0KCQkJCXxxdWVyeSBwcm90b2NvbC4NCgkJQmluYXJ5IFNl Y3JldA0KCQkJUmVxdWlyZWQJCQ0KCQkJRGVzY3JpcHRpb24NCgkJCQl8U2hhcmVkIHNlY3JldA0K CQlMYWJlbCBFbmNyeXB0aW9uIA0KCQkJUmVxdWlyZWQNCgkJCURlc2NyaXB0aW9uDQoJCQkJfEVu Y3J5cHRpb24gQWxnb3JpdGhtIHNlbGVjdGVkDQoJCUxhYmVsIEF1dGhlbnRpY2F0aW9uIA0KCQkJ UmVxdWlyZWQNCgkJCURlc2NyaXB0aW9uDQoJCQkJfEF1dGhlbnRpY2F0aW9uIEFsZ29yaXRobSBz ZWxlY3RlZA0KCQlCaW5hcnkgVGlja2V0CQ0KCQkJUmVxdWlyZWQJCQ0KCQkJRGVzY3JpcHRpb24N CgkJCQl8T3BhcXVlIHRpY2tldCBpc3N1ZWQgYnkgdGhlIHNlcnZlciB0aGF0IGlkZW50aWZpZXMN CgkJCQl8dGhlIGNyeXB0b2dyYXBoaWMgcGFyYW1ldGVycyBmb3IgZW5jcnlwdGlvbiBhbmQNCgkJ CQl8YXV0aGVudGljYXRpb24gb2YgdGhlIG1lc3NhZ2UgcGF5bG9hZC4NCgkJRGF0ZVRpbWUgRXhw aXJlcyANCgkJCURlc2NyaXB0aW9uDQoJCQkJfERhdGUgYW5kIHRpbWUgYXQgd2hpY2ggdGhlIGNv bnRleHQgd2lsbCBleHBpcmUNCgkJRGVzY3JpcHRpb24NCgkJCXxQYXJhbWV0ZXJzIGRlc2NyaWJp bmcgYSBjcnlwdG9ncmFwaGljIGNvbnRleHQuDQoJU3RydWN0dXJlIEltYWdlTGluayAgDQoJCUxh YmVsIEFsZ29yaXRobQkJDQoJCQlEZXNjcmlwdGlvbg0KCQkJCXxJbWFnZSBlbmNvZGluZyBhbGdv cml0aG0gKGUuZy4gSlBHLCBQTkcpDQoJCUJpbmFyeSBJbWFnZQ0KCQkJRGVzY3JpcHRpb24NCgkJ CQl8SW1hZ2UgZGF0YSBhcyBzcGVjaWZpZWQgYnkgYWxnb3JpdGhtDQoJU3RydWN0dXJlIENvbm5l Y3Rpb24JDQoJCURlc2NyaXB0aW9uDQoJCQl8Q29udGFpbnMgaW5mb3JtYXRpb24gZGVzY3JpYmlu ZyBhIG5ldHdvcmsgY29ubmVjdGlvbi4NCgkJTmFtZQkJTmFtZQ0KCQkJRGVzY3JpcHRpb24NCgkJ CQl8RE5TIE5hbWUuIFNpbmNlIG9uZSBvZiB0aGUgZnVuY3Rpb25zIG9mIGFuIE9CUCBzZXJ2aWNl IGlzIG5hbWUNCgkJCQl8cmVzb2x1dGlvbiwgYSBETlMgbmFtZSBpcyBvbmx5IHVzZWQgdG8gZXN0 YWJsaXNoIGEgY29ubmVjdGlvbiBpZg0KCQkJCXxjb25uZWN0aW9uIGJ5IG1lYW5zIG9mIHRoZSBJ UCBhZGRyZXNzIGZhaWxzLg0KCQlJbnRlZ2VyIFBvcnQJCQ0KCQkJRGVzY3JpcHRpb24NCgkJCQl8 VENQIG9yIFVEUCBwb3J0IG51bWJlci4NCgkJU3RyaW5nIEFkZHJlc3MJCQ0KCQkJRGVzY3JpcHRp b24NCgkJCQl8SVB2NCAoMzIgYml0KSBvciBJUHY2ICgxMjggYml0KSBzZXJ2aWNlIGFkZHJlc3MN CgkJSW50ZWdlciBQcmlvcml0eQkNCgkJCURlc2NyaXB0aW9uDQoJCQkJfFNlcnZpY2UgcHJpb3Jp dHkuIFNlcnZpY2VzIHdpdGggbG93ZXIgcHJpb3JpdHkgbnVtYmVycyBTSE9VTEQNCgkJCQl8YmUg YXR0ZW1wdGVkIGJlZm9yZSB0aG9zZSB3aXRoIGhpZ2hlciBudW1iZXJzLg0KCQlJbnRlZ2VyIFdl aWdodAkJDQoJCQlEZXNjcmlwdGlvbg0KCQkJCXxXZWlnaHQgdG8gYmUgdXNlZCB0byBzZWxlY3Qg YmV0d2VlbiBzZXJ2aWNlcyBvZiBlcXVhbCBwcmlvcml0eS4NCgkJTGFiZWwgVHJhbnNwb3J0CQ0K CQkJRGVzY3JpcHRpb24NCgkJCQl8T0JQIFRyYW5zcG9ydCBiaW5kaW5nIHRvIGJlIHVzZWQgdmFs aWQgdmFsdWVzIGFyZSBIVFRQLCBETlMgYW5kIFVEUC4NCgkJRGF0ZVRpbWUgRXhwaXJlcyANCgkJ CURlc2NyaXB0aW9uDQoJCQkJfERhdGUgYW5kIHRpbWUgYXQgd2hpY2ggdGhlIHNwZWNpZmllZCBj b25uZWN0aW9uIGNvbnRleHQgd2lsbCBleHBpcmUuDQoJCVN0cnVjdCBDcnlwdG9ncmFwaGljIENy eXB0b2dyYXBoaWMNCgkJCURlc2NyaXB0aW9uDQoJCQkJfENyeXB0b2dyYXBoaWMgUGFyYW1ldGVy cy4NCglUcmFuc2FjdGlvbiBCaW5kIA0KCQlSZXF1ZXN0CQlCaW5kUmVxdWVzdA0KCQlSZXNwb25z ZQlCaW5kUmVzcG9uc2UNCgkJUmVxdWVzdAkJT3BlblJlcXVlc3QNCgkJUmVzcG9uc2UJT3BlblJl c3BvbnNlDQoJCVJlcXVlc3QJCVRpY2tldFJlcXVlc3QNCgkJUmVzcG9uc2UJVGlja2V0UmVzcG9u c2UNCgkJRGVzY3JpcHRpb24NCgkJCXxCaW5kaW5nIGEgZGV2aWNlIGlzIGEgdHdvIHN0ZXAgcHJv dG9jb2wgdGhhdCBiZWdpbnMgd2l0aCB0aGUNCgkJCXxTdGFydCBRdWVyeSBmb2xsb3dlZCBieSBh IHNlcXVlbmNlIG9mIFRpY2tldCBxdWVyaWVzLg0KCU1lc3NhZ2UgQmluZFJlcXVlc3QNCgkJQWJz dHJhY3QNCgkJSW5oZXJpdHMJCVJlcXVlc3QNCgkJRGVzY3JpcHRpb24NCgkJCXxUaGUgZm9sbG93 aW5nIHBhcmFtZXRlcnMgTUFZIG9jY3VyIGluIGVpdGhlciBhDQoJCQl8U3RhcnRSZXF1ZXN0IG9y IFRpY2tldFJlcXVlc3Q6DQoJCUxhYmVsIEVuY3J5cHRpb24gDQoJCQlNdWx0aXBsZQ0KCQkJRGVz Y3JpcHRpb24NCgkJCQl8RW5jcnlwdGlvbiBBbGdvcml0aG0gdGhhdCB0aGUgY2xpZW50IGFjY2Vw dHMuIEEgQ2xpZW50IE1BWQ0KCQkJCXxvZmZlciBtdWx0aXBsZSBhbGdvcml0aG1zLiBJZiBubyBh bGdvcml0aG1zIGFyZSBzcGVjaWZpZWQgdGhlbg0KCQkJCXxzdXBwb3J0IGZvciB0aGUgbWFuZGF0 b3J5IHRvIGltcGxlbWVudCBhbGdvcml0aG0gaXMgYXNzdW1lZC4NCgkJCQl8T3RoZXJ3aXNlIG1h bmRhdG9yeSB0byBpbXBsZW1lbnQgYWxnb3JpdGhtcyBNVVNUIGJlIA0KCQkJCXxzcGVjaWZpZWQg ZXhwbGljaXRseS4NCgkJTGFiZWwgQXV0aGVudGljYXRpb24NCgkJCU11bHRpcGxlDQoJCQlEZXNj cmlwdGlvbg0KCQkJCXxBdXRoZW50aWNhdGlvbiBBbGdvcml0aG0gdGhhdCB0aGUgY2xpZW50IGFj Y2VwdHMuDQoJCQkJfElmIG5vIGFsZ29yaXRobXMgYXJlIHNwZWNpZmllZCB0aGVuDQoJCQkJfHN1 cHBvcnQgZm9yIHRoZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGFsZ29yaXRobSBpcyBhc3N1bWVk Lg0KCQkJCXxPdGhlcndpc2UgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBhbGdvcml0aG1zIE1VU1Qg YmUgDQoJCQkJfHNwZWNpZmllZCBleHBsaWNpdGx5LiANCglNZXNzYWdlIEJpbmRSZXNwb25zZQkN CgkJQWJzdHJhY3QNCgkJSW5oZXJpdHMJUmVzcG9uc2UJCQ0KCQlEZXNjcmlwdGlvbg0KCQkJfFRo ZSBmb2xsb3dpbmcgcGFyYW1ldGVycyBNQVkgb2NjdXIgaW4gZWl0aGVyIGENCgkJCXxTdGFydFJl c3BvbnNlIG9yIFRpY2tldFJlc3BvbnNlOg0KCQlTdHJ1Y3QgQ3J5cHRvZ3JhcGhpYyBDcnlwdG9n cmFwaGljDQoJCQlNdWx0aXBsZQ0KCQkJRGVzY3JpcHRpb24NCgkJCQl8Q3J5cHRvZ3JhcGhpYyBQ YXJhbWV0ZXJzLg0KCQlTdHJ1Y3QgQ29ubmVjdGlvbiBTZXJ2aWNlCQ0KCQkJTXVsdGlwbGUNCgkJ CURlc2NyaXB0aW9uDQoJCQkJfEEgQ29ubmVjdGlvbiBkZXNjcmliaW5nIGFuIE9CUCBzZXJ2aWNl IHBvaW50DQoNCg0KCU1lc3NhZ2UgT3BlblJlcXVlc3QJCQ0KCQlJbmhlcml0cwlCaW5kUmVxdWVz dA0KCQlEZXNjcmlwdGlvbg0KCQkJfFRoZSBPcGVuUmVxdWVzdCBNZXNzYWdlIGlzIHVzZWQgdG8g YmVnaW4gYSBkZXZpY2UgYmluZGluZyB0cmFuc2FjdGlvbi4NCgkJCXxEZXBlbmRpbmcgb24gdGhl IGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgc2VydmljZSB0aGUNCgkJCXx0cmFu c2FjdGlvbiBtYXkgYmUgY29tcGxldGVkIGluIGEgc2luZ2xlIHF1ZXJ5IG9yIHJlcXVpcmUgYSAN CgkJCXxmdXJ0aGVyIFRpY2tldCBRdWVyeSB0byBjb21wbGV0ZS4NCgkJRGVzY3JpcHRpb24NCgkJ CXxJZiBhdXRoZW50aWNhdGlvbiBpcyByZXF1aXJlZCwgdGhlIG1lY2hhbmlzbSB0byBiZSB1c2Vk IGRlcGVuZHMgb24NCgkJCXx0aGUgY2FwYWJpbGl0aWVzIG9mIHRoZSBkZXZpY2UsIHRoZSByZXF1 aXJlbWVudHMgb2YgdGhlIGJyb2tlciBhbmQNCgkJCXx0aGUgZXhpc3RpbmcgcmVsYXRpb25zaGlw IGJldHdlZW4gdGhlIHVzZXIgYW5kIHRoZSBicm9rZXIuDQoJCURlc2NyaXB0aW9uDQoJCQl8SWYg dGhlIGRldmljZSBzdXBwb3J0cyBzb21lIG1lYW5zIG9mIGRhdGEgZW50cnksIGF1dGhlbnRpY2F0 aW9uIA0KCQkJfE1BWSBiZSBhY2hpZXZlZCBieSBlbnRlcmluZyBhIHBhc3Njb2RlIHByZXZpb3Vz bHkgZGVsaXZlcmVkIG91dA0KCQkJfG9mIGJhbmQgaW50byB0aGUgZGV2aWNlLg0KCQlTdHJpbmcg QWNjb3VudAkJCQ0KCQkJRGVzY3JpcHRpb24NCgkJCQl8QWNjb3VudCBuYW1lIG9mIHRoZSB1c2Vy IGF0IHRoZSBPQlAgc2VydmljZQ0KCQlOYW1lIERvbWFpbgkJCQ0KCQkJRGVzY3JpcHRpb24NCgkJ CQl8RG9tYWluIG5hbWUgb2YgdGhlIE9CUCBicm9rZXIgc2VydmljZQ0KCQlCb29sZWFuIEhhdmVQ YXNzY29kZQkNCgkJCURlZmF1bHQJCSJGYWxzZSINCgkJCURlc2NyaXB0aW9uDQoJCQkJfElmICd0 cnVlJywgdGhlIHVzZXIgaGFzIGVudGVyZWQgYSBwYXNzY29kZSB2YWx1ZSBmb3IgDQoJCQkJfHVz ZSB3aXRoIHBhc3Njb2RlIGF1dGhlbnRpY2F0aW9uLg0KCQlCb29sZWFuIEhhdmVEaXNwbGF5CQkN CgkJCURlZmF1bHQJCSJGYWxzZSINCgkJCURlc2NyaXB0aW9uDQoJCQkJfFNwZWNpZmllcyBpZiB0 aGUgZGV2aWNlIGlzIGNhcGFibGUgb2YgZGlzcGxheWluZyBpbmZvcm1hdGlvbg0KCQkJCXx0byB0 aGUgdXNlciBvciBub3QuDQoJCUJpbmFyeSBDaGFsbGVuZ2UJDQoJCQlEZXNjcmlwdGlvbg0KCQkJ CXxDbGllbnQgY2hhbGxlbmdlIHZhbHVlIHRvIGJlIHVzZWQgaW4gYXV0aGVudGljYXRpb24gY2hh bGxlbmdlDQoJCQkJfG1lY2hhbmlzbSBhcyBkZXNjcmliZWQgaW4gc2VjdGlvbiA8eHJlZiB0YXJn ZXQ9IkNoYWxsZW5nZVJlc3BvbnNlIi8+DQoJCVVSSSBEZXZpY2VJRAkJDQoJCQlEZXNjcmlwdGlv bg0KCQkJCXxEZXZpY2UgaWRlbnRpZmllciB1bmlxdWUgZm9yIGEgcGFydGljdWxhciBpbnN0YW5j ZSBvZiBhIGRldmljZSBzdWNoIGFzIGEgTUFDIG9yIEVVSS02NCBhZGRyZXNzIGV4cHJlc3NlZCBh cyBhIFVSSQ0KCQlVUkkgRGV2aWNlVVJJCQkNCgkJCURlc2NyaXB0aW9uDQoJCQkJfERldmljZSBp ZGVudGlmaWVyIHNwZWNpZnlpbmcgdGhlIHR5cGUgb2YgZGV2aWNlLCBlLmcuIGFuIHhQaG9uZS4N CgkJU3RydWN0IEltYWdlTGluayBEZXZpY2VJbWFnZQ0KCQkJRGVzY3JpcHRpb24NCgkJCQl8QW4g aW1hZ2UgaWRlbnRpZnlpbmcgdGhlIHBoeXNpY2FsIGFwcGVhcmFuY2Ugb2YgdGhlIGRldmljZS4g DQoJCVN0cmluZyBEZXZpY2VOYW1lCQkNCgkJCURlc2NyaXB0aW9uDQoJCQkJfERlc2NyaXB0aXZl IG5hbWUgZm9yIHRoZSBkZXZpY2UgdGhhdCB3b3VsZCBkaXN0aW5ndWlzaCBpdCANCgkJCQl8ZnJv bSBvdGhlciBzaW1pbGFyIGRldmljZXMsIGUuZy4gJ0FsaWNlJ3MgeFBob25lIi4NCgkJRGVzY3Jp cHRpb24NCgkJCXxUaGUgT3BlblJlcXVlc3Qgc3BlY2lmaWVzIHRoZSBwcm9wZXJ0aWVzIG9mIHRo ZSBzZXJ2aWNlDQoJCQl8KEFjY291bnQsIERvbWFpbikgYW5kIERldmljZSAoSUQsIFVSSSwgTmFt ZSkgdGhhdCB3aWxsIHJlbWFpbg0KCQkJfGNvbnN0YW50IHRocm91Z2hvdXQgdGhlIHBlcmlvZCB0 aGF0IHRoZSBkZXZpY2UgYmluZGluZyBpcyBhY3RpdmUNCgkJCXxhbmQgcGFyYW1ldGVycyB0byBi ZSB1c2VkIGZvciB0aGUgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sLg0KCQ0KCQ0KCU1l c3NhZ2UgT3BlblJlc3BvbnNlCQ0KCQlJbmhlcml0cwlCaW5kUmVzcG9uc2UNCg0KCQlCaW5hcnkg Q2hhbGxlbmdlCQ0KCQkJRGVzY3JpcHRpb24NCgkJCQl8Q2hhbGxlbmdlIHZhbHVlIHRvIGJlIHVz ZWQgYnkgdGhlIGNsaWVudCB0byByZXNwb25kDQoJCQkJfHRvIHRoZSBzZXJ2ZXIgYXV0aGVudGlj YXRpb24gY2hhbGxlbmdlLg0KCQlCaW5hcnkgQ2hhbGxlbmdlUmVzcG9uc2UJDQoJCQlEZXNjcmlw dGlvbg0KCQkJCXxTZXJ2ZXIgcmVzcG9uc2UgdG8gYXV0aGVudGljYXRpb24gY2hhbGxlbmdlIGJ5 IHRoZSBjbGllbnQNCgkJCQl8YXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gPHhyZWYgdGFyZ2V0PSJD aGFsbGVuZ2VSZXNwb25zZSIvPg0KCQlTdHJ1Y3QgSW1hZ2VMaW5rIFZlcmlmaWNhdGlvbkltYWdl CQ0KCQkJTXVsdGlwbGUNCgkJCURlc2NyaXB0aW9uDQoJCQkJfExpbmsgdG8gYW4gaW1hZ2UgdG8g YmUgdXNlZCBpbiBhbiBpbWFnZSB2ZXJpZmljYXRpb24gbWVjaGFuaXNtLg0KCQlEZXNjcmlwdGlv bg0KCQkJfEFuIE9wZW4gcmVxdWVzdCBNQVkgYmUgYWNjZXB0ZWQgaW1tZWRpYXRlbHkgb3IgYmUg aGVsZCBwZW5kaW5nDQoJCQl8Y29tcGxldGlvbiBvZiBhbiBpbmJhbmQgb3Igb3V0LW9mLWJhbmQg YXV0aGVudGljYXRpb24gcHJvY2Vzcy4NCgkJRGVzY3JpcHRpb24NCgkJCXxUaGUgT3BlblJlc3Bv bnNlIHJldHVybnMgYSB0aWNrZXQgYW5kIGEgc2V0IG9mIGNyeXB0b2dyYXBoaWMNCgkJCXxjb25u ZWN0aW9uIHBhcmFtZXRlcnMgaW4gZWl0aGVyIGNhc2UuIElmIHRoZSANCgkJU3RhdHVzCQlDb21w bGV0ZQ0KCQkJfFRoZSBPcGVuUmVxdWVzdCB3YXMgYWNjZXB0ZWQgYW5kIHRoZSBiaW5kaW5nIHBh cmFtZXRlcnMNCgkJCXxzcGVjaWZpZWQgYXJlIG5vdyBhY3RpdmUuDQoJCVN0YXR1cwkJUGVuZGlu Zw0KCQkJfFRoZSBPcGVuUmVxdWVzdCBpcyBiZWluZyBoZWxkIHBlbmRpbmcgb2ZmbGluZSB2ZXJp ZmljYXRpb24gDQoJCQl8b2YgdGhlIHBhcmFtZXRlcnMuDQoJCVN0YXR1cwkJUGFzc2NvZGUNCgkJ CXxUaGUgT3BlblJlcXVlc3QgaXMgYmVpbmcgaGVsZCBwZW5kaW5nIGNvbXBsZXRpb24gb2YgdGhl DQoJCQl8cGFzc2NvZGUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtLg0KCU1lc3NhZ2UgVGlja2V0 UmVxdWVzdAkNCgkJRGVzY3JpcHRpb24NCgkJCXxUaGUgVGlja2V0UmVxdWVzdCBtZXNzYWdlIGlz IHVzZWQgdG8gKDEpIGNvbXBsZXRlIGEgYmluZGluZyByZXF1ZXN0DQoJCQl8YmVndW4gd2l0aCBh biBPcGVuUmVxdWVzdCBhbmQgKDIpIHRvIHJlZnJlc2ggdGlja2V0IG9yIGNvbm5lY3Rpb24gDQoJ CQl8cGFyYW1ldGVycyBhcyBuZWNlc3NhcnkuDQoJCUluaGVyaXRzCQlSZXF1ZXN0DQoNCgkJQmlu YXJ5IENoYWxsZW5nZVJlc3BvbnNlCQ0KCQkJRGVzY3JpcHRpb24NCgkJCQl8VGhlIHJlc3BvbnNl IHRvIGEgc2VyZXIgYXV0aGVudGljYXRpb24gY2hhbGxlbmdlIA0KCQkJCXxhcyBkZXNjcmliZWQg aW4gc2VjdGlvbiA8eHJlZiB0YXJnZXQ9IkNoYWxsZW5nZVJlc3BvbnNlIi8+DQoJTWVzc2FnZSBU aWNrZXRSZXNwb25zZQkNCgkJSW5oZXJpdHMJQmluZFJlc3BvbnNlDQoJCURlc2NyaXB0aW9uDQoJ CQl8VGhlIFRpY2tldFJlc3BvbnNlIG1lc3NhZ2UgcmV0dXJucyBjcnlwdG9ncmFwaGljIGFuZC9v ciBjb25uZWN0aW9uDQoJCQl8Y29udGV4dCBpbmZvcm1hdGlvbiB0byBhIGNsaWVudC4NCglUcmFu c2FjdGlvbiBVbmJpbmQgDQoJCVJlcXVlc3QJCVVuYmluZFJlcXVlc3QNCgkJUmVzcG9uc2UJVW5i aW5kUmVzcG9uc2UNCgkJRGVzY3JpcHRpb24NCgkJCXxSZXF1ZXN0cyB0aGF0IGEgcHJldmlvdXMg ZGV2aWNlIGFzc29jaWF0aW9uIGJlIGRlbGV0ZWQuDQoJTWVzc2FnZSBVbmJpbmRSZXF1ZXN0CQ0K CQlJbmhlcml0cwlSZXF1ZXN0DQoJCURlc2NyaXB0aW9uDQoJCQl8U2luY2UgdGhlIHRpY2tldCBp ZGVudGlmaWVzIHRoZSBiaW5kaW5nIHRvIGJlIGRlbGV0ZWQsIHRoZQ0KCQkJfG9ubHkgdGhpbmcg dGhhdCB0aGUgdW5iaW5kIG1lc3NhZ2UgbmVlZCBzcGVjaWZ5IGlzIHRoYXQNCgkJCXx0aGUgZGV2 aWNlIHdpc2hlcyB0byBjYW5jZWwgdGhlIGJpbmRpbmcuDQoJTWVzc2FnZSBVbmJpbmRSZXNwb25z ZQkNCgkJSW5oZXJpdHMJUmVzcG9uc2UNCgkJRGVzY3JpcHRpb24NCgkJCXxSZXBvcnRzIG9uIHRo ZSBzdWNjZXNzIG9mIHRoZSB1bmJpbmRpbmcgb3BlcmF0aW9uLg0KCQlEZXNjcmlwdGlvbg0KCQkJ fElmIHRoZSBzZXJ2ZXIgcmVwb3J0cyBzdWNjZXNzLCB0aGUgY2xpZW50IFNIT1VMRCBkZWxldGUg dGhlDQoJCQl8dGlja2V0IGFuZCBhbGwgaW5mb3JtYXRpb24gcmVsYXRpbmcgdG8gdGhlIGJpbmRp bmcuDQoJCURlc2NyaXB0aW9uDQoJCQl8QSBzZXJ2aWNlIE1BWSBjb250aW51ZSB0byBhY2NlcHQg YSB0aWNrZXQgYWZ0ZXIgYW4gdW5iaW5kIHJlcXVlc3QNCgkJCXxoYXMgYmVlbiBncmFudGVkIGJ1 dCBNVVNUIE5PVCBhY2NlcHQgc3VjaCBhIHRpY2tldCBmb3INCgkJCXxhIGJpbmQgcmVxdWVzdC4N Cg== --f46d04463078eca0dd04ca37f3a2-- From cabo@tzi.org Fri Sep 21 08:35:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3710E21F8522 for ; Fri, 21 Sep 2012 08:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVofFRJQdNXV for ; Fri, 21 Sep 2012 08:35:21 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 521CE21F8734 for ; Fri, 21 Sep 2012 08:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q8LFZ8Uw010854; Fri, 21 Sep 2012 17:35:08 +0200 (CEST) Received: from [192.168.217.105] (p54893726.dip.t-dialin.net [84.137.55.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3D2BFE81; Fri, 21 Sep 2012 17:35:08 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 21 Sep 2012 17:35:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1348178993.2900.0.camel@polyglot> <08D741A0-6449-41BD-9C10-FA67942B91E4@tzi.org> <505C3098.3030209@it.aoyama.ac.jp> To: Nico Williams X-Mailer: Apple Mail (2.1498) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 15:35:22 -0000 > That would probably be their reason: an octet string literal can't be > had without changing ECMAScript, or, in our case, without making JSON > no longer a subset of ECMAScript. It might be possible to develop a way to express the difference between = a UTF-8 string and a base64-encoded byte string in a way that is = backwards compatible with RFC 4627 JSON. If JSON had comments, you = might do "foob" /*utf-8*/ and "foob" /*b64*/ Now, JSON does not have comments, and the only variability we have for = expressing this kind of out-of-band information appears to be = whitespace. E.g., interpret a RFC 4627 JSON string as a base64-encoded byte string = if/only if it is preceded by, say, two newlines. So a JSON reader not aware of this encoding would need to rely on a = schema to know when a string is text or base-64-encoded bytes. A JSON writer not aware of this would be quite unlikely to emit the two = newlines. (And we'd need a similar covert channel to indicate a JSON text is = actually using this encoding.) (I'm well aware of the security considerations of this kind of backwards = compatibility. But it could be made to work in practice.) > For some protocols that's something I'm willing to live with. I doubt > we'd reach consensus on that, so we may have to settle for "the schema > tells you if a string is actually intended to be a base64 encoding of > an octet string", in which case this will continue to be my biggest > pet peeve about JSON. Exactly. Gr=FC=DFe, Carsten From jasnell@gmail.com Fri Sep 21 08:39:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9882721F8686 for ; Fri, 21 Sep 2012 08:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIfoImiXvcWe for ; Fri, 21 Sep 2012 08:39:26 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBA221F8681 for ; Fri, 21 Sep 2012 08:39:26 -0700 (PDT) Received: by weyx48 with SMTP id x48so2204449wey.31 for ; Fri, 21 Sep 2012 08:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DWfhzX9OSXx8iqGm5Pqu9i2pxQQm2ARwWBHU0+wJhNY=; b=vYZdprMi/pGKgZgOWZ8WGi9ydUNQO+JJOWfxbK+RYXBPOBAZVIC7XWgVyvA0ZIb6N+ uPhlfQhzj1Zm7CeoS7BpQC9VBurV8a2KSOjouoooMlQk2iBXpzZMoQ+0kIAz67j/vi/r KsnhE6mDwbtz8C69IblAZayne3GiOFsXoOVpE2E9ZZMy/gsQ34pulAkMA594UGTbgUkX ewbR4+Q+CGikwLPk7htp5Zq9CLStxzD35JXw3Yqt1iZTpBrDrHVZ53tiLcpq7MYV00lG o7n3dXJuQJABaT1oWEmD8mBmXoMwg72TCfOtfmEIPG4r8jlEQcYPbXqhRhwF/F44SWBw JrMA== Received: by 10.216.194.143 with SMTP id m15mr3194722wen.128.1348241965362; Fri, 21 Sep 2012 08:39:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Fri, 21 Sep 2012 08:39:05 -0700 (PDT) In-Reply-To: <505C3098.3030209@it.aoyama.ac.jp> References: <1348178993.2900.0.camel@polyglot> <08D741A0-6449-41BD-9C10-FA67942B91E4@tzi.org> <505C3098.3030209@it.aoyama.ac.jp> From: James M Snell Date: Fri, 21 Sep 2012 08:39:05 -0700 Message-ID: To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=0016e6da2e7f6aae5204ca380b24 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 15:39:27 -0000 --0016e6da2e7f6aae5204ca380b24 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Introducing a binary data type within JSON would just be a mistake. Full stop. If you do need to represent binary data within JSON, Base64 works quite well and is all that is really needed. (Refer to [1] for a real world example). As far as dates are concerned, RFC3339 has generally become the defacto standard for the majority of JSON-based applications I've seen (and have developed). JSON itself, however, does not need an explicit date type. In the specs I've written, I've found the following to be more than sufficient to get the point across: "Unless otherwise specified, all properties specifying date and time values MUST conform to the "date-time" production in [RFC3339]." [1] http://activitystrea.ms/specs/json/schema/activity-schema.html#binary - James On Fri, Sep 21, 2012 at 2:17 AM, "Martin J. D=C3=BCrst" wrote: > On 2012/09/21 8:46, Carsten Bormann wrote: > >> On Sep 21, 2012, at 00:23, Nico Williams wrote= : >> >> Dunno. But here's what I'm looking for: >>> >>> - strings: '...' >>> - octet strings: x'' or b'' >>> >> >> Indeed. The problem is not that the binary data has to be carried aroun= d >> in some encoded text form, but that it is not identified as binary data. >> (Lose the hex idea, though. Unneeded choice.) >> Which raises the question: What is the status on binary data (really: >> byte strings) in ECMAscript? >> > > Last I heard (that was in a WebSocket discussion, so it must be a year or > two ago), it was being worked on. WebSocket has both text (UTF-8) and > binary messages, and in order to handle binary messages in JavaScript, a > binary datatype is needed. > > Just checked a bit now, found e.g. https://developer.mozilla.org/** > en-US/docs/JavaScript_typed_**arrays/ArrayBuffer. > It looks like rather than using a very simple datatype with a literal > syntax, they went for a rather complex architecture. They must have had > their reasons, but please don't ask me why. > > If the above is true, then introducing something like > b'' would mean JSON is no longer a subset of JS. > > Regards, Martin. > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --0016e6da2e7f6aae5204ca380b24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Introducing a binary data type within = JSON would just be a mistake. Full stop. If you do need to represent binary= data within JSON, Base64 works quite well and is all that is really needed= . (Refer to [1] for a real world example).=C2=A0

    As far as dates are concerned, RFC3339 has generally= become the defacto standard for the majority of JSON-based applications I&= #39;ve seen (and have developed). JSON itself, however, does not need an ex= plicit date type. In the specs I've written, I've found the followi= ng to be more than sufficient to get the point across: "Unless otherwise specified, all propert= ies specifying date and time values MUST conform to the "date-time&quo= t; production in=C2=A0[RFC3339]."


    - James

    On Fri, Sep 21, 2012 at 2:17 AM, "Martin J. D=C3=BCrst" <d= uerst@it.aoyama.ac.jp> wrote:
    On 2012/09/21 8:46, Carste= n Bormann wrote:
    On Sep 21, 2012, at 00:23, Nico Williams<nico@cryptonector.com> =C2=A0wrot= e:

    Dunno. =C2=A0But here's what I'm looking for:

    - strings: '...'
    - octet strings: x'<hex-encoded>' or b'<base64-encoded= >'

    Indeed. =C2=A0The problem is not that the binary data has to be carried aro= und in some encoded text form, but that it is not identified as binary data= .
    (Lose the hex idea, though. =C2=A0Unneeded choice.)
    Which raises the question: What is the status on binary data (really: byte = strings) in ECMAscript?

    Last I heard (that was in a WebSocket discussion, so it must be a year or t= wo ago), it was being worked on. WebSocket has both text (UTF-8) and binary= messages, and in order to handle binary messages in JavaScript, a binary d= atatype is needed.

    Just checked a bit now, found e.g. https://= developer.mozilla.org/en-US/docs/JavaScript_typed_arrays/Arra= yBuffer. It looks like rather than using a very simple datatype with a = literal syntax, they went for a rather complex architecture. They must have= had their reasons, but please don't ask me why.

    If the above is true, then introducing something like
    b'<base64-encoded>' would mean JSON is no longer a subset of = JS.

    Regards, =C2=A0 =C2=A0Martin.

    _______________________________________________
    apps-discuss mailing list
    apps-discuss@iet= f.org
    https://www.ietf.org/mailman/listinfo/apps-discuss

    --0016e6da2e7f6aae5204ca380b24-- From hallam@gmail.com Fri Sep 21 08:41:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB0A21F8687 for ; Fri, 21 Sep 2012 08:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQapCu2Z39Zh for ; Fri, 21 Sep 2012 08:41:53 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 34F5C21F8686 for ; Fri, 21 Sep 2012 08:41:53 -0700 (PDT) Received: by oagn5 with SMTP id n5so3246877oag.31 for ; Fri, 21 Sep 2012 08:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CGwu0l3QXcumS8Awx1Qtcr5NTGepba2nsM9dmMw0ojo=; b=lWw0O51HccS2nnfO2TNFwmRvcbUTpLL6Hpw4LkNvIzXwm1yh9DLSqsqW2mRhZzYMqv O0crctPnOyp05/UrrvsB38fFslPAoKx67ddeKNYw3OvYgKkIS1CKC6JGtqJFfioeAdQh dka5nOdERdQrOeqP6UHZMs7rRNa/Bi6Ml03/dP9fsRACMpvegqDrOw5PTfuaZv3rb9mo WLG7Vld2hE16B2hqr14NS+8QjbOr168mmK6ctfg+GgAzlqNupWq3DrKruBuWmvxxMFk+ 0XUGNY9lKq3vOzNNshOC3uj7Z5vSERi/nw0BznraOx0PP+HCPxncURLfpGdwx040qQwe c3sA== MIME-Version: 1.0 Received: by 10.60.170.9 with SMTP id ai9mr1222409oec.36.1348242112711; Fri, 21 Sep 2012 08:41:52 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Fri, 21 Sep 2012 08:41:52 -0700 (PDT) In-Reply-To: <505C10DB.5080401@gmx.de> References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> <505C10DB.5080401@gmx.de> Date: Fri, 21 Sep 2012 11:41:52 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=bcaec54a3e02330b4804ca3814bb Cc: Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 15:41:54 -0000 --bcaec54a3e02330b4804ca3814bb Content-Type: text/plain; charset=ISO-8859-1 I think it rather obvious that a random number generator used to generate session keys has to be random. But it took me over a week to beat the idea into the Netscape security guy who thought that the current date and time and the IP address was enough randomness for a 128 bit seed. After he finally got the point I sent him the design note for the random number scheme I developed for Shen which he then put in the file and handed over to Taher and co when they took over security. First thing they did was read the file, find my design note and conclude that the design must be solid. They never looked at the code. A year later they were hacked when someone decompiled the code (who would expect an attacker would do that?). Due to a similar IETF history with Kerberos there is no way that you would get an RFC issued today without an SC note that the random number generator has to be random and reference the RFC on the topic. JSON-BIS is not going to issue without a similar note stating the blatantly obvious with respect to an escaped encoding. The point of doing this is 1) To inform the implementer 2) To tell the tester what to look for 3) To assure people reading the spec that the designers are competent. On Fri, Sep 21, 2012 at 3:01 AM, Julian Reschke wrote: > On 2012-09-21 01:35, Phillip Hallam-Baker wrote: > >> ... >> >> I'm sorry, but I must have missed something. Are we playing a game >> of State the Obvious now? >> >> Bingo! >> >> Yes, we are playing a game of state the obvious because that is what >> most security issues tend to end up being. If you have a million lines >> of code then the chance of at least one of them having an obvious error >> is pretty much 100%. It is rather obvious that a buffer overrun is >> likely to be a bad thing but it took over a decade for people to realize >> that it allowed people to smash the stack and pown the machine. >> And given that it has taken us the best part of a day to get to the >> point where the explanation is obvious I think that the problem itself >> is far from obvious. >> >> >> This attack vector (in different incarnations) is currently the most >> commonly used attack against Web Services. >> ... >> > > I personally don't believe that "stating the obvious" is something we > should do in Security Considerations. > > First, because those implementers who even get the obvious things wrong > are unlikely to even look at the spec. > > Second, because adding tons of "obvious" things to the SC totally > distracts from the *non-obvious* things. > > Now what's obvious and what's not of course depends on the background. > Anybody who has dealt with HTML and XML professionally should know that > constructing messages with simple string operations is dangerous. Maybe > that's something that's not was obvious in the JSON world yet. > > Best regards, Julian > -- Website: http://hallambaker.com/ --bcaec54a3e02330b4804ca3814bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it rather obvious that a random number generator used to generate s= ession keys has to be random. But it took me over a week to beat the idea i= nto the Netscape security guy who thought that the current date and time an= d the IP address was enough randomness for a 128 bit seed.

    After he finally got the point I sent him the design note fo= r the random number scheme I developed for Shen which he then put in the fi= le and handed over to Taher and co when they took over security. First thin= g they did was read the file, find my design note and conclude that the des= ign must be solid. They never looked at the code. A year later they were ha= cked when someone decompiled the code (who would expect an attacker would d= o that?).

    Due to a similar IETF history with Kerberos there is no= way that you would get an RFC issued today without an SC note that the ran= dom number generator has to be random and reference the RFC on the topic.

    JSON-BIS is not going to issue without a similar note s= tating the blatantly obvious with respect to an escaped encoding.

    The point of doing this is=A0

    1) To inform the i= mplementer
    2) To tell the tester what to look for
    3) To assure people r= eading the spec that the designers are competent.

    =

    On Fri, Sep 21, 2012 at 3:01 AM, Julian = Reschke <julian.reschke@gmx.de> wrote:
    On 2012-09-21 01:35, Phill= ip Hallam-Baker wrote:
    ...

    =A0 =A0 I'm sorry, but I must have missed something. Are we playing a g= ame
    =A0 =A0 of State the Obvious now?

    Bingo!

    Yes, we are playing a game of state the obvious because that is what
    most security issues tend to end up being. If you have a million lines
    of code then the chance of at least one of them having an obvious error
    is pretty much 100%. It is rather obvious that a buffer overrun is
    likely to be a bad thing but it took over a decade for people to realize that it allowed people to smash the stack and pown the machine.
    And given that it has taken us the best part of a day to get to the
    point where the explanation is obvious I think that the problem itself
    is far from obvious.


    This attack vector (in different incarnations) is currently the most
    commonly used attack against Web Services.
    ...

    I personally don't believe that "stating the obvious" is some= thing we should do in Security Considerations.

    First, because those implementers who even get the obvious things wrong are= unlikely to even look at the spec.

    Second, because adding tons of "obvious" things to the SC totally= distracts from the *non-obvious* things.

    Now what's obvious and what's not of course depends on the backgrou= nd. Anybody who has dealt with HTML and XML professionally should know that= constructing messages with simple string operations is dangerous. Maybe th= at's something that's not was obvious in the JSON world yet.

    Best regards, Julian



    --
    Website: http://hallambaker.com/

    --bcaec54a3e02330b4804ca3814bb-- From nico@cryptonector.com Fri Sep 21 08:47:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5B921E80B0 for ; Fri, 21 Sep 2012 08:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIuhJi4V1WOu for ; Fri, 21 Sep 2012 08:47:08 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 06FC821E80A6 for ; Fri, 21 Sep 2012 08:47:06 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id C1FAD36005C for ; Fri, 21 Sep 2012 08:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=haLjqEfu3nJCzN3huGmb wL8aQuw=; b=v1Mx6ZK491tO+9fqSp1iltYhhUqgbIhue/IQ1D1Vp52tqHR56Yr8 Z32vR/kuD3M+YkM9FkMWvtq4wG5Y137H1Dt9hyutTTjLxzhSlEsosrnVlJovgNOu jD8IYX5U6kcWnAFwWEPnhsIVsLaJLZgBJrZbwiLNLwJp2NQsPAfRYm4= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id A88EB36006F for ; Fri, 21 Sep 2012 08:47:05 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so5516709pbb.31 for ; Fri, 21 Sep 2012 08:47:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.195 with SMTP id ru3mr16429888pbc.149.1348242425363; Fri, 21 Sep 2012 08:47:05 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 21 Sep 2012 08:47:05 -0700 (PDT) In-Reply-To: References: <1348178993.2900.0.camel@polyglot> <08D741A0-6449-41BD-9C10-FA67942B91E4@tzi.org> <505C3098.3030209@it.aoyama.ac.jp> Date: Fri, 21 Sep 2012 10:47:05 -0500 Message-ID: From: Nico Williams To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 15:47:09 -0000 On Fri, Sep 21, 2012 at 10:35 AM, Carsten Bormann wrote: > Now, JSON does not have comments, and the only variability we have for expressing this kind of out-of-band information appears to be whitespace. > E.g., interpret a RFC 4627 JSON string as a base64-encoded byte string if/only if it is preceded by, say, two newlines. Interesting idea. It may well be good enough for me (considering I can't have the way I'd like it). > So a JSON reader not aware of this encoding would need to rely on a schema to know when a string is text or base-64-encoded bytes. > A JSON writer not aware of this would be quite unlikely to emit the two newlines. > (And we'd need a similar covert channel to indicate a JSON text is actually using this encoding.) > > (I'm well aware of the security considerations of this kind of backwards compatibility. But it could be made to work in practice.) Well, no further security considerations than we'd have today when just encoding with base64, except, of course, that we would need to ensure that any canonicalization does not strip out these marker newlines. Nico -- From julian.reschke@gmx.de Fri Sep 21 08:53:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC2E21F8711 for ; Fri, 21 Sep 2012 08:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.024 X-Spam-Level: X-Spam-Status: No, score=-103.024 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOJOYQBH8Ika for ; Fri, 21 Sep 2012 08:53:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id B5AF321F8713 for ; Fri, 21 Sep 2012 08:53:44 -0700 (PDT) Received: (qmail invoked by alias); 21 Sep 2012 15:53:43 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp033) with SMTP; 21 Sep 2012 17:53:43 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19OjxF/UlxOC+X1nAoZ2gJsj2o78/nkGkEB25vOy1 JtFx1PEGWr3Q8r Message-ID: <505C8D7E.9040402@gmx.de> Date: Fri, 21 Sep 2012 17:53:34 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON encoding of binary objects X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 15:53:45 -0000 On 2012-09-21 17:32, Phillip Hallam-Baker wrote: > Here is what I do in Omnibroker, an example message is: > > HTTP/1.1 203 Passcode > ... 203? Really? Best regards, Julian From James.H.Manger@team.telstra.com Fri Sep 21 09:03:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B8721E803D for ; Fri, 21 Sep 2012 09:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.725 X-Spam-Level: X-Spam-Status: No, score=-0.725 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXRbzlcKysqr for ; Fri, 21 Sep 2012 09:03:36 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id A499521E8082 for ; Fri, 21 Sep 2012 09:03:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,464,1344175200"; d="scan'208,217";a="94215023" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 22 Sep 2012 02:03:34 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6842"; a="89200132" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbvi.tcif.telstra.com.au with ESMTP; 22 Sep 2012 02:03:34 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Sat, 22 Sep 2012 02:03:33 +1000 From: "Manger, James H" To: "apps-discuss@ietf.org Discuss" Date: Sat, 22 Sep 2012 02:03:29 +1000 Thread-Topic: JSON patch: setting a value; appending to an array Thread-Index: Ac2YEqQGg+aXajrXSeSwDj3QZVgb1Q== Message-ID: <255B9BB34FB7D647A506DC292726F6E114FD3375AA@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114FD3375AAWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [apps-discuss] JSON patch: setting a value; appending to an array X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 16:03:37 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114FD3375AAWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGN1cnJlbnQgb3BlcmF0aW9ucyBpbiBkcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1wYXRjaC0w NCByZXF1aXJlIHRoZSBjcmVhdG9yIG9mIGEgcGF0Y2ggdG8ga25vdyBhIGZhaXIgYml0IGFib3V0 IHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoZSBKU09OIHJlc291cmNlIGJlaW5nIHBhdGNoZWQg4oCU IG1vcmUgdGhhbiBuZWNlc3NhcnkuDQoNCkNvbnNpZGVyIGEgSlNPTiBvYmplY3QgdGhhdCBjYW4g aGF2ZSBhIGVsZW1lbnQgbmFtZWQgImFjdGl2ZSIuIElmIHlvdSB3YW50IHRoZSBlbGVtZW50IHRv IGJlICJhY3RpdmUiOnRydWUgdGhlIHBhdGNoIG5lZWRzIHRvIGJlOg0KMS4gIFt7ImFkZCI6Ii9h Y3RpdmUiLCAidmFsdWUiOnRydWV9XSAgICBpZiB0aGUgImFjdGl2ZSIgZWxlbWVudCBpcyBhYnNl bnQ7IG9yDQoyLiAgW3sicmVwbGFjZSI6Ii9hY3RpdmUiLCAidmFsdWUiOnRydWV9XSAgICBpZiB0 aGUgImFjdGl2ZSIgZWxlbWVudCBpcyBwcmVzZW50Lg0KSGVuY2UgeW91IGNhbm5vdCBzaW1wbHkg c2V0IHRoZSB2YWx1ZSB3aXRoIGEgcGF0Y2ggd2l0aG91dCBiZWluZyBzdXJlIG9mIHRoZSBvbGQg c3RhdGUuDQoNCkFzIGFub3RoZXIgZXhhbXBsZSwgY29uc2lkZXIgYXBwZW5kaW5nIHRvIGFuIGFy cmF5Lg0KT2xkIGRvYzogIFsyLDMsNSw3LDExXQ0KUGF0Y2g6ICB7ImFkZCI6Ii81IiwgInZhbHVl IjoxM30NCk5ldyBkb2M6ICBbMiwzLDUsNywxMSwxM10NCllvdSBuZWVkIHRvIGtub3cgdGhlIGN1 cnJlbnQgbGVuZ3RoIG9mIHRoZSBhcnJheSAoNSkgdG8gYXBwZW5kIGEgdmFsdWUuIFtZb3UgY2Fu IGluc2VydCBhIG5ldyBpdGVtIGF0IHRoZSBzdGFydCBvZiB0aGUgYXJyYXkgd2l0aG91dCBrbm93 aW5nIHRoZSBhcnJheSBsZW5ndGgsIGJ1dCB0aGF0IGlzIGxlc3MgY29tbW9uLl0NCg0KSXQgd291 bGQgYmUgdXNlZnVsIHRvIGJlIGFibGUgdG8gY29uc3RydWN0IHBhdGNoZXMgZm9yIHRoZSB0d28g dGFza3MgYWJvdmUgd2l0aG91dCBrbm93aW5nIHRoZSBjdXJyZW50IHJlc291cmNlIHN0YXRlLiBU aGF0IGNvdWxkIHNhdmUgYSByb3VuZCB0cmlwIGFuZC9vciBhdm9pZCBzb21lIHN5bmNocm9uaXph dGlvbiByZXF1aXJlbWVudHMuIFRoZSAidGVzdCIgb3BlcmF0aW9uIGNhbiBiZSB1c2VkIHdoZW4g aXTigJlzIG5lY2Vzc2FyeSB0byBlbnN1cmUgYSBKU09OIGRvYyBpcyBpbiB0aGUgY29ycmVjdCBz dGF0ZSB0byBhcHBseSBhIHBhdGNoLg0KDQpJIHN1Z2dlc3Qgd2UgZGVmaW5lIGFuIG5ldyBvcGVy YXRpb246ICJqb2luIi4NCkl0IHRha2VzIHR3byBwYXJhbWV0ZXJzOiBhIHBvaW50ZXI7IGFuZCBh IHZhbHVlLg0KDQpXaGVuIHRoZSB2YWx1ZSBpcyBhbiBhcnJheSB0aGUgcG9pbnRlciBtdXN0IGFs c28gaWRlbnRpZnkgYW4gYXJyYXkgKG90aGVyd2lzZSBpdCBpcyBhbiBlcnJvcikuIFRoZSBpdGVt cyBmcm9tIHRoZSB2YWx1ZSBhcnJheSBhcmUgYXBwZW5kZWQgdG8gdGhlIGlkZW50aWZpZWQgYXJy YXkgaW4gb3JkZXIuDQoNCldoZW4gdGhlIHZhbHVlIGlzIGFuIG9iamVjdCB0aGUgcG9pbnRlciBt dXN0IGFsc28gaWRlbnRpdHkgYW4gb2JqZWN0IChvdGhlcndpc2UgaXQgaXMgYW4gZXJyb3IpLiBU aGUgZWxlbWVudHMgaW4gdGhlIHZhbHVlIGFyZSBhZGRlZCB0byB0aGUgaWRlbnRpZmllZCBvYmpl Y3QsIHJlcGxhY2luZyBhbnkgZWxlbWVudHMgd2l0aCB0aGUgc2FtZSBrZXlzLg0KDQpJdCBpcyBh biBlcnJvciBpZiB0aGUgdmFsdWUgaXMgbm90IGFuIGFycmF5IG9yIGFuIG9iamVjdC4NClt0aG91 Z2ggImpvaW4iaW5nIHR3byBudW1iZXJzIGNvdWxkIGJlIGRlZmluZWQgYXMgbnVtZXJpY2FsIGFk ZGl0aW9uOiB1c2VmdWwgb3IgdG9vIGN1dGU/XQ0KDQpFeGFtcGxlOg0KT2xkIGRvYzogeyJvYmoi OnsiYSI6ImZvbyIsICJiIjoiYmFyIn0sICJqb2IiOlsyLDMsNSw3LDExXX0NCg0KUGF0Y2hlczog Ww0KICB7ImpvaW4iOiIvb2JqIiwgInZhbHVlIjp7ImIiOiJCQVIiLCAiYyI6IkJBWiJ9fSwNCiAg eyJqb2luIjoiL2pvYiIsICJ2YWx1ZSI6WzEzXX0NCl0NCg0KTmV3IGRvYzogIHsib2JqIjp7ImEi OiJmb28iLCAiYiI6IkJBUiIsICJjIjoiQkFaIn0sICJqb2IiOlsyLDMsNSw3LDExLDEzXX0NCg0K DQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg== --_000_255B9BB34FB7D647A506DC292726F6E114FD3375AAWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tQVUgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNs YXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+VGhlIGN1cnJlbnQgb3BlcmF0aW9u cyBpbiBkcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1wYXRjaC0wNCByZXF1aXJlIHRoZSBjcmVhdG9y IG9mIGEgcGF0Y2ggdG8ga25vdyBhIGZhaXIgYml0IGFib3V0IHRoZSBjdXJyZW50IHN0YXRlIG9m IHRoZSBKU09OIHJlc291cmNlIGJlaW5nIHBhdGNoZWQg4oCUIG1vcmUgdGhhbiBuZWNlc3Nhcnku PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD5Db25zaWRlciBhIEpTT04gb2JqZWN0IHRoYXQgY2FuIGhhdmUgYSBl bGVtZW50IG5hbWVkICZxdW90O2FjdGl2ZSZxdW90Oy4gSWYgeW91IHdhbnQgdGhlIGVsZW1lbnQg dG8gYmUgJnF1b3Q7YWN0aXZlJnF1b3Q7OnRydWUgdGhlIHBhdGNoIG5lZWRzIHRvIGJlOjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4xLsKgIFt7JnF1b3Q7YWRkJnF1b3Q7OiZxdW90 Oy9hY3RpdmUmcXVvdDssICZxdW90O3ZhbHVlJnF1b3Q7OnRydWV9XSDCoMKgwqBpZiB0aGUgJnF1 b3Q7YWN0aXZlJnF1b3Q7IGVsZW1lbnQgaXMgYWJzZW50OyBvcjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD4yLsKgIFt7JnF1b3Q7cmVwbGFjZSZxdW90OzomcXVvdDsvYWN0aXZlJnF1 b3Q7LCAmcXVvdDt2YWx1ZSZxdW90Ozp0cnVlfV3CoMKgwqAgaWYgdGhlICZxdW90O2FjdGl2ZSZx dW90OyBlbGVtZW50IGlzIHByZXNlbnQuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PkhlbmNlIHlvdSBjYW5ub3Qgc2ltcGx5IHNldCB0aGUgdmFsdWUgd2l0aCBhIHBhdGNoIHdpdGhv dXQgYmVpbmcgc3VyZSBvZiB0aGUgb2xkIHN0YXRlLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+QXMgYW5vdGhl ciBleGFtcGxlLCBjb25zaWRlciBhcHBlbmRpbmcgdG8gYW4gYXJyYXkuPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPk9sZCBkb2M6IMKgWzIsMyw1LDcsMTFdPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPlBhdGNoOsKgIHsmcXVvdDthZGQmcXVvdDs6JnF1b3Q7LzUmcXVv dDssICZxdW90O3ZhbHVlJnF1b3Q7OjEzfTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD5OZXcgZG9jOsKgIFsyLDMsNSw3LDExLDEzXTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD5Zb3UgbmVlZCB0byBrbm93IHRoZSBjdXJyZW50IGxlbmd0aCBvZiB0aGUgYXJyYXkgKDUp IHRvIGFwcGVuZCBhIHZhbHVlLiBbWW91IGNhbiBpbnNlcnQgYSBuZXcgaXRlbSBhdCB0aGUgc3Rh cnQgb2YgdGhlIGFycmF5IHdpdGhvdXQga25vd2luZyB0aGUgYXJyYXkgbGVuZ3RoLCBidXQgdGhh dCBpcyBsZXNzIGNvbW1vbi5dPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5JdCB3b3VsZCBiZSB1c2VmdWwgdG8g YmUgYWJsZSB0byBjb25zdHJ1Y3QgcGF0Y2hlcyBmb3IgdGhlIHR3byB0YXNrcyBhYm92ZSB3aXRo b3V0IGtub3dpbmcgdGhlIGN1cnJlbnQgcmVzb3VyY2Ugc3RhdGUuIFRoYXQgY291bGQgc2F2ZSBh IHJvdW5kIHRyaXAgYW5kL29yIGF2b2lkIHNvbWUgc3luY2hyb25pemF0aW9uIHJlcXVpcmVtZW50 cy4gVGhlICZxdW90O3Rlc3QmcXVvdDsgb3BlcmF0aW9uIGNhbiBiZSB1c2VkIHdoZW4gaXTigJlz IG5lY2Vzc2FyeSB0byBlbnN1cmUgYSBKU09OIGRvYyBpcyBpbiB0aGUgY29ycmVjdCBzdGF0ZSB0 byBhcHBseSBhIHBhdGNoLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+SSBzdWdnZXN0IHdlIGRlZmluZSBhbiBu ZXcgb3BlcmF0aW9uOiAmcXVvdDtqb2luJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD5JdCB0YWtlcyB0d28gcGFyYW1ldGVyczogYSBwb2ludGVyOyBhbmQgYSB2YWx1ZS48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPldoZW4gdGhlIHZhbHVlIGlzIGFuIGFycmF5IHRoZSBwb2ludGVyIG11 c3QgYWxzbyBpZGVudGlmeSBhbiBhcnJheSAob3RoZXJ3aXNlIGl0IGlzIGFuIGVycm9yKS4gVGhl IGl0ZW1zIGZyb20gdGhlIHZhbHVlIGFycmF5IGFyZSBhcHBlbmRlZCB0byB0aGUgaWRlbnRpZmll ZCBhcnJheSBpbiBvcmRlci48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPldoZW4gdGhlIHZhbHVlIGlzIGFuIG9i amVjdCB0aGUgcG9pbnRlciBtdXN0IGFsc28gaWRlbnRpdHkgYW4gb2JqZWN0IChvdGhlcndpc2Ug aXQgaXMgYW4gZXJyb3IpLiBUaGUgZWxlbWVudHMgaW4gdGhlIHZhbHVlIGFyZSBhZGRlZCB0byB0 aGUgaWRlbnRpZmllZCBvYmplY3QsIHJlcGxhY2luZyBhbnkgZWxlbWVudHMgd2l0aCB0aGUgc2Ft ZSBrZXlzLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+SXQgaXMgYW4gZXJyb3IgaWYgdGhlIHZhbHVlIGlzIG5v dCBhbiBhcnJheSBvciBhbiBvYmplY3QuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs Plt0aG91Z2ggJnF1b3Q7am9pbiZxdW90O2luZyB0d28gbnVtYmVycyBjb3VsZCBiZSBkZWZpbmVk IGFzIG51bWVyaWNhbCBhZGRpdGlvbjogdXNlZnVsIG9yIHRvbyBjdXRlP108bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPkV4YW1wbGU6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPk9sZCBkb2M6IHsm cXVvdDtvYmomcXVvdDs6eyZxdW90O2EmcXVvdDs6JnF1b3Q7Zm9vJnF1b3Q7LCAmcXVvdDtiJnF1 b3Q7OiZxdW90O2JhciZxdW90O30sICZxdW90O2pvYiZxdW90OzpbMiwzLDUsNywxMV19PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD5QYXRjaGVzOiBbPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPsKg IHsmcXVvdDtqb2luJnF1b3Q7OiZxdW90Oy9vYmomcXVvdDssICZxdW90O3ZhbHVlJnF1b3Q7Onsm cXVvdDtiJnF1b3Q7OiZxdW90O0JBUiZxdW90OywgJnF1b3Q7YyZxdW90OzomcXVvdDtCQVomcXVv dDt9fSw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+wqAgeyZxdW90O2pvaW4mcXVv dDs6JnF1b3Q7L2pvYiZxdW90OywgJnF1b3Q7dmFsdWUmcXVvdDs6WzEzXX08bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+XTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+TmV3IGRvYzrCoCB7JnF1b3Q7 b2JqJnF1b3Q7OnsmcXVvdDthJnF1b3Q7OiZxdW90O2ZvbyZxdW90OywgJnF1b3Q7YiZxdW90Ozom cXVvdDtCQVImcXVvdDssICZxdW90O2MmcXVvdDs6JnF1b3Q7QkFaJnF1b3Q7fSwgJnF1b3Q7am9i JnF1b3Q7OlsyLDMsNSw3LDExLDEzXX08Yj48bzpwPjwvbzpwPjwvYj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+LS08bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_255B9BB34FB7D647A506DC292726F6E114FD3375AAWSMSG3153Vsrv_-- From hallam@gmail.com Fri Sep 21 09:08:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74E121F8711 for ; Fri, 21 Sep 2012 09:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.894 X-Spam-Level: X-Spam-Status: No, score=-3.894 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0RBp94Y8fOT for ; Fri, 21 Sep 2012 09:08:59 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2152121F867A for ; Fri, 21 Sep 2012 09:08:59 -0700 (PDT) Received: by oagn5 with SMTP id n5so3281920oag.31 for ; Fri, 21 Sep 2012 09:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fbk2nfGdqrCUEszr1yv7MjdnbHBylDbGrUCMuOk+nGo=; b=i3QKX3wzuAS/mrWEnoGObzD0lq60dvn4JFLQGrgWLT+uARwWwYMX2Qxvpo3BQQNTre FXcFwduT7Sus31zfsXnAgsedsLRMchg2MrVGF8G/MAq/F0o3Hb5olKKWjCqH67gAIiLy rvcT5m9A/cFaphkZOYc7qVgW9uXteGuaRYhT4znkY+QOp9VpG/yssXF724qrxW3fPcc6 gI1Yo5y/IrtlGXZFlucyTFRNX/n514oekfowUm3OWi6oZYbBcuDyce6yHwdyyNaXLC5y spOtlxI8sT+RR3M3VJS+bOAYbWi08PKI9Bm8FM8Xgd1o9roBgEOBVDzYFnCpAQKAefFK vAoQ== MIME-Version: 1.0 Received: by 10.182.75.33 with SMTP id z1mr4267468obv.9.1348243738656; Fri, 21 Sep 2012 09:08:58 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Fri, 21 Sep 2012 09:08:58 -0700 (PDT) In-Reply-To: <505C8D7E.9040402@gmx.de> References: <505C8D7E.9040402@gmx.de> Date: Fri, 21 Sep 2012 12:08:58 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=14dae93994e71d010704ca3875bb Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON encoding of binary objects X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 16:08:59 -0000 --14dae93994e71d010704ca3875bb Content-Type: text/plain; charset=ISO-8859-1 That should be 202 or 200, not decided which yet. ProtoGen not define the HTTP status codes right now. I I did implement them it would be as part of a state machine describing the client and server side operations. The issue that appeared when I tried to do that is that the state machine for the client and server are very different. In fact the server protocol is intentionally stateless. The server side state is bundled into the ticket. On Fri, Sep 21, 2012 at 11:53 AM, Julian Reschke wrote: > On 2012-09-21 17:32, Phillip Hallam-Baker wrote: > >> Here is what I do in Omnibroker, an example message is: >> >> HTTP/1.1 203 Passcode >> > > ... > > 203? Really? > > Best regards, Julian > -- Website: http://hallambaker.com/ --14dae93994e71d010704ca3875bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That should be 202 or 200, not decided which yet.=A0

    Pro= toGen not define the HTTP status codes right now. I I did implement them it= would be as part of a state machine describing the client and server side = operations. The issue that appeared when I tried to do that is that the sta= te machine for the client and server are very different. In fact the server= protocol is intentionally stateless. The server side state is bundled into= the ticket.

    On Fri, Sep 21, 2012 at 11:53 AM, Julia= n Reschke <julian.reschke@gmx.de> wrote:
    On 2012-09-21 17:32, Phillip Hallam-Baker wrote:
    Here is what I do in Omnibroker, an example message is:

    HTTP/1.1 203 Passcode
    > ...

    203? Really?

    Best regards, Julian



    --
    Website: http://hallambaker.com/

    --14dae93994e71d010704ca3875bb-- From nico@cryptonector.com Fri Sep 21 09:47:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1935221F87D5 for ; Fri, 21 Sep 2012 09:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eA-o7qx3WL2f for ; Fri, 21 Sep 2012 09:47:08 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8E20A21F87BD for ; Fri, 21 Sep 2012 09:47:08 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 3552926C069 for ; Fri, 21 Sep 2012 09:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=3p6tv+/lbHsHaeTQ3gy/rWhy0Ow=; b=HsHbXX/FhbU vFnAZABn4QZfncSj3WSTnUYUpffoghAk/32uc4xAMcpxqVgmPAkRKIeMqutAsXBK RJ3NLLS+lyXP9UfJp2qzuii3MlleTJgJP+B4NMSbfgcS+gRHFBXPv6EC+uDxLlY9 lSKHspQWHNpr3F7DiKo1VY3K5LIOIvzo= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 19A1626C057 for ; Fri, 21 Sep 2012 09:47:08 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so5625388pbb.31 for ; Fri, 21 Sep 2012 09:47:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.236.69 with SMTP id us5mr17262660pbc.59.1348246027305; Fri, 21 Sep 2012 09:47:07 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 21 Sep 2012 09:47:07 -0700 (PDT) Date: Fri, 21 Sep 2012 11:47:07 -0500 Message-ID: From: Nico Williams To: Apps Discuss Content-Type: text/plain; charset=UTF-8 Subject: [apps-discuss] JSON Pointer should be called JPath X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 16:47:09 -0000 See subject. We have enough trouble as it is with different terminology for the same concepts all over the place. Why add more to the pile of sets of synonyms that we already have? I don't know the story of why it's JSON Pointer, not JSON Path or JPath (maybe a naming conflict? maybe JSON Pointer has so much less functionality than XPath that it seemed better to distinguish the name strongly?), but short of a trademark dispute I also should not have to care, and neither should anyone else. If there's no trademark conflict then please rename this to JSON Path or JPath. If this doesn't happen ("too late"), well, at least this post will record my objection. Also, really, the I-D[*] for JSON Pointer ought to mention XPath with an informative reference at the very, very least. (I hope the authors are in fact aware of XPath, and preferably also at least conversant with it, if not fluent. Some treatment of the functional differences between XPath and JSON Pointer would be nice.) Nico [*] The one I'm reading is http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-04 From nico@cryptonector.com Fri Sep 21 09:57:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C34621E80B5 for ; Fri, 21 Sep 2012 09:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27BoUbYW94d2 for ; Fri, 21 Sep 2012 09:57:41 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id B442621E8082 for ; Fri, 21 Sep 2012 09:57:41 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 753F4318071 for ; Fri, 21 Sep 2012 09:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=mdno7rujjpy2TWwn/eef 0ZNPRm0=; b=SRdadOHbJdl6xb0eBvPc2Z95sfxAyHY1XufZFmuwayGxlvI0QsW1 82W+6Jd4a2eb0z4hiIcIwCwFn0YV5akV9DH6cpbFghTtolgRBmhplpDj/QNJTell 6wviG2+Dawniyy9XK9d9PV1oFpKSJybBpRMnLHOmEIA4w5h43kBOgSo= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 5B660318059 for ; Fri, 21 Sep 2012 09:57:41 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so5643677pbb.31 for ; Fri, 21 Sep 2012 09:57:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.236.69 with SMTP id us5mr17329695pbc.59.1348246661064; Fri, 21 Sep 2012 09:57:41 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 21 Sep 2012 09:57:40 -0700 (PDT) In-Reply-To: <5059E1E8.6040704@status.net> References: <5059E1E8.6040704@status.net> Date: Fri, 21 Sep 2012 11:57:40 -0500 Message-ID: From: Nico Williams To: Evan Prodromou Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Pointer syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 16:57:42 -0000 On Wed, Sep 19, 2012 at 10:16 AM, Evan Prodromou wrote: > I find it funny that JSON Pointer syntax doesn't map more closely to object > syntax in JavaScript. Why not pile on? Allow me to list my problems with JSON Pointer: - if it's meant to be XPath-like then call it JPath - ~0 and ~1 are not exactly great escapes for ~ and /, no, they're *awful*! Use ~/ and ~~, but not digits (and not even numbers corresponding to the Unicode or ASCII codepoints for these characters!). - Empty key string selection needs to be more obvious. The example given in the I-D is that "/" selects the value of the one key of the root object that is an empty string. WAT? That's not even remotely obvious. - Yeah, JSON Pointer is very limited by comparison to XPath 2.0, but please make it extensible so that it could get that powerful. Nico -- From mnot@mnot.net Fri Sep 21 10:16:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3352F21F8776 for ; Fri, 21 Sep 2012 10:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.199 X-Spam-Level: X-Spam-Status: No, score=-104.199 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ylNpdi48si5 for ; Fri, 21 Sep 2012 10:16:11 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA3A21F874C for ; Fri, 21 Sep 2012 10:16:11 -0700 (PDT) Received: from [172.30.66.198] (unknown [72.247.151.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9719B22E255; Fri, 21 Sep 2012 13:16:04 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Mark Nottingham In-Reply-To: Date: Fri, 21 Sep 2012 10:16:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2445552C-5528-4FA3-BE0B-323C6304852F@mnot.net> References: To: Nico Williams X-Mailer: Apple Mail (2.1498) Cc: Apps Discuss Subject: Re: [apps-discuss] JSON Pointer should be called JPath X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 17:16:12 -0000 On 21/09/2012, at 9:47 AM, Nico Williams wrote: > See subject. >=20 > We have enough trouble as it is with different terminology for the > same concepts all over the place. Why add more to the pile of sets of > synonyms that we already have? I don't know the story of why it's > JSON Pointer, not JSON Path or JPath (maybe a naming conflict? maybe > JSON Pointer has so much less functionality than XPath that it seemed > better to distinguish the name strongly?), but short of a trademark > dispute I also should not have to care, and neither should anyone > else. If there's no trademark conflict then please rename this to > JSON Path or JPath. If this doesn't happen ("too late"), well, at > least this post will record my objection. You're objecting over a *name*? Really? The most obvious reason we can't do this is that there's already = something called JSON Path . And = before it's asked, I do think we have reasonable grounds for not using = it (besides the fact that it hasn't been submitted); we need something = with a much smaller profile. > Also, really, the I-D[*] for JSON Pointer ought to mention XPath with > an informative reference at the very, very least. (I hope the authors > are in fact aware of XPath, and preferably also at least conversant > with it, if not fluent. Some treatment of the functional differences > between XPath and JSON Pointer would be nice.) This isn't an academic paper, it's a spec. If we mentioned every similar = technology, we'd a) forget a bunch of people, thereby pissing them off, = and b) make it about twice as long. -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Fri Sep 21 10:21:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3235F21F8707 for ; Fri, 21 Sep 2012 10:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.054 X-Spam-Level: X-Spam-Status: No, score=-104.054 tagged_above=-999 required=5 tests=[AWL=-1.455, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJlGz1N6CRcU for ; Fri, 21 Sep 2012 10:21:39 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 681D821F86FF for ; Fri, 21 Sep 2012 10:21:39 -0700 (PDT) Received: from [172.30.66.198] (unknown [72.247.151.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E60C022E259; Fri, 21 Sep 2012 13:21:31 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Mark Nottingham In-Reply-To: <505C10DB.5080401@gmx.de> Date: Fri, 21 Sep 2012 10:21:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> <505C10DB.5080401@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1498) Cc: Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 17:21:40 -0000 On 21/09/2012, at 12:01 AM, Julian Reschke = wrote: >=20 > I personally don't believe that "stating the obvious" is something we = should do in Security Considerations. >=20 > First, because those implementers who even get the obvious things = wrong are unlikely to even look at the spec. >=20 > Second, because adding tons of "obvious" things to the SC totally = distracts from the *non-obvious* things. >=20 > Now what's obvious and what's not of course depends on the background. = Anybody who has dealt with HTML and XML professionally should know that = constructing messages with simple string operations is dangerous. Maybe = that's something that's not was obvious in the JSON world yet. +1 and well said.=20 We agonise over Security Considerations, failing to consider that the = people who need to read them won't, so all we do is make ourselves feel = better that we've "improved security." -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Fri Sep 21 10:28:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581EC21F8489 for ; Fri, 21 Sep 2012 10:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJ0zE+cnC4BX for ; Fri, 21 Sep 2012 10:28:07 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 558AC21F8437 for ; Fri, 21 Sep 2012 10:28:07 -0700 (PDT) Received: from [172.30.66.198] (unknown [72.247.151.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7AF9222E256; Fri, 21 Sep 2012 13:28:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Mark Nottingham In-Reply-To: Date: Fri, 21 Sep 2012 10:28:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1348178993.2900.0.camel@polyglot> <08D741A0-6449-41BD-9C10-FA67942B91E4@tzi.org> <505C3098.3030209@it.aoyama.ac.jp> To: Nico Williams X-Mailer: Apple Mail (2.1498) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Content Rules and the need for schema languages for JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 17:28:08 -0000 You folks are getting way off track, and I can see Crockford holding his = head in his hands and weeping. Or maybe reaching for a gun. Go off and invent something new, fine, but please don't call it "JSON" = anything. And, specify it as something broadly applicable at your peril = (lest myself and others watching this in horror have something to aim = at). Cheers, On 21/09/2012, at 8:47 AM, Nico Williams wrote: > On Fri, Sep 21, 2012 at 10:35 AM, Carsten Bormann = wrote: >> Now, JSON does not have comments, and the only variability we have = for expressing this kind of out-of-band information appears to be = whitespace. >> E.g., interpret a RFC 4627 JSON string as a base64-encoded byte = string if/only if it is preceded by, say, two newlines. >=20 > Interesting idea. It may well be good enough for me (considering I > can't have the way I'd like it). >=20 >> So a JSON reader not aware of this encoding would need to rely on a = schema to know when a string is text or base-64-encoded bytes. >> A JSON writer not aware of this would be quite unlikely to emit the = two newlines. >> (And we'd need a similar covert channel to indicate a JSON text is = actually using this encoding.) >>=20 >> (I'm well aware of the security considerations of this kind of = backwards compatibility. But it could be made to work in practice.) >=20 > Well, no further security considerations than we'd have today when > just encoding with base64, except, of course, that we would need to > ensure that any canonicalization does not strip out these marker > newlines. >=20 > Nico > -- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From hallam@gmail.com Fri Sep 21 10:32:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B103A21F877B for ; Fri, 21 Sep 2012 10:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.886 X-Spam-Level: X-Spam-Status: No, score=-3.886 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvrJxH+Qd156 for ; Fri, 21 Sep 2012 10:32:31 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0BDF21F8777 for ; Fri, 21 Sep 2012 10:32:31 -0700 (PDT) Received: by oagn5 with SMTP id n5so3377666oag.31 for ; Fri, 21 Sep 2012 10:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L53BkgSd46zso4JYpQ42Tw0JxCoV6lwRJiq2Lk2S9xY=; b=jEkN+FHIj+lBoMT1FfSgUejiuxG6kMBEwLPfx77B3d9JM46VWrmD2zyiFRWbaRfL4X fVGFIo3qbrOlfagZWl6z1BGQX5cgFeTMcfJk5/w2eF+fG+K1j5kusKKZxR4sNAOVwqip iQln5EXaqHLebd5Dwj4z/kOLEaFyavdkjM5bA7RtRtZKjvEzkGS0tWqHlr9FGc0UE8KU ybHzB6FFhg4jI4xnk0YzusDaZmaQ5LmjGcjWCWIdpJvmwKvNP6RRPHyzgi4ubmPjt42W bnc8Kgo6ba2XG/sZVRad3kGRHYuQO5evl0qRz+Q5aWhNx+Te/ySsyj2DhujOtrEKrZzX U8PA== MIME-Version: 1.0 Received: by 10.182.152.36 with SMTP id uv4mr4333711obb.81.1348248751316; Fri, 21 Sep 2012 10:32:31 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Fri, 21 Sep 2012 10:32:31 -0700 (PDT) In-Reply-To: References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> <505C10DB.5080401@gmx.de> Date: Fri, 21 Sep 2012 13:32:31 -0400 Message-ID: From: Phillip Hallam-Baker To: Mark Nottingham Content-Type: multipart/alternative; boundary=f46d044472f3e41dbb04ca399f0e Cc: Julian Reschke , Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 17:32:32 -0000 --f46d044472f3e41dbb04ca399f0e Content-Type: text/plain; charset=ISO-8859-1 The primary point of the SC sections is to demonstrate that we at least have considered these issues. But the people who read them are often managers and people writing RFPs. If you have exposure to the policy level you will know that there are many people who make decisions about technology that have never written a single line of code and never intend to. This is not a major issue. If it was a major issue then the response would be 'heel no, don't endorse this format'. The process we have here is that when drafts are submitted, someone on SECDIR is going to do a review and submit comments in last call. I thought people wanted to know what to put in the SC section to avoid a DISCUSS. Sorry if that was not clear. I don't see the need to be so defensive here. I suggest the following as a path forward, I will write up an SC section for the draft that I think will cover likely objections. The other outstanding issues with the current draft seem to be moving the statement about object ordering into the syntax section and removing the MIME type registration and instead putting in an IANA section requesting the existing entry be updated. Anything else missing? Has anyone talked to the original author on this? On Fri, Sep 21, 2012 at 1:21 PM, Mark Nottingham wrote: > > On 21/09/2012, at 12:01 AM, Julian Reschke wrote: > > > > I personally don't believe that "stating the obvious" is something we > should do in Security Considerations. > > > > First, because those implementers who even get the obvious things wrong > are unlikely to even look at the spec. > > > > Second, because adding tons of "obvious" things to the SC totally > distracts from the *non-obvious* things. > > > > Now what's obvious and what's not of course depends on the background. > Anybody who has dealt with HTML and XML professionally should know that > constructing messages with simple string operations is dangerous. Maybe > that's something that's not was obvious in the JSON world yet. > > > +1 and well said. > > We agonise over Security Considerations, failing to consider that the > people who need to read them won't, so all we do is make ourselves feel > better that we've "improved security." > > -- > Mark Nottingham > http://www.mnot.net/ > > > > > -- Website: http://hallambaker.com/ --f46d044472f3e41dbb04ca399f0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The primary point of the SC sections is to demonstrate that we at least hav= e considered these issues.

    But the people who read them = are often managers and people writing RFPs. If you have exposure to the pol= icy level you will know that there are many people who make decisions about= technology that have never written a single line of code and never intend = to.

    This is not a major issue. If it was a major issue then= the response would be 'heel no, don't endorse this format'.

    The process we have here is that when drafts are sub= mitted, someone on SECDIR is going to do a review and submit comments in la= st call. I thought people wanted to know what to put in the SC section to a= void a DISCUSS. Sorry if that was not clear.


    I don't see the need to be so defens= ive here. I suggest the following as a path forward, I will write up an SC = section for the draft that I think will cover likely objections. The other = outstanding issues with the current draft seem to be moving the statement a= bout object ordering into the syntax section and removing the MIME type reg= istration and instead putting in an IANA section requesting the existing en= try be updated.

    Anything else missing? Has anyone talked to the origina= l author on this?


    On Fri, Sep = 21, 2012 at 1:21 PM, Mark Nottingham <mnot@mnot.net> wrote:

    On 21/09/2012, at 12:01 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
    >
    > I personally don't believe that "stating the obvious" is= something we should do in Security Considerations.
    >
    > First, because those implementers who even get the obvious things wron= g are unlikely to even look at the spec.
    >
    > Second, because adding tons of "obvious" things to the SC to= tally distracts from the *non-obvious* things.
    >
    > Now what's obvious and what's not of course depends on the bac= kground. Anybody who has dealt with HTML and XML professionally should know= that constructing messages with simple string operations is dangerous. May= be that's something that's not was obvious in the JSON world yet.

    +1 and well said.

    We agonise over Security Considerations, failing to consider that the peopl= e who need to read them won't, so all we do is make ourselves feel bett= er that we've "improved security."

    --
    Mark Nottingham
    http://www.mnot.net/=







    --
    Website: http://hallambaker.com/

    --f46d044472f3e41dbb04ca399f0e-- From mnot@mnot.net Fri Sep 21 10:40:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2D121F866E for ; Fri, 21 Sep 2012 10:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.83 X-Spam-Level: X-Spam-Status: No, score=-103.83 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxpG0y7XNWZv for ; Fri, 21 Sep 2012 10:40:53 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id CCC3521F865C for ; Fri, 21 Sep 2012 10:40:53 -0700 (PDT) Received: from [172.30.66.198] (unknown [72.247.151.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B2C7522E256; Fri, 21 Sep 2012 13:40:46 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Mark Nottingham In-Reply-To: Date: Fri, 21 Sep 2012 10:40:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> <505C10DB.5080401@gmx.de> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1498) Cc: Julian Reschke , Ned Freed , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 17:40:54 -0000 On 21/09/2012, at 10:32 AM, Phillip Hallam-Baker = wrote: > Has anyone talked to the original author on this? Yes, I have, at the request of the ADs. He's fine with it going standards-track, and has a few ambiguities he'd = like to fix. He is concerned about people seeing an opportunity to = "improve it", thereby breaking compatibility, but it seems we have this = pretty well in hand. Regards, -- Mark Nottingham http://www.mnot.net/ From paul.hoffman@vpnc.org Fri Sep 21 10:49:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C810121E80BD for ; Fri, 21 Sep 2012 10:49:16 -0700 (PDT) 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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQ4m81-r2Tyb for ; Fri, 21 Sep 2012 10:49:16 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 57C9421E80BB for ; Fri, 21 Sep 2012 10:49:16 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q8LHnDqn066305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Sep 2012 10:49:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Paul Hoffman In-Reply-To: Date: Fri, 21 Sep 2012 10:49:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6DFD8A55-B432-49D1-AD54-D0D62829ABE2@vpnc.org> <7328D528-7915-4675-8067-DD23373F8DFB@vpnc.org> <01OKH096DL180006TF@mauve.mrochek.com> <0B281559-CD98-400D-A21B-AC13F75C9552@vpnc.org> <01OKH59WL0SW0006TF@mauve.mrochek.com> <505B5922.5020704@gmx.de> <505B5C7B.1010005@gmx.de> <505B7812.30702@gmx.de> <505C10DB.5080401@gmx.de> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1498) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Guidance on RFC 4627 as reference X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 17:49:16 -0000 On Sep 21, 2012, at 10:32 AM, Phillip Hallam-Baker = wrote: > The primary point of the SC sections is to demonstrate that we at = least have considered these issues. A giant -1 to that. --Paul Hoffman= From fgaliegue@gmail.com Fri Sep 21 10:58:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF70621F8690 for ; Fri, 21 Sep 2012 10:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPOFSs1NtKOd for ; Fri, 21 Sep 2012 10:58:13 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8A921F8686 for ; Fri, 21 Sep 2012 10:58:13 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4593069vcb.31 for ; Fri, 21 Sep 2012 10:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=iod6dOQmlelbN5+9RW+r1Zgti3sHz9JMTKWYQTWBakM=; b=C1Ye1z6n0Bi5Bb8/z/4Dn4RVcFNGhtLm/R2dcHoGGxQ/HrrsQeWLUPDFNmAZnGXX+Z Kt/T5MkgiWAmVdUE5NyFbapkCg4eOjMhmpRFGo4iCGtOA8L+Gm7Lnhl+NmDQeqZSuyKR EjsuEsHeUI0zZe2yIhDo1Ufb6jDleUMgQeizzhBwz6I2rR8jBfP8wbP/HkgdAT0aC2PO Glkunbl+lCRZHnKP2Y7xNi7rRLyecwKrBcRb0z195OvoBuEWPNUm74I0rHOXbgyLAvQg YguUjr/bL0gxK4sDy6U9Xds7vYeXiC5hmAx9tcnwrLNJqVxYVVAcv4peMIlFmiXjazrs nu9Q== MIME-Version: 1.0 Received: by 10.58.74.196 with SMTP id w4mr3523813vev.7.1348250292549; Fri, 21 Sep 2012 10:58:12 -0700 (PDT) Received: by 10.52.72.137 with HTTP; Fri, 21 Sep 2012 10:58:12 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Sep 2012 19:58:12 +0200 Message-ID: From: Francis Galiegue To: Nico Williams Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss Subject: Re: [apps-discuss] JSON Pointer should be called JPath X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 17:58:14 -0000 On Fri, Sep 21, 2012 at 6:47 PM, Nico Williams wrot= e: [...] > > Also, really, the I-D[*] for JSON Pointer ought to mention XPath with > an informative reference at the very, very least. > Why? XPath can select several nodes, JSON Pointer can "select" only one. With the added advantage that it can be used in URI fragments. Also, neither "/" or "" are valid XML tag names. In fact, a JSON object member's name can be any JSON string value. JSON Path exists but right now it cannot quite address such things either. JSON Pointer, on the other hand, has no trouble with that. --=20 Francis Galiegue, fgaliegue@gmail.com JSON Schema: https://github.com/json-schema "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From mnot@mnot.net Fri Sep 21 11:37:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E70D21F86E5 for ; Fri, 21 Sep 2012 11:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.742 X-Spam-Level: X-Spam-Status: No, score=-103.742 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnY0XaexH4H4 for ; Fri, 21 Sep 2012 11:37:14 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id C656421F8697 for ; Fri, 21 Sep 2012 11:37:13 -0700 (PDT) Received: from [172.30.66.198] (unknown [72.247.151.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6809522E253; Fri, 21 Sep 2012 14:37:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Mark Nottingham In-Reply-To: <1348098123.5269.8.camel@polyglot> Date: Fri, 21 Sep 2012 11:37:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0542E643-0298-4262-8D60-37C97E765531@mnot.net> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6 E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <1348077816.2880.9.camel@polyglot> <1348080756.2880.32.camel@polyglot> <1348098123.5269.8.camel@polyglot> To: "apps-discuss@ietf.org Discuss" X-Mailer: Apple Mail (2.1498) Subject: [apps-discuss] JSON Patch: Changing Operator Syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 18:37:15 -0000 On 19/09/2012, at 4:42 PM, Paul C. Bryan wrote: >> When using something like "op":"replace" as an alternative, however, = this additional validation check becomes entirely unnecessary and the = possibility of ambiguity dissolves completely. For me, this is much more = advantageous than saving a few bytes on the wire. >=20 > Well, there was significant feedback against separate operation and = path members at the time. Personally, I'm ambivalent on this; I like = both approaches for different reasons, though the current method wins = out by a small margin. That said, if strong consensus to change to = bifurcating to separate op/path were to be established, I wouldn't = resist. My .02 - I'd support op/path, as long as we can get there quickly and = not rathole on it.=20 Does anyone object strongly to changing the syntax of an operation to = something approximately like: { "op": "add", "path": "/a/b/c", "value": "foo" } Cheers, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Fri Sep 21 11:46:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8EA21F870F for ; Fri, 21 Sep 2012 11:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.366 X-Spam-Level: X-Spam-Status: No, score=-103.366 tagged_above=-999 required=5 tests=[AWL=-1.367, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2l3oPe7GgoLZ for ; Fri, 21 Sep 2012 11:46:07 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1A98421F870E for ; Fri, 21 Sep 2012 11:46:07 -0700 (PDT) Received: from [172.30.66.198] (unknown [72.247.151.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4CE8C22E256; Fri, 21 Sep 2012 14:45:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Mark Nottingham In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FD2A9600@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 21 Sep 2012 11:46:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6 E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FD2316D2@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FD2A9600@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1498) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 18:46:08 -0000 Hi James, On 20/09/2012, at 12:40 AM, "Manger, James H" = wrote: >>>>> An array based approach=20 >=20 >>> The main issue, aside from the basic possible extensibility >>> ramifications is that it just *feels* like an entirely pointless >>> optimization... a change that buys us absolutely nothing in terms of >>> real functionality and simply trades one set of potential issues for >>> another. The spec version of code smell. >=20 > Given that each operation is likely to be mapped to a function call = such as add(ptr, val), an array approach ["add", ptr, val] seems quite = natural. The object-based approach *feels* like an entirely pointless = optimization... an optimization to support some potential extensibility = that we explicitly don't want. >=20 > Extensions by adding new operations is potentially useful -- it is = equally easy with an array approach or an object-with-op-member = approach. >=20 > Extensions by adding new parameters to previously defined operations = sounds bad -- so the fact that that may be easier with an = object-with-op-member approach is not actually an advantage. I understand your arguments, and don't disagree on any point. People = naturally reach for an object because of its properties when extended, = and we *don't* want extensibility here. However, my sense is that it's going to be hard to convince people to = change to an array-based syntax. Could be wrong, but that's what I see = from here. > I suggest that the patch spec should say: > 1. "it is an error condition if an operation name is unrecognised" We're already there... > 2. "unrecognized parameters MUST be ignored" > It is so likely that some/many implementations will not bother to = check that there are no unrecognized parameters that the spec should not = imply that anyone can rely on those checks occurring. I'd be OK with this, as long as we clarify that this means that the = format explicitly doesn't allow extensions, and that we can get = consensus quickly. Others? -- Mark Nottingham http://www.mnot.net/ From hallam@gmail.com Fri Sep 21 12:05:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E28D21F8759 for ; Fri, 21 Sep 2012 12:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.882 X-Spam-Level: X-Spam-Status: No, score=-3.882 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4WSiJM7gQ0B for ; Fri, 21 Sep 2012 12:05:52 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E065F21F8754 for ; Fri, 21 Sep 2012 12:05:51 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4038549obb.31 for ; Fri, 21 Sep 2012 12:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rN6rRFXNuXQu11Co+ULy6KDUCNvpoa4Po7mUZhE5M3A=; b=a4dlK5IMMJyN56tejHQFmK6bN6ZhTPQGGpZEPp1oTNRuBOPJtkIxUjEOArKzpbHUI+ kI91GXpHq11khfaTwk5MIaGHbpv0r/1sfZo3HoSh8T+hMavorXfw9GhENGU08UL2XJyU esp0PFyvlqOStdXXmaxC9WDDRJTtJj4wcgkTP8NHDGAgI2RVVY+qsri9ChaGMKvhgyi0 /RyJoZIfGcERlHpdnmeLlOIRNPL+i/wLajnnYzdb4JnNF/SDu3mn6S2BwOVTgnxkLTY1 s18FrEn7xQFTyVAPUZaycUQn9xBDmC0jk+wVMAnryJrFiQ+n99yOFxYs0EXfyhPBHzon L11Q== MIME-Version: 1.0 Received: by 10.182.197.73 with SMTP id is9mr4594870obc.32.1348254351541; Fri, 21 Sep 2012 12:05:51 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Fri, 21 Sep 2012 12:05:51 -0700 (PDT) In-Reply-To: <0542E643-0298-4262-8D60-37C97E765531@mnot.net> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <1348077816.2880.9.camel@polyglot> <1348080756.2880.32.camel@polyglot> <1348098123.5269.8.camel@polyglot> <0542E643-0298-4262-8D60-37C97E765531@mnot.net> Date: Fri, 21 Sep 2012 15:05:51 -0400 Message-ID: From: Phillip Hallam-Baker To: Mark Nottingham Content-Type: multipart/alternative; boundary=14dae9399cadb0c7d004ca3aed7b Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] JSON Patch: Changing Operator Syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 19:05:53 -0000 --14dae9399cadb0c7d004ca3aed7b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 21, 2012 at 2:37 PM, Mark Nottingham wrote: > > On 19/09/2012, at 4:42 PM, Paul C. Bryan wrote: > > >> When using something like "op":"replace" as an alternative, however, > this additional validation check becomes entirely unnecessary and the > possibility of ambiguity dissolves completely. For me, this is much more > advantageous than saving a few bytes on the wire. > > > > Well, there was significant feedback against separate operation and path > members at the time. Personally, I'm ambivalent on this; I like both > approaches for different reasons, though the current method wins out by a > small margin. That said, if strong consensus to change to bifurcating to > separate op/path were to be established, I wouldn't resist. > > My .02 - I'd support op/path, as long as we can get there quickly and not > rathole on it. > > Does anyone object strongly to changing the syntax of an operation to > something approximately like: > > { "op": "add", "path": "/a/b/c", "value": "foo" } > I prefer this to the -04 version: { "add": "/a/b/c", "value": [ "foo", "bar" ] } "/a/b/c" does look to me to be a path attribute to me. But my preferred version would be {"add" : {"path": "/a/b/c", "value": "foo" }} That would seem to me to be the right way to do it. One advantage being that it ensures that the operation always comes first. The following is equivalent but much harder to follow: { "path": "/a/b/c", "op": "add", "value": "foo" } -- Website: http://hallambaker.com/ --14dae9399cadb0c7d004ca3aed7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Fri, Sep 21, 2012 at 2:37 PM, Mark No= ttingham <mnot@mnot.net> wrote:
    pbryan@anode.ca> wrote:

    >> When using something like "op":"replace" as an= alternative, however, this additional validation check becomes entirely un= necessary and the possibility of ambiguity dissolves completely. For me, th= is is much more advantageous than saving a few bytes on the wire.
    >
    > Well, there was significant feedback against separate operation and pa= th members at the time. Personally, I'm ambivalent on this; I like both= approaches for different reasons, though the current method wins out by a = small margin. That said, if strong consensus to change to bifurcating to se= parate op/path were to be established, I wouldn't resist.

    My .02 - =A0I'd support op/path, as long as we can get there quickly an= d not rathole on it.

    Does anyone object strongly to changing the syntax of an operation to somet= hing approximately like:

    { "op": "add", "path": "/a/b/c", &q= uot;value": "foo" }

    I pr= efer this to the -04 version:
    { &qu= ot;add": "/a/b/c", "value": [ "foo", &qu= ot;bar" ] }=A0

    "/a/b/c" does look to me to be a pat= h attribute to me.

    But my preferred version would = be

    {"add" : {"path": "/a/= b/c", "value": "foo" }}

    That would seem to me to be the right way to do it. One= advantage being that it ensures that the operation always comes first. The= following is equivalent but much harder to follow:

    { =A0"path": "/a/b/c",=A0"op": "add= ",=A0"value": "foo" }

    --
    W= ebsite: http://hallambaker.com/
    =
    --14dae9399cadb0c7d004ca3aed7b-- From jasnell@gmail.com Fri Sep 21 12:09:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6219921E805D for ; Fri, 21 Sep 2012 12:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZ9W4rc6N4aA for ; Fri, 21 Sep 2012 12:09:14 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1F221E8045 for ; Fri, 21 Sep 2012 12:09:14 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1935881wib.13 for ; Fri, 21 Sep 2012 12:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JPxzwlpG6OscasSz80sw1rptMwBqVnRJUISjloSuq+E=; b=zsotqOLLq6Ioirz8CzJuieP+wCwxiguNXvLRePOEw8cAEAS3nuYCPk64Cd6VMozkP9 R/r6m/1igyoz3x/jadZyLNTKeRQ5IQ3SQyfxHN0AGX6O9wziJAeACjQFfV3hyVU/XoQY ZRFwDVl7lfgFS+x578XKGblWCzzXDhxCrSlpPEjk+6fpY896E0tENbo0/Q5pEd9KqtX5 AUMPV+jKRYJYZ4mpVCf4yBFZEB/ccdYXvqF1vsBcLSjpxbERqYFkec9mjGmOjk/PNyM3 khr3vOj0Ao3Y7HlhZlIAoItz2KUeXgvFTbT7RDsafMkQfykOee6vFQZ7d1wJ2UPyz5g5 rj4g== Received: by 10.216.135.148 with SMTP id u20mr3250913wei.137.1348254553226; Fri, 21 Sep 2012 12:09:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Fri, 21 Sep 2012 12:08:52 -0700 (PDT) In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FD2316D2@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FD2A9600@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Fri, 21 Sep 2012 12:08:52 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=0016e6dd9920b63d4c04ca3af933 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 19:09:15 -0000 --0016e6dd9920b63d4c04ca3af933 Content-Type: text/plain; charset=UTF-8 On Fri, Sep 21, 2012 at 11:46 AM, Mark Nottingham wrote: > [snip] > > > 2. "unrecognized parameters MUST be ignored" > > It is so likely that some/many implementations will not bother to check > that there are no unrecognized parameters that the spec should not imply > that anyone can rely on those checks occurring. > > I'd be OK with this, as long as we clarify that this means that the format > explicitly doesn't allow extensions, and that we can get consensus quickly. > Others? > > I'm ok with this. I just want to make sure that it's crystal clear to everyone that the semantics of an existing change operation cannot be modified by adding new attributes down the road. That is, if some client application happens to send {"op":"test", "path": "/a/b/c", "value": "foo", "ignore_case":"true"}, the "ignore_case" will be ignored completely. There can be absolutely zero ambiguity on that point. - James > -- > Mark Nottingham > http://www.mnot.net/ > > > > > --0016e6dd9920b63d4c04ca3af933 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On Fri, Sep 21, 2012 at 11:46 AM, Mark Notti= ngham <mnot@mnot.net> wrote:
    [snip]

    > 2. "unrecognized parameters MUST be ignored"
    > It is so likely that some/many implementations will not bother to chec= k that there are no unrecognized parameters that the spec should not imply = that anyone can rely on those checks occurring.

    I'd be OK with this, as long as we clarify that this means that t= he format explicitly doesn't allow extensions, and that we can get cons= ensus quickly. Others?

    <= br>
    I'm ok with this. I just want to make sure that it's = crystal clear to everyone that the semantics of an existing change operatio= n cannot be modified by adding new attributes down the road. That is, if so= me client application happens to send {"op":"test", &qu= ot;path": "/a/b/c", "value": "foo", &quo= t;ignore_case":"true"}, the "ignore_case" will be = ignored completely. There can be absolutely zero ambiguity on that point.

    - James
    =C2=A0
    --
    Mark Nottingham
    http://www.mnot.net/=





    --0016e6dd9920b63d4c04ca3af933-- From mnot@mnot.net Fri Sep 21 12:11:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED3F21E8045 for ; Fri, 21 Sep 2012 12:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.58 X-Spam-Level: X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=-0.981, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhqNyieMqhtk for ; Fri, 21 Sep 2012 12:11:53 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC3E21E805D for ; Fri, 21 Sep 2012 12:11:53 -0700 (PDT) Received: from [172.30.66.198] (unknown [72.247.151.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C822B22E255; Fri, 21 Sep 2012 15:11:46 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Mark Nottingham In-Reply-To: Date: Fri, 21 Sep 2012 12:11:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <1347910396.19756.29.camel@pbry an-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FD2316D2@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FD2A9600@WSMSG3153V.srv.dir.telstra.com> To: James M Snell X-Mailer: Apple Mail (2.1498) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 19:11:54 -0000 On 21/09/2012, at 12:08 PM, James M Snell wrote: > > 2. "unrecognized parameters MUST be ignored" > > It is so likely that some/many implementations will not bother to = check that there are no unrecognized parameters that the spec should not = imply that anyone can rely on those checks occurring. >=20 > I'd be OK with this, as long as we clarify that this means that the = format explicitly doesn't allow extensions, and that we can get = consensus quickly. Others? >=20 >=20 > I'm ok with this. I just want to make sure that it's crystal clear to = everyone that the semantics of an existing change operation cannot be = modified by adding new attributes down the road. That is, if some client = application happens to send {"op":"test", "path": "/a/b/c", "value": = "foo", "ignore_case":"true"}, the "ignore_case" will be ignored = completely. There can be absolutely zero ambiguity on that point. +1 -- Mark Nottingham http://www.mnot.net/ From dret@berkeley.edu Fri Sep 21 13:05:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC0F21E8043; Fri, 21 Sep 2012 13:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpiCXGPlj2cT; Fri, 21 Sep 2012 13:05:56 -0700 (PDT) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE3A11E8097; Fri, 21 Sep 2012 13:05:56 -0700 (PDT) Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.64]) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TF9U2-00021x-I7; Fri, 21 Sep 2012 13:05:56 -0700 Message-ID: <505CC89F.7080006@berkeley.edu> Date: Fri, 21 Sep 2012 13:05:51 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: link-relations@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hypermedia-web@googlegroups.com, REST-Discuss , "apps-discuss@ietf.org application-layer protocols" Subject: [apps-discuss] request to register 'profile' link relation (http://tools.ietf.org/html/draft-wilde-profile-link-03) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 20:05:57 -0000 dear link-relations experts, this is a request to register http://tools.ietf.org/html/draft-wilde-profile-link-03 in the IANA link relations registry established by RFC 5988. the latest draft of the registration document is available at http://tools.ietf.org/html/draft-wilde-profile-link-03, and the last version announced on a variety of mailing lists has not generated any feedback asking for changes. should the registration request be accepted, my understanding is that the draft registration document will be forwarded to IANA for registration by a designated expert. thanks a lot and kind regards, erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From martin.thomson@gmail.com Fri Sep 21 15:38:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A0E21F8630 for ; Fri, 21 Sep 2012 15:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.721 X-Spam-Level: X-Spam-Status: No, score=-3.721 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+ld1RxFN-5R for ; Fri, 21 Sep 2012 15:38:22 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6FEE21F8618 for ; Fri, 21 Sep 2012 15:38:21 -0700 (PDT) Received: by lboj14 with SMTP id j14so4392201lbo.31 for ; Fri, 21 Sep 2012 15:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FkBDaPEnlu9dGfO2JMOgmvSd86t5sqi/Jt3tzE9uXu4=; b=hnI/Uy4kGm5+NNdTVvRGGBUzXhc7tvm1Q0BeYIn4qabp+XvqfAOmrohGpQhWEXQ+z/ 39585lXKrtohMiRRmnW1Oqu0VjXyPGP0dHhyiMU7X4QCYG46MhwAsgQtlkMryQUn8G+q EkqA+rWwrNDEGB6b1uI9QYGqVrKk/6Dr4QXIQAOuUeE/ADQ0GN3t3VNYQfzN61LMXBCm icVqt6CsMGAWD7tm8KA0mQch2VXqTR8eSeKXo1Z9ompEIoByzTkysy+m6/MKUVWwtJlQ ivd2vsRDsOzLpD0StQ3ekb6kg4h6iHQLddA17M0KULA7JM31VwhDUoKS7C0HJJWts6p5 nyUw== MIME-Version: 1.0 Received: by 10.112.84.233 with SMTP id c9mr1584787lbz.111.1348267100478; Fri, 21 Sep 2012 15:38:20 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Fri, 21 Sep 2012 15:38:20 -0700 (PDT) In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <1348077816.2880.9.camel@polyglot> <1348080756.2880.32.camel@polyglot> <1348098123.5269.8.camel@polyglot> <0542E643-0298-4262-8D60-37C97E765531@mnot.net> Date: Fri, 21 Sep 2012 15:38:20 -0700 Message-ID: From: Martin Thomson To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] JSON Patch: Changing Operator Syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 22:38:22 -0000 On 21 September 2012 12:05, Phillip Hallam-Baker wrote: > But my preferred version would be > > {"add" : {"path": "/a/b/c", "value": "foo" }} Interesting, what does this do then? {"add" : {"path": "/a/b/c", "value": "foo" }, "delete": {"path": "/a/b/c"}} From martin.thomson@gmail.com Fri Sep 21 15:51:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33DA21E809A for ; Fri, 21 Sep 2012 15:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.716 X-Spam-Level: X-Spam-Status: No, score=-3.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOWBX2FabOV0 for ; Fri, 21 Sep 2012 15:51:27 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED06821E8099 for ; Fri, 21 Sep 2012 15:51:26 -0700 (PDT) Received: by lboj14 with SMTP id j14so4401465lbo.31 for ; Fri, 21 Sep 2012 15:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5KOKyU5ohFQEkg1yu2hrLppJR1QpzFKxiQPfBM2J+HM=; b=qeJDPG0TCBTUOgMWgFOwk9h9OnmjaiwFdQY3EU0/hGIIL6Io4SPGn/IPPDAZX1KonQ IvVF4Sp2eg7XUKadlj3bFK+zoge/H340CxglrRazNO6UewWEhZncBxwFOWHnkPgiYmhc EInD40II6HHPoxwfXf1E+9bO1dw/NVR284B+ZtQ3fCamuj8Tgl6bv8T9OH9y/yBmrDT9 FTn4W90769wVyi00e2h4C9OJlApIERU2nXzhO7ONohHPRrgtacVO2OYR+cWcSoSe7Wrh geOY7ipZiC823YNDE4/OMddwht0wudM3Ih4Ve7UHfx3DtRLpPwH2Fw35VR1gCi6elFnf AayA== MIME-Version: 1.0 Received: by 10.152.48.102 with SMTP id k6mr3804826lan.12.1348267885455; Fri, 21 Sep 2012 15:51:25 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Fri, 21 Sep 2012 15:51:25 -0700 (PDT) In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FD2316D2@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FD2A9600@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 21 Sep 2012 15:51:25 -0700 Message-ID: From: Martin Thomson To: James M Snell Content-Type: text/plain; charset=UTF-8 Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 22:51:27 -0000 On 21 September 2012 12:08, James M Snell wrote: > I'm ok with this. I just want to make sure that it's crystal clear to > everyone that the semantics of an existing change operation cannot be > modified by adding new attributes down the road. That is, if some client > application happens to send {"op":"test", "path": "/a/b/c", "value": "foo", > "ignore_case":"true"}, the "ignore_case" will be ignored completely. There > can be absolutely zero ambiguity on that point. +1 I observe that there is no way to define a new type of test in -04. { "test_ignore_case":"/a/b/c", "value": "foo" } is a new unsupported operation, but I didn't see rules on what to do with those. Do unsupported/unknown operations cause processing to fail? If so, then this would be the right way to implement a case-ignoring test. From algermissen1971@mac.com Fri Sep 21 14:33:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2009C21F8487; Fri, 21 Sep 2012 14:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jm9PER68wtQ; Fri, 21 Sep 2012 14:33:01 -0700 (PDT) Received: from nk11p03mm-asmtp003.mac.com (nk11p03mm-asmtpout003.mac.com [17.158.232.38]) by ietfa.amsl.com (Postfix) with ESMTP id 8080421F8484; Fri, 21 Sep 2012 14:33:01 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.2.103] ([84.143.182.243]) by nk11p03mm-asmtp003.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0MAP005BMYIP6I80@nk11p03mm-asmtp003.mac.com>; Fri, 21 Sep 2012 21:32:53 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.431,0.0.0000 definitions=2012-09-21_11:2012-09-21, 2012-09-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1209210271 From: Jan Algermissen In-reply-to: <505CC89F.7080006@berkeley.edu> Date: Fri, 21 Sep 2012 23:32:49 +0200 Message-id: References: <505CC89F.7080006@berkeley.edu> To: link-relations@ietf.org X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Sat, 22 Sep 2012 09:11:30 -0700 Cc: hypermedia-web@googlegroups.com, REST-Discuss , "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] request to register 'profile' link relation (http://tools.ietf.org/html/draft-wilde-profile-link-03) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 21:33:02 -0000 Hi Erik, On Sep 21, 2012, at 10:05 PM, Erik Wilde wrote: > dear link-relations experts, > > this is a request to register http://tools.ietf.org/html/draft-wilde-profile-link-03 in the IANA link relations registry established by RFC 5988. the latest draft of the registration document is available at http://tools.ietf.org/html/draft-wilde-profile-link-03, and the last version announced on a variety of mailing lists has not generated any feedback asking for changes. "While this specification associates profiles with resource representations, creators and users of profiles MAY define and manage them in a way that they can be used across media types and thus could be associated with a resource, independent of its representations (i.e., using the same profile URI for in different media types)." Wonder whether this contradicts the idea that 'Link' is an *entity* header? Ignoring my personal uneasiness regarding profiles in general, looks fine to me. Jan (And in fact, I could use it for a client next week who needs to differentiate variations of HTML snippets :-) > > should the registration request be accepted, my understanding is that the draft registration document will be forwarded to IANA for registration by a designated expert. > > thanks a lot and kind regards, > > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | > > -- > You received this message because you are subscribed to the Google Groups "Hypermedia Web" group. > To post to this group, send email to hypermedia-web@googlegroups.com. > To unsubscribe from this group, send email to hypermedia-web+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/hypermedia-web?hl=en. > From jasnell@gmail.com Sat Sep 22 09:54:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0406321F869C for ; Sat, 22 Sep 2012 09:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frOKHJBtJQoz for ; Sat, 22 Sep 2012 09:54:37 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCC6D21F8670 for ; Sat, 22 Sep 2012 09:54:36 -0700 (PDT) Received: by weyx48 with SMTP id x48so2789685wey.31 for ; Sat, 22 Sep 2012 09:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=G1KRD8g3INY6j9NFJ5y8jlyiDz0izEWRmz7cPHgx0SE=; b=McE7Onl7fN3YBwkjkMBCgd57wQHJel7Ybfw6GQ+T8hFJ+vAyv3fQEY4AjFyguH1gsM sOBY3gm+E57aP7dxFZAd2/4/Q358yhtgwULObMy0IqyobQwawYA09aV4BO9+HfahG3+o RRdTOvkO2ScKh3woCCRuAFgP5Oygh9Ibg3nD5l3+uLWg6+M+6pijumvCLspsSHNdJPzz aZiMSiGtia+lMNpJ1EMXE6VTlPtrskkjSx8NJd0W9fVlMd3O8OCFTzSOotrBrShH80Pz xEomfyaOVKG2BFw83kQsbN4/hDz438CxaUdX5gaWNmjKMLFt93T2JrZadI54fZz/bYjn YMbg== Received: by 10.180.82.164 with SMTP id j4mr3872575wiy.18.1348332875822; Sat, 22 Sep 2012 09:54:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Sat, 22 Sep 2012 09:54:15 -0700 (PDT) In-Reply-To: <0542E643-0298-4262-8D60-37C97E765531@mnot.net> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <1348077816.2880.9.camel@polyglot> <1348080756.2880.32.camel@polyglot> <1348098123.5269.8.camel@polyglot> <0542E643-0298-4262-8D60-37C97E765531@mnot.net> From: James M Snell Date: Sat, 22 Sep 2012 09:54:15 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=f46d04428d961a350304ca4d360a Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] JSON Patch: Changing Operator Syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 16:54:38 -0000 --f46d04428d961a350304ca4d360a Content-Type: text/plain; charset=UTF-8 +1 on using the separate op/path/value syntax On Fri, Sep 21, 2012 at 11:37 AM, Mark Nottingham wrote: > > On 19/09/2012, at 4:42 PM, Paul C. Bryan wrote: > > >> When using something like "op":"replace" as an alternative, however, > this additional validation check becomes entirely unnecessary and the > possibility of ambiguity dissolves completely. For me, this is much more > advantageous than saving a few bytes on the wire. > > > > Well, there was significant feedback against separate operation and path > members at the time. Personally, I'm ambivalent on this; I like both > approaches for different reasons, though the current method wins out by a > small margin. That said, if strong consensus to change to bifurcating to > separate op/path were to be established, I wouldn't resist. > > My .02 - I'd support op/path, as long as we can get there quickly and not > rathole on it. > > Does anyone object strongly to changing the syntax of an operation to > something approximately like: > > { "op": "add", "path": "/a/b/c", "value": "foo" } > > Cheers, > > -- > Mark Nottingham > http://www.mnot.net/ > > > > > --f46d04428d961a350304ca4d360a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 on using the separate op/path/value= syntax=C2=A0

    On Fri, Sep 21, 2012= at 11:37 AM, Mark Nottingham <mnot@mnot.net> wrote:

    On 19/09/2012, at 4:42 PM, Paul C. Bryan <pbryan@anode.ca> wrote:

    >> When using something like "op":"replace" as an= alternative, however, this additional validation check becomes entirely un= necessary and the possibility of ambiguity dissolves completely. For me, th= is is much more advantageous than saving a few bytes on the wire.
    >
    > Well, there was significant feedback against separate operation and pa= th members at the time. Personally, I'm ambivalent on this; I like both= approaches for different reasons, though the current method wins out by a = small margin. That said, if strong consensus to change to bifurcating to se= parate op/path were to be established, I wouldn't resist.

    My .02 - =C2=A0I'd support op/path, as long as we can get there quickly= and not rathole on it.

    Does anyone object strongly to changing the syntax of an operation to somet= hing approximately like:

    { "op": "add", "path": "/a/b/c", &q= uot;value": "foo" }

    Cheers,

    --
    Mark Nottingham
    http://www.mnot.net/=





    --f46d04428d961a350304ca4d360a-- From hallam@gmail.com Sat Sep 22 10:40:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A295621F8674 for ; Sat, 22 Sep 2012 10:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.962 X-Spam-Level: X-Spam-Status: No, score=-3.962 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqBIVXUVqRIF for ; Sat, 22 Sep 2012 10:40:01 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13DCF21F866E for ; Sat, 22 Sep 2012 10:39:54 -0700 (PDT) Received: by oagn5 with SMTP id n5so4187452oag.31 for ; Sat, 22 Sep 2012 10:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BYPsjFkTNDZR684kt9CkV/Wl04i4i8/VwtbPhYOK18o=; b=f4M3Ubwjw7imeSIB+NawWgm/8m3kx4UdRRbuVpdDIorbfscRY5mohWB26aRQk+wbv3 jbK6YEeKC5Nc/u6v0+c4e7fNRAc4puWNdLx0LoqoC0B28Dtt0aD5zuopSraFUFVyT6xx oW2MkmJrqrcu51A1FobcojR1MmjfMADLgVfZDAEA+ssJP/EJKiCYwVCri3+NzovVI66r bfAlE4J18sagAp2BXtS5gXOC1Pm9jSpmVvooqECnPBliwgvTZczXqkGSRHsQ+wF6sHO1 zhB2SEAG1yx5S3nFVunU9vVHpmYLmWGx0rtB8agERqRuVKKC0eyfEyriJriebVCvvTJb aHNw== MIME-Version: 1.0 Received: by 10.60.170.229 with SMTP id ap5mr6398951oec.101.1348335593715; Sat, 22 Sep 2012 10:39:53 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Sat, 22 Sep 2012 10:39:53 -0700 (PDT) In-Reply-To: References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <1348077816.2880.9.camel@polyglot> <1348080756.2880.32.camel@polyglot> <1348098123.5269.8.camel@polyglot> <0542E643-0298-4262-8D60-37C97E765531@mnot.net> Date: Sat, 22 Sep 2012 13:39:53 -0400 Message-ID: From: Phillip Hallam-Baker To: Martin Thomson Content-Type: multipart/alternative; boundary=bcaec54b4ac019f7ad04ca4dd877 Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] JSON Patch: Changing Operator Syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 17:40:02 -0000 --bcaec54b4ac019f7ad04ca4dd877 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 21, 2012 at 6:38 PM, Martin Thomson wrote: > On 21 September 2012 12:05, Phillip Hallam-Baker wrote: > > But my preferred version would be > > > > {"add" : {"path": "/a/b/c", "value": "foo" }} > > Interesting, what does this do then? > > {"add" : {"path": "/a/b/c", "value": "foo" }, "delete": {"path": "/a/b/c"}} > Well I would probably want to prohibit that as ambiguous and insist on an array: [{"add" : {"path": "/a/b/c", "value": "foo" }}, {"delete": {"path": "/a/b/c"}}] It would probably be a good idea to limit commands to one command per slot. That is what I do in my protocol compiler. If you need more than one command then use an array. In my schema I have: Type add String path String value Sealed // raise exception to unknown tags. Type delete String path String value Sealed That looks pretty clean to me. Adding a move command also looks pretty clean: Type move String from String to Sealed If you have an application where you have an option of doing things in parallel then you might have something like: {"Seq" : [ {"Par" : [ {"add" : {"path": "/a/b/c", "value": "foo" }}, {"add" : {"path": "/a/b/d", "value": "foo" }}]}, {"delete": {"path": "/a/b/c"}}] } That would be nonsense for a patch application (unless the patches were to separate files). But it could make a lot of sense in a different context. JSON syntax seems to be pretty well adapted to doing this sort of thing. It looks pretty convenient. -- Website: http://hallambaker.com/ --bcaec54b4ac019f7ad04ca4dd877 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Fri, Sep 21, 2012 at 6:38 PM, Martin = Thomson <martin.thomson@gmail.com> wrote:
    On 21 September 2012 12:05, Phillip Hallam-Baker <hallam@gmail.com> wrote:
    > But my preferred version would be
    >
    > {"add" : {"path": "/a/b/c", "value&= quot;: "foo" }}

    Interesting, what does this do then?

    {"add" : {"path": "/a/b/c", "value"= : "foo" }, "delete": {"path": "/a/b/c&qu= ot;}}

    Well I would probably want to prohibit that as ambig= uous and insist on an array:

    [{"add" : {&= quot;path": "/a/b/c", "value": "foo" }},= {"delete": {"path": "/a/b/c"}}]

    It would probably be a good idea to limit commands to o= ne command per slot. That is what I do in my protocol compiler. If you need= more than one command then use an array.=A0

    In my= schema I have:

    Type add
    =A0 =A0 String path
    =A0 = =A0 String value
    =A0 =A0 Sealed =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0// raise exception to unknown tags.

    Type delete=
    =A0 =A0 String path
    =A0 =A0 String value
    =A0 =A0 Sealed

    That looks pretty clean to me. Adding a move command also looks pretty cle= an:

    Type move
    =A0 =A0 String from
    <= div>=A0 =A0 String to
    =A0 =A0 Sealed


    If you have an = application where you have an option of doing things in parallel then you m= ight have something like:

    {"Seq" :=A0[
    =A0 =A0 =A0{"Par" : [
    =A0 =A0 =A0 =A0 =A0 =A0{&quo= t;add" : {"path": "/a/b/c", "value": &qu= ot;foo" }},=A0{"add" : {"path": "/a/b/d"= , "value": "foo" }}]},
    =A0 =A0 =A0{"delete": {"path": "/a/b/c"}= }] }

    That would be nonsense for a patch applicatio= n (unless the patches were to separate files). But it could make a lot of s= ense in a different context.

    JSON syntax seems to be pretty well adapted to doing th= is sort of thing. It looks pretty convenient.


    =
    --
    Website: http://hallambake= r.com/

    --bcaec54b4ac019f7ad04ca4dd877-- From James.H.Manger@team.telstra.com Sun Sep 23 17:48:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A39C21F845C for ; Sun, 23 Sep 2012 17:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.153 X-Spam-Level: X-Spam-Status: No, score=0.153 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_24=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_45=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8huGLV58Jrt for ; Sun, 23 Sep 2012 17:48:27 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 8799521F845B for ; Sun, 23 Sep 2012 17:48:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,472,1344175200"; d="scan'208";a="92682934" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipocni.tcif.telstra.com.au with ESMTP; 24 Sep 2012 10:48:10 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6844"; a="90811051" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipccni.tcif.telstra.com.au with ESMTP; 24 Sep 2012 10:48:10 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Mon, 24 Sep 2012 10:48:10 +1000 From: "Manger, James H" To: Mark Nottingham Date: Mon, 24 Sep 2012 10:48:08 +1000 Thread-Topic: [apps-discuss] JSON Patch: extensibility Thread-Index: Ac2YKV7LF/HVJzthSvGvNJN7w6VumQBuWlPQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114FD337B3F@WSMSG3153V.srv.dir.telstra.com> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6 E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FD2316D2@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FD2A9600@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 00:48:28 -0000 PiA+Pj4+PiBBbiBhcnJheSBiYXNlZCBhcHByb2FjaA0KPiA+DQouLi4NCj4gPiBHaXZlbiB0aGF0 IGVhY2ggb3BlcmF0aW9uIGlzIGxpa2VseSB0byBiZSBtYXBwZWQgdG8gYSBmdW5jdGlvbiBjYWxs DQo+IHN1Y2ggYXMgYWRkKHB0ciwgdmFsKSwgYW4gYXJyYXkgYXBwcm9hY2ggWyJhZGQiLCBwdHIs IHZhbF0gc2VlbXMgcXVpdGUNCj4gbmF0dXJhbC4gVGhlIG9iamVjdC1iYXNlZCBhcHByb2FjaCAq ZmVlbHMqIGxpa2UgYW4gZW50aXJlbHkgcG9pbnRsZXNzDQo+IG9wdGltaXphdGlvbi4uLiBhbiBv cHRpbWl6YXRpb24gdG8gc3VwcG9ydCBzb21lIHBvdGVudGlhbCBleHRlbnNpYmlsaXR5DQo+IHRo YXQgd2UgZXhwbGljaXRseSBkb24ndCB3YW50Lg0KPiA+DQo+ID4gRXh0ZW5zaW9ucyBieSBhZGRp bmcgbmV3IG9wZXJhdGlvbnMgaXMgcG90ZW50aWFsbHkgdXNlZnVsIC0tIGl0IGlzDQo+IGVxdWFs bHkgZWFzeSB3aXRoIGFuIGFycmF5IGFwcHJvYWNoIG9yIGFuIG9iamVjdC13aXRoLW9wLW1lbWJl cg0KPiBhcHByb2FjaC4NCj4gPg0KPiA+IEV4dGVuc2lvbnMgYnkgYWRkaW5nIG5ldyBwYXJhbWV0 ZXJzIHRvIHByZXZpb3VzbHkgZGVmaW5lZCBvcGVyYXRpb25zDQo+IHNvdW5kcyBiYWQgLS0gc28g dGhlIGZhY3QgdGhhdCB0aGF0IG1heSBiZSBlYXNpZXIgd2l0aCBhbiBvYmplY3Qtd2l0aC0NCj4g b3AtbWVtYmVyIGFwcHJvYWNoIGlzIG5vdCBhY3R1YWxseSBhbiBhZHZhbnRhZ2UuDQoNCj4gSSB1 bmRlcnN0YW5kIHlvdXIgYXJndW1lbnRzLCBhbmQgZG9uJ3QgZGlzYWdyZWUgb24gYW55IHBvaW50 LiBQZW9wbGUNCj4gbmF0dXJhbGx5IHJlYWNoIGZvciBhbiBvYmplY3QgYmVjYXVzZSBvZiBpdHMg cHJvcGVydGllcyB3aGVuIGV4dGVuZGVkLA0KPiBhbmQgd2UgKmRvbid0KiB3YW50IGV4dGVuc2li aWxpdHkgaGVyZS4NCj4gDQo+IEhvd2V2ZXIsIG15IHNlbnNlIGlzIHRoYXQgaXQncyBnb2luZyB0 byBiZSBoYXJkIHRvIGNvbnZpbmNlIHBlb3BsZSB0bw0KPiBjaGFuZ2UgdG8gYW4gYXJyYXktYmFz ZWQgc3ludGF4LiBDb3VsZCBiZSB3cm9uZywgYnV0IHRoYXQncyB3aGF0IEkgc2VlDQo+IGZyb20g aGVyZS4NCg0KUGVyaGFwcyB3ZSBzaG91bGQgcmFuZG9taXNlIHRoZSBvcmRlciBvZiBuYW1lOnZh bHVlIHBhaXJzIGluIHRoZSBzcGVjIGV4YW1wbGVzIGFzIGEgc3VidGxlIHJlbWluZGVyIHRoYXQg eW91IGRvIGhhdmUgdG8gaXRlcmF0ZSB0aHJvdWdoIHRoZW0gYWxsIHRvIGZpbmQgYSBuYW1lIHRo YXQgaXMgYW4gb3BlcmF0aW9uICh3aXRoIGRyYWZ0IDA0IHN5bnRheCkuDQogIHsidmFsdWUiOiJx dXgiLCAiYWRkIjoiL2JheiJ9DQoNCkluY2x1ZGluZyBleGFtcGxlcyBvZiBvcGVyYXRpb25zIHRo YXQgTVVTVCBiZSByZWplY3RlZCB3b3VsZCBiZSBhIGdvb2QgaGludCBhcyB0byBhbnkgZXh0cmEg ZWZmb3J0IHJlcXVpcmVkIHRvIGltcGxlbWVudCB0aG9zZSBjaGVja3MuIEZvciBpbnN0YW5jZSwg dGhlIGZvbGxvd2luZyBNVVNUIGJlIHJlamVjdGVkOg0KICB7InZhbHVlIjoicXV4IiwgImFkZCI6 Ii9iYXoiLCAiXHUwMDcyZW1vdmUiOiIvYmF6In0NCg0KT3Igd2l0aCBvcDpuYW1lIHN5bnRheCwg dGhlIGZvbGxvd2luZyBNVVNUIGJlIHJlamVjdGVkIChub3Qgc2lsZW50bHkgdHJlYXRlZCBhcyBh biAiYWRkIiBvciAicmVtb3ZlIik6DQogIHsidmFsdWUiOiJxdXgiLCAicGF0aCI6Ii9iYXoiLCAi b3AiOiJhZGQiLCAib3AiOiJyZW1vdmUifQ0KDQpXaGVyZWFzIHRoZSBmb2xsb3dpbmcgaXMgYSB2 YWxpZCAiYWRkIiBvcGVyYXRpb24gKGlnbm9yZSB0aGUgcGFyYW1ldGVyIHdpdGggYW4gdW5rbm93 biBuYW1lICJPUCIpDQogIHsiT1AiOiJyZW1vdmUiLCAidmFsdWUiOiJxdXgiLCAicGF0aCI6Ii9i YXoiLCAiXHUwMDZGcCI6Ilx1MDA2MWRkIn0NCg0KU2VlaW5nIGV4YW1wbGVzIGxpa2UgdGhlc2Ug bWFrZXMgYW4gYXJyYXktYmFzZWQgYXBwcm9hY2ggbG9vayBzaW1wbGVyIGFuZCBzYWZlci4NCg0K DQo+ID4gMi4gInVucmVjb2duaXplZCBwYXJhbWV0ZXJzIE1VU1QgYmUgaWdub3JlZCINCj4gPiBJ dCBpcyBzbyBsaWtlbHkgdGhhdCBzb21lL21hbnkgaW1wbGVtZW50YXRpb25zIHdpbGwgbm90IGJv dGhlciB0bw0KPiBjaGVjayB0aGF0IHRoZXJlIGFyZSBubyB1bnJlY29nbml6ZWQgcGFyYW1ldGVy cyB0aGF0IHRoZSBzcGVjIHNob3VsZA0KPiBub3QgaW1wbHkgdGhhdCBhbnlvbmUgY2FuIHJlbHkg b24gdGhvc2UgY2hlY2tzIG9jY3VycmluZy4NCg0KPiBJJ2QgYmUgT0sgd2l0aCB0aGlzLCBhcyBs b25nIGFzIHdlIGNsYXJpZnkgdGhhdCB0aGlzIG1lYW5zIHRoYXQgdGhlDQo+IGZvcm1hdCBleHBs aWNpdGx5IGRvZXNuJ3QgYWxsb3cgZXh0ZW5zaW9ucywgYW5kIHRoYXQgd2UgY2FuIGdldA0KPiBj b25zZW5zdXMgcXVpY2tseS4gT3RoZXJzPw0KDQpTYXlpbmcgInVucmVjb2duaXplZCBwYXJhbWV0 ZXJzIE1VU1QgYmUgaWdub3JlZCIgbWVhbnMgbmV3IHBhcmFtZXRlcnMgY2FuIGJlIGluc2VydGVk IGluIGZ1dHVyZSwgd2l0aCB0aGUgY2xlYXIgdW5kZXJzdGFuZGluZyB0aGF0IG9sZCBpbXBsZW1l bnRhdGlvbnMgd2lsbCBpZ25vcmUgdGhlbSBzbyB0aGV5IGNhbiBvbmx5IGJlIG9wdGlvbmFsIGhp bnRzLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From pbryan@anode.ca Sun Sep 23 17:53:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A6021F8554 for ; Sun, 23 Sep 2012 17:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Lz13v5dYH-9 for ; Sun, 23 Sep 2012 17:53:08 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 541F421F845C for ; Sun, 23 Sep 2012 17:53:08 -0700 (PDT) Received: from [192.168.1.10] (S0106a021b762dbb3.vf.shawcable.net [174.1.50.247]) by maple.anode.ca (Postfix) with ESMTPSA id 3F9936156; Mon, 24 Sep 2012 00:53:06 +0000 (UTC) Message-ID: <1348448025.26754.2.camel@polyjuice> From: "Paul C. Bryan" To: Mark Nottingham Date: Sun, 23 Sep 2012 17:53:45 -0700 In-Reply-To: <0542E643-0298-4262-8D60-37C97E765531@mnot.net> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6 E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <1348077816.2880.9.camel@polyglot> <1348080756.2880.32.camel@polyglot> <1348098123.5269.8.camel@polyglot> <0542E643-0298-4262-8D60-37C97E765531@mnot.net> Content-Type: multipart/alternative; boundary="=-YN9tHKYlGk0dYIF39CHP" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] JSON Patch: Changing Operator Syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 00:53:09 -0000 --=-YN9tHKYlGk0dYIF39CHP Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit +1 on reinstating "op". Paul On Fri, 2012-09-21 at 11:37 -0700, Mark Nottingham wrote: > On 19/09/2012, at 4:42 PM, Paul C. Bryan wrote: > > >> When using something like "op":"replace" as an alternative, however, this additional validation check becomes entirely unnecessary and the possibility of ambiguity dissolves completely. For me, this is much more advantageous than saving a few bytes on the wire. > > > > Well, there was significant feedback against separate operation and path members at the time. Personally, I'm ambivalent on this; I like both approaches for different reasons, though the current method wins out by a small margin. That said, if strong consensus to change to bifurcating to separate op/path were to be established, I wouldn't resist. > > My .02 - I'd support op/path, as long as we can get there quickly and not rathole on it. > > Does anyone object strongly to changing the syntax of an operation to something approximately like: > > { "op": "add", "path": "/a/b/c", "value": "foo" } > > Cheers, > > -- > Mark Nottingham > http://www.mnot.net/ > > > > --=-YN9tHKYlGk0dYIF39CHP Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit +1 on reinstating "op".

    Paul

    On Fri, 2012-09-21 at 11:37 -0700, Mark Nottingham wrote: 
    On 19/09/2012, at 4:42 PM, Paul C. Bryan <pbryan@anode.ca> wrote:

>> When using something like "op":"replace" as an alternative, however, this additional validation check becomes entirely unnecessary and the possibility of ambiguity dissolves completely. For me, this is much more advantageous than saving a few bytes on the wire.
> 
> Well, there was significant feedback against separate operation and path members at the time. Personally, I'm ambivalent on this; I like both approaches for different reasons, though the current method wins out by a small margin. That said, if strong consensus to change to bifurcating to separate op/path were to be established, I wouldn't resist.

My .02 -  I'd support op/path, as long as we can get there quickly and not rathole on it. 

Does anyone object strongly to changing the syntax of an operation to something approximately like:

{ "op": "add", "path": "/a/b/c", "value": "foo" }

Cheers,

--
Mark Nottingham
http://www.mnot.net/

    --=-YN9tHKYlGk0dYIF39CHP-- From James.H.Manger@team.telstra.com Sun Sep 23 18:01:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476CF21F857E for ; Sun, 23 Sep 2012 18:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.664 X-Spam-Level: X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BZiX872+SMJ for ; Sun, 23 Sep 2012 18:01:52 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 79DB621F8573 for ; Sun, 23 Sep 2012 18:01:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,472,1344175200"; d="scan'208";a="92685122" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 24 Sep 2012 11:01:51 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6844"; a="84884817" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcdni.tcif.telstra.com.au with ESMTP; 24 Sep 2012 11:01:51 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Mon, 24 Sep 2012 11:01:51 +1000 From: "Manger, James H" To: Phillip Hallam-Baker , Martin Thomson Date: Mon, 24 Sep 2012 11:01:50 +1000 Thread-Topic: [apps-discuss] JSON Patch: Changing Operator Syntax Thread-Index: Ac2Y6U+gEcOSXMg7RlSS1qndm7Z1kgBBQV0Q Message-ID: <255B9BB34FB7D647A506DC292726F6E114FD337BAC@WSMSG3153V.srv.dir.telstra.com> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <1348077816.2880.9.camel@polyglot> <1348080756.2880.32.camel@polyglot> <1348098123.5269.8.camel@polyglot> <0542E643-0298-4262-8D60-37C97E765531@mnot.net> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] JSON Patch: Changing Operator Syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 01:01:53 -0000 Pj4+IEJ1dCBteSBwcmVmZXJyZWQgdmVyc2lvbiB3b3VsZCBiZQ0KPj4+DQo+Pj4geyJhZGQiIDog eyJwYXRoIjogIi9hL2IvYyIsICJ2YWx1ZSI6ICJmb28iIH19DQoNCj4+IEludGVyZXN0aW5nLCB3 aGF0IGRvZXMgdGhpcyBkbyB0aGVuPw0KPj4gDQo+PiB7ImFkZCIgOiB7InBhdGgiOiAiL2EvYi9j IiwgInZhbHVlIjogImZvbyIgfSwgImRlbGV0ZSI6IHsicGF0aCI6DQo+PiAiL2EvYi9jIn19DQog DQo+IFdlbGwgSSB3b3VsZCBwcm9iYWJseSB3YW50IHRvIHByb2hpYml0IHRoYXQgYXMgYW1iaWd1 b3VzIGFuZCBpbnNpc3Qgb24NCj4gYW4gYXJyYXk6DQo+IA0KPiBbeyJhZGQiIDogeyJwYXRoIjog Ii9hL2IvYyIsICJ2YWx1ZSI6ICJmb28iIH19LCB7ImRlbGV0ZSI6IHsicGF0aCI6DQo+ICIvYS9i L2MifX1dDQoNClBoaWxsaXAsDQpUd2VhayB5b3VyIHByZWZlcnJlZCBzeW50YXggKGZvciBhIHNp bmdsZSBvcGVyYXRpb24pIGZyb206DQogIHsiYWRkIiA6IHsicGF0aCI6ICIvYS9iL2MiLCAidmFs dWUiOiAiZm9vIiB9fQ0KdG86DQogIFsiYWRkIiAsIHsicGF0aCI6ICIvYS9iL2MiLCAidmFsdWUi OiAiZm9vIiB9XQ0KYW5kIHByb2hpYml0aW5nIE1hcnRpbuKAmXMgZXhhbXBsZSB0aGF0IGludHJv ZHVjZXMgYW1iaWd1aXR5IHdpbGwgb2NjdXIgbmF0dXJhbGx5Lg0KDQooVGhlIHdob2xlIHBhdGNo IGRvYyBpcyBhbiBhcnJheSBvZiB0aGVzZSBvcGVyYXRpb25zLCByZWdhcmRsZXNzIG9mIHdoZXRo ZXIgYW4gYXJyYXkgb3Igb2JqZWN0IHN5bnRheCBpcyBjaG9zZW4gZm9yIGVhY2ggaW5kaXZpZHVh bCBvcGVyYXRpb24pDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From hallam@gmail.com Sun Sep 23 18:36:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C8321F847D for ; Sun, 23 Sep 2012 18:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.698 X-Spam-Level: X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHKIJx-PDCH7 for ; Sun, 23 Sep 2012 18:36:16 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id B80DD21F8470 for ; Sun, 23 Sep 2012 18:36:16 -0700 (PDT) Received: by oagn5 with SMTP id n5so4942292oag.31 for ; Sun, 23 Sep 2012 18:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3LOTZW5B3S6Q+VFWKpLXPDs6jbijUf7j4XJWGK7bUmI=; b=TuUFkNIZQQq4Oqkwuj8P78s0iYj24VMxdw5P+sxCdVISb3kvu/TonBtBXGYr9zESXI r3+1J2GqtmIoEBenxQtYMDb7/SKDsbAraIwTWCuq1q9ipvlPqp1ly8BnX54jdhqUUN7F tTMedY/EkmSdaXm6tld7fXnZT/1WbUiJnCVnWHiQFBnFnHroTLUCCLDeAYY1dcXw09lc XcyZOIEaKIzpNB+d4r+qLdix34xqDZ12i4dtJiypTh69F/lKoT0p21iClGfSjOd/nABx 4Ro0aSYJPrv3Y3kaL8bRbn/KI3wKFaHoMgkM5qdO8WfO8yfXy0UC4kW3z2ZOqv5Q7SEM 1I1g== MIME-Version: 1.0 Received: by 10.60.170.229 with SMTP id ap5mr8604061oec.101.1348450576293; Sun, 23 Sep 2012 18:36:16 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Sun, 23 Sep 2012 18:36:16 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FD2A9600@WSMSG3153V.srv.dir.telstra.com> References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FD2316D2@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FD2A9600@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 23 Sep 2012 21:36:16 -0400 Message-ID: From: Phillip Hallam-Baker To: "Manger, James H" Content-Type: multipart/alternative; boundary=bcaec54b4ac098dd7004ca689d3c Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch: extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 01:36:17 -0000 --bcaec54b4ac098dd7004ca689d3c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 20, 2012 at 3:40 AM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > > >> > An array based approach > > > > The main issue, aside from the basic possible extensibility > > > ramifications is that it just *feels* like an entirely pointless > > > optimization... a change that buys us absolutely nothing in terms of > > > real functionality and simply trades one set of potential issues for > > > another. The spec version of code smell. > > Given that each operation is likely to be mapped to a function call such > as add(ptr, val), an array approach ["add", ptr, val] seems quite natural. > The object-based approach *feels* like an entirely pointless > optimization... an optimization to support some potential extensibility > that we explicitly don't want. > ["add", ptr, val] remove the comas, change the brackets and we get ("add" ptr val) I seem to remember that from somewhere. -- Website: http://hallambaker.com/ --bcaec54b4ac098dd7004ca689d3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Thu, Sep 20, 2012 at 3:40 AM, Manger,= James H <James.H.Manger@team.telstra.com> wro= te:
    > >> > An array based approach

    > > The main issue, aside from the basic possible extensibility
    > > ramifications is that it just *feels* like an entirely pointless<= br> > > optimization... a change that buys us absolutely nothing in terms= of
    > > real functionality and simply trades one set of potential issues = for
    > > another. The spec version of code smell.

    Given that each operation is likely to be mapped to a function call s= uch as add(ptr, val), an array approach ["add", ptr, val] seems q= uite natural. The object-based approach *feels* like an entirely pointless = optimization... an optimization to support some potential extensibility tha= t we explicitly don't want.

    ["add", ptr, val]=A0
    <= br>
    remove the comas, change the brackets and we get
    ("add" ptr val)

    I seem to r= emember that from somewhere.
    =A0
    --
    Website: htt= p://hallambaker.com/

    --bcaec54b4ac098dd7004ca689d3c-- From mnot@mnot.net Sun Sep 23 19:36:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24E221F84EF for ; Sun, 23 Sep 2012 19:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqK6EbeL7PQ4 for ; Sun, 23 Sep 2012 19:36:32 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 662B321F849C for ; Sun, 23 Sep 2012 19:36:30 -0700 (PDT) Received: from [172.20.0.191] (unknown [173.166.16.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9C8F522E1F4; Sun, 23 Sep 2012 22:36:23 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-92096FD2-9953-4633-A1A4-FB81FD77D545 Content-Transfer-Encoding: 7bit References: <56F81D51-1A33-4298-BA7E-DAD92AE6C9DD@mnot.net> <1347296874.2591.4.camel@pbryan-wsl.internal.salesforce.com> <1347298445.2591.7.camel@pbryan-wsl.internal.salesforce.com> <1347303562.2591.20.camel@pbryan-wsl.internal.salesforce.com> <1347466201.3003.6.camel@pbryan-wsl.internal.salesforce.com> <1347466541.3003.7.camel@pbryan-wsl.internal.salesforce.com> <0434540C-DFCF-48C3-B811-209CD7C71761@mnot.net> <1347810127.2811.1.camel@polyglot> <255B9BB34FB7D647A506DC292726F6 E114FD10DAC5@WSMSG3153V.srv.dir.telstra.com> <1347910396.19756.29.camel@pbryan-wsl.internal.salesforce.com> <66F49A74-6958-4989-82B0-29AA96DEF120@mnot.net> <1347990131.4734.37.camel@polyglot> <18154AA8-C913-4FF5-80E3-C0D001AE0E49@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FD231334@WSMSG3153V.srv.dir.telstra.com> <1348077816.2880.9.camel@polyglot> <1348080756.2880.32.camel@polyglot> <1348098123.5269.8.camel@polyglot> <0542E643-0298-4262-8D60-37C97E765531@mnot.net> <1348448025.26754.2.camel@polyjuice> From: Mark Nottingham Mime-Version: 1.0 (1.0) In-Reply-To: <1348448025.26754.2.camel@polyjuice> Message-Id: Date: Sun, 23 Sep 2012 21:50:37 -0400 To: "Paul C. Bryan" X-Mailer: iPhone Mail (10A403) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] JSON Patch: Changing Operator Syntax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 02:36:32 -0000 --Apple-Mail-92096FD2-9953-4633-A1A4-FB81FD77D545 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Ok, it sounds like we want to go there. I'll work on it.=20 Sent from my iPhone On 23/09/2012, at 8:53 PM, "Paul C. Bryan" wrote: > +1 on reinstating "op". >=20 > Paul >=20 > On Fri, 2012-09-21 at 11:37 -0700, Mark Nottingham wrote: >>=20 >> On 19/09/2012, at 4:42 PM, Paul C. Bryan wrote: >>=20 >> >> When using something like "op":"replace" as an alternative, however, t= his additional validation check becomes entirely unnecessary and the possibi= lity of ambiguity dissolves completely. For me, this is much more advantageo= us than saving a few bytes on the wire. >> >=20 >> > Well, there was significant feedback against separate operation and pat= h members at the time. Personally, I'm ambivalent on this; I like both appro= aches for different reasons, though the current method wins out by a small m= argin. That said, if strong consensus to change to bifurcating to separate o= p/path were to be established, I wouldn't resist. >>=20 >> My .02 - I'd support op/path, as long as we can get there quickly and no= t rathole on it.=20 >>=20 >> Does anyone object strongly to changing the syntax of an operation to som= ething approximately like: >>=20 >> { "op": "add", "path": "/a/b/c", "value": "foo" } >>=20 >> Cheers, >>=20 >> -- >> Mark Nottingham >> http://www.mnot.net/ >>=20 >>=20 >>=20 >>=20 >=20 --Apple-Mail-92096FD2-9953-4633-A1A4-FB81FD77D545 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
    Ok, it sounds like we want to go there. I'll work on it. 

    Sent from my iPhone

    On 23/09/2012, at 8:53 PM, "Paul C. Bryan" <pbryan@anode.ca> wrote:

    +1 on reinstating "op".

    Paul

    On Fri, 2012-09-21 at 11:37 -0700, Mark Nottingham wrote: 
    On 19/09/2012, at 4:42 PM, Paul C. Bryan <pbryan@anode.ca> wrote:

>> When using something like "op":"replace" as an alternative, however, this additional validation check becomes entirely unnecessary and the possibility of ambiguity dissolves completely. For me, this is much more advantageous than saving a few bytes on the wire.
> 
> Well, there was significant feedback against separate operation and path members at the time. Personally, I'm ambivalent on this; I like both approaches for different reasons, though the current method wins out by a small margin. That said, if strong consensus to change to bifurcating to separate op/path were to be established, I wouldn't resist.

My .02 -  I'd support op/path, as long as we can get there quickly and not rathole on it. 

Does anyone object strongly to changing the syntax of an operation to something approximately like:

{ "op": "add", "path": "/a/b/c", "value": "foo" }

Cheers,

--
Mark Nottingham
http://www.mnot.net/

    --Apple-Mail-92096FD2-9953-4633-A1A4-FB81FD77D545-- From dret@berkeley.edu Mon Sep 24 19:25:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A69521F87BF for ; Mon, 24 Sep 2012 19:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3usQaKXdpwe for ; Mon, 24 Sep 2012 19:25:52 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3E70A21F8203 for ; Mon, 24 Sep 2012 19:25:52 -0700 (PDT) Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.67]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TGKqL-0001So-Fr; Mon, 24 Sep 2012 19:25:51 -0700 Message-ID: <5061162A.9070303@berkeley.edu> Date: Mon, 24 Sep 2012 19:25:46 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" References: <20120925015640.15903.72458.idtracker@ietfa.amsl.com> In-Reply-To: <20120925015640.15903.72458.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120925015640.15903.72458.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "hypermedia-web@googlegroups.com" , LDP WG , REST Discuss Subject: [apps-discuss] New Version Notification for draft-wilde-describes-link-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 02:25:53 -0000 A new version of I-D, draft-wilde-describes-link-01.txt has been successfully submitted by Erik Wilde and posted to the IETF repository. Filename: draft-wilde-describes-link Revision: 01 Title: The 'describes' Link Relation Type Creation date: 2012-09-22 WG ID: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-wilde-describes-link-01.txt Status: http://datatracker.ietf.org/doc/draft-wilde-describes-link Htmlized: http://tools.ietf.org/html/draft-wilde-describes-link-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-wilde-describes-link-01 Abstract: This specification defines the 'describes' link relation type that allows resource representations to indicate that they are describing another resource. In contexts where applications want to associate described resources and description resources, and want to build services based on these associations, the 'describes' link relation type provides the opposite direction of the 'describedby' link relation type, which already is a registered link relation type. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From paulej@packetizer.com Mon Sep 24 22:02:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6529421F8913 for ; Mon, 24 Sep 2012 22:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFX7IECGUxJu for ; Mon, 24 Sep 2012 22:02:43 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7093521F88DB for ; Mon, 24 Sep 2012 22:02:43 -0700 (PDT) Received: from [131.181.20.110] ([131.181.20.110]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q8P52cvf029232 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 25 Sep 2012 01:02:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1348549362; bh=eDUQBWi7Tv9eXuVjUk036bNdGavhKxAAxVP860uc3D0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=emjEEDvYyBdQ7Mu8N9VndGLhgSprXBwkFpL56n2A+/HlpmEeDvYFSsUf447/+EbVk YAQP1OT4+8+2Lirh8knL4geAIs8+cAvmwOb1SAOjPMDs6JblP6w0irMENerjTUJpQy ehQPes+I53EpBoEx0E/PrYtp5lKD+X1SSCKzAhww= Message-ID: <50613AF0.2050706@packetizer.com> Date: Tue, 25 Sep 2012 01:02:40 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Evan Prodromou References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> In-Reply-To: <504E9555.4070605@status.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 05:02:44 -0000 On 9/10/2012 9:35 PM, Evan Prodromou wrote: > On 12-09-10 12:11 PM, Evan Prodromou wrote: >> Changing the semantics of the "lrdd" link relation from "XRD by >> default" to "JRD by default" is unnecessarily damaging to existing >> implementations. >> >> It does not serve new implementers well if the specification doesn't >> describe the way current implementations work, or give a reasonable >> upgrade path. >> >> I very much like the way RFC 6415 deals with XRD and JRD and I think >> it is a great model to follow with Webfinger: XRD by default, and >> easy mechanisms (content negotiation or a separate endpoint) to get JRD. > So, reviewing RFC 6415, I see it covers almost everything I think of > as "Webfinger": the lrdd link relation, XRD and JRD versions of > host-meta and LRDD doc. Evan, you're entirely correct that it does. The WebFinger spec was originally intended to provide some examples, add a few new requirements (e.g., CORS) and to bring JSON more into prominence. What happened through dialog on this list was that, rather than requiring server-side support for both XML and JSON, there was a preference to "one format only". And, there was a fair number of people strongly arguing for "JSON only". Personally, I don't see a strong reason to abandon XML. XRD is a trivial format. Further, I personally found it trivial to publish both XRD and JRD from the server. So, my preference was to require both. Based on dialog on the list and privately with a few folks, I think what the spec should say is that all servers MUST implement JRD and SHOULD implement XRD. The clients may use either XRD or JRD, but obviously only JRD can be definitely relied upon over the long-term. This flip-flops what was stated in RFC 6415. Would you be OK with language that mandates JRD and says the server "SHOULD" support XRD? Or do you strongly believe the server should continue to require XML as the only mandatory format? Paul From paulej@packetizer.com Mon Sep 24 22:34:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6B021F892F for ; Mon, 24 Sep 2012 22:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b710i2ckTy8X for ; Mon, 24 Sep 2012 22:34:22 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6E021F892C for ; Mon, 24 Sep 2012 22:34:22 -0700 (PDT) Received: from [131.181.20.110] ([131.181.20.110]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q8P5YGVR030339 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 25 Sep 2012 01:34:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1348551260; bh=DHe3T2sZIfOnHdCTnaio7ZCgmHxiiulL2hnNe1cRnGc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=PsgbR2ZnNyrxwJm0hSQLzfNEiEYPrUE/+U9YiEMi4wfBtMzvXi5wzu6FBo0NqYe5G zRoHB7OBa0GylKPVbvthqAppdPcj3ttAjrovnHD5AkUbCLwRtz1ocsj0YwrfX8SPuq 4O3MsHZrmvimaozMrSyAtvKERIB/Xx2dxpSQTKeQ= Message-ID: <50614259.2040504@packetizer.com> Date: Tue, 25 Sep 2012 01:34:17 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: John Bradley References: <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net> <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> <04f001cd8627$092727e0$1b7577a0$@packetizer.com> <90420743-8FE8-4EDB-98EF-D717D5346397@frobbit.se> <1346306587.53748.YahooMailNeo@web31804.mail.mud.yahoo.com> <251A4741-1E52-41D3-B4C8-43BEDE5C79B7@ve7jtb.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 05:34:23 -0000 On 9/11/2012 11:49 AM, John Bradley wrote: > Nat, > > TuCows supports SRV records at least for openSRS. Some of there resellers may be using other things to manage DNS recodes and just using them for registration, so it would be hard to make a blanket statement. > > I think using a SRV record introduces other security issues that would have to be looked at without DNSsec. > > John B. I think this is true regardless. DNSSEC should be a top priority for anyone, really. Otherwise, there exists the risk of having the domain requests hijacked. And if one can do that, they can probably get certificates for the hijacked domains. Paul From paulej@packetizer.com Mon Sep 24 22:41:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FE821F8943 for ; Mon, 24 Sep 2012 22:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nimd5SLTDSM7 for ; Mon, 24 Sep 2012 22:41:39 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBC021F893F for ; Mon, 24 Sep 2012 22:41:39 -0700 (PDT) Received: from [131.181.20.110] ([131.181.20.110]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q8P5fS3b030613 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 25 Sep 2012 01:41:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1348551692; bh=EhAC5XB3MKZgN1r7y7BuObKK7wVHoHV8muyv2499YnY=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=sWaJFEpgJuZJVEMJyaNV1UNZiGBWhongRZ+h751iVYR9/twNuNY3GJyVw+LyMaxUs njUVGSIn9+3kuud0NJvXUa9vw2/nIcIPqZiprsMfT/s1VJC8SVKwcrbW21DTDwAVwa 6tjAU4OHBW6YBOGPJ2Pl4izDI3C6aBdthTPRIgnc= Message-ID: <50614409.4040608@packetizer.com> Date: Tue, 25 Sep 2012 01:41:29 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B1680429673943667C07CC@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667C07CC@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------070300070304040201080700" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WebFinger should be HTTPS only X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 05:41:41 -0000 This is a multi-part message in MIME format. --------------070300070304040201080700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/11/2012 1:43 PM, Mike Jones wrote: > > Having looked at the WebFinger specification a bit more, I recently > realized that it currently does not require TLS to be used. Section > 5.1 - Performing a WebFinger Query -- currently begins "The first step > a client must perform in executing a WebFinger query is to query for > the host metadata using HTTPS or HTTP". This concerns me, since this > may enable classes of phishing attacks in some situations. > > I would therefore request that the specification be updated to > prohibit non-TLS connections. > > Thank you, > > -- Mike > Mike, The spec currently recommends the use of HTTPS, as did RFC 6415 (referenced right after the text you highlight). I do not believe we can mandate HTTPS. There may be private networks that use WebFinger that do not need HTTPS. There will definitely be those who do not want to pay for the certificate to protect WebFinger. We can strongly recommend use of HTTPS, but I don't think we can mandate it. Paul --------------070300070304040201080700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    On 9/11/2012 1:43 PM, Mike Jones wrote:

    Having looked at the WebFinger specification a bit more, I recently realized that it currently does not require TLS to be used.  Section 5.1 - Performing a WebFinger Query – currently begins “The first step a client must perform in executing a WebFinger query is to query for the host metadata using HTTPS or HTTP”.  This concerns me, since this may enable classes of phishing attacks in some situations.

     

    I would therefore request that the specification be updated to prohibit non-TLS connections.

     

                                                                Thank you,

                                                                -- Mike


    Mike,

    The spec currently recommends the use of HTTPS, as did RFC 6415 (referenced right after the text you highlight).  I do not believe we can mandate HTTPS.  There may be private networks that use WebFinger that do not need HTTPS.  There will definitely be those who do not want to pay for the certificate to protect WebFinger.  We can strongly recommend use of HTTPS, but I don't think we can mandate it.

    Paul

    --------------070300070304040201080700-- From mlepinski.ietf@gmail.com Tue Sep 25 07:36:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7424121F87D2 for ; Tue, 25 Sep 2012 07:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LF54zy3W5akJ for ; Tue, 25 Sep 2012 07:36:33 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB3C21F866B for ; Tue, 25 Sep 2012 07:36:33 -0700 (PDT) Received: by iec9 with SMTP id 9so15546838iec.31 for ; Tue, 25 Sep 2012 07:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dJpZftzLo7WYSHK5OL35fa+27ft7YWkb1lqVbR53uJE=; b=rAYG87+g8+cAbiE+Wf5uzHH8j+Qwycrr3LEGeEE1M5GeVyohnV9Ky7B3lPGmgc0qe9 AmkBintfbLnZWxpqOfGRed43+OJ4dpgHhrvX62C5tlscwc52kKv3Bfy7ITL9t422bE1M K4UJU3uS512MwuD7USH4OsvneVg3q81jVj1wtysW0DpzQzn2yTwyCQ1+886Nc1XZeYmQ BegfYrKYwAv/WDT8Uufe/28ypvOJ9nQPzpTosKU++5ma2UWQBRpNZCEPWF1z7CF1t4Xs wPtjdK/BCm0qI2ghTvuKnvTNO7ZCWzSpj9DbtNn4HZSW3EYD/2ahdnk2t4jUJ3UCMDz4 QkKw== MIME-Version: 1.0 Received: by 10.50.17.230 with SMTP id r6mr8382646igd.16.1348583793026; Tue, 25 Sep 2012 07:36:33 -0700 (PDT) Received: by 10.231.76.82 with HTTP; Tue, 25 Sep 2012 07:36:32 -0700 (PDT) Date: Tue, 25 Sep 2012 10:36:32 -0400 Message-ID: From: Matthew Lepinski To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 25 Sep 2012 08:09:02 -0700 Subject: [apps-discuss] Message NomCom: Re APP AD Position X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 14:36:34 -0000 The IETF Nominations Committee (NomCom) considers one of the two APP Area Director positions each year. This year we are considering the position currently held by Pete Resnick. We are considering re-appointing Pete for another two-year term. However, we are also considering Pete for the position of IETF Chair. The success of the IETF NomCom process requires having a variety qualified candidates for each position, gathering feedback from the community, and then selecting the candidate that best meets the needs of the community. Currently, we only have two candidates who have agreed to be considered for the position of APP AD. The nominations committee would greatly appreciate having three candidates to consider for this position. This is especially true if we are to give Pete serious consideration for the position of IETF chair. Note that the desire of the NomCom to identify qualified candidates is in no way a reflection on Pete, and the job he has done as APP AD. It may be the case that Pete is the perfect person to serve as APP AD for the next two years, and it may be the case that someone other than Pete is the perfect choice for IETF chair. However, it would be unfortunate if any decision made by the NomCom was made due to a lack of diversity in qualified candidates, and opposed to careful consideration of the needs of the community. Therefore, if anyone on this list would be willing to be considered for a term as APP AD, or if you know anyone that the NomCom should talk to, please let us know. You can email the NomCom at nomcom12@ietf.org or myself at nomcom-chair@ietf.org. Finally, I would encourage everyone to provide input to the NomCom on candidates that we are considering. You can provide feedback using the web tool: https://www.ietf.org/group/nomcom/2012/input or you can send email to nomcom12@ietf.org. Additionally, the NomCom welcomes general feedback (via email) about the state of the APP area, or the IETF as a while and issues that we should take into account in making decisions. Thank you for your help, - Matt Lepinski From paulej@packetizer.com Tue Sep 25 13:35:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E2D21F87CC for ; Tue, 25 Sep 2012 13:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.31 X-Spam-Level: ** X-Spam-Status: No, score=2.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, RCVD_ILLEGAL_IP=1.908, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8ZDpnyeuVKm for ; Tue, 25 Sep 2012 13:35:40 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 57E5521F86A0 for ; Tue, 25 Sep 2012 13:35:40 -0700 (PDT) Received: from [100.120.246.151] ([1.141.235.64]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q8PKZVRo006569 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 25 Sep 2012 16:35:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1348605338; bh=FljCEZi6RkNmDk2Wak7fwpWfOxu75kySus30AuBVn2s=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=oN+JKwdXZ3xlDaleem+q0Cm+oDujlWLytqxLe05JrTXf0uL4Z5tDbrUv5Cae4htYc TuG0L3JwbVA8OZChrMPs40YyQIHOztOh++pSVCxS19Ev/Apd2iqrNadfXuB+9Utmfk o6fYMaEzfuWZUAjhJLKNwZfu/52JCCk3mb8cC/8A= User-Agent: K-9 Mail for Android In-Reply-To: References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----URRD1GFNGJPWU4D6E9M1F0EAR2ZGUP" From: "Paul E. Jones" Date: Wed, 26 Sep 2012 06:35:25 +1000 To: Jonathan Ballard Message-ID: <9cd188f4-8009-45e9-ba6a-00defee3f28b@email.android.com> Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 20:35:41 -0000 ------URRD1GFNGJPWU4D6E9M1F0EAR2ZGUP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I didn't follow that. Where did UDP come into this discussion? Everything in WebFinger is HTTPS or HTTP. Paul -------- Original Message -------- From: Jonathan Ballard Sent: Wed Sep 26 03:12:04 AEST 2012 To: "Paul E. Jones" Cc: Evan Prodromou , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] XML in Webfinger XML as mandatory on UDP sounds reasonable when there is an alternative on TCP, so that does not make XML mandatory on UDP at all, especially if there is no alternative. On Monday, September 24, 2012, Paul E. Jones wrote: > On 9/10/2012 9:35 PM, Evan Prodromou wrote: > >> On 12-09-10 12:11 PM, Evan Prodromou wrote: >> >>> Changing the semantics of the "lrdd" link relation from "XRD by default" >>> to "JRD by default" is unnecessarily damaging to existing implementations. >>> >>> It does not serve new implementers well if the specification doesn't >>> describe the way current implementations work, or give a reasonable upgrade >>> path. >>> >>> I very much like the way RFC 6415 deals with XRD and JRD and I think it >>> is a great model to follow with Webfinger: XRD by default, and easy >>> mechanisms (content negotiation or a separate endpoint) to get JRD. >>> >> So, reviewing RFC 6415, I see it covers almost everything I think of as >> "Webfinger": the lrdd link relation, XRD and JRD versions of host-meta and >> LRDD doc. >> > > Evan, you're entirely correct that it does. The WebFinger spec was > originally intended to provide some examples, add a few new requirements > (e.g., CORS) and to bring JSON more into prominence. > > What happened through dialog on this list was that, rather than requiring > server-side support for both XML and JSON, there was a preference to "one > format only". And, there was a fair number of people strongly arguing for > "JSON only". Personally, I don't see a strong reason to abandon XML. XRD > is a trivial format. Further, I personally found it trivial to publish > both XRD and JRD from the server. So, my preference was to require both. > > Based on dialog on the list and privately with a few folks, I think what > the spec should say is that all servers MUST implement JRD and SHOULD > implement XRD. The clients may use either XRD or JRD, but obviously only > JRD can be definitely relied upon over the long-term. This flip-flops what > was stated in RFC 6415. > > Would you be OK with language that mandates JRD and says the server > "SHOULD" support XRD? Or do you strongly believe the server should > continue to require XML as the only mandatory format? > > Paul > > > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > ------URRD1GFNGJPWU4D6E9M1F0EAR2ZGUP Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I didn't follow that. Where did UDP come into this discussion? Everything in WebFinger is HTTPS or HTTP.

    Paul

    From: Jonathan Ballard <dzonatas@gmail.com>
    Sent: Wed Sep 26 03:12:04 AEST 2012
    To: "Paul E. Jones" <paulej@packetizer.com>
    Cc: Evan Prodromou <evan@status.net>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
    Subject: Re: [apps-discuss] XML in Webfinger

    XML as mandatory on UDP sounds reasonable when there is an alternative on TCP, so that does not make XML mandatory on UDP at all, especially if there is no alternative.

    On Monday, September 24, 2012, Paul E. Jones wrote:
    On 9/10/2012 9:35 PM, Evan Prodromou wrote:
    On 12-09-10 12:11 PM, Evan Prodromou wrote:
    Changing the semantics of the "lrdd" link relation from "XRD by default" to "JRD by default" is unnecessarily damaging to existing implementations.

    It does not serve new implementers well if the specification doesn't describe the way current implementations work, or give a reasonable upgrade path.

    I very much like the way RFC 6415 deals with XRD and JRD and I think it is a great model to follow with Webfinger: XRD by default, and easy mechanisms (content negotiation or a separate endpoint) to get JRD.
    So, reviewing RFC 6415, I see it covers almost everything I think of as "Webfinger": the lrdd link relation, XRD and JRD versions of host-meta and LRDD doc.

    Evan, you're entirely correct that it does. The WebFinger spec was originally intended to provide some examples, add a few new requirements (e.g., CORS) and to bring JSON more into prominence.

    What happened through dialog on this list was that, rather than requiring server-side support for both XML and JSON, there was a preference to "one format only".  And, there was a fair number of people strongly arguing for "JSON only".  Personally, I don't see a strong reason to abandon XML.  XRD is a trivial format.  Further, I personally found it trivial to publish both XRD and JRD from the server.  So, my preference was to require both.

    Based on dialog on the list and privately with a few folks, I think what the spec should say is that all servers MUST implement JRD and SHOULD implement XRD.  The clients may use either XRD or JRD, but obviously only JRD can be definitely relied upon over the long-term.  This flip-flops what was stated in RFC 6415.

    Would you be OK with language that mandates JRD and says the server "SHOULD" support XRD?  Or do you strongly believe the server should continue to require XML as the only mandatory format?

    Paul



    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss
    ------URRD1GFNGJPWU4D6E9M1F0EAR2ZGUP-- From wmills@yahoo-inc.com Tue Sep 25 15:05:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FC921F87E7 for ; Tue, 25 Sep 2012 15:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.671 X-Spam-Level: X-Spam-Status: No, score=-16.671 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1r6tGx5UtND for ; Tue, 25 Sep 2012 15:05:19 -0700 (PDT) Received: from nm33-vm7.bullet.mail.bf1.yahoo.com (nm33-vm7.bullet.mail.bf1.yahoo.com [72.30.239.207]) by ietfa.amsl.com (Postfix) with SMTP id 95C3D21F8698 for ; Tue, 25 Sep 2012 15:05:19 -0700 (PDT) Received: from [98.139.214.32] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 25 Sep 2012 22:05:18 -0000 Received: from [98.139.212.201] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 25 Sep 2012 22:05:18 -0000 Received: from [127.0.0.1] by omp1010.mail.bf1.yahoo.com with NNFMP; 25 Sep 2012 22:05:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 692568.93777.bm@omp1010.mail.bf1.yahoo.com Received: (qmail 30691 invoked by uid 60001); 25 Sep 2012 22:05:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348610717; bh=3T1aiOKz9yRsCRK3zLeiNortrmftay4xnfUSSOYYzZY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=llxjnsGlZ6OcLuf8CAdq9RJoa5KHQxSPEj2BMZe0gU0g7VM3N1IeQigDeYiD1K3qGSAnMlRr6Q4Bpxlx3U3FZQC8dX/97HaOqv+C/P5LfihNbLI2e0KcbW6nGh0VVaX6QzVyZ57tpki1jfgLd+dVmnexhLSKR8DNacK7POFoM/M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Jy2jJmynMcO43NciO/bq/7beC8XdpFMS713GFJH+InyYXmLqRiSE50oVXHkljJGANEVU7WdyQW44VJ7RY2zyp0KHdJTy69dtPKGLpoI67mhIMoI7OmUBQTGu97IdpGGgHW3MmJK7+c/3icW/3fymRmqkA78uHv1vQMppHNnRjcQ=; X-YMail-OSG: VcbVg7YVM1mcSLtoSGtvbMHl.p68iIfA1ugMSeR0BizgYxj hK4qp1.NendhSFMigf95bUYEwmXL2mp6hfXrgb6Ra.T9WuNYLr.kxKyWyyBe TcxhZIU2K770q6mcUSnC.M9XayzSjGBcdlxXHxBEhQg7A9Ht8t2nXVaCTbJv EuR0Zhw0FCqULnwKc5cb99yts059MSsaAseXKUe2mucN3W2tetHnHoQt8fVV r5qjbBV0bG93HqcuzA8c89u.DMBgfgAXGYoL4yNYw1V05XUlFXjTWRi3946F KjKyEXE0eQw_i_IEGel547958faNCnyTsvsrgth0OsHgwt8aIeHV02owSWTL lojnGFkjnfiq_HJuz8a9INtNuGypm5VXrS.wWg2.MvUJDZzWQPwjL_SHjNah FHvxwhMx5DUWgPlw044zEARaeYFU.qcQGwf5Vnm3VRoxtcFewhllXwkNUyJT En8isqLfcueRtKTfE7_OAVJPYPecO5vuC3Ofh Received: from [209.131.62.115] by web31802.mail.mud.yahoo.com via HTTP; Tue, 25 Sep 2012 15:05:17 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.122.442 References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <9cd188f4-8009-45e9-ba6a-00defee3f28b@email.android.com> Message-ID: <1348610717.25773.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Tue, 25 Sep 2012 15:05:17 -0700 (PDT) From: William Mills To: "Paul E. Jones" , Jonathan Ballard In-Reply-To: <9cd188f4-8009-45e9-ba6a-00defee3f28b@email.android.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-337472821-1348610717=:25773" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 22:05:21 -0000 ---1036955950-337472821-1348610717=:25773 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Typo of IDP perhaps?=0A=0A=0A=0A=0A=0A>________________________________=0A>= From: Paul E. Jones =0A>To: Jonathan Ballard =0A>Cc: "apps-discuss@ietf.org" =0A>= Sent: Tuesday, September 25, 2012 1:35 PM=0A>Subject: Re: [apps-discuss] XM= L in Webfinger=0A> =0A>=0A>I didn't follow that. Where did UDP come into th= is discussion? Everything in WebFinger is HTTPS or HTTP.=0A>=0A>Paul=0A>=0A= >=0A>=0A>________________________________=0A> From: Jonathan Ballard =0A>Sent: Wed Sep 26 03:12:04 AEST 2012=0A>To: "Paul E. Jones= " =0A>Cc: Evan Prodromou , "apps-di= scuss@ietf.org" =0A>Subject: Re: [apps-discuss] XML = in Webfinger=0A>=0A>XML as mandatory on UDP sounds reasonable when there is= an alternative on TCP, so that does not make XML mandatory on UDP at all, = especially if there is no alternative.=0A>=0A>On Monday, September 24, 2012= , Paul E. Jones wrote:=0A>=0A>On 9/10/2012 9:35 PM, Evan Prodromou wrote:= =0A>>=0A>>On 12-09-10 12:11 PM, Evan Prodromou wrote:=0A>>>=0A>>>Changing t= he semantics of the "lrdd" link relation from "XRD by default" to "JRD by d= efault" is unnecessarily damaging to existing implementations.=0A>>>>=0A>>>= >It does not serve new implementers well if the specification doesn't descr= ibe the way current implementations work, or give a reasonable upgrade path= .=0A>>>>=0A>>>>I very much like the way RFC 6415 deals with XRD and JRD and= I think it is a great model to follow with Webfinger: XRD by default, and = easy mechanisms (content negotiation or a separate endpoint) to get JRD.=0A= >>>>=0ASo, reviewing RFC 6415, I see it covers almost everything I think of= as "Webfinger": the lrdd link relation, XRD and JRD versions of host-meta = and LRDD doc.=0A>>>=0A>>Evan, you're entirely correct that it does. The Web= Finger spec was originally intended to provide some examples, add a few new= requirements (e.g., CORS) and to bring JSON more into prominence.=0A>>=0A>= >What happened through dialog on this list was that, rather than requiring = server-side support for both XML and JSON, there was a preference to "one f= ormat only". =A0And, there was a fair number of people strongly arguing for= "JSON only". =A0Personally, I don't see a strong reason to abandon XML. = =A0XRD is a trivial format. =A0Further, I personally found it trivial to pu= blish both XRD and JRD from the server. =A0So, my preference was to require= both.=0A>>=0A>>Based on dialog on the list and privately with a few folks,= I think what the spec should say is that all servers MUST implement JRD an= d SHOULD implement XRD. =A0The clients may use either XRD or JRD, but obvio= usly only JRD can be definitely relied upon over the long-term. =A0This fli= p-flops what was stated in RFC 6415.=0A>>=0A>>Would you be OK with language= that mandates JRD and says the server "SHOULD" support XRD? =A0Or do you s= trongly believe the server should continue to require XML as the only manda= tory format?=0A>>=0A>>Paul=0A>>=0A>>=0A>>=0A>>_____________________________= __________________=0A>>apps-discuss mailing list=0A>>apps-discuss@ietf.org= =0A>>https://www.ietf.org/mailman/listinfo/apps-discuss=0A>>=0A>___________= ____________________________________=0A>apps-discuss mailing list=0A>apps-d= iscuss@ietf.org=0A>https://www.ietf.org/mailman/listinfo/apps-discuss=0A>= =0A>=0A> ---1036955950-337472821-1348610717=:25773 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    Typo of I= DP perhaps?


    =
    From: Paul E. Jones <paulej@packetizer.com> To: Jonathan Ballard <= ;dzonatas@gmail.com>
    Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
    Sent: Tuesday, September 25, 2012 1:= 35 PM
    Subject: Re: [apps-discus= s] XML in Webfinger

    I didn't follow that. Where did UDP come into this discussion? Everythin= g in WebFinger is HTTPS or HTTP.
    =0A
    =0APaul

    =0A
    =0AFrom: Jonathan Ballard <dzonatas@gmail.com>
    =0A<= b>Sent: Wed Sep 26 03:12:04 AEST 2012
    =0ATo: "Paul E. Jones" = <paulej@packetizer.com>
    =0ACc: Evan Prodromou <evan@stat= us.net>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
    =0A= Subject: Re: [apps-discuss] XML in Webfinger
    =0A
    =0A
    =0AXML = as mandatory on UDP sounds reasonable when there is an alternative on TCP, = so that does not make XML mandatory on UDP at all, especially if there is n= o alternative.

    On Monday, September 24, 2012, Paul E. Jones wrote:<= br>=0A
    On 9/10/2012 9:35 PM, Eva= n Prodromou wrote:
    =0A
    =0AOn = 12-09-10 12:11 PM, Evan Prodromou wrote:
    =0A
    =0AChanging the semantics of the "lrdd" link relation from = "XRD by default" to "JRD by default" is unnecessarily damaging to existing = implementations.
    =0A
    =0AIt does not serve new implementers well if th= e specification doesn't describe the way current implementations work, or g= ive a reasonable upgrade path.
    =0A
    =0AI very much like the way RFC 64= 15 deals with XRD and JRD and I think it is a great model to follow with We= bfinger: XRD by default, and easy mechanisms (content negotiation or a sepa= rate endpoint) to get JRD.
    =0A
    =0ASo, reviewing RFC 6415, I = see it covers almost everything I think of as "Webfinger": the lrdd link re= lation, XRD and JRD versions of host-meta and LRDD doc.
    =0A
    = =0A
    =0AEvan, you're entirely correct that it does. The WebFinger spec wa= s originally intended to provide some examples, add a few new requirements = (e.g., CORS) and to bring JSON more into prominence.
    =0A
    =0AWhat happ= ened through dialog on this list was that, rather than requiring server-sid= e support for both XML and JSON, there was a preference to "one format only= ".  And, there was a fair number of people strongly arguing for "JSON = only".  Personally, I don't see a strong reason to abandon XML.  = XRD is a trivial format.  Further, I personally found it trivial to pu= blish both XRD and JRD from the server.  So, my preference was to requ= ire both.
    =0A=0A
    =0ABased on dialog on the list and privately with a = few folks, I think what the spec should say is that all servers MUST implem= ent JRD and SHOULD implement XRD.  The clients may use either XRD or J= RD, but obviously only JRD can be definitely relied upon over the long-term= .  This flip-flops what was stated in RFC 6415.
    =0A=0A
    =0AWould = you be OK with language that mandates JRD and says the server "SHOULD" supp= ort XRD?  Or do you strongly believe the server should continue to req= uire XML as the only mandatory format?
    =0A
    =0APaul
    =0A
    =0A
    = =0A
    =0A_______________________________________________
    =0Aapps= -discuss mailing list
    =0Aapps-discuss@ietf= .org
    =0Ahttps://www.ietf.org/mailman/l= istinfo/apps-discuss
    =0A
    =0A

    ______= _________________________________________
    apps-discuss mailing list
    <= a ymailto=3D"mailto:apps-discuss@ietf.org" href=3D"mailto:apps-discuss@ietf= .org">apps-discuss@ietf.org
    https://www.ietf.org/mailman/listi= nfo/apps-discuss


    = ---1036955950-337472821-1348610717=:25773-- From barryleiba@gmail.com Tue Sep 25 16:13:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EEB21F86CB for ; Tue, 25 Sep 2012 16:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuUZhDEwbZ+I for ; Tue, 25 Sep 2012 16:13:53 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id D938821F86D1 for ; Tue, 25 Sep 2012 16:13:52 -0700 (PDT) Received: by oagn5 with SMTP id n5so7632443oag.31 for ; Tue, 25 Sep 2012 16:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=/MdvJHNYps3nwW6nP2vZA6vYbetIyjCkdr92WhVj+jg=; b=spuKarCeMJgq2jdJemLv41XykT7HSGw0U5LUOOcuv0snw9lKlpZMMljWYSCT5cOMUO JUtf7JIAxm9blPxZcvm2zpGmmi77A0Q1g3CTQtFBu0aRJwL5t77xguJBCTvy8lARAFXA 8zktXyiqycU80ZKy/IEznTvxBfADaTjGyRSj2oOxbRPPM0JlI5SWUgSPAnaAUnsli9SG R+37tb3Hc6i4gL2E4fbYxUqDWy+TMfsBy7sbpTyxnpZf12QICZelIedThJQGh5j5XaAN PbHzGOjxe4WzysZvWgk0/lfkGm2+7FQs8y1I6FwIqqlwXiJn1MgLQeXAu52O+yXVTu+3 DKLg== MIME-Version: 1.0 Received: by 10.60.6.202 with SMTP id d10mr13480652oea.132.1348614832443; Tue, 25 Sep 2012 16:13:52 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.76.73.228 with HTTP; Tue, 25 Sep 2012 16:13:52 -0700 (PDT) Date: Tue, 25 Sep 2012 19:13:52 -0400 X-Google-Sender-Auth: EirlvY3YJLFMei38YEd6MvhMtrE Message-ID: From: Applications Area Directors To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 25 Sep 2012 16:19:34 -0700 Subject: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 23:13:54 -0000 App Area denizens: Pete and I have been having a debate, in response to a request for clarification from IANA, on the proper registration policy for the Permanent Message Header Field Names registry: http://www.iana.org/assignments/message-headers/perm-headers.html The registry was defined in RFC 3864 (along with the Provisional Message Header Field Names registry), and we weren't as rigorous then as we are now about specifying registration policies. The relevant text from 3864 is in two places: Section 4.2.1: A header registered in the Permanent Message Header Field Registry MUST be published as an RFC or as an "Open Standard" in the sense described by RFC 2026, section 7 [1], and MUST have a name which is unique among all the registered permanent field names that may be used with the same application protocol. Section 4.3: The registration template is submitted for incorporation in one of the IANA message header field repositories by one of the following methods: o An IANA considerations section in a defining RFC, calling for registration of the message header and referencing information as required by the registration template within the same document. Registration of the header is then processed as part of the RFC publication process. o Send a copy of the template to the designated email discussion list [33] [34]. Allow a reasonable period - at least 2 weeks - for discussion and comments, then send the template to IANA at the designated email address [35]. IANA will publish the template information if the requested name and the specification document meet the criteria noted in Section 4.1 and Section 4.2.2, unless the IESG or their designated expert have requested that it not be published (see Section 4.4). IESG's designated expert should confirm to IANA that the registration criteria have been satisfied. This collectively clearly says that there are two processes: one for registrations documented in an RFC, and one for others, which involves expert review. IANA currently has the policy listed as "Expert Review", and, therefore, question whether registration requests in RFCs have been through expert review. Our answer, on reading RFC 3864, is "No, and it's not necessary." So they want to correct their registration policy. The trouble is that Pete reads RFC 3864 and says that the words clearly say that all that's required is an RFC, so the correct policy should be "RFC Required or Expert Review"... while I read RFC 3864 and say that the intent was to have a reasonable level of review for the registrations, that the intended level of review will only happen with IETF Stream RFCs, and so the correct policy should be "IETF Review or Expert Review". We're looking for discussion, and other opinions. The difference between our opinions involves RFCs done in non-IETF streams: currently those in the IAB, IRTF, and Independent Streams. Let's focus on the Independent Stream for the moment, because that's the one with the greatest potential for problems. The IESG gets a very light level of review for Independent Stream documents, just to determine whether the publication request is in conflict with work being done in the IETF -- a check for "end runs", as we call it. We can object to the publication of a document that is in conflict with current IETF work. But we can't object on the grounds that an IANA registration request has not had sufficient review. On the other hand, we can *recommend* to the ISE that the IANA registration go through expert review. The ISE is not obliged to take that recommendation, but he's very likely to. Pete thinks that this provides sufficient opportunity for the IESG to say that the registration needs to be checked. I think that was never the intent of RFC 3864, and that it should only be IETF Stream RFCs that can bypass Expert Review. OK, there are the arguments so far. Opinions, please (and I'd especially like to hear from Graham (the designated expert for the registry) and Ned (the designated expert for Media Types, which has a similar process)). Barry (for Barry and Pete) From john@jlc.net Tue Sep 25 16:38:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A86F21F84EF for ; Tue, 25 Sep 2012 16:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.305 X-Spam-Level: X-Spam-Status: No, score=-106.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36i2mFzHoOuw for ; Tue, 25 Sep 2012 16:38:15 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id D9EE021F84EE for ; Tue, 25 Sep 2012 16:38:14 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A015433C21; Tue, 25 Sep 2012 19:38:14 -0400 (EDT) Date: Tue, 25 Sep 2012 19:38:14 -0400 From: John Leslie To: Applications Area Directors Message-ID: <20120925233814.GE21618@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 23:38:15 -0000 Applications Area Directors wrote: > > The trouble is that Pete reads RFC 3864 and says that the words > clearly say that all that's required is an RFC, so the correct policy > should be "RFC Required or Expert Review"... while I read RFC 3864 and > say that the intent was to have a reasonable level of review for the > registrations, that the intended level of review will only happen with > IETF Stream RFCs, and so the correct policy should be "IETF Review or > Expert Review". Sorry, Barry, I'm with Pete here. It might indeed be better if it had been written your way; but RFCs are "forever", and trying to fix by "interpreting" is a bad choice. > The IESG gets a very light level of review for Independent Stream > documents, just to determine whether the publication request is in > conflict with work being done in the IETF -- a check for "end runs", > as we call it. We can object to the publication of a document that is > in conflict with current IETF work. But we can't object on the > grounds that an IANA registration request has not had sufficient > review. True, but anybody (even IESG members) can write a note suggesting changes to the RFC Editor. IMHO, if the authors are so recalcitrant as to resist suggestions from the RFC Editor, we should find another windmill to tilt at. The overall intent is to have a simple path to expanding header fields. Nobody has to use them. We want the process simple enough that new fields are documented, not drawn out so much that they appear without documentation. > On the other hand, we can *recommend* to the ISE that the IANA > registration go through expert review. The ISE is not obliged to take > that recommendation, but he's very likely to. Pete thinks that this > provides sufficient opportunity for the IESG to say that the > registration needs to be checked. I think that was never the intent > of RFC 3864, and that it should only be IETF Stream RFCs that can > bypass Expert Review. Again, I agree with Pete. -- John Leslie From wmills@yahoo-inc.com Tue Sep 25 18:57:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88FDC21F8605 for ; Tue, 25 Sep 2012 18:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.59 X-Spam-Level: X-Spam-Status: No, score=-17.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgCgwifLKlmT for ; Tue, 25 Sep 2012 18:57:53 -0700 (PDT) Received: from nm4-vm0.bullet.mail.bf1.yahoo.com (nm4-vm0.bullet.mail.bf1.yahoo.com [98.139.213.129]) by ietfa.amsl.com (Postfix) with SMTP id 61E8421F85F3 for ; Tue, 25 Sep 2012 18:57:53 -0700 (PDT) Received: from [98.139.215.141] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 26 Sep 2012 01:57:52 -0000 Received: from [98.139.212.239] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 26 Sep 2012 01:57:52 -0000 Received: from [127.0.0.1] by omp1048.mail.bf1.yahoo.com with NNFMP; 26 Sep 2012 01:57:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 665676.5554.bm@omp1048.mail.bf1.yahoo.com Received: (qmail 31643 invoked by uid 60001); 26 Sep 2012 01:57:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348624672; bh=x2FFm/kfCp6sIjZorzjKe9qIDDUerOxgURnys+vUuSk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=aSr/wXve8BfZ74BBhUh46aAYp/f5iefEnV73AHPVOv3XCgySz6OYyWqowS/cJllgRYheWx9swBte4/5pPpy3gQ4pZgwltAxYdqYK2Mh68eP9zdY8WIT4w29uaZcKoClwZtR/jA8Z+R4i1c1l9fvpvJL7rM8uDsloBpU0CU/136k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=dZbNGMCnyZ9V0GVEcZzTNp2Jd0FT5zMHrsSdEoqsGy8+le4SeHz5oCty4SHHW/bOXZQTO7+jI76seUurejysQc21q5ldA4wnNWywttqNCow0ememFvb0FEnxtktNrjo/wjdG3dxst+wkn8rP6KrHh5sXQj3/2R41uJQznmgUeQk=; X-YMail-OSG: CmeFHzEVM1leMrCwfZtn7KKVMkFVcpNKvzukbCI.XB0P7y7 iqeKMnT0Sxi1VdU573QF.2soSEtYmShpQMKMV1WAynoY0erNPXPK85zlGTig LA2YyypnPF1U1nhIvGispAdew.4qdXPDFI..muCAhaqaS_Tal31Zw_QjJ5KU YDhBR5Ymlh_9lIg9oxyyotXYhX0jBkbi1_lUFUQuCZFu6d6sPeVf.Q3AmbnZ SIsNEMDy_nVyzXRNyZHj.U8UPF7aAQxYT883lv7Hffr_kWhuU4iEiwfBRjjV kDHxIso0lKXDr3BjbfFFeSkCktT90mh5yz.BJYjo7iJIN2sWKB19Y8w3_.M9 3wi49S1Y0LpNn4Lc6fp3tdC7C8qj37UeiohiB.otnocsFtp1byKBrUgE0vO1 nqZCYD1WFl9LdsnSedxBiVQVBHr.omdHCMND13tggIgd9u6ygXslgPIZHoZs IdSbOIu8tdxYB Received: from [99.31.212.42] by web31816.mail.mud.yahoo.com via HTTP; Tue, 25 Sep 2012 18:57:52 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.122.442 References: <20120926013809.18175.60668.idtracker@ietfa.amsl.com> <1348624404.15450.YahooMailNeo@web31813.mail.mud.yahoo.com> Message-ID: <1348624672.28828.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Tue, 25 Sep 2012 18:57:52 -0700 (PDT) From: William Mills To: Apps Discuss In-Reply-To: <1348624404.15450.YahooMailNeo@web31813.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-1427011142-1348624672=:28828" Subject: [apps-discuss] Fw: New Version Notification for draft-wmills-oauth-lrdd-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 01:57:54 -0000 ---1238014912-1427011142-1348624672=:28828 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,=0A=0AI've updated this individual draft with another example.=A0 I'= m not quite sure how to proceed though with an individual submission rather= than a WG one, I don't think there's a lot left to be done.=A0 I'd appreci= ate any comments, and guidance.=0A=0AThanks,=0A=0A-bill=0A=0A=0A=0A=0A>=0A>= =0A>=0A>----- Forwarded Message -----=0A>From: "internet-drafts@ietf.org" <= internet-drafts@ietf.org>=0A>To: wmills_92105@yahoo.com =0A>Sent: Tuesday, = September 25, 2012 6:38 PM=0A>Subject: New Version Notification for draft-w= mills-oauth-lrdd-02.txt=0A> =0A>=0A>A new version of I-D, draft-wmills-oaut= h-lrdd-02.txt=0A>has been successfully submitted by William J. Mills and po= sted to the=0A>IETF repository.=0A>=0A>Filename:=A0=A0=A0 draft-wmills-oau= th-lrdd=0A>Revision:=A0=A0=A0 02=0A>Title:=A0=A0=A0 =A0=A0=A0 Link Type R= egistry for OAuth 2=0A>Creation date:=A0=A0=A0 2012-09-26=0A>WG ID:=A0=A0= =A0 =A0=A0=A0 Individual Submission=0A>Number of pages: 12=0A>URL:=A0 =A0 = =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-wmills-oauth-lrd= d-02.txt=0A>Status:=A0 =A0 =A0 =A0 =A0 http://datatracker.ietf.org/doc/draf= t-wmills-oauth-lrdd=0A>Htmlized:=A0 =A0 =A0 =A0 http://tools.ietf.org/html/= draft-wmills-oauth-lrdd-02=0A>Diff:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.= org/rfcdiff?url2=3Ddraft-wmills-oauth-lrdd-02=0A>=0A>Abstract:=0A>=A0 Defi= nes link type registrations for the OAuth 2=0A authentication=0A>=A0 frame= work.=0A>=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A>=0A>=0A>The IETF Secretariat=0A>=0A>=0A>= =0A>=0A>=0A> ---1238014912-1427011142-1348624672=:28828 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi all,

    I've updated this individual draft with another example.&= nbsp; I'm not quite sure how to proceed though with an individual submissio= n rather than a WG one, I don't think there's a lot left to be done.  = I'd appreciate any comments, and guidance.

    Thanks,<= /div>

    -bill

    <= div style=3D"font-family: Courier New, courier, monaco, monospace, sans-ser= if; font-size: 14pt;">


    ----- Forwarded Message -----
    From: "internet-drafts@ietf.org" <internet-drafts@ietf.org&= gt;
    To: wmills_92105@ya= hoo.com
    Sent: Tuesday,= September 25, 2012 6:38 PM
    Subjec= t: New Version Notification for draft-wmills-oauth-lrdd-02.txt

    =0A
    A new version of I-D, draft-wmills-oauth-lrdd-= 02.txt
    has been successfully submitted by William J. Mills and posted to= the
    IETF repository.

    Filename:    draft-wmills-o= auth-lrdd
    Revision:    02
    Title:    &n= bsp;   Link Type Registry for OAuth 2
    Creation date: &nb= sp;  2012-09-26
    WG ID:        Indiv= idual Submission
    Number of pages: 12
    URL:        =     http://www.ietf.org/internet-drafts/draft-wmills-oauth-lrdd-= 02.txt
    Status:          http://datatracker.ietf= .org/doc/draft-wmills-oauth-lrdd
    Htmlized:        ht= tp://tools.ietf.org/html/draft-wmills-oauth-lrdd-02
    Diff:    &= nbsp;       http://www.ietf.org/rfcdiff?url2=3Ddraft-wmills-= oauth-lrdd-02

    Abstract:
      Defines link type registrations f= or the OAuth 2=0A authentication
      framework.

       =                     &nbs= p;                     &n= bsp;                     =              


    The IETF Secre= tariat





    ---1238014912-1427011142-1348624672=:28828-- From ned.freed@mrochek.com Tue Sep 25 20:11:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2287E1F0C96 for ; Tue, 25 Sep 2012 20:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUSfMDy6iLjY for ; Tue, 25 Sep 2012 20:11:24 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E8CFB21F84C9 for ; Tue, 25 Sep 2012 20:11:23 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKOOEXVGXC001WVW@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 25 Sep 2012 20:06:17 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Tue, 25 Sep 2012 20:06:11 -0700 (PDT) Message-id: <01OKOOEUHQFQ0006TF@mauve.mrochek.com> Date: Tue, 25 Sep 2012 20:01:04 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 25 Sep 2012 19:38:14 -0400" <20120925233814.GE21618@verdi> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120925233814.GE21618@verdi> To: John Leslie Cc: Apps Discuss , Applications Area Directors Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 03:11:25 -0000 > Applications Area Directors wrote: > > > > The trouble is that Pete reads RFC 3864 and says that the words > > clearly say that all that's required is an RFC, so the correct policy > > should be "RFC Required or Expert Review"... while I read RFC 3864 and > > say that the intent was to have a reasonable level of review for the > > registrations, that the intended level of review will only happen with > > IETF Stream RFCs, and so the correct policy should be "IETF Review or > > Expert Review". > Sorry, Barry, I'm with Pete here. And so am I. The mistake we make with depressing regularity is making our registration processes too onerous, with the inevitable result that people just do things without bothering to register. We really, really, really need to get it through our heads that we are not the protocol police and that documentation of something does not imply endorsement. A documented bad idea can be seen for what it is, whereas an undocumented one can be very difficult to grapple with. > It might indeed be better if it had been written your way; but RFCs > are "forever", and trying to fix by "interpreting" is a bad choice. Agreed as well. > > The IESG gets a very light level of review for Independent Stream > > documents, just to determine whether the publication request is in > > conflict with work being done in the IETF -- a check for "end runs", > > as we call it. We can object to the publication of a document that is > > in conflict with current IETF work. But we can't object on the > > grounds that an IANA registration request has not had sufficient > > review. > True, but anybody (even IESG members) can write a note suggesting > changes to the RFC Editor. Indeed. > IMHO, if the authors are so recalcitrant as to resist suggestions > from the RFC Editor, we should find another windmill to tilt at. > The overall intent is to have a simple path to expanding header fields. > Nobody has to use them. We want the process simple enough that new > fields are documented, not drawn out so much that they appear without > documentation. Exactly. > > On the other hand, we can *recommend* to the ISE that the IANA > > registration go through expert review. The ISE is not obliged to take > > that recommendation, but he's very likely to. Pete thinks that this > > provides sufficient opportunity for the IESG to say that the > > registration needs to be checked. I think that was never the intent > > of RFC 3864, and that it should only be IETF Stream RFCs that can > > bypass Expert Review. > Again, I agree with Pete. As do I. I have a number of issues with the way RFC 3864 was done, but this is not one of them. Ned From laurentwalter.goix@telecomitalia.it Wed Sep 26 02:12:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CCA21F8645 for ; Wed, 26 Sep 2012 02:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjIJeJM1y0iK for ; Wed, 26 Sep 2012 02:12:32 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id DCAD321F8613 for ; Wed, 26 Sep 2012 02:12:31 -0700 (PDT) Content-Type: multipart/mixed; boundary="_74c325f9-7c51-47d5-a0be-0554d31961de_" Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 26 Sep 2012 11:12:22 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Wed, 26 Sep 2012 11:12:20 +0200 From: Goix Laurent Walter To: William Mills , Apps Discuss Date: Wed, 26 Sep 2012 11:12:18 +0200 Thread-Topic: [apps-discuss] Fw: New Version Notification for draft-wmills-oauth-lrdd-02.txt Thread-Index: Ac2bil0pf4x2bLB0THuA5ujfq+R8ygAOejig Message-ID: References: <20120926013809.18175.60668.idtracker@ietfa.amsl.com> <1348624404.15450.YahooMailNeo@web31813.mail.mud.yahoo.com> <1348624672.28828.YahooMailNeo@web31816.mail.mud.yahoo.com> In-Reply-To: <1348624672.28828.YahooMailNeo@web31816.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Subject: [apps-discuss] R: Fw: New Version Notification for draft-wmills-oauth-lrdd-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 09:12:35 -0000 --_74c325f9-7c51-47d5-a0be-0554d31961de_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A3068B0CGRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A3068B0CGRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello bill, Thanks for the update. I also believe this should be straightforward... Some comments regarding your latest revision: - The page header still mentions "A SASL/GSS-API Mechanism for OAu= th" and needs cleanup - Section 2: you mention "C:", "S:" and SASL terminology that are = not used in the draft and need cleanup - 4.1.2: /s/available/available (twice) - 4.1.2: you mention "The client MAY use this to determine if the = client supports ..." (for grant types and token types). Isn't it rather the= client to determine whether the *server* support these grant types? What a= bout "The client MAY use this to determine the grant/token types available = at the server"? - 5.1: maybe you could provide https endpoints in your example rat= her than http as this would be more typical/in line with oauth recommendati= ons - 5.2: /s/soupporting/supporting - 6.2: note that the wf i-d is now wg (ietf-appsawg-webfinger-00) In general I am not that clear about your representation of the "grant-type= s" and "token-types" properties/attributes in the examples. Based on rfc641= 5 xrd/jrd mapping there seem to be some inconsistency on the mapping: do yo= u envision these as link attributes or as properties? Cheers walter Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Pe= r conto di William Mills Inviato: mercoled=EC 26 settembre 2012 3.58 A: Apps Discuss Oggetto: [apps-discuss] Fw: New Version Notification for draft-wmills-oauth= -lrdd-02.txt Hi all, I've updated this individual draft with another example. I'm not quite sur= e how to proceed though with an individual submission rather than a WG one,= I don't think there's a lot left to be done. I'd appreciate any comments,= and guidance. Thanks, -bill ----- Forwarded Message ----- From: "internet-drafts@ietf.org" To: wmills_92105@yahoo.com Sent: Tuesday, September 25, 2012 6:38 PM Subject: New Version Notification for draft-wmills-oauth-lrdd-02.txt A new version of I-D, draft-wmills-oauth-lrdd-02.txt has been successfully submitted by William J. Mills and posted to the IETF repository. Filename: draft-wmills-oauth-lrdd Revision: 02 Title: Link Type Registry for OAuth 2 Creation date: 2012-09-26 WG ID: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-wmills-oauth-lrdd= -02.txt Status: http://datatracker.ietf.org/doc/draft-wmills-oauth-lrdd Htmlized: http://tools.ietf.org/html/draft-wmills-oauth-lrdd-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-wmills-oauth-lrdd= -02 Abstract: Defines link type registrations for the OAuth 2 authentication framework. The IETF Secretariat Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE53A3068B0CGRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Hello bill,

     

    Thanks for the update. I also believe this should be straigh= tforward…

     

    Some comments regarding your latest revision:

    -The p= age header still mentions “A SASL/GSS-API Mechanism for OAuth” = and needs cleanup

    -Secti= on 2: you mention “C:”, “S:” and SASL terminology t= hat are not used in the draft and need cleanup

    -4.1.2= : /s/available/available (twice)

    -4.1.2= : you mention “The client MAY use this to determine if the client sup= ports …” (for grant types and token types). Isn’t it rath= er the client to determine whether the *server* support these grant ty= pes? What about “The client MAY use this to determine the grant/token= types available at the server”?

    -5.1: = maybe you could provide https endpoints in your example rather than http as= this would be more typical/in line with oauth recommendations

    -5.2: = /s/soupporting/supporting

    -6.2: = note that the wf i-d is now wg (ietf-appsawg-webfinger-00)

     

    In general I am not that clear about your representation of = the “grant-types” and “token-types” properties/attr= ibutes in the examples. Based on rfc6415 xrd/jrd mapping there seem to be some inconsistency on the mapp= ing: do you envision these as link attributes or as properties?<= /span>

     

    Cheers

    walter

     

     

    Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounce= s@ietf.org] Per conto di William Mills
    Inviato: mercoled=EC 26 settembre 2012 3.58
    A: Apps Discuss
    Oggetto: [apps-discuss] Fw: New Version Notification for draft-wmill= s-oauth-lrdd-02.txt

     

    Hi all,<= /p>

     

    I've updated this individual draft with another example. = I'm not quite sure how to proceed though with an individual submission rat= her than a WG one, I don't think there's a lot left to be done.  I'd appreciate any comments, and guid= ance.

     

    Thanks,

     

    -bill

     

     

     

    ----- For= warded Message -----
    From: "internet-drafts@ietf.org" <internet-drafts@ietf.= org>
    To: wmills_92105@yahoo.com
    Sent: Tuesday, September 25, 2012 6:38 PM
    Subject: New Version Notification for draft-wmills-oauth-lrdd-02.txt=



    A new version of I-D, draft-wmills-oauth-lrdd-02.txt
    has been successfully submitted by William J. Mills and posted to the
    IETF repository.

    Filename:    draft-wmills-oauth-lrdd
    Revision:    02
    Title:        Link Type Registry for OAuth 2<= br> Creation date:    2012-09-26
    WG ID:        Individual Submission
    Number of pages: 12
    URL:            http://www.ietf.org/internet-= drafts/draft-wmills-oauth-lrdd-02.txt
    Status:          http://datatracker.ietf.org/doc/d= raft-wmills-oauth-lrdd
    Htmlized:        http://tools.ietf.org/html/draft-wmill= s-oauth-lrdd-02
    Diff:            http://www.ietf.org/rfcdiff?= url2=3Ddraft-wmills-oauth-lrdd-02

    Abstract:
      Defines link type registrations for the OAuth 2 authentication
      framework.

                         = ;                     &nb= sp;                     &= nbsp;                


    The IETF Secretariat


     

    = Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

    This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

    3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

    --_000_A09A9E0A4B9C654E8672D1DC003633AE53A3068B0CGRFMBX704BA02_-- --_74c325f9-7c51-47d5-a0be-0554d31961de_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_74c325f9-7c51-47d5-a0be-0554d31961de_-- From dzonatas@gmail.com Tue Sep 25 10:12:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0992B1F0CC9 for ; Tue, 25 Sep 2012 10:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JHzazDn5D58 for ; Tue, 25 Sep 2012 10:12:05 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B9B9C1F0CA2 for ; Tue, 25 Sep 2012 10:12:04 -0700 (PDT) Received: by iec9 with SMTP id 9so16063222iec.31 for ; Tue, 25 Sep 2012 10:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g/M6MRpWRq83zVjFmOQskVdoccDBla8l+fbjtKyFcgQ=; b=SKuLUJmWQeIV2bouJpFn/AqDAXTr06hiUHLfZAQiUwaPkl/p4TY2cGu5j2cnUxcf1s n3S0581vSLuX0pltZy0cN0nx77VIKaynE5kL638drglKVidk9ZgIxmJ46AaZ+FJbAgYK HxQN7Vnr7thrX8J/j7EPb5cLFgk8A8Mm+uKyGVJGJorgBcA36WkPYe4FbWXBcVvIh1eX 8ZhN2pivQrsivxG5rXPFtIaFj9okCKcDdR5wFZPpftk6IPAkZmUh3VREzjvtbMT+KjFN mzBPHEUMxxhnS59T/CKUCqY6CNb4jvYuk7TGJqiN2+zX7Oy41WrzBYDOt242whxuH06l xXLA== MIME-Version: 1.0 Received: by 10.50.95.228 with SMTP id dn4mr8774253igb.25.1348593124302; Tue, 25 Sep 2012 10:12:04 -0700 (PDT) Received: by 10.64.102.100 with HTTP; Tue, 25 Sep 2012 10:12:04 -0700 (PDT) In-Reply-To: <50613AF0.2050706@packetizer.com> References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> Date: Tue, 25 Sep 2012 10:12:04 -0700 Message-ID: From: Jonathan Ballard To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f23596b1ede4a04ca89ce5b X-Mailman-Approved-At: Wed, 26 Sep 2012 08:07:59 -0700 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 17:12:06 -0000 --e89a8f23596b1ede4a04ca89ce5b Content-Type: text/plain; charset=ISO-8859-1 XML as mandatory on UDP sounds reasonable when there is an alternative on TCP, so that does not make XML mandatory on UDP at all, especially if there is no alternative. On Monday, September 24, 2012, Paul E. Jones wrote: > On 9/10/2012 9:35 PM, Evan Prodromou wrote: > >> On 12-09-10 12:11 PM, Evan Prodromou wrote: >> >>> Changing the semantics of the "lrdd" link relation from "XRD by default" >>> to "JRD by default" is unnecessarily damaging to existing implementations. >>> >>> It does not serve new implementers well if the specification doesn't >>> describe the way current implementations work, or give a reasonable upgrade >>> path. >>> >>> I very much like the way RFC 6415 deals with XRD and JRD and I think it >>> is a great model to follow with Webfinger: XRD by default, and easy >>> mechanisms (content negotiation or a separate endpoint) to get JRD. >>> >> So, reviewing RFC 6415, I see it covers almost everything I think of as >> "Webfinger": the lrdd link relation, XRD and JRD versions of host-meta and >> LRDD doc. >> > > Evan, you're entirely correct that it does. The WebFinger spec was > originally intended to provide some examples, add a few new requirements > (e.g., CORS) and to bring JSON more into prominence. > > What happened through dialog on this list was that, rather than requiring > server-side support for both XML and JSON, there was a preference to "one > format only". And, there was a fair number of people strongly arguing for > "JSON only". Personally, I don't see a strong reason to abandon XML. XRD > is a trivial format. Further, I personally found it trivial to publish > both XRD and JRD from the server. So, my preference was to require both. > > Based on dialog on the list and privately with a few folks, I think what > the spec should say is that all servers MUST implement JRD and SHOULD > implement XRD. The clients may use either XRD or JRD, but obviously only > JRD can be definitely relied upon over the long-term. This flip-flops what > was stated in RFC 6415. > > Would you be OK with language that mandates JRD and says the server > "SHOULD" support XRD? Or do you strongly believe the server should > continue to require XML as the only mandatory format? > > Paul > > > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --e89a8f23596b1ede4a04ca89ce5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable XML as mandatory on UDP sounds reasonable when there is an alternative on T= CP, so that does not make XML mandatory on UDP at all, especially if there = is no alternative.

    On Monday, September 24, 2012, Paul E. Jones wro= te:
    On 9/10/2012 9:35 PM, Evan Prodromou wrote:<= br>
    On 12-09-10 12:11 PM, Evan Prodromou wrote:
    Changing the semantics of the "lrdd" link relation from "XRD= by default" to "JRD by default" is unnecessarily damaging t= o existing implementations.

    It does not serve new implementers well if the specification doesn't de= scribe the way current implementations work, or give a reasonable upgrade p= ath.

    I very much like the way RFC 6415 deals with XRD and JRD and I think it is = a great model to follow with Webfinger: XRD by default, and easy mechanisms= (content negotiation or a separate endpoint) to get JRD.
    So, reviewing RFC 6415, I see it covers almost everything I think of as &qu= ot;Webfinger": the lrdd link relation, XRD and JRD versions of host-me= ta and LRDD doc.

    Evan, you're entirely correct that it does. The WebFinger spec was orig= inally intended to provide some examples, add a few new requirements (e.g.,= CORS) and to bring JSON more into prominence.

    What happened through dialog on this list was that, rather than requiring s= erver-side support for both XML and JSON, there was a preference to "o= ne format only". =A0And, there was a fair number of people strongly ar= guing for "JSON only". =A0Personally, I don't see a strong re= ason to abandon XML. =A0XRD is a trivial format. =A0Further, I personally f= ound it trivial to publish both XRD and JRD from the server. =A0So, my pref= erence was to require both.

    Based on dialog on the list and privately with a few folks, I think what th= e spec should say is that all servers MUST implement JRD and SHOULD impleme= nt XRD. =A0The clients may use either XRD or JRD, but obviously only JRD ca= n be definitely relied upon over the long-term. =A0This flip-flops what was= stated in RFC 6415.

    Would you be OK with language that mandates JRD and says the server "S= HOULD" support XRD? =A0Or do you strongly believe the server should co= ntinue to require XML as the only mandatory format?

    Paul



    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss
    --e89a8f23596b1ede4a04ca89ce5b-- From dhc@dcrocker.net Wed Sep 26 08:56:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD9A21F84AF for ; Wed, 26 Sep 2012 08:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnayDNGdro+3 for ; Wed, 26 Sep 2012 08:56:47 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E861121F849D for ; Wed, 26 Sep 2012 08:56:46 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8QFujYp018177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Sep 2012 08:56:46 -0700 Message-ID: <506325AE.3000100@dcrocker.net> Date: Wed, 26 Sep 2012 08:56:30 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ned Freed References: <20120925233814.GE21618@verdi> <01OKOOEUHQFQ0006TF@mauve.mrochek.com> In-Reply-To: <01OKOOEUHQFQ0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 26 Sep 2012 08:56:46 -0700 (PDT) Cc: Apps Discuss , Applications Area Directors Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 15:56:47 -0000 On 9/25/2012 8:01 PM, Ned Freed wrote: > We really, really, really need to get it through our heads that we are not the > protocol police and that documentation of something does not imply endorsement. > A documented bad idea can be seen for what it is, whereas an undocumented one > can be very difficult to grapple with. +10 Registration is an administrative step to ensure awareness and uniqueness; it's not for quality control (absent an extremely compelling case being made for 'dangerous' registrations.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From barryleiba.mailing.lists@gmail.com Wed Sep 26 09:04:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9DD21F8581 for ; Wed, 26 Sep 2012 09:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.96 X-Spam-Level: X-Spam-Status: No, score=-102.96 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1osdAtjvivdt for ; Wed, 26 Sep 2012 09:04:28 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CAE5C21F84DC for ; Wed, 26 Sep 2012 09:04:27 -0700 (PDT) Received: by laah2 with SMTP id h2so99524laa.31 for ; Wed, 26 Sep 2012 09:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=VRBxmUiv7u/s3EPbn5VpiwJCwpwtrhdBf9B3cIiFzQs=; b=Wt2uGRutAYVEoSeMYqYypb3SSLH/rj8B2jQ9BTSUpSuLuRPW7Wn8B7c2QwRRZ8mG+K OCwCoiKzJtMQc7QCyZxJp+ik1HlhakgmGR7I5+51ke5UeUe/95l8EpxeitEZH1I4pvKl NLffkOd+fMjBIFztgO8hDUWbswMnHw+ZlhAlDlS+ANZkh7NxZHjzLvvKs1lBl+oppMjK u+ox8qPkulJgsWumMeBkqa4ZXOiyCkIgblBvVIXP8A2hprBdPUhnOggSqgbITuUS4urG IXCLGMP0M135CiIGhQyqbcgXSBvI8UAL9J7MKTBQk2J14YKR0aeYyuDVVcRMogI6EcQE EYYw== MIME-Version: 1.0 Received: by 10.112.31.197 with SMTP id c5mr586388lbi.50.1348675466295; Wed, 26 Sep 2012 09:04:26 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Wed, 26 Sep 2012 09:04:26 -0700 (PDT) In-Reply-To: <506325AE.3000100@dcrocker.net> References: <20120925233814.GE21618@verdi> <01OKOOEUHQFQ0006TF@mauve.mrochek.com> <506325AE.3000100@dcrocker.net> Date: Wed, 26 Sep 2012 12:04:26 -0400 X-Google-Sender-Auth: uWFOA-s8eZ8VJ3UiEBehPnOVKZI Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 16:04:33 -0000 > Sorry, Barry, I'm with Pete here. Well, John, there's no need for the "sorry"; this is all exactly the feedback we're looking for. > We really, really, really need to get it through our heads that we are not > the protocol police and that documentation of something does not imply > endorsement. Yes, and I think everyone here knows that I've been pushing hard in general for more lenient registration policies, not tighter ones. I absolutely agree with what Ned says above. Pete and I are trying to get at what was intended in RFC 3864, not trying to apply our opinions of what it *should* have done. So far, we have three responses that want the slightly more relaxed "RFC Required or Expert Review" policy. Honestly, it's what I want as well. If we think that's what was intended in RFC 3864, I'm happy, and we can give an answer to IANA. Barry From alexey.melnikov@isode.com Wed Sep 26 09:35:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF1E21F856F for ; Wed, 26 Sep 2012 09:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AogQ-6r6suXN for ; Wed, 26 Sep 2012 09:35:31 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF5121F856D for ; Wed, 26 Sep 2012 09:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1348677328; d=isode.com; s=selector; i=@isode.com; bh=6Z3SJ9/IOurnTAnJCp73Yc3BqPPDuEORn31f2447RIY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=B/WcXlMnxjpKjyfvxmUytkMPD7kZ4vy2LKbu0sVsNgBpmiQderHnJl08P9tZxyTyCdXdmb w12u9Lp+DGAmb81Fz2BvihDlBPgnxHLZFrXcmTVLr5Qi8Smz2Bgy8zU+7I7Ov6Am0wFcZL YReLfj2pQ7G2j2ugQDvq6gbCFb5HLDg=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 26 Sep 2012 17:35:28 +0100 Message-ID: <50632EE9.70302@isode.com> Date: Wed, 26 Sep 2012 17:35:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Applications Area Directors References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 16:35:32 -0000 On 26/09/2012 00:13, Applications Area Directors wrote: > App Area denizens: > > Pete and I have been having a debate, in response to a request for > clarification from IANA, on the proper registration policy for the > Permanent Message Header Field Names registry: > http://www.iana.org/assignments/message-headers/perm-headers.html > > The registry was defined in RFC 3864 (along with the Provisional > Message Header Field Names registry), and we weren't as rigorous then > as we are now about specifying registration policies. The relevant > text from 3864 is in two places: > > Section 4.2.1: > A header registered in the Permanent Message Header Field Registry > MUST be published as an RFC or as an "Open Standard" in the sense > described by RFC 2026, section 7 [1], and MUST have a name which is > unique among all the registered permanent field names that may be > used with the same application protocol. > > Section 4.3: > The registration template is submitted for incorporation in one of > the IANA message header field repositories by one of the following > methods: > > o An IANA considerations section in a defining RFC, calling for > registration of the message header and referencing information as > required by the registration template within the same document. > Registration of the header is then processed as part of the RFC > publication process. > > o Send a copy of the template to the designated email discussion > list [33] [34]. Allow a reasonable period - at least 2 weeks - > for discussion and comments, then send the template to IANA at the > designated email address [35]. IANA will publish the template > information if the requested name and the specification document > meet the criteria noted in Section 4.1 and Section 4.2.2, unless > the IESG or their designated expert have requested that it not be > published (see Section 4.4). IESG's designated expert should > confirm to IANA that the registration criteria have been > satisfied. > > This collectively clearly says that there are two processes: one for > registrations documented in an RFC, and one for others, which involves > expert review. IANA currently has the policy listed as "Expert > Review", and, therefore, question whether registration requests in > RFCs have been through expert review. Our answer, on reading RFC > 3864, is "No, and it's not necessary." So they want to correct their > registration policy. > > The trouble is that Pete reads RFC 3864 and says that the words > clearly say that all that's required is an RFC, so the correct policy > should be "RFC Required or Expert Review"... while I read RFC 3864 and > say that the intent was to have a reasonable level of review for the > registrations, that the intended level of review will only happen with > IETF Stream RFCs, and so the correct policy should be "IETF Review or > Expert Review". Yeah, I got confused by that in the past as well. According to Graham (who is the Expert Reviewer and can correct me if I misrepresent him), Expert Review is required in all cases, but for IETF Stream RFCs Graham trusts that there was sufficient review and basically applies lightweight approval. > We're looking for discussion, and other opinions. > > The difference between our opinions involves RFCs done in non-IETF > streams: currently those in the IAB, IRTF, and Independent Streams. > Let's focus on the Independent Stream for the moment, because that's > the one with the greatest potential for problems. > > The IESG gets a very light level of review for Independent Stream > documents, just to determine whether the publication request is in > conflict with work being done in the IETF -- a check for "end runs", > as we call it. We can object to the publication of a document that is > in conflict with current IETF work. But we can't object on the > grounds that an IANA registration request has not had sufficient > review. > > On the other hand, we can *recommend* to the ISE that the IANA > registration go through expert review. The ISE is not obliged to take > that recommendation, but he's very likely to. Pete thinks that this > provides sufficient opportunity for the IESG to say that the > registration needs to be checked. I think that was never the intent > of RFC 3864, and that it should only be IETF Stream RFCs that can > bypass Expert Review. > > OK, there are the arguments so far. Opinions, please (and I'd > especially like to hear from Graham (the designated expert for the > registry) and Ned (the designated expert for Media Types, which has a > similar process)). > > Barry (for Barry and Pete) From wmills@yahoo-inc.com Wed Sep 26 09:42:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CA821F8596 for ; Wed, 26 Sep 2012 09:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.484 X-Spam-Level: X-Spam-Status: No, score=-17.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtYaOuXsWORp for ; Wed, 26 Sep 2012 09:42:58 -0700 (PDT) Received: from nm15-vm0.bullet.mail.sp2.yahoo.com (nm15-vm0.bullet.mail.sp2.yahoo.com [98.139.91.208]) by ietfa.amsl.com (Postfix) with SMTP id A167521F852A for ; Wed, 26 Sep 2012 09:42:58 -0700 (PDT) Received: from [98.139.91.66] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 26 Sep 2012 16:42:54 -0000 Received: from [98.139.91.47] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 26 Sep 2012 16:42:54 -0000 Received: from [127.0.0.1] by omp1047.mail.sp2.yahoo.com with NNFMP; 26 Sep 2012 16:42:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 380993.97602.bm@omp1047.mail.sp2.yahoo.com Received: (qmail 95669 invoked by uid 60001); 26 Sep 2012 16:42:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348677773; bh=GxgXqGHMjg7CFTfxUZJgvRsAwO4Z13goKUUY4MVHy9E=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OYM72022+svdAuRhNx6vB2dkk4vlu3LJy/H1nyb/AAn9FkYaGgEp+cnjPq5HkP9jxHlrb6FqAKsRic+0lPM9xxzG75FlEjZQknK5JK6tw/AWP9/t9NdZ0SlzuZYGaSoYDpOyXFPFttIn5jPb7uEHjIP4nfmwMlqRAeLcYzJoEBw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jPzEALINxgBe5Hjn5m8h0qPwCh7ruyOMauC6klB75N59uX5YqUXmNL6nLLXc5CgseBZjq+XPNNKUCsH9E9/V4GM6ELJI6r2OgccXPMzbB75ljb2eXcvB3+i67PafdvmT9TYGXX6wStc+y0uLXdx0Dflc8KY3OURRmAJuP0D6q+c=; X-YMail-OSG: VXL1ApkVM1mwYP02xHgiQ.AMsgZSpgLpUe8QJAW18.ZeNWb LKL8jkpBWhWzoAKS5742H4_SdA3ih7ERwBo5SFAVwbOMeAOJcIyOiaZTdAQF bObnW70SuQx46lAvhznXSftkEy_km5lrESV1Rts1ss7_OMesAd5hIp3o.Wm8 qyH6IqcnQ0ILKLzVQxke5JvPLF11u7ROQ34ovd0yuaHISfRi2RhK9djUMLHS COpsJhURKWdThFWtwK8F0Xmvy944xW9RMjlx1r92XXpeWQ.qonk0fUB51lmq inhrx4_s55rIWYTTmtZ50L7SyHzR8zd6HKUVQmPCieDkhMJYWlUpP6dD4mp1 huHAv7QnhfojG0zUe2ovn1u9Y4SLxeRouB72bL1dh5ZifwFR5sLTbRyeUKBt IXsRVaqBhs.E3lVrH.YbE0PNOtj8VNg4TP9egJzxCRnJ_pdIaXBYvzCjeTZU Q5krYFqPNhu4PsHEc8punMtADta8Mz1WY180- Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Wed, 26 Sep 2012 09:42:53 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.122.442 References: <20120926013809.18175.60668.idtracker@ietfa.amsl.com> <1348624404.15450.YahooMailNeo@web31813.mail.mud.yahoo.com> <1348624672.28828.YahooMailNeo@web31816.mail.mud.yahoo.com> Message-ID: <1348677773.77425.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Wed, 26 Sep 2012 09:42:53 -0700 (PDT) From: William Mills To: Goix Laurent Walter , Apps Discuss In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] R: Fw: New Version Notification for draft-wmills-oauth-lrdd-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 16:42:59 -0000 =0A=0AThank you for the review!=C2=A0 Comments inline.=0A=0A>______________= __________________=0A> From: Goix Laurent Walter =0A>To: William Mills ; Apps Discuss =0A>Sent: Wednesday, September 26, 2012 2:12 AM=0A>Subje= ct: R: [apps-discuss] Fw: New Version Notification for draft-wmills-oauth-l= rdd-02.txt=0A> =0A>=0A> =0A>Hello bill,=0A>=C2=A0=0A>Thanks for the update.= I also believe this should be straightforward=E2=80=A6=0A>=C2=A0=0A>Some c= omments regarding your latest revision:=0A>-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 The page header still mentions =E2=80=9CA SASL/GSS= -API Mechanism for OAuth=E2=80=9D and needs cleanup=0A>-=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 2: you mention =E2=80=9CC:=E2= =80=9D, =E2=80=9CS:=E2=80=9D and SASL terminology that are not used in the = draft and need cleanup=0A=0A=0AFixed and fixed.=0A=0A=0A>-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4.1.2: /s/available/available (twic= e)=0A=0AOnly found one?=0A=0A>-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 4.1.2: you mention =E2=80=9CThe client MAY use this to determi= ne if the client supports =E2=80=A6=E2=80=9D (for grant types and token typ= es). Isn=E2=80=99t it rather the client to determine whether the *server* s= upport these grant types? What about =E2=80=9CThe client MAY use this to de= termine the grant/token types available at the server=E2=80=9D?=0A=0A=0ACha= nged the language, but not quite what you suggest.=0A=0A=0A>-=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 5.1: maybe you could provide htt= ps endpoints in your example rather than http as this would be more typical= /in line with oauth recommendations=0A=0ADOH!!!=0A=0A>-=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 5.2: /s/soupporting/supporting=0A>-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6.2: note that the wf i= -d is now wg (ietf-appsawg-webfinger-00)=0A=0A=0AFixed x2=0A=0A=0A>=C2=A0= =0A>In general I am not that clear about your representation of the =E2=80= =9Cgrant-types=E2=80=9D and =E2=80=9Ctoken-types=E2=80=9D properties/attrib= utes in the examples. Based on rfc6415 xrd/jrd mapping there seem to be som= e inconsistency on the mapping: do you envision these as link attributes or= as properties?=0A>=C2=A0=0A=0AThese are link extensions as defined in rfc = 5988.=C2=A0 I see that I've represented them wrong in XRD, fixing that.=0A= =0A=0A>Cheers=0A>walter=0A>=C2=A0=0A>=C2=A0=0A=0A=0AAgain, thanks!=0A From barryleiba@gmail.com Wed Sep 26 09:43:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B96821F8528 for ; Wed, 26 Sep 2012 09:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X08k4LPsVoLj for ; Wed, 26 Sep 2012 09:43:54 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA6821F8472 for ; Wed, 26 Sep 2012 09:43:54 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so961185vcb.31 for ; Wed, 26 Sep 2012 09:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=81WctUKGJcNo8zNu5U/qYzGfiHHtxQ8ve9S63PkAtYA=; b=da7j2PctjD+pnWUjyWsPjDlV4ErmKh36xGhbnIFbteJfsA6MWHRfhq2amU9e2paz+j EZn5kuzzy6cexEuOQot6wsSmzOeu7iwipfI7+y/JaZ2TXSBxSsZ9AOijm3Ioz+fL74wO gcw0Q3dzlLbfbGv7oxtt65p2om/xwY1TYluLaZraDu31p94ST5uVZchNNE95iaJgM+Wp Brh3W6C4530fP/Yi66pRsfrZFFgrlBH8PN+rkYWoGBqMlLYmUnocy0REIqbiO0u8sUk9 tw0S3IY8LtwsvhHVB5C3xFITeknpkEQiTRGHakYbqEYufC2DruhFe9TT5xbeiq3klGvn f/nQ== MIME-Version: 1.0 Received: by 10.58.86.36 with SMTP id m4mr652611vez.14.1348677834035; Wed, 26 Sep 2012 09:43:54 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.58.41 with HTTP; Wed, 26 Sep 2012 09:43:53 -0700 (PDT) In-Reply-To: <50632EE9.70302@isode.com> References: <50632EE9.70302@isode.com> Date: Wed, 26 Sep 2012 12:43:53 -0400 X-Google-Sender-Auth: RepMkfZYsaSQR08rF16kTjhdg6w Message-ID: From: Barry Leiba To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 16:43:55 -0000 Alexey says... > Yeah, I got confused by that in the past as well. > > According to Graham (who is the Expert Reviewer and can correct me if I > misrepresent him), Expert Review is required in all cases, but for IETF > Stream RFCs Graham trusts that there was sufficient review and basically > applies lightweight approval. Now, this is how IANA has been handling this until now (because they have consider the policy to be simply "Expert Review"), but it's the one option that's clearly NOT supported by RFC 3864 Section 4.3 -- which very clearly bypasses expert review for requests that are in RFCs. Are you saying that you read 3864 differently? Barry From evan@status.net Wed Sep 26 10:12:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC0A21F85A0 for ; Wed, 26 Sep 2012 10:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjoDV7WHDRw7 for ; Wed, 26 Sep 2012 10:12:14 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 11C9721F8433 for ; Wed, 26 Sep 2012 10:12:13 -0700 (PDT) Received: from [192.168.0.101] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 909208D5C42 for ; Wed, 26 Sep 2012 17:22:33 +0000 (UTC) Message-ID: <50633767.2010003@status.net> Date: Wed, 26 Sep 2012 13:12:07 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> In-Reply-To: <50613AF0.2050706@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 17:12:14 -0000 Paul, I'm happy with making XRD "SHOULD" and JRD "MUST". I suggest that the default content type, if unspecified, stay XRD. So, if a client sees: ...they can be somewhat confident that the results will be XRD, regardless of the specification the remote host supports. -Evan -- Evan Prodromou, CEO and Founder, StatusNet Inc. 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 E: evan@status.net P: +1-514-554-3826 From alexey.melnikov@isode.com Wed Sep 26 10:23:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C36421F84C5 for ; Wed, 26 Sep 2012 10:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6bv+syrrw7i for ; Wed, 26 Sep 2012 10:23:55 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id F0CE921F84BF for ; Wed, 26 Sep 2012 10:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1348680229; d=isode.com; s=selector; i=@isode.com; bh=zErDA726qJKqij5NZBJtjI99+3MmmtykrLe9SSK1Tq8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Yuf+MSUgE3L2cnLHyqHzbnA5A3VpYsxJkxYYw7EZiXvdwF30Ln5kIMdkmxTgSZJz9hb+L+ hxSL5oL75tjriezKnmZ2gRzG5AhYNXeMIy7ekMX0CJ945Vnyw1t40fireLqxjrqj30H4SK SUt1lC0FFkZEwhDE+WmyKuD2WxQ2JM0=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 26 Sep 2012 18:23:48 +0100 Message-ID: <50633A3D.4050700@isode.com> Date: Wed, 26 Sep 2012 18:24:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Barry Leiba References: <50632EE9.70302@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 17:23:56 -0000 On 26/09/2012 17:43, Barry Leiba wrote: > Alexey says... >> Yeah, I got confused by that in the past as well. >> >> According to Graham (who is the Expert Reviewer and can correct me if I >> misrepresent him), Expert Review is required in all cases, but for IETF >> Stream RFCs Graham trusts that there was sufficient review and basically >> applies lightweight approval. > Now, this is how IANA has been handling this until now (because they > have consider the policy to be simply "Expert Review"), but it's the > one option that's clearly NOT supported by RFC 3864 Section 4.3 -- > which very clearly bypasses expert review for requests that are in > RFCs. > > Are you saying that you read 3864 differently? Quoting the RFC again: Section 4.2.1: A header registered in the Permanent Message Header Field Registry MUST be published as an RFC or as an "Open Standard" in the sense described by RFC 2026, section 7 [1], and MUST have a name which is unique among all the registered permanent field names that may be used with the same application protocol. Section 4.3: The registration template is submitted for incorporation in one of the IANA message header field repositories by one of the following methods: o An IANA considerations section in a defining RFC, calling for registration of the message header and referencing information as required by the registration template within the same document. Registration of the header is then processed as part of the RFC publication process. The two sections can be interpreted as complementary (i.e. both apply). And the last sentence can be interpreted as "Expert Review would magically happen during RFC publication". Granted, this might be a very liberal interpretation of the above. But anyway, ask Graham, as he actually co-edited the RFC. o Send a copy of the template to the designated email discussion list [33] [34]. Allow a reasonable period - at least 2 weeks - for discussion and comments, then send the template to IANA at the designated email address [35]. IANA will publish the template information if the requested name and the specification document meet the criteria noted in Section 4.1 and Section 4.2.2, unless the IESG or their designated expert have requested that it not be published (see Section 4.4). IESG's designated expert should confirm to IANA that the registration criteria have been satisfied. From alexey.melnikov@isode.com Wed Sep 26 10:24:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071F721F84D3 for ; Wed, 26 Sep 2012 10:24:48 -0700 (PDT) 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.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5A1IqJ8VT-V for ; Wed, 26 Sep 2012 10:24:47 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id A3AF621F8569 for ; Wed, 26 Sep 2012 10:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1348680280; d=isode.com; s=selector; i=@isode.com; bh=k8Yc8zr7mIOryRf+6dSZp24Ev6d+4llgg2VaXhtIxPs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=TEqfJs/AhBG8Eb5k91KQKf6fJcNOVuauQqHAAGp3svNDj9MnnUu6Wb7gr6NJqMIVjeMUgL P/XfLplxYKei52+pufkvIr97tGpS48FkW5GHFbuwXZoXFpOl/4JpixmuION9ZISxUhv1M6 JJ50CB7bXM8T0U220EG8jl4yNROoASs=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 26 Sep 2012 18:24:40 +0100 Message-ID: <50633A72.1090203@isode.com> Date: Wed, 26 Sep 2012 18:25:06 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Barry Leiba References: <20120925233814.GE21618@verdi> <01OKOOEUHQFQ0006TF@mauve.mrochek.com> <506325AE.3000100@dcrocker.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 17:24:48 -0000 On 26/09/2012 17:04, Barry Leiba wrote: >> Sorry, Barry, I'm with Pete here. > Well, John, there's no need for the "sorry"; this is all exactly the > feedback we're looking for. > >> We really, really, really need to get it through our heads that we are not >> the protocol police and that documentation of something does not imply >> endorsement. > Yes, and I think everyone here knows that I've been pushing hard in > general for more lenient registration policies, not tighter ones. I > absolutely agree with what Ned says above. Agreed. But I think the question you've asked was not "what do you think the policy should be", but "what do you think the document currently requires". From Michael.Jones@microsoft.com Wed Sep 26 11:09:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0D321F84AF for ; Wed, 26 Sep 2012 11:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.766 X-Spam-Level: X-Spam-Status: No, score=-3.766 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LA4oTgXz0d8O for ; Wed, 26 Sep 2012 11:09:25 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7655821F844C for ; Wed, 26 Sep 2012 11:09:25 -0700 (PDT) Received: from mail184-ch1-R.bigfish.com (10.43.68.247) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Sep 2012 18:09:24 +0000 Received: from mail184-ch1 (localhost [127.0.0.1]) by mail184-ch1-R.bigfish.com (Postfix) with ESMTP id E24E73600F2; Wed, 26 Sep 2012 18:09:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VS-25(zz9371I542Md6f1izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1155h) Received-SPF: pass (mail184-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail184-ch1 (localhost.localdomain [127.0.0.1]) by mail184-ch1 (MessageSwitch) id 1348682963557579_15709; Wed, 26 Sep 2012 18:09:23 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail184-ch1.bigfish.com (Postfix) with ESMTP id 869B980044; Wed, 26 Sep 2012 18:09:23 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Sep 2012 18:09:22 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.31]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Wed, 26 Sep 2012 18:09:21 +0000 From: Mike Jones To: Evan Prodromou , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] XML in Webfinger Thread-Index: AQHNjPswpgx4hV1CUEOd0DUjH3qdLZeDq1SAgAAYdACAAJ2mgIAWOpUAgAJeI4CAAA9ekA== Date: Wed, 26 Sep 2012 18:09:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> In-Reply-To: <50633767.2010003@status.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 18:09:26 -0000 The problem with this is that it doesn't accomplish the core goal of the ch= ange - which is simplifying WebFinger by requiring only one data format. I= t's fine to describe XML support in an appendix describing historical usage= and it's fine to say that implementations MAY implement it, but saying tha= t implementations SHOULD implement it leaves us with an unnecessarily compl= icated two-format spec, in practice. -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Evan Prodromou Sent: Wednesday, September 26, 2012 10:12 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] XML in Webfinger Paul, I'm happy with making XRD "SHOULD" and JRD "MUST". I suggest that the default content type, if unspecified, stay XRD. So, if a= client sees: ...they can be somewhat confident that the results will be XRD, regardless = of the specification the remote host supports. -Evan -- Evan Prodromou, CEO and Founder, StatusNet Inc. 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 E: evan@status.net P: +1-514-554-3826 _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From evan@status.net Wed Sep 26 11:58:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C959121F859E for ; Wed, 26 Sep 2012 11:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jk5FeAHl3NHU for ; Wed, 26 Sep 2012 11:58:43 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 6738C21F8581 for ; Wed, 26 Sep 2012 11:58:43 -0700 (PDT) Received: from [192.168.0.101] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id A14778D5E9A for ; Wed, 26 Sep 2012 19:09:07 +0000 (UTC) Message-ID: <50635061.2050703@status.net> Date: Wed, 26 Sep 2012 14:58:41 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Making Webfinger replace RFC 6415 (was Re: XML in Webfinger) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 18:58:43 -0000 One thing I'm grappling with with the Webfinger draft is that it depends on RFC 6415, then requires some incompatible changes to that spec, or drops requirements from it. This means that implementers that support the (still active!) RFC 6415 but don't yet know about or support the Webfinger draft will get unexpected results. Is there a reason that we don't simply replace RFC 6415 with a new RFC? That would make it clear that there's a preferred new way to do things. Otherwise, we should make it a priority that a compliant Webfinger implementation is also compliant with the closely-related RFC 6415. -Evan -- Evan Prodromou, CEO and Founder, StatusNet Inc. 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 E: evan@status.net P: +1-514-554-3826 From ned.freed@mrochek.com Wed Sep 26 13:30:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D886921F8522 for ; Wed, 26 Sep 2012 13:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYyV29Udsc8P for ; Wed, 26 Sep 2012 13:30:31 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 64C0521F851C for ; Wed, 26 Sep 2012 13:30:31 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKPOPE403400ASLG@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 26 Sep 2012 13:25:29 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Wed, 26 Sep 2012 13:25:27 -0700 (PDT) Message-id: <01OKPOPCRS7Q0006TF@mauve.mrochek.com> Date: Wed, 26 Sep 2012 13:18:27 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 26 Sep 2012 18:25:06 +0100" <50633A72.1090203@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20120925233814.GE21618@verdi> <01OKOOEUHQFQ0006TF@mauve.mrochek.com> <506325AE.3000100@dcrocker.net> <50633A72.1090203@isode.com> To: Alexey Melnikov Cc: Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 20:30:32 -0000 > On 26/09/2012 17:04, Barry Leiba wrote: > >> Sorry, Barry, I'm with Pete here. > > Well, John, there's no need for the "sorry"; this is all exactly the > > feedback we're looking for. > > > >> We really, really, really need to get it through our heads that we are not > >> the protocol police and that documentation of something does not imply > >> endorsement. > > Yes, and I think everyone here knows that I've been pushing hard in > > general for more lenient registration policies, not tighter ones. I > > absolutely agree with what Ned says above. > Agreed. > But I think the question you've asked was not "what do you think the > policy should be", but "what do you think the document currently requires". I believe I stated that I think Pete's reading is correct. IMO Barry's is a stretch. And while it's entirely appropriate to ask "what does the RFC say", once this reaches the point of trying to divine intent, in cases like this that's going too far. The RFC says what it says. What the authors intended to say might be relevant during a revision process, or perhaps in deciding how to handle a technical case that wasn't anticipated, but it's not really appropriate when the apparent goal is to implement administrative policy. Ned From mnot@mnot.net Wed Sep 26 13:37:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3B421F8581 for ; Wed, 26 Sep 2012 13:37:05 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVQXS9aBJ3Hx for ; Wed, 26 Sep 2012 13:37:05 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id E0BED21F857E for ; Wed, 26 Sep 2012 13:37:04 -0700 (PDT) Received: from [172.30.20.93] (unknown [72.246.0.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 457E522E1F4; Wed, 26 Sep 2012 16:36:58 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Mark Nottingham In-Reply-To: <01OKOOEUHQFQ0006TF@mauve.mrochek.com> Date: Wed, 26 Sep 2012 16:36:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <55BCBAE2-0E66-406B-84A5-AB566C35D9B1@mnot.net> References: <20120925233814.GE21618@verdi> <01OKOOEUHQFQ0006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1498) Cc: Apps Discuss , Applications Area Directors Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 20:37:05 -0000 On 25/09/2012, at 11:01 PM, Ned Freed wrote: >=20 > As do I. I have a number of issues with the way RFC 3864 was done, but = this is > not one of them. =85 and FWIW I've been talking to Graham about revising it. In our = copious spare time, of course. Cheers, -- Mark Nottingham http://www.mnot.net/ From john-ietf@jck.com Wed Sep 26 18:49:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4AA21F863F for ; Wed, 26 Sep 2012 18:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zserqRCCdBYJ for ; Wed, 26 Sep 2012 18:49:28 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA2A21F8629 for ; Wed, 26 Sep 2012 18:49:28 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TH3ED-000BX5-OJ; Wed, 26 Sep 2012 21:49:25 -0400 Date: Wed, 26 Sep 2012 21:49:20 -0400 From: John C Klensin To: Ned Freed , John Leslie Message-ID: <2747A13381D34945560A89E0@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Apps Discuss , Applications Area Directors Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 01:49:33 -0000 FWIW, +1 to Ned (and Pete and John). Unless there is a scarcity issue, the _only_ criterion for registration should be a review for competence of the description. It should be a process that can get feedback to authors along the lines of "this isn't clear, would you please fix it?" and, when appropriate, notes in the registry that say "there are multiple definitions for this keyword even though we only have documentation for some of them". But "we like it" or "there is IETF consensus of some flavor" should not even be on the list. FWIW, this was approximately the review model for most registries before IANA moved to ICANN and the IESG decided that it needed to be in charge for review processes. We have a creeping tendency toward every-increasing control going on here and, especially for registries like this one, we should stop it. I like the idea of recommending to the ISE that documents be handed off for expert review, but note that is procedurally no different from recommending reviewers to the ISE for any other document topic, recommendations that are always in order and usually welcome. More generally, I think that is the right solution to the current text (and, according to other notes, the one that is in use): no modification to procedural text required, IANA makes sure that the Expert has at least looked at the thing, Expert either signs off on RFCs because they can be presumed to have gotten adequate review or whines during Last Call (for the IETF Stream), announcement of intention to publish (for the IAB and IRTF Streams), and during his or her own review (for the Independent Stream). I'm glad to hear that Graham has the issue under control because, frankly, any Expert who can't figure out the relationship between "RFC", especially IETF Stream RFC, and "adequately reviewed" needs to be fired for general dumbness. best, john --On Tuesday, September 25, 2012 20:01 -0700 Ned Freed wrote: >> Applications Area Directors wrote: >> > >> > The trouble is that Pete reads RFC 3864 and says that the >> > words clearly say that all that's required is an RFC, so >> > the correct policy should be "RFC Required or Expert >> > Review"... while I read RFC 3864 and say that the intent >> > was to have a reasonable level of review for the >> > registrations, that the intended level of review will only >> > happen with IETF Stream RFCs, and so the correct policy >> > should be "IETF Review or Expert Review". > >> Sorry, Barry, I'm with Pete here. > > And so am I. The mistake we make with depressing regularity is > making our registration processes too onerous, with the > inevitable result that people just do things without bothering > to register. > > We really, really, really need to get it through our heads > that we are not the protocol police and that documentation of > something does not imply endorsement. A documented bad idea > can be seen for what it is, whereas an undocumented one can be > very difficult to grapple with. >... From barryleiba@gmail.com Wed Sep 26 19:53:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEFA21F847A for ; Wed, 26 Sep 2012 19:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.883 X-Spam-Level: X-Spam-Status: No, score=-102.883 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCaYjd-5MBZ4 for ; Wed, 26 Sep 2012 19:53:16 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6C621F845D for ; Wed, 26 Sep 2012 19:53:16 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so1575049vcb.31 for ; Wed, 26 Sep 2012 19:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=1mjNc5I0WNhwwUPRrXB4GTb0LJ6Gy8WjHQ14wbP4nj4=; b=bYvrgYRtPb0fUjtRgpA+rAkppO6rHug9aHDPCJwLXPML2NSiD0ufurSS+Vf3amAWYa x1GsQ5Pl7acRo0whegE96P35mGBZbGG2FP7pqxbAcsY4Egs36HR0zUHXwwksRi7XFIaY WCVWo3Fi0AveyAwMg61EHENIttMGLRVlEcVLcSm1itBNay77Vd8OUddj3anpO1obNBwR ghcc5cZtZwWzT/9F6ue3wO/6Ysrp0tUMHbNDt4JWLoqEFU2NXVCGwTzYv95hS57LIdJY VgqmbHg/PTDVtiokgFYlL6nBS8nTbJFzDbKfjqhlmdV7ptzHyjORZVdHDKiUGMKEjfbj hn3w== MIME-Version: 1.0 Received: by 10.58.179.39 with SMTP id dd7mr1538192vec.2.1348714396040; Wed, 26 Sep 2012 19:53:16 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.58.41 with HTTP; Wed, 26 Sep 2012 19:53:15 -0700 (PDT) In-Reply-To: <2747A13381D34945560A89E0@JcK-HP8200.jck.com> References: <2747A13381D34945560A89E0@JcK-HP8200.jck.com> Date: Wed, 26 Sep 2012 22:53:15 -0400 X-Google-Sender-Auth: y-qbzALSLdFIKNOs_RfqJ4ERHAg Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 02:53:17 -0000 > FWIW, this was approximately the review model for most > registries before IANA moved to ICANN and the IESG decided that > it needed to be in charge for review processes. We have a > creeping tendency toward every-increasing control going on here > and, especially for registries like this one, we should stop it. OK, look, John K and everyone: rants about how registration policies should be are not useful here. So far, everyone who's commented, *including me*, agree that we want to make registrations easier in general. And the IESG doesn't really *want* to be in the middle of the review process for registrations, which is why some of us are pushing document authors to use more lenient registration policies. This question isn't about how they SHOULD be, but what RFC 3864 says or meant to say. And let me remind everyone again that we *already* have nothing more than Graham's lightweight Expert Review on this registry in all cases. What we're talking about here is making it *easier* for RFCs, by bypassing Expert Review for RFCs, as 3864 seems to clearly specify. The *only* question is whether *all* RFCs should bypass it, or only IETF Stream RFCs. It doesn't help to overreact and tell us that what's wrong with the world is that we're all trying to make registrations harder. We're not. OK, so there's MY rant. Ha. Anyway, it's clear that *everyone* who has commented, including me, thinks that we *want to* use "RFC Required or Expert Review" -- that is, that ALL RFCs should bypass Expert Review, assuming to be adequately reviewed by each stream's process. But so far only Pete and Ned have said that that's not only what they *want*, but also what they think RFC 3864 *says* (or intended to say; Ned says it doesn't matter what was intended, only what's written). Anyway, tiring of the rants, my inclination is to wrap up this discussion and say that RFC 3864 does not specify any level of review for RFCs other than that they be RFCs, so the BCP 26 interpretation should be "RFC Required or Expert Review". If Pete agrees that we've had enough discussion and we're ready to tell IANA, we will tell IANA and ask them to change the registry policy. Barry [When did it happen that one could no longer post a question and have a gentle discussion, without rants, accusations, and generally excessive grumpiness? Oh, my, well... that's another rant, for another time.] From ned.freed@mrochek.com Wed Sep 26 19:57:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF10921F847C for ; Wed, 26 Sep 2012 19:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmTGY+2c1kFv for ; Wed, 26 Sep 2012 19:57:00 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEDA21F845D for ; Wed, 26 Sep 2012 19:57:00 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKQ27ISJ3K00B9OD@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 26 Sep 2012 19:51:56 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Wed, 26 Sep 2012 19:51:53 -0700 (PDT) Message-id: <01OKQ27GEZGC0006TF@mauve.mrochek.com> Date: Wed, 26 Sep 2012 19:43:11 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 26 Sep 2012 21:49:20 -0400" <2747A13381D34945560A89E0@JcK-HP8200.jck.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <2747A13381D34945560A89E0@JcK-HP8200.jck.com> To: John C Klensin Cc: Ned Freed , Apps Discuss , Applications Area Directors Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 02:57:01 -0000 > FWIW, +1 to Ned (and Pete and John). Unless there is a scarcity > issue, the _only_ criterion for registration should be a review > for competence of the description. I want to emphasize this, because it is incredibly important. The *description* needs to be competent. The underlying technology does not. In fact the cases where the underlying technology is obscure or outright crap are the ones that are most important to document, because otherwise they can be incredibly difficult to figure out. Decent technology tends to be self-explanatory, even when it's misapplied or misused. The syntax and semantics of a lot of nonstandard headers is obvious from inspection even when they don't actually accomplish their intended goal. But some others ... the other day I ran into one with an opaque name that was a series of base64 sections. On a whim I decoded it, and it's BER inside. Good thing I didn't need to understand it, because good luck doing so without a description. Ned From stpeter@stpeter.im Wed Sep 26 19:58:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895CE21F8435 for ; Wed, 26 Sep 2012 19:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTre+1Q5G9AC for ; Wed, 26 Sep 2012 19:58:11 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C1DEA21F842E for ; Wed, 26 Sep 2012 19:58:11 -0700 (PDT) Received: from [192.168.1.234] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0436D40058; Wed, 26 Sep 2012 20:59:40 -0600 (MDT) Message-ID: <5063C0C2.6080907@stpeter.im> Date: Wed, 26 Sep 2012 20:58:10 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Barry Leiba References: <2747A13381D34945560A89E0@JcK-HP8200.jck.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 02:58:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/26/12 8:53 PM, Barry Leiba wrote: [rants elided] > Anyway, it's clear that *everyone* who has commented, including > me, thinks that we *want to* use "RFC Required or Expert Review" -- > that is, that ALL RFCs should bypass Expert Review, assuming to be > adequately reviewed by each stream's process. > > But so far only Pete and Ned have said that that's not only what > they *want*, but also what they think RFC 3864 *says* (or intended > to say; Ned says it doesn't matter what was intended, only what's > written). > > Anyway, tiring of the rants, my inclination is to wrap up this > discussion and say that RFC 3864 does not specify any level of > review for RFCs other than that they be RFCs, so the BCP 26 > interpretation should be "RFC Required or Expert Review". If Pete > agrees that we've had enough discussion and we're ready to tell > IANA, we will tell IANA and ask them to change the registry > policy. I think Section 4.3 of RFC 3864 implies "RFC Required or Expert Review". The first bullet point there covers "RFC Required" and the second one covers "Expert Review". IMHO. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBjwMIACgkQNL8k5A2w/vx1KwCfU4sbS3dOyQYvDeWsj+mZRux7 A4wAn0HfhaXIf0bdipOBDX3X6bJNK8/e =txZ0 -----END PGP SIGNATURE----- From internet-drafts@ietf.org Wed Sep 26 20:37:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272F121F862B; Wed, 26 Sep 2012 20:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSFnDOVdw7OO; Wed, 26 Sep 2012 20:37:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EBE21F8503; Wed, 26 Sep 2012 20:37:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120927033703.3356.43186.idtracker@ietfa.amsl.com> Date: Wed, 26 Sep 2012 20:37:03 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 03:37:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : JSON Patch Author(s) : Paul C. Bryan Mark Nottingham Filename : draft-ietf-appsawg-json-patch-05.txt Pages : 15 Date : 2012-09-26 Abstract: JSON Patch defines the media type "application/json-patch", a JSON document structure for expressing a sequence of operations to apply to a JSON document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-patch-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From john@jck.com Wed Sep 26 20:37:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5843721F863C for ; Wed, 26 Sep 2012 20:37:54 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlDGHEdfscRc for ; Wed, 26 Sep 2012 20:37:53 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id C700521F84FE for ; Wed, 26 Sep 2012 20:37:53 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TH4vB-000Bjs-CF; Wed, 26 Sep 2012 23:37:53 -0400 Date: Wed, 26 Sep 2012 23:37:48 -0400 From: John C Klensin To: Barry Leiba , Apps Discuss Message-ID: <374D95D5E228FC5A329E5075@JcK-HP8200.jck.com> In-Reply-To: References: <2747A13381D34945560A89E0@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 03:37:54 -0000 --On Wednesday, September 26, 2012 22:53 -0400 Barry Leiba wrote: > And let me remind everyone again that we *already* have > nothing more than Graham's lightweight Expert Review on this > registry in all cases. What we're talking about here is > making it *easier* for RFCs, by bypassing Expert Review for > RFCs, as 3864 seems to clearly specify. The *only* question is > whether *all* RFCs should bypass it, or only IETF Stream RFCs. > > It doesn't help to overreact and tell us that what's wrong > with the world is that we're all trying to make registrations > harder. We're not. Barry, while my message may have been too long for you to get to the part of my message that addressed the above, I think I did answer your question. IMO, (1) 3864 doesn't say "if you have an RFC, expert review is completely unnecessary". The language and cases are certainly confusing, but I can't get to "no expert". (2) Regardless of (1), it doesn't say "some RFCs are more equal than others". (3) At the risk of getting back into the "rant" area, the problem with treating "have an RFC" as an alternative to Expert Review is that, even in the IETF Stream, a registration of a header type that is semi-buried in a document that is mostly about something else may not get the quality of review that a definition in a document whose sole purpose was to define that header field would. In that context, it is probably useful to remember that, while we have two Apps ADs at the moment who are both email experts who have enough knowledge to do reviews like this themselves, we are not guaranteed that and could easily end up in a situation where we had zero ADs with that level of qualification and interest. (4) So I believe that, if Expert Review is specified, all such registrations ought to be passed by the Expert, independent of Stream. I believe the language in 3854 is consistent with that. If it is, instead, merely ambiguous or subject to multiple interpretations, I think it is in the interest of the community to interpret it that way. And, if an Expert ever starts blocking registrations from RFCs that have been carefully reviewed for registration application competency, then the IESG needs to correct or fire said Expert. john From mnot@mnot.net Wed Sep 26 20:40:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B719721F84FF for ; Wed, 26 Sep 2012 20:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG3rraV4N27B for ; Wed, 26 Sep 2012 20:40:50 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id B5AD621F84C9 for ; Wed, 26 Sep 2012 20:40:50 -0700 (PDT) Received: from [172.19.1.158] (unknown [173.13.121.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4E8AD50A65 for ; Wed, 26 Sep 2012 23:40:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Mark Nottingham In-Reply-To: <20120927033703.3356.43186.idtracker@ietfa.amsl.com> Date: Wed, 26 Sep 2012 23:40:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1498) Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 03:40:51 -0000 FYI - this incorporates the discussions we've had to date (including = "op"), and it also changes the language around error handling. Feedback / corrections appreciated. Regards, On 26/09/2012, at 11:37 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Applications Area Working Group = Working Group of the IETF. >=20 > Title : JSON Patch > Author(s) : Paul C. Bryan > Mark Nottingham > Filename : draft-ietf-appsawg-json-patch-05.txt > Pages : 15 > Date : 2012-09-26 >=20 > Abstract: > JSON Patch defines the media type "application/json-patch", a JSON > document structure for expressing a sequence of operations to apply > to a JSON document. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-patch-05 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From wmills@yahoo-inc.com Wed Sep 26 21:44:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104BD21F864A for ; Wed, 26 Sep 2012 21:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.487 X-Spam-Level: X-Spam-Status: No, score=-17.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQq+9Hm1ef63 for ; Wed, 26 Sep 2012 21:44:10 -0700 (PDT) Received: from nm7.bullet.mail.sp2.yahoo.com (nm7.bullet.mail.sp2.yahoo.com [98.139.91.77]) by ietfa.amsl.com (Postfix) with SMTP id 9286421F861C for ; Wed, 26 Sep 2012 21:44:10 -0700 (PDT) Received: from [72.30.22.77] by nm7.bullet.mail.sp2.yahoo.com with NNFMP; 27 Sep 2012 04:44:07 -0000 Received: from [98.139.91.45] by tm11.bullet.mail.sp2.yahoo.com with NNFMP; 27 Sep 2012 04:44:07 -0000 Received: from [127.0.0.1] by omp1045.mail.sp2.yahoo.com with NNFMP; 27 Sep 2012 04:44:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 839629.45708.bm@omp1045.mail.sp2.yahoo.com Received: (qmail 63894 invoked by uid 60001); 27 Sep 2012 04:44:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348721047; bh=9O2FWkw5D7ehs6vs8l+RztNBN7kFzvJprbN79qAHbDQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Rk0yI9C8C1OZ+gLHyNOjnbEehi2JRGc/+UIbJNOF6O8VjwN9VVx2Os7xaPSyUoPng3mMa3qfdoR7DW1flnrz9f6hp4JZcc+layG8GtVXsER0sfuoZ7MuHK93pfAfrxru3y1hFteQDxl2VdsKVMUPWEbJEd8WyNlrdJlKOGRUmVU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=MNUtpjAhbh99avOSxB3H6kc/wa+IYRWTAg1POpJFIQT1TvUCYYqR26g8tJCACkq9yUD/k+SBhrM9Z2VbymEimI66pvrQ5OCh7V8cnMpuwMpej6wvyTVaUGxQG4BdoBPxB4aMNIgB2hJeX80tCu+mbHbCk0ZyG5bw+7LUDvx/h0U=; X-YMail-OSG: yhQI_D8VM1n0dR_jzPUF3ToNMYnXbFCNm6HilYNk7jBf_gg znr._KPvDQj4Tdfk82ooKG.4qNSBSikzzswKFbE_EybSbeINP8Vk6AVUGYal fUAd9LXWplmrDwVg7n4hDaluiBr4W6LbcpTZn8zo.aZ_dxHRfap4Cq8Bs.6b gAz0gYDZ3SDzpNKsvtwYQC7ER1INI81AVYp3n5sP97MnP4t2c3V_ceosy3D7 9QSBcqD6efHTkxPB7.hrIx3uVzZHDf.AqLo19.H0OAkTb93pNFTkCLBx2HYJ wJgn9glNB0vFRNZFAV_sKlha3wyWf.LO_IJuMIMa5I4a8aVqLgpOP1CyqZgx Np4pNTatkGcQcb4BQLonxNMKO8GVFMcStETk5MNILdUb9_S5.9nJ.ns9nXx0 tBdcBPSnyNAMHVskeR_8_yaw4Uen.Udv727AET13U8Knc1WWzv67jTZ2HpeP aOZ7bW7nfnekenDdg5YQA3YNfkED9gQ5foBI- Received: from [209.131.62.115] by web31801.mail.mud.yahoo.com via HTTP; Wed, 26 Sep 2012 21:44:07 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.122.442 References: <20120927044105.29367.48787.idtracker@ietfa.amsl.com> <1348720912.62932.YahooMailNeo@web31809.mail.mud.yahoo.com> Message-ID: <1348721047.14972.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Wed, 26 Sep 2012 21:44:07 -0700 (PDT) From: William Mills To: Apps Discuss In-Reply-To: <1348720912.62932.YahooMailNeo@web31809.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-368338466-84472394-1348721047=:14972" Subject: [apps-discuss] Fw: New Version Notification for draft-wmills-oauth-lrdd-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 04:44:12 -0000 ---368338466-84472394-1348721047=:14972 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Updates based on the rather large error pointed out by G. L. Walter in the = examples.=0A=0A-bill=0A=0A=0A=0A----- Forwarded Message -----=0A>From: "int= ernet-drafts@ietf.org" =0A>To: wmills_92105@yahoo= .com =0A>Sent: Wednesday, September 26, 2012 9:41 PM=0A>Subject: New Versio= n Notification for draft-wmills-oauth-lrdd-03.txt=0A> =0A>=0A>A new version= of I-D, draft-wmills-oauth-lrdd-03.txt=0A>has been successfully submitted = by William J. Mills and posted to the=0A>IETF repository.=0A>=0A>Filename:= =A0=A0=A0 draft-wmills-oauth-lrdd=0A>Revision:=A0=A0=A0 03=0A>Title:=A0= =A0=A0 =A0=A0=A0 Link Type Registry for OAuth 2=0A>Creation date:=A0=A0=A0= 2012-09-27=0A>WG ID:=A0=A0=A0 =A0=A0=A0 Individual Submission=0A>Number = of pages: 12=0A>URL:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-d= rafts/draft-wmills-oauth-lrdd-03.txt=0A>Status:=A0 =A0 =A0 =A0 =A0 http://d= atatracker.ietf.org/doc/draft-wmills-oauth-lrdd=0A>Htmlized:=A0 =A0 =A0 =A0= http://tools.ietf.org/html/draft-wmills-oauth-lrdd-03=0A>Diff:=A0 =A0 =A0 = =A0 =A0 =A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-wmills-oauth-lrdd-03= =0A>=0A>Abstract:=0A>=A0 Defines link type registrations for the OAuth 2= =0A authentication=0A>=A0 framework.=0A>=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A>=0A>=0A>Th= e IETF Secretariat=0A>=0A>=0A>=0A>=0A>=0A> ---368338466-84472394-1348721047=:14972 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    Updates based on the rather large error pointed out by G. L. Walter in th= e examples.

    -bill

    -----= Forwarded Message -----
    From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
    To: wmills_92105@yahoo.com Sent: Wednesday, Septemb= er 26, 2012 9:41 PM
    Subject: New Version Notification for draft-wmills-oauth-lrdd-03.txt

    =0A
    A new version of I-D, draft-wmills-oauth-lrdd-03.txthas been successfully submitted by William J. Mills and posted to the
    = IETF repository.

    Filename:    draft-wmills-oauth-lrd= d
    Revision:    03
    Title:     &nbs= p;  Link Type Registry for OAuth 2
    Creation date:   = ; 2012-09-27
    WG ID:        Individual Su= bmission
    Number of pages: 12
    URL:          &= nbsp; http://www.ietf.org/internet-drafts/draft-wmills-oauth-lrdd-03.txtStatus:          http://datatracker.ietf.org/doc= /draft-wmills-oauth-lrdd
    Htmlized:        http://too= ls.ietf.org/html/draft-wmills-oauth-lrdd-03
    Diff:      &n= bsp;     http://www.ietf.org/rfcdiff?url2=3Ddraft-wmills-oauth-lr= dd-03

    Abstract:
      Defines link type registrations for the O= Auth 2=0A authentication
      framework.

          =                      = ;                     &nb= sp;                     &= nbsp;          


    The IETF Secretariat




    ---368338466-84472394-1348721047=:14972-- From duerst@it.aoyama.ac.jp Wed Sep 26 23:29:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3951721F860B for ; Wed, 26 Sep 2012 23:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.019 X-Spam-Level: X-Spam-Status: No, score=-103.019 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUOk+teeVaUt for ; Wed, 26 Sep 2012 23:29:03 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2D621F8607 for ; Wed, 26 Sep 2012 23:29:02 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q8R6Srwm013164 for ; Thu, 27 Sep 2012 15:28:53 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 4623_e555_9b8d2a4a_086c_11e2_b3e3_001d096c5782; Thu, 27 Sep 2012 15:28:52 +0900 Received: from [IPv6:::1] ([133.2.210.1]:45519) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 27 Sep 2012 15:28:55 +0900 Message-ID: <5063F220.2020206@it.aoyama.ac.jp> Date: Thu, 27 Sep 2012 15:28:48 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Alexey Melnikov , Graham Klyne References: <50632EE9.70302@isode.com> In-Reply-To: <50632EE9.70302@isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Applications Area Directors Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 06:29:04 -0000 First, I have copied Graham explicitly. I think he's on this list, but may not have realized that we might appreciate his input. More below. On 2012/09/27 1:35, Alexey Melnikov wrote: > On 26/09/2012 00:13, Applications Area Directors wrote: >> App Area denizens: >> >> Pete and I have been having a debate, in response to a request for >> clarification from IANA, on the proper registration policy for the >> Permanent Message Header Field Names registry: >> http://www.iana.org/assignments/message-headers/perm-headers.html >> >> The registry was defined in RFC 3864 (along with the Provisional >> Message Header Field Names registry), and we weren't as rigorous then >> as we are now about specifying registration policies. The relevant >> text from 3864 is in two places: >> >> Section 4.2.1: >> A header registered in the Permanent Message Header Field Registry >> MUST be published as an RFC or as an "Open Standard" in the sense >> described by RFC 2026, section 7 [1], and MUST have a name which is >> unique among all the registered permanent field names that may be >> used with the same application protocol. >> >> Section 4.3: >> The registration template is submitted for incorporation in one of >> the IANA message header field repositories by one of the following >> methods: >> >> o An IANA considerations section in a defining RFC, calling for >> registration of the message header and referencing information as >> required by the registration template within the same document. >> Registration of the header is then processed as part of the RFC >> publication process. >> >> o Send a copy of the template to the designated email discussion >> list [33] [34]. Allow a reasonable period - at least 2 weeks - >> for discussion and comments, then send the template to IANA at the >> designated email address [35]. IANA will publish the template >> information if the requested name and the specification document >> meet the criteria noted in Section 4.1 and Section 4.2.2, unless >> the IESG or their designated expert have requested that it not be >> published (see Section 4.4). IESG's designated expert should >> confirm to IANA that the registration criteria have been >> satisfied. >> >> This collectively clearly says that there are two processes: one for >> registrations documented in an RFC, and one for others, which involves >> expert review. IANA currently has the policy listed as "Expert >> Review", and, therefore, question whether registration requests in >> RFCs have been through expert review. Our answer, on reading RFC >> 3864, is "No, and it's not necessary." So they want to correct their >> registration policy. >> >> The trouble is that Pete reads RFC 3864 and says that the words >> clearly say that all that's required is an RFC, so the correct policy >> should be "RFC Required or Expert Review"... while I read RFC 3864 and >> say that the intent was to have a reasonable level of review for the >> registrations, that the intended level of review will only happen with >> IETF Stream RFCs, and so the correct policy should be "IETF Review or >> Expert Review". > Yeah, I got confused by that in the past as well. > > According to Graham (who is the Expert Reviewer and can correct me if I > misrepresent him), Expert Review is required in all cases, but for IETF > Stream RFCs Graham trusts that there was sufficient review and basically > applies lightweight approval. Graham said this for URI/IRI scheme registrations, in the context of the ni:/nih: discussion. He may have said the same for message header field names, or he may not have said so. In the later case, he may still actually do so also for message header field names. Regarding the point that Barry explicitly asked for, my reading (not interpretation or intent) of the text is that "one of the following methods:" clearly means that it's okay to have an RFC but no Expert Review (it doesn't exclude doing both, but it does not require having both at the same time). Anything else would be a serious interpretative stretch to the plain English text. While writing this mail (and ducking to not being hit by Barry's rant), I'd like to add that I agree with John that in general, it's a good idea to pass RFC-based registrations past the Expert Reviewers, because of exactly the reasons John has given. I also agree with the general sentiment that it's better to encourage registrations even for stuff that's not necessary technically sound, for the reasons given by several people in the thread. Last but not least, I have to say that I don't care too much which way this turns out, because I don't think it will make too much of a difference in practice. Regards, Martin. From laurentwalter.goix@telecomitalia.it Thu Sep 27 01:31:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D1D21F8707 for ; Thu, 27 Sep 2012 01:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHZk9W3xsDf8 for ; Thu, 27 Sep 2012 01:31:52 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 636CA21F8705 for ; Thu, 27 Sep 2012 01:31:52 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.245.1; Thu, 27 Sep 2012 10:31:47 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Thu, 27 Sep 2012 10:31:47 +0200 From: Goix Laurent Walter To: Evan Prodromou , "apps-discuss@ietf.org" Date: Thu, 27 Sep 2012 10:31:32 +0200 Thread-Topic: [apps-discuss] Making Webfinger replace RFC 6415 (was Re: XML in Webfinger) Thread-Index: Ac2cGPix+dW6awkDQZKVhUGc2+OoZgAatEWw Message-ID: References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> <50635061.2050703@status.net> In-Reply-To: <50635061.2050703@status.net> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [apps-discuss] R: Making Webfinger replace RFC 6415 (was Re: XML in Webfinger) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 08:31:53 -0000 Indeed, should the group feel that some of the basic principles of rrfc6415= be deprecated (see json vs xml discussion) then I would go in favor of suc= h an approach for a cleaner migration. This deprecation would also incentiv= e the related implementations to migrate and avoid a dual-rfc specification= that would facilitate fragmentation. In this process though care should be given to other usages of current rfc6= 415 outside "webfinger" that may be impacted. walter > -----Messaggio originale----- > Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = Per > conto di Evan Prodromou > Inviato: mercoled=EC 26 settembre 2012 20.59 > A: apps-discuss@ietf.org > Oggetto: [apps-discuss] Making Webfinger replace RFC 6415 (was Re: XML in > Webfinger) > > One thing I'm grappling with with the Webfinger draft is that it depends > on RFC 6415, then requires some incompatible changes to that spec, or > drops requirements from it. > > This means that implementers that support the (still active!) RFC 6415 > but don't yet know about or support the Webfinger draft will get > unexpected results. > > Is there a reason that we don't simply replace RFC 6415 with a new RFC? > That would make it clear that there's a preferred new way to do things. > > Otherwise, we should make it a priority that a compliant Webfinger > implementation is also compliant with the closely-related RFC 6415. > > -Evan > > -- > Evan Prodromou, CEO and Founder, StatusNet Inc. > 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 > E: evan@status.net P: +1-514-554-3826 > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From fgaliegue@gmail.com Thu Sep 27 05:27:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FA521F85A3 for ; Thu, 27 Sep 2012 05:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.627 X-Spam-Level: X-Spam-Status: No, score=-3.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BO+EGOfUfPBD for ; Thu, 27 Sep 2012 05:27:41 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DDE6A21F859C for ; Thu, 27 Sep 2012 05:27:40 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so2084660vbb.31 for ; Thu, 27 Sep 2012 05:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=g3jr10QhuI3Pi4+qZ4rr+2uSUa8xgDmkylpYxXEIJvU=; b=AeRBr0ylBh8IX/01fULoA6iHEH4xggkaGV3k7W+c3RsjFKbH2TT06eYbGHcdt6KG0G QV9fBw8zELfFZErJMzIrzg6osfNNEdRZRU8xpMiatl3FwSSEk+ByB0oy5fgIxzBr+K+Q KrzF2DlbBFa+0QHXgBmTimJXp6nQ1LAGbCseG3VyQKv3FlV6dtMyIbLNwk4dxL/cDOYk dsUIFBixGucoKQZEypBl2UhiziNdHdyaeYq359SJwHOk3CA84Cp7RBHGYY+lPP+IA2VX fwQpZmU0TizJLD3UFjRxPKnP5cYXi5eO7dflHoOA/211SvnEU0ujAHPMJlUVLEOPzJX4 Xa1g== MIME-Version: 1.0 Received: by 10.52.27.229 with SMTP id w5mr1714248vdg.126.1348748860291; Thu, 27 Sep 2012 05:27:40 -0700 (PDT) Received: by 10.52.72.137 with HTTP; Thu, 27 Sep 2012 05:27:40 -0700 (PDT) Date: Thu, 27 Sep 2012 14:27:40 +0200 Message-ID: From: Francis Galiegue To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [apps-discuss] RFC 4627 and text vs values X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 12:27:41 -0000 Hello, RFC 4627 has a disturbing feature, since it defines that a JSON text is either an object or an array, but a JSON value can be any type. It also says that JSON generators produce JSON text (without a MUST or SHOULD), and that JSON parsers transform JSON texts only (without a MUST or SHOULD either). Essentially, does it mean that if an application, say, using HTTP, returns: 1 which is a valid JSON _value_, it violates RFC 4627? All JSON parsers I have tried so far "correctly" parse 1, or any "non container" value for that matter, and this seems to be in contradiction with the RFC as well... --=20 Francis Galiegue, fgaliegue@gmail.com "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From andy@hxr.us Thu Sep 27 05:42:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AD921F85A8 for ; Thu, 27 Sep 2012 05:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FecmOhQspd8e for ; Thu, 27 Sep 2012 05:42:26 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DCCDE21F8527 for ; Thu, 27 Sep 2012 05:42:25 -0700 (PDT) Received: by lamb11 with SMTP id b11so367738lam.31 for ; Thu, 27 Sep 2012 05:42:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=WWQh/qSolcCMJmUQ+b9QXRmrsJRExiPG0caeaQoUfQg=; b=V2clccI7k9haMflku15rMn9RSDsLHnxmyG5Lq4eJF4hwKtozIbvSDfnwnyx3P3Rlnn WHEYgTeai1j06Rp4E7zZSWyfXKGyAp/SQLvvTiVKQA/nT/wShXrPJABZq8Cir4xuBImD r3L7JjNj5r/T33qcGT74kAnpx0Gb5S0m2jrheucAsLDkI6EmsMJyQ6n1SYJgWzt1ADH2 a4qvJQCiISh+FxynvF7Ms9APA9Nx11zsXY+I8uEbT4rV9tixnDGJzOYqQVmN3dVf7nyc bJgHORo6RKp9fxGA+YKE+0uTTTfzeQaeE0NqoPeCQZr5RJAOf4qVB2k5D/GpbqGkNNKP zsCw== MIME-Version: 1.0 Received: by 10.152.162.97 with SMTP id xz1mr3207880lab.38.1348749744701; Thu, 27 Sep 2012 05:42:24 -0700 (PDT) Received: by 10.112.7.67 with HTTP; Thu, 27 Sep 2012 05:42:24 -0700 (PDT) X-Originating-IP: [2001:500:4:15:648c:c8f8:b23e:bd70] In-Reply-To: References: Date: Thu, 27 Sep 2012 08:42:24 -0400 Message-ID: From: Andrew Newton To: Francis Galiegue Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnvILflYLxbNNemwx8BEmwofcgvUd+w5Cekrc6sMWz/UNOYxJCSvkDAYThPFRB5C3Q4uRr+ Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] RFC 4627 and text vs values X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 12:42:26 -0000 On Thu, Sep 27, 2012 at 8:27 AM, Francis Galiegue wrote: > Hello, > > RFC 4627 has a disturbing feature, since it defines that a JSON text > is either an object or an array, but a JSON value can be any type. It > also says that JSON generators produce JSON text (without a MUST or > SHOULD), and that JSON parsers transform JSON texts only (without a > MUST or SHOULD either). Hmmm... It does appear that the first two sentences of Section 2 might contradict each other. And the reference to the ABNF from the prose is "JSON text" where the grammar rule is "JSON-text". > > Essentially, does it mean that if an application, say, using HTTP, returns: > > 1 > > which is a valid JSON _value_, it violates RFC 4627? > > All JSON parsers I have tried so far "correctly" parse 1, or any "non > container" value for that matter, and this seems to be in > contradiction with the RFC as well... For what it is worth, this is one of the two differences between RFC 4627 and ECMA-262 called out by ECMAScript. -andy From fgaliegue@gmail.com Thu Sep 27 06:01:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDE521F844F for ; Thu, 27 Sep 2012 06:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.625 X-Spam-Level: X-Spam-Status: No, score=-3.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7m7HvT2y2xW for ; Thu, 27 Sep 2012 06:01:27 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B5BEB21F8504 for ; Thu, 27 Sep 2012 06:01:27 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so2118233vbb.31 for ; Thu, 27 Sep 2012 06:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zcfvde9IQKsBat6BXQGcBVBge5WLRDaMvy850C33Dss=; b=y3Plh4E4k/jwBPbBuSvKzspKySEeZXx74bttcU8Rq2zu6Nh3juiSFTl7fCflMFZFcT 4nS3w6sm58QDIpxVmxXIwKQh/U5Klhz0Zh5YHXV5qjhlSbg3rtGH8dJXRflDhiT7mo3h b/i7POKhymNN5cJqd/TppiHL2F0Lhhs4z+Gu2btFYV9TU/X8o0TdzyJ8NBhT2wisFw7i l32RJrr78chWHVRcLQn2+gtriH/G6ue80nSsRfEZ9kBCegFKv45T5qs7BOkmkmKo/jp8 TIw/6R4mODl7kSA4VZYQPnl7b5UiZ8wl5lFetdCGVVd5m3nvHV/bAOTMvYchXL6heJvd QDKw== MIME-Version: 1.0 Received: by 10.58.74.196 with SMTP id w4mr2239768vev.7.1348750887185; Thu, 27 Sep 2012 06:01:27 -0700 (PDT) Received: by 10.52.72.137 with HTTP; Thu, 27 Sep 2012 06:01:26 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Sep 2012 15:01:26 +0200 Message-ID: From: Francis Galiegue To: Andrew Newton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] RFC 4627 and text vs values X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 13:01:28 -0000 On Thu, Sep 27, 2012 at 2:42 PM, Andrew Newton wrote: [...] > >> >> Essentially, does it mean that if an application, say, using HTTP, retur= ns: >> >> 1 >> >> which is a valid JSON _value_, it violates RFC 4627? >> >> All JSON parsers I have tried so far "correctly" parse 1, or any "non >> container" value for that matter, and this seems to be in >> contradiction with the RFC as well... > > For what it is worth, this is one of the two differences between RFC > 4627 and ECMA-262 called out by ECMAScript. > That kind of begs the question: why wouldn't it be legal to produce JSON values other than arrays/objects? "Primitve" JSON values are potentially useful as well, I don't see the point of forbidding their production. This looks like limiting the expressiveness of JSON to me. Regards, --=20 Francis Galiegue, fgaliegue@gmail.com "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) From wmills@yahoo-inc.com Thu Sep 27 07:08:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D6E21F8433 for ; Thu, 27 Sep 2012 07:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.591 X-Spam-Level: X-Spam-Status: No, score=-17.591 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etznCrm8S1+K for ; Thu, 27 Sep 2012 07:08:34 -0700 (PDT) Received: from nm24-vm1.bullet.mail.ne1.yahoo.com (nm24-vm1.bullet.mail.ne1.yahoo.com [98.138.90.45]) by ietfa.amsl.com (Postfix) with SMTP id 2DE0121F843E for ; Thu, 27 Sep 2012 07:08:33 -0700 (PDT) Received: from [98.138.226.176] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 14:08:29 -0000 Received: from [98.138.89.249] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 14:08:28 -0000 Received: from [127.0.0.1] by omp1041.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 14:08:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 890326.51144.bm@omp1041.mail.ne1.yahoo.com Received: (qmail 13538 invoked by uid 60001); 27 Sep 2012 14:08:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348754908; bh=0sQK0uicY6ghrxSGm7l3fHVQW6m4fL8zJKrTKZjTcTM=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=jCAdT1JcC22pItJDINeMbrqt857FMgCvvtYNLX2nLEuHJ4AwJDaZK/UF4O3LGEv137Kq+m73GgaPAN+JHuoSwNec1qzfY3/bJ9nmphNFLcCZkRwagWb94hJXiOmq9nPreYiQyRIhFW5SnZBAJJSFm0PjyAmUhecAAChsFjsixSc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=bhAf47zeVFXn2lsT8/k3QGSauSeoGtxPUAZZvm+UeXMjUaP/aUFCbip2R0z24Ue+J7OHBKbDiFzOnwhqeQ+qklJntmjejFMZmz96LwZn0uyDY0lsd4CX0Jt/jPolaywmLfdpnoP3TOYVtAAh7dSsal4Zl8+Pic5A7U/lq05Hn+4=; X-YMail-OSG: tWfvh7sVM1ld5_Vwp.d8nfCnteOoTeBtRhOyNti.eGcDa0B tzNOi0Kqhn6pszoItPQro0H1eHclQEEXLPrlwMYqwN2yYhxWMrbJeWZHbT3l D6Q.4QFbVbREE6rPSL3ZtiBDU9HV4HOnQ9zyJfVc4NvZhaBY4Ngja_O3DYg_ 1qN3UlINKQ96t7eI1.VqU.2oZKIOHm.zpJrjYtv865a9bYVB6OJ5BWSTkrsU qgtqbDitmCJJ8IASAGXu9hRF5LWqUNT_AibqimW1kpOSdC5eTU5Fhrc_jzoK 3FceHNV3O62oWvXTDbnkQoXmRbnIvMxZB8jcLwgjbpc65hgjAr0IsZBiIfrO WlmoXsbaMGETi9FJ2q9.9d03eNM_nIWU68_m9hqfgR_O9EaooH7CoHENy9Wz FpwghxpockHHuCIv9iP_ps.bE7gWOlruf0HE59Mc8OMhU22ZQDIT53x2wWp_ Day5uX2pzMw4- Received: from [99.31.212.42] by web31816.mail.mud.yahoo.com via HTTP; Thu, 27 Sep 2012 07:08:27 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.122.442 References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> <50635061.2050703@status.net> Message-ID: <1348754907.98380.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Thu, 27 Sep 2012 07:08:27 -0700 (PDT) From: William Mills To: Goix Laurent Walter , Evan Prodromou , "apps-discuss@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-1644082299-1348754907=:98380" Subject: Re: [apps-discuss] R: Making Webfinger replace RFC 6415 (was Re: XML in Webfinger) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 14:08:35 -0000 ---1238014912-1644082299-1348754907=:98380 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'm generally in favor of having the new thing modify but not replace 6415.= =A0 Much of 6415 can, and I think should, remain intact.=0A=0A=0A=0A=0A=0A>= ________________________________=0A> From: Goix Laurent Walter =0A>To: Evan Prodromou ; "apps-di= scuss@ietf.org" =0A>Sent: Thursday, September 27, 2= 012 1:31 AM=0A>Subject: [apps-discuss] R: Making Webfinger replace RFC 6415= (was Re: XML in Webfinger)=0A> =0A>Indeed, should the group feel that some= of the basic principles of rrfc6415 be deprecated (see json vs xml discuss= ion) then I would go in favor of such an approach for a cleaner migration. = This deprecation would also incentive the related implementations to migrat= e and avoid a dual-rfc specification that would facilitate fragmentation.= =0A>=0A>In this process though care should be given to other usages of curr= ent rfc6415 outside "webfinger" that may be impacted.=0A>=0A>walter=0A>=0A>= =0A>> -----Messaggio originale-----=0A>> Da: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] Per=0A>> conto di Evan Prodromou=0A>= > Inviato: mercoled=EC 26 settembre 2012 20.59=0A>> A: apps-discuss@ietf.or= g=0A>> Oggetto: [apps-discuss] Making Webfinger replace RFC 6415 (was Re: X= ML in=0A>> Webfinger)=0A>>=0A>> One thing I'm grappling with with the Webfi= nger draft is that it depends=0A>> on RFC 6415, then requires some incompat= ible changes to that spec, or=0A>> drops requirements from it.=0A>>=0A>> Th= is means that implementers that support the (still active!) RFC 6415=0A>> b= ut don't yet know about or support the Webfinger draft will get=0A>> unexpe= cted results.=0A>>=0A>> Is there a reason that we don't simply replace RFC = 6415 with a new RFC?=0A>> That would make it clear that there's a preferred= new way to do things.=0A>>=0A>> Otherwise, we should make it a priority th= at a compliant Webfinger=0A>> implementation is also compliant with the clo= sely-related RFC 6415.=0A>>=0A>> -Evan=0A>>=0A>> --=0A>> Evan Prodromou, CE= O and Founder, StatusNet Inc.=0A>> 1124 rue Marie-Anne Est #32, Montreal, Q= uebec, Canada H2J 2B7=0A>> E: evan@status.net P: +1-514-554-3826=0A>>=0A>> = _______________________________________________=0A>> apps-discuss mailing l= ist=0A>> apps-discuss@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/a= pps-discuss=0A>=0A>Questo messaggio e i suoi allegati sono indirizzati escl= usivamente alle persone indicate. La diffusione, copia o qualsiasi altra az= ione derivante dalla conoscenza di queste informazioni sono rigorosamente v= ietate. Qualora abbiate ricevuto questo documento per errore siete cortesem= ente pregati di darne immediata comunicazione al mittente e di provvedere a= lla sua distruzione, Grazie.=0A>=0A>This e-mail and any attachments is conf= idential and may contain privileged information intended for the addressee(= s) only. Dissemination, copying, printing or use by anybody else is unautho= rised. If you are not the intended recipient, please delete this message an= d any attachments and advise the sender by return e-mail, Thanks.=0A>=0A>__= _____________________________________________=0A>apps-discuss mailing list= =0A>apps-discuss@ietf.org=0A>https://www.ietf.org/mailman/listinfo/apps-dis= cuss=0A>=0A>=0A> ---1238014912-1644082299-1348754907=:98380 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    I'm gener= ally in favor of having the new thing modify but not replace 6415.  Mu= ch of 6415 can, and I think should, remain intact.


    From: Goix La= urent Walter <laurentwalter.goix@telecomitalia.it>
    To: Evan Prodromou <evan@status.net&g= t;; "apps-discuss@ietf.org" <apps-discuss@ietf.org>
    Sent: Thursday, September 27, 2012= 1:31 AM
    Subject: [app= s-discuss] R: Making Webfinger replace RFC 6415 (was Re: XML in Webfinger)<= br>

    Indeed, should the group feel that some of the basic= principles of rrfc6415 be deprecated (see json vs xml discussion) then I w= ould go in favor of such an approach for a cleaner migration. This deprecat= ion would also incentive the related implementations to migrate and avoid a= dual-rfc specification that would facilitate fragmentation.

    In this= process though care should be given to other usages of current rfc6415 out= side "webfinger" that may be impacted.

    walter


    > -----M= essaggio originale-----
    > Da: apps-discuss-bou= nces@ietf.org [mailto:apps-discuss-bounces@ietf.or= g] Per
    > conto di Evan Prodromou
    > Inviato: mercoled=EC 26 = settembre 2012 20.59
    > A: apps-discuss@ietf.org
    > Og= getto: [apps-discuss] Making Webfinger replace RFC 6415 (was Re: XML in
    = > Webfinger)
    >
    > One thing I'm grappling with with the Webfi= nger draft is that it depends
    > on RFC 6415, then requires some incom= patible changes to that spec, or
    > drops requirements from it.
    >= ;
    > This means that implementers that support the (still active!) RFC= 6415
    > but don't yet know about or support the Webfinger draft will = get
    > unexpected results.
    >
    > Is there a reason that we d= on't simply replace RFC 6415 with a new RFC?
    > That would make it cle= ar that there's a preferred new way to do things.
    >
    > Otherwise, we should make it a priority that a compliant Webfinger
    >= implementation is also compliant with the closely-related RFC 6415.
    >= ;
    > -Evan
    >
    > --
    > Evan Prodromou, CEO and Founder,= StatusNet Inc.
    > 1124 rue Marie-Anne Est #32, Montreal, Quebec, Cana= da H2J 2B7
    > E: evan@status.net P: +1-514-554-3826
    >
    > ___= ____________________________________________
    > apps-discuss mailing l= ist
    > apps-discuss@ietf.org
    > https://www.ietf= .org/mailman/listinfo/apps-discuss

    Questo messaggio e i suoi all= egati sono indirizzati esclusivamente alle persone indicate. La diffusione,= copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo d= ocumento per errore siete cortesemente pregati di darne immediata comunicaz= ione al mittente e di provvedere alla sua distruzione, Grazie.

    This = e-mail and any attachments is confidential and may contain privileged infor= mation intended for the addressee(s) only. Dissemination, copying, printing= or use by anybody else is unauthorised. If you are not the intended recipi= ent, please delete this message and any attachments and advise the sender b= y return e-mail, Thanks.

    ___________________________________________= ____
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss


    ---1238014912-1644082299-1348754907=:98380-- From pbryan@anode.ca Thu Sep 27 09:19:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5534921F855A for ; Thu, 27 Sep 2012 09:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13YaCM6oo-ns for ; Thu, 27 Sep 2012 09:19:12 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0C121F8534 for ; Thu, 27 Sep 2012 09:19:12 -0700 (PDT) Received: from [10.126.22.51] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 60D8E64F7; Thu, 27 Sep 2012 16:19:11 +0000 (UTC) From: "Paul C. Bryan" To: Mark Nottingham In-Reply-To: References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="=-zkaxcqBhHr1AKrt+/XK1" Date: Thu, 27 Sep 2012 09:19:05 -0700 Message-ID: <1348762745.2494.11.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 16:19:14 -0000 --=-zkaxcqBhHr1AKrt+/XK1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Looks great! Paul On Wed, 2012-09-26 at 23:40 -0400, Mark Nottingham wrote: > FYI - this incorporates the discussions we've had to date (including "op"), and it also changes the language around error handling. > > Feedback / corrections appreciated. > > Regards, > > > On 26/09/2012, at 11:37 PM, internet-drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > > > Title : JSON Patch > > Author(s) : Paul C. Bryan > > Mark Nottingham > > Filename : draft-ietf-appsawg-json-patch-05.txt > > Pages : 15 > > Date : 2012-09-26 > > > > Abstract: > > JSON Patch defines the media type "application/json-patch", a JSON > > document structure for expressing a sequence of operations to apply > > to a JSON document. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-05 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-patch-05 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Mark Nottingham > http://www.mnot.net/ > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-zkaxcqBhHr1AKrt+/XK1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Looks great!

    Paul

    On Wed, 2012-09-26 at 23:40 -0400, Mark Nottingham wrote: 
    FYI - this incorporates the discussions we've had to date (including "op"), and it also changes the language around error handling.

Feedback / corrections appreciated.

Regards,


On 26/09/2012, at 11:37 PM, internet-drafts@ietf.org wrote:

> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Applications Area Working Group Working Group of the IETF.
> 
> 	Title           : JSON Patch
> 	Author(s)       : Paul C. Bryan
>                          Mark Nottingham
> 	Filename        : draft-ietf-appsawg-json-patch-05.txt
> 	Pages           : 15
> 	Date            : 2012-09-26
> 
> Abstract:
>   JSON Patch defines the media type "application/json-patch", a JSON
>   document structure for expressing a sequence of operations to apply
>   to a JSON document.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-05
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-patch-05
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham
http://www.mnot.net/




_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

    --=-zkaxcqBhHr1AKrt+/XK1-- From ned.freed@mrochek.com Fri Sep 28 00:53:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE0521F847A for ; Fri, 28 Sep 2012 00:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9elF3a9TMMW for ; Fri, 28 Sep 2012 00:53:22 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE8721F846B for ; Fri, 28 Sep 2012 00:53:22 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKRQUBPPN4008NUD@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 28 Sep 2012 00:48:19 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=windows-1252 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Fri, 28 Sep 2012 00:48:15 -0700 (PDT) Message-id: <01OKRQU9H8IE0006TF@mauve.mrochek.com> Date: Fri, 28 Sep 2012 00:46:09 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 26 Sep 2012 16:36:57 -0400" <55BCBAE2-0E66-406B-84A5-AB566C35D9B1@mnot.net> References: <20120925233814.GE21618@verdi> <01OKOOEUHQFQ0006TF@mauve.mrochek.com> <55BCBAE2-0E66-406B-84A5-AB566C35D9B1@mnot.net> To: Mark Nottingham Cc: Ned Freed , Apps Discuss , Applications Area Directors Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 07:53:22 -0000 > On 25/09/2012, at 11:01 PM, Ned Freed wrote: > > > > As do I. I have a number of issues with the way RFC 3864 was done, but this is > > not one of them. > and FWIW I've been talking to Graham about revising it. In our copious > spare time, of course. I'm always willing to take some of that copius free time off your hands ;-) More seriously, while such a revision would be nice, I don't think any of this or previous comments pushes it anywhere close to urgent. Ned From GK@ninebynine.org Fri Sep 28 01:40:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B95D21F8546 for ; Fri, 28 Sep 2012 01:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGIMxIesyt4p for ; Fri, 28 Sep 2012 01:40:17 -0700 (PDT) Received: from relay0.mail.ox.ac.uk (relay0.mail.ox.ac.uk [129.67.1.161]) by ietfa.amsl.com (Postfix) with ESMTP id F338821F852E for ; Fri, 28 Sep 2012 01:40:11 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay0.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1THW7F-0006My-29; Fri, 28 Sep 2012 09:40:09 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1THW7F-0000ZW-0h; Fri, 28 Sep 2012 09:40:09 +0100 Message-ID: <50655E62.10104@ninebynine.org> Date: Fri, 28 Sep 2012 09:22:58 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Applications Area Directors References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 08:40:18 -0000 Hi, From memory, and reading the quoted text from section 4..1 of RFC3864, the *intent* of the permanent header field registration was that permanent header fields should have been reviewed through an open standards process by the IETF or similar body - i.e. that permanently registered header fields would be treated as being approved standards. The expert review process was intended to allow some judgement to be applied regarding whether the criteria had been met, particularly in cases where the definition had not gone through the IETF standards process leading to standards-track RFC publication. For example, I would regard a new HTTP header published in a W3C REC track specification to meet the criteria. Thus, section 4.2.1 states the requirements, and section 4.3 describes the process for checking that the requirements are satisfied. Note that the role of expert reviewer here is not primarily to make a technical judgement, but to check for evidence of due process. (In the case of publication in an RFC standards-track document, due process would be self-evident.) ... It is possible that there are instances of approved permanent headers that have been published in informational RFCs that have been through an IETF last-call. This would, strictly speaking, be a violation of the letter of RFC3864 requirements. I believe the URI scheme registries were loosely modeled on the message header field registries, but IIRC adopted a lower bar of "IETF Consensus" for permanent registration. In practice, I think there are relatively few cases where this has or would have made a material difference. ... Since then, there has been a general and gradual move away from the notion of strict standards-process compliance for registered protocol parameters of this kind. There's a tension here between flexibility to introduce new features into existing IETF protocols, and avoiding a Tower of Babel profusion of options with attendant developer confusion and possibly harmful consequences in deployment. Given that there is no enforcement of what header fields can actually be transmitted, and more recent experience that suggests lighter-touch mechanisms can be quite effective for distilling community consensus, there is a reasonable debate to be had about whether the originally proposed requirements and mechanism are appropriate today. Some discussion of this has taken place on the HAPPIANA list, but that is currently stalled. ... To respond to your specific questions, I would judge that an independent stream RFC did not meet the criteria (unless it contained reference to definitions in some other open standards body specification - in which that would be the primary reference). IAB and IRTF stream publications are less clear cut. Strictly, they don't meet the requirements, but to enforce that absolutely would, IMO, to make the process master rather than servant of "doing the right thing". As reviewer, my response would be to seek IESG guidance in such corner cases. (I think there's an "escape clause" in RFC3864 that gives the IESG final say in any case.) At the end of the day, I understand the "IETF way" aims to apply good judgement in these cases ("do the right thing"), and the process is intended to help us achieve that outcome. I see the role of expert reviewer in the process is, in part, to allow for corner cases to be handled responsively. ... I hope this helps. #g -- On 26/09/2012 00:13, Applications Area Directors wrote: > App Area denizens: > > Pete and I have been having a debate, in response to a request for > clarification from IANA, on the proper registration policy for the > Permanent Message Header Field Names registry: > http://www.iana.org/assignments/message-headers/perm-headers.html > > The registry was defined in RFC 3864 (along with the Provisional > Message Header Field Names registry), and we weren't as rigorous then > as we are now about specifying registration policies. The relevant > text from 3864 is in two places: > > Section 4.2.1: > A header registered in the Permanent Message Header Field Registry > MUST be published as an RFC or as an "Open Standard" in the sense > described by RFC 2026, section 7 [1], and MUST have a name which is > unique among all the registered permanent field names that may be > used with the same application protocol. > > Section 4.3: > The registration template is submitted for incorporation in one of > the IANA message header field repositories by one of the following > methods: > > o An IANA considerations section in a defining RFC, calling for > registration of the message header and referencing information as > required by the registration template within the same document. > Registration of the header is then processed as part of the RFC > publication process. > > o Send a copy of the template to the designated email discussion > list [33] [34]. Allow a reasonable period - at least 2 weeks - > for discussion and comments, then send the template to IANA at the > designated email address [35]. IANA will publish the template > information if the requested name and the specification document > meet the criteria noted in Section 4.1 and Section 4.2.2, unless > the IESG or their designated expert have requested that it not be > published (see Section 4.4). IESG's designated expert should > confirm to IANA that the registration criteria have been > satisfied. > > This collectively clearly says that there are two processes: one for > registrations documented in an RFC, and one for others, which involves > expert review. IANA currently has the policy listed as "Expert > Review", and, therefore, question whether registration requests in > RFCs have been through expert review. Our answer, on reading RFC > 3864, is "No, and it's not necessary." So they want to correct their > registration policy. > > The trouble is that Pete reads RFC 3864 and says that the words > clearly say that all that's required is an RFC, so the correct policy > should be "RFC Required or Expert Review"... while I read RFC 3864 and > say that the intent was to have a reasonable level of review for the > registrations, that the intended level of review will only happen with > IETF Stream RFCs, and so the correct policy should be "IETF Review or > Expert Review". > > We're looking for discussion, and other opinions. > > The difference between our opinions involves RFCs done in non-IETF > streams: currently those in the IAB, IRTF, and Independent Streams. > Let's focus on the Independent Stream for the moment, because that's > the one with the greatest potential for problems. > > The IESG gets a very light level of review for Independent Stream > documents, just to determine whether the publication request is in > conflict with work being done in the IETF -- a check for "end runs", > as we call it. We can object to the publication of a document that is > in conflict with current IETF work. But we can't object on the > grounds that an IANA registration request has not had sufficient > review. > > On the other hand, we can *recommend* to the ISE that the IANA > registration go through expert review. The ISE is not obliged to take > that recommendation, but he's very likely to. Pete thinks that this > provides sufficient opportunity for the IESG to say that the > registration needs to be checked. I think that was never the intent > of RFC 3864, and that it should only be IETF Stream RFCs that can > bypass Expert Review. > > OK, there are the arguments so far. Opinions, please (and I'd > especially like to hear from Graham (the designated expert for the > registry) and Ned (the designated expert for Media Types, which has a > similar process)). > > Barry (for Barry and Pete) > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From GK@ninebynine.org Fri Sep 28 01:40:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E12C21F8546 for ; Fri, 28 Sep 2012 01:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KezGRTEP5Q0 for ; Fri, 28 Sep 2012 01:40:18 -0700 (PDT) Received: from relay9.mail.ox.ac.uk (relay9.mail.ox.ac.uk [163.1.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 05A7F21F84FF for ; Fri, 28 Sep 2012 01:40:18 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay9.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1THW7J-0001a6-W4; Fri, 28 Sep 2012 09:40:13 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1THW7J-0000Zi-1A; Fri, 28 Sep 2012 09:40:13 +0100 Message-ID: <50656258.6090900@ninebynine.org> Date: Fri, 28 Sep 2012 09:39:52 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <50632EE9.70302@isode.com> <5063F220.2020206@it.aoyama.ac.jp> In-Reply-To: <5063F220.2020206@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Cc: Apps Discuss , Applications Area Directors Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 08:40:19 -0000 Martin, On 27/09/2012 07:28, "Martin J. Drst" wrote: > First, I have copied Graham explicitly. I think he's on this list, but may not > have realized that we might appreciate his input. I'm here, but not always attentive or instantly responsive :) I have responded to Barry's message. Brief comments below... > More below. > > On 2012/09/27 1:35, Alexey Melnikov wrote: >> On 26/09/2012 00:13, Applications Area Directors wrote: >>> App Area denizens: >>> >>> Pete and I have been having a debate, in response to a request for >>> clarification from IANA, on the proper registration policy for the >>> Permanent Message Header Field Names registry: >>> http://www.iana.org/assignments/message-headers/perm-headers.html >>> >>> The registry was defined in RFC 3864 (along with the Provisional >>> Message Header Field Names registry), and we weren't as rigorous then >>> as we are now about specifying registration policies. The relevant >>> text from 3864 is in two places: >>> >>> Section 4.2.1: >>> A header registered in the Permanent Message Header Field Registry >>> MUST be published as an RFC or as an "Open Standard" in the sense >>> described by RFC 2026, section 7 [1], and MUST have a name which is >>> unique among all the registered permanent field names that may be >>> used with the same application protocol. >>> >>> Section 4.3: >>> The registration template is submitted for incorporation in one of >>> the IANA message header field repositories by one of the following >>> methods: >>> >>> o An IANA considerations section in a defining RFC, calling for >>> registration of the message header and referencing information as >>> required by the registration template within the same document. >>> Registration of the header is then processed as part of the RFC >>> publication process. >>> >>> o Send a copy of the template to the designated email discussion >>> list [33] [34]. Allow a reasonable period - at least 2 weeks - >>> for discussion and comments, then send the template to IANA at the >>> designated email address [35]. IANA will publish the template >>> information if the requested name and the specification document >>> meet the criteria noted in Section 4.1 and Section 4.2.2, unless >>> the IESG or their designated expert have requested that it not be >>> published (see Section 4.4). IESG's designated expert should >>> confirm to IANA that the registration criteria have been >>> satisfied. >>> >>> This collectively clearly says that there are two processes: one for >>> registrations documented in an RFC, and one for others, which involves >>> expert review. IANA currently has the policy listed as "Expert >>> Review", and, therefore, question whether registration requests in >>> RFCs have been through expert review. Our answer, on reading RFC >>> 3864, is "No, and it's not necessary." So they want to correct their >>> registration policy. >>> >>> The trouble is that Pete reads RFC 3864 and says that the words >>> clearly say that all that's required is an RFC, so the correct policy >>> should be "RFC Required or Expert Review"... while I read RFC 3864 and >>> say that the intent was to have a reasonable level of review for the >>> registrations, that the intended level of review will only happen with >>> IETF Stream RFCs, and so the correct policy should be "IETF Review or >>> Expert Review". > >> Yeah, I got confused by that in the past as well. >> >> According to Graham (who is the Expert Reviewer and can correct me if I >> misrepresent him), Expert Review is required in all cases, but for IETF >> Stream RFCs Graham trusts that there was sufficient review and basically >> applies lightweight approval. Yes, I think expert review is always required. In the case of standards yrack publicaton, it's generally trivial (though I do try to make sure the template and definition are actually present and not obviously bogus or inadequate, but any technical comments are clearly separated from my expert reviewer response). > Graham said this for URI/IRI scheme registrations, in the context of the > ni:/nih: discussion. He may have said the same for message header field names, > or he may not have said so. In the later case, he may still actually do so also > for message header field names. The URI scheme requirements are different from the message header requirements. They came later, and were (I believe) designed to be less strict (maybe setting a direction for future progress...) #g -- > Regarding the point that Barry explicitly asked for, my reading (not > interpretation or intent) of the text is that "one of the following methods:" > clearly means that it's okay to have an RFC but no Expert Review (it doesn't > exclude doing both, but it does not require having both at the same time). > Anything else would be a serious interpretative stretch to the plain English text. > > > While writing this mail (and ducking to not being hit by Barry's rant), I'd like > to add that I agree with John that in general, it's a good idea to pass > RFC-based registrations past the Expert Reviewers, because of exactly the > reasons John has given. I also agree with the general sentiment that it's better > to encourage registrations even for stuff that's not necessary technically > sound, for the reasons given by several people in the thread. > > Last but not least, I have to say that I don't care too much which way this > turns out, because I don't think it will make too much of a difference in practice. > > > Regards, Martin. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From GK@ninebynine.org Fri Sep 28 01:40:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C80121F8585 for ; Fri, 28 Sep 2012 01:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.024 X-Spam-Level: X-Spam-Status: No, score=-7.024 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koc4VnmEfHPw for ; Fri, 28 Sep 2012 01:40:19 -0700 (PDT) Received: from relay8.mail.ox.ac.uk (relay8.mail.ox.ac.uk [129.67.1.171]) by ietfa.amsl.com (Postfix) with ESMTP id C915121F852E for ; Fri, 28 Sep 2012 01:40:18 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay8.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1THW7H-0000JC-RW; Fri, 28 Sep 2012 09:40:11 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1THW7H-0000ZZ-1C; Fri, 28 Sep 2012 09:40:11 +0100 Message-ID: <50655FB4.90303@ninebynine.org> Date: Fri, 28 Sep 2012 09:28:36 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <20120925233814.GE21618@verdi> <01OKOOEUHQFQ0006TF@mauve.mrochek.com> <506325AE.3000100@dcrocker.net> In-Reply-To: <506325AE.3000100@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: Ned Freed , Apps Discuss , Applications Area Directors Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 08:40:19 -0000 On 26/09/2012 16:56, Dave Crocker wrote: > > > On 9/25/2012 8:01 PM, Ned Freed wrote: >> We really, really, really need to get it through our heads that we are not the >> protocol police and that documentation of something does not imply endorsement. >> A documented bad idea can be seen for what it is, whereas an undocumented one >> can be very difficult to grapple with. > > > +10 > > Registration is an administrative step to ensure awareness and uniqueness; it's > not for quality control (absent an extremely compelling case being made for > 'dangerous' registrations.) I mostly agree with this, but it was not the prevailing mood at the time header registration proposal was written. The introduction of the "provisional" registry to provide an alternative to standards-track process was, at the time, not without controversy. The result inevitably contained compromises, and maybe not the best ones. But the world has moved on, and maybe it's time to loosen the apron strings some more. #g From GK@ninebynine.org Fri Sep 28 02:49:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BA521F85C4 for ; Fri, 28 Sep 2012 02:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.882 X-Spam-Level: X-Spam-Status: No, score=-6.882 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bunP7AdA8dZ2 for ; Fri, 28 Sep 2012 02:49:13 -0700 (PDT) Received: from relay1.mail.ox.ac.uk (relay1.mail.ox.ac.uk [129.67.1.165]) by ietfa.amsl.com (Postfix) with ESMTP id C157421F8450 for ; Fri, 28 Sep 2012 02:49:13 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay1.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1THXC2-0004le-4W; Fri, 28 Sep 2012 10:49:10 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1THXC1-0001wp-36; Fri, 28 Sep 2012 10:49:10 +0100 Message-ID: <50657229.4070509@ninebynine.org> Date: Fri, 28 Sep 2012 10:47:21 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Ned Freed , Mark Nottingham References: <2747A13381D34945560A89E0@JcK-HP8200.jck.com> <01OKQ27GEZGC0006TF@mauve.mrochek.com> In-Reply-To: <01OKQ27GEZGC0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: Apps Discuss Subject: [apps-discuss] Registration review (was: Registration policy for the Permanent Message Header Field Names registry) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 09:49:14 -0000 Ned, re. "The *description* needs to be competent." I think you make a very important observation here, and one that maybe has not been sufficiently emphasized. I shall try to keep this more firmly in mind when I undertake future reviews. Mark, Is this maybe something to incorporate into your "custodian" draft (sorry, I forget the exact term you used)? #g -- On 27/09/2012 03:43, Ned Freed wrote: >> FWIW, +1 to Ned (and Pete and John). Unless there is a scarcity >> issue, the _only_ criterion for registration should be a review >> for competence of the description. > > I want to emphasize this, because it is incredibly important. > > The *description* needs to be competent. The underlying technology does not. In > fact the cases where the underlying technology is obscure or outright crap are > the ones that are most important to document, because otherwise they can be > incredibly difficult to figure out. > > Decent technology tends to be self-explanatory, even when it's misapplied or > misused. The syntax and semantics of a lot of nonstandard headers is obvious > from inspection even when they don't actually accomplish their intended goal. > But some others ... the other day I ran into one with an opaque name that was a > series of base64 sections. On a whim I decoded it, and it's BER inside. Good > thing I didn't need to understand it, because good luck doing so without a > description. > > Ned > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From barryleiba@gmail.com Fri Sep 28 03:30:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C669321F8578 for ; Fri, 28 Sep 2012 03:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.045 X-Spam-Level: X-Spam-Status: No, score=-103.045 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5igRsvVfw3x for ; Fri, 28 Sep 2012 03:30:24 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 487F721F8513 for ; Fri, 28 Sep 2012 03:30:24 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so3386514vcb.31 for ; Fri, 28 Sep 2012 03:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8CpJJtd3o2FJ2nBx0zRdEsbM2kVwNxkumc6UO6s+Sc4=; b=IVYLKzlwjtlOzjMBLwOZw9Bzj05shTPajBqHqIkzF/x1H+mXYxZYw2LGX+yTLBZKZl 7qxlYBAItnPFklyoi60vFib+a5pql9M28cVRvRBPYzBTa56YaNCbJmOv6DLQ/odpYXEQ RtS4ZoHzKUIQy+GO6IzhKeR/pSy+utc3wLM/wkkrTN/bVgA0R8ujU6jOXebgZu9rZRFP 8NyBKtUw5PYZkKBTQ4SXEeXiHzRPsr+dTrsCtgBQf4oQoWwySvGGyAv+JRY5AeH0z5zB azs9N1DybUEf0yjwE3iN7NjmzBpycQHSGcRqKBPY/AMVOeNCXDApMRI2rSUrZpJMc6/w LZQw== MIME-Version: 1.0 Received: by 10.52.90.83 with SMTP id bu19mr3071376vdb.64.1348828223489; Fri, 28 Sep 2012 03:30:23 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.58.41 with HTTP; Fri, 28 Sep 2012 03:30:23 -0700 (PDT) In-Reply-To: <50655E62.10104@ninebynine.org> References: <50655E62.10104@ninebynine.org> Date: Fri, 28 Sep 2012 06:30:23 -0400 X-Google-Sender-Auth: s_bCf1RR6ylmNPEaiO2jF8cZuyE Message-ID: From: Barry Leiba To: Graham Klyne Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 10:30:24 -0000 Hi, Graham. So you are actually saying that we should leave it alone, and require registrations in RFCs to go through Expert Review, as they have been, and you (and, one presumes, your successor, eventually) will do the right thing. You're saying that the first bullet in Section 4.3 does *not* say that RFCs do not have to go through Expert Review? Barry From hallam@gmail.com Fri Sep 28 05:43:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF3021F8466 for ; Fri, 28 Sep 2012 05:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.984 X-Spam-Level: X-Spam-Status: No, score=-3.984 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZJAGd5K66MQ for ; Fri, 28 Sep 2012 05:43:54 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D62AA21F846D for ; Fri, 28 Sep 2012 05:43:47 -0700 (PDT) Received: by obqv19 with SMTP id v19so3460763obq.31 for ; Fri, 28 Sep 2012 05:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LuyDhlCPizKAhF1PU4O3qcfPQPieOSH82XGPyCWKyGA=; b=AL1t9vtNPjAX9TETifzZ78Uv4xV02OJVwwzuIvuv44hSL5XvPi81ViyWQUk80Dv0qk Id5gR6EfqWZnwhldYlZLodCxA3LcWq5m9m1V6ruxa+Tu/Ful+8kUMi8P+oL8v1ieIeaS LllJBu0mhotvmaZQhd4qiS970+vQRGqJVZKfZsrVFVYh/Llc2lC2ZZchw2C3IxJG1cYV uJtUmhaGMzf9x4N+MYreJYR5UMVJLIQhpqVdsFC9ucdeENGq3hazUXwCtQ31xHwlp+ya zk1HGI1k3en96pkgGv+c01llHDsQduvt+h8/Rb+q05f2OQJOFDmqNCmeOgzWxUYO4F3L EbQw== MIME-Version: 1.0 Received: by 10.60.170.9 with SMTP id ai9mr5606964oec.36.1348836226989; Fri, 28 Sep 2012 05:43:46 -0700 (PDT) Received: by 10.76.18.237 with HTTP; Fri, 28 Sep 2012 05:43:46 -0700 (PDT) In-Reply-To: References: <50655E62.10104@ninebynine.org> Date: Fri, 28 Sep 2012 08:43:46 -0400 Message-ID: From: Phillip Hallam-Baker To: Barry Leiba Content-Type: multipart/alternative; boundary=bcaec54a3e022b7d2d04cac26869 Cc: Graham Klyne , Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 12:43:54 -0000 --bcaec54a3e022b7d2d04cac26869 Content-Type: text/plain; charset=ISO-8859-1 That is how I think it should work. For the DNS registration I needed for CAA, I first asked for a registration through the DNS header registration process, then had the draft referred back to DNS land as part of the last call process. I don't see anything wrong with that process. In fact I think that the expert review is actually more important in standards track applications than otherwise since the point of standards track is that there has been review. For other applications I think people need to take note of the fact that people can and do create new headers without any IANA registration whatsoever. The advantage of registration is that it helps avoid accidental collisions - provided there is a sufficient description to understand what is registered. The real reason that we are having a big confusion in diplomatic circles concerning IETF standards making is that they are unable to understand any system that does not have a top-down flow of authority. Expert review needs to be really minimal or we will end up in the situation where we have a large number of headers that are de-facto standards because they are in use that are not recorded anywhere. We will end up with the mess we have got into with SRV prefixes where other groups have taken over the task of registration. On Fri, Sep 28, 2012 at 6:30 AM, Barry Leiba wrote: > Hi, Graham. > > So you are actually saying that we should leave it alone, and require > registrations in RFCs to go through Expert Review, as they have been, > and you (and, one presumes, your successor, eventually) will do the > right thing. You're saying that the first bullet in Section 4.3 does > *not* say that RFCs do not have to go through Expert Review? > > Barry > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Website: http://hallambaker.com/ --bcaec54a3e022b7d2d04cac26869 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That is how I think it should work.

    For the DNS registra= tion I needed for CAA, I first asked for a registration through the DNS hea= der registration process, then had the draft referred back to DNS land as p= art of the last call process.

    I don't see anything wrong with that process. In fa= ct I think that the expert review is actually more important in standards t= rack applications than otherwise since the point of standards track is that= there has been review.

    For other applications I think people need to take note= of the fact that people can and do create new headers without any IANA reg= istration whatsoever. The advantage of registration is that it helps avoid = accidental collisions - provided there is a sufficient description to under= stand what is registered.

    The real reason that we are having a big confusion in d= iplomatic circles concerning IETF standards making is that they are unable = to understand any system that does not have a top-down flow of authority.= =A0

    Expert review needs to be really minimal or we will end= up in the situation where we have a large number of headers that are de-fa= cto standards because they are in use that are not recorded anywhere. We wi= ll end up with the mess we have got into with SRV prefixes where other grou= ps have taken over the task of registration.



    On Fri, Sep 28, 2012 at 6:30 AM, Barry Leiba <barryleiba@computer.= org> wrote:
    Hi, Graham.

    So you are actually saying that we should leave it alone, and require
    registrations in RFCs to go through Expert Review, as they have been,
    and you (and, one presumes, your successor, eventually) will do the
    right thing. =A0You're saying that the first bullet in Section 4.3 does=
    *not* say that RFCs do not have to go through Expert Review?

    Barry
    _____________________= __________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss



    --
    = Website: http://hallambaker.com/
    --bcaec54a3e022b7d2d04cac26869-- From internet-drafts@ietf.org Fri Sep 28 10:39:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C936821F84FF; Fri, 28 Sep 2012 10:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUNF-h-i5iOh; Fri, 28 Sep 2012 10:39:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4022F21F851C; Fri, 28 Sep 2012 10:39:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120928173928.29198.16219.idtracker@ietfa.amsl.com> Date: Fri, 28 Sep 2012 10:39:28 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 17:39:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Additional Media Type Structured Syntax Suffixes Author(s) : Tony Hansen Alexey Melnikov Filename : draft-ietf-appsawg-media-type-suffix-regs-05.txt Pages : 15 Date : 2012-09-28 Abstract: A content media type name sometimes includes partitioned meta- information distinguish by a Structured Syntax, to permit noting an attribute of the media as a suffix to the name. This document defines several Structured Syntax Suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax Suffixes, and updates the "+xml" Message Type Structured Syntax Suffix registration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-suffix-regs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-media-type-suffix-reg= s-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From evan@status.net Fri Sep 28 13:44:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D8D21F84FE for ; Fri, 28 Sep 2012 13:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fxrCSs2JnKZ for ; Fri, 28 Sep 2012 13:44:12 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 7749521F84EA for ; Fri, 28 Sep 2012 13:44:12 -0700 (PDT) Received: from [192.168.0.115] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 828C08D61B9; Fri, 28 Sep 2012 20:54:40 +0000 (UTC) Message-ID: <50660C1B.20307@status.net> Date: Fri, 28 Sep 2012 16:44:11 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: William Mills References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> <50635061.2050703@status.net> <1348754907.98380.YahooMailNeo@web31816.mail.mud.yahoo.com> In-Reply-To: <1348754907.98380.YahooMailNeo@web31816.mail.mud.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] R: Making Webfinger replace RFC 6415 (was Re: XML in Webfinger) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 20:44:13 -0000 On Thu 27 Sep 2012 10:08:27 AM EDT, William Mills wrote: > I'm generally in favor of having the new thing modify but not replace > 6415. Much of 6415 can, and I think should, remain intact. So, do you think that a client implementing 6415 but not the Webfinger draft should work with a server implementing the Webfinger draft? Similarly with a Webfinger client encounters an RFC 6415 server? I think it's counterproductive to have a current RFC that says, "Do it this way" and another RFC that says "do it another way" and those ways don't actually interoperate. -Evan From evan@status.net Fri Sep 28 13:48:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A732021F846D for ; Fri, 28 Sep 2012 13:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ck-HhwoDQOBN for ; Fri, 28 Sep 2012 13:48:16 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 3C12321F8468 for ; Fri, 28 Sep 2012 13:48:16 -0700 (PDT) Received: from [192.168.0.115] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id EB89A8D6CBF; Fri, 28 Sep 2012 20:58:44 +0000 (UTC) Message-ID: <50660D0F.8090606@status.net> Date: Fri, 28 Sep 2012 16:48:15 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mike Jones References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 20:48:16 -0000 On 12-09-26 02:09 PM, Mike Jones wrote: > The problem with this is that it doesn't accomplish the core goal of the change - which is simplifying WebFinger by requiring only one data format. It's fine to describe XML support in an appendix describing historical usage and it's fine to say that implementations MAY implement it, but saying that implementations SHOULD implement it leaves us with an unnecessarily complicated two-format spec, in practice. > > Mike, I don't agree with that goal. I also disagree that simplicity of the spec is a higher priority than compatibility with existing implementations. I think that dealing with the existing XRD documents on the Web isn't an unnecessary complexity, but a necessary one. -Evan From melvincarvalho@gmail.com Fri Sep 28 13:54:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC91821F85A2 for ; Fri, 28 Sep 2012 13:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFhBkpzRd1wX for ; Fri, 28 Sep 2012 13:54:03 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E85321F85A3 for ; Fri, 28 Sep 2012 13:54:02 -0700 (PDT) Received: by lbok13 with SMTP id k13so2674337lbo.31 for ; Fri, 28 Sep 2012 13:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JsQxKXEyxzpS56c5R36lrfTtuUh4FAd1HqT0DUD8Q68=; b=hX5H4tpgBbwcW+RUPrcjW9QhB/LSgSWe/h+b4Mf2Yy7Xw9XDWwYVcxNpkCaNhKVFzf j2zLZQ/AZiF7XwWrAgMa5iLCtS/bsIawYv+cKgxQ3rebwhbQVBLZrojqUwIK/SxGXQJp nnql/n2qLVKjRZ11vnN0W6fFZnM1rCFP93uCcctvIOBppSwGFeOLUI54ia20DfH6mQ8E 3QLTVmO1khrqtn0oh3m0rP05r2wRHfKUAebmsbpHZVEQ5deDkEEHYGS23dwj3Yf69xjK slB6PTidoPeh84dkUwnoQ35SxAzBFCNvclOM/i3HI02o57SHoS6LPwoDCgOjTCMBtrKA FDGA== MIME-Version: 1.0 Received: by 10.152.108.112 with SMTP id hj16mr135864lab.51.1348865641159; Fri, 28 Sep 2012 13:54:01 -0700 (PDT) Received: by 10.112.148.231 with HTTP; Fri, 28 Sep 2012 13:54:01 -0700 (PDT) In-Reply-To: <50660D0F.8090606@status.net> References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> <50660D0F.8090606@status.net> Date: Fri, 28 Sep 2012 22:54:01 +0200 Message-ID: From: Melvin Carvalho To: Evan Prodromou Content-Type: multipart/alternative; boundary=bcaec54b4e92641d9304cac9415e Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 20:54:04 -0000 --bcaec54b4e92641d9304cac9415e Content-Type: text/plain; charset=ISO-8859-1 On 28 September 2012 22:48, Evan Prodromou wrote: > On 12-09-26 02:09 PM, Mike Jones wrote: > >> The problem with this is that it doesn't accomplish the core goal of the >> change - which is simplifying WebFinger by requiring only one data format. >> It's fine to describe XML support in an appendix describing historical >> usage and it's fine to say that implementations MAY implement it, but >> saying that implementations SHOULD implement it leaves us with an >> unnecessarily complicated two-format spec, in practice. >> >> >> > > Mike, > > I don't agree with that goal. > > I also disagree that simplicity of the spec is a higher priority than > compatibility with existing implementations. > > I think that dealing with the existing XRD documents on the Web isn't an > unnecessary complexity, but a necessary one. > I could be mistaken, but my understanding was that consensus was reached, to move forward with JSON as the required serialization, rather than, XML Given that it took several months of debate to reach such a consensus, is it going to be productive to reopen the debate? > > -Evan > > > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --bcaec54b4e92641d9304cac9415e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On 28 September 2012 22:48, Evan Prodrom= ou <evan@status.net> wrote:
    On 12-09-26 02:09 PM, Mike Jones wrote:
    The problem with this is that it doesn't accomplish the core goal of th= e change - which is simplifying WebFinger by requiring only one data format= . =A0It's fine to describe XML support in an appendix describing histor= ical usage and it's fine to say that implementations MAY implement it, = but saying that implementations SHOULD implement it leaves us with an unnec= essarily complicated two-format spec, in practice.

    =A0 =A0 =A0 =A0

    Mike,

    I don't agree with that goal.

    I also disagree that simplicity of the spec is a higher priority than compa= tibility with existing implementations.

    I think that dealing with the existing XRD documents on the Web isn't a= n unnecessary complexity, but a necessary one.

    I could be mistak= en, but my understanding was that consensus was reached, to move forward wi= th JSON as the required serialization, rather than, XML

    Given that it took several months of debate to reach such a consensus, = is it going to be productive to reopen the debate?
    =A0

    -Evan



    _______________________________________________
    apps-discuss mailing list
    apps-discuss@iet= f.org
    https://www.ietf.org/mailman/listinfo/apps-discuss

    --bcaec54b4e92641d9304cac9415e-- From Michael.Jones@microsoft.com Fri Sep 28 16:30:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF2421F85C6 for ; Fri, 28 Sep 2012 16:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.748 X-Spam-Level: X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNBy8qa9Yvim for ; Fri, 28 Sep 2012 16:30:46 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 85B9621F8464 for ; Fri, 28 Sep 2012 16:30:22 -0700 (PDT) Received: from mail140-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Fri, 28 Sep 2012 23:30:21 +0000 Received: from mail140-ch1 (localhost [127.0.0.1]) by mail140-ch1-R.bigfish.com (Postfix) with ESMTP id 61EE0360113; Fri, 28 Sep 2012 23:30:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VS-23(zz98dI9371Id6eah936eIc85fh1418Id6f1izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1155h) Received-SPF: pass (mail140-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail140-ch1 (localhost.localdomain [127.0.0.1]) by mail140-ch1 (MessageSwitch) id 1348875018749517_30550; Fri, 28 Sep 2012 23:30:18 +0000 (UTC) Received: from CH1EHSMHS023.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail140-ch1.bigfish.com (Postfix) with ESMTP id B14721A005C; Fri, 28 Sep 2012 23:30:18 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 28 Sep 2012 23:30:18 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.31]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Fri, 28 Sep 2012 23:30:17 +0000 From: Mike Jones To: Melvin Carvalho , Evan Prodromou Thread-Topic: [apps-discuss] XML in Webfinger Thread-Index: AQHNjPswpgx4hV1CUEOd0DUjH3qdLZeDq1SAgAAYdACAAJ2mgIAWOpUAgAJeI4CAAA9ekIADUa+AgAABnICAACub8A== Date: Fri, 28 Sep 2012 23:30:16 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667FA1EA@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> <50660D0F.8090606@status.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943667FA1EATK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 23:30:47 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943667FA1EATK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Exactly From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Friday, September 28, 2012 1:54 PM To: Evan Prodromou Cc: Mike Jones; apps-discuss@ietf.org Subject: Re: [apps-discuss] XML in Webfinger On 28 September 2012 22:48, Evan Prodromou > wrote: On 12-09-26 02:09 PM, Mike Jones wrote: The problem with this is that it doesn't accomplish the core goal of the ch= ange - which is simplifying WebFinger by requiring only one data format. I= t's fine to describe XML support in an appendix describing historical usage= and it's fine to say that implementations MAY implement it, but saying tha= t implementations SHOULD implement it leaves us with an unnecessarily compl= icated two-format spec, in practice. Mike, I don't agree with that goal. I also disagree that simplicity of the spec is a higher priority than compa= tibility with existing implementations. I think that dealing with the existing XRD documents on the Web isn't an un= necessary complexity, but a necessary one. I could be mistaken, but my understanding was that consensus was reached, t= o move forward with JSON as the required serialization, rather than, XML Given that it took several months of debate to reach such a consensus, is i= t going to be productive to reopen the debate? -Evan _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --_000_4E1F6AAD24975D4BA5B1680429673943667FA1EATK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Exactly=

     <= /p>

    From: Melvin C= arvalho [mailto:melvincarvalho@gmail.com]
    Sent: Friday, September 28, 2012 1:54 PM
    To: Evan Prodromou
    Cc: Mike Jones; apps-discuss@ietf.org
    Subject: Re: [apps-discuss] XML in Webfinger

     

     

    On 28 September 2012 22:48, Evan Prodromou <evan@status.net> wro= te:

    On 12-09-26 02:09 PM, Mike Jones wrote:

    The problem with this is that it doesn't accomplish = the core goal of the change - which is simplifying WebFinger by requiring o= nly one data format.  It's fine to describe XML support in an appendix= describing historical usage and it's fine to say that implementations MAY implement it, but saying that implementati= ons SHOULD implement it leaves us with an unnecessarily complicated two-for= mat spec, in practice.

           

     

    Mike,

    I don't agree with that goal.

    I also disagree that simplicity of the spec is a higher priority than compa= tibility with existing implementations.

    I think that dealing with the existing XRD documents on the Web isn't an un= necessary complexity, but a necessary one.


    I could be mistaken, but my understanding was that consensus was reached, t= o move forward with JSON as the required serialization, rather than, XML
    Given that it took several months of debate to reach such a consensus, is i= t going to be productive to reopen the debate?
     


    -Evan




    _______________________________________________
    apps-discuss mailing list
    apps-discuss@iet= f.org
    https://www.ietf.org/mailman/listinfo/apps-discuss

     

    --_000_4E1F6AAD24975D4BA5B1680429673943667FA1EATK5EX14MBXC284r_-- From evan@status.net Fri Sep 28 17:18:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F305721F8480 for ; Fri, 28 Sep 2012 17:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEZmgZdGuGCd for ; Fri, 28 Sep 2012 17:18:22 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 641E921F845C for ; Fri, 28 Sep 2012 17:18:22 -0700 (PDT) Received: from [192.168.69.113] (modemcable107.194-202-24.mc.videotron.ca [24.202.194.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 177948D6716 for ; Sat, 29 Sep 2012 00:28:51 +0000 (UTC) Message-ID: <50663E4C.3010000@status.net> Date: Fri, 28 Sep 2012 20:18:20 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> <50660D0F.8090606@status.net> <4E1F6AAD24975D4BA5B1680429673943667FA1EA@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667FA1EA@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 00:18:23 -0000 I think that JRD should be favoured over XRD. But conflicting specs with different requirements are confusing for implementers and may cause interoperability problems. I think that Webfinger should either cleanly extend or replace RFC 6415. -Evan From Michael.Jones@microsoft.com Fri Sep 28 17:24:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF8E21F84F5 for ; Fri, 28 Sep 2012 17:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.735 X-Spam-Level: X-Spam-Status: No, score=-3.735 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63LwefDjQuB5 for ; Fri, 28 Sep 2012 17:24:24 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4A15B21F84F2 for ; Fri, 28 Sep 2012 17:24:24 -0700 (PDT) Received: from mail132-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Sat, 29 Sep 2012 00:24:23 +0000 Received: from mail132-ch1 (localhost [127.0.0.1]) by mail132-ch1-R.bigfish.com (Postfix) with ESMTP id A95613001D9; Sat, 29 Sep 2012 00:24:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz9371I542M1418Id6f1izz1202h1d1ah1d2ahzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1155h) Received-SPF: pass (mail132-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail132-ch1 (localhost.localdomain [127.0.0.1]) by mail132-ch1 (MessageSwitch) id 1348878260891889_987; Sat, 29 Sep 2012 00:24:20 +0000 (UTC) Received: from CH1EHSMHS026.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail132-ch1.bigfish.com (Postfix) with ESMTP id D622422007A; Sat, 29 Sep 2012 00:24:20 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 29 Sep 2012 00:24:20 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.31]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Sat, 29 Sep 2012 00:24:03 +0000 From: Mike Jones To: Evan Prodromou , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] XML in Webfinger Thread-Index: AQHNjPswpgx4hV1CUEOd0DUjH3qdLZeDq1SAgAAYdACAAJ2mgIAWOpUAgAJeI4CAAA9ekIADUa+AgAABnICAACub8IAADXsAgAAAJIA= Date: Sat, 29 Sep 2012 00:24:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667FA31B@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> <50660D0F.8090606@status.net> <4E1F6AAD24975D4BA5B1680429673943667FA1EA@TK5EX14MBXC284.redmond.corp.microsoft.com> <50663E4C.3010000@status.net> In-Reply-To: <50663E4C.3010000@status.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 00:24:25 -0000 This change isn't being made in a vacuum. You're not including the more th= an a dozen of implementations of SWD in your description of the current sta= te of discovery protocol adoption. They have an investment in a JSON-only = discovery protocol that's already working for them. If we can simplify Web= Finger sufficiently, I suspect we can persuade them to switch in the name o= f unification. But if it stays a two-format protocol, that makes the case = a lot harder to make. As I see it, WebFinger may continue to use RFC 6415 IF it makes sense for t= he WebFinger goals. But starting with the premise that using RFC 6415 is a= goal in and of itself seems like the tail wagging the dog. The real goal here is a simple and secure discovery protocol that can and w= ill be ubiquitously adopted. All other considerations should be secondary. -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Evan Prodromou Sent: Friday, September 28, 2012 5:18 PM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] XML in Webfinger I think that JRD should be favoured over XRD. But conflicting specs with different requirements are confusing for impleme= nters and may cause interoperability problems. I think that Webfinger should either cleanly extend or replace RFC 6415. -Evan _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From evan@status.net Fri Sep 28 19:28:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2192F21F8620 for ; Fri, 28 Sep 2012 19:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X0UANaMBX-U for ; Fri, 28 Sep 2012 19:28:07 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 5803921F8613 for ; Fri, 28 Sep 2012 19:28:07 -0700 (PDT) Received: from [192.168.69.107] (modemcable107.194-202-24.mc.videotron.ca [24.202.194.107]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id C26788D5855; Sat, 29 Sep 2012 02:38:35 +0000 (UTC) User-Agent: K-9 Mail for Android In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667FA31B@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> <50660D0F.8090606@status.net> <4E1F6AAD24975D4BA5B1680429673943667FA1EA@TK5EX14MBXC284.redmond.corp.microsoft.com> <50663E4C.3010000@status.net> <4E1F6AAD24975D4BA5B1680429673943667FA31B@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----HRZWY7KOC7GKWLRGKM14DBGXCABEG2" From: Evan Prodromou Date: Fri, 28 Sep 2012 22:28:04 -0400 To: Mike Jones , "apps-discuss@ietf.org" Message-ID: <2d0fb681-d6b0-4c35-8b29-c87b988f83e5@email.android.com> Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 02:28:08 -0000 ------HRZWY7KOC7GKWLRGKM14DBGXCABEG2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Mike, I get that! If we want an all-JRD flow, what about starting from the /.well-known/host-meta.json endpoint instead of /.well-known/host-meta ? The explicit contract for the .json endpoint has always been to provide JRD exclusively, and the lrdd link there is supposed to be jrd, too. It would make it unnecessary to talk at all about XML and XRD in the draft. -Evan Mike Jones wrote: >This change isn't being made in a vacuum. You're not including the >more than a dozen of implementations of SWD in your description of the >current state of discovery protocol adoption. They have an investment >in a JSON-only discovery protocol that's already working for them. If >we can simplify WebFinger sufficiently, I suspect we can persuade them >to switch in the name of unification. But if it stays a two-format >protocol, that makes the case a lot harder to make. > >As I see it, WebFinger may continue to use RFC 6415 IF it makes sense >for the WebFinger goals. But starting with the premise that using RFC >6415 is a goal in and of itself seems like the tail wagging the dog. > >The real goal here is a simple and secure discovery protocol that can >and will be ubiquitously adopted. All other considerations should be >secondary. > > -- Mike > >-----Original Message----- >From: apps-discuss-bounces@ietf.org >[mailto:apps-discuss-bounces@ietf.org] On Behalf Of Evan Prodromou >Sent: Friday, September 28, 2012 5:18 PM >To: apps-discuss@ietf.org >Subject: Re: [apps-discuss] XML in Webfinger > >I think that JRD should be favoured over XRD. > >But conflicting specs with different requirements are confusing for >implementers and may cause interoperability problems. > >I think that Webfinger should either cleanly extend or replace RFC >6415. > >-Evan > >_______________________________________________ >apps-discuss mailing list >apps-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/apps-discuss -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------HRZWY7KOC7GKWLRGKM14DBGXCABEG2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Mike,

    I get that!

    If we want an all-JRD flow, what about starting from the /.well-known/host-meta.json endpoint instead of /.well-known/host-meta ?

    The explicit contract for the .json endpoint has always been to provide JRD exclusively, and the lrdd link there is supposed to be jrd, too.

    It would make it unnecessary to talk at all about XML and XRD in the draft.

    -Evan



    Mike Jones <Michael.Jones@microsoft.com> wrote:
    This change isn't being made in a vacuum.  You're not including the more than a dozen of implementations of SWD in your description of the current state of discovery protocol adoption.  They have an investment in a JSON-only discovery protocol that's already working for them.  If we can simplify WebFinger sufficiently, I suspect we can persuade them to switch in the name of unification.  But if it stays a two-format protocol, that makes the case a lot harder to make.

    As I see it, WebFinger may continue to use RFC 6415 IF it makes sense for the WebFinger goals.  But starting with the premise that using RFC 6415 is a goal in and of itself seems like the tail wagging the dog.

    The real goal here is a simple and secure discovery protocol that can and will be ubiquitously adopted.  All other considerations should be secondary.

        -- Mike

    -----Original Message-----
    From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Evan Prodromou
    Sent: Friday, September 28, 2012 5:18 PM
    To: apps-discuss@ietf.org
    Subject: Re: [apps-discuss] XML in Webfinger

    I think that JRD should be favoured over XRD.

    But conflicting specs with different requirements are confusing for implementers and may cause interoperability problems.

    I think that Webfinger should either cleanly extend or replace RFC 6415.

    -Evan


    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss



    --
    Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------HRZWY7KOC7GKWLRGKM14DBGXCABEG2-- From GK@ninebynine.org Sat Sep 29 03:35:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2236A21F859A for ; Sat, 29 Sep 2012 03:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGYrLi3o0Oz1 for ; Sat, 29 Sep 2012 03:35:45 -0700 (PDT) Received: from relay0.mail.ox.ac.uk (relay0.mail.ox.ac.uk [129.67.1.161]) by ietfa.amsl.com (Postfix) with ESMTP id 82DD821F8593 for ; Sat, 29 Sep 2012 03:35:45 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay0.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1THuOb-0005bA-2H; Sat, 29 Sep 2012 11:35:41 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1THuOa-0002yW-1q; Sat, 29 Sep 2012 11:35:41 +0100 Message-ID: <50659C3C.4080305@ninebynine.org> Date: Fri, 28 Sep 2012 13:46:52 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Barry Leiba References: <50655E62.10104@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 10:35:46 -0000 On 28/09/2012 11:30, Barry Leiba wrote: > Hi, Graham. > > So you are actually saying that we should leave it alone, and require > registrations in RFCs to go through Expert Review, as they have been, > and you (and, one presumes, your successor, eventually) will do the > right thing. You're saying that the first bullet in Section 4.3 does > *not* say that RFCs do not have to go through Expert Review? Short answer: yes, I think so. ... but re-reading the actual text at http://tools.ietf.org/html/rfc3864#section-3 it's not so obvious. What seems to happen in practice is that IANA run header field registration templates in RFCs submitted for publication by me for approval. For standards-track RFCs, that's pretty much a formality, for others, I will dig a little further to evaluate the source of the definition. Thus, my response to your question. By way of explanation, section 4.3 is intended to tell submitters what they have to do. I think the unstated assumption here is that the expert review is part of the "RFC publication process" - that could be clearer. Do IANA get to review registrations before final approval for standards-track RFC publication (as they do, e.g., for independent stream submissions)? If so, then I think it makes sense to simply pass all submissions by the designated reviewer, as an extra pair of eyeballs, however cursory, rarely does harm. #g From john-ietf@jck.com Sat Sep 29 07:12:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA2021F852B for ; Sat, 29 Sep 2012 07:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.557 X-Spam-Level: X-Spam-Status: No, score=-103.557 tagged_above=-999 required=5 tests=[AWL=1.042, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bynk3j9Vgjfh for ; Sat, 29 Sep 2012 07:12:56 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4EF21F8514 for ; Sat, 29 Sep 2012 07:12:55 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1THxml-0000P4-6K; Sat, 29 Sep 2012 10:12:51 -0400 Date: Sat, 29 Sep 2012 10:12:46 -0400 From: John C Klensin To: Graham Klyne , Barry Leiba Message-ID: In-Reply-To: <50659C3C.4080305@ninebynine.org> References: <50655E62.10104@ninebynine.org> <50659C3C.4080305@ninebynine.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 14:12:56 -0000 --On Friday, September 28, 2012 13:46 +0100 Graham Klyne wrote: > By way of explanation, section 4.3 is intended to tell > submitters what they have to do. I think the unstated > assumption here is that the expert review is part of the "RFC > publication process" - that could be clearer. > Do IANA get to review registrations before final approval for > standards-track RFC publication (as they do, e.g., for > independent stream submissions)? If so, then I think it makes > sense to simply pass all submissions by the designated > reviewer, as an extra pair of eyeballs, however cursory, > rarely does harm. It is actually the opposite. Under current procedures IANA gets to (and is required to) review anything that goes out for IETF Last Call as part of/ during the Last Call process. AFIK, there is no such requirement for the Independent Stream. But I think the solution to this problem (if there is a problem) is to work with IANA and the other streams to be sure that review happens in all cases where it is appropriate. In practice, little or nothing is required for an RFC because the RFC Editor has their own procedures for noticing IANA Consideratons sections and registrations and clearing them with IANA. I don't think that requires changes to 3864, nor that such changes would help since this is really a procedural/ coordination issue and there is no real evidence that anything is broken. I agree that, if 3864 were opened for other reasons, a little clarification might be in order. But it seems to me that you are doing the right thing, IANA is doing the right thing, the RFC Editor is doing the right thing, and, if anything actually needs to be done, it is simply to remind the other streams and the RFC Editor that publication of relevant RFCs before IANA signs off is an invitation to confusion. I personally don't think they even need reminding. best, john From melvincarvalho@gmail.com Sun Sep 30 04:40:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08C621F859C for ; Sun, 30 Sep 2012 04:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbyyzK4-jbap for ; Sun, 30 Sep 2012 04:40:50 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C13221F8585 for ; Sun, 30 Sep 2012 04:40:49 -0700 (PDT) Received: by lbok13 with SMTP id k13so3652934lbo.31 for ; Sun, 30 Sep 2012 04:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ID4nnSbEOu6c3hhvoxDp2f9I3VsdsFydw8WCiImbmZ4=; b=dhtYhKW+1fL/MTynoh1KpPDdbCnFJQAXtFPH0lgUzMedfk8eU5UBb8XB27PUYvPVcD L3qwl+LP5+9AkP3qFyeTEGqki79Rw/yFTSasmkeFoF5q4giDQjdkfvxscCkU3BXSM4L3 SJx5CMRhImZI906ONXcHoyzBB3ajLZPSwmEalG+f716KxYgYpsa9HtexL4EVyQ0rby9L vjIcIWkvUN4FrXGseOVkEaAP0ajDMvwuzj6266J5uZb0TVj9if6allSQ7FjzNxAB5Yfw 1HmB8WUdDRKgmQM8ir9CC1UDXT9HrqBdxHL32ZEGqb9/Yk9Uyvb2KrJwhXkXZHqcd1JP Ge5g== MIME-Version: 1.0 Received: by 10.112.86.65 with SMTP id n1mr4278094lbz.100.1349005248984; Sun, 30 Sep 2012 04:40:48 -0700 (PDT) Received: by 10.112.148.231 with HTTP; Sun, 30 Sep 2012 04:40:48 -0700 (PDT) In-Reply-To: <2d0fb681-d6b0-4c35-8b29-c87b988f83e5@email.android.com> References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> <50660D0F.8090606@status.net> <4E1F6AAD24975D4BA5B1680429673943667FA1EA@TK5EX14MBXC284.redmond.corp.microsoft.com> <50663E4C.3010000@status.net> <4E1F6AAD24975D4BA5B1680429673943667FA31B@TK5EX14MBXC284.redmond.corp.microsoft.com> <2d0fb681-d6b0-4c35-8b29-c87b988f83e5@email.android.com> Date: Sun, 30 Sep 2012 13:40:48 +0200 Message-ID: From: Melvin Carvalho To: Evan Prodromou Content-Type: multipart/alternative; boundary=bcaec554e0f2aa750804cae9c200 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 11:40:51 -0000 --bcaec554e0f2aa750804cae9c200 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 29 September 2012 04:28, Evan Prodromou wrote: > Mike, > > I get that! > > If we want an all-JRD flow, what about starting from the > /.well-known/host-meta.json endpoint instead of /.well-known/host-meta ? > Content negotiation elegantly solves this problem. http://en.wikipedia.org/wiki/Content_negotiation If implementations have correctly followed the spec, and set the correct accept header (xrd or jrd), they should always get back the right serialization? If not, it's a one line bug fix? > > The explicit contract for the .json endpoint has always been to provide > JRD exclusively, and the lrdd link there is supposed to be jrd, too. > > It would make it unnecessary to talk at all about XML and XRD in the draf= t. > > -Evan > > > > Mike Jones wrote: >> >> This change isn't being made in a vacuum. You're not including the more= than a dozen of implementations of SWD in your description of the current = state of discovery protocol adoption. They have an investment in a JSON-on= ly discovery protocol that's already working for them. If we can simplify = WebFinger sufficiently, I suspect we can persuade them to switch in the nam= e of unification. But if it stays a two-format protocol, that makes the ca= se a lot harder to make. >> >> As I see it, WebFinger may continue to use RFC 6415 IF it makes sense fo= r the WebFinger goals. But starting with the premise that using RFC 6415 i= s a goal in and of itself seems like the tail wagging the dog. >> >> >> The real goal here is a simple and secure discovery protocol that can an= d will be ubiquitously adopted. All other considerations should be seconda= ry. >> >> -- Mike >> >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.or= g] On Behalf Of Evan Prodromou >> >> Sent: Friday, September 28, 2012 5:18 PM >> To: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] XML in Webfinger >> >> I think that JRD should be favoured over XRD. >> >> But conflicting specs with different requirements are confusing for impl= ementers and may cause interoperability problems. >> >> I think that Webfinger should either cleanly extend or replace RFC 6415. >> >> -Evan >> >> ------------------------------ >> >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> >> > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --bcaec554e0f2aa750804cae9c200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On 29 September 2012 04:28, Evan Prodrom= ou <evan@status.net> wrote:
    Mike,

    I get that!

    If we want an all-JRD flow, what about starting from the /.well-known/host-= meta.json endpoint instead of /.well-known/host-meta ?

    Content negotiation elegantly solves this problem.

    http://en.wikipedia.org/wiki/Content_negotiation

    If impl= ementations have correctly followed the spec, and set the correct accept he= ader (xrd or jrd), they should always get back the right serialization?

    If not, it's a one line bug fix?
    =A0

    The explicit contract for the .json endpoint has always been to provide JRD= exclusively, and the lrdd link there is supposed to be jrd, too.

    It would make it unnecessary to talk at all about XML and XRD in the draft.=

    -Evan



    Mike Jones <Michael.Jones@microsoft.com>= wrote:
    This change isn't being made in a vacuum.  You=
're not including the more than a dozen of implementations of SWD in yo=
ur description of the current state of discovery protocol adoption.  They h=
ave an investment in a JSON-only discovery protocol that's already work=
ing for them.  If we can simplify WebFinger sufficiently, I suspect we can =
persuade them to switch in the name of unification.  But if it stays a two-=
format protocol, that makes the case a lot harder to make.
    


    As I see it, WebFinger may continue to use RFC 6415 IF it makes sense f=
or the WebFinger goals.  But starting with the premise that using RFC 6415 =
is a goal in and of itself seems like the tail wagging the dog.

    

The real goal here is a simple and secure discovery protocol that can and w=
ill be ubiquitously adopted.  All other considerations should be secondary.=


        -- Mike

    -----Original Message-----
    From: apps-discuss-bounces=
@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Evan Prodromo=
u
    

Sent: Friday, September 28, 2012 5:18 PM
    To: apps-discuss@ietf.org
    Subject: Re: [=
apps-discuss] XML in Webfinger

    I think that JRD should be favoured o=
ver XRD.
    


    But conflicting specs with different requirements are confusing for imp=
lementers and may cause interoperability problems.

    I think that Webf=
inger should either cleanly extend or replace RFC 6415.

    -Evan


    --
    Sent from my Android phone with K-9 Mail. Please excuse my brevity.    <= /span>

    _______________________________________________
    apps-discuss mailing list
    apps-discuss@iet= f.org
    https://www.ietf.org/mailman/listinfo/apps-discuss


    --bcaec554e0f2aa750804cae9c200-- From evan@status.net Sun Sep 30 06:17:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34A121F866B for ; Sun, 30 Sep 2012 06:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwCHnhQwlJs0 for ; Sun, 30 Sep 2012 06:17:50 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 137B521F8525 for ; Sun, 30 Sep 2012 06:17:49 -0700 (PDT) Received: from [192.168.69.113] (modemcable107.194-202-24.mc.videotron.ca [24.202.194.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id B003B8D5ABC for ; Sun, 30 Sep 2012 13:28:20 +0000 (UTC) Message-ID: <5068467A.1010004@status.net> Date: Sun, 30 Sep 2012 09:17:46 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> <50660D0F.8090606@status.net> <4E1F6AAD24975D4BA5B1680429673943667FA1EA@TK5EX14MBXC284.redmond.corp.microsoft.com> <50663E4C.3010000@status.net> <4E1F6AAD24975D4BA5B1680429673943667FA31B@TK5EX14MBXC284.redmond.corp.microsoft.com> <2d0fb681-d6b0-4c35-8b29-c87b988f83e5@email.android.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050005080201060501050804" Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 13:17:51 -0000 This is a multi-part message in MIME format. --------------050005080201060501050804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12-09-30 07:40 AM, Melvin Carvalho wrote: > > > On 29 September 2012 04:28, Evan Prodromou > wrote: > > Mike, > > I get that! > > If we want an all-JRD flow, what about starting from the > /.well-known/host-meta.json endpoint instead of > /.well-known/host-meta ? > > > Content negotiation elegantly solves this problem. In RFC 6415, the default content type for the /.well-known/host-meta endpoint is XRD. If no "Accept" request header field is included with the request, or if the client requests an "application/xrd+xml" representation, the server MUST respond using the REQUIRED XRD 1.0 XML representation described inSection 3.1 . On the other hand, the /.well-known/host-meta.json endpoint always returns JRD. Alternatively, the client MAY request a JRD representation by requesting the "host-meta.json" well-known document, by making a GET request for "/.well-known/host-meta.json", following the same process used for "/.well-known/host-meta". If the server does not support serving a JRD representation at this location, the server MUST respond with an HTTP 404 (Not Found) status code. If there's a desire to make a JRD-only version of the Webfinger draft -- which I think is a good idea! -- I think using the host-meta.json endpoint /only/ is a good idea. > If implementations have correctly followed the spec, and set the > correct accept header (xrd or jrd), they should always get back the > right serialization? The Accept header isn't required in RFC 6415, probably because there are plenty of implementations that antedate the RFC and just return (or expect) XRD no matter what. Having different default content types at the same well-known endpoint makes it impossible for servers to support both RFC 6415 and the new Webfinger draft. > If not, it's a one line bug fix? I think as with any network protocol, the hard part isn't fixing one's own software, but communicating with everyone else's. -Evan --------------050005080201060501050804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    On 12-09-30 07:40 AM, Melvin Carvalho wrote:


    On 29 September 2012 04:28, Evan Prodromou <evan@status.net> wrote:
    Mike,

    I get that!

    If we want an all-JRD flow, what about starting from the /.well-known/host-meta.json endpoint instead of /.well-known/host-meta ?

    Content negotiation elegantly solves this problem.
    In RFC 6415, the default content type for the /.well-known/host-meta endpoint is XRD.
       If no "Accept" request header field
   is included with the request, or if the client requests an
   "application/xrd+xml" representation, the server MUST respond using
   the REQUIRED XRD 1.0 XML representation described in Section 3.1.
    On the other hand, the /.well-known/host-meta.json endpoint always returns JRD.
       Alternatively, the client MAY request a JRD representation by
   requesting the "host-meta.json" well-known document, by making a GET
   request for "/.well-known/host-meta.json", following the same process
   used for "/.well-known/host-meta".  If the server does not support
   serving a JRD representation at this location, the server MUST
   respond with an HTTP 404 (Not Found) status code.
    If there's a desire to make a JRD-only version of the Webfinger draft -- which I think is a good idea! -- I think using the host-meta.json endpoint only is a good idea.
    If implementations have correctly followed the spec, and set the correct accept header (xrd or jrd), they should always get back the right serialization?
    The Accept header isn't required in RFC 6415, probably because there are plenty of implementations that antedate the RFC and just return (or expect) XRD no matter what.

    Having different default content types at the same well-known endpoint makes it impossible for servers to support both RFC 6415 and the new Webfinger draft.
    If not, it's a one line bug fix?
    I think as with any network protocol, the hard part isn't fixing one's own software, but communicating with everyone else's.

    -Evan
    --------------050005080201060501050804-- From melvincarvalho@gmail.com Sun Sep 30 06:35:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78E321F8669 for ; Sun, 30 Sep 2012 06:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.973 X-Spam-Level: X-Spam-Status: No, score=-2.973 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbIlj4XikLA8 for ; Sun, 30 Sep 2012 06:35:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8656A21F865F for ; Sun, 30 Sep 2012 06:35:48 -0700 (PDT) Received: by lbok13 with SMTP id k13so3697842lbo.31 for ; Sun, 30 Sep 2012 06:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lM9jM0bRuE050F2pfSh+3q2UhlsjDL8hrvP4SnJ9+Ns=; b=rv4db+EO4fYyWfSDqu/xmyI4rbx26Ubf0XKQBou7oCBn366oBHu9H8lifUFFEGDD1E ErN55I7KavqQvoMOppk8GqmgDCVFQdwCWHKW8GdKG2tj+QyDjbdmEFIaSKjBvZlErGq/ F+ShfowAAqz1Ed02Kbnq+GsVwaNnnSz8K/vDnwVdkpEO4WNImP49/qwXEaffkYhgYNgi 5dU15iazp6kb2WLrz455LbnINfRUa/NMK4/t0VnnBO3jMi5W9VOga8vjVMkCnJJ1jArW 4PrwdDtppTTGzTuA715eAk+kDF/yASGOWuoPMbBntKvBsLLTzElcF14UDEvUk2s4bxhd SKNw== MIME-Version: 1.0 Received: by 10.112.85.132 with SMTP id h4mr4200222lbz.90.1349012147455; Sun, 30 Sep 2012 06:35:47 -0700 (PDT) Received: by 10.112.148.231 with HTTP; Sun, 30 Sep 2012 06:35:47 -0700 (PDT) In-Reply-To: <5068467A.1010004@status.net> References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> <50660D0F.8090606@status.net> <4E1F6AAD24975D4BA5B1680429673943667FA1EA@TK5EX14MBXC284.redmond.corp.microsoft.com> <50663E4C.3010000@status.net> <4E1F6AAD24975D4BA5B1680429673943667FA31B@TK5EX14MBXC284.redmond.corp.microsoft.com> <2d0fb681-d6b0-4c35-8b29-c87b988f83e5@email.android.com> <5068467A.1010004@status.net> Date: Sun, 30 Sep 2012 15:35:47 +0200 Message-ID: From: Melvin Carvalho To: Evan Prodromou Content-Type: multipart/alternative; boundary=f46d04016877d8c82104caeb5ddd Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 13:35:49 -0000 --f46d04016877d8c82104caeb5ddd Content-Type: text/plain; charset=ISO-8859-1 On 30 September 2012 15:17, Evan Prodromou wrote: > On 12-09-30 07:40 AM, Melvin Carvalho wrote: > > > > On 29 September 2012 04:28, Evan Prodromou wrote: > >> Mike, >> >> I get that! >> >> If we want an all-JRD flow, what about starting from the >> /.well-known/host-meta.json endpoint instead of /.well-known/host-meta ? >> > > Content negotiation elegantly solves this problem. > > In RFC 6415, the default content type for the /.well-known/host-meta > endpoint is XRD. > > If no "Accept" request header field > is included with the request, or if the client requests an > "application/xrd+xml" representation, the server MUST respond using > the REQUIRED XRD 1.0 XML representation described in Section 3.1 . > > On the other hand, the /.well-known/host-meta.json endpoint always returns > JRD. > > Alternatively, the client MAY request a JRD representation by > requesting the "host-meta.json" well-known document, by making a GET > request for "/.well-known/host-meta.json", following the same process > used for "/.well-known/host-meta". If the server does not support > serving a JRD representation at this location, the server MUST > respond with an HTTP 404 (Not Found) status code. > > If there's a desire to make a JRD-only version of the Webfinger draft -- > which I think is a good idea! -- I think using the host-meta.json endpoint > *only* is a good idea. > Thanks for the clarification. That makes sense. > > If implementations have correctly followed the spec, and set the correct > accept header (xrd or jrd), they should always get back the right > serialization? > > The Accept header isn't required in RFC 6415, probably because there are > plenty of implementations that antedate the RFC and just return (or expect) > XRD no matter what. > > Having different default content types at the same well-known endpoint > makes it impossible for servers to support both RFC 6415 and the new > Webfinger draft. > > If not, it's a one line bug fix? > > I think as with any network protocol, the hard part isn't fixing one's own > software, but communicating with everyone else's. > > -Evan > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d04016877d8c82104caeb5ddd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On 30 September 2012 15:17, Evan Prodrom= ou <evan@status.net> wrote:
    =20 =20 =20
    On 12-09-30 07:40 AM, Melvin Carvalho wrote:


    On 29 September 2012 04:28, Evan Prodromou <evan@status.net> wrote:
    Mike,

    I get that!

    If we want an all-JRD flow, what about starting from the /.well-known/host-meta.json endpoint instead of /.well-known/host-meta ?

    Content negotiation elegantly solves this problem.
    In RFC 6415, the default content type for the /.well-known/host-meta endpoint is XRD.
       If no "Accept" request header field
   is included with the request, or if the client requests an
   "application/xrd+xml" representation, the server MUST respond =
using
   the REQUIRED XRD 1.0 XML representation described in Section 3.1.
    On the other hand, the /.well-known/host-meta.json endpoint always returns JRD.
       Alternatively, the client MAY request a JRD representation by
   requesting the "host-meta.json" well-known document, by making=
 a GET
   request for "/.well-known/host-meta.json", following the same =
process
   used for "/.well-known/host-meta".  If the server does not sup=
port
   serving a JRD representation at this location, the server MUST
   respond with an HTTP 404 (Not Found) status code.
    If there's a desire to make a JRD-only version of the Webfinger draft -- which I think is a good idea! -- I think using the host-meta.json endpoint only is a good idea.
    <= div>
    Thanks for the clarification.=A0 That makes sense.
    =A0

    If implementations have correctly followed the spec, and set the correct accept header (xrd or jrd), they should always get back the right serialization?
    The Accept header isn't required in RFC 6415, probably because ther= e are plenty of implementations that antedate the RFC and just return (or expect) XRD no matter what.

    Having different default content types at the same well-known endpoint makes it impossible for servers to support both RFC 6415 and the new Webfinger draft.

    If not, it's a one line bug fix?
    I think as with any network protocol, the hard part isn't fixing one's own software, but communicating with everyone else's.

    -Evan

    _______________________________________________
    apps-discuss mailing list
    apps-discuss@ietf.org
    https://www.ietf.org/mailman/listinfo/apps-discuss


    --f46d04016877d8c82104caeb5ddd-- From James.H.Manger@team.telstra.com Sun Sep 30 22:22:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1385721F84F5 for ; Sun, 30 Sep 2012 22:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.242 X-Spam-Level: X-Spam-Status: No, score=0.242 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uk0NLXAbouFg for ; Sun, 30 Sep 2012 22:22:15 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 0011D21F8459 for ; Sun, 30 Sep 2012 22:22:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,515,1344175200"; d="scan'208";a="93531031" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 01 Oct 2012 15:22:10 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6851"; a="39978996" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcani.tcif.telstra.com.au with ESMTP; 01 Oct 2012 15:22:10 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Mon, 1 Oct 2012 15:22:09 +1000 From: "Manger, James H" To: Mark Nottingham , "apps-discuss@ietf.org" Date: Mon, 1 Oct 2012 15:22:08 +1000 Thread-Topic: json-patch: "op":"insert" and "op":"put" Thread-Index: Ac2cYehurY7DjAyjT5O6gci4i377xgDKiE2A Message-ID: <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com> References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [apps-discuss] json-patch: "op":"insert" and "op":"put" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 05:22:16 -0000 UkU6IGRyYWZ0LWlldGYtYXBwc2F3Zy1qc29uLXBhdGNoLTA1DQoNClN1Z2dlc3Rpb246IHJlcGxh Y2UgdGhlICJhZGQiIGFuZCAicmVwbGFjZSIgb3BlcmF0aW9ucyB3aXRoICJpbnNlcnQiIGFuZCAi cHV0IiBvcGVyYXRpb25zIHRoYXQgd29yayB3aXRob3V0IG5lZWRpbmcgdG8ga25vdyAoaWUgYmUg aW4gc3luYyB3aXRoKSB0aGUgb2xkIHN0YXRlIG9mIHRoZSBKU09OIGRvYyBiZWluZyBjaGFuZ2Vk LiBOZXcgdGV4dDoNCg0KICA0LjEuIGluc2VydA0KDQogICAgVGhlICJpbnNlcnQiIG9wZXJhdGlv biBhZGRzIGEgbmV3IHZhbHVlIHRvIGFuIGFycmF5LiBUaGUgb3BlcmF0aW9uDQogICAgb2JqZWN0 IE1VU1QgaW5jbHVkZSAicGF0aCIgYW5kICJ2YWx1ZSIgbWVtYmVycywgYW5kIE1BWSBpbmNsdWRl IGFuDQogICAgImkiIG1lbWJlci4gInBhdGgiIGhvbGRzIGEgSlNPTiBwb2ludGVyIHRoYXQgaWRl bnRpZmllcyBhbiBhcnJheS4NCiAgICAidmFsdWUiIGhvbGRzIHRoZSB2YWx1ZSB0byBhZGQsIHdo aWNoIGNhbiBiZSBhbnkgSlNPTiB2YWx1ZS4NCiAgICAiaSIgaG9sZHMgYSBudW1iZXIgdGhhdCBp cyByb3VuZGVkIHRvIHRoZSBuZWFyZXN0IGludGVnZXIgdG8gZ2l2ZQ0KICAgIHRoZSBhcnJheSBp bmRleCBvZiB0aGUgbmV3IHZhbHVlIHdoZW4gaW5zZXJ0ZWQuIElmICJpIiBpcyBhYnNlbnQgdGhl DQogICAgdmFsdWUgaXMgYXBwZW5kZWQgdG8gdGhlIGFycmF5LiBBbnkgaXRlbXMgaW4gdGhlIGFy cmF5IGF0IGFuIGluZGV4DQogICAgZXF1YWwgdG8gb3IgZ3JlYXRlciB0aGFuICJpIiBhcmUgbW92 ZWQgdG8gdGhlIG5leHQgaGlnaGVyIGluZGV4IHRvDQogICAgbWFrZSByb29tIGZvciB0aGUgbmV3 IHZhbHVlLg0KDQogICAgSXQgaXMgYW4gZXJyb3IgaWYgImkiIChyb3VuZGVkIHRvIHRoZSBuZWFy ZXN0IGludGVnZXIpIGlzIGxlc3MgdGhhbg0KICAgIDAgb3IgZ3JlYXRlciB0aGFuIHRoZSBsZW5n dGggb2YgdGhlIGFycmF5Lg0KDQogICAgRXhhbXBsZToNCiAgICBPbGQ6ICAgeyJuIjpbMSwyLDNd fQ0KICAgIFBhdGNoOiBbeyJvcCI6Imluc2VydCIsICJwYXRoIjoiL24iLCAidmFsdWUiOjR9LA0K ICAgICAgICAgICAgeyJvcCI6Imluc2VydCIsICJwYXRoIjoiL24iLCAidmFsdWUiOjUsICJpIjo1 fSwNCiAgICAgICAgICAgIHsib3AiOiJpbnNlcnQiLCAicGF0aCI6Ii9uIiwgInZhbHVlIjoxLjUs ICJpIjoxfV0NCiAgICBOZXc6ICAgeyJuIjpbMSwxLjUsMiwzLDQsNV19DQoNCg0KICA0LjIuIHB1 dA0KDQogICAgVGhlICJwdXQiIG9wZXJhdGlvbiBwdXRzIGEgbmV3IHZhbHVlIGF0IHRoZSB0YXJn ZXQgbG9jYXRpb24sDQogICAgcmVwbGFjaW5nIGFueSBleGlzdGluZyB2YWx1ZSBpZiB0aGVyZSBp cyBvbmUuIFRoZSBvcGVyYXRpb24gb2JqZWN0DQogICAgTVVTVCBpbmNsdWRlICJwYXRoIiBhbmQg InZhbHVlIiBtZW1iZXJzLiAicGF0aCIgaG9sZHMgYSBKU09OIHBvaW50ZXINCiAgICB0aGF0IGlk ZW50aWZpZXMgdGhlIHRhcmdldCBsb2NhdGlvbiwgd2hpY2ggY2FuIGJlIGFuIG9iamVjdCBtZW1i ZXINCiAgICAodGhhdCBpcyBvciBpc24ndCBwcmVzZW50KSwgYW4gYXJyYXkgaW5kZXggKHRoYXQg bXVzdCBleGlzdCksIG9yDQogICAgdGhlIHdob2xlIHRhcmdldC4gInZhbHVlIiBob2xkcyB0aGUg dmFsdWUgdG8gYWRkLCB3aGljaCBjYW4gYmUgYW55DQogICAgSlNPTiB2YWx1ZS4NCg0KICAgIEV4 YW1wbGU6DQogICAgT2xkOiAgIHsibiI6WzEsMiwzXX0NCiAgICBQYXRjaDogW3sib3AiOiJwdXQi LCAicGF0aCI6IiIsICJ2YWx1ZSI6W3RydWUsIHsiYSI6MX1dfSwNCiAgICAgICAgICAgIHsib3Ai OiJwdXQiLCAicGF0aCI6Ii8wIiwgInZhbHVlIjpmYWxzZX0sDQogICAgICAgICAgICB7Im9wIjoi cHV0IiwgInBhdGgiOiIvMS9iIiwgInZhbHVlIjoyfSwNCiAgICAgICAgICAgIHsib3AiOiJwdXQi LCAicGF0aCI6Ii8xL2EiLCAidmFsdWUiOjN9XQ0KICAgIE5ldzogICBbZmFsc2UsIHsiYSI6Mywg ImIiOjJ9XQ0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From James.H.Manger@team.telstra.com Sun Sep 30 22:41:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD6D21F859C for ; Sun, 30 Sep 2012 22:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.307 X-Spam-Level: X-Spam-Status: No, score=0.307 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIH7qqt4N0DW for ; Sun, 30 Sep 2012 22:41:31 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 83E2B21F859B for ; Sun, 30 Sep 2012 22:41:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,515,1344175200"; d="scan'208";a="95204224" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 01 Oct 2012 15:41:26 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6851"; a="130690196" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcavi.tcif.telstra.com.au with ESMTP; 01 Oct 2012 15:41:26 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Mon, 1 Oct 2012 15:41:25 +1000 From: "Manger, James H" To: Mark Nottingham , "apps-discuss@ietf.org" Date: Mon, 1 Oct 2012 15:41:24 +1000 Thread-Topic: json-patch: "op":"tree" Thread-Index: Ac2cYehurY7DjAyjT5O6gci4i377xgDKiE2AAAIrQXA= Message-ID: <255B9BB34FB7D647A506DC292726F6E114FD642E67@WSMSG3153V.srv.dir.telstra.com> References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [apps-discuss] json-patch: "op":"tree" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 05:41:32 -0000 UkU6IGRyYWZ0LWlldGYtYXBwc2F3Zy1qc29uLXBhdGNoLTA1DQoNClN1Z2dlc3Rpb246IGRlZmlu ZSBhICJ0cmVlIiBvcGVyYXRpb24gZm9yIGdyb3VwaW5nIG9wZXJhdGlvbnMgdGhhdCBhcHBseSB0 byBwYXJ0IG9mIHRoZSBKU09OIGRvYyBiZWluZyBjaGFuZ2VkLiBJdCBhdm9pZHMgcmVwZWF0aW5n IGEgcGF0aCBwcmVmaXggaW4gbG90cyBvZiBvcGVyYXRpb25zOyBpdCBzaW1wbGlmaWVzIHdyaXRp bmcgYSBwYXRjaCB0aGF0IGNhbiBiZSBhcHBsaWVkIGF0IGRpZmZlcmVudCBwb2ludHM7IGl0cyBl YXNpZXIgdG8gc2VwYXJhdGUgdGhlIHBhdGNoIGZvciBjaGFuZ2luZyBhIHZhbHVlIGZyb20gd2hl cmUgdGhhdCB2YWx1ZSBpcyBpbiBhIGxhcmdlciBKU08gc3RydWN0dXJlLiBOZXcgdGV4dDoNCg0K ICA0LjcuIHRyZWUNCg0KICAgIFRoZSAidHJlZSIgb3BlcmF0aW9uIGFwcGxpZXMgb3RoZXIgb3Bl cmF0aW9ucyB0byBhIHN1YnNldCBvZg0KICAgIHRoZSB0YXJnZXQuIFRoZSBvcGVyYXRpb24gb2Jq ZWN0IE1VU1QgaW5jbHVkZSAicGF0aCIgYW5kICJvcHMiDQogICAgbWVtYmVycy4gInBhdGgiIGhv bGRzIGEgSlNPTiBwb2ludGVyIHRoYXQgaWRlbnRpZmllcyB0aGUgdmFsdWUNCiAgICB0byB3aGlj aCB0aGUgb3RoZXIgb3BlcmF0aW9ucyBhcHBseS4gIm9wcyIgaG9sZHMgYW4gYXJyYXkgb2YNCiAg ICBvcGVyYXRpb24gb2JqZWN0cy4gSlNPTiBwb2ludGVycyB3aXRoaW4gIm9wcyIgYXJlIHJlbGF0 aXZlDQogICAgdG8gdGhlIHZhbHVlIGlkZW50aWZpZWQgYnkgInBhdGgiLg0KDQogICAgRXhhbXBs ZToNCiAgICBPbGQ6ICAgeyJhIjp7ImIiOnsiYyI6eyJkIjp7ImUiOnsibmFtZSI6IkFsaWNlIn19 fX19fQ0KICAgIFBhdGNoOiBbeyJvcCI6InRyZWUiLCAicGF0aCI6Ii9hL2IvYy9kL2UiLCAib3Bz IjpbDQogICAgICAgICAgICAgIHsib3AiOiJhZGQiLCAicGF0aCI6Ii9hZ2UiLCAidmFsdWUiOjIw fSwNCiAgICAgICAgICAgICAgeyJvcCI6ImFkZCIsICJwYXRoIjoiL2VtYWlsIiwgInZhbHVlIjoi YUBlZy5jb20ifV19XQ0KICAgIE5ldzogICB7ImEiOnsiYiI6eyJjIjp7ImQiOnsiZSI6ew0KICAg ICAgICAgICAgIm5hbWUiOiJBbGljZSIsICJhZ2UiOjIwLCAiZW1haWwiOiJhQGVnLmNvbSJ9fX19 fX0NCg0KLS0NCkphbWVzIE1hbmdlcg0K