From fgaliegue@gmail.com Tue Jan 1 02:05:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A1F21F86D9 for ; Tue, 1 Jan 2013 02:05:25 -0800 (PST) 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 yDwQOybyohC4 for ; Tue, 1 Jan 2013 02:05:24 -0800 (PST) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by ietfa.amsl.com (Postfix) with ESMTP id 640D721F8480 for ; Tue, 1 Jan 2013 02:05:24 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id uo13so11873568obb.8 for ; Tue, 01 Jan 2013 02:05:24 -0800 (PST) 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=TrBoMAa6eNsFIoJWKCOoxHH5fQujtyvpaRm5qOVwcsg=; b=Nct6JGQwn+bzF27HNduJ6VgmEIiOKk1urVYUSYlHVfOjD72Qfols0De8f2UJUcKzAW 7+EYoqGqo/20uWiH1zZECwvx5RYsC+zIIS8ed0eW6GvyY5N0fAC/rAGtk4gpD1h6LSb8 kmnAHtmc2EG5zbGsHha4J6kMRRxkGErAyVDzJo/Ua/ORcXVtpb00dZ+OztNj1Nm3Wpkc DMOyqG0rL+OaraqQEg54IPRObiqg5pJAw1xt/C+MD48BZi7hrgEJm3QqAjY1tynE5cFi pngh7XUzf+35O9gSmENSMkuSKK9oTApSf7dqGOO2jFefooZOthuM5Uh5g0fsXqG0NB8A 4sdg== MIME-Version: 1.0 Received: by 10.182.164.103 with SMTP id yp7mr35862559obb.74.1357034723905; Tue, 01 Jan 2013 02:05:23 -0800 (PST) Received: by 10.60.13.231 with HTTP; Tue, 1 Jan 2013 02:05:23 -0800 (PST) In-Reply-To: <950C0B01-E28E-4604-BFE2-05AB48CCDAC8@tzi.org> References: <40FE4BA4-2505-400E-9FC6-61A73939C5B3@mnot.net> <3bksd81m0ake6cd0n3jrjb3v0hcgfonpl8@hive.bjoern.hoehrmann.de> <950C0B01-E28E-4604-BFE2-05AB48CCDAC8@tzi.org> Date: Tue, 1 Jan 2013 11:05:23 +0100 Message-ID: From: Francis Galiegue To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss , Mark Nottingham , Bjoern Hoehrmann Subject: Re: [apps-discuss] json-pointer: "characters that represent an unsigned base-10 integer value" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jan 2013 10:05:25 -0000 On Mon, Dec 31, 2012 at 4:44 PM, Carsten Bormann wrote: > On Dec 31, 2012, at 16:35, James M Snell wrote: > >> 1+DIGIT with a statement that leading zeros SHOULD not be used and MUST= be ignored if they are present when evaluating an array > > No, make that "MUST NOT be sent", "MUST be handled as an error" *). > The other way is the recipe for soup. > It is legal in a JSON Object to have a member with name "01", so forbidding this as a reference token makes such members effectively unaccessible. -- 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 cabo@tzi.org Tue Jan 1 02:52:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1417221F88E0 for ; Tue, 1 Jan 2013 02:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.291 X-Spam-Level: X-Spam-Status: No, score=-106.291 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 dGVkA8CgDq2F for ; Tue, 1 Jan 2013 02:52:24 -0800 (PST) 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 4FC5821F8804 for ; Tue, 1 Jan 2013 02:52:23 -0800 (PST) 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 r01AqF3r025279; Tue, 1 Jan 2013 11:52:17 +0100 (CET) Received: from [192.168.217.105] (p54894753.dip.t-dialin.net [84.137.71.83]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3894D999; Tue, 1 Jan 2013 11:52:15 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 1 Jan 2013 11:52:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <40FE4BA4-2505-400E-9FC6-61A73939C5B3@mnot.net> <3bksd81m0ake6cd0n3jrjb3v0hcgfonpl8@hive.bjoern.hoehrmann.de> <950C0B01-E28E-4604-BFE2-05AB48CCDAC8@tzi.org> To: Francis Galiegue X-Mailer: Apple Mail (2.1499) Cc: Apps Discuss , Mark Nottingham , Bjoern Hoehrmann Subject: Re: [apps-discuss] json-pointer: "characters that represent an unsigned base-10 integer value" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jan 2013 10:52:25 -0000 On Jan 1, 2013, at 11:05, Francis Galiegue wrote: > It is legal in a JSON Object to have a member with name "01", so > forbidding this as a reference token makes such members effectively > unaccessible. That is, of course, correct. JSON (RFC 4627) makes a difference between arrays and objects (i.e., an = array is not an object). JavaScript, of course, doesn't. So in a JavaScript array, you might = have additional members with keys such as "foo" or the "01" above. I just don't think these serialize into JSON arrays*). So my point was that, if you are talking about JSON arrays, the key "01" = is bad, and it MUST NOT occur in a JSON pointer for this purpose. Side note: More generally speaking, I'm a bit unhappy with the current = spec language o If the currently referenced value is a JSON object, [...] o If the currently referenced value is a JSON array, [...] because in JavaScript, I'm sometimes not so sure. That's one reason why I'd prefer the rules to work fine in an = implementation that doesn't make that distinction as much. (The other one is that I prefer to avoid soup.) (In an implementation that doesn't quite know whether it is looking at = an array, there is still a problem with the key "-".) Gr=FC=DFe, Carsten *) try this: my_object =3D ["bar"] my_object[1] =3D "foo" my_object["01"] =3D "baz" and then serialize my_object (and, look at my_object["01"] and = keys(my_object) to verify correct behavior). From mmorley@mpcm.com Tue Jan 1 10:47:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF1721F86DD for ; Tue, 1 Jan 2013 10:47:08 -0800 (PST) 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 lmyU6zQIG+sR for ; Tue, 1 Jan 2013 10:47:07 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECCB21F86CD for ; Tue, 1 Jan 2013 10:47:07 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id fr10so5174644lab.17 for ; Tue, 01 Jan 2013 10:47:06 -0800 (PST) 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=XBqUTBtCrNiW/JW7qmsMwMyboa2tdfMLN0L8WvwlmHI=; b=H7kDemcNll9qZYIJLPwHvG7FE40ckBaqyjX2hyR9LmHQ0yz+bMtu/8CPzpvCveEcy7 cPRc4Hfu0NsA0pN9jp0vdsWrDNCzEW2a1A89Kxt3jQPX336Tfis/XMEatrqRIWGXtJgL VNkoiK08RYK/nTR8FYzfnBsL7nDCk7A4GQQs8Wk/QHOW/R+rgKM1QJ+08ajSW6F9OR6J mPTSH4TljrT0pe9o/kuesjAGMS2IC7usRcIcDCtOGxymQ49d480XWNr72Bt01NV+EdEa /ZIkVnIuRo0SFR32/aB4HtRfXq4Nt3lpCu3TjiBy6PKrz4q5y2/gYySYKWEpKSdEXRKY aUoQ== MIME-Version: 1.0 Received: by 10.152.110.229 with SMTP id id5mr41792468lab.36.1357066026042; Tue, 01 Jan 2013 10:47:06 -0800 (PST) Sender: mmorley@mpcm.com Received: by 10.114.38.137 with HTTP; Tue, 1 Jan 2013 10:47:05 -0800 (PST) In-Reply-To: References: <40FE4BA4-2505-400E-9FC6-61A73939C5B3@mnot.net> <3bksd81m0ake6cd0n3jrjb3v0hcgfonpl8@hive.bjoern.hoehrmann.de> <950C0B01-E28E-4604-BFE2-05AB48CCDAC8@tzi.org> Date: Tue, 1 Jan 2013 13:47:05 -0500 X-Google-Sender-Auth: 6crUFLO49JZifnApPYx54c0MjZc Message-ID: From: Matthew Morley To: Carsten Bormann Content-Type: multipart/alternative; boundary=f46d040713e36b470d04d23e8e1b X-Gm-Message-State: ALoCoQn0yrjgxGWlRZF6o7FYSfWjObKO35loRkMVfUr09tKx9pxi3eAZCiZgAwE3treKMpvMdTOj Cc: Apps Discuss , Mark Nottingham , Bjoern Hoehrmann Subject: Re: [apps-discuss] json-pointer: "characters that represent an unsigned base-10 integer value" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jan 2013 18:47:08 -0000 --f46d040713e36b470d04d23e8e1b Content-Type: text/plain; charset=ISO-8859-1 . On Mon, Dec 31, 2012 at 10:15 PM, Matthew Morley wrote: > On Mon, Dec 31, 2012 at 10:44 AM, Carsten Bormann wrote: > >> On Dec 31, 2012, at 16:35, James M Snell wrote: >> >> > 1+DIGIT with a statement that leading zeros SHOULD not be used and >> MUST be ignored if they are present when evaluating an array >> >> No, make that "MUST NOT be sent", "MUST be handled as an error" *). >> The other way is the recipe for soup. >> >> > Stricter wording makes the most sense to me. The behavior should be one of > non-resolution in the context of an array, which should translate into > either errors or failure. > I wanted to clarify, that I agree with the "MUST be handled as an error" part only. 1e0 or 1.000 should be allowed as part of the json pointer string, due to being a potentially valid keys inside an object. -- Matt --f46d040713e36b470d04d23e8e1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable .

On Mon, Dec 31, 2012 at 10:15 PM, Matth= ew Morley <matt@mpcm.com> wrote:
On Mon, Dec 31, 2012 at 10:44 AM, Carsten Bormann <cabo@tzi.o= rg> wrote:
On Dec 31, 2012, at 16:35, James M Snell <jasnell@gmail.com> wrote:

> =A01+DIGIT with a statement that leading zeros SHOULD not be used and = MUST be ignored if they are present when evaluating an array

No, make that "MUST NOT be sent", "MUST be handled as = an error" *).
The other way is the recipe for soup.


Stricter wording makes the most = sense to me. The behavior should be one of non-resolution in the context of= an array, which should translate into either errors or failure.

I wanted to clarify, that I ag= ree with the "MUST be handled as an error" part only. 1e0 or 1.00= 0 should be allowed as part of the json pointer string, due to being a pote= ntially valid keys inside an object.

--
Matt --f46d040713e36b470d04d23e8e1b-- From Claudio.Allocchio@garr.it Wed Jan 2 00:35:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6272321F8D33 for ; Wed, 2 Jan 2013 00:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.211 X-Spam-Level: X-Spam-Status: No, score=0.211 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-K4NuHy1zj6 for ; Wed, 2 Jan 2013 00:35:36 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACFD21F8C51 for ; Wed, 2 Jan 2013 00:35:35 -0800 (PST) Received: internal info suppressed Date: Sun, 30 Dec 2012 23:23:20 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: S Moonesamy In-Reply-To: <6.2.5.6.2.20121230123316.0a344b68@elandnews.com> Message-ID: References: <6.2.5.6.2.20121230123316.0a344b68@elandnews.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1356906201; bh=dc9bOmChzZPH5Fi1tOpnI+Fmnl7ppyt4P4R8LytZ7Z8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Uzt72cHu4cwMt1yzOQbru56hb7jQAcMo+gYoKtaXWYT+eY9BDN2tedyCpqUHLOb8v GCICP0c2Fnt4JNe36YjOZhQtghlWUnQkJjhOmF4omS85RXnE7PTwMlDjNklsNzJXRo JdEluOjTINxM83XyGacTG1X7dVKG50KFF3iWGXts= Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Apps Area Directorate report for December 2012 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jan 2013 08:35:37 -0000 ... and now... time for a New Year! May 2013 be so rich of new ideas as 2012 was ... Lot of work for the Apps Area Directorate menas a lot of lively ideas coming across! :-) all the best!! Enjoy! ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From internet-drafts@ietf.org Thu Jan 3 19:52:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B5121F8E30; Thu, 3 Jan 2013 19:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.315 X-Spam-Level: X-Spam-Status: No, score=-102.315 tagged_above=-999 required=5 tests=[AWL=0.284, 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 z7FNxdMXHJzQ; Thu, 3 Jan 2013 19:52:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3288D21F8E3E; Thu, 3 Jan 2013 19:52:51 -0800 (PST) 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.37 Message-ID: <20130104035251.12248.32117.idtracker@ietfa.amsl.com> Date: Thu, 03 Jan 2013 19:52:51 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-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: Fri, 04 Jan 2013 03:52:51 -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 : JavaScript Object Notation (JSON) Pointer Author(s) : Paul C. Bryan Kris Zyp Mark Nottingham Filename : draft-ietf-appsawg-json-pointer-08.txt Pages : 8 Date : 2013-01-03 Abstract: JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-pointer-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Jan 3 19:56:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F8E21F8CB1; Thu, 3 Jan 2013 19:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 vzRMbAEsw4HN; Thu, 3 Jan 2013 19:56:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FA921F8CBF; Thu, 3 Jan 2013 19:56:45 -0800 (PST) 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.37 Message-ID: <20130104035645.14550.34061.idtracker@ietfa.amsl.com> Date: Thu, 03 Jan 2013 19:56:45 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-09.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, 04 Jan 2013 03:56:46 -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-09.txt Pages : 17 Date : 2013-01-03 Abstract: JSON Patch defines the media type "application/json-patch", a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation (JSON) document, suitable for use with the HTTP PATCH method. 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-patch-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Martin.Huelsemann@telekom.de Fri Jan 4 04:04:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66ADB21F854D; Fri, 4 Jan 2013 04:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 HOvIjJ-jqjGH; Fri, 4 Jan 2013 04:04:45 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id E552721F8546; Fri, 4 Jan 2013 04:04:43 -0800 (PST) Received: from he113415.emea1.cds.t-internal.com ([10.125.65.81]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 04 Jan 2013 13:04:41 +0100 Received: from HE111543.emea1.cds.t-internal.com ([10.125.90.96]) by HE113415.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 4 Jan 2013 13:04:40 +0100 From: To: , , , Date: Fri, 4 Jan 2013 13:04:39 +0100 Thread-Topic: APPSDIR review of draft-ietf-bliss-call-completion-18 Thread-Index: Ac3jjRNSegTUCi0/TCGgztugjupcigG3dt9g Message-ID: <9762ACF04FA26B4388476841256BDE020119E20069BC@HE111543.emea1.cds.t-internal.com> References: <50DB3173.7040206@ericsson.com> In-Reply-To: <50DB3173.7040206@ericsson.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_9762ACF04FA26B4388476841256BDE020119E20069BCHE111543eme_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 04 Jan 2013 08:10:14 -0800 Cc: worley@ariadne.com, R.Jesske@telekom.de Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-bliss-call-completion-18 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jan 2013 12:04:47 -0000 --_000_9762ACF04FA26B4388476841256BDE020119E20069BCHE111543eme_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Salvatore, thanks for checking the draft. Issue 'how is the m parameter provided': will be changed accordingly. Issue 'security considerations for no reply / not logged in indication': in= formation about these states are conveyed indirectly by accepting SUBSCRIBE= s or CC INVITEs with this purpose, but only in the latter use case this rea= lly allows conclusions on the current state of the callee. Even though it is mentioned in the first bullet in the list in section 11th= at there should be a temporal relation between selection for CC and the CC = call, I agree it would be good to clarify the besides information on busy/n= ot busy also information on what causes busy/not busy is revealed, and to c= larify that these 2 aspects have the same security implications. Thanks for your support. Regards, Martin ________________________________ Von: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] Gesendet: Mittwoch, 26. Dezember 2012 18:19 An: apps-discuss@ietf.org; draft-ietf-bliss-call-completion@tools.ietf.org;= The IESG Betreff: APPSDIR review of draft-ietf-bliss-call-completion-18 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-bonica-special-purpose-04 Title: Call Completion for Session Initiation Protocol (SIP) Reviewer: Salvatore Loreto Review Date: Dec 26th 2012 Summary: This draft is ready for publication. Major Issues: none. Minor Issues: (1) Section 4.1, in the second to last paragraph In a more restricted system, this determination can depend on the mode of the CC call in question, which is provided by the 'm' parameter. It would be better specify what 'm' parameter you are referring, I guess it= is the URI 'm' parameter so s/which is provided by the 'm' parameter/whi= ch is provided by the URI 'm' parameter (2) Section 11. Security considerat= ions. The information is confined to a busy/not-busy indication, and in leg= itimate use, will be subscribed to stereotyped ways that limit the disclosu= re of status information: that is not completely true, as it can also convey indications about 'No Re= ply' or 'Not Logged-in'. The sections does not say anything if there are di= fferent security implications related to those two different indications. = Nits: none Best Regards, -- Salvatore Loreto, PhD www.sloreto.com --_000_9762ACF04FA26B4388476841256BDE020119E20069BCHE111543eme_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Salvatore,
 
thanks for checking the draft.
 
Issue 'how is the m parameter provided': will be= =20 changed accordingly.
 
Issue 'security considerations for no reply / no= t=20 logged in indication': information about these states are conveyed indirect= ly by=20 accepting SUBSCRIBEs or CC INVITEs with this purpose, but only in the latte= r use=20 case this really allows conclusions on the current state of the=20 callee. 
Even though it is mentioned in the first bu= llet in=20 the list in section 11that there should be a temporal relation between sele= ction=20 for CC and the CC call, I agree it would be good to clarify the besides=20 information on busy/not busy also information on what causes busy/not busy = is=20 revealed, and to clarify that these 2 aspects have the same security=20 implications.
 
Thanks for your support.
 
Regards, Martin
 
 
 
 

Von: Salvatore Loreto=20 [mailto:salvatore.loreto@ericsson.com]
Gesendet: Mittwoch, 26.= =20 Dezember 2012 18:19
An: apps-discuss@ietf.org;=20 draft-ietf-bliss-call-completion@tools.ietf.org; The IESG
Betreff:<= /B>=20 APPSDIR review of draft-ietf-bliss-call-completion-18

I have been selected as the Applications Area D=
irectorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/ap=
p/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:   draft-bonica-special-purpose-04
Title: Call Completion for Session Initiation Protocol (SIP)
Reviewer:  Salvatore Loreto
Review Date:  Dec 26th 2012


Summary:

This draft is ready for publication.

Major Issues:

none.

Minor Issues:

(1)
Section 4.1, in the second to last paragraph

   In a more restricted system, this determination can depend
   on the mode of the CC call in question, which is provided by the 'm'
   parameter.

It would be better specify what 'm' parameter you are referring,
I guess it is the URI 'm' parameter so
 
s/which is provided by the 'm' parameter/which is provided by the URI 'm' p=
arameter


(2)
Section 11. Security considerations.

   The information is
   confined to a busy/not-busy indication, and in legitimate use, will
   be subscribed to stereotyped ways that limit the disclosure of status
   information:

that is not completely true, as it can also convey indications about 'No Re=
ply'
or 'Not Logged-in'.
The sections does not say anything if there are different security implicat=
ions
related to those two different indications.


 Nits:

none

Best Regards,

--=20
Salvatore Loreto, PhD
www.slo=
reto.com


--_000_9762ACF04FA26B4388476841256BDE020119E20069BCHE111543eme_--

From zfang@qualcomm.com  Fri Jan  4 15:27:30 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D71A21F86F8 for ; Fri,  4 Jan 2013 15:27:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 D+VPQm-eqWyF for ; Fri,  4 Jan 2013 15:27:30 -0800 (PST)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 594C421F8696 for ; Fri,  4 Jan 2013 15:27:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1357340958; x=1388876958; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version:x-ironport-av; bh=wphN+oPmz0TsybMZk4EdEKV80nFg5XSTQPG0pTfl+vQ=; b=tPkcDyOyWO8HqAL6VdDszfo5FZe8QDVFW85JXYniEGtv7sy2Rl1k+FNd +OeyYC6ryK3G3UIEkDLtWJiZ6xLwok6xCTCyxAbtg0UNiPo39sC+7QKxp qrZmTCTSGjtlTe3CZioQUC42FKVLJ4rpETbHCIRa7Akrq4F7gULIEiJ6x o=;
X-IronPort-AV: E=Sophos;i="4.84,412,1355126400"; d="scan'208";a="14642686"
Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 04 Jan 2013 15:09:17 -0800
Received: from nasanexhc16.na.qualcomm.com ([129.46.52.216]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Jan 2013 15:27:26 -0800
Received: from NASANEXD01A.na.qualcomm.com ([169.254.1.229]) by nasanexhc16.na.qualcomm.com ([129.46.52.216]) with mapi id 14.02.0318.004; Fri, 4 Jan 2013 15:27:25 -0800
From: "Fang, Zheng" 
To: Claudio Allocchio , "apps-discuss@ietf.org" , "draft-ietf-avt-rtp-evrc-nw.all@tools.ietf.org" 
Thread-Topic: APPSDIR review of draft-ietf-avt-rtp-evrc-nw-09
Thread-Index: AQHN3fk326A+TL4slkCNNBfqXiKT5Jg56FBA
Date: Fri, 4 Jan 2013 23:27:25 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.30.39.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Mailman-Approved-At: Sat, 05 Jan 2013 09:23:04 -0800
Cc: "iesg.ietf.org@cyrus.dir.garr.it" , "Sinder, Dan" 
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-avt-rtp-evrc-nw-09
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 04 Jan 2013 23:27:30 -0000

SGkgQ2xhdWRpbywNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3IGZlZWRiYWNrLiAgVGhlICJ3aWRl
YmFuZCIgYW5kICJuYXJyb3diYW5kIiBkZW5vdGUgdGhlIGF1ZGlvIGJhbmR3aWR0aCBvciBzYW1w
bGluZyByYXRlLiBUaGUgYXVkaW8gc2FtcGxpbmcgcmF0ZXMgb2YgMTZrSHogYW5kIDhrSHogYXJl
IG1lbnRpb25lZCBpbiB0aGUgMm5kIHBhcmFncmFwaCBpbiBTZWN0aW9uIDMuIEkgY2FuIG1ha2Ug
aXQgbW9yZSBleHBsaWNpdCBieSBhZGRpbmcgY2hhbmdlcyBhcyBpbiBiZWxvdyAoYWRkZWQgY2hh
bmdlcyBhcmUgaW4gdGhlIGJyYWNrZXRzKS4NCg0KVGhlIEVWUkMtTlcgY29kZWMgb3BlcmF0ZXMg
b24gMjAgbXMgZnJhbWVzLCBhbmQgdGhlIGRlZmF1bHQgc2FtcGxpbmcgICByYXRlIGlzIDE2IGtI
eiAod2lkZWJhbmQpLiAgSW5wdXQgYW5kIG91dHB1dCBhdCA4IGtIeiBzYW1wbGluZyByYXRlIChu
YXJyb3diYW5kKSBpcyBhbHNvICBzdXBwb3J0ZWQuDQoNCkRvZXMgdGhpcyBjaGFuZ2UgbG9vayBP
Sz8NCg0KLVpoZW5nDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDbGF1ZGlv
IEFsbG9jY2hpbyBbbWFpbHRvOkNsYXVkaW8uQWxsb2NjaGlvQGdhcnIuaXRdIA0KU2VudDogV2Vk
bmVzZGF5LCBEZWNlbWJlciAxOSwgMjAxMiA2OjU3IEFNDQpUbzogYXBwcy1kaXNjdXNzQGlldGYu
b3JnOyBkcmFmdC1pZXRmLWF2dC1ydHAtZXZyYy1udy5hbGxAdG9vbHMuaWV0Zi5vcmcNCkNjOiBp
ZXNnLmlldGYub3JnQGN5cnVzLmRpci5nYXJyLml0DQpTdWJqZWN0OiBBUFBTRElSIHJldmlldyBv
ZiBkcmFmdC1pZXRmLWF2dC1ydHAtZXZyYy1udy0wOQ0KDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVk
IGFzIHRoZSBBcHBsaWNhdGlvbnMgQXJlYSBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBk
cmFmdCAoZm9yIGJhY2tncm91bmQgb24gYXBwc2RpciwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJh
Yy50b29scy5pZXRmLm9yZy9hcmVhL2FwcC90cmFjL3dpa2kvQXBwbGljYXRpb25zQXJlYURpcmVj
dG9yYXRlDQopLiBJIGNvbnNpZGVyZWQgdmVyc2lvbiAwOS4NCg0KUGxlYXNlIHJlc29sdmUgdGhl
c2UgY29tbWVudHMgYWxvbmcgd2l0aCBhbnkgb3RoZXIgTGFzdCBDYWxsIGNvbW1lbnRzIHlvdSBt
YXkgcmVjZWl2ZS4gUGxlYXNlIHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQg
c2hlcGhlcmQgb3IgQUQgYmVmb3JlIHBvc3RpbmcgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQu
DQoNCkRvY3VtZW50OiAgIGRyYWZ0LWlldGYtYXZ0LXJ0cC1ldnJjLW53LTA5DQpUaXRsZTogUlRQ
IHBheWxvYWQgZm9ybWF0IGZvciBFbmhhbmNlZCBWYXJpYWJsZSBSYXRlIE5hcnJvd2JhbmQtV2lk
ZWJhbmQNCiAgICAgICAgQ29kZWMNClJldmlld2VyOiAgQ2xhdWRpbyBBbGxvY2NoaW8NClJldmll
dyBEYXRlOiAgRGVjIDE5dGggMjAxMg0KSUVURiBMYXN0IENhbGwgRGF0ZToNCklFU0cgVGVsZWNo
YXQgRGF0ZTogMjAxMi0xMi0yMA0KDQpTdW1tYXJ5Og0KDQp0aGUgZHJhZnQgc2VlbXMgcmVhZHkg
Zm9yIHB1YmxpY2F0aW9uIGFuZCByZXF1aXJlcyBJQU5BIHJlZ2lzdHJhdGlvbnMuIEkgZG8gbm90
IHNlZSBhbnkgbWFqb3IgcHJvYmxlbSBpbiB0aGUgc3BlY2lmaWNhdGlvbi4NCg0KTWFqb3IgSXNz
dWVzOg0KDQpub25lLg0KDQpNaW5vciBJc3N1ZXM6DQoNCkFzIGp1c3QgYW4gZWRpdG9yaWFsIHN1
Z2dzdGlvbiwgSSdkIGp1c3QgYWRkIGFuIGV4YW1wbGUgaW4gdGhlIHRleHQgb2Ygd2hhdCB3ZSBp
bnRlbmQgd2hlbiB3ZSB0YWxrIG9mICJuYXJyb3diYW5kIiBhbmQgIndpZGViYW5kIiANCnNpdHVh
dGlvbnMuIEFuIGV4YW1wbGUgd2l0aCAibnVtYmVycyIgaW4gaXQuIEUuRy4gd2UgY29uc2lkZXIg
Im5hcnJvd2JhbmQiIA0Kd2hlbiB0aGUgTWJwcyByYXRlIGlzIGJlbG93IFhYWCwgIndpZGViYW5k
IiBvdGhlcndpc2UuDQoNCk5pdHM6DQoNCm5vbmUuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
Q2xhdWRpbyBBbGxvY2NoaW8gICAgICAgICAgICAgRyAgIEEgICBSICAgUiAgICAgICAgICBDbGF1
ZGlvLkFsbG9jY2hpb0BnYXJyLml0DQogICAgICAgICAgICAgICAgICAgICAgICAgU2VuaW9yIFRl
Y2huaWNhbCBPZmZpY2VyDQp0ZWw6ICszOSAwNDAgMzc1ODUyMyAgICAgIEl0YWxpYW4gQWNhZGVt
aWMgYW5kICAgICAgIEc9Q2xhdWRpbzsgUz1BbGxvY2NoaW87DQpmYXg6ICszOSAwNDAgMzc1ODU2
NSAgICAgICAgUmVzZWFyY2ggTmV0d29yayAgICAgICAgIFA9Z2FycjsgQT1nYXJyOyBDPWl0Ow0K
DQogICAgICAgICAgICBQR1AgS2V5OiBodHRwOi8vd3d3LmNlcnQuZ2Fyci5pdC9QR1Ava2V5cy5w
aHAzI2NhDQo=

From Claudio.Allocchio@garr.it  Sat Jan  5 15:04:36 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A2B21F8554 for ; Sat,  5 Jan 2013 15:04:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGhZlj1h5zVb for ; Sat,  5 Jan 2013 15:04:35 -0800 (PST)
Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 1972521F8551 for ; Sat,  5 Jan 2013 15:04:34 -0800 (PST)
Received: internal info suppressed
Date: Sun, 6 Jan 2013 00:04:17 +0100 (CET)
From: Claudio Allocchio 
X-X-Sender: claudio@mac-allocchio3.local
To: "Fang, Zheng" 
In-Reply-To: 
Message-ID: 
References:  
User-Agent: Alpine 2.02 (OSX 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-993324371-1357427063=:13361"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1357427071; bh=eAVHtPNjxKTM1IcYud3lwxnS25jVdBSbd97UVRFCcPQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=nyHrMv1OSA3jd04F6eNxQKhvE1lSNudUZwX8HaxgVMalTppExIVbyRD2r3snmicjd RRkrj1kuwc8j+EWeacqdR1AvnrQhUksIBISC4mcKYpdz/cG2oKpj1utNsj+yZQqvwh h2i2V3nY7iN1+mvhzKpZpuwCygan1PQoWfbA6lNQ=
Cc: "draft-ietf-avt-rtp-evrc-nw.all@tools.ietf.org" , "Sinder, Dan" , "iesg.ietf.org@cyrus.dir.garr.it" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-avt-rtp-evrc-nw-09
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 05 Jan 2013 23:04:36 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-993324371-1357427063=:13361
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Fri, 4 Jan 2013, Fang, Zheng wrote:

> Hi Claudio,
>
> Thanks for the review feedback.  The "wideband" and "narrowband" denote the audio bandwidth or sampling rate. The audio sampling rates of 16kHz and 8kHz are mentioned in the 2nd paragraph in Section 3. I can make it more explicit by adding changes as in below (added changes are in the brackets).
>
> The EVRC-NW codec operates on 20 ms frames, and the default sampling   rate is 16 kHz (wideband).  Input and output at 8 kHz sampling rate (narrowband) is also  supported.
>
> Does this change look OK?

yes!  :-)

please do so!

thanks again!

>
> -Zheng
>
> -----Original Message-----
> From: Claudio Allocchio [mailto:Claudio.Allocchio@garr.it]
> Sent: Wednesday, December 19, 2012 6:57 AM
> To: apps-discuss@ietf.org; draft-ietf-avt-rtp-evrc-nw.all@tools.ietf.org
> Cc: iesg.ietf.org@cyrus.dir.garr.it
> Subject: APPSDIR review of draft-ietf-avt-rtp-evrc-nw-09
>
>
> I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
> ). I considered version 09.
>
> Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.
>
> Document:   draft-ietf-avt-rtp-evrc-nw-09
> Title: RTP payload format for Enhanced Variable Rate Narrowband-Wideband
>        Codec
> Reviewer:  Claudio Allocchio
> Review Date:  Dec 19th 2012
> IETF Last Call Date:
> IESG Telechat Date: 2012-12-20
>
> Summary:
>
> the draft seems ready for publication and requires IANA registrations. I do not see any major problem in the specification.
>
> Major Issues:
>
> none.
>
> Minor Issues:
>
> As just an editorial suggstion, I'd just add an example in the text of what we intend when we talk of "narrowband" and "wideband"
> situations. An example with "numbers" in it. E.G. we consider "narrowband"
> when the Mbps rate is below XXX, "wideband" otherwise.
>
> Nits:
>
> none.
>
> ------------------------------------------------------------------------------
> Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
>                         Senior Technical Officer
> tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
> fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;
>
>            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca
--0-993324371-1357427063=:13361--

From sayrer@gmail.com  Sat Jan  5 16:19:06 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C4821F85CC; Sat,  5 Jan 2013 16:19:06 -0800 (PST)
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 gmxHkQx7R+OC; Sat,  5 Jan 2013 16:19:05 -0800 (PST)
Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6672121F8583; Sat,  5 Jan 2013 16:19:04 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id gg4so8355552wgb.6 for ; Sat, 05 Jan 2013 16:19:03 -0800 (PST)
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=HVAx443GPdwtmDGTz6qFnYEBfwUvdzwqj5kBQd02Pok=; b=QgkEu8+UVYFZhoOp/hE4Ggvf+YdtCiMyJKtgcFApyHAFXvuZX+yRzv3oqIW8EeNeR8 waJPt5v/N8n4Ebz1Di9eRe0EHNS69GcVlcW6OWexHYzvG2TDJHt5XdlaDy/40ClCGHhk ++idcD+5ktH2sxwt94ngVbMzI7uGq3toPVdxWQelkRgzQWu0D4CoklAmvTd6T/ZoxggC eyCGVzpANeEQzTbTqi7IM1ZBv12d0GDIkNFDKMWpq+8mr5lAoSqGjKSyigaUV2kQ9Pfi pR5jPD8F+/oN55vrgHPAWHY9ZfKlh8h4D10+EWjuZZUEV2XRvsslMRtG6XrJyQCsNG0Q gOxQ==
MIME-Version: 1.0
Received: by 10.194.23.37 with SMTP id j5mr89600518wjf.28.1357431543500; Sat, 05 Jan 2013 16:19:03 -0800 (PST)
Received: by 10.194.1.101 with HTTP; Sat, 5 Jan 2013 16:19:03 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>     
Date: Sat, 5 Jan 2013 16:19:03 -0800
Message-ID: 
From: Robert Sayre 
To: Mark Nottingham 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Sun, 06 Jan 2013 00:19:06 -0000

Mark,

The WG's reasoning, as stated in your message below, seems flawed.
Messages since your last communication on this matter have shown:

1) The ambiguity around arrays makes the patch format unsuitable for
common concurrent editing algorithms.
2) The ambiguity is likely to occur in the real world, for a couple of
different reasons.
3) It's not possible to tell whether a JSON Pointer document is
syntactically correct in isolation.

Additionally, you raised this point in your message below:
>
> the patch author already has to understand the semantics of the document =
they're patching

That claim does not seem to be well-justified, and it could be
meaningless to the person implementing patch software (for example:
https://github.com/sayrer/json-sync).

This issue is a problem in practice, and it's a problem in theory as
well. JSON-Patch messages aren't sufficiently self-descriptive, so
they aren't appropriate for use in a RESTful system.

A response containing technical reasoning seems in order, since the
points raised by myself and others on this issue are unrelated to the
WG's previous thinking.

- Rob

On Sun, Dec 16, 2012 at 9:41 PM, Mark Nottingham  wrote:
> Robert,
>
> This was discussed extensively in the Working Group.
>
> The root of the issue was that some people reflexively felt that this was=
 necessary, but upon reflection, we decided it wasn't; although it seems "n=
atural" to some, especially those coming from a static language background,=
 it didn't provide any utility.
>
> You might argue that someone who (for example) adds to "/foo/1" in the mi=
staken belief that it's an array, when in fact it's an object, will get sur=
prising results. That's true, but if we were to solve this problem, that pe=
rson would still need to understand the underlying semantics of "foo" to do=
 anything useful to it -- and I'm not hearing anyone complain about that (I=
 hope).
>
> Put another way -- do you really think that people PATCHing something as =
if it's an array (when in fact it's an object) is a significant, real-world=
 problem, given that the patch author already has to understand the semanti=
cs of the document they're patching? I don't, and the WG didn't either.
>
> Regards,
>
>
> On 17/12/2012, at 3:36 PM, Robert Sayre  wrote:
>
>> The cost of fixing it seems low, either by changing the path syntax of
>> JSON pointer or changing the names of operations applied to arrays.
>> Array-like objects are common enough in JavaScript to make this a
>> worry. The other suggestions either assume a particular policy for
>> concurrent edits or require more machinery (test operation etc).
>> Wouldn't it be simpler to make the patch format more precise?
>>
>> - Rob
>>
>> On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley  wrote:
>>> I am usually lurking and struggling to keep up with these posts. But, I
>>> concur with James, this really is a non-issue in practice.
>>>
>>> The JSON Pointer expresses a path down a JSON object to a specific cont=
ext.
>>> The Patch expresses a change within or to that context.
>>> Everything about the both standards is about that end context.
>>>
>>> If you want to confirm the type of the context before applying a patch,=
 this
>>> should probably be part of a test operation. I'm not sure if this is
>>> possible at this point (?), but that is where the logic should exist.
>>>
>>>
>>>
>>> On Sun, Dec 16, 2012 at 12:22 AM, James M Snell  wro=
te:
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre  wrote=
:
>>>>>
>>>>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler
>>>>>  wrote:
>>>>>>
>>>>>> Hmm.. I think that=92s quite problematic. Especially considering how=
 JSON
>>>>>> Pointer is used in JSON Patch.
>>>>>
>>>>> I agree--I provided the same feedback privately. It seems
>>>>> straightforwardly unsound.
>>>>>
>>>>
>>>> In practice it doesn't seem to be much of an issue.
>>>>
>>>> Specifically, if I GET an existing document and get an etag with the J=
SON,
>>>> then make some changes and send a PATCH with If-Match, the fact that a=
ny
>>>> given pointer could point to an array or object member doesn't really =
matter
>>>> much.
>>>>
>>>> For example:
>>>>
>>>>> GET /the/doc HTTP/1.1
>>>>
>>>>  <  HTTP/1.1 200 OK
>>>>     ETag: "my-document-tag"
>>>>     Content-Type: application/json
>>>>
>>>>     {"1":"foo"}
>>>>
>>>>> PATCH /the/doc HTTP/1.1
>>>>     If-Match: "my-document-etag"
>>>>     Content-Type: application/json-patch
>>>>
>>>>     [{"op":"add","path":"/2","value":"bar"}]
>>>>
>>>> Generally speaking, someone should not be using PATCH to perform a par=
tial
>>>> modification if they don't already have some knowledge in advance what=
 they
>>>> are modifying. The only time the apparent ambiguity becomes an issue i=
s when
>>>> a client is blindly sending a patch to an unknown endpoint... in which=
 case,
>>>> you get whatever you end up with.
>>>>
>>>> - James
>>>>
>>>>
>>>>>
>>>>> - Rob
>>>>>
>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Markus Lanthaler
>>>>>>
>>>>>> @markuslanthaler
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: James M Snell [mailto:jasnell@gmail.com]
>>>>>> Sent: Friday, December 14, 2012 5:41 PM
>>>>>> To: Markus Lanthaler
>>>>>> Cc: IETF Discussion; IETF Apps Discuss
>>>>>> Subject: Re: [apps-discuss] Last Call:
>>>>>>  (JSON Pointer) to Proposed =
Standard
>>>>>>
>>>>>>
>>>>>>
>>>>>> JSON Pointer does not distinguish between objects and arrays. That i=
s
>>>>>> not determined until the pointer is applied to an actual object inst=
ance...
>>>>>> the pointer "/1" is valid against {"1":"a"} or ["a","b"]
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler
>>>>>>  wrote:
>>>>>>
>>>>>> I've asked that before but didn't get an answer. So let me ask again
>>>>>> (even
>>>>>> though I'm quite sure it has already been asked by somebody else).
>>>>>>
>>>>>> How does JSON Pointer distinguish between objects and arrays? E.g.
>>>>>> consider
>>>>>> the following JSON document:
>>>>>>
>>>>>> {
>>>>>>  "foo": "bar",
>>>>>>  "1": "baz"
>>>>>> }
>>>>>>
>>>>>> As I read the draft, the JSON Pointer "/1" would evaluate to "baz" e=
ven
>>>>>> though that's probably not what the author intended. Is there a way =
to
>>>>>> avoid
>>>>>> that?
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Markus
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Markus Lanthaler
>>>>>> @markuslanthaler
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>>>>>>> bounces@ietf.org] On Behalf Of The IESG
>>>>>>> Sent: Tuesday, December 11, 2012 4:01 PM
>>>>>>> To: IETF-Announce
>>>>>>> Cc: apps-discuss@ietf.org
>>>>>>> Subject: [apps-discuss] Last Call: >>>>>> 07.txt> (JSON Pointer) to Proposed Standard
>>>>>>>
>>>>>>>
>>>>>>> The IESG has received a request from the Applications Area Working
>>>>>>> Group
>>>>>>> WG (appsawg) to consider the following document:
>>>>>>> - 'JSON Pointer'
>>>>>>>   as Proposed Standard
>>>>>>>
>>>>>>> The IESG plans to make a decision in the next few weeks, and solici=
ts
>>>>>>> final comments on this action. Please send substantive comments to
>>>>>>> the
>>>>>>> ietf@ietf.org mailing lists by 2012-12-25. 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.
>>>>>>>
>>>>>>> Abstract
>>>>>>>
>>>>>>>
>>>>>>>   JSON Pointer defines a string syntax for identifying a specific
>>>>>>> value
>>>>>>>   within a JSON document.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The file can be obtained via
>>>>>>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/
>>>>>>>
>>>>>>> IESG discussion can be tracked via
>>>>>>>
>>>>>>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/bal=
lot/
>>>>>>>
>>>>>>>
>>>>>>> No IPR declarations have been submitted directly on this I-D.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Matthew P. C. Morley
>> _______________________________________________
>> 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  Sat Jan  5 17:31:26 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB19A21F8514; Sat,  5 Jan 2013 17:31:26 -0800 (PST)
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 krnL8HJnp3Yj; Sat,  5 Jan 2013 17:31:25 -0800 (PST)
Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id DEAE421F8510; Sat,  5 Jan 2013 17:31:24 -0800 (PST)
Received: by mail-oa0-f53.google.com with SMTP id j6so16289220oag.26 for ; Sat, 05 Jan 2013 17:31:24 -0800 (PST)
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=R1QGDaBtObbigb7511+EgX674huTEsank8svzI2EHcg=; b=WstZq2KqGnlWv8DP8r2bDF8B2imaVg0KPR/k1bruL9z1xhbE+hqq7K9Usdgbm0U2zR H0bwLhvEcxDxCxynlh9OssrqnM3nyy4sJjTMBHRI44hQGRcQiH44PDrc76U2ZUc+J5M0 l9FHYOgSNOkMa8k9q6TIB3IEtbUYoL/KolnK4q98KSZkr98xw6yEe/kWCAJY2nCNslKa SVNl1rm+dG2dBcDhWX4jil9xybYt4Ya8942EfcNDTCqaflbQWDMS707yj0GvS0xupAhO kfOJXHKAbaNBRSQSeENlQ2K7xPt/v69ETje5GjnGfAJKFZ7bdVKEbj0WJLeBPuF9WAw7 41IA==
Received: by 10.182.0.68 with SMTP id 4mr42070525obc.80.1357435884336; Sat, 05 Jan 2013 17:31:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.86.9 with HTTP; Sat, 5 Jan 2013 17:31:04 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>      
From: James M Snell 
Date: Sat, 5 Jan 2013 17:31:04 -0800
Message-ID: 
To: Robert Sayre 
Content-Type: multipart/alternative; boundary=f46d043c7f88b0f73f04d294ab99
Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Sun, 06 Jan 2013 01:31:26 -0000

--f46d043c7f88b0f73f04d294ab99
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Robert,

I may have missed it, but can you provide a non-theoretical example of this
problem that you're suggesting exists in practice?

On Sat, Jan 5, 2013 at 4:19 PM, Robert Sayre  wrote:

> Mark,
>
> The WG's reasoning, as stated in your message below, seems flawed.
> Messages since your last communication on this matter have shown:
>
> 1) The ambiguity around arrays makes the patch format unsuitable for
> common concurrent editing algorithms.
>

Why? I'm still not seeing how it's unsuitable. Again, a non-theoretical
example would be helpful.



> 2) The ambiguity is likely to occur in the real world, for a couple of
> different reasons.
>

Such as? What are the reasons?


> 3) It's not possible to tell whether a JSON Pointer document is
> syntactically correct in isolation.
>

There is no such thing as a "JSON Pointer document" and I have absolutely
no idea what "syntactically correct in isolation" means with regards to
this problem you're suggesting. If I see "/a/b/1", that is a syntactically
correct JSON Pointer... whether or not it points to anything specific
depends entirely on the specific JSON structure it is applied to. If I had
to guess, you're saying that it's not possible to tell if "/a/b/01" is a
valid JSON Pointer or not given nothing but the pointer? If so, who cares
really? The JSON Pointer is not useful unless it's applied to an actual
JSON structure, it's only at that point that we really ought to care about
validity.

Still not seeing the problem.


>
> Additionally, you raised this point in your message below:
> >
> > the patch author already has to understand the semantics of the documen=
t
> they're patching
>
> That claim does not seem to be well-justified, and it could be
> meaningless to the person implementing patch software (for example:
> https://github.com/sayrer/json-sync).
>
> This issue is a problem in practice, and it's a problem in theory as
> well. JSON-Patch messages aren't sufficiently self-descriptive, so
> they aren't appropriate for use in a RESTful system.
>
>
What would be "sufficiently self-descriptive" ? Again, a non-theoretical
example and suggested alternative that we can compare would be helpful for
context.

It is possible that I missed a couple of posts on this over the holiday so
if you already provided an example, please do let me know and I'll go
hunting through the archives.

- James


> A response containing technical reasoning seems in order, since the
> points raised by myself and others on this issue are unrelated to the
> WG's previous thinking.



>
> - Rob
>
> On Sun, Dec 16, 2012 at 9:41 PM, Mark Nottingham  wrote:
> > Robert,
> >
> > This was discussed extensively in the Working Group.
> >
> > The root of the issue was that some people reflexively felt that this
> was necessary, but upon reflection, we decided it wasn't; although it see=
ms
> "natural" to some, especially those coming from a static language
> background, it didn't provide any utility.
> >
> > You might argue that someone who (for example) adds to "/foo/1" in the
> mistaken belief that it's an array, when in fact it's an object, will get
> surprising results. That's true, but if we were to solve this problem, th=
at
> person would still need to understand the underlying semantics of "foo" t=
o
> do anything useful to it -- and I'm not hearing anyone complain about tha=
t
> (I hope).
> >
> > Put another way -- do you really think that people PATCHing something a=
s
> if it's an array (when in fact it's an object) is a significant, real-wor=
ld
> problem, given that the patch author already has to understand the
> semantics of the document they're patching? I don't, and the WG didn't
> either.
> >
> > Regards,
> >
> >
> > On 17/12/2012, at 3:36 PM, Robert Sayre  wrote:
> >
> >> The cost of fixing it seems low, either by changing the path syntax of
> >> JSON pointer or changing the names of operations applied to arrays.
> >> Array-like objects are common enough in JavaScript to make this a
> >> worry. The other suggestions either assume a particular policy for
> >> concurrent edits or require more machinery (test operation etc).
> >> Wouldn't it be simpler to make the patch format more precise?
> >>
> >> - Rob
> >>
> >> On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley  wrote:
> >>> I am usually lurking and struggling to keep up with these posts. But,=
 I
> >>> concur with James, this really is a non-issue in practice.
> >>>
> >>> The JSON Pointer expresses a path down a JSON object to a specific
> context.
> >>> The Patch expresses a change within or to that context.
> >>> Everything about the both standards is about that end context.
> >>>
> >>> If you want to confirm the type of the context before applying a
> patch, this
> >>> should probably be part of a test operation. I'm not sure if this is
> >>> possible at this point (?), but that is where the logic should exist.
> >>>
> >>>
> >>>
> >>> On Sun, Dec 16, 2012 at 12:22 AM, James M Snell 
> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre 
> wrote:
> >>>>>
> >>>>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler
> >>>>>  wrote:
> >>>>>>
> >>>>>> Hmm.. I think that=E2=80=99s quite problematic. Especially conside=
ring how
> JSON
> >>>>>> Pointer is used in JSON Patch.
> >>>>>
> >>>>> I agree--I provided the same feedback privately. It seems
> >>>>> straightforwardly unsound.
> >>>>>
> >>>>
> >>>> In practice it doesn't seem to be much of an issue.
> >>>>
> >>>> Specifically, if I GET an existing document and get an etag with the
> JSON,
> >>>> then make some changes and send a PATCH with If-Match, the fact that
> any
> >>>> given pointer could point to an array or object member doesn't reall=
y
> matter
> >>>> much.
> >>>>
> >>>> For example:
> >>>>
> >>>>> GET /the/doc HTTP/1.1
> >>>>
> >>>>  <  HTTP/1.1 200 OK
> >>>>     ETag: "my-document-tag"
> >>>>     Content-Type: application/json
> >>>>
> >>>>     {"1":"foo"}
> >>>>
> >>>>> PATCH /the/doc HTTP/1.1
> >>>>     If-Match: "my-document-etag"
> >>>>     Content-Type: application/json-patch
> >>>>
> >>>>     [{"op":"add","path":"/2","value":"bar"}]
> >>>>
> >>>> Generally speaking, someone should not be using PATCH to perform a
> partial
> >>>> modification if they don't already have some knowledge in advance
> what they
> >>>> are modifying. The only time the apparent ambiguity becomes an issue
> is when
> >>>> a client is blindly sending a patch to an unknown endpoint... in
> which case,
> >>>> you get whatever you end up with.
> >>>>
> >>>> - James
> >>>>
> >>>>
> >>>>>
> >>>>> - Rob
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> --
> >>>>>>
> >>>>>> Markus Lanthaler
> >>>>>>
> >>>>>> @markuslanthaler
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> From: James M Snell [mailto:jasnell@gmail.com]
> >>>>>> Sent: Friday, December 14, 2012 5:41 PM
> >>>>>> To: Markus Lanthaler
> >>>>>> Cc: IETF Discussion; IETF Apps Discuss
> >>>>>> Subject: Re: [apps-discuss] Last Call:
> >>>>>>  (JSON Pointer) to Propose=
d
> Standard
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> JSON Pointer does not distinguish between objects and arrays. That
> is
> >>>>>> not determined until the pointer is applied to an actual object
> instance...
> >>>>>> the pointer "/1" is valid against {"1":"a"} or ["a","b"]
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler
> >>>>>>  wrote:
> >>>>>>
> >>>>>> I've asked that before but didn't get an answer. So let me ask aga=
in
> >>>>>> (even
> >>>>>> though I'm quite sure it has already been asked by somebody else).
> >>>>>>
> >>>>>> How does JSON Pointer distinguish between objects and arrays? E.g.
> >>>>>> consider
> >>>>>> the following JSON document:
> >>>>>>
> >>>>>> {
> >>>>>>  "foo": "bar",
> >>>>>>  "1": "baz"
> >>>>>> }
> >>>>>>
> >>>>>> As I read the draft, the JSON Pointer "/1" would evaluate to "baz"
> even
> >>>>>> though that's probably not what the author intended. Is there a wa=
y
> to
> >>>>>> avoid
> >>>>>> that?
> >>>>>>
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Markus
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Markus Lanthaler
> >>>>>> @markuslanthaler
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> >>>>>>> bounces@ietf.org] On Behalf Of The IESG
> >>>>>>> Sent: Tuesday, December 11, 2012 4:01 PM
> >>>>>>> To: IETF-Announce
> >>>>>>> Cc: apps-discuss@ietf.org
> >>>>>>> Subject: [apps-discuss] Last Call:
>  >>>>>>> 07.txt> (JSON Pointer) to Proposed Standard
> >>>>>>>
> >>>>>>>
> >>>>>>> The IESG has received a request from the Applications Area Workin=
g
> >>>>>>> Group
> >>>>>>> WG (appsawg) to consider the following document:
> >>>>>>> - 'JSON Pointer'
> >>>>>>>   as Proposed Standard
> >>>>>>>
> >>>>>>> The IESG plans to make a decision in the next few weeks, and
> solicits
> >>>>>>> final comments on this action. Please send substantive comments t=
o
> >>>>>>> the
> >>>>>>> ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comment=
s
> >>>>>>> may
> >>>>>>> be
> >>>>>>> sent to iesg@ietf.org instead. In either case, please retain the
> >>>>>>> beginning of the Subject line to allow automated sorting.
> >>>>>>>
> >>>>>>> Abstract
> >>>>>>>
> >>>>>>>
> >>>>>>>   JSON Pointer defines a string syntax for identifying a specific
> >>>>>>> value
> >>>>>>>   within a JSON document.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> The file can be obtained via
> >>>>>>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/
> >>>>>>>
> >>>>>>> IESG discussion can be tracked via
> >>>>>>>
> >>>>>>>
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/
> >>>>>>>
> >>>>>>>
> >>>>>>> No IPR declarations have been submitted directly on this I-D.
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> 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
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Matthew P. C. Morley
> >> _______________________________________________
> >> 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
>

--f46d043c7f88b0f73f04d294ab99
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Robert,

I may have missed it, but can you provide a non-=
theoretical example of this problem that you're suggesting exists in pr=
actice?=C2=A0




On Sat, Jan 5, 20=
13 at 4:19 PM, Robert Sayre <sayrer@gmail.com> wrote:


Mark,



The WG's reasoning, as stated in your message below, seems flawed.

Messages since your last communication on this matter have shown:



1) The ambiguity around arrays makes the patch format unsuitable for

common concurrent editing algorithms.

Why? I'm still not seeing ho=
w it's unsuitable. Again, a non-theoretical example would be helpful.




=C2=A0

2) The ambiguity is likely to occur in the real world, for a couple of

different reasons.

Such as? What are the reasons?=C2=A0
=C2=A0



3) It's not possible to tell whether a JSON Pointer document is

syntactically correct in isolation.

There is no such thing as a "=
JSON Pointer document" and I have absolutely no idea what "syntac=
tically correct in isolation" means with regards to this problem you&#=
39;re suggesting. If I see "/a/b/1", that is a syntactically corr=
ect JSON Pointer... whether or not it points to anything specific depends e=
ntirely on the specific JSON structure it is applied to. If I had to guess,=
 you're saying that it's not possible to tell if "/a/b/01"=
; is a valid JSON Pointer or not given nothing but the pointer? If so, who =
cares really? The JSON Pointer is not useful unless it's applied to an =
actual JSON structure, it's only at that point that we really ought to =
care about validity.




Still not seeing the problem.
=C2=A0





Additionally, you raised this point in your message below:


>

> the patch author already has to understand the semantics of the docume=
nt they're patching




That claim does not seem to be well-justified, and it could be

meaningless to the person implementing patch software (for example:

https://g=
ithub.com/sayrer/json-sync).



This issue is a problem in practice, and it's a problem in theory as
well. JSON-Patch messages aren't sufficiently self-descriptive, so

they aren't appropriate for use in a RESTful system.



What would be "sufficiently self-descriptive" ? Again, a no=
n-theoretical example and suggested alternative that we can compare would b=
e helpful for context.




It is=
 possible that I missed a couple of posts on this over the holiday so if yo=
u already provided an example, please do let me know and I'll go huntin=
g through the archives.




- James
=C2=A0



A response containing technical reasoning seems in order, since the

points raised by myself and others on this issue are unrelated to the

WG's previous thinking.
=C2=A0



- Rob




On Sun, Dec 16, 2012 at 9:41 PM, Mark Nottingham <mnot@mnot.net> wrote:


> Robert,

>

> This was discussed extensively in the Working Group.

>

> The root of the issue was that some people reflexively felt that this =
was necessary, but upon reflection, we decided it wasn't; although it s=
eems "natural" to some, especially those coming from a static lan=
guage background, it didn't provide any utility.



>

> You might argue that someone who (for example) adds to "/foo/1&qu=
ot; in the mistaken belief that it's an array, when in fact it's an=
 object, will get surprising results. That's true, but if we were to so=
lve this problem, that person would still need to understand the underlying=
 semantics of "foo" to do anything useful to it -- and I'm no=
t hearing anyone complain about that (I hope).



>

> Put another way -- do you really think that people PATCHing something =
as if it's an array (when in fact it's an object) is a significant,=
 real-world problem, given that the patch author already has to understand =
the semantics of the document they're patching? I don't, and the WG=
 didn't either.



>

> Regards,

>

>

> On 17/12/2012, at 3:36 PM, Robert Sayre <sayrer@gmail.com> wrote:

>

>> The cost of fixing it seems low, either by changing the path synta=
x of

>> JSON pointer or changing the names of operations applied to arrays=
.

>> Array-like objects are common enough in JavaScript to make this a<=
br>
>> worry. The other suggestions either assume a particular policy for=


>> concurrent edits or require more machinery (test operation etc).
>> Wouldn't it be simpler to make the patch format more precise?<=
br>
>>

>> - Rob

>>

>> On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley <matt@mpcm.com> wrote:

>>> I am usually lurking and struggling to keep up with these post=
s. But, I

>>> concur with James, this really is a non-issue in practice.

>>>

>>> The JSON Pointer expresses a path down a JSON object to a spec=
ific context.

>>> The Patch expresses a change within or to that context.

>>> Everything about the both standards is about that end context.=


>>>

>>> If you want to confirm the type of the context before applying=
 a patch, this

>>> should probably be part of a test operation. I'm not sure =
if this is

>>> possible at this point (?), but that is where the logic should=
 exist.

>>>

>>>

>>>

>>> On Sun, Dec 16, 2012 at 12:22 AM, James M Snell <jasnell@gmail.com> wrote:

>>>>

>>>>

>>>>

>>>>

>>>> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre <sayrer@gmail.com> wrote:

>>>>>

>>>>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler

>>>>> <markus=
.lanthaler@gmx.net> wrote:

>>>>>>

>>>>>> Hmm.. I think that=E2=80=99s quite problematic. Es=
pecially considering how JSON

>>>>>> Pointer is used in JSON Patch.

>>>>>

>>>>> I agree--I provided the same feedback privately. It se=
ems

>>>>> straightforwardly unsound.

>>>>>

>>>>

>>>> In practice it doesn't seem to be much of an issue.
>>>>

>>>> Specifically, if I GET an existing document and get an eta=
g with the JSON,

>>>> then make some changes and send a PATCH with If-Match, the=
 fact that any

>>>> given pointer could point to an array or object member doe=
sn't really matter

>>>> much.

>>>>

>>>> For example:

>>>>

>>>>> GET /the/doc HTTP/1.1

>>>>

>>>> =C2=A0< =C2=A0HTTP/1.1 200 OK

>>>> =C2=A0 =C2=A0 ETag: "my-document-tag"

>>>> =C2=A0 =C2=A0 Content-Type: application/json

>>>>

>>>> =C2=A0 =C2=A0 {"1":"foo"}

>>>>

>>>>> PATCH /the/doc HTTP/1.1

>>>> =C2=A0 =C2=A0 If-Match: "my-document-etag"

>>>> =C2=A0 =C2=A0 Content-Type: application/json-patch

>>>>

>>>> =C2=A0 =C2=A0 [{"op":"add","path&=
quot;:"/2","value":"bar"}]

>>>>

>>>> Generally speaking, someone should not be using PATCH to p=
erform a partial

>>>> modification if they don't already have some knowledge=
 in advance what they

>>>> are modifying. The only time the apparent ambiguity become=
s an issue is when

>>>> a client is blindly sending a patch to an unknown endpoint=
... in which case,

>>>> you get whatever you end up with.

>>>>

>>>> - James

>>>>

>>>>

>>>>>

>>>>> - Rob

>>>>>

>>>>>

>>>>>>

>>>>>> --

>>>>>>

>>>>>> Markus Lanthaler

>>>>>>

>>>>>> @markuslanthaler

>>>>>>

>>>>>>

>>>>>>

>>>>>>

>>>>>>

>>>>>>

>>>>>>

>>>>>> From: James M Snell [mailto:jasnell@gmail.com]

>>>>>> Sent: Friday, December 14, 2012 5:41 PM

>>>>>> To: Markus Lanthaler

>>>>>> Cc: IETF Discussion; IETF Apps Discuss

>>>>>> Subject: Re: [apps-discuss] Last Call:

>>>>>> <draft-ietf-appsawg-json-pointer-07.txt> (JS=
ON Pointer) to Proposed Standard

>>>>>>

>>>>>>

>>>>>>

>>>>>> JSON Pointer does not distinguish between objects =
and arrays. That is

>>>>>> not determined until the pointer is applied to an =
actual object instance...

>>>>>> the pointer "/1" is valid against {"=
;1":"a"} or ["a","b"]

>>>>>>

>>>>>>

>>>>>>

>>>>>> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler<=
br>
>>>>>> <ma=
rkus.lanthaler@gmx.net> wrote:

>>>>>>

>>>>>> I've asked that before but didn't get an a=
nswer. So let me ask again

>>>>>> (even

>>>>>> though I'm quite sure it has already been aske=
d by somebody else).

>>>>>>

>>>>>> How does JSON Pointer distinguish between objects =
and arrays? E.g.

>>>>>> consider

>>>>>> the following JSON document:

>>>>>>

>>>>>> {

>>>>>> =C2=A0"foo": "bar",

>>>>>> =C2=A0"1": "baz"

>>>>>> }

>>>>>>

>>>>>> As I read the draft, the JSON Pointer "/1&quo=
t; would evaluate to "baz" even

>>>>>> though that's probably not what the author int=
ended. Is there a way to

>>>>>> avoid

>>>>>> that?

>>>>>>

>>>>>>

>>>>>> Thanks,

>>>>>> Markus

>>>>>>

>>>>>>

>>>>>>

>>>>>> --

>>>>>> Markus Lanthaler

>>>>>> @markuslanthaler

>>>>>>

>>>>>>

>>>>>>

>>>>>>

>>>>>>

>>>>>>> -----Original Message-----

>>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-

>>>>>>> bounces@ie=
tf.org] On Behalf Of The IESG

>>>>>>> Sent: Tuesday, December 11, 2012 4:01 PM

>>>>>>> To: IETF-Announce

>>>>>>> Cc: a=
pps-discuss@ietf.org

>>>>>>> Subject: [apps-discuss] Last Call: <draft-i=
etf-appsawg-json-pointer-

>>>>>>> 07.txt> (JSON Pointer) to Proposed Standard=


>>>>>>>

>>>>>>>

>>>>>>> The IESG has received a request from the Appli=
cations Area Working

>>>>>>> Group

>>>>>>> WG (appsawg) to consider the following documen=
t:

>>>>>>> - 'JSON Pointer'

>>>>>>> =C2=A0<draft-ietf-appsawg-json-pointer-07.t=
xt> as Proposed Standard

>>>>>>>

>>>>>>> The IESG plans to make a decision in the next =
few weeks, and solicits

>>>>>>> final comments on this action. Please send sub=
stantive comments to

>>>>>>> the

>>>>>>> ietf@ietf.org=
 mailing lists by 2012-12-25. Exceptionally, comments

>>>>>>> may

>>>>>>> be

>>>>>>> sent to iesg@=
ietf.org instead. In either case, please retain the

>>>>>>> beginning of the Subject line to allow automat=
ed sorting.

>>>>>>>

>>>>>>> Abstract

>>>>>>>

>>>>>>>

>>>>>>> =C2=A0 JSON Pointer defines a string syntax fo=
r identifying a specific

>>>>>>> value

>>>>>>> =C2=A0 within a JSON document.

>>>>>>>

>>>>>>>

>>>>>>>

>>>>>>>

>>>>>>> The file can be obtained via

>>>>>>> http://datatracker.ietf.or=
g/doc/draft-ietf-appsawg-json-pointer/

>>>>>>>

>>>>>>> IESG discussion can be tracked via

>>>>>>>

>>>>>>> http://datatracker.=
ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/

>>>>>>>

>>>>>>>

>>>>>>> No IPR declarations have been submitted direct=
ly on this I-D.

>>>>>>>

>>>>>>>

>>>>>>> ______________________________________________=
_

>>>>>>> apps-discuss mailing list

>>>>>>> apps-=
discuss@ietf.org

>>>>>>> https://www.ietf.org/mailman/listinfo/ap=
ps-discuss

>>>>>>

>>>>>> _______________________________________________
>>>>>> apps-discuss mailing list

>>>>>> apps-disc=
uss@ietf.org

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

>>>>>>

>>>>>>

>>>>>>

>>>>>>

>>>>>> _______________________________________________
>>>>>> apps-discuss mailing list

>>>>>> apps-disc=
uss@ietf.org

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

>>>>>>

>>>>

>>>>

>>>>

>>>> _______________________________________________

>>>> apps-discuss mailing list

>>>> apps-discuss@ietf=
.org

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

>>>>

>>>

>>>

>>>

>>> --

>>> Matthew P. C. Morley

>> _______________________________________________

>> apps-discuss mailing list

>> apps-discuss@ietf.org=


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

>

> --

> Mark Nottingham =C2=A0 http://www.mnot.net/

>

>

>

_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--f46d043c7f88b0f73f04d294ab99--

From mnot@mnot.net  Sat Jan  5 17:48:22 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7203D21F8583; Sat,  5 Jan 2013 17:48:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 m7iO9rn1IByk; Sat,  5 Jan 2013 17:48:21 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id D9F2A21F8574; Sat,  5 Jan 2013 17:48:20 -0800 (PST)
Received: from [192.168.1.80] (unknown [118.209.230.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 68975509B8; Sat,  5 Jan 2013 20:48:14 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: 
Date: Sun, 6 Jan 2013 12:48:10 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <263BA4B0-6401-4391-A369-A90863D9A4BC@mnot.net>
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>      
To: Robert Sayre 
X-Mailer: Apple Mail (2.1499)
Cc: IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Sun, 06 Jan 2013 01:48:22 -0000

Robert,

I neither represent the WG (except in as far as I attempt to do so as =
document editor), nor do I judge consensus in the WG (the Chairs do, =
although at this late date, the IESG are making the decisions).

That said, if we were starting this from scratch, I *personally* could =
see adding some syntax to distinguish intent, as I don't see it causing =
any huge amount of harm (besides leading some to believe that JSON =
Pointer is a proto-schema language).=20

However, at this point, doing so really a judgement call; we have =
multiple implementations, and we shouldn't force them to change =
arbitrarily. As far as I can see, you haven't convinced anyone that this =
is a serious enough problem to do so (and I don't appear to be the only =
one to hold that opinion, by any means). Furthermore, it's not clear =
that the use cases you have in mind (since you have brought up JSON =
Sync) are in-scope for these specifications.

Soon, the IESG will make its determination, so you'd likely be much more =
productive by laying out your argument cogently to them, rather than =
focusing on me.

If we were to open up to further changes, I'd like to see us discuss =
things like allowing header modifications in the format, and specifying =
the target's intended media type (which was already discussed and =
rejected in the WG).=20

However, I'm even more interested in getting this format published, in =
the knowledge that HTTP PATCH has been defined for some time, but is =
effectively useless (at least against JSON) without any defined, stable =
patch format. If we find serious deficiencies, nothing stops us, or you, =
or anyone else from defining a new patch format (as James is already =
doing).

Cheers,


On 06/01/2013, at 11:19 AM, Robert Sayre  wrote:

> Mark,
>=20
> The WG's reasoning, as stated in your message below, seems flawed.
> Messages since your last communication on this matter have shown:
>=20
> 1) The ambiguity around arrays makes the patch format unsuitable for
> common concurrent editing algorithms.
> 2) The ambiguity is likely to occur in the real world, for a couple of
> different reasons.
> 3) It's not possible to tell whether a JSON Pointer document is
> syntactically correct in isolation.
>=20
> Additionally, you raised this point in your message below:
>>=20
>> the patch author already has to understand the semantics of the =
document they're patching
>=20
> That claim does not seem to be well-justified, and it could be
> meaningless to the person implementing patch software (for example:
> https://github.com/sayrer/json-sync).
>=20
> This issue is a problem in practice, and it's a problem in theory as
> well. JSON-Patch messages aren't sufficiently self-descriptive, so
> they aren't appropriate for use in a RESTful system.
>=20
> A response containing technical reasoning seems in order, since the
> points raised by myself and others on this issue are unrelated to the
> WG's previous thinking.
>=20
> - Rob
>=20
> On Sun, Dec 16, 2012 at 9:41 PM, Mark Nottingham  =
wrote:
>> Robert,
>>=20
>> This was discussed extensively in the Working Group.
>>=20
>> The root of the issue was that some people reflexively felt that this =
was necessary, but upon reflection, we decided it wasn't; although it =
seems "natural" to some, especially those coming from a static language =
background, it didn't provide any utility.
>>=20
>> You might argue that someone who (for example) adds to "/foo/1" in =
the mistaken belief that it's an array, when in fact it's an object, =
will get surprising results. That's true, but if we were to solve this =
problem, that person would still need to understand the underlying =
semantics of "foo" to do anything useful to it -- and I'm not hearing =
anyone complain about that (I hope).
>>=20
>> Put another way -- do you really think that people PATCHing something =
as if it's an array (when in fact it's an object) is a significant, =
real-world problem, given that the patch author already has to =
understand the semantics of the document they're patching? I don't, and =
the WG didn't either.
>>=20
>> Regards,
>>=20
>>=20
>> On 17/12/2012, at 3:36 PM, Robert Sayre  wrote:
>>=20
>>> The cost of fixing it seems low, either by changing the path syntax =
of
>>> JSON pointer or changing the names of operations applied to arrays.
>>> Array-like objects are common enough in JavaScript to make this a
>>> worry. The other suggestions either assume a particular policy for
>>> concurrent edits or require more machinery (test operation etc).
>>> Wouldn't it be simpler to make the patch format more precise?
>>>=20
>>> - Rob
>>>=20
>>> On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley  =
wrote:
>>>> I am usually lurking and struggling to keep up with these posts. =
But, I
>>>> concur with James, this really is a non-issue in practice.
>>>>=20
>>>> The JSON Pointer expresses a path down a JSON object to a specific =
context.
>>>> The Patch expresses a change within or to that context.
>>>> Everything about the both standards is about that end context.
>>>>=20
>>>> If you want to confirm the type of the context before applying a =
patch, this
>>>> should probably be part of a test operation. I'm not sure if this =
is
>>>> possible at this point (?), but that is where the logic should =
exist.
>>>>=20
>>>>=20
>>>>=20
>>>> On Sun, Dec 16, 2012 at 12:22 AM, James M Snell  =
wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre  =
wrote:
>>>>>>=20
>>>>>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler
>>>>>>  wrote:
>>>>>>>=20
>>>>>>> Hmm.. I think that=92s quite problematic. Especially considering =
how JSON
>>>>>>> Pointer is used in JSON Patch.
>>>>>>=20
>>>>>> I agree--I provided the same feedback privately. It seems
>>>>>> straightforwardly unsound.
>>>>>>=20
>>>>>=20
>>>>> In practice it doesn't seem to be much of an issue.
>>>>>=20
>>>>> Specifically, if I GET an existing document and get an etag with =
the JSON,
>>>>> then make some changes and send a PATCH with If-Match, the fact =
that any
>>>>> given pointer could point to an array or object member doesn't =
really matter
>>>>> much.
>>>>>=20
>>>>> For example:
>>>>>=20
>>>>>> GET /the/doc HTTP/1.1
>>>>>=20
>>>>> <  HTTP/1.1 200 OK
>>>>>    ETag: "my-document-tag"
>>>>>    Content-Type: application/json
>>>>>=20
>>>>>    {"1":"foo"}
>>>>>=20
>>>>>> PATCH /the/doc HTTP/1.1
>>>>>    If-Match: "my-document-etag"
>>>>>    Content-Type: application/json-patch
>>>>>=20
>>>>>    [{"op":"add","path":"/2","value":"bar"}]
>>>>>=20
>>>>> Generally speaking, someone should not be using PATCH to perform a =
partial
>>>>> modification if they don't already have some knowledge in advance =
what they
>>>>> are modifying. The only time the apparent ambiguity becomes an =
issue is when
>>>>> a client is blindly sending a patch to an unknown endpoint... in =
which case,
>>>>> you get whatever you end up with.
>>>>>=20
>>>>> - James
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>> - Rob
>>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>> --
>>>>>>>=20
>>>>>>> Markus Lanthaler
>>>>>>>=20
>>>>>>> @markuslanthaler
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> From: James M Snell [mailto:jasnell@gmail.com]
>>>>>>> Sent: Friday, December 14, 2012 5:41 PM
>>>>>>> To: Markus Lanthaler
>>>>>>> Cc: IETF Discussion; IETF Apps Discuss
>>>>>>> Subject: Re: [apps-discuss] Last Call:
>>>>>>>  (JSON Pointer) to =
Proposed Standard
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> JSON Pointer does not distinguish between objects and arrays. =
That is
>>>>>>> not determined until the pointer is applied to an actual object =
instance...
>>>>>>> the pointer "/1" is valid against {"1":"a"} or ["a","b"]
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler
>>>>>>>  wrote:
>>>>>>>=20
>>>>>>> I've asked that before but didn't get an answer. So let me ask =
again
>>>>>>> (even
>>>>>>> though I'm quite sure it has already been asked by somebody =
else).
>>>>>>>=20
>>>>>>> How does JSON Pointer distinguish between objects and arrays? =
E.g.
>>>>>>> consider
>>>>>>> the following JSON document:
>>>>>>>=20
>>>>>>> {
>>>>>>> "foo": "bar",
>>>>>>> "1": "baz"
>>>>>>> }
>>>>>>>=20
>>>>>>> As I read the draft, the JSON Pointer "/1" would evaluate to =
"baz" even
>>>>>>> though that's probably not what the author intended. Is there a =
way to
>>>>>>> avoid
>>>>>>> that?
>>>>>>>=20
>>>>>>>=20
>>>>>>> Thanks,
>>>>>>> Markus
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> --
>>>>>>> Markus Lanthaler
>>>>>>> @markuslanthaler
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>>>>>>>> bounces@ietf.org] On Behalf Of The IESG
>>>>>>>> Sent: Tuesday, December 11, 2012 4:01 PM
>>>>>>>> To: IETF-Announce
>>>>>>>> Cc: apps-discuss@ietf.org
>>>>>>>> Subject: [apps-discuss] Last Call: =
>>>>>>> 07.txt> (JSON Pointer) to Proposed Standard
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> The IESG has received a request from the Applications Area =
Working
>>>>>>>> Group
>>>>>>>> WG (appsawg) to consider the following document:
>>>>>>>> - 'JSON Pointer'
>>>>>>>>  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-12-25. 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
>>>>>>>>  JSON Pointer defines a string syntax for identifying a =
specific
>>>>>>>> value
>>>>>>>>  within a JSON document.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> The file can be obtained via
>>>>>>>> =
http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/
>>>>>>>>=20
>>>>>>>> IESG discussion can be tracked via
>>>>>>>>=20
>>>>>>>> =
http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> No IPR declarations have been submitted directly on this I-D.
>>>>>>>>=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
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> apps-discuss mailing list
>>>>>>> apps-discuss@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> apps-discuss mailing list
>>>>> apps-discuss@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> Matthew P. C. Morley
>>> _______________________________________________
>>> 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

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




From sayrer@gmail.com  Sat Jan  5 18:29:50 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC8E21F852C; Sat,  5 Jan 2013 18:29:50 -0800 (PST)
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 xnEZwV6-vVSf; Sat,  5 Jan 2013 18:29:49 -0800 (PST)
Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 10AC721F8526; Sat,  5 Jan 2013 18:29:48 -0800 (PST)
Received: by mail-wg0-f54.google.com with SMTP id fg15so8393529wgb.21 for ; Sat, 05 Jan 2013 18:29:48 -0800 (PST)
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=iSxaa8cOyR01s6YTFdOlGc89BTjz+V+x23RWLU92LaQ=; b=wBQqPY7n8fwiJDbk+nleXsOAAHDydLYeD5ejwoV3iax7N1vUUaBPKiQlCOcxsIKbA1 HCY/tPaYY505T6bRDKufdyERMK9j3hizcC8WYl/0FBvL6g/OTdgw++uoo7+gxlZKphrQ 59T5gGEW+m8lAzECBQIolzp3jce7OFjWcvpPqiLM9ZKiV0nPj0z7mXwbSAi/Vygm9+Qy mgjLG+XP3K7ADd6T0WwdHY+B22h/Nu2dImt3NF1xD48RSoz5hug12GBmOqa4cd+1C2Gm 9XHVtG67eTlEi86xJvE5ZCcv7aFAOZ20IFi0wOz0L/3O1PGqcIkvGcAKRuaiMfG00Dfl ABTQ==
MIME-Version: 1.0
Received: by 10.194.78.162 with SMTP id c2mr89570783wjx.46.1357439388168; Sat, 05 Jan 2013 18:29:48 -0800 (PST)
Received: by 10.194.1.101 with HTTP; Sat, 5 Jan 2013 18:29:48 -0800 (PST)
In-Reply-To: <263BA4B0-6401-4391-A369-A90863D9A4BC@mnot.net>
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <263BA4B0-6401-4391-A369-A90863D9A4BC@mnot.net>
Date: Sat, 5 Jan 2013 18:29:48 -0800
Message-ID: 
From: Robert Sayre 
To: Mark Nottingham 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Sun, 06 Jan 2013 02:29:50 -0000

On Sat, Jan 5, 2013 at 5:48 PM, Mark Nottingham  wrote:
>
> However, at this point, doing so really a judgement call; we have multipl=
e implementations, and we shouldn't
> force them to change arbitrarily.

The word "arbitrarily" seems inappropriate here. I raised at least
four technical issues and your message addresses none of them.

> As far as I can see, you haven't convinced anyone that this is a serious =
enough problem to do so (and I don't
> appear to be the only one to hold that opinion, by any means).

Did you read this thread? Markus Lanthaler and Conal Tuohy raised
similar points.

> Furthermore, it's not clear that the use cases you have in mind (since yo=
u have brought up JSON Sync)
> are in-scope for these specifications.

That assertion is both unsubstantiated and incorrect. json-sync has
identical primitive operations to JSON Patch (create/edit/remove vs
add/replace/remove). The JSON Patch document defines Copy and Move in
terms of the add/replace, so those are mostly syntactic sugar. The
only meaningful delta is the "test" operation, and I do plan to add
that to json-sync, since it's a good way to make application-specific
assertions.

> However, I'm even more interested in getting this format published,

Well, I guess someone has something they want to ship...

- Rob

> Cheers,
>
>
> On 06/01/2013, at 11:19 AM, Robert Sayre  wrote:
>
>> Mark,
>>
>> The WG's reasoning, as stated in your message below, seems flawed.
>> Messages since your last communication on this matter have shown:
>>
>> 1) The ambiguity around arrays makes the patch format unsuitable for
>> common concurrent editing algorithms.
>> 2) The ambiguity is likely to occur in the real world, for a couple of
>> different reasons.
>> 3) It's not possible to tell whether a JSON Pointer document is
>> syntactically correct in isolation.
>>
>> Additionally, you raised this point in your message below:
>>>
>>> the patch author already has to understand the semantics of the documen=
t they're patching
>>
>> That claim does not seem to be well-justified, and it could be
>> meaningless to the person implementing patch software (for example:
>> https://github.com/sayrer/json-sync).
>>
>> This issue is a problem in practice, and it's a problem in theory as
>> well. JSON-Patch messages aren't sufficiently self-descriptive, so
>> they aren't appropriate for use in a RESTful system.
>>
>> A response containing technical reasoning seems in order, since the
>> points raised by myself and others on this issue are unrelated to the
>> WG's previous thinking.
>>
>> - Rob
>>
>> On Sun, Dec 16, 2012 at 9:41 PM, Mark Nottingham  wrote:
>>> Robert,
>>>
>>> This was discussed extensively in the Working Group.
>>>
>>> The root of the issue was that some people reflexively felt that this w=
as necessary, but upon reflection, we decided it wasn't; although it seems =
"natural" to some, especially those coming from a static language backgroun=
d, it didn't provide any utility.
>>>
>>> You might argue that someone who (for example) adds to "/foo/1" in the =
mistaken belief that it's an array, when in fact it's an object, will get s=
urprising results. That's true, but if we were to solve this problem, that =
person would still need to understand the underlying semantics of "foo" to =
do anything useful to it -- and I'm not hearing anyone complain about that =
(I hope).
>>>
>>> Put another way -- do you really think that people PATCHing something a=
s if it's an array (when in fact it's an object) is a significant, real-wor=
ld problem, given that the patch author already has to understand the seman=
tics of the document they're patching? I don't, and the WG didn't either.
>>>
>>> Regards,
>>>
>>>
>>> On 17/12/2012, at 3:36 PM, Robert Sayre  wrote:
>>>
>>>> The cost of fixing it seems low, either by changing the path syntax of
>>>> JSON pointer or changing the names of operations applied to arrays.
>>>> Array-like objects are common enough in JavaScript to make this a
>>>> worry. The other suggestions either assume a particular policy for
>>>> concurrent edits or require more machinery (test operation etc).
>>>> Wouldn't it be simpler to make the patch format more precise?
>>>>
>>>> - Rob
>>>>
>>>> On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley  wrote:
>>>>> I am usually lurking and struggling to keep up with these posts. But,=
 I
>>>>> concur with James, this really is a non-issue in practice.
>>>>>
>>>>> The JSON Pointer expresses a path down a JSON object to a specific co=
ntext.
>>>>> The Patch expresses a change within or to that context.
>>>>> Everything about the both standards is about that end context.
>>>>>
>>>>> If you want to confirm the type of the context before applying a patc=
h, this
>>>>> should probably be part of a test operation. I'm not sure if this is
>>>>> possible at this point (?), but that is where the logic should exist.
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Dec 16, 2012 at 12:22 AM, James M Snell  w=
rote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre  wro=
te:
>>>>>>>
>>>>>>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> Hmm.. I think that=92s quite problematic. Especially considering h=
ow JSON
>>>>>>>> Pointer is used in JSON Patch.
>>>>>>>
>>>>>>> I agree--I provided the same feedback privately. It seems
>>>>>>> straightforwardly unsound.
>>>>>>>
>>>>>>
>>>>>> In practice it doesn't seem to be much of an issue.
>>>>>>
>>>>>> Specifically, if I GET an existing document and get an etag with the=
 JSON,
>>>>>> then make some changes and send a PATCH with If-Match, the fact that=
 any
>>>>>> given pointer could point to an array or object member doesn't reall=
y matter
>>>>>> much.
>>>>>>
>>>>>> For example:
>>>>>>
>>>>>>> GET /the/doc HTTP/1.1
>>>>>>
>>>>>> <  HTTP/1.1 200 OK
>>>>>>    ETag: "my-document-tag"
>>>>>>    Content-Type: application/json
>>>>>>
>>>>>>    {"1":"foo"}
>>>>>>
>>>>>>> PATCH /the/doc HTTP/1.1
>>>>>>    If-Match: "my-document-etag"
>>>>>>    Content-Type: application/json-patch
>>>>>>
>>>>>>    [{"op":"add","path":"/2","value":"bar"}]
>>>>>>
>>>>>> Generally speaking, someone should not be using PATCH to perform a p=
artial
>>>>>> modification if they don't already have some knowledge in advance wh=
at they
>>>>>> are modifying. The only time the apparent ambiguity becomes an issue=
 is when
>>>>>> a client is blindly sending a patch to an unknown endpoint... in whi=
ch case,
>>>>>> you get whatever you end up with.
>>>>>>
>>>>>> - James
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> - Rob
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Markus Lanthaler
>>>>>>>>
>>>>>>>> @markuslanthaler
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> From: James M Snell [mailto:jasnell@gmail.com]
>>>>>>>> Sent: Friday, December 14, 2012 5:41 PM
>>>>>>>> To: Markus Lanthaler
>>>>>>>> Cc: IETF Discussion; IETF Apps Discuss
>>>>>>>> Subject: Re: [apps-discuss] Last Call:
>>>>>>>>  (JSON Pointer) to Propose=
d Standard
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> JSON Pointer does not distinguish between objects and arrays. That=
 is
>>>>>>>> not determined until the pointer is applied to an actual object in=
stance...
>>>>>>>> the pointer "/1" is valid against {"1":"a"} or ["a","b"]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> I've asked that before but didn't get an answer. So let me ask aga=
in
>>>>>>>> (even
>>>>>>>> though I'm quite sure it has already been asked by somebody else).
>>>>>>>>
>>>>>>>> How does JSON Pointer distinguish between objects and arrays? E.g.
>>>>>>>> consider
>>>>>>>> the following JSON document:
>>>>>>>>
>>>>>>>> {
>>>>>>>> "foo": "bar",
>>>>>>>> "1": "baz"
>>>>>>>> }
>>>>>>>>
>>>>>>>> As I read the draft, the JSON Pointer "/1" would evaluate to "baz"=
 even
>>>>>>>> though that's probably not what the author intended. Is there a wa=
y to
>>>>>>>> avoid
>>>>>>>> that?
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Markus
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Markus Lanthaler
>>>>>>>> @markuslanthaler
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>>>>>>>>> bounces@ietf.org] On Behalf Of The IESG
>>>>>>>>> Sent: Tuesday, December 11, 2012 4:01 PM
>>>>>>>>> To: IETF-Announce
>>>>>>>>> Cc: apps-discuss@ietf.org
>>>>>>>>> Subject: [apps-discuss] Last Call: >>>>>>>> 07.txt> (JSON Pointer) to Proposed Standard
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The IESG has received a request from the Applications Area Workin=
g
>>>>>>>>> Group
>>>>>>>>> WG (appsawg) to consider the following document:
>>>>>>>>> - 'JSON Pointer'
>>>>>>>>>  as Proposed Standard
>>>>>>>>>
>>>>>>>>> The IESG plans to make a decision in the next few weeks, and soli=
cits
>>>>>>>>> final comments on this action. Please send substantive comments t=
o
>>>>>>>>> the
>>>>>>>>> ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comment=
s
>>>>>>>>> may
>>>>>>>>> be
>>>>>>>>> sent to iesg@ietf.org instead. In either case, please retain the
>>>>>>>>> beginning of the Subject line to allow automated sorting.
>>>>>>>>>
>>>>>>>>> Abstract
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  JSON Pointer defines a string syntax for identifying a specific
>>>>>>>>> value
>>>>>>>>>  within a JSON document.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The file can be obtained via
>>>>>>>>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/
>>>>>>>>>
>>>>>>>>> IESG discussion can be tracked via
>>>>>>>>>
>>>>>>>>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/b=
allot/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No IPR declarations have been submitted directly on this I-D.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matthew P. C. Morley
>>>> _______________________________________________
>>>> 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/
>
>
>

From mnot@mnot.net  Sat Jan  5 18:59:56 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496ED21F87C3; Sat,  5 Jan 2013 18:59:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 UF40DjJXo7PK; Sat,  5 Jan 2013 18:59:55 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id A636D21F8717; Sat,  5 Jan 2013 18:59:54 -0800 (PST)
Received: from [192.168.1.80] (unknown [118.209.230.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5CB29509B8; Sat,  5 Jan 2013 21:59:51 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: 
Date: Sun, 6 Jan 2013 13:59:46 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <263BA4B0-6401-4391-A369-A90863D9A4BC@mnot.net> 
To: Robert Sayre 
X-Mailer: Apple Mail (2.1499)
Cc: IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Sun, 06 Jan 2013 02:59:56 -0000

On 06/01/2013, at 1:29 PM, Robert Sayre  wrote:

> On Sat, Jan 5, 2013 at 5:48 PM, Mark Nottingham  wrote:
>>=20
>> However, at this point, doing so really a judgement call; we have =
multiple implementations, and we shouldn't
>> force them to change arbitrarily.
>=20
> The word "arbitrarily" seems inappropriate here. I raised at least
> four technical issues and your message addresses none of them.

... and I explained why.=20


>> As far as I can see, you haven't convinced anyone that this is a =
serious enough problem to do so (and I don't
>> appear to be the only one to hold that opinion, by any means).
>=20
> Did you read this thread? Markus Lanthaler and Conal Tuohy raised
> similar points.

Yes.=20


>> Furthermore, it's not clear that the use cases you have in mind =
(since you have brought up JSON Sync)
>> are in-scope for these specifications.
>=20
> That assertion is both unsubstantiated and incorrect. json-sync has
> identical primitive operations to JSON Patch (create/edit/remove vs
> add/replace/remove). The JSON Patch document defines Copy and Move in
> terms of the add/replace, so those are mostly syntactic sugar. The
> only meaningful delta is the "test" operation, and I do plan to add
> that to json-sync, since it's a good way to make application-specific
> assertions.

Yes, you've brought that to our attention several times. If you wanted =
this spec to align with your software, it would have been much easier if =
you'd got involved before Last Call.


>> However, I'm even more interested in getting this format published,
>=20
> Well, I guess someone has something they want to ship...

Right. I'll let that statement stand on its own; I think anyone who's =
been participating or watching the WG can assess how justified it is.

Always a pleasure, Rob.


>=20
> - Rob
>=20
>> Cheers,
>>=20
>>=20
>> On 06/01/2013, at 11:19 AM, Robert Sayre  wrote:
>>=20
>>> Mark,
>>>=20
>>> The WG's reasoning, as stated in your message below, seems flawed.
>>> Messages since your last communication on this matter have shown:
>>>=20
>>> 1) The ambiguity around arrays makes the patch format unsuitable for
>>> common concurrent editing algorithms.
>>> 2) The ambiguity is likely to occur in the real world, for a couple =
of
>>> different reasons.
>>> 3) It's not possible to tell whether a JSON Pointer document is
>>> syntactically correct in isolation.
>>>=20
>>> Additionally, you raised this point in your message below:
>>>>=20
>>>> the patch author already has to understand the semantics of the =
document they're patching
>>>=20
>>> That claim does not seem to be well-justified, and it could be
>>> meaningless to the person implementing patch software (for example:
>>> https://github.com/sayrer/json-sync).
>>>=20
>>> This issue is a problem in practice, and it's a problem in theory as
>>> well. JSON-Patch messages aren't sufficiently self-descriptive, so
>>> they aren't appropriate for use in a RESTful system.
>>>=20
>>> A response containing technical reasoning seems in order, since the
>>> points raised by myself and others on this issue are unrelated to =
the
>>> WG's previous thinking.
>>>=20
>>> - Rob
>>>=20
>>> On Sun, Dec 16, 2012 at 9:41 PM, Mark Nottingham  =
wrote:
>>>> Robert,
>>>>=20
>>>> This was discussed extensively in the Working Group.
>>>>=20
>>>> The root of the issue was that some people reflexively felt that =
this was necessary, but upon reflection, we decided it wasn't; although =
it seems "natural" to some, especially those coming from a static =
language background, it didn't provide any utility.
>>>>=20
>>>> You might argue that someone who (for example) adds to "/foo/1" in =
the mistaken belief that it's an array, when in fact it's an object, =
will get surprising results. That's true, but if we were to solve this =
problem, that person would still need to understand the underlying =
semantics of "foo" to do anything useful to it -- and I'm not hearing =
anyone complain about that (I hope).
>>>>=20
>>>> Put another way -- do you really think that people PATCHing =
something as if it's an array (when in fact it's an object) is a =
significant, real-world problem, given that the patch author already has =
to understand the semantics of the document they're patching? I don't, =
and the WG didn't either.
>>>>=20
>>>> Regards,
>>>>=20
>>>>=20
>>>> On 17/12/2012, at 3:36 PM, Robert Sayre  wrote:
>>>>=20
>>>>> The cost of fixing it seems low, either by changing the path =
syntax of
>>>>> JSON pointer or changing the names of operations applied to =
arrays.
>>>>> Array-like objects are common enough in JavaScript to make this a
>>>>> worry. The other suggestions either assume a particular policy for
>>>>> concurrent edits or require more machinery (test operation etc).
>>>>> Wouldn't it be simpler to make the patch format more precise?
>>>>>=20
>>>>> - Rob
>>>>>=20
>>>>> On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley  =
wrote:
>>>>>> I am usually lurking and struggling to keep up with these posts. =
But, I
>>>>>> concur with James, this really is a non-issue in practice.
>>>>>>=20
>>>>>> The JSON Pointer expresses a path down a JSON object to a =
specific context.
>>>>>> The Patch expresses a change within or to that context.
>>>>>> Everything about the both standards is about that end context.
>>>>>>=20
>>>>>> If you want to confirm the type of the context before applying a =
patch, this
>>>>>> should probably be part of a test operation. I'm not sure if this =
is
>>>>>> possible at this point (?), but that is where the logic should =
exist.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Sun, Dec 16, 2012 at 12:22 AM, James M Snell =
 wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre  =
wrote:
>>>>>>>>=20
>>>>>>>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler
>>>>>>>>  wrote:
>>>>>>>>>=20
>>>>>>>>> Hmm.. I think that=92s quite problematic. Especially =
considering how JSON
>>>>>>>>> Pointer is used in JSON Patch.
>>>>>>>>=20
>>>>>>>> I agree--I provided the same feedback privately. It seems
>>>>>>>> straightforwardly unsound.
>>>>>>>>=20
>>>>>>>=20
>>>>>>> In practice it doesn't seem to be much of an issue.
>>>>>>>=20
>>>>>>> Specifically, if I GET an existing document and get an etag with =
the JSON,
>>>>>>> then make some changes and send a PATCH with If-Match, the fact =
that any
>>>>>>> given pointer could point to an array or object member doesn't =
really matter
>>>>>>> much.
>>>>>>>=20
>>>>>>> For example:
>>>>>>>=20
>>>>>>>> GET /the/doc HTTP/1.1
>>>>>>>=20
>>>>>>> <  HTTP/1.1 200 OK
>>>>>>>   ETag: "my-document-tag"
>>>>>>>   Content-Type: application/json
>>>>>>>=20
>>>>>>>   {"1":"foo"}
>>>>>>>=20
>>>>>>>> PATCH /the/doc HTTP/1.1
>>>>>>>   If-Match: "my-document-etag"
>>>>>>>   Content-Type: application/json-patch
>>>>>>>=20
>>>>>>>   [{"op":"add","path":"/2","value":"bar"}]
>>>>>>>=20
>>>>>>> Generally speaking, someone should not be using PATCH to perform =
a partial
>>>>>>> modification if they don't already have some knowledge in =
advance what they
>>>>>>> are modifying. The only time the apparent ambiguity becomes an =
issue is when
>>>>>>> a client is blindly sending a patch to an unknown endpoint... in =
which case,
>>>>>>> you get whatever you end up with.
>>>>>>>=20
>>>>>>> - James
>>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> - Rob
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> --
>>>>>>>>>=20
>>>>>>>>> Markus Lanthaler
>>>>>>>>>=20
>>>>>>>>> @markuslanthaler
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> From: James M Snell [mailto:jasnell@gmail.com]
>>>>>>>>> Sent: Friday, December 14, 2012 5:41 PM
>>>>>>>>> To: Markus Lanthaler
>>>>>>>>> Cc: IETF Discussion; IETF Apps Discuss
>>>>>>>>> Subject: Re: [apps-discuss] Last Call:
>>>>>>>>>  (JSON Pointer) to =
Proposed Standard
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> JSON Pointer does not distinguish between objects and arrays. =
That is
>>>>>>>>> not determined until the pointer is applied to an actual =
object instance...
>>>>>>>>> the pointer "/1" is valid against {"1":"a"} or ["a","b"]
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler
>>>>>>>>>  wrote:
>>>>>>>>>=20
>>>>>>>>> I've asked that before but didn't get an answer. So let me ask =
again
>>>>>>>>> (even
>>>>>>>>> though I'm quite sure it has already been asked by somebody =
else).
>>>>>>>>>=20
>>>>>>>>> How does JSON Pointer distinguish between objects and arrays? =
E.g.
>>>>>>>>> consider
>>>>>>>>> the following JSON document:
>>>>>>>>>=20
>>>>>>>>> {
>>>>>>>>> "foo": "bar",
>>>>>>>>> "1": "baz"
>>>>>>>>> }
>>>>>>>>>=20
>>>>>>>>> As I read the draft, the JSON Pointer "/1" would evaluate to =
"baz" even
>>>>>>>>> though that's probably not what the author intended. Is there =
a way to
>>>>>>>>> avoid
>>>>>>>>> that?
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Thanks,
>>>>>>>>> Markus
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> --
>>>>>>>>> Markus Lanthaler
>>>>>>>>> @markuslanthaler
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>>>>>>>>>> bounces@ietf.org] On Behalf Of The IESG
>>>>>>>>>> Sent: Tuesday, December 11, 2012 4:01 PM
>>>>>>>>>> To: IETF-Announce
>>>>>>>>>> Cc: apps-discuss@ietf.org
>>>>>>>>>> Subject: [apps-discuss] Last Call: =
>>>>>>>>> 07.txt> (JSON Pointer) to Proposed Standard
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> The IESG has received a request from the Applications Area =
Working
>>>>>>>>>> Group
>>>>>>>>>> WG (appsawg) to consider the following document:
>>>>>>>>>> - 'JSON Pointer'
>>>>>>>>>>  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-12-25. 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
>>>>>>>>>> JSON Pointer defines a string syntax for identifying a =
specific
>>>>>>>>>> value
>>>>>>>>>> within a JSON document.
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> The file can be obtained via
>>>>>>>>>> =
http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/
>>>>>>>>>>=20
>>>>>>>>>> IESG discussion can be tracked via
>>>>>>>>>>=20
>>>>>>>>>> =
http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> No IPR declarations have been submitted directly on this I-D.
>>>>>>>>>>=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
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> apps-discuss mailing list
>>>>>>>>> apps-discuss@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> apps-discuss mailing list
>>>>>>> apps-discuss@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>> Matthew P. C. Morley
>>>>> _______________________________________________
>>>>> 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
>>=20
>> --
>> Mark Nottingham   http://www.mnot.net/
>>=20
>>=20
>>=20

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




From sayrer@gmail.com  Sat Jan  5 20:20:22 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7084221F889A; Sat,  5 Jan 2013 20:20:22 -0800 (PST)
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 lP0EABJFvl7N; Sat,  5 Jan 2013 20:20:20 -0800 (PST)
Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by ietfa.amsl.com (Postfix) with ESMTP id 54C9321F86D2; Sat,  5 Jan 2013 20:20:20 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id u3so8590697wey.2 for ; Sat, 05 Jan 2013 20:20:19 -0800 (PST)
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=u1BsyZimtWLoOOmBKOLEKpqVQ3ZNJbjzgTOYlEhX4Pc=; b=mgr03Yxq3oci2e0OpTCuwnyDwe/APllCjQdiRbhSaC+xB9ZlbQrAOIdslgCjDCRBJS ylSwuh0MbWcYAcrJ1aWgKZf3INcz26RaOgDHVN30yafBjfvgkDacm/ymMpjSJz9ZeP/g UDg6igmg3bskt1E7cb5lPKQH6Ocx8/b/zcsdlAG+HkHR3DuhbPUWzXgFvFAPBYWiza0R MIOoANZ6KPAEMLnX5nUzcQLX8mluvMp/XDhe1aHeVnBnWfl2pDi9CJxO07k3wxwx9C9U EDnAyrx8SF6ibXHaabYTQYy7OugBLJYSebbNk8aU8Leewr1i3QDdWE492fhTudRNDiLT AWuQ==
MIME-Version: 1.0
Received: by 10.180.88.40 with SMTP id bd8mr3777178wib.33.1357446019252; Sat, 05 Jan 2013 20:20:19 -0800 (PST)
Received: by 10.194.1.101 with HTTP; Sat, 5 Jan 2013 20:20:19 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <263BA4B0-6401-4391-A369-A90863D9A4BC@mnot.net>  
Date: Sat, 5 Jan 2013 20:20:19 -0800
Message-ID: 
From: Robert Sayre 
To: Mark Nottingham 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Sun, 06 Jan 2013 04:20:22 -0000

On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham  wrote:
>
> Yes, you've brought that to our attention several times. If you wanted
> this spec to align with your software, it would have been much easier
> if you'd got involved before Last Call.

Well, there shouldn't be any big adjustments to my software at all,
and the document generally looks good. This is just a bug: two parties
can apply the same patch and get different results, without
encountering an error.

>>> However, I'm even more interested in getting this format published,
>>
>> Well, I guess someone has something they want to ship...
>
> Right. I'll let that statement stand on its own; I think anyone who's bee=
n
> participating or watching the WG can assess how justified it is.

Ah. I meant that the WG seems to be favoring "running code" a little
too heavily in the presence of a bug. It's an old argument, and it's
boring: "We can't change it now, there are already twelve users!"

>
> Always a pleasure, Rob.

That tone leaves something to be desired, but no matter. This is a bug
and the WG should fix it. I don't think more process emails are
necessary.

- Rob

On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham  wrote:
> On 06/01/2013, at 1:29 PM, Robert Sayre  wrote:
>
>> On Sat, Jan 5, 2013 at 5:48 PM, Mark Nottingham  wrote:
>>>
>>> However, at this point, doing so really a judgement call; we have multi=
ple implementations, and we shouldn't
>>> force them to change arbitrarily.
>>
>> The word "arbitrarily" seems inappropriate here. I raised at least
>> four technical issues and your message addresses none of them.
>
> ... and I explained why.
>
>
>>> As far as I can see, you haven't convinced anyone that this is a seriou=
s enough problem to do so (and I don't
>>> appear to be the only one to hold that opinion, by any means).
>>
>> Did you read this thread? Markus Lanthaler and Conal Tuohy raised
>> similar points.
>
> Yes.
>
>
>>> Furthermore, it's not clear that the use cases you have in mind (since =
you have brought up JSON Sync)
>>> are in-scope for these specifications.
>>
>> That assertion is both unsubstantiated and incorrect. json-sync has
>> identical primitive operations to JSON Patch (create/edit/remove vs
>> add/replace/remove). The JSON Patch document defines Copy and Move in
>> terms of the add/replace, so those are mostly syntactic sugar. The
>> only meaningful delta is the "test" operation, and I do plan to add
>> that to json-sync, since it's a good way to make application-specific
>> assertions.
>
> Yes, you've brought that to our attention several times. If you wanted th=
is spec to align with your software, it would have been much easier if you'=
d got involved before Last Call.
>
>
>>> However, I'm even more interested in getting this format published,
>>
>> Well, I guess someone has something they want to ship...
>
> Right. I'll let that statement stand on its own; I think anyone who's bee=
n participating or watching the WG can assess how justified it is.
>
> Always a pleasure, Rob.
>
>
>>
>> - Rob
>>
>>> Cheers,
>>>
>>>
>>> On 06/01/2013, at 11:19 AM, Robert Sayre  wrote:
>>>
>>>> Mark,
>>>>
>>>> The WG's reasoning, as stated in your message below, seems flawed.
>>>> Messages since your last communication on this matter have shown:
>>>>
>>>> 1) The ambiguity around arrays makes the patch format unsuitable for
>>>> common concurrent editing algorithms.
>>>> 2) The ambiguity is likely to occur in the real world, for a couple of
>>>> different reasons.
>>>> 3) It's not possible to tell whether a JSON Pointer document is
>>>> syntactically correct in isolation.
>>>>
>>>> Additionally, you raised this point in your message below:
>>>>>
>>>>> the patch author already has to understand the semantics of the docum=
ent they're patching
>>>>
>>>> That claim does not seem to be well-justified, and it could be
>>>> meaningless to the person implementing patch software (for example:
>>>> https://github.com/sayrer/json-sync).
>>>>
>>>> This issue is a problem in practice, and it's a problem in theory as
>>>> well. JSON-Patch messages aren't sufficiently self-descriptive, so
>>>> they aren't appropriate for use in a RESTful system.
>>>>
>>>> A response containing technical reasoning seems in order, since the
>>>> points raised by myself and others on this issue are unrelated to the
>>>> WG's previous thinking.
>>>>
>>>> - Rob
>>>>
>>>> On Sun, Dec 16, 2012 at 9:41 PM, Mark Nottingham  wrote=
:
>>>>> Robert,
>>>>>
>>>>> This was discussed extensively in the Working Group.
>>>>>
>>>>> The root of the issue was that some people reflexively felt that this=
 was necessary, but upon reflection, we decided it wasn't; although it seem=
s "natural" to some, especially those coming from a static language backgro=
und, it didn't provide any utility.
>>>>>
>>>>> You might argue that someone who (for example) adds to "/foo/1" in th=
e mistaken belief that it's an array, when in fact it's an object, will get=
 surprising results. That's true, but if we were to solve this problem, tha=
t person would still need to understand the underlying semantics of "foo" t=
o do anything useful to it -- and I'm not hearing anyone complain about tha=
t (I hope).
>>>>>
>>>>> Put another way -- do you really think that people PATCHing something=
 as if it's an array (when in fact it's an object) is a significant, real-w=
orld problem, given that the patch author already has to understand the sem=
antics of the document they're patching? I don't, and the WG didn't either.
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> On 17/12/2012, at 3:36 PM, Robert Sayre  wrote:
>>>>>
>>>>>> The cost of fixing it seems low, either by changing the path syntax =
of
>>>>>> JSON pointer or changing the names of operations applied to arrays.
>>>>>> Array-like objects are common enough in JavaScript to make this a
>>>>>> worry. The other suggestions either assume a particular policy for
>>>>>> concurrent edits or require more machinery (test operation etc).
>>>>>> Wouldn't it be simpler to make the patch format more precise?
>>>>>>
>>>>>> - Rob
>>>>>>
>>>>>> On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley  wrot=
e:
>>>>>>> I am usually lurking and struggling to keep up with these posts. Bu=
t, I
>>>>>>> concur with James, this really is a non-issue in practice.
>>>>>>>
>>>>>>> The JSON Pointer expresses a path down a JSON object to a specific =
context.
>>>>>>> The Patch expresses a change within or to that context.
>>>>>>> Everything about the both standards is about that end context.
>>>>>>>
>>>>>>> If you want to confirm the type of the context before applying a pa=
tch, this
>>>>>>> should probably be part of a test operation. I'm not sure if this i=
s
>>>>>>> possible at this point (?), but that is where the logic should exis=
t.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Dec 16, 2012 at 12:22 AM, James M Snell =
 wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre  w=
rote:
>>>>>>>>>
>>>>>>>>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler
>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>> Hmm.. I think that=92s quite problematic. Especially considering=
 how JSON
>>>>>>>>>> Pointer is used in JSON Patch.
>>>>>>>>>
>>>>>>>>> I agree--I provided the same feedback privately. It seems
>>>>>>>>> straightforwardly unsound.
>>>>>>>>>
>>>>>>>>
>>>>>>>> In practice it doesn't seem to be much of an issue.
>>>>>>>>
>>>>>>>> Specifically, if I GET an existing document and get an etag with t=
he JSON,
>>>>>>>> then make some changes and send a PATCH with If-Match, the fact th=
at any
>>>>>>>> given pointer could point to an array or object member doesn't rea=
lly matter
>>>>>>>> much.
>>>>>>>>
>>>>>>>> For example:
>>>>>>>>
>>>>>>>>> GET /the/doc HTTP/1.1
>>>>>>>>
>>>>>>>> <  HTTP/1.1 200 OK
>>>>>>>>   ETag: "my-document-tag"
>>>>>>>>   Content-Type: application/json
>>>>>>>>
>>>>>>>>   {"1":"foo"}
>>>>>>>>
>>>>>>>>> PATCH /the/doc HTTP/1.1
>>>>>>>>   If-Match: "my-document-etag"
>>>>>>>>   Content-Type: application/json-patch
>>>>>>>>
>>>>>>>>   [{"op":"add","path":"/2","value":"bar"}]
>>>>>>>>
>>>>>>>> Generally speaking, someone should not be using PATCH to perform a=
 partial
>>>>>>>> modification if they don't already have some knowledge in advance =
what they
>>>>>>>> are modifying. The only time the apparent ambiguity becomes an iss=
ue is when
>>>>>>>> a client is blindly sending a patch to an unknown endpoint... in w=
hich case,
>>>>>>>> you get whatever you end up with.
>>>>>>>>
>>>>>>>> - James
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> - Rob
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> Markus Lanthaler
>>>>>>>>>>
>>>>>>>>>> @markuslanthaler
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> From: James M Snell [mailto:jasnell@gmail.com]
>>>>>>>>>> Sent: Friday, December 14, 2012 5:41 PM
>>>>>>>>>> To: Markus Lanthaler
>>>>>>>>>> Cc: IETF Discussion; IETF Apps Discuss
>>>>>>>>>> Subject: Re: [apps-discuss] Last Call:
>>>>>>>>>>  (JSON Pointer) to Propo=
sed Standard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> JSON Pointer does not distinguish between objects and arrays. Th=
at is
>>>>>>>>>> not determined until the pointer is applied to an actual object =
instance...
>>>>>>>>>> the pointer "/1" is valid against {"1":"a"} or ["a","b"]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler
>>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>> I've asked that before but didn't get an answer. So let me ask a=
gain
>>>>>>>>>> (even
>>>>>>>>>> though I'm quite sure it has already been asked by somebody else=
).
>>>>>>>>>>
>>>>>>>>>> How does JSON Pointer distinguish between objects and arrays? E.=
g.
>>>>>>>>>> consider
>>>>>>>>>> the following JSON document:
>>>>>>>>>>
>>>>>>>>>> {
>>>>>>>>>> "foo": "bar",
>>>>>>>>>> "1": "baz"
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> As I read the draft, the JSON Pointer "/1" would evaluate to "ba=
z" even
>>>>>>>>>> though that's probably not what the author intended. Is there a =
way to
>>>>>>>>>> avoid
>>>>>>>>>> that?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Markus
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Markus Lanthaler
>>>>>>>>>> @markuslanthaler
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>>>>>>>>>>> bounces@ietf.org] On Behalf Of The IESG
>>>>>>>>>>> Sent: Tuesday, December 11, 2012 4:01 PM
>>>>>>>>>>> To: IETF-Announce
>>>>>>>>>>> Cc: apps-discuss@ietf.org
>>>>>>>>>>> Subject: [apps-discuss] Last Call: >>>>>>>>>> 07.txt> (JSON Pointer) to Proposed Standard
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The IESG has received a request from the Applications Area Work=
ing
>>>>>>>>>>> Group
>>>>>>>>>>> WG (appsawg) to consider the following document:
>>>>>>>>>>> - 'JSON Pointer'
>>>>>>>>>>>  as Proposed Standard
>>>>>>>>>>>
>>>>>>>>>>> The IESG plans to make a decision in the next few weeks, and so=
licits
>>>>>>>>>>> final comments on this action. Please send substantive comments=
 to
>>>>>>>>>>> the
>>>>>>>>>>> ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comme=
nts
>>>>>>>>>>> may
>>>>>>>>>>> be
>>>>>>>>>>> sent to iesg@ietf.org instead. In either case, please retain th=
e
>>>>>>>>>>> beginning of the Subject line to allow automated sorting.
>>>>>>>>>>>
>>>>>>>>>>> Abstract
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> JSON Pointer defines a string syntax for identifying a specific
>>>>>>>>>>> value
>>>>>>>>>>> within a JSON document.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The file can be obtained via
>>>>>>>>>>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer=
/
>>>>>>>>>>>
>>>>>>>>>>> IESG discussion can be tracked via
>>>>>>>>>>>
>>>>>>>>>>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer=
/ballot/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No IPR declarations have been submitted directly on this I-D.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matthew P. C. Morley
>>>>>> _______________________________________________
>>>>>> 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/
>>>
>>>
>>>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>

From jasnell@gmail.com  Sat Jan  5 20:55:55 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84D521F86C4; Sat,  5 Jan 2013 20:55:55 -0800 (PST)
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 DRtl7gQwfgIO; Sat,  5 Jan 2013 20:55:53 -0800 (PST)
Received: from mail-ia0-f171.google.com (mail-ia0-f171.google.com [209.85.210.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7209521F86C2; Sat,  5 Jan 2013 20:55:53 -0800 (PST)
Received: by mail-ia0-f171.google.com with SMTP id k27so15146355iad.16 for ; Sat, 05 Jan 2013 20:55:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/JERQDQf9uDDkvBq41BVGCG4CD7+NP7w3V0emDQU7Uw=; b=Wp0CM3kstpkPa0/WhRKXWUZCytcBqCt/Fd10arLafkZ7GUxmaTO+tbt8ZnfgNGYcCU ryeEIDp0nZWYaXel5YsbhZ2MXkG1vnOXmyV9aDSKxZfQx5Q5d1Paknm1tAGbnytAH9Tk 4XJ8XbBakI3DZX8iVOF4rHpCMVih9XIhmSiIHgibFik24Jjt0EAJqufkeTrfjwHZlDqz DDA0MiJoP2NblMCy8EyIUQnKhltGvJ9heUDUuAfJ+hkk5PndnJhSnfJ+aeXLesEtUtKx X3ldVsj3RG8zsmJHB/cXjpPcYEg8Lprv+gzUVgy+uhSTC3OlXHixZQ8gXVQC9NebuA0+ FtQg==
MIME-Version: 1.0
X-Received: by 10.50.178.10 with SMTP id cu10mr2721943igc.75.1357448152974; Sat, 05 Jan 2013 20:55:52 -0800 (PST)
Received: by 10.64.7.19 with HTTP; Sat, 5 Jan 2013 20:55:52 -0800 (PST)
Received: by 10.64.7.19 with HTTP; Sat, 5 Jan 2013 20:55:52 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <263BA4B0-6401-4391-A369-A90863D9A4BC@mnot.net>   
Date: Sat, 5 Jan 2013 20:55:52 -0800
Message-ID: 
From: James M Snell 
To: Rob Sayre 
Content-Type: multipart/alternative; boundary=e89a8f839ca1f5860704d2978658
Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Sun, 06 Jan 2013 04:55:56 -0000

--e89a8f839ca1f5860704d2978658
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Jan 5, 2013 8:20 PM, "Robert Sayre"  wrote:
>
> On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham  wrote:
> >
> > Yes, you've brought that to our attention several times. If you wanted
> > this spec to align with your software, it would have been much easier
> > if you'd got involved before Last Call.
>
> Well, there shouldn't be any big adjustments to my software at all,
> and the document generally looks good. This is just a bug: two parties
> can apply the same patch and get different results, without
> encountering an error.
>

Not seeing the bug... applying the same patch to different resources that
have different states ought to have different results. #worksasintended
#wontfix #moveonthereisnothingmoretoseehere

- james

> >>> However, I'm even more interested in getting this format published,
> >>
> >> Well, I guess someone has something they want to ship...
> >
> > Right. I'll let that statement stand on its own; I think anyone who's
been
> > participating or watching the WG can assess how justified it is.
>
> Ah. I meant that the WG seems to be favoring "running code" a little
> too heavily in the presence of a bug. It's an old argument, and it's
> boring: "We can't change it now, there are already twelve users!"
>
> >
> > Always a pleasure, Rob.
>
> That tone leaves something to be desired, but no matter. This is a bug
> and the WG should fix it. I don't think more process emails are
> necessary.
>
> - Rob
>
> On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham  wrote:
> > On 06/01/2013, at 1:29 PM, Robert Sayre  wrote:
> >
> >> On Sat, Jan 5, 2013 at 5:48 PM, Mark Nottingham  wrote:
> >>>
> >>> However, at this point, doing so really a judgement call; we have
multiple implementations, and we shouldn't
> >>> force them to change arbitrarily.
> >>
> >> The word "arbitrarily" seems inappropriate here. I raised at least
> >> four technical issues and your message addresses none of them.
> >
> > ... and I explained why.
> >
> >
> >>> As far as I can see, you haven't convinced anyone that this is a
serious enough problem to do so (and I don't
> >>> appear to be the only one to hold that opinion, by any means).
> >>
> >> Did you read this thread? Markus Lanthaler and Conal Tuohy raised
> >> similar points.
> >
> > Yes.
> >
> >
> >>> Furthermore, it's not clear that the use cases you have in mind
(since you have brought up JSON Sync)
> >>> are in-scope for these specifications.
> >>
> >> That assertion is both unsubstantiated and incorrect. json-sync has
> >> identical primitive operations to JSON Patch (create/edit/remove vs
> >> add/replace/remove). The JSON Patch document defines Copy and Move in
> >> terms of the add/replace, so those are mostly syntactic sugar. The
> >> only meaningful delta is the "test" operation, and I do plan to add
> >> that to json-sync, since it's a good way to make application-specific
> >> assertions.
> >
> > Yes, you've brought that to our attention several times. If you wanted
this spec to align with your software, it would have been much easier if
you'd got involved before Last Call.
> >
> >
> >>> However, I'm even more interested in getting this format published,
> >>
> >> Well, I guess someone has something they want to ship...
> >
> > Right. I'll let that statement stand on its own; I think anyone who's
been participating or watching the WG can assess how justified it is.
> >
> > Always a pleasure, Rob.
> >
> >
> >>
> >> - Rob
> >>
> >>> Cheers,
> >>>
> >>>
> >>> On 06/01/2013, at 11:19 AM, Robert Sayre  wrote:
> >>>
> >>>> Mark,
> >>>>
> >>>> The WG's reasoning, as stated in your message below, seems flawed.
> >>>> Messages since your last communication on this matter have shown:
> >>>>
> >>>> 1) The ambiguity around arrays makes the patch format unsuitable for
> >>>> common concurrent editing algorithms.
> >>>> 2) The ambiguity is likely to occur in the real world, for a couple
of
> >>>> different reasons.
> >>>> 3) It's not possible to tell whether a JSON Pointer document is
> >>>> syntactically correct in isolation.
> >>>>
> >>>> Additionally, you raised this point in your message below:
> >>>>>
> >>>>> the patch author already has to understand the semantics of the
document they're patching
> >>>>
> >>>> That claim does not seem to be well-justified, and it could be
> >>>> meaningless to the person implementing patch software (for example:
> >>>> https://github.com/sayrer/json-sync).
> >>>>
> >>>> This issue is a problem in practice, and it's a problem in theory as
> >>>> well. JSON-Patch messages aren't sufficiently self-descriptive, so
> >>>> they aren't appropriate for use in a RESTful system.
> >>>>
> >>>> A response containing technical reasoning seems in order, since the
> >>>> points raised by myself and others on this issue are unrelated to th=
e
> >>>> WG's previous thinking.
> >>>>
> >>>> - Rob
> >>>>
> >>>> On Sun, Dec 16, 2012 at 9:41 PM, Mark Nottingham 
wrote:
> >>>>> Robert,
> >>>>>
> >>>>> This was discussed extensively in the Working Group.
> >>>>>
> >>>>> The root of the issue was that some people reflexively felt that
this was necessary, but upon reflection, we decided it wasn't; although it
seems "natural" to some, especially those coming from a static language
background, it didn't provide any utility.
> >>>>>
> >>>>> You might argue that someone who (for example) adds to "/foo/1" in
the mistaken belief that it's an array, when in fact it's an object, will
get surprising results. That's true, but if we were to solve this problem,
that person would still need to understand the underlying semantics of
"foo" to do anything useful to it -- and I'm not hearing anyone complain
about that (I hope).
> >>>>>
> >>>>> Put another way -- do you really think that people PATCHing
something as if it's an array (when in fact it's an object) is a
significant, real-world problem, given that the patch author already has to
understand the semantics of the document they're patching? I don't, and the
WG didn't either.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>>
> >>>>> On 17/12/2012, at 3:36 PM, Robert Sayre  wrote:
> >>>>>
> >>>>>> The cost of fixing it seems low, either by changing the path
syntax of
> >>>>>> JSON pointer or changing the names of operations applied to arrays=
.
> >>>>>> Array-like objects are common enough in JavaScript to make this a
> >>>>>> worry. The other suggestions either assume a particular policy for
> >>>>>> concurrent edits or require more machinery (test operation etc).
> >>>>>> Wouldn't it be simpler to make the patch format more precise?
> >>>>>>
> >>>>>> - Rob
> >>>>>>
> >>>>>> On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley 
wrote:
> >>>>>>> I am usually lurking and struggling to keep up with these posts.
But, I
> >>>>>>> concur with James, this really is a non-issue in practice.
> >>>>>>>
> >>>>>>> The JSON Pointer expresses a path down a JSON object to a
specific context.
> >>>>>>> The Patch expresses a change within or to that context.
> >>>>>>> Everything about the both standards is about that end context.
> >>>>>>>
> >>>>>>> If you want to confirm the type of the context before applying a
patch, this
> >>>>>>> should probably be part of a test operation. I'm not sure if this
is
> >>>>>>> possible at this point (?), but that is where the logic should
exist.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Sun, Dec 16, 2012 at 12:22 AM, James M Snell 
wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre 
wrote:
> >>>>>>>>>
> >>>>>>>>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler
> >>>>>>>>>  wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hmm.. I think that=E2=80=99s quite problematic. Especially con=
sidering
how JSON
> >>>>>>>>>> Pointer is used in JSON Patch.
> >>>>>>>>>
> >>>>>>>>> I agree--I provided the same feedback privately. It seems
> >>>>>>>>> straightforwardly unsound.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> In practice it doesn't seem to be much of an issue.
> >>>>>>>>
> >>>>>>>> Specifically, if I GET an existing document and get an etag with
the JSON,
> >>>>>>>> then make some changes and send a PATCH with If-Match, the fact
that any
> >>>>>>>> given pointer could point to an array or object member doesn't
really matter
> >>>>>>>> much.
> >>>>>>>>
> >>>>>>>> For example:
> >>>>>>>>
> >>>>>>>>> GET /the/doc HTTP/1.1
> >>>>>>>>
> >>>>>>>> <  HTTP/1.1 200 OK
> >>>>>>>>   ETag: "my-document-tag"
> >>>>>>>>   Content-Type: application/json
> >>>>>>>>
> >>>>>>>>   {"1":"foo"}
> >>>>>>>>
> >>>>>>>>> PATCH /the/doc HTTP/1.1
> >>>>>>>>   If-Match: "my-document-etag"
> >>>>>>>>   Content-Type: application/json-patch
> >>>>>>>>
> >>>>>>>>   [{"op":"add","path":"/2","value":"bar"}]
> >>>>>>>>
> >>>>>>>> Generally speaking, someone should not be using PATCH to perform
a partial
> >>>>>>>> modification if they don't already have some knowledge in
advance what they
> >>>>>>>> are modifying. The only time the apparent ambiguity becomes an
issue is when
> >>>>>>>> a client is blindly sending a patch to an unknown endpoint... in
which case,
> >>>>>>>> you get whatever you end up with.
> >>>>>>>>
> >>>>>>>> - James
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> - Rob
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>>
> >>>>>>>>>> Markus Lanthaler
> >>>>>>>>>>
> >>>>>>>>>> @markuslanthaler
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> From: James M Snell [mailto:jasnell@gmail.com]
> >>>>>>>>>> Sent: Friday, December 14, 2012 5:41 PM
> >>>>>>>>>> To: Markus Lanthaler
> >>>>>>>>>> Cc: IETF Discussion; IETF Apps Discuss
> >>>>>>>>>> Subject: Re: [apps-discuss] Last Call:
> >>>>>>>>>>  (JSON Pointer) to
Proposed Standard
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> JSON Pointer does not distinguish between objects and arrays.
That is
> >>>>>>>>>> not determined until the pointer is applied to an actual
object instance...
> >>>>>>>>>> the pointer "/1" is valid against {"1":"a"} or ["a","b"]
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler
> >>>>>>>>>>  wrote:
> >>>>>>>>>>
> >>>>>>>>>> I've asked that before but didn't get an answer. So let me ask
again
> >>>>>>>>>> (even
> >>>>>>>>>> though I'm quite sure it has already been asked by somebody
else).
> >>>>>>>>>>
> >>>>>>>>>> How does JSON Pointer distinguish between objects and arrays?
E.g.
> >>>>>>>>>> consider
> >>>>>>>>>> the following JSON document:
> >>>>>>>>>>
> >>>>>>>>>> {
> >>>>>>>>>> "foo": "bar",
> >>>>>>>>>> "1": "baz"
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> As I read the draft, the JSON Pointer "/1" would evaluate to
"baz" even
> >>>>>>>>>> though that's probably not what the author intended. Is there
a way to
> >>>>>>>>>> avoid
> >>>>>>>>>> that?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> Markus
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Markus Lanthaler
> >>>>>>>>>> @markuslanthaler
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> >>>>>>>>>>> bounces@ietf.org] On Behalf Of The IESG
> >>>>>>>>>>> Sent: Tuesday, December 11, 2012 4:01 PM
> >>>>>>>>>>> To: IETF-Announce
> >>>>>>>>>>> Cc: apps-discuss@ietf.org
> >>>>>>>>>>> Subject: [apps-discuss] Last Call:
 >>>>>>>>>>> 07.txt> (JSON Pointer) to Proposed Standard
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> The IESG has received a request from the Applications Area
Working
> >>>>>>>>>>> Group
> >>>>>>>>>>> WG (appsawg) to consider the following document:
> >>>>>>>>>>> - 'JSON Pointer'
> >>>>>>>>>>>  as Proposed Standard
> >>>>>>>>>>>
> >>>>>>>>>>> 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-12-25. 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.
> >>>>>>>>>>>
> >>>>>>>>>>> Abstract
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> JSON Pointer defines a string syntax for identifying a
specific
> >>>>>>>>>>> value
> >>>>>>>>>>> within a JSON document.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> The file can be obtained via
> >>>>>>>>>>>
http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/
> >>>>>>>>>>>
> >>>>>>>>>>> IESG discussion can be tracked via
> >>>>>>>>>>>
> >>>>>>>>>>>
http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> No IPR declarations have been submitted directly on this I-D.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> 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
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Matthew P. C. Morley
> >>>>>> _______________________________________________
> >>>>>> 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/
> >>>
> >>>
> >>>
> >
> > --
> > Mark Nottingham   http://www.mnot.net/
> >
> >
> >
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--e89a8f839ca1f5860704d2978658
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Jan 5, 2013 8:20 PM, "Robert Sayre" <sayrer@gmail.com> wrote:

>

> On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham <mnot@mnot.net> wrote:

> >

> > Yes, you've brought that to our attention several times. If y=
ou wanted

> > this spec to align with your software, it would have been much ea=
sier

> > if you'd got involved before Last Call.

>

> Well, there shouldn't be any big adjustments to my software at all=
,

> and the document generally looks good. This is just a bug: two parties=


> can apply the same patch and get different results, without

> encountering an error.

>


Not seeing the bug... applying the same patch to different r=
esources that have different states ought to have different results. #works=
asintended #wontfix #moveonthereisnothingmoretoseehere


- james


> >>> However, I'm even more interested in g=
etting this format published,

> >>

> >> Well, I guess someone has something they want to ship...

> >

> > Right. I'll let that statement stand on its own; I think anyo=
ne who's been

> > participating or watching the WG can assess how justified it is.<=
br>
>

> Ah. I meant that the WG seems to be favoring "running code" =
a little

> too heavily in the presence of a bug. It's an old argument, and it=
's

> boring: "We can't change it now, there are already twelve use=
rs!"

>

> >

> > Always a pleasure, Rob.

>

> That tone leaves something to be desired, but no matter. This is a bug=


> and the WG should fix it. I don't think more process emails are
> necessary.

>

> - Rob

>

> On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham <mnot@mnot.net> wrote:

> > On 06/01/2013, at 1:29 PM, Robert Sayre <sayrer@gmail.com> wrote:

> >

> >> On Sat, Jan 5, 2013 at 5:48 PM, Mark Nottingham <mnot@mnot.net> wrote:

> >>>

> >>> However, at this point, doing so really a judgement call;=
 we have multiple implementations, and we shouldn't

> >>> force them to change arbitrarily.

> >>

> >> The word "arbitrarily" seems inappropriate here. I =
raised at least

> >> four technical issues and your message addresses none of them=
.

> >

> > ... and I explained why.

> >

> >

> >>> As far as I can see, you haven't convinced anyone tha=
t this is a serious enough problem to do so (and I don't

> >>> appear to be the only one to hold that opinion, by any me=
ans).

> >>

> >> Did you read this thread? Markus Lanthaler and Conal Tuohy ra=
ised

> >> similar points.

> >

> > Yes.

> >

> >

> >>> Furthermore, it's not clear that the use cases you ha=
ve in mind (since you have brought up JSON Sync)

> >>> are in-scope for these specifications.

> >>

> >> That assertion is both unsubstantiated and incorrect. json-sy=
nc has

> >> identical primitive operations to JSON Patch (create/edit/rem=
ove vs

> >> add/replace/remove). The JSON Patch document defines Copy and=
 Move in

> >> terms of the add/replace, so those are mostly syntactic sugar=
. The

> >> only meaningful delta is the "test" operation, and =
I do plan to add

> >> that to json-sync, since it's a good way to make applicat=
ion-specific

> >> assertions.

> >

> > Yes, you've brought that to our attention several times. If y=
ou wanted this spec to align with your software, it would have been much ea=
sier if you'd got involved before Last Call.

> >

> >

> >>> However, I'm even more interested in getting this for=
mat published,

> >>

> >> Well, I guess someone has something they want to ship...

> >

> > Right. I'll let that statement stand on its own; I think anyo=
ne who's been participating or watching the WG can assess how justified=
 it is.

> >

> > Always a pleasure, Rob.

> >

> >

> >>

> >> - Rob

> >>

> >>> Cheers,

> >>>

> >>>

> >>> On 06/01/2013, at 11:19 AM, Robert Sayre <sayrer@gmail.com> wrote:

> >>>

> >>>> Mark,

> >>>>

> >>>> The WG's reasoning, as stated in your message bel=
ow, seems flawed.

> >>>> Messages since your last communication on this matter=
 have shown:

> >>>>

> >>>> 1) The ambiguity around arrays makes the patch format=
 unsuitable for

> >>>> common concurrent editing algorithms.

> >>>> 2) The ambiguity is likely to occur in the real world=
, for a couple of

> >>>> different reasons.

> >>>> 3) It's not possible to tell whether a JSON Point=
er document is

> >>>> syntactically correct in isolation.

> >>>>

> >>>> Additionally, you raised this point in your message b=
elow:

> >>>>>

> >>>>> the patch author already has to understand the se=
mantics of the document they're patching

> >>>>

> >>>> That claim does not seem to be well-justified, and it=
 could be

> >>>> meaningless to the person implementing patch software=
 (for example:

> >>>> https=
://github.com/sayrer/json-sync).

> >>>>

> >>>> This issue is a problem in practice, and it's a p=
roblem in theory as

> >>>> well. JSON-Patch messages aren't sufficiently sel=
f-descriptive, so

> >>>> they aren't appropriate for use in a RESTful syst=
em.

> >>>>

> >>>> A response containing technical reasoning seems in or=
der, since the

> >>>> points raised by myself and others on this issue are =
unrelated to the

> >>>> WG's previous thinking.

> >>>>

> >>>> - Rob

> >>>>

> >>>> On Sun, Dec 16, 2012 at 9:41 PM, Mark Nottingham <=
mnot@mnot.net> wrote:

> >>>>> Robert,

> >>>>>

> >>>>> This was discussed extensively in the Working Gro=
up.

> >>>>>

> >>>>> The root of the issue was that some people reflex=
ively felt that this was necessary, but upon reflection, we decided it wasn=
't; although it seems "natural" to some, especially those com=
ing from a static language background, it didn't provide any utility.

> >>>>>

> >>>>> You might argue that someone who (for example) ad=
ds to "/foo/1" in the mistaken belief that it's an array, whe=
n in fact it's an object, will get surprising results. That's true,=
 but if we were to solve this problem, that person would still need to unde=
rstand the underlying semantics of "foo" to do anything useful to=
 it -- and I'm not hearing anyone complain about that (I hope).


> >>>>>

> >>>>> Put another way -- do you really think that peopl=
e PATCHing something as if it's an array (when in fact it's an obje=
ct) is a significant, real-world problem, given that the patch author alrea=
dy has to understand the semantics of the document they're patching? I =
don't, and the WG didn't either.


> >>>>>

> >>>>> Regards,

> >>>>>

> >>>>>

> >>>>> On 17/12/2012, at 3:36 PM, Robert Sayre <sayrer@gmail.com> wrote:

> >>>>>

> >>>>>> The cost of fixing it seems low, either by ch=
anging the path syntax of

> >>>>>> JSON pointer or changing the names of operati=
ons applied to arrays.

> >>>>>> Array-like objects are common enough in JavaS=
cript to make this a

> >>>>>> worry. The other suggestions either assume a =
particular policy for

> >>>>>> concurrent edits or require more machinery (t=
est operation etc).

> >>>>>> Wouldn't it be simpler to make the patch =
format more precise?

> >>>>>>

> >>>>>> - Rob

> >>>>>>

> >>>>>> On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morl=
ey <matt@mpcm.com> wrote:

> >>>>>>> I am usually lurking and struggling to ke=
ep up with these posts. But, I

> >>>>>>> concur with James, this really is a non-i=
ssue in practice.

> >>>>>>>

> >>>>>>> The JSON Pointer expresses a path down a =
JSON object to a specific context.

> >>>>>>> The Patch expresses a change within or to=
 that context.

> >>>>>>> Everything about the both standards is ab=
out that end context.

> >>>>>>>

> >>>>>>> If you want to confirm the type of the co=
ntext before applying a patch, this

> >>>>>>> should probably be part of a test operati=
on. I'm not sure if this is

> >>>>>>> possible at this point (?), but that is w=
here the logic should exist.

> >>>>>>>

> >>>>>>>

> >>>>>>>

> >>>>>>> On Sun, Dec 16, 2012 at 12:22 AM, James M=
 Snell <jasnell@gmail.com> w=
rote:

> >>>>>>>>

> >>>>>>>>

> >>>>>>>>

> >>>>>>>>

> >>>>>>>> On Sat, Dec 15, 2012 at 8:36 PM, Robe=
rt Sayre <sayrer@gmail.com> w=
rote:

> >>>>>>>>>

> >>>>>>>>> On Fri, Dec 14, 2012 at 9:17 AM, =
Markus Lanthaler

> >>>>>>>>> <markus.lanthaler@gmx.net> wrote:

> >>>>>>>>>>

> >>>>>>>>>> Hmm.. I think that=E2=80=99s =
quite problematic. Especially considering how JSON

> >>>>>>>>>> Pointer is used in JSON Patch=
.

> >>>>>>>>>

> >>>>>>>>> I agree--I provided the same feed=
back privately. It seems

> >>>>>>>>> straightforwardly unsound.

> >>>>>>>>>

> >>>>>>>>

> >>>>>>>> In practice it doesn't seem to be=
 much of an issue.

> >>>>>>>>

> >>>>>>>> Specifically, if I GET an existing do=
cument and get an etag with the JSON,

> >>>>>>>> then make some changes and send a PAT=
CH with If-Match, the fact that any

> >>>>>>>> given pointer could point to an array=
 or object member doesn't really matter

> >>>>>>>> much.

> >>>>>>>>

> >>>>>>>> For example:

> >>>>>>>>

> >>>>>>>>> GET /the/doc HTTP/1.1

> >>>>>>>>

> >>>>>>>> < =C2=A0HTTP/1.1 200 OK

> >>>>>>>> =C2=A0 ETag: "my-document-tag&qu=
ot;

> >>>>>>>> =C2=A0 Content-Type: application/json=


> >>>>>>>>

> >>>>>>>> =C2=A0 {"1":"foo"=
}

> >>>>>>>>

> >>>>>>>>> PATCH /the/doc HTTP/1.1

> >>>>>>>> =C2=A0 If-Match: "my-document-et=
ag"

> >>>>>>>> =C2=A0 Content-Type: application/json=
-patch

> >>>>>>>>

> >>>>>>>> =C2=A0 [{"op":"add&quo=
t;,"path":"/2","value":"bar"}]

> >>>>>>>>

> >>>>>>>> Generally speaking, someone should no=
t be using PATCH to perform a partial

> >>>>>>>> modification if they don't alread=
y have some knowledge in advance what they

> >>>>>>>> are modifying. The only time the appa=
rent ambiguity becomes an issue is when

> >>>>>>>> a client is blindly sending a patch t=
o an unknown endpoint... in which case,

> >>>>>>>> you get whatever you end up with.

> >>>>>>>>

> >>>>>>>> - James

> >>>>>>>>

> >>>>>>>>

> >>>>>>>>>

> >>>>>>>>> - Rob

> >>>>>>>>>

> >>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>> --

> >>>>>>>>>>

> >>>>>>>>>> Markus Lanthaler

> >>>>>>>>>>

> >>>>>>>>>> @markuslanthaler

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>> From: James M Snell [mailto:<=
a href=3D"mailto:jasnell@gmail.com">jasnell@gmail.com]

> >>>>>>>>>> Sent: Friday, December 14, 20=
12 5:41 PM

> >>>>>>>>>> To: Markus Lanthaler

> >>>>>>>>>> Cc: IETF Discussion; IETF App=
s Discuss

> >>>>>>>>>> Subject: Re: [apps-discuss] L=
ast Call:

> >>>>>>>>>> <draft-ietf-appsawg-json-p=
ointer-07.txt> (JSON Pointer) to Proposed Standard

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>> JSON Pointer does not disting=
uish between objects and arrays. That is

> >>>>>>>>>> not determined until the poin=
ter is applied to an actual object instance...

> >>>>>>>>>> the pointer "/1" is=
 valid against {"1":"a"} or ["a","b"=
;]

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>> On Fri, Dec 14, 2012 at 2:51 =
AM, Markus Lanthaler

> >>>>>>>>>> <markus.lanthaler@gmx.net> wrote:

> >>>>>>>>>>

> >>>>>>>>>> I've asked that before bu=
t didn't get an answer. So let me ask again

> >>>>>>>>>> (even

> >>>>>>>>>> though I'm quite sure it =
has already been asked by somebody else).

> >>>>>>>>>>

> >>>>>>>>>> How does JSON Pointer disting=
uish between objects and arrays? E.g.

> >>>>>>>>>> consider

> >>>>>>>>>> the following JSON document:<=
br>
> >>>>>>>>>>

> >>>>>>>>>> {

> >>>>>>>>>> "foo": "bar&qu=
ot;,

> >>>>>>>>>> "1": "baz"=
;

> >>>>>>>>>> }

> >>>>>>>>>>

> >>>>>>>>>> As I read the draft, the JSON=
 Pointer "/1" would evaluate to "baz" even

> >>>>>>>>>> though that's probably no=
t what the author intended. Is there a way to

> >>>>>>>>>> avoid

> >>>>>>>>>> that?

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>> Thanks,

> >>>>>>>>>> Markus

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>> --

> >>>>>>>>>> Markus Lanthaler

> >>>>>>>>>> @markuslanthaler

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>> -----Original Message----=
-

> >>>>>>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-

> >>>>>>>>>>> bounces@ietf.org] On Behalf Of The IESG

> >>>>>>>>>>> Sent: Tuesday, December 1=
1, 2012 4:01 PM

> >>>>>>>>>>> To: IETF-Announce

> >>>>>>>>>>> Cc: apps-discuss@ietf.org

> >>>>>>>>>>> Subject: [apps-discuss] L=
ast Call: <draft-ietf-appsawg-json-pointer-

> >>>>>>>>>>> 07.txt> (JSON Pointer)=
 to Proposed Standard

> >>>>>>>>>>>

> >>>>>>>>>>>

> >>>>>>>>>>> The IESG has received a r=
equest from the Applications Area Working

> >>>>>>>>>>> Group

> >>>>>>>>>>> WG (appsawg) to consider =
the following document:

> >>>>>>>>>>> - 'JSON Pointer'<=
br>
> >>>>>>>>>>> <draft-ietf-appsawg-js=
on-pointer-07.txt> as Proposed Standard

> >>>>>>>>>>>

> >>>>>>>>>>> The IESG plans to make a =
decision in the next few weeks, and solicits

> >>>>>>>>>>> final comments on this ac=
tion. Please send substantive comments to

> >>>>>>>>>>> the

> >>>>>>>>>>> ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comme=
nts

> >>>>>>>>>>> may

> >>>>>>>>>>> be

> >>>>>>>>>>> sent to iesg@ietf.org instead. In either case, please retain th=
e

> >>>>>>>>>>> beginning of the Subject =
line to allow automated sorting.

> >>>>>>>>>>>

> >>>>>>>>>>> Abstract

> >>>>>>>>>>>

> >>>>>>>>>>>

> >>>>>>>>>>> JSON Pointer defines a st=
ring syntax for identifying a specific

> >>>>>>>>>>> value

> >>>>>>>>>>> within a JSON document.
> >>>>>>>>>>>

> >>>>>>>>>>>

> >>>>>>>>>>>

> >>>>>>>>>>>

> >>>>>>>>>>> The file can be obtained =
via

> >>>>>>>>>>> http://datatracker.ietf=
.org/doc/draft-ietf-appsawg-json-pointer/

> >>>>>>>>>>>

> >>>>>>>>>>> IESG discussion can be tr=
acked via

> >>>>>>>>>>>

> >>>>>>>>>>> http://datatrack=
er.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/

> >>>>>>>>>>>

> >>>>>>>>>>>

> >>>>>>>>>>> No IPR declarations have =
been submitted directly on this I-D.

> >>>>>>>>>>>

> >>>>>>>>>>>

> >>>>>>>>>>> _________________________=
______________________

> >>>>>>>>>>> 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/app=
s-discuss

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>> _____________________________=
__________________

> >>>>>>>>>> apps-discuss mailing list

> >>>>>>>>>> apps-discuss@ietf.org

> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/app=
s-discuss

> >>>>>>>>>>

> >>>>>>>>

> >>>>>>>>

> >>>>>>>>

> >>>>>>>> _____________________________________=
__________

> >>>>>>>> apps-discuss mailing list

> >>>>>>>> apps-discuss@ietf.org

> >>>>>>>> https://www.ietf.org/mailman/listinfo/apps-discus=
s

> >>>>>>>>

> >>>>>>>

> >>>>>>>

> >>>>>>>

> >>>>>>> --

> >>>>>>> Matthew P. C. Morley

> >>>>>> _____________________________________________=
__

> >>>>>> apps-discuss mailing list

> >>>>>> apps=
-discuss@ietf.org

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

> >>>>> --

> >>>>> Mark Nottingham =C2=A0 http://www.mnot.net/

> >>>>>

> >>>>>

> >>>>>

> >>>

> >>> --

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

> >>>

> >>>

> >>>

> >

> > --

> > Mark Nottingham =C2=A0 http://ww=
w.mnot.net/

> >

> >

> >

> _______________________________________________

> apps-discuss mailing list

> apps-discuss@ietf.org

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




--e89a8f839ca1f5860704d2978658--

From sayrer@gmail.com  Sat Jan  5 21:25:41 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AC021F8753; Sat,  5 Jan 2013 21:25:41 -0800 (PST)
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 IvHT6tDIrukH; Sat,  5 Jan 2013 21:25:41 -0800 (PST)
Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by ietfa.amsl.com (Postfix) with ESMTP id D330D21F873C; Sat,  5 Jan 2013 21:25:40 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id u3so9065471wey.30 for ; Sat, 05 Jan 2013 21:25:40 -0800 (PST)
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=65iawI3jB5FxP+ZcgrYq6XU0Ocp9ArB1mf44MYln13c=; b=fzdavCgh9eyvwZZGfIsj75/dnRlVUjmj9RbwEYIjgoIHhu1xUKksEgYlk6D0hoedmG nBW8uulRS5ohZRFDN9Q41GGqHJvBfy1EiB22kln1omTkqqwnaz/BGQnGwCgbprQBa0h4 lJG4nV7li0w45fREiUiA5FiopNtuUUMyKEceA1ktIv7zNQ5XL5YoP/j28VIvkafzxFuS LBp+WnCZ5sDMJEpGcgGg8OazK/DJ9zGH+t2Sf3TOF0j8I5O9IvKip1IhXFuTl2Y6E0M1 bvXIsqhWaPodtor4pdHb7xSKMT1E8jdNsburipVvYtdUvfWfbtAI6SB3BQXuawJDT/TV fH1Q==
MIME-Version: 1.0
Received: by 10.194.76.99 with SMTP id j3mr90845663wjw.47.1357449940101; Sat, 05 Jan 2013 21:25:40 -0800 (PST)
Received: by 10.194.1.101 with HTTP; Sat, 5 Jan 2013 21:25:40 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <263BA4B0-6401-4391-A369-A90863D9A4BC@mnot.net>    
Date: Sat, 5 Jan 2013 21:25:40 -0800
Message-ID: 
From: Robert Sayre 
To: James M Snell 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Sun, 06 Jan 2013 05:25:41 -0000

On Sat, Jan 5, 2013 at 8:55 PM, James M Snell  wrote:
>
> On Jan 5, 2013 8:20 PM, "Robert Sayre"  wrote:
>>
>> On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham  wrote:
>> >
>> > Yes, you've brought that to our attention several times. If you wanted
>> > this spec to align with your software, it would have been much easier
>> > if you'd got involved before Last Call.
>>
>> Well, there shouldn't be any big adjustments to my software at all,
>> and the document generally looks good. This is just a bug: two parties
>> can apply the same patch and get different results, without
>> encountering an error.
>>
>
> Not seeing the bug... applying the same patch to different resources that
> have different states ought to have different results.

This argument is fallacious. Consider this JSON patch:

{ "op": "remove", "path": "/1" }

This patch can be generated by removing a key from a hashtable by the
sender, and then applied to an array by the recipient (which may
result in array shifts etc). A good quality patch format would not
permit such an obvious ambiguity, because applying that patch can fail
all parties. The resulting document does not reflect the intent of any
author.

I have obviously said my piece. And, fwiw, I don't think the IESG
should contradict the WG.

- Rob

From jasnell@gmail.com  Sat Jan  5 21:58:56 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E1B21F8756; Sat,  5 Jan 2013 21:58:56 -0800 (PST)
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 HpckNnA7+mE7; Sat,  5 Jan 2013 21:58:56 -0800 (PST)
Received: from mail-ia0-f174.google.com (mail-ia0-f174.google.com [209.85.210.174]) by ietfa.amsl.com (Postfix) with ESMTP id E65DD21F8732; Sat,  5 Jan 2013 21:58:55 -0800 (PST)
Received: by mail-ia0-f174.google.com with SMTP id y25so14908766iay.5 for ; Sat, 05 Jan 2013 21:58:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kZAtZHaF12CbwG28Kw5Lfr7sTXTN1zEibcbShC+7+EA=; b=aBpf/KB4fDPQhSvRkJ8b2ZGF9tptJlUP3EdL4PCGyU3xki8UAtbOyX99SD1kKtimfp ZxIri9HO3x30mY40pB1DJ5Lq3Z0ApnB2eYk+16kSlQxHftt6uve0GYriH7yQoR8LjxK6 qN2zzPGnvYVyIAOSkVqY3ScS/L54eGpGb39ZSdhA/x65l46p9xmE0pkc9HN8urIiTWaZ DT5g63bepR5NWo5H8bWL14DGuX5uclDgPQATZf8cXK2EzY8KCcg7yGKGgRKvDV67naov +W9kSQK7DgHiK5SwworSzkKnlIo8EHPa7+SrigfQob5/vxtnP3RzaB4lVPUqcGATs30h lyFQ==
MIME-Version: 1.0
X-Received: by 10.50.219.233 with SMTP id pr9mr2746714igc.19.1357451935539; Sat, 05 Jan 2013 21:58:55 -0800 (PST)
Received: by 10.64.7.19 with HTTP; Sat, 5 Jan 2013 21:58:55 -0800 (PST)
Received: by 10.64.7.19 with HTTP; Sat, 5 Jan 2013 21:58:55 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <263BA4B0-6401-4391-A369-A90863D9A4BC@mnot.net>     
Date: Sat, 5 Jan 2013 21:58:55 -0800
Message-ID: 
From: James M Snell 
To: Rob Sayre 
Content-Type: multipart/alternative; boundary=14dae934120f6ae03304d2986821
Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Sun, 06 Jan 2013 05:58:56 -0000

--14dae934120f6ae03304d2986821
Content-Type: text/plain; charset=UTF-8

[{"op":"type","path":"","value":"array"},{"op":"remove","path":"/1"}]

Problem solved. Still no bug, and still nothing I can see that needs
fixing.

I've said my piece on it to. Afaic, this spec is done and ready to go.

- James
 On Jan 5, 2013 9:25 PM, "Robert Sayre"  wrote:

> On Sat, Jan 5, 2013 at 8:55 PM, James M Snell  wrote:
> >
> > On Jan 5, 2013 8:20 PM, "Robert Sayre"  wrote:
> >>
> >> On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham  wrote:
> >> >
> >> > Yes, you've brought that to our attention several times. If you wanted
> >> > this spec to align with your software, it would have been much easier
> >> > if you'd got involved before Last Call.
> >>
> >> Well, there shouldn't be any big adjustments to my software at all,
> >> and the document generally looks good. This is just a bug: two parties
> >> can apply the same patch and get different results, without
> >> encountering an error.
> >>
> >
> > Not seeing the bug... applying the same patch to different resources that
> > have different states ought to have different results.
>
> This argument is fallacious. Consider this JSON patch:
>
> { "op": "remove", "path": "/1" }
>
> This patch can be generated by removing a key from a hashtable by the
> sender, and then applied to an array by the recipient (which may
> result in array shifts etc). A good quality patch format would not
> permit such an obvious ambiguity, because applying that patch can fail
> all parties. The resulting document does not reflect the intent of any
> author.
>
> I have obviously said my piece. And, fwiw, I don't think the IESG
> should contradict the WG.
>
> - Rob
>

--14dae934120f6ae03304d2986821
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


[{"op":"type","path":"&qu=
ot;,"value":"array"},{"op":"remove"=
,"path":"/1"}]


Problem solved. Still no bug, and still nothing I can see th=
at needs fixing. 


I've said my piece on it to. Afaic, this spec is done an=
d ready to go. 


- James




On Jan 5, 2013 9:25 PM, "Robert Sayre"=
 <sayrer@gmail.com> wrote:

On Sat, Jan 5, 2013 at 8:55 PM, James M Snell <jasnell@gmail.com> wrote:

>

> On Jan 5, 2013 8:20 PM, "Robert Sayre" <sayrer@gmail.com> wrote:

>>

>> On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham <mnot@mnot.net> wrote:

>> >

>> > Yes, you've brought that to our attention several times. =
If you wanted

>> > this spec to align with your software, it would have been muc=
h easier

>> > if you'd got involved before Last Call.

>>

>> Well, there shouldn't be any big adjustments to my software at=
 all,

>> and the document generally looks good. This is just a bug: two par=
ties

>> can apply the same patch and get different results, without

>> encountering an error.

>>

>

> Not seeing the bug... applying the same patch to different resources t=
hat

> have different states ought to have different results.



This argument is fallacious. Consider this JSON patch:



{ "op": "remove", "path": "/1" }


This patch can be generated by removing a key from a hashtable by the

sender, and then applied to an array by the recipient (which may

result in array shifts etc). A good quality patch format would not

permit such an obvious ambiguity, because applying that patch can fail

all parties. The resulting document does not reflect the intent of any

author.



I have obviously said my piece. And, fwiw, I don't think the IESG

should contradict the WG.



- Rob




--14dae934120f6ae03304d2986821--

From sm@resistor.net  Sun Jan  6 10:11:44 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F35921F8541 for ; Sun,  6 Jan 2013 10:11:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.549
X-Spam-Level: 
X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 3L+aSyFmVQiX for ; Sun,  6 Jan 2013 10:11:42 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D16FD21F854F for ; Sun,  6 Jan 2013 10:11:42 -0800 (PST)
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 r06IBW2n009550; Sun, 6 Jan 2013 10:11:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1357495898; bh=v/xHlq+nOyZdze5uatRTbMyM1AtWKv7UUiCIf9BXV5g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3BqmRBChhHdp9DmsQDRD1x+G/TDWCRu4M2XgKW82E8iinY4B2OF2BYGIBr42VBICu C3qbO7L8NEWL5+CWJ01p4pg00daOxsv3jBLFQTd8NNhXOsehNCC5E6mRrTG+tqH9eN A/EXFSqfUfe8Ozb+KEIu7cvLhmK0svjmZDcvxlhw=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1357495898; i=@resistor.net; bh=v/xHlq+nOyZdze5uatRTbMyM1AtWKv7UUiCIf9BXV5g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=C/JIhRjLpPoZvkeq9Fkha21BVfzdgivxgS1EwFznm+uJ4zp8sPa3asKul83h1BMpT hgMH/n9CifzO8S+ZUVyc65o/Gfn8SdoCoPuWhWDmbrkGD0CJ8wyHV5OmSpTqgwa6El ACzdWzJQPZWg+oOwGNDWZK3B9eVYU9uxmabQpIuM=
Message-Id: <6.2.5.6.2.20130106010843.0a41a920@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 06 Jan 2013 10:07:11 -0800
To: "Murray S. Kucherawy" 
From: SM 
In-Reply-To: 
References:  <50DD45C1.4040605@bbiw.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] Comments on draft-kucherawy-rfc5451bis-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 06 Jan 2013 18:11:44 -0000

Hi Murray,

I have some comments on draft-kucherawy-rfc5451bis-01.  The draft is 
well-written.  I commented off-list about the excessive use of RFC 
2119 key words.  Frankly, I don't know what's the right path as it 
can be argued both ways.

I suggest obsoleting RFC 6577 as well and rolling the changes into 
this document.

In Section 1:

   "This document revises that definition based on current use of
    various authentication protocols in use today and incorporates
    errate logged since the publication of the original specification."

There is a type for "errata".  I gather that the changes are only 
those listed in Appendix E and the errata.

   "[DOMAINKEYS] is also referenced here, though it has "Historic" status
    as it is no longer common.  This proposal is not intended to be
    restricted to domain-based authentication, but this has proven to be
    a good starting point for implementations."

I suggest dropping DomainKeys as it's historic.  Implementers can 
reference RFC 5451 if they need the information.

   "Although [SPF] defined a header field called Received-SPF and
    [DOMAINKEYS] defined one called DomainKey-Status for this purpose,
    those header fields are specific to the conveyance of their
    respective results only and thus are insufficient to satisfy the
    requirements enumerated below."

I suggest aligning the document with the current SPF draft.  You 
don't have to discuss about Received-SPF then.  I favor dropping the 
paragraph to trim the document without losing anything important.

In Section 1.5.2:

   "As examples: [SPF] and [SENDERID] are authorization mechanisms in
    that they express a result that shows whether or not the ADMD that"

I suggest dropping the SENDERID reference.

In Section 2.1:

   "This new header field SHOULD be added at the top of the message as it
    transits MTAs that do authentication checks so some idea of how far
    away the checks were done can be inferred.  It therefore should also
    be treated as a Trace Field as defined in [MAIL], and thus all of the
    related definitions in that document apply."

There is current a discussion about when to use caps. :-)  FWIW, 
Section 3.1 of draft-levine-trace-header-registry-01 provides a 
reason for Trace fields.

 From Section 4.1 of your document:

   "As stated in Section 2.1, this header field SHOULD be treated as
    though it were a trace header field as defined in Section 3.6.7 of
    [MAIL], and hence MUST NOT be reordered and MUST be prepended to the
    message, so that there is generally some indication upon delivery of
    where in the chain of handling MTAs the message authentication was
    done."

You have a "should" in Section 2.1 and a "SHOULD" in Section 4.1 for 
the trace header field argument.  You have a "SHOULD be added at the 
top of the message" in Section 2.1 and a "MUST NOT be reordered and 
MUST be prepended" in Section 4.1.  This causes inconsistencies.  I 
am not aware of this causing any problems.  I suggest (in Section 2.1):

   The header field is added to the top of the message as it transits MTAs that
   do authentication checks so some idea of how far away the checks were
   done can be inferred (See Section 4.1).  It is considered as a Trace
   Field as defined in  Section 3.6.7 of [MAIL], and thus all of the
   related definitions in that document apply.

I would write the Section 4.1 part as follows:

   As stated in Section 2.1, this header field is considered as a 
trace header field
   and hence MUST NOT be reordered and MUST be prepended to the 
message, so that
   there is generally some indication upon delivery of where in the 
chain of handling
   MTAs the message authentication was done."

Section 2.1:

  "The header field MAY appear more than once in a single message, or
   more than one result MAY be represented in a single header field, or
   a combination of these MAY be applied."

I read the definition of "MAY" in RFC 2119.  The "MAY" does not add 
any value here.  I would use lower case or have the text as:

  The header field can appear more than once in a single message, or
   more than one result MAY be represented in a single header field, or
   a combination of these can be applied.

In Section 2.3:

   "MUAs or downstream filters SHOULD use this identifier to determine
    whether or not the data contained in an Authentication-Results header
    field ought to be used or ignored."

I don't see a good reason for a "SHOULD".  I would move this text to 
Section 4.1 as it discusses about "Interpretation".

   "The uniqueness of the identifier MUST be guaranteed by the
    ADMD that generates it and MUST pertain to exactly that one ADMD."

   "For simplicity and scalability, the authentication service identifier
    SHOULD be a common token used throughout the ADMD, such as the DNS
    domain name used by or within that ADMD."

   "For tracing and debugging purposes, the authentication identifier MAY
    instead be the hostname of the MTA performing the authentication
    check whose result is being reported."

You have a "MUST" for uniqueness and one for restricting the 
identifier to the ADMD.  You then have a SHOULD for a unique 
identifier for the ADMD.  You then have a "MAY" with an 
explanation.  I'd say keep it simple.


    The authentication service identifier field provides a unique
    identifier that refers to the authenticating service within a
    given ADMD.  It is intended to be machine-readable and not
    necessarily meaningful to users.  The uniqueness of the identifier
    MUST be guaranteed by the ADMD that generates it and MUST pertain
    to exactly that one ADMD.  For simplicity and scalability, the
    authentication service identifier would be a common token used
    throughout the ADMD, such as the DNS domain name used by or within
    that ADMD.

    For tracing and debugging purposes, the authentication identifier may
    instead be the hostname of the MTA performing the authentication
    check whose result is being reported. (remainder of that paragraph)

Section 2.3

   'Examples of valid authentication identifiers are "example.com",
    "mail.example.org", "ms1.newyork.example.com", and "example-auth".'

"example-auth" cannot be guaranteed to be unique.  It violates the "MUST".

For Section 2.4.1, see my previous comment about DomainKeys.  For 
Section 2.4.2, see my previous comment about Sender-ID.

In Section 2.4.5:

   "Additional result codes (extension results) might be defined in the
    future by later revisions or extensions to this specification.
    Result codes MUST be registered with the Internet Assigned Numbers
    Authority (IANA) and preferably published in an RFC.  See Section 6
    for further details."

   "Extension results MUST only be used within ADMDs that have explicitly
    consented to use them.  These results and the parameters associated
    with them are not formally documented."

The above is not clear to me.  Am I allowed to extend this 
specification without IETF review?  I misunderstood this part at 
first as I missed the "x-" that was in this section before.  I'll 
comment below.

You have already defined the initial methods (Section 2.5.1) in RFC 
5451.  I suggest moving the table in Section 6.2 to Section 2.5.1 and 
adjust the text in that section accordingly.

In Section 2.5.2:

   "Additional authentication method identifiers (extension methods) may
    be defined in the future by later revisions or extensions to this
    specification.  Method identifiers MUST be registered with the
    Internet Assigned Numbers Authority (IANA) and, preferably, published
    in an RFC."

   "Experimental method identifiers MUST only be used within ADMDs that
    have explicitly consented to use them.  These method identifiers and
    the parameters associated with them are not documented in RFCs."

Section 2.5.2 previously used "x-" for experimental stuff.  This 
version of the specification removes that.  However, it keeps the 
previous logic where there are registered and experimental 
methods.  It's easier to tell people to register what they are using 
and specifying the requirements for that (First Come First Serve, for 
example).  You can then get rid of the "Experimental method 
identifiers MUST only be used within ADMDs" requirement.  I suggest 
rewriting the requirements where methods which are not supported are 
ignored.  There is already text for that in Section 4.1.

In Section 4:

   'Each "method" MUST refer to an authentication method declared in the
    IANA registry, or an extension method as described in Section 2.5.2,
    and each "result" MUST refer to a result code declared in the IANA
    registry, or an extension result code as defined in Section 2.4.5.
    See Section 6 for further information about the registered methods
    and result codes.'

I don't see any reason for the above paragraph.

   "An MTA adding this header field MUST take steps to identify it as
    legitimate to the MUAs or downstream filters that will ultimately
    consume its content.  One REQUIRED process to do so is described in
    Section 5."

There is only one REQUIRED process.  The process is not about "adding 
the header".  I suggest removing this paragraph.

   "Moreover, this header field SHOULD be inserted above any other trace
    header fields such MTAs might prepend."

There is a "MUST prepend" in Section 4.1 while the above has a "SHOULD".

  "An MTA SHOULD remove any instance of this header field bearing a
   version (express or implied) that it does not support."

It's easier to ignore such instances instead of removing them.  Would 
letting such headers through cause a problem?

   "However, an MTA MUST remove such a header field if the [SMTP]
    connection relaying the message is not from a trusted internal MTA."

I don't understand this requirement.  It's easier to have simple 
requirements for when to remove (as mentioned in the first two 
paragraphs of Section 5) instead of requirements in several places 
which are applicable under different conditions.

I suggest keeping the IANA Considerations for instructions to 
IANA.  For Section 6:

   The entry in the IANA Permanent Message Header Field Registry is updated
   to reference this document.

   The following is the registration template:

      Header field name: Authentication-Results
      Applicable protocol: mail ([MAIL])
      Status: Standard
      Author/Change controller: IETF
      Specification document(s): [this memo]
      Related information:
        Requesting review of any proposed changes and additions to
        this field is recommended.

Section 6.1 can then be dropped.

   The following entry in the Email Authentication Method Name 
Registry is update
   to reference this document:


    +------------+----------+--------+-------------+--------------------+
    |    iprev   | [this    | policy | iprev       | client IP address  |
    |            |  RFC]    |        |             |                    |
    +------------+----------+--------+-------------+--------------------+

   The following entries in the Email Authentication Result Name Registry are
   updated to reference this document:



    +-----------+----------+-------------+------------------------------+
    |   Code    | Defined  | Auth        | Meaning                      |
    |           |          | Method(s)   |                              |
    +-----------+----------+-------------+------------------------------+
    | none      | [this    | dkim        | section 2.4.1                |
    |           |  RFC]    | domainkeys  |                              |
    |           |          +-------------+------------------------------+
    |           |          | spf         | section 2.4.2                |
    |           |          | sender-id   |                              |
    |           |          +-------------+------------------------------+
    |           |          | auth        | section 2.4.4                |
    |           |          +-------------+------------------------------+
    |           |          | vbr         | section 4 of RFC6212         |
    |           |          +-------------+------------------------------+
    |           |          | dkim-adsp   | section 5.4 of RFC5617       |
    |           |          +-------------+------------------------------+
    |           |          | dkim-atps   | section 8.3 of RFC6541       |
    +-----------+----------+-------------+------------------------------+
    | pass      | [this    | dkim        | section 2.4.1                |
    |           |  RFC]    | domainkeys  |                              |
    |           |          +-------------+------------------------------+
    |           |          | spf         | section 2.4.2                |
    |           |          | sender-id   |                              |
    |           |          +-------------+------------------------------+
    |           |          | iprev       | section 2.4.3                |
    |           |          +-------------+------------------------------+
    |           |          | auth        | section 2.4.4                |
    |           |          +-------------+------------------------------+
    |           |          | vbr         | section 4 of RFC6212         |
    |           |          +-------------+------------------------------+
    |           |          | dkim-adsp   | section 5.4 of RFC5617       |
    |           |          +-------------+------------------------------+
    |           |          | dkim-atps   | section 8.3 of RFC6541       |
    +-----------+----------+-------------+------------------------------+
    | fail      | [this    | dkim        | section 2.4.1                |
    |           |  RFC]    | domainkeys  |                              |
    |           |          +-------------+------------------------------+
    |           |          | spf         | section 2.4.2                |
    |           |          | sender-id   |                              |
     |           |          +-------------+------------------------------+
    |           |          | iprev       | section 2.4.3                |
    |           |          +-------------+------------------------------+
    |           |          | auth        | section 2.4.4                |
    |           |          +-------------+------------------------------+
    |           |          | vbr         | section 4 of RFC6212         |
    |           |          +-------------+------------------------------+
    |           |          | dkim-adsp   | section 5.4 of RFC5617       |
    |           |          +-------------+------------------------------+
    |           |          | dkim-atps   | section 8.3 of RFC6541       |
    +-----------+----------+-------------+------------------------------+
    | policy    | [this    | dkim        | section 2.4.1                |
    |           |  RFC]    | domainkeys  |                              |
    |           |          +-------------+------------------------------+
    |           |          | spf         | section 2.4.2                |
    |           |          | sender-id   |                              |
    +-----------+----------+-------------+------------------------------+
    | neutral   | [this    | dkim        | section 2.4.1                |
    |           |  RFC]    | domainkeys  |                              |
    |           |          +-------------+------------------------------+
    |           |          | spf         | section 2.4.2                |
    |           |          | sender-id   |                              |
    +-----------+----------+-------------+------------------------------+
    | temperror | [this    | dkim        | section 2.4.1                |
    |           |  RFC]    | domainkeys  |                              |
    |           |          +-------------+------------------------------+
    |           |          | spf         | section 2.4.2                |
    |           |          | sender-id   |                              |
    |           |          +-------------+------------------------------+
    |           |          | iprev       | section 2.4.3                |
    |           |          +-------------+------------------------------+
    |           |          | auth        | section 2.4.4                |
    |           |          +-------------+------------------------------+
    |           |          | vbr         | section 4 of RFC6212         |
    |           |          +-------------+------------------------------+
    |           |          | dkim-adsp   | section 5.4 of RFC5617       |
    |           |          +-------------+------------------------------+
    |           |          | dkim-atps   | section 8.3 of RFC6541       |
    +-----------+----------+-------------+------------------------------+
    | permerror | [this    | dkim        | section 2.4.1                |
    |           |  RFC]    | domainkeys  |                              |
    |           |          +-------------+------------------------------+
    |           |          | spf         | section 2.4.2                |
    |           |          | sender-id   |                              |
    |           |          +-------------+------------------------------+
    |           |          | iprev       | section 2.4.3                |
    |           |          +-------------+------------------------------+
    |           |          | auth        | section 2.4.4                |
    |           |          +-------------+------------------------------+
    |           |          | vbr         | section 4 of RFC6212         |
    |           |          +-------------+------------------------------+
    |           |          | dkim-adsp   | section 5.4 of RFC5617       |
    |           |          +-------------+------------------------------+
    |           |          | dkim-atps   | section 8.3 of RFC6541       |
    +-----------+----------+-------------+------------------------------+
    | softfail  | [this    | spf         | section 2.4.2                |
    |           |  RFC]    | sender-id   |                              |
    +-----------+----------+-------------+------------------------------+

As a FYI, RFC 6577 amended the Email Authentication Methods and Email 
Authentication Result Names registries.  The registries use "Expert 
Review".  "Experts are expected to apply applicable documented review 
or vetting procedures, or in the absence of documented criteria, 
follow generally accepted norms".  The guidance in the document is:

   "The Designated Expert has discretion to request that a publication
    be referenced if a clear, concise definition of the authentication
    method cannot be provided such that interoperability is assured.
    Registrations should otherwise be permitted."

"The evaluation process is not intended to be secretive or bestow 
unquestioned power on the expert".  I suggest:

  (i)   Identifying a mailing list for the registration requests and 
discussions.

  (ii)  Deciding whether First Come First Served with some minimal checks
        is adequate as the lowest bar.

  (iii) Defining registration templates

  (iv)  Documenting how to deprecate a registration.

 From Section 7:

   "Another would be a means to interrogate the MTA that added the
    header field to see if it is actually providing any message
    authentication services and saw the message in question, but this
    isn't especially palatable given the work required to craft and
    implement such a scheme.

I don't consider the above as feasible.

   "Yet another might be a method to interrogate the internal MTAs
    that apparently handled the message (based on Received: header
    fields) to determine whether any of them conform to Section 5 of
    this memo.  This, too, has potentially high barriers to entry.

Ok, you thought about it. :-)

   "Extensions to [IMAP], [SMTP], and [POP3] could be defined to
    allow an MUA or filtering agent to acquire the "authserv-id" in
    use within an ADMD, thus allowing it to identify which
    Authentication-Results header fields it can trust.

I suggest removing this paragraph as it does not add much value.

I suggest making AR-ORIG informative as I do not need to read it to 
understand this document.  EMAIL-ARCH should reference RFC 5598.

I may have missed some stuff as I wrote the review.  I didn't notice 
any changes that could affect backward compatibility.

Regards,
-sm


From dret@berkeley.edu  Sun Jan  6 13:10:55 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A205F21F856C for ; Sun,  6 Jan 2013 13:10:55 -0800 (PST)
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 sbYxgrK9RAzQ for ; Sun,  6 Jan 2013 13:10:54 -0800 (PST)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id CECE621F8552 for ; Sun,  6 Jan 2013 13:10:54 -0800 (PST)
Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretair.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TrxUa-0006GE-8S; Sun, 06 Jan 2013 13:10:53 -0800
Message-ID: <50E9E85B.3000507@berkeley.edu>
Date: Sun, 06 Jan 2013 22:10:51 +0100
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Dominik Tomaszuk 
References: <20121230000248.6308.87225.idtracker@ietfa.amsl.com> <50DF857D.3050208@berkeley.edu> <50E03AC7.1000808@wp.pl>
In-Reply-To: <50E03AC7.1000808@wp.pl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Michael Hausenblas , hypermedia-web@googlegroups.com, REST-Discuss , "apps-discuss@ietf.org application-layer protocols" , Jeni Tennison 
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-hausenblas-csv-fragment-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 06 Jan 2013 21:10:55 -0000

hello dominik.

thanks for the feedback!

On 2012-12-30 13:59 , Dominik Tomaszuk wrote:
> I propose to add "regexp" scheme. For example:
> http://example.com/data.csv#regexp:place=/^G/
> Following the listing in § 2, the above CSV fragment selects a slice,
> yielding another CSV table as follows:
> date,temperature,place
> 2011-01-01,1,Galway
> 2011-01-02,-1,Galway
> 2011-01-03,0,Galway

adding regex support could be regarded as a logical step up in 
functionality from the current slices which use strict matches only. 
however, the general design question is whether sophisticated 
content-based identification is worth the effort, and what the use cases 
are. generally speaking, fragids shouldn't be seen as some form of 
"search mechanism", this can be left to clients by themselves. they 
should mainly focus on identification, and there identifying by location 
usually works fine. we are considering dropping splices all together, 
because they already cross the line into "search land".

interestingly, we had the same discussions when we designed fragids for 
plain text files (http://tools.ietf.org/html/rfc5147). we had the same 
proposals to add regexes and maybe even more sophisticated mechanisms 
(string distance measures, for example) for identifiers that are robust 
against some changes. however, in the end these mechanisms did not make 
the 80/20 cut, and instead an integrity check mechanism was added 
(http://tools.ietf.org/html/rfc5147#section-3.1), so that it's at least 
possible to detect changes in the resource representation.

cheers,

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 pbryan@anode.ca  Sun Jan  6 15:35:13 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C089B21F8586; Sun,  6 Jan 2013 15:35:13 -0800 (PST)
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 ZBk35INM1-ZQ; Sun,  6 Jan 2013 15:35:13 -0800 (PST)
Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 006FA21F8584; Sun,  6 Jan 2013 15:35:12 -0800 (PST)
Received: from [192.168.1.1] (S0106a021b762dbb3.vf.shawcable.net [174.1.50.247]) by maple.anode.ca (Postfix) with ESMTPSA id AFBE56AB7; Sun,  6 Jan 2013 23:35:11 +0000 (UTC)
Message-ID: <1357515310.6827.23.camel@polyglot>
From: "Paul C. Bryan" 
To: Robert Sayre 
Date: Sun, 06 Jan 2013 15:35:10 -0800
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>      
Content-Type: multipart/alternative; boundary="=-B1xg1qOCqeQSYLxluh/N"
X-Mailer: Evolution 3.4.4-1 
Mime-Version: 1.0
Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Sun, 06 Jan 2013 23:35:13 -0000

--=-B1xg1qOCqeQSYLxluh/N
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

> On Sat, 2013-01-05 at 16:19 -0800, Robert Sayre wrote:


[snip]


> 1) The ambiguity around arrays makes the patch format unsuitable for
> common concurrent editing algorithms.


Common concurrent editing algorithms should, in my opinion, use
techniques to ensure the state of the resource (relative to the edits)
is known. In HTTP, we have ETag and If-Match/If-None-Match
preconditions. In JSON Patch, we have (a rudimentary) test operation.

[snip]


> 3) It's not possible to tell whether a JSON Pointer document is
> syntactically correct in isolation.


There is no such thing as a JSON Pointer document.


> This issue is a problem in practice, and it's a problem in theory as
> well. JSON-Patch messages aren't sufficiently self-descriptive, so
> they aren't appropriate for use in a RESTful system.


99% of RESTful systems I'm familiar with are based on HTTP. Where
optimistic concurrency is acceptable, HTTP preconditions seems to
provide acceptable coverage. Where more granularity or more pessimistic
concurrency is required, implementors are free to use their own
mechanisms, including more expressive predicates (as has been proposed
here, with my endorsement) and/or resource locking. These are
intentionally out of scope for JSON Patch.

Later in this thread, you wrote:


> Ah. I meant that the WG seems to be favoring "running code" a little
> too heavily in the presence of a bug. It's an old argument, and it's
> boring: "We can't change it now, there are already twelve users!"


I don't agree that this is a bug; it lacks a feature that you and some
others have requested. Our reasoning for resisting such change is
legitimate.

The reason I value implementations is because they endorse the
specification through tangible action. Some of their authors have
participated in this forum to help improve the specification and create
consensus around it. Unfortunately, you've raised objections quite late
in the process, and I'm personally not persuaded that the issues you've
raised warrants (likely significant) changes.

Paul

--=-B1xg1qOCqeQSYLxluh/N
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  




    On Sat, 2013-01-05 at 16:19 -0800, Robert Sayre wrote:





[snip]





    1) The ambiguity around arrays makes the patch format unsuitable for common concurrent editing algorithms.





Common concurrent editing algorithms should, in my opinion, use techniques to ensure the state of the resource (relative to the edits) is known. In HTTP, we have ETag and If-Match/If-None-Match preconditions. In JSON Patch, we have (a rudimentary) test operation.



[snip]





    3) It's not possible to tell whether a JSON Pointer document is syntactically correct in isolation.





There is no such thing as a JSON Pointer document.





    This issue is a problem in practice, and it's a problem in theory as well. JSON-Patch messages aren't sufficiently self-descriptive, so they aren't appropriate for use in a RESTful system.





99% of RESTful systems I'm familiar with are based on HTTP. Where optimistic concurrency is acceptable, HTTP preconditions seems to provide acceptable coverage. Where more granularity or more pessimistic concurrency is required, implementors are free to use their own mechanisms, including more expressive predicates (as has been proposed here, with my endorsement) and/or resource locking. These are intentionally out of scope for JSON Patch.



Later in this thread, you wrote:





    Ah. I meant that the WG seems to be favoring "running code" a little too heavily in the presence of a bug. It's an old argument, and it's boring: "We can't change it now, there are already twelve users!"





I don't agree that this is a bug; it lacks a feature that you and some others have requested. Our reasoning for resisting such change is legitimate.



The reason I value implementations is because they endorse the specification through tangible action. Some of their authors have participated in this forum to help improve the specification and create consensus around it. Unfortunately, you've raised objections quite late in the process, and I'm personally not persuaded that the issues you've raised warrants (likely significant) changes.



Paul



--=-B1xg1qOCqeQSYLxluh/N--


From sayrer@gmail.com  Sun Jan  6 16:01:36 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1E421F857B; Sun,  6 Jan 2013 16:01:36 -0800 (PST)
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 AJ0W-a3YgXMX; Sun,  6 Jan 2013 16:01:35 -0800 (PST)
Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by ietfa.amsl.com (Postfix) with ESMTP id 223E621F8578; Sun,  6 Jan 2013 16:01:34 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id x48so9224028wey.8 for ; Sun, 06 Jan 2013 16:01:34 -0800 (PST)
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=dw+ysy5x2Qze/pzJPJljE4jmDrGirRkeSdFljnROM/o=; b=gFcK7/BKijCgnKvfld7Uc1Xkqsc8Cx4/Y9VHv59KLPGuSoXEFN/mchcUwXqBO5gc60 4KqixqSC/x6xT9BP2zcgxpBrNLHUEZ7eN+qVMgYbwT90iDptnRdaigBgWqg7SH+QCCMk neeDlHjYCYmJdd2dcul/glzWFWinFdvo9l4Wsoh9Q9fr/zW5hVDSbw+RAVueSMrpxquc A/kl8zopZcQ8l/n1gTIxEVI9NGj8HV5xcTqtLjIrjaKTViKp3Oz2PrMW+yBo4FAhGqD2 svjXNNQlFvL3qGTMZsvjUqRFlAB2bEwmNY3Lwe6DqYS2D/JBz3ntIxiHUlnhA5nUIaWA Cy4w==
MIME-Version: 1.0
Received: by 10.194.23.37 with SMTP id j5mr92782594wjf.28.1357516894252; Sun, 06 Jan 2013 16:01:34 -0800 (PST)
Received: by 10.194.1.101 with HTTP; Sun, 6 Jan 2013 16:01:34 -0800 (PST)
In-Reply-To: <1357515310.6827.23.camel@polyglot>
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>
Date: Sun, 6 Jan 2013 16:01:34 -0800
Message-ID: 
From: Robert Sayre 
To: "Paul C. Bryan" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Mon, 07 Jan 2013 00:01:36 -0000

On Sun, Jan 6, 2013 at 3:35 PM, Paul C. Bryan  wrote:
>

Thank you for the technical response.

>
> 1) The ambiguity around arrays makes the patch format unsuitable for common
> concurrent editing algorithms.
>
>
> Common concurrent editing algorithms should, in my opinion, use techniques
> to ensure the state of the resource (relative to the edits) is known. In
> HTTP, we have ETag and If-Match/If-None-Match preconditions. In JSON Patch,
> we have (a rudimentary) test operation.

That is sequential editing, not concurrent editing. Here are a few
links to make sure we're not talking past each other:

http://en.wikipedia.org/wiki/Operational_transformation#Basics

The above overview section contains a two-step insert/delete process
bearing an uncanny resemblance to a JSON Patch document.

Here's some software that uses patch documents in this fashion:

http://en.wikipedia.org/wiki/Operational_transformation#OT_software

>
> [snip]
>
>
> 3) It's not possible to tell whether a JSON Pointer document is
> syntactically correct in isolation.
>
>
> There is no such thing as a JSON Pointer document.

Yes, I meant JSON Pointer /reference/. This error seems tangential to
the thread in general, though, which is why I didn't bother to correct
myself when others raised this point.

>
> This issue is a problem in practice, and it's a problem in theory as well.
> JSON-Patch messages aren't sufficiently self-descriptive, so they aren't
> appropriate for use in a RESTful system.
>
>
> 99% of RESTful systems I'm familiar with are based on HTTP. Where optimistic
> concurrency is acceptable, HTTP preconditions seems to provide acceptable
> coverage. Where more granularity or more pessimistic concurrency is
> required, implementors are free to use their own mechanisms, including more
> expressive predicates (as has been proposed here, with my endorsement)
> and/or resource locking. These are intentionally out of scope for JSON
> Patch.

Fully disagree. My point is that the array ambiguity makes it hard to
implement more optimistic concurrency.

>
> Later in this thread, you wrote:
>
> Ah. I meant that the WG seems to be favoring "running code" a little too
> heavily in the presence of a bug. It's an old argument, and it's boring: "We
> can't change it now, there are already twelve users!"
>
>
> I don't agree that this is a bug; it lacks a feature that you and some
> others have requested.

The only rationale I've seen prior to my message was something about
"feeling natural" and "static languages" that I admit I don't fully
understand. Are there other technical arguments I've missed? I'm happy
to go read up.

> Our reasoning for resisting such change is
> legitimate.

This last assertion really isn't qualified very well. Do you have a
more extensive rationale, or is a simple contradiction the extent of
your argument?

- Rob

From sayrer@gmail.com  Sun Jan  6 17:15:08 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3520B21F84F8; Sun,  6 Jan 2013 17:15:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 pPiw64mRZ-Bq; Sun,  6 Jan 2013 17:15:07 -0800 (PST)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 09FBB21F84F6; Sun,  6 Jan 2013 17:15:06 -0800 (PST)
Received: by mail-wg0-f41.google.com with SMTP id ds1so1765670wgb.4 for ; Sun, 06 Jan 2013 17:15:05 -0800 (PST)
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=cerFm2Nwtrzw/JgZDkqrf/mLp5kDOiTPKeIMc5/Si4E=; b=maSQOtsZTCbPbcNXJtr6yUdwI0Dgu/NEqc6x+CqmspBZqdHggdmHiNCmAogyUU8M5/ GVBqA5MCk2dr2TL/rFU3vbfXXUXYK3NJIg6bwdVIRips5OxkdoYWvCUvJ+kmoy1ME3n6 uvS1zp1vSDqnXXAi7J1UZIJlM+hsT2x8BilrXEe7iyi0RYaYETDUWj13vpuzPUi9b/8P N8Acj7DmjcTetotwhr743TPc+nA2m8YeMGe08wdnAhcPA1m6qBb1D8GPdAwyI4uIfofb JSKNwu4cqhxv43//yP+zFiuDQuSFImu8ydFpGrYXinEAdmIOkGWyT/WHzAGrXgqLzJlW 4o2A==
MIME-Version: 1.0
Received: by 10.180.88.40 with SMTP id bd8mr6568125wib.33.1357521305755; Sun, 06 Jan 2013 17:15:05 -0800 (PST)
Received: by 10.194.1.101 with HTTP; Sun, 6 Jan 2013 17:15:05 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot> 
Date: Sun, 6 Jan 2013 17:15:05 -0800
Message-ID: 
From: Robert Sayre 
To: "Paul C. Bryan" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss , IESG 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Mon, 07 Jan 2013 01:15:08 -0000

On Sun, Jan 6, 2013 at 4:01 PM, Robert Sayre  wrote:
> On Sun, Jan 6, 2013 at 3:35 PM, Paul C. Bryan  wrote:
>>
>>
>> Common concurrent editing algorithms should, in my opinion, use techniques
>> to ensure the state of the resource (relative to the edits) is known. In
>> HTTP, we have ETag and If-Match/If-None-Match preconditions. In JSON Patch,
>> we have (a rudimentary) test operation.
...
> links to make sure we're not talking past each other:

Actually, let me restate my point in terms of RFC5789 (HTTP PATCH).
That will make it easier to communicate.

RFC 5789 Section 2.2 (Error Handling) defines error conditions which
correspond directly to the point at hand: 'Conflicting state' and
'Conflicting modification'. Section 5 of the JSON Patch document
directly references RFC5789, Section 2.2.

With that in mind, let's note that there are several normative
requirements in the JSON Patch document directed at conflicting state.
One such example is from Section 4.2 'remove'. It reads: "The target
location MUST exist for the operation to be successful.". If a server
received an HTTP JSON Patch request attempting to delete a
non-existent location, this text from RFC5789 would seem to apply:

"Conflicting state:  Can be specified with a 409 (Conflict) status
      code when the request cannot be applied given the state of the
      resource.  For example, if the client attempted to apply a
      structural modification and the structures assumed to exist did
      not exist ..."

The text above wouldn't be necessary in JSON Patch or RFC5789 if
RFC5789 required checking ETags and preconditions for all use cases
(it doesn't). The larger point is that RFC5789, and patch formats in
general, make all sorts of allowances for *non-conflicting* concurrent
edits to a common ancestor. The problem with leaving this JSON Pointer
array ambiguity in the draft is that patch messages which should
trigger '409 Conflict' errors can be mistakenly and 'successfully' (in
the HTTP sense) applied to a different structure than intended.

In summary, the JSON Patch draft allows patch documents to be
formulated that make it impossible to correctly implement RFC5789, a
normative reference.

Here are the questions the IESG focuses on during review:
"Reviews should focus on these questions: 'Is this document a
reasonable basis on which to build the salient part of the Internet
infrastructure? If not, what changes would make it so?'"

For JSON Patch, the answer to the first question is 'no', because of a
deficiency in JSON Pointer. The change needed to make these documents
acceptable as part of the Internet infrastructure is to make Arrays
explicit in JSON Pointer syntax.

- Rob

From mmorley@mpcm.com  Sun Jan  6 19:23:50 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2E921F8548 for ; Sun,  6 Jan 2013 19:23:50 -0800 (PST)
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 o+BuWsGQsu61 for ; Sun,  6 Jan 2013 19:23:49 -0800 (PST)
Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by ietfa.amsl.com (Postfix) with ESMTP id B4D2821F84F2 for ; Sun,  6 Jan 2013 19:23:48 -0800 (PST)
Received: by mail-la0-f50.google.com with SMTP id fs13so14278392lab.37 for ; Sun, 06 Jan 2013 19:23:47 -0800 (PST)
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=ro39O8NhduStT3XQnHzOKdba0RXxFCku6N1ZtKZwe+0=; b=G21RmzzpvfM237u3NhdsEOj6c6Y6jnjuAevetRlam60mg5tGhQgCtWISUILuJfkn3o ia0GhRjtL+EQD8qzzGF6wBGDhn1QsqD06xkMGamZaz93hjYwT0GcjcLL4N5Z1u2PnKoc 1oH63bMUOdKei2cjjTMWN2qqcqspWPCQwGCWbK1T8HCElmitYN3c13fnM3d3/gFcvtNq hQaBf+VxNiGYcKg4jmtCnFWgF0zWW30drla3U4vE8w11sVpetNib+E+QjRvPdp/B02iN VQoTlP0VvwQZ8LCVfimqp3tpkH42yAWf/0azlb7aSF8cR8A+8qT7qp7pMIe3DGOVgDCA BH/A==
MIME-Version: 1.0
Received: by 10.112.87.40 with SMTP id u8mr24179427lbz.50.1357529027336; Sun, 06 Jan 2013 19:23:47 -0800 (PST)
Sender: mmorley@mpcm.com
Received: by 10.114.38.137 with HTTP; Sun, 6 Jan 2013 19:23:47 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>  
Date: Sun, 6 Jan 2013 22:23:47 -0500
X-Google-Sender-Auth: Ny6xVmqSjYgYU1tb3ochhYuU63Q
Message-ID: 
From: Matthew Morley 
To: Robert Sayre 
Content-Type: multipart/alternative; boundary=bcaec554df40725ba304d2aa5b85
X-Gm-Message-State: ALoCoQnAXfMYTggK9QT5GS3LWkUtyCjB1FxFkd5ZoHLL7QhVHJ5JmlMfZeUo1siQJ2p83+k1UF9r
Cc: IETF Apps Discuss , Mark Nottingham , IETF Discussion , IESG 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Mon, 07 Jan 2013 03:23:50 -0000

--bcaec554df40725ba304d2aa5b85
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Jan 6, 2013 at 8:15 PM, Robert Sayre  wrote:

> On Sun, Jan 6, 2013 at 4:01 PM, Robert Sayre  wrote:
> > On Sun, Jan 6, 2013 at 3:35 PM, Paul C. Bryan  wrote:
> >>
> >>
> >> Common concurrent editing algorithms should, in my opinion, use
> techniques
> >> to ensure the state of the resource (relative to the edits) is known. In
> >> HTTP, we have ETag and If-Match/If-None-Match preconditions. In JSON
> Patch,
> >> we have (a rudimentary) test operation.
> ...
> > links to make sure we're not talking past each other:
>
> Actually, let me restate my point in terms of RFC5789 (HTTP PATCH).
> That will make it easier to communicate.
>
> RFC 5789 Section 2.2 (Error Handling) defines error conditions which
> correspond directly to the point at hand: 'Conflicting state' and
> 'Conflicting modification'. Section 5 of the JSON Patch document
> directly references RFC5789, Section 2.2.
>
> With that in mind, let's note that there are several normative
> requirements in the JSON Patch document directed at conflicting state.
> One such example is from Section 4.2 'remove'. It reads: "The target
> location MUST exist for the operation to be successful.". If a server
> received an HTTP JSON Patch request attempting to delete a
> non-existent location, this text from RFC5789 would seem to apply:
>
> "Conflicting state:  Can be specified with a 409 (Conflict) status
>       code when the request cannot be applied given the state of the
>       resource.  For example, if the client attempted to apply a
>       structural modification and the structures assumed to exist did
>       not exist ..."
>
> The text above wouldn't be necessary in JSON Patch or RFC5789 if
> RFC5789 required checking ETags and preconditions for all use cases
> (it doesn't). The larger point is that RFC5789, and patch formats in
> general, make all sorts of allowances for *non-conflicting* concurrent
> edits to a common ancestor. The problem with leaving this JSON Pointer
> array ambiguity in the draft is that patch messages which should
> trigger '409 Conflict' errors can be mistakenly and 'successfully' (in
> the HTTP sense) applied to a different structure than intended.
>
> In summary, the JSON Patch draft allows patch documents to be
> formulated that make it impossible to correctly implement RFC5789, a
> normative reference.
>
> Here are the questions the IESG focuses on during review:
> "Reviews should focus on these questions: 'Is this document a
> reasonable basis on which to build the salient part of the Internet
> infrastructure? If not, what changes would make it so?'"
>
> For JSON Patch, the answer to the first question is 'no', because of a
> deficiency in JSON Pointer. The change needed to make these documents
> acceptable as part of the Internet infrastructure is to make Arrays
> explicit in JSON Pointer syntax.
>
> - Rob
>

For me the deficiency is not in the pointer, but patch format being
generated.

One approach is to push that *one* test, structure conformity, into the
pointer syntax. Another is via the type operation.

If a vague patch is generated, vague results are to be expected.

Testing for *just* the structure does not really create a verbose patch
either. Which is why I am not overly in favor of a syntax specific to
arrays, with this argument.

For example, if you are replacing a key in a object, the json-pointer to
get there, *and* the value would be required to ensure it is not
vague. Setting /a/b/c to 6 when it was 4, and applying that patch without
such tests to a document where /a/b/c is 13, is also vague.

Without tests, the patch format is optimistic at best, there is no escaping
this fact. Changing the spec for the json-pointer syntax to address
vagueness in json-patch specification seems wrong to me.

If json-pointer is not well suited, because of the desire for a descriptive
path which includes structure and value, perhaps a different specification
is need. One that provides both path, structure, and value confirmation in
the pointer string. Though at that point is more of a query path, so
something like JsonPath (http://goessner.net/articles/JsonPath/)?

I prefer the test/type operations and the json-pointer specification, with
optimistic patches.

-- 
Matthew P. C. Morley

--bcaec554df40725ba304d2aa5b85
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 6, 2013 at 8:15 PM, Robert Sayre <sayrer@gmail.com> wrote:


On Sun, Jan 6, 2013 at 4:01 PM, Robert Sayre <sayrer@gmail.com> wrote:

> On Sun, Jan 6, 2013 at 3:35 PM, Paul C. Bryan <pbryan@anode.ca> wrote:

>>

>>


>> Common concurrent editing algorithms shoul=
d, in my opinion, use techniques

>> to ensure the state of the resource (relative to the edits) is kno=
wn. In

>> HTTP, we have ETag and If-Match/If-None-Match preconditions. In JS=
ON Patch,

>> we have (a rudimentary) test operation.


...


> links to make sure we're not talking past each o=
ther:




Actually, let me restate my point in terms of RFC5789 (HTTP PATCH).
That will make it easier to communicate.



RFC 5789 Section 2.2 (Error Handling) defines error conditions which

correspond directly to the point at hand: 'Conflicting state' and
'Conflicting modification'. Section 5 of the JSON Patch document
directly references RFC5789, Section 2.2.



With that in mind, let's note that there are several normative

requirements in the JSON Patch document directed at conflicting state.

One such example is from Section 4.2 'remove'. It reads: "The =
target

location MUST exist for the operation to be successful.". If a server<=
br>
received an HTTP JSON Patch request attempting to delete a

non-existent location, this text from RFC5789 would seem to apply:



"Conflicting state: =A0Can be specified with a 409 (Conflict) status
=A0 =A0 =A0 code when the request cannot be applied given the state of the<=
br>
=A0 =A0 =A0 resource. =A0For example, if the client attempted to apply a
=A0 =A0 =A0 structural modification and the structures assumed to exist did=


=A0 =A0 =A0 not exist ..."



The text above wouldn't be necessary in JSON Patch or RFC5789 if

RFC5789 required checking ETags and preconditions for all use cases

(it doesn't). The larger point is that RFC5789, and patch formats in
general, make all sorts of allowances for *non-conflicting* concurrent

edits to a common ancestor. The problem with leaving this JSON Pointer

array ambiguity in the draft is that patch messages which should

trigger '409 Conflict' errors can be mistakenly and 'successful=
ly' (in

the HTTP sense) applied to a different structure than intended.



In summary, the JSON Patch draft allows patch documents to be

formulated that make it impossible to correctly implement RFC5789, a

normative reference.



Here are the questions the IESG focuses on during review:

"Reviews should focus on these questions: 'Is this document a

reasonable basis on which to build the salient part of the Internet

infrastructure? If not, what changes would make it so?'"



For JSON Patch, the answer to the first question is 'no', because o=
f a

deficiency in JSON Pointer. The change needed to make these documents

acceptable as part of the Internet infrastructure is to make Arrays

explicit in JSON Pointer syntax.




- Rob

For me the deficiency is not in=
 the pointer, but patch format being generated.

One approach is to p=
ush that *one* test, structure=A0conformity, into the pointer syntax.=A0Ano=
ther is via the type operation.


If a vague patch is generated, vague results are to be expected.
Testing for *just* the structure does not really create a verbose patch ei=
ther. Which is why I am not overly in favor of a syntax specific to arrays,=
 with this argument.


For example, if you are replacing a key in a object, the json-pointer t=
o get there, *and* the value would be required to ensure it is not vague.=
=A0Setting /a/b/c to 6 when it was 4, and applying that patch without such =
tests to a document where /a/b/c is 13, is also vague. =A0


Without tests, the patch format is optimistic at best, there is no esca=
ping this fact. Changing the spec for the json-pointer syntax to address va=
gueness in json-patch specification seems wrong to me.

If json-point=
er is not well suited, because of the desire for a descriptive path which i=
ncludes structure and value, perhaps a different=A0specification is need. O=
ne that provides both path, structure, and value confirmation in the pointe=
r string. Though at that point is more of a query path, so something like J=
sonPath (http://goessner=
.net/articles/JsonPath/)?



I prefer the test/type operations and the json-pointer specificati=
on, with optimistic patches.

-- 
Matthew P. C. Morley

--bcaec554df40725ba304d2aa5b85--

From conal.tuohy@gmail.com  Mon Jan  7 00:00:21 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C5721F8546 for ; Mon,  7 Jan 2013 00:00:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.143
X-Spam-Level: 
X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_55=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 67D-KYAWV2Gp for ; Mon,  7 Jan 2013 00:00:20 -0800 (PST)
Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1E50D21F8541 for ; Mon,  7 Jan 2013 00:00:20 -0800 (PST)
Received: by mail-pb0-f41.google.com with SMTP id xa7so10499232pbc.28 for ; Mon, 07 Jan 2013 00:00:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=b5UzFQ9ND6wxGhoBsY9CITdumLEjqawBwoksl4zcLvs=; b=W1KS2TpLAg61OdXzg58cqYFfQrB485QT3H7e7ay+SM+HnmtagmjYQgRo+suMRC7XKI AJ19dU45GOltZJgJu45VXuCq+HruzqXJEYyEd+Fr2hrZDJlcgoHRh9/dtKa6df71Qrkp MIvc3m71O1jWyRI3PMDxdSPgXwdXvxEKbjUhJ1Qa9OuVCh5N0lcmTyWK0A2JVJCLUjgi a5ftqh6BNfw74k8pm8OXqkaILVLMti1UMLc8bj7nwHFHRI++D9/98v51pgTz0p4PqQF4 RAqk7UjQt+JilYl4KH0cdhMbTQ0ct7HsKdGyGnPgCXSDuzTRjw4jgmZA5rsbSN84iWfe tufQ==
X-Received: by 10.68.241.136 with SMTP id wi8mr185570345pbc.95.1357545619829;  Mon, 07 Jan 2013 00:00:19 -0800 (PST)
Received: from [10.1.1.8] (d58-106-8-154.rdl801.qld.optusnet.com.au. [58.106.8.154]) by mx.google.com with ESMTPS id d2sm38284317paw.19.2013.01.07.00.00.16 (version=SSLv3 cipher=OTHER); Mon, 07 Jan 2013 00:00:18 -0800 (PST)
Sender: Conal Tuohy 
Message-ID: <50EA808D.3060800@versi.edu.au>
Date: Mon, 07 Jan 2013 18:00:13 +1000
From: Conal Tuohy 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Mark Nottingham 
References: <50C5A6BB.5000300@versi.edu.au> <50CA92A2.5060301@versi.edu.au> <50CE9F39.4020601@versi.edu.au> <6993B286-2B25-4D92-A201-812F3909068B@mnot.net>
In-Reply-To: <6993B286-2B25-4D92-A201-812F3909068B@mnot.net>
Content-Type: multipart/alternative; boundary="------------080308000706090203050803"
Cc: "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-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: Mon, 07 Jan 2013 08:00:21 -0000

This is a multi-part message in MIME format.
--------------080308000706090203050803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 17/12/12 15:34, Mark Nottingham wrote:
>> Using namespaces to disambiguate XML vocabularies is considered best practice. It allows for an XML document to be correctly interpreted even outside the HTTP context in which it might appear (i.e. without knowing the specific internet media type). See http://www.w3.org/TR/webarch/#xml-namespaces for details, and also see http://www.w3.org/TR/webarch/#namespace-document for the reasons why namespace URIs should resolve to useful documentation (such as an RFC document).
> Yes, I'm familiar with the WebArch document. In practice, XML Namespaces can cause a lot of developer confusion, and I'd put forth that they should only be used where distributed extensibility is necessary, and there are no other ways to achieve it.
I beg to differ. I agree with Erik, there. Many developers (especially 
those without much XML experience) don't like XML namespaces, and 
there's no doubt they are a complication of the original XML model. But 
like them or not, they are THE standard way to handle mixed vocabularies 
in the XML world, and I firmly believe that more XML developers would be 
confused by XML documents in which vocabularies are re-used and mixed 
WITHOUT the help of XML namespaces. To be honest the idea of not using 
XML's standard namespace mechanism for its God-given purpose seems 
wilfully deviant to me.
> Here, because the definition of the problem type (and thereby, its extensions) is controlled by the person that mints it (using a describedBy link), there isn't a need for distributed extensibility, as far as I can see. Furthermore, using XML namespaces would force the use of a similar mechanism with JSON, which would make me (and many others, I think) unhappy.
Yes, the "describedBy" link in the current draft is a namespace 
mechanism as well, but it applies holus bolus - it's not clear how one 
could use it to handle cases where a problem type is itself a composite, 
i.e. where I have a problem which I wish to describe using multiple 
vocabularies. A couple of examples:

  * I might have a common low-level vocabulary shared by many apps, and
    other, more domain-specific vocabularies, for describing an error in
    more high-level terms. Analogously to how Java exceptions can model
    high-level (more user- and action- oriented) errors, and also
    contain nested within them exceptions which model more low-level
    (system-oriented) descriptions of the same error.
  * I might also have a web service which is a mashup of two other web
    services, each with their own vocabularies. A client app might
    attempt some erroneous operation on the mashup, generating two
    erroneous operations on the aggregated services, and producing a
    single error, containing two underlying errors.

>> It seems to me that the relationship between the names of JSON objects and corresponding XML elements also needs clarification.
>>
>> For instance, the XML schema allows those objects to be in "##any" namespace, but how would those namespaces relate to JSON expressions of the same error report? If a JSON problem report were to be transformed into XML, what XML namespaces would actually be used for any extension members? Conversely, if an XML-formatted problem report were converted to JSON, how would any XML namespaces be rendered in the JSON?
> I'm CC:ing Erik because he helped me add the XML format (which I was somewhat reluctant to do).
>
> No namespaces would be used, as I understand it. Erik, does the schema need revision?
Yeah, that would resolve the issue of how namespaced extension 
properties would be represented in JSON, but to my mind it would be an 
unnatural act, from the point of view of XML ;-)

An alternative would be to extend the "describedBy" feature to extension 
properties. It seems to me that already a JSON problem object could be 
converted to XML in which which all the extension properties were 
elements whose names were in the namespace defined by the "describedBy" 
URI. If those extension objects contained "describedBy" properties in 
turn, then they too could be converted to namespaced XML elements. It 
might be necessary to rearrange the structure of a problem object 
slightly to make that work, but I think it would be a minor change, and 
it would allow for problems to be composed out of other problems.

Regards

Con
-- 
Conal Tuohy
HuNI  Technical Coordinator 

Victorian eResearch Strategic Initiative 

Skype: conal.tuohy
Twitter: @conal_tuohy 
Mobile: +61-466324297 


--------------080308000706090203050803
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 17/12/12 15:34, Mark Nottingham
      wrote:

    

    

      

        
Using namespaces to disambiguate XML vocabularies is considered best practice. It allows for an XML document to be correctly interpreted even outside the HTTP context in which it might appear (i.e. without knowing the specific internet media type). See http://www.w3.org/TR/webarch/#xml-namespaces for details, and also see http://www.w3.org/TR/webarch/#namespace-document for the reasons why namespace URIs should resolve to useful documentation (such as an RFC document).


      

      
Yes, I'm familiar with the WebArch document. In practice, XML Namespaces can cause a lot of developer confusion, and I'd put forth that they should only be used where distributed extensibility is necessary, and there are no other ways to achieve it. 

    

    I beg to differ. I agree with Erik, there. Many developers
    (especially those without much XML experience) don't like XML
    namespaces, and there's no doubt they are a complication of the
    original XML model. But like them or not, they are THE standard way
    to handle mixed vocabularies in the XML world, and I firmly believe
    that more XML developers would be confused by XML documents in which
    vocabularies are re-used and mixed WITHOUT the help of XML
    namespaces. To be honest the idea of not using XML's standard
    namespace mechanism for its God-given purpose seems wilfully deviant
    to me.

    

      
Here, because the definition of the problem type (and thereby, its extensions) is controlled by the person that mints it (using a describedBy link), there isn't a need for distributed extensibility, as far as I can see. Furthermore, using XML namespaces would force the use of a similar mechanism with JSON, which would make me (and many others, I think) unhappy.


    

    Yes, the "describedBy" link in the current draft is a namespace
    mechanism as well, but it applies holus bolus - it's not clear how
    one could use it to handle cases where a problem type is itself a
    composite, i.e. where I have a problem which I wish to describe
    using multiple vocabularies. A couple of examples:

    
    
      
  • I might have a common low-level vocabulary shared by many
        apps, and other, more domain-specific vocabularies, for
        describing an error in more high-level terms. Analogously to how
        Java exceptions can model high-level (more user- and action-
        oriented) errors, and also contain nested within them exceptions
        which model more low-level (system-oriented) descriptions of the
        same error.  
    • 
      
  • I might also have a web service which is a mashup of two other
        web services, each with their own vocabularies. A client app
        might attempt some erroneous operation on the mashup, generating
        two erroneous operations on the aggregated services, and
        producing a single error, containing two underlying errors.
    • 
    

    

      

        
It seems to me that the relationship between the names of JSON objects and corresponding XML elements also needs clarification. 

For instance, the XML schema allows those objects to be in "##any" namespace, but how would those namespaces relate to JSON expressions of the same error report? If a JSON problem report were to be transformed into XML, what XML namespaces would actually be used for any extension members? Conversely, if an XML-formatted problem report were converted to JSON, how would any XML namespaces be rendered in the JSON?


      

      
I'm CC:ing Erik because he helped me add the XML format (which I was somewhat reluctant to do). 

No namespaces would be used, as I understand it. Erik, does the schema need revision?

    

    Yeah, that would resolve the issue of how namespaced extension
    properties would be represented in JSON, but to my mind it would be
    an unnatural act, from the point of view of XML ;-)

    

    An alternative would be to extend the "describedBy" feature to
    extension properties. It seems to me that already a JSON problem
    object could be converted to XML in which which all the extension
    properties were elements whose names were in the namespace defined
    by the "describedBy" URI. If those extension objects contained
    "describedBy" properties in turn, then they too could be converted
    to namespaced XML elements. It might be necessary to rearrange the
    structure of a problem object slightly to make that work, but I
    think it would be a minor change, and it would allow for problems to
    be composed out of other problems.

    

    Regards

    

    Con

    

    

    
-- 

      

        Conal Tuohy

        HuNI Technical
          Coordinator

        Victorian
          eResearch Strategic Initiative

        Skype: conal.tuohy

        Twitter: @conal_tuohy

        Mobile: +61-466324297
      

    

  


--------------080308000706090203050803--

From dret@berkeley.edu  Mon Jan  7 05:09:32 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6DF21F870A for ; Mon,  7 Jan 2013 05:09:32 -0800 (PST)
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 N5bmVqRg29yC for ; Mon,  7 Jan 2013 05:09:31 -0800 (PST)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 92D4021F8703 for ; Mon,  7 Jan 2013 05:09:31 -0800 (PST)
Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretpro.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TsCSC-0001Ff-91; Mon, 07 Jan 2013 05:09:25 -0800
Message-ID: <50EAC900.7060605@berkeley.edu>
Date: Mon, 07 Jan 2013 14:09:20 +0100
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Conal Tuohy 
References: <50C5A6BB.5000300@versi.edu.au> <50CA92A2.5060301@versi.edu.au> <50CE9F39.4020601@versi.edu.au> <6993B286-2B25-4D92-A201-812F3909068B@mnot.net> <50EA808D.3060800@versi.edu.au>
In-Reply-To: <50EA808D.3060800@versi.edu.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-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: Mon, 07 Jan 2013 13:09:32 -0000

hello conal.

On 2013-01-07 9:00 , Conal Tuohy wrote:
> On 17/12/12 15:34, Mark Nottingham wrote:
>> Yes, I'm familiar with the WebArch document. In practice, XML Namespaces can cause a lot of developer confusion, and I'd put forth that they should only be used where distributed extensibility is necessary, and there are no other ways to achieve it.
> I beg to differ. I agree with Erik, there. Many developers (especially
> those without much XML experience) don't like XML namespaces, and
> there's no doubt they are a complication of the original XML model. But
> like them or not, they are THE standard way to handle mixed vocabularies
> in the XML world, and I firmly believe that more XML developers would be
> confused by XML documents in which vocabularies are re-used and mixed
> WITHOUT the help of XML namespaces. To be honest the idea of not using
> XML's standard namespace mechanism for its God-given purpose seems
> wilfully deviant to me.

for the record: i do agree that XML namespaces are what is used in XML 
to clearly separate vocabularies, and thus they should be the default 
choice for doing this. i also think that even though intensely disliking 
namespaces for a while seemed to be the hip thing to do, in the meantime 
things have cooled down a bit, and they are just a fact of life when 
you're dealing with XML.

that being said, however, what convinced me about mark's argument was 
the following: if you want to have a model that spans more than one 
representation (specifically, JSON and XML), and you don't want to be in 
the business of inventing namespaces in JSON, then avoiding namespaces 
in XML may be the best way to go. it still looks wrong to me, from the 
XML point of view, but from he "let's reuse the same model in JSON and 
XML" view, maybe it's the best possible way to go.

cheers,

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 julian.reschke@gmx.de  Mon Jan  7 05:49:35 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9E821F868B for ; Mon,  7 Jan 2013 05:49:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.449
X-Spam-Level: 
X-Spam-Status: No, score=-104.449 tagged_above=-999 required=5 tests=[AWL=-1.850, 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 1C9VBsrDwQOe for ; Mon,  7 Jan 2013 05:49:34 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7F67821F854D for ; Mon,  7 Jan 2013 05:49:34 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MOVLv-1TxyNU1m1V-005pJ6 for ; Mon, 07 Jan 2013 14:49:33 +0100
Received: (qmail invoked by alias); 07 Jan 2013 13:49:33 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.104]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 07 Jan 2013 14:49:33 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/L7mZW8PrLjucpe9BxdQVxtqoScESE8thjkmZJjr 5p4wqPfgp+pZkV
Message-ID: <50EAD269.4090006@gmx.de>
Date: Mon, 07 Jan 2013 14:49:29 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Erik Wilde 
References: <50C5A6BB.5000300@versi.edu.au> <50CA92A2.5060301@versi.edu.au> <50CE9F39.4020601@versi.edu.au> <6993B286-2B25-4D92-A201-812F3909068B@mnot.net> <50EA808D.3060800@versi.edu.au> <50EAC900.7060605@berkeley.edu>
In-Reply-To: <50EAC900.7060605@berkeley.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-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: Mon, 07 Jan 2013 13:49:35 -0000

On 2013-01-07 14:09, Erik Wilde wrote:
> hello conal.
>
> On 2013-01-07 9:00 , Conal Tuohy wrote:
>> On 17/12/12 15:34, Mark Nottingham wrote:
>>> Yes, I'm familiar with the WebArch document. In practice, XML
>>> Namespaces can cause a lot of developer confusion, and I'd put forth
>>> that they should only be used where distributed extensibility is
>>> necessary, and there are no other ways to achieve it.
>> I beg to differ. I agree with Erik, there. Many developers (especially
>> those without much XML experience) don't like XML namespaces, and
>> there's no doubt they are a complication of the original XML model. But
>> like them or not, they are THE standard way to handle mixed vocabularies
>> in the XML world, and I firmly believe that more XML developers would be
>> confused by XML documents in which vocabularies are re-used and mixed
>> WITHOUT the help of XML namespaces. To be honest the idea of not using
>> XML's standard namespace mechanism for its God-given purpose seems
>> wilfully deviant to me.
>
> for the record: i do agree that XML namespaces are what is used in XML
> to clearly separate vocabularies, and thus they should be the default
> choice for doing this. i also think that even though intensely disliking
> namespaces for a while seemed to be the hip thing to do, in the meantime
> things have cooled down a bit, and they are just a fact of life when
> you're dealing with XML.
>
> that being said, however, what convinced me about mark's argument was
> the following: if you want to have a model that spans more than one
> representation (specifically, JSON and XML), and you don't want to be in
> the business of inventing namespaces in JSON, then avoiding namespaces
> in XML may be the best way to go. it still looks wrong to me, from the
> XML point of view, but from he "let's reuse the same model in JSON and
> XML" view, maybe it's the best possible way to go.

Erik: thanks for the explanation.

So what actually *is* the added complexity if we did use XML namespaces 
for the XML variant *only*?

Best regards, Julian


From dret@berkeley.edu  Mon Jan  7 07:00:56 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E3A21F88B9 for ; Mon,  7 Jan 2013 07:00:56 -0800 (PST)
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 hdT8aDR49QWM for ; Mon,  7 Jan 2013 07:00:55 -0800 (PST)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 90DCB21F88B5 for ; Mon,  7 Jan 2013 07:00:55 -0800 (PST)
Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretair.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TsEC1-0004on-CD; Mon, 07 Jan 2013 07:00:51 -0800
Message-ID: <50EAE31D.5090802@berkeley.edu>
Date: Mon, 07 Jan 2013 16:00:45 +0100
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Julian Reschke 
References: <50C5A6BB.5000300@versi.edu.au> <50CA92A2.5060301@versi.edu.au> <50CE9F39.4020601@versi.edu.au> <6993B286-2B25-4D92-A201-812F3909068B@mnot.net> <50EA808D.3060800@versi.edu.au> <50EAC900.7060605@berkeley.edu> <50EAD269.4090006@gmx.de>
In-Reply-To: <50EAD269.4090006@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-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: Mon, 07 Jan 2013 15:00:56 -0000

hello julian.

On 2013-01-07 14:49 , Julian Reschke wrote:
> On 2013-01-07 14:09, Erik Wilde wrote:
>> that being said, however, what convinced me about mark's argument was
>> the following: if you want to have a model that spans more than one
>> representation (specifically, JSON and XML), and you don't want to be in
>> the business of inventing namespaces in JSON, then avoiding namespaces
>> in XML may be the best way to go. it still looks wrong to me, from the
>> XML point of view, but from he "let's reuse the same model in JSON and
>> XML" view, maybe it's the best possible way to go.
> Erik: thanks for the explanation.
> So what actually *is* the added complexity if we did use XML namespaces
> for the XML variant *only*?

it wouldn't be easy to define a straightforward mapping between the JSON 
and the XML representations. it would be strange (i think) to define a 
format where representing some resources in XML would result in very 
strange JSON, or might not even be possible. if you want to use 
namespaces in the XML, then they should be meaningful (for example, 
represent a special kind of extension through the namespace URI). but 
then how would you map this to the equivalent JSON? you'd have to define 
a generic namespace mapping from XML into JSON, or something specific 
for our format, and both options are not very appealing.

cheers,

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 julian.reschke@gmx.de  Mon Jan  7 07:50:05 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D4021F867D for ; Mon,  7 Jan 2013 07:50:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 SWG7-t3hBU3p for ; Mon,  7 Jan 2013 07:50:05 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id EF56521F8775 for ; Mon,  7 Jan 2013 07:50:03 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LiZpS-1THn9C1ra8-00clpe for ; Mon, 07 Jan 2013 16:50:02 +0100
Received: (qmail invoked by alias); 07 Jan 2013 15:50:02 -0000
Received: from p54BB30A6.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.48.166] by mail.gmx.net (mp002) with SMTP; 07 Jan 2013 16:50:02 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19leb0jEb5l7SS7JkYgyQY7I4o30/EOHI86fJxm5+ FxyoOQaQq2FK40
Message-ID: <50EAEEA8.3010005@gmx.de>
Date: Mon, 07 Jan 2013 16:50:00 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Erik Wilde 
References: <50C5A6BB.5000300@versi.edu.au> <50CA92A2.5060301@versi.edu.au> <50CE9F39.4020601@versi.edu.au> <6993B286-2B25-4D92-A201-812F3909068B@mnot.net> <50EA808D.3060800@versi.edu.au> <50EAC900.7060605@berkeley.edu> <50EAD269.4090006@gmx.de> <50EAE31D.5090802@berkeley.edu>
In-Reply-To: <50EAE31D.5090802@berkeley.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-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: Mon, 07 Jan 2013 15:50:05 -0000

On 2013-01-07 16:00, Erik Wilde wrote:
> hello julian.
>
> On 2013-01-07 14:49 , Julian Reschke wrote:
>> On 2013-01-07 14:09, Erik Wilde wrote:
>>> that being said, however, what convinced me about mark's argument was
>>> the following: if you want to have a model that spans more than one
>>> representation (specifically, JSON and XML), and you don't want to be in
>>> the business of inventing namespaces in JSON, then avoiding namespaces
>>> in XML may be the best way to go. it still looks wrong to me, from the
>>> XML point of view, but from he "let's reuse the same model in JSON and
>>> XML" view, maybe it's the best possible way to go.
>> Erik: thanks for the explanation.
>> So what actually *is* the added complexity if we did use XML namespaces
>> for the XML variant *only*?
>
> it wouldn't be easy to define a straightforward mapping between the JSON
> and the XML representations. it would be strange (i think) to define a
> format where representing some resources in XML would result in very
> strange JSON, or might not even be possible. if you want to use
> namespaces in the XML, then they should be meaningful (for example,
> represent a special kind of extension through the namespace URI). but
> then how would you map this to the equivalent JSON? you'd have to define
> a generic namespace mapping from XML into JSON, or something specific
> for our format, and both options are not very appealing.
>
> cheers,
>
> dret.

I understand your point. Also I think that JSON should indeed have a 
mapping for XML namespaces (such as proposed by Peter St. Andre, if I 
recall correctly).

That being said: if *this* vocabulary used a namespace, it would still 
be trivial to map to JSON; as long as it's not being mixed with anything 
else. So where is the *actual* problem here, except that the XML variant 
would be more ... versatile?

Best regards, Julian



From dret@berkeley.edu  Mon Jan  7 08:01:48 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8D121F867D for ; Mon,  7 Jan 2013 08:01:48 -0800 (PST)
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 Q74L0aGcyW7V for ; Mon,  7 Jan 2013 08:01:48 -0800 (PST)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1A96D21F8467 for ; Mon,  7 Jan 2013 08:01:48 -0800 (PST)
Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretair.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TsF8z-0003oy-8B; Mon, 07 Jan 2013 08:01:46 -0800
Message-ID: <50EAF166.9010507@berkeley.edu>
Date: Mon, 07 Jan 2013 17:01:42 +0100
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Julian Reschke 
References: <50C5A6BB.5000300@versi.edu.au> <50CA92A2.5060301@versi.edu.au> <50CE9F39.4020601@versi.edu.au> <6993B286-2B25-4D92-A201-812F3909068B@mnot.net> <50EA808D.3060800@versi.edu.au> <50EAC900.7060605@berkeley.edu> <50EAD269.4090006@gmx.de> <50EAE31D.5090802@berkeley.edu> <50EAEEA8.3010005@gmx.de>
In-Reply-To: <50EAEEA8.3010005@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-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: Mon, 07 Jan 2013 16:01:48 -0000

hello julian.

On 2013-01-07 16:50 , Julian Reschke wrote:
> I understand your point. Also I think that JSON should indeed have a
> mapping for XML namespaces (such as proposed by Peter St. Andre, if I
> recall correctly).

well, i think the devil is in many details there, starting with 
different naming syntaxes and all of this then leaking into all 
technologies that are layered on top of JSON. for now, i think it's safe 
to assume that we will not have such a thing anytime soon.

> That being said: if *this* vocabulary used a namespace, it would still
> be trivial to map to JSON; as long as it's not being mixed with anything
> else. So where is the *actual* problem here, except that the XML variant
> would be more ... versatile?

my initial proposal was to at least have a namespace in there for the 
syntax. however, it seems odd (at least to me) to use namespaces but 
then to not use them what they are intended for: to segment vocabularies 
and then have the standard namespace and allow extensions to add their 
own namespaced vocabularies. so if we accept that we're not using 
namespaces to keep vocabularies separate, then maybe using a single 
namespace is almost more confusing than using a non-namespace 
vocabulary. but i see that this may be a matter of debate, and if most 
people would prefer to have at least one namespace used for everything 
(instead of having none), then we can certainly go that route.

the downside of this is that i am fairly certain that implementations 
then will start using namespaces when they use the XML format, because 
as conal pointed out, that's the natural thing to do in an XML world. 
because of this, we should at least plan ahead and add some language 
that would say how to treat this kind of XML: ignore any XML not in the 
one blessed namespace? or ignore namespaces and treat all local names as 
if they were in the blessed namespace?

cheers,

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 julian.reschke@gmx.de  Mon Jan  7 08:12:31 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AFE21F86C0 for ; Mon,  7 Jan 2013 08:12:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 YODT6wTLAoOX for ; Mon,  7 Jan 2013 08:12:31 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id BBECF21F845A for ; Mon,  7 Jan 2013 08:12:27 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LaIM4-1T8R9w2yaM-00m3Mz for ; Mon, 07 Jan 2013 17:12:26 +0100
Received: (qmail invoked by alias); 07 Jan 2013 16:12:26 -0000
Received: from p54BB30A6.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.48.166] by mail.gmx.net (mp024) with SMTP; 07 Jan 2013 17:12:26 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+EIXQ1UXSEgQbiR1+N8irpkPIbtucoWsiKnW8wTO 7WjEP/9JM5vuCX
Message-ID: <50EAF3E8.2050409@gmx.de>
Date: Mon, 07 Jan 2013 17:12:24 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Erik Wilde 
References: <50C5A6BB.5000300@versi.edu.au> <50CA92A2.5060301@versi.edu.au> <50CE9F39.4020601@versi.edu.au> <6993B286-2B25-4D92-A201-812F3909068B@mnot.net> <50EA808D.3060800@versi.edu.au> <50EAC900.7060605@berkeley.edu> <50EAD269.4090006@gmx.de> <50EAE31D.5090802@berkeley.edu> <50EAEEA8.3010005@gmx.de> <50EAF166.9010507@berkeley.edu>
In-Reply-To: <50EAF166.9010507@berkeley.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-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: Mon, 07 Jan 2013 16:12:31 -0000

On 2013-01-07 17:01, Erik Wilde wrote:
> hello julian.
>
> On 2013-01-07 16:50 , Julian Reschke wrote:
>> I understand your point. Also I think that JSON should indeed have a
>> mapping for XML namespaces (such as proposed by Peter St. Andre, if I
>> recall correctly).
>
> well, i think the devil is in many details there, starting with
> different naming syntaxes and all of this then leaking into all
> technologies that are layered on top of JSON. for now, i think it's safe
> to assume that we will not have such a thing anytime soon.
>
>> That being said: if *this* vocabulary used a namespace, it would still
>> be trivial to map to JSON; as long as it's not being mixed with anything
>> else. So where is the *actual* problem here, except that the XML variant
>> would be more ... versatile?
>
> my initial proposal was to at least have a namespace in there for the
> syntax. however, it seems odd (at least to me) to use namespaces but
> then to not use them what they are intended for: to segment vocabularies
> and then have the standard namespace and allow extensions to add their
> own namespaced vocabularies. so if we accept that we're not using
> namespaces to keep vocabularies separate, then maybe using a single
> namespace is almost more confusing than using a non-namespace
> vocabulary. but i see that this may be a matter of debate, and if most
> people would prefer to have at least one namespace used for everything
> (instead of having none), then we can certainly go that route.
> ...

Another use case for XML namespaces is so that the elements of *this* 
vocabulary can be embedded more easily into *other* vocabularies. I 
would think it's ok if this would be a difference between the XML and 
the JSON side...

> the downside of this is that i am fairly certain that implementations
> then will start using namespaces when they use the XML format, because
> as conal pointed out, that's the natural thing to do in an XML world.
> because of this, we should at least plan ahead and add some language
> that would say how to treat this kind of XML: ignore any XML not in the
> one blessed namespace? or ignore namespaces and treat all local names as
> if they were in the blessed namespace?
> ...

Um, no. There shouldn't be multiple element names for the same thing. 
Either stick with no namespace, or use a namespace, and use that 
throughout...

Best regards, Julian

From jasnell@gmail.com  Mon Jan  7 12:55:31 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35ED621F88E4 for ; Mon,  7 Jan 2013 12:55:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.473
X-Spam-Level: 
X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[AWL=-0.875, 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 52Z3DXglHsvv for ; Mon,  7 Jan 2013 12:55:30 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 476A821F88C8 for ; Mon,  7 Jan 2013 12:55:30 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id c13so24749429ieb.3 for ; Mon, 07 Jan 2013 12:55:28 -0800 (PST)
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=FAM9JOtlqPiLPy3xQhU4PGqX/JWLxOaxwopoAJkGpHQ=; b=MeVxSU8ZybE8dgYrJDPDQFcNy3ktCV7lfCUG93UQYiSqE3TvUUIEROlQNT/NQXsT5N AJKiaefx5MYwPagH8EmaEKiSEtwWeeVRD2QivHr0BO6sybWVqlIZPuow5jaK662IhY+F hn/czuGlIxWk0fH8mH9IOesnsFXzH5jZx88TKvMRaNoC4JfTTBR1zLuekSLx6VhpGMge wR7d7VjzPBQqwssozhKSALJ1w9cAsRy2MT+pxJ7N+7SCjurNXtcQ+1/Oj5sZl7zTTO25 m1y6s+p5nkaUztUFo+Y7+bLTNwA3W/SHMdxR1VjeDwIwzEcbPOA/vdKZWUH/hUt5x9A+ dbwg==
Received: by 10.42.58.202 with SMTP id j10mr45707394ich.39.1357592127760; Mon, 07 Jan 2013 12:55:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.7.19 with HTTP; Mon, 7 Jan 2013 12:55:07 -0800 (PST)
From: James M Snell 
Date: Mon, 7 Jan 2013 12:55:07 -0800
Message-ID: 
To: IETF Apps Discuss 
Content-Type: multipart/alternative; boundary=20cf3033461386699404d2b90c0e
Subject: [apps-discuss] Updated JSON Predicates
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 07 Jan 2013 20:55:31 -0000

--20cf3033461386699404d2b90c0e
Content-Type: text/plain; charset=UTF-8

I have posted an update to the JSON Predicates document. Again, as I've
mentioned before, this draft is largely experimental in nature at this
point and is intended to provide additional predicate operations to JSON
Patch. It is still very much a work in progress and is far from completion.
Nothing in the doc should be set in stone, particularly the new stuff I
just added. Comments and feedback are welcome... even if only to tell me
how bad of an idea the new stuff may be ;-)

http://www.ietf.org/id/draft-snell-json-test-05.txt

The main changes are:

1. Dedicate mime media type for JSON Patch documents that include JSON
Predicates

2. New conditional operation properties that can be used to alter the
processing of a JSON Patch operation. For instance:

  {
    "op": "add",
    "path": "/a/b/-",
    "value": 1,
    "if": {
      "op": "and",
      "path": "/a/b",
      "apply": [
        {"op":"defined"},
        {"op":"type", "value": "array"}
      ]
    }
  }

In this case, the value 1 will be added to "/a/b/-" only if "/a/b" exists
and is an array. If that condition is not met, the operation is simply
skipped over and processing of the patch document continues without
reporting an error.

I fully understand why this type of change would be controversial. So why
would we do this? Consider the following example:

     [
       {
         "op": "add",
         "path": "/a/b",
         "value": [],
         "unless": {
           "op": "type",
           "value": "array"
         }
       },
       {
         "op": "add",
         "path": "/a/b/-",
         "value": "ABC"
       }
     ]

Here, the Patch document will ensure that the path "/a/b" exists and is an
array prior to applying the secondary and. If "/a/b" exists and is not an
array, it's value is overridden and changed to an array. If "/a/b" doesn't
exist, it's added. If "/a/b" does exist and is already an array, processing
just skips over the first "add" and moves on to the second one.

Yes, there are other ways of doing this. I added this to the document in
order to get it on the table for discussion. I think it would be useful and
have examples, but I'm not opposed to pulling it back out.

Feedback and comments are more than welcome, as always.

- James

--20cf3033461386699404d2b90c0e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I have posted an upda=
te to the JSON Predicates document. Again, as I've mentioned before, th=
is draft is largely experimental in nature at this point and is intended to=
 provide additional predicate operations to JSON Patch. It is still very mu=
ch a work in progress and is far from completion. Nothing in the doc should=
 be set in stone, particularly the new stuff I just added. Comments and fee=
dback are welcome... even if only to tell me how bad of an idea the new stu=
ff may be ;-)







The main changes are:

1. Dedicate mime media type for JSON Patch =
documents that include JSON Predicates




2. New conditional operation proper=
ties that can be used to alter the processing of a JSON Patch operation. Fo=
r instance:




=C2=A0 {
=C2=A0 =C2=A0 "op": "add&=
quot;,



=C2=A0 =C2=A0 "path&q=
uot;: "/a/b/-",
=C2=A0 =C2=A0 "value": 1,
=C2=A0 =C2=A0 "if": {


=C2=A0 =C2=A0 =C2=A0 "=
;op": "and",
=C2=A0 =C2=A0 =C2=A0 "path": "/a/b",
=C2=A0 =C2=A0 =C2=
=A0 "apply": [



=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 {"op":"defined"},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {"op":&qu=
ot;type", "value": "array"}



=C2=A0 =C2=A0 =C2=A0 ]
=C2=A0 =C2=A0 }
=C2=A0 }=





In this case,=
 the value 1 will be added to "/a/b/-" only if "/a/b" e=
xists and is an array. If that condition is not met, the operation is simpl=
y skipped over and processing of the patch document continues without repor=
ting an error.=C2=A0




I fully understand why this type of=
 change would be controversial. So why would we do this? Consider the follo=
wing example:




=C2=A0 =C2=A0 =C2=A0[
=C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
"op": "add",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0"path": "/a/b",



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"value": [],
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"unless": {
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"op": "type",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"value": "arr=
ay"
=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 =C2=A0 =C2=A0"op": "add&=
quot;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"path": "=
/a/b/-",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"value"=
: "ABC"
=C2=A0 =C2=A0 =C2=A0 =C2=A0}



=C2=A0 =C2=A0 =C2=A0]

Here, the Patch d=
ocument will ensure that the path "/a/b" exists and is an array p=
rior to applying the secondary and. If "/a/b" exists and is not a=
n array, it's value is overridden and changed to an array. If "/a/=
b" doesn't exist, it's added. If "/a/b" does exist a=
nd is already an array, processing just skips over the first "add"=
; and moves on to the second one.=C2=A0




Yes, there are other ways of doing this. I =
added this to the document in order to get it on the table for discussion. =
I think it would be useful and have examples, but I'm not opposed to pu=
lling it back out.




Feedback and comments are more than welcome=
, as always.

- James




--20cf3033461386699404d2b90c0e--

From internet-drafts@ietf.org  Mon Jan  7 13:57:14 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CB921F86C2; Mon,  7 Jan 2013 13:57:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.301
X-Spam-Level: 
X-Spam-Status: No, score=-99.301 tagged_above=-999 required=5 tests=[AWL=-2.984, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HELO_MISMATCH_COM=0.553, RCVD_IN_XBL=3.033, 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 YKVVD5gxSiXy; Mon,  7 Jan 2013 13:57:12 -0800 (PST)
Received: from jlonline.com (pip13.ptt.js.cn [61.155.13.243]) by ietfa.amsl.com (Postfix) with SMTP id 40D1721F86C0; Mon,  7 Jan 2013 13:57:11 -0800 (PST)
Received: from jlonline.com([10.100.0.22]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm050eb4b8d; Tue, 08 Jan 2013 05:48:12 +0800
Received: from mail.ietf.org([64.170.98.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm1b50e69c4b; Fri, 04 Jan 2013 12:02:35 +0800
Received: from mail.ietf.org([64.170.98.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id AISP action; Fri, 04 Jan 2013 12:02:35 +0800
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B75921F8CA7; Thu,  3 Jan 2013 19:56:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1357271807; bh=SR81G7ubBTjCelEUPdgoD8TRiHYeBbwGq+YAlbgQJeY=; h=MIME-Version:From:To:Subject:Message-ID:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=NgL1YWYzF45iD6zjf9RwnAt32lprgWu9KBq+2qSdfm8kZjr4scH6S7CQeUB29Y8RG xA9zJyUh4loR3Vz3W6t8vcK8RS2ti8mfHQUmgPaBtXhYEmQymURc7myWm+dWRwIOlc nZoUwXXL/Pmg9JjrH6ACcJZzhqTmhR8Shh56Uawc=
X-Original-To: i-d-announce@ietfa.amsl.com
Delivered-To: i-d-announce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F8E21F8CB1; Thu,  3 Jan 2013 19:56:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzRMbAEsw4HN; Thu,  3 Jan 2013 19:56:45 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FA921F8CBF; Thu,  3 Jan 2013 19:56:45 -0800 (PST)
MIME-Version: 1.0
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.37
Message-ID: <20130104035645.14550.34061.idtracker@ietfa.amsl.com>
Date: Thu, 03 Jan 2013 19:56:45 -0800
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: i-d-announce-bounces@ietf.org
Errors-To: i-d-announce-bounces@ietf.org
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org
X-AIMC-Msg-ID: CAX4yq3B
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: internet-drafts@ietf.org
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-09.txt
X-BeenThere: apps-discuss@ietf.org
Reply-To: internet-drafts@ietf.org
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Jan 2013 21:57:14 -0000

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-09.txt
	Pages           : 17
	Date            : 2013-01-03

Abstract:
   JSON Patch defines the media type "application/json-patch", a JSON
   document structure for expressing a sequence of operations to apply
   to a JavaScript Object Notation (JSON) document, suitable for use
   with the HTTP PATCH method.


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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-patch-09


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From conal.tuohy@gmail.com  Mon Jan  7 14:16:18 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F259421F8967 for ; Mon,  7 Jan 2013 14:16:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.443
X-Spam-Level: 
X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, J_CHICKENPOX_55=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 WyiIAHDzrZwM for ; Mon,  7 Jan 2013 14:16:16 -0800 (PST)
Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7C01521F8949 for ; Mon,  7 Jan 2013 14:16:16 -0800 (PST)
Received: by mail-pa0-f54.google.com with SMTP id bi5so11009562pad.27 for ; Mon, 07 Jan 2013 14:16:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=kBHTxTjDgBK47MvNjQLRys3I5CEjoRs2RG4Mk6lrNiw=; b=Gv3qpF+xd5WxAGkB/RyyplvVoTnowup4usnELMycgyO48svlV2oPa+GDCWfLyL/dHJ msiAysZPkxRCUskGGTPZv1vE+2NxDRpVB+rVjLM/qnQ8PqQEK9Uh08+D9g/2DZNf/nSj uWeDoVB0N2nHRoeRhHkGGZG6k3yqKiQmmVhSuMflU0BpPbLOmwR9FvKPnVAjfJYKBBH5 dv0mjdDHt4MXSyt4GEdASG9tTw+BxmC9Aaz8ZGm2FFVN0YBqQPLbhiPwWQAnF+arFIac R+XRsE+nuY8UfHk7YyRelDRWCEWs/lyJIrriIl7AEJOOeJt1J7zyCMCYq3Fq0uOdPTRJ sWoA==
X-Received: by 10.69.0.40 with SMTP id av8mr191433245pbd.117.1357596976291; Mon, 07 Jan 2013 14:16:16 -0800 (PST)
Received: from [10.1.1.8] (d58-106-8-154.rdl801.qld.optusnet.com.au. [58.106.8.154]) by mx.google.com with ESMTPS id qr8sm38303439pbc.64.2013.01.07.14.16.12 (version=SSLv3 cipher=OTHER); Mon, 07 Jan 2013 14:16:14 -0800 (PST)
Sender: Conal Tuohy 
Message-ID: <50EB4929.3020507@versi.edu.au>
Date: Tue, 08 Jan 2013 08:16:09 +1000
From: Conal Tuohy 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Erik Wilde 
References: <50C5A6BB.5000300@versi.edu.au> <50CA92A2.5060301@versi.edu.au> <50CE9F39.4020601@versi.edu.au> <6993B286-2B25-4D92-A201-812F3909068B@mnot.net> <50EA808D.3060800@versi.edu.au> <50EAC900.7060605@berkeley.edu> <50EAD269.4090006@gmx.de> <50EAE31D.5090802@berkeley.edu>
In-Reply-To: <50EAE31D.5090802@berkeley.edu>
Content-Type: multipart/alternative; boundary="------------010407020609030909050704"
Cc: Julian Reschke , Mark Nottingham , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-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: Mon, 07 Jan 2013 22:16:18 -0000

This is a multi-part message in MIME format.
--------------010407020609030909050704
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 08/01/13 01:00, Erik Wilde wrote:
> hello julian.
>
> On 2013-01-07 14:49 , Julian Reschke wrote:
>> On 2013-01-07 14:09, Erik Wilde wrote:
>>> that being said, however, what convinced me about mark's argument was
>>> the following: if you want to have a model that spans more than one
>>> representation (specifically, JSON and XML), and you don't want to 
>>> be in
>>> the business of inventing namespaces in JSON, then avoiding namespaces
>>> in XML may be the best way to go. it still looks wrong to me, from the
>>> XML point of view, but from he "let's reuse the same model in JSON and
>>> XML" view, maybe it's the best possible way to go.
>> Erik: thanks for the explanation.
>> So what actually *is* the added complexity if we did use XML namespaces
>> for the XML variant *only*?
>
> it wouldn't be easy to define a straightforward mapping between the 
> JSON and the XML representations. it would be strange (i think) to 
> define a format where representing some resources in XML would result 
> in very strange JSON, or might not even be possible. if you want to 
> use namespaces in the XML, then they should be meaningful (for 
> example, represent a special kind of extension through the namespace 
> URI). but then how would you map this to the equivalent JSON? you'd 
> have to define a generic namespace mapping from XML into JSON, or 
> something specific for our format, and both options are not very 
> appealing.
>
My understanding was that the JSON model would be primary; hence the XML 
version would not be arbitrary XML, but only an XML version of whatever 
was expressible in the JSON syntax. So there'd be no need for anything 
complicated.


-- 
Conal Tuohy
HuNI  Technical Coordinator 

Victorian eResearch Strategic Initiative 

Skype: conal.tuohy
Twitter: @conal_tuohy 
Mobile: +61-466324297 


--------------010407020609030909050704
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 08/01/13 01:00, Erik Wilde wrote:

    

    
hello
      julian.
      

      

      On 2013-01-07 14:49 , Julian Reschke wrote:
      

      
On 2013-01-07 14:09, Erik Wilde wrote:
        

        
that being said, however, what convinced
          me about mark's argument was
          

          the following: if you want to have a model that spans more
          than one
          

          representation (specifically, JSON and XML), and you don't
          want to be in
          

          the business of inventing namespaces in JSON, then avoiding
          namespaces
          

          in XML may be the best way to go. it still looks wrong to me,
          from the
          

          XML point of view, but from he "let's reuse the same model in
          JSON and
          

          XML" view, maybe it's the best possible way to go.
          

        

        Erik: thanks for the explanation.
        

        So what actually *is* the added complexity if we did use XML
        namespaces
        

        for the XML variant *only*?
        

      

      

      it wouldn't be easy to define a straightforward mapping between
      the JSON and the XML representations. it would be strange (i
      think) to define a format where representing some resources in XML
      would result in very strange JSON, or might not even be possible.
      if you want to use namespaces in the XML, then they should be
      meaningful (for example, represent a special kind of extension
      through the namespace URI). but then how would you map this to the
      equivalent JSON? you'd have to define a generic namespace mapping
      from XML into JSON, or something specific for our format, and both
      options are not very appealing.
      

      

    

    My understanding was that the JSON model would be primary; hence the
    XML version would not be arbitrary XML, but only an XML version of
    whatever was expressible in the JSON syntax. So there'd be no need
    for anything complicated.

    

    

    
-- 

      

        Conal Tuohy

        HuNI Technical
          Coordinator

        Victorian
          eResearch Strategic Initiative

        Skype: conal.tuohy

        Twitter: @conal_tuohy

        Mobile: +61-466324297
      

    

  


--------------010407020609030909050704--

From conal.tuohy@gmail.com  Mon Jan  7 14:25:18 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5B421F8949 for ; Mon,  7 Jan 2013 14:25:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.593
X-Spam-Level: 
X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, J_CHICKENPOX_55=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 zv2NIXJ0mibE for ; Mon,  7 Jan 2013 14:25:17 -0800 (PST)
Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 14A1821F8967 for ; Mon,  7 Jan 2013 14:25:17 -0800 (PST)
Received: by mail-pb0-f41.google.com with SMTP id xa7so10924909pbc.0 for ; Mon, 07 Jan 2013 14:25:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=PX5KQRS52TglQ9nQYCnKyOR9FxCpKtU+z4FUEtNmGSk=; b=PBBGXkOpAvsrZJmJRoSJR9aRHGZV07YVZZPfSpQPGDlk6lKpuR4ta/3/zn6sNg8EFh pYD8bDii58w0aieNafexkyaza0nFSo1JQhcvl7NPqNsCaUuOEDR48LSe7CMxcE2PYCrc wfoKV8waaEpqi3CYz1dXWQCJ7Yx2Zc5rNHZExLLEL4O9YpYvB1aeGG9eUqK76rxIy3N7 xOzwz4WgRuqrD03O0dPlA5XqKothBWd7nCPcEFiCwuAOMXU5XA8MXfOnjjAIu3TtHiHH 7o1QzoJY2H4i4bRVDQfiNM73RJ8FfXaFYOJV2q/KcrFdT6KQ09w4CUjfGXGJV4kf8et0 wcng==
X-Received: by 10.68.192.66 with SMTP id he2mr189959953pbc.112.1357597516802;  Mon, 07 Jan 2013 14:25:16 -0800 (PST)
Received: from [10.1.1.8] (d58-106-8-154.rdl801.qld.optusnet.com.au. [58.106.8.154]) by mx.google.com with ESMTPS id s7sm39422765paz.7.2013.01.07.14.25.13 (version=SSLv3 cipher=OTHER); Mon, 07 Jan 2013 14:25:15 -0800 (PST)
Sender: Conal Tuohy 
Message-ID: <50EB4B47.5060601@versi.edu.au>
Date: Tue, 08 Jan 2013 08:25:11 +1000
From: Conal Tuohy 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Erik Wilde 
References: <50C5A6BB.5000300@versi.edu.au> <50CA92A2.5060301@versi.edu.au> <50CE9F39.4020601@versi.edu.au> <6993B286-2B25-4D92-A201-812F3909068B@mnot.net> <50EA808D.3060800@versi.edu.au> <50EAC900.7060605@berkeley.edu>
In-Reply-To: <50EAC900.7060605@berkeley.edu>
Content-Type: multipart/alternative; boundary="------------020603000401060108080700"
Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-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: Mon, 07 Jan 2013 22:25:18 -0000

This is a multi-part message in MIME format.
--------------020603000401060108080700
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 07/01/13 23:09, Erik Wilde wrote:
>
> that being said, however, what convinced me about mark's argument was 
> the following: if you want to have a model that spans more than one 
> representation (specifically, JSON and XML), and you don't want to be 
> in the business of inventing namespaces in JSON, then avoiding 
> namespaces in XML may be the best way to go. 
Indeed, and I'd agree with that syllogism, and with the first premise, 
but not the second.

In fact the informal JSON schema for http-problem already has invented a 
quasi-namespace feature - "describedBy". It would be only a small 
stretch to allow for an http-problem to include multiple "describedBy" 
links, each qualifying a particular set of properties. That would be my 
preferred solution.
> it still looks wrong to me, from the XML point of view, but from he 
> "let's reuse the same model in JSON and XML" view, maybe it's the best 
> possible way to go.
>
I presented a couple of use cases for namespaced properties which I 
think show that there's some value in having namespaces in the 
underlying model (i.e. for both XML and JSON). Do you have any comment 
on those?


-- 
Conal Tuohy
HuNI  Technical Coordinator 

Victorian eResearch Strategic Initiative 

Skype: conal.tuohy
Twitter: @conal_tuohy 
Mobile: +61-466324297 


--------------020603000401060108080700
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 07/01/13 23:09, Erik Wilde wrote:

    

    
 

      that being said, however, what convinced me about mark's argument
      was the following: if you want to have a model that spans more
      than one representation (specifically, JSON and XML), and you
      don't want to be in the business of inventing namespaces in JSON,
      then avoiding namespaces in XML may be the best way to go. 

    Indeed, and I'd agree with that syllogism, and with the first
    premise, but not the second. 

    

    In fact the informal JSON schema for http-problem already has
    invented a quasi-namespace feature - "describedBy". It would be only
    a small stretch to allow for an http-problem to include multiple
    "describedBy" links, each qualifying a particular set of properties.
    That would be my preferred solution. 

    
it
      still looks wrong to me, from the XML point of view, but from he
      "let's reuse the same model in JSON and XML" view, maybe it's the
      best possible way to go. 

      

    

    I presented a couple of use cases for namespaced properties which I
    think show that there's some value in having namespaces in the
    underlying model (i.e. for both XML and JSON). Do you have any
    comment on those?

    

    

    
-- 

      

        Conal Tuohy

        HuNI Technical
          Coordinator

        Victorian
          eResearch Strategic Initiative

        Skype: conal.tuohy

        Twitter: @conal_tuohy

        Mobile: +61-466324297
      

    

  


--------------020603000401060108080700--

From jasnell@gmail.com  Mon Jan  7 14:27:47 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE75511E80A5 for ; Mon,  7 Jan 2013 14:27:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level: 
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[AWL=-0.700, 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 stvequ9786tZ for ; Mon,  7 Jan 2013 14:27:42 -0800 (PST)
Received: from mail-ia0-f179.google.com (mail-ia0-f179.google.com [209.85.210.179]) by ietfa.amsl.com (Postfix) with ESMTP id AAC4C21F8464 for ; Mon,  7 Jan 2013 14:27:42 -0800 (PST)
Received: by mail-ia0-f179.google.com with SMTP id o25so16827326iad.38 for ; Mon, 07 Jan 2013 14:27:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=n6k+nMUGY46NWlqqZ4k3DctfL7SqpNUd2ZY6fEShgnA=; b=0ZLcQg2NP5GichvHwheXkzduQPft3sAY4X0egfPTjtQA9a3laKyfNLr0LDMlAcO1z5 sIu0Y7g8EQtsaNQkzGsSl/Rk99+lxpTmrAETlbqMcp+nr2/Vu3VZLMOI3VwX8EzhvLzU zWjXQgBtQKUecwWLiDuWfSOdMiELjANo+0k0ModM7GmnvyOafKdnLincZ6RUlaSCdN5Z MHl8ZU8jLsI+2XC5bT/Zbf6Rg+S0RXC6/aMrKuH6AVHH0/zP6DL6YJnJsh4MwJ3fd/om d1jbqoKuoPHf1oQdnvtAI6AL1yKET+VagHBedEpdvn2REwzMUz3sAmXIQ7As+amSQ1Fd Jj8w==
X-Received: by 10.50.178.10 with SMTP id cu10mr7047102igc.75.1357597662245; Mon, 07 Jan 2013 14:27:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.7.19 with HTTP; Mon, 7 Jan 2013 14:27:22 -0800 (PST)
In-Reply-To: <20130107222456.26439.3537.idtracker@ietfa.amsl.com>
References: <20130107222456.26439.3537.idtracker@ietfa.amsl.com>
From: James M Snell 
Date: Mon, 7 Jan 2013 14:27:22 -0800
Message-ID: 
To: IETF Apps Discuss 
Content-Type: multipart/alternative; boundary=e89a8f839ca167f4e204d2ba56ea
Subject: [apps-discuss] Fwd: New Version Notification for draft-snell-merge-patch-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: Mon, 07 Jan 2013 22:27:47 -0000

--e89a8f839ca167f4e204d2ba56ea
Content-Type: text/plain; charset=UTF-8

Minor update to clarify a couple of the rules around nulls in the provided
data. I'm considering making this a standards track independent submission
but want to do an informal last call here before asking it to be
submitted...


---------- Forwarded message ----------
From: 
Date: Mon, Jan 7, 2013 at 2:24 PM
Subject: New Version Notification for draft-snell-merge-patch-08.txt
To: jasnell@gmail.com



A new version of I-D, draft-snell-merge-patch-08.txt
has been successfully submitted by James M Snell and posted to the
IETF repository.

Filename:        draft-snell-merge-patch
Revision:        08
Title:           The application/json-merge-patch Media Type
Creation date:   2013-01-07
WG ID:           Individual Submission
Number of pages: 9
URL:
http://www.ietf.org/internet-drafts/draft-snell-merge-patch-08.txt
Status:          http://datatracker.ietf.org/doc/draft-snell-merge-patch
Htmlized:        http://tools.ietf.org/html/draft-snell-merge-patch-08
Diff:            http://www.ietf.org/rfcdiff?url2=draft-snell-merge-patch-08

Abstract:
   This specification defines the application/json-merge-patch media
   type and it's intended use with the HTTP PATCH method defined by RFC
   5789.




The IETF Secretariat

--e89a8f839ca167f4e204d2ba56ea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Minor upda=
te to clarify a couple of the rules around nulls in the provided data. I=
9;m considering making this a standards track independent submission but wa=
nt to do an informal last call here before asking it to be submitted...




---------- Forwarded mes=
sage ----------
From:  <internet-drafts@ietf.org=
>


Date: Mon, Jan 7, 2013 at 2:24 PM
Subject: New Version Notification for =
draft-snell-merge-patch-08.txt
To: =
jasnell@gmail.com




A new version of I-D, draft-snell-merge-patch-08.txt

has been successfully submitted by James M Snell and posted to the

IETF repository.



Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-snell-merge-patch

Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A008

Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The application/json-merge-patch =
Media Type

Creation date: =C2=A0 2013-01-07

WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission

Number of pages: 9

URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http:/=
/www.ietf.org/internet-drafts/draft-snell-merge-patch-08.txt

Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatracker.iet=
f.org/doc/draft-snell-merge-patch

Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/dr=
aft-snell-merge-patch-08

Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.=
ietf.org/rfcdiff?url2=3Ddraft-snell-merge-patch-08



Abstract:

=C2=A0 =C2=A0This specification defines the application/json-merge-patch me=
dia

=C2=A0 =C2=A0type and it's intended use with the HTTP PATCH method defi=
ned by RFC

=C2=A0 =C2=A05789.









The IETF Secretariat







--e89a8f839ca167f4e204d2ba56ea--

From conal.tuohy@gmail.com  Mon Jan  7 14:39:18 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1B321F87D5; Mon,  7 Jan 2013 14:39:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.643
X-Spam-Level: 
X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, J_CHICKENPOX_55=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 1gmmHx30ef3r; Mon,  7 Jan 2013 14:39:17 -0800 (PST)
Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id CDA3121F8835; Mon,  7 Jan 2013 14:39:16 -0800 (PST)
Received: by mail-da0-f44.google.com with SMTP id z20so8893152dae.3 for ; Mon, 07 Jan 2013 14:39:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=dTIXJFCLeu5k41HtqbS06tSljk19RUaV2XENEFAHFgc=; b=UGC7JnXQjXBHybUmI4RGLVhqts94KXyXeVt9IfEgjEHMxvoGgUauoccu+MyRE5Ct1E nGUPvmTOcid71YRIRwjcl2N7I0o0geAlinY9jE586Dd18ujN00HEvaCm8qx9zsfbXEjQ 7J1Onb7LbA/EhwdFy17d92vNktw9K/JiTxEf4egna6A45IZKeNeNWLeBlFKogGC9Imt2 kwlabR1GSKiNAzzZHTEwlY7V44MqY7mw1ga80DVdmIalu+OWrCOI7M7BxcVQoJ/fgs0S nECF0hORik1kbpcm5Kpvd1uIVb0b62uvTgROI1lMuyessl/1SwaDMIq1HTGQl61a8DKY RAiQ==
X-Received: by 10.68.213.202 with SMTP id nu10mr193946308pbc.91.1357598356307;  Mon, 07 Jan 2013 14:39:16 -0800 (PST)
Received: from [10.1.1.8] (d58-106-8-154.rdl801.qld.optusnet.com.au. [58.106.8.154]) by mx.google.com with ESMTPS id ai8sm38344177pbd.14.2013.01.07.14.39.11 (version=SSLv3 cipher=OTHER); Mon, 07 Jan 2013 14:39:14 -0800 (PST)
Sender: Conal Tuohy 
Message-ID: <50EB4E8B.30700@versi.edu.au>
Date: Tue, 08 Jan 2013 08:39:07 +1000
From: Conal Tuohy 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Matthew Morley 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>   
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010408020306010502060903"
Cc: IESG , Mark Nottingham , IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Mon, 07 Jan 2013 22:39:18 -0000

This is a multi-part message in MIME format.
--------------010408020306010502060903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 07/01/13 13:23, Matthew Morley wrote:
>
> For me the deficiency is not in the pointer, but patch format being 
> generated.
>
> One approach is to push that *one* test, structure conformity, into 
> the pointer syntax. Another is via the type operation.
>
> If a vague patch is generated, vague results are to be expected.
It seems to me, on the contrary, that the deficiency is in the pointer 
syntax, and I think it would be a mistake to try to work around that 
deficiency in JSON Patch. Because aren't there other things which one 
might do with JSON Pointer than use it with JSON Patch? There's been 
mention of having it registered as a URI fragment identifier syntax for 
JSON for example. JSON Pointers could then end up all over the place, 
outside of patches. IMHO JSON Pointer needs to be taken seriously as a 
technology in its own right.

-- 
Conal Tuohy
HuNI  Technical Coordinator 

Victorian eResearch Strategic Initiative 

Skype: conal.tuohy
Twitter: @conal_tuohy 


--------------010408020306010502060903
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 07/01/13 13:23, Matthew Morley
      wrote:

    

    

      
      

      For me the deficiency is not in the pointer, but patch format
      being generated.

      

      One approach is to push that *one* test, structure conformity,
      into the pointer syntax. Another is via the type operation.

      

      If a vague patch is generated, vague results are to be expected.

    

    It seems to me, on the contrary, that the deficiency is in the
    pointer syntax, and I think it would be a mistake to try to work
    around that deficiency in JSON Patch. Because aren't there other
    things which one might do with JSON Pointer than use it with JSON
    Patch? There's been mention of having it registered as a URI
    fragment identifier syntax for JSON for example. JSON Pointers could
    then end up all over the place, outside of patches. IMHO JSON
    Pointer needs to be taken seriously as a technology in its own
    right. 

    

    
-- 

      

        Conal Tuohy

        HuNI Technical
          Coordinator

        Victorian
          eResearch Strategic Initiative

        Skype: conal.tuohy

        Twitter: @conal_tuohy
      

    

  


--------------010408020306010502060903--

From pbryan@anode.ca  Mon Jan  7 17:33:13 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBCC11E80D7; Mon,  7 Jan 2013 17:33:13 -0800 (PST)
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 LHRa-LOgY6SK; Mon,  7 Jan 2013 17:33:12 -0800 (PST)
Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id ACA8211E80B8; Mon,  7 Jan 2013 17:33:12 -0800 (PST)
Received: from [10.126.22.206] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 009E8699B; Tue,  8 Jan 2013 01:33:11 +0000 (UTC)
From: "Paul C. Bryan" 
To: Robert Sayre 
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot> 
Content-Type: multipart/alternative; boundary="=-I8ZK7EqkdsYa6okd4xdy"
Date: Mon, 07 Jan 2013 17:33:10 -0800
Message-ID: <1357608790.27936.223.camel@pbryan-wsl.internal.salesforce.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 01:33:13 -0000

--=-I8ZK7EqkdsYa6okd4xdy
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On Sun, 2013-01-06 at 16:01 -0800, Robert Sayre wrote:


> This last assertion really isn't qualified very well.


It would have been better for me to state this is my opinion, based on
discussions that were animated from similar objections raised in the
past. 

Paul

--=-I8ZK7EqkdsYa6okd4xdy
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


On Sun, 2013-01-06 at 16:01 -0800, Robert Sayre wrote:






This last assertion really isn't qualified very well.






It would have been better for me to state this is my opinion, based on discussions that were animated from similar objections raised in the past. 



Paul



--=-I8ZK7EqkdsYa6okd4xdy--


From barryleiba.mailing.lists@gmail.com  Mon Jan  7 18:35:41 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E7721F84FD for ; Mon,  7 Jan 2013 18:35:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.196
X-Spam-Level: 
X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[AWL=-0.219, 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 9h3t2afm14EO for ; Mon,  7 Jan 2013 18:35:41 -0800 (PST)
Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9D821F84F5 for ; Mon,  7 Jan 2013 18:35:41 -0800 (PST)
Received: by mail-vc0-f178.google.com with SMTP id l6so6462966vcl.23 for ; Mon, 07 Jan 2013 18:35:40 -0800 (PST)
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=BUV1ihNp9DBk/MT0BqyFslyFcP/0J5dA5lNeC7xDKxM=; b=brTg8yU3kO/GXfyvnqKgmuiYIMi+ix/uudXDh7+N4V8K1D8jcCEHROjMyK8O/ACsFN jM2Gkva/eML85ynjCMZzT5oPlWwbV2tO7y3SC6ysQcKQ7PqDnAHvqHz4Q433P63JTXWP Gvqb3Samr1ep/Unr8je/2b+aK12dOrI7PQohJziwwRYTDMoSTEBkWkLQwSWCfXTmfcQG Ye/IKy5HAsRIBeyTMmDfAyxWVs2WmfoY59MBIb2tkhuh6sC/Z6At4uuUDxbaN5lg0eQs 8pfNroQdYLnFa1Lmt9DPPsjMquTvAFNhj6l9Sqie5C/C6kLyofhnVDdkgX3/K4WQFQQj ep5w==
MIME-Version: 1.0
Received: by 10.52.88.33 with SMTP id bd1mr73512524vdb.70.1357612540784; Mon, 07 Jan 2013 18:35:40 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Mon, 7 Jan 2013 18:35:40 -0800 (PST)
In-Reply-To: 
References: <20130107222456.26439.3537.idtracker@ietfa.amsl.com> 
Date: Mon, 7 Jan 2013 21:35:40 -0500
X-Google-Sender-Auth: k5P4_yphnLUbWqIe9o98EGBnpR4
Message-ID: 
From: Barry Leiba 
To: James M Snell 
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-snell-merge-patch-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: Tue, 08 Jan 2013 02:35:42 -0000

> Minor update to clarify a couple of the rules around nulls in the provided
> data. I'm considering making this a standards track independent submission
> but want to do an informal last call here before asking it to be
> submitted...

I presume you mean "standards track INDIVIDUAL submission" sponsored
by an AD.  Independent submissions (those sent directly to the RFC
Editor and published in the Independent Stream) can't be Standards
Track.

Barry

From jasnell@gmail.com  Mon Jan  7 18:36:35 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D2821F8501 for ; Mon,  7 Jan 2013 18:36:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.181
X-Spam-Level: 
X-Spam-Status: No, score=-4.181 tagged_above=-999 required=5 tests=[AWL=-0.583, 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 oaLdcu5sR6yv for ; Mon,  7 Jan 2013 18:36:35 -0800 (PST)
Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEA821F84FD for ; Mon,  7 Jan 2013 18:36:35 -0800 (PST)
Received: by mail-ia0-f172.google.com with SMTP id r13so674489iar.17 for ; Mon, 07 Jan 2013 18:36:34 -0800 (PST)
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=WP+ZKKBsoAbyE/zLjeKReNy8mg3aLQch28ma7dWsAzk=; b=Y7DzliaDDBoRiDGzWBcUkXx5JEvA0A3zWyNiTG5sAO/fGQccZVg4Gq8GtNo+ltpuGs bgiTaOMe8vs3NbJ3JWdnCVh1xJbXvacIsbHB02bqS5tdXDf8g4G/CwmwQHXDaOuIZ+ME XcbLPWVRYFZxcACxgXrDfgxm8QvD3ABdJzwqIzOSVHwzt5e/9uuw3DXfKl2IXeGFhLlG FoKGocf3AoLo++1VAckGxsd64Htdsc2pwxmjJbeGITbWH5YlFCakrRdLQIA9vjTaNd/3 3GpaMxxCK7ZAvb/FyZmTzmK2WnF4WCMdYnDJwLdg0SdqW8JeMjPsuDuqM3PYRgFz7oz3 iB3w==
MIME-Version: 1.0
Received: by 10.50.158.170 with SMTP id wv10mr7564802igb.75.1357612594781; Mon, 07 Jan 2013 18:36:34 -0800 (PST)
Received: by 10.64.7.19 with HTTP; Mon, 7 Jan 2013 18:36:34 -0800 (PST)
Received: by 10.64.7.19 with HTTP; Mon, 7 Jan 2013 18:36:34 -0800 (PST)
In-Reply-To: 
References: <20130107222456.26439.3537.idtracker@ietfa.amsl.com>  
Date: Mon, 7 Jan 2013 18:36:34 -0800
Message-ID: 
From: James M Snell 
To: Barry Leiba 
Content-Type: multipart/alternative; boundary=14dae9340f21745d4504d2bdd0a2
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-snell-merge-patch-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: Tue, 08 Jan 2013 02:36:35 -0000

--14dae9340f21745d4504d2bdd0a2
Content-Type: text/plain; charset=UTF-8

Oh right.. sorry... :)
On Jan 7, 2013 6:35 PM, "Barry Leiba"  wrote:

> > Minor update to clarify a couple of the rules around nulls in the
> provided
> > data. I'm considering making this a standards track independent
> submission
> > but want to do an informal last call here before asking it to be
> > submitted...
>
> I presume you mean "standards track INDIVIDUAL submission" sponsored
> by an AD.  Independent submissions (those sent directly to the RFC
> Editor and published in the Independent Stream) can't be Standards
> Track.
>
> Barry
>

--14dae9340f21745d4504d2bdd0a2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Oh right.. sorry... :)


On Jan 7, 2013 6:35 PM, "Barry Leiba" =
<barryleiba@computer.org&=
gt; wrote:

> Minor update to clarify a couple of the rules around nulls in the prov=
ided

> data. I'm considering making this a standards track independent su=
bmission

> but want to do an informal last call here before asking it to be

> submitted...



I presume you mean "standards track INDIVIDUAL submission" sponso=
red

by an AD. =C2=A0Independent submissions (those sent directly to the RFC

Editor and published in the Independent Stream) can't be Standards

Track.



Barry




--14dae9340f21745d4504d2bdd0a2--

From barryleiba@gmail.com  Mon Jan  7 18:42:20 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CA71F0CFA for ; Mon,  7 Jan 2013 18:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.188
X-Spam-Level: 
X-Spam-Status: No, score=-103.188 tagged_above=-999 required=5 tests=[AWL=-0.211, 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 hygDapOURHuV for ; Mon,  7 Jan 2013 18:42:20 -0800 (PST)
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 180E41F0CB3 for ; Mon,  7 Jan 2013 18:42:19 -0800 (PST)
Received: by mail-lb0-f170.google.com with SMTP id j14so23077lbo.29 for ; Mon, 07 Jan 2013 18:42:19 -0800 (PST)
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=J9xz5WK/iVEtQLVvI7custVIy7KO9sYVnnrSe0LRp4o=; b=v4ph2eFVtvfsKPNADg9xymeahEhe/ylZdw3qidC/ZgwcKIhGt8JdEMEU28iANAPlHi EAdBBHqbDDK8GADzMGcZ017lVSseen8ZDQi2qL+wsxLqRw+24RzHXJ80nSFRP56ERiSg +4p8Rjow8MhAwcaLtIxz5Wz14ePeNICnlQ5mkEvWhsM84EgaEWMSvwRY4P6Dp3N5k5qS ZtmyDTwlR2cOctyxd7Hvc4jcItzNKVv0mCAbCUb8r5m1M86OqMwbapCeLzwuW5W3dOMS XUEFa/w7hIGserpb9Fe2ePNwYXFOhpQLcvHFg1HDDWwqkdo+t4S9cA8KoSJuMSjFjUxS 3qTw==
MIME-Version: 1.0
Received: by 10.152.123.77 with SMTP id ly13mr4916596lab.4.1357612938997; Mon, 07 Jan 2013 18:42:18 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.112.81.194 with HTTP; Mon, 7 Jan 2013 18:42:18 -0800 (PST)
In-Reply-To: 
References: <20130107222456.26439.3537.idtracker@ietfa.amsl.com>   
Date: Mon, 7 Jan 2013 21:42:18 -0500
X-Google-Sender-Auth: U7baoAPoPz_-tp8vg9dd2ZLC_6M
Message-ID: 
From: Barry Leiba 
To: James M Snell 
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-snell-merge-patch-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: Tue, 08 Jan 2013 02:42:20 -0000

>> I presume you mean "standards track INDIVIDUAL submission" sponsored
>> by an AD.  Independent submissions (those sent directly to the RFC
>> Editor and published in the Independent Stream) can't be Standards
>> Track.
>
> Oh right.. sorry... :)

I really do wish we hadn't called the two things by names that are
sufficiently similar so as to be *very* frequently confused and
confusing.

Sigh.

b

From superuser@gmail.com  Mon Jan  7 20:40:22 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB4C11E8097; Mon,  7 Jan 2013 20:40:22 -0800 (PST)
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 utRG83JWgdBS; Mon,  7 Jan 2013 20:40:21 -0800 (PST)
Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) by ietfa.amsl.com (Postfix) with ESMTP id C276021F846E; Mon,  7 Jan 2013 20:40:20 -0800 (PST)
Received: by mail-la0-f41.google.com with SMTP id em20so8112lab.28 for ; Mon, 07 Jan 2013 20:40:19 -0800 (PST)
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=WWhwUo8iuICmHP0k/Wkr1TSkhuqa4juxuM6ZL+Wc5iY=; b=Q6pZjTpZAvnld7wxtJ+TqIdPVhDzFpnaLNvvfMsHxrnqMYlmSGFex/AzumtJ29+QAV dYTRV/oFAn9t1xQdLCqTvEAc5UXSzP9zWB1z9CD0atvJ/RyLyTgrXpICJLcWu8sRejX/ PMwne6tq1cdmM8Kc9x/4YQ8cYBViorkfBZDRlbf6KHWRJU5dztoHoDIX8YMc8J1jHz5M 2QeWIa4WcoAEZiowsUblOkWQUXFfdX0FbgaITz/+PqnPCPkGcdx12R9W67lg97lQIewl cvJK7OO2WyuBcTT39iWbTA1Q5qwE6zeBMj8VwjrD0XD36/9iIs27W7lTy12zYES7N5pX Jeww==
MIME-Version: 1.0
Received: by 10.112.87.104 with SMTP id w8mr26229283lbz.49.1357620019682; Mon, 07 Jan 2013 20:40:19 -0800 (PST)
Received: by 10.112.61.67 with HTTP; Mon, 7 Jan 2013 20:40:19 -0800 (PST)
In-Reply-To: <1357608790.27936.223.camel@pbryan-wsl.internal.salesforce.com>
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>  <1357608790.27936.223.camel@pbryan-wsl.internal.salesforce.com>
Date: Mon, 7 Jan 2013 20:40:19 -0800
Message-ID: 
From: "Murray S. Kucherawy" 
To: "Paul C. Bryan" 
Content-Type: multipart/alternative; boundary=bcaec554e0f6035f4004d2bf8b75
Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 04:40:22 -0000

--bcaec554e0f6035f4004d2bf8b75
Content-Type: text/plain; charset=ISO-8859-1

I apologize for being absent for this thread until now.  Vacation and
medical matters interfered with me keeping current.

First, with my participant hat on:

I've been occasionally comparing this work to conventional UNIX "patch" to
try to maintain a point of reference as these works developed.  As such,
I'm swayed by the argument (which, as I recall, was part of working group
deliberations prior to WGLC) that we have the "test" operations, so people
generating patch documents should use them to ensure proper context before
applying any of the operations that alter the target.  UNIX "patch"
accomplishes this by default by surrounding the lines to be changed in the
target with context lines that aren't changed, and so must exist precisely
as-is before the change can be made or the change is rejected.  Consider a
target file comprising 26 lines, each containing the next character of the
upper-case English alphabet and a newline, but the M and the N lines are
swapped.  A typical patch to fix this would look like so:

--- x   Mon Jan  7 20:27:36 2013
+++ y   Mon Jan  7 20:27:40 2013
@@ -10,8 +10,8 @@
 J
 K
 L
-N
 M
+N
 O
 P
 Q

The default for UNIX "diff" is to produce three lines of context above and
below the change to be made to ensure the change is being made in the right
place.  One could also request no lines of context, yielding:

--- x   Mon Jan  7 20:27:36 2013
+++ y   Mon Jan  7 20:27:40 2013
@@ -13 +12,0 @@
-N
@@ -14,0 +14 @@
+N

But this doesn't bother to check any context, except of course to ensure
that the target file is at least 14 lines long.  Although the top one is
clearly safer, both are actually legal patches.

In my view, these two JSON documents present a language for referencing and
object and changing it, and also for querying for context, just like the
conventional UNIX diff/patch format does.  But in neither the UNIX case nor
the proposed JSON case is the context part mandatory to use (though one
could certainly argue it's foolish to skip doing so).  That seems fine to
me.

Then, with my co-chair hat on:

Although I hear and understand Robert's position that this is an important
thing that needs to be addressed, it is not my view after reviewing this
thread that there's rough consensus to reopen the question.  Please note
that this is not an "it's too late in the process to change this" position,
but rather one that notes that the burden of supporting a change to
something that already has rough consensus is on the person proposing the
change, and I don't believe Robert has succeeded here.

That said, I would ask the document editors to consider adding a paragraph
or an appendix indicating this issue was considered during development of
the work and the current format was deliberately selected, preferably with
some supporting text.  This will ensure future readers will not interpret
the chosen design as a bug, but rather an intentional design choice.

-MSK, APPSAWG co-chair

On Mon, Jan 7, 2013 at 5:33 PM, Paul C. Bryan  wrote:

> **
> On Sun, 2013-01-06 at 16:01 -0800, Robert Sayre wrote:
>
>  This last assertion really isn't qualified very well.
>
>
> It would have been better for me to state this is my opinion, based on
> discussions that were animated from similar objections raised in the past.
>
> Paul
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

--bcaec554e0f6035f4004d2bf8b75
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I apologize for be=
ing absent for this thread until now.=A0 Vacation and medical matters inter=
fered with me keeping current.

First, with my participant hat =
on:


I've been occasionally comparing this work to conventional UNIX &qu=
ot;patch" to try to maintain a point of reference as these works devel=
oped.=A0 As such, I'm swayed by the argument (which, as I recall, was p=
art of working group deliberations prior to WGLC) that we have the "te=
st" operations, so people generating patch documents should use them t=
o ensure proper context before applying any of the operations that alter th=
e target.=A0 UNIX "patch" accomplishes this by default by surroun=
ding the lines to be changed in the target with context lines that aren'=
;t changed, and so must exist precisely as-is before the change can be made=
 or the change is rejected.=A0 Consider a target file comprising 26 lines, =
each containing the next character of the upper-case English alphabet and a=
 newline, but the M and the N lines are swapped.=A0 A typical patch to fix =
this would look like so:



--- x=A0=A0 Mon Jan=A0 7 20:27:36 2013
+++ y=A0=A0 Mon Jan=A0 =
7 20:27:40 2013
@@ -10,8 +10,8 @@
=A0J
=A0K
=A0L
-N
=A0M<=
br>+N
=A0O
=A0P
=A0Q

The default for UNIX "diff&=
quot; is to produce three lines of context above and below the change to be=
 made to ensure the change is being made in the right place.=A0 One could a=
lso request no lines of context, yielding:


--- x=A0=A0 Mon Jan=A0 7 20:27:36 2013
+++ y=A0=A0 Mon Jan=A0 7 20:2=
7:40 2013
@@ -13 +12,0 @@
-N
@@ -14,0 +14 @@
+N

Bu=
t this doesn't bother to check any context, except of course to ensure =
that the target file is at least 14 lines long.=A0 Although the top one is =
clearly safer, both are actually legal patches.


In my view, these two JSON documents present a language for refer=
encing and object and changing it, and also for querying for context, just =
like the conventional UNIX diff/patch format does.=A0 But in neither the UN=
IX case nor the proposed JSON case is the context part mandatory to use (th=
ough one could certainly argue it's foolish to skip doing so).=A0 That =
seems fine to me.


Then, with my co-chair hat on:

Although I hear and u=
nderstand Robert's position that this is an important thing that needs =
to be addressed, it is not my view after reviewing this thread that there&#=
39;s rough consensus to reopen the question.=A0 Please note that this is no=
t an "it's too late in the process to change this" position, =
but rather one that notes that the burden of supporting a change to somethi=
ng that already has rough consensus is on the person proposing the change, =
and I don't believe Robert has succeeded here.


That said, I would ask the document editors to consider adding a =
paragraph or an appendix indicating this issue was considered during develo=
pment of the work and the current format was deliberately selected, prefera=
bly with some supporting text.=A0 This will ensure future readers will not =
interpret the chosen design as a bug, but rather an intentional design choi=
ce.


-MSK, APPSAWG co-chair

On Mon, Jan 7, 2013 at=
 5:33 PM, Paul C. Bryan <pbryan@anode.ca> wrote:





 =20
 =20



On Sun, 2013-01-06 at 16:01 -0800, Robert Sayre wrote:






This last assertion really isn't qualified very well.






It would have been better for me to state this is my opinion, based on disc=
ussions that were animated from similar objections raised in the past. 
=



Paul




_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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



=



--bcaec554e0f6035f4004d2bf8b75--

From jasnell@gmail.com  Mon Jan  7 20:47:39 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6435511E8097; Mon,  7 Jan 2013 20:47:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.098
X-Spam-Level: 
X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 2iR0x5evJ-wp; Mon,  7 Jan 2013 20:47:38 -0800 (PST)
Received: from mail-ia0-f175.google.com (mail-ia0-f175.google.com [209.85.210.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7E921F84E8; Mon,  7 Jan 2013 20:47:38 -0800 (PST)
Received: by mail-ia0-f175.google.com with SMTP id z3so17286336iad.34 for ; Mon, 07 Jan 2013 20:47:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=0xVLh/hK31Z61PfEmjR1JybJiQ0ghfzc1B1IwJLAG40=; b=x8DwHnM4Zv9eP2DOw1dUXl0O314Dr5rHH+kkppusBlhqT46QSQR9ll8cppy9dxy1tT sNy3nDvw7uIDHJeA9pxkiwBdPS0xwnf9E4cEvHX40O0mMZFssjJh1KwFAddpbgpbNIC9 8HJCXkDj3eJgl2foVxiKvJ05ly5lJdTnUvUHxxcvRKap7ePH7fYSEVKBUjt6SyAL1XJa zWJ3CRJyGM2cZ3BMeSIO2Fl6dm9ZQG3XviQvxuUYKFoyip209dV+C0slKM65YKvNDYRT cT5mafocYie96D3bE4Dxt087P9/DWZ3w4fvqw2ngGUYHONOp2x1Vv5hHy0T52z8RFff4 kDjw==
X-Received: by 10.50.219.233 with SMTP id pr9mr7607426igc.19.1357620457722; Mon, 07 Jan 2013 20:47:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.7.19 with HTTP; Mon, 7 Jan 2013 20:47:17 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>  <1357608790.27936.223.camel@pbryan-wsl.internal.salesforce.com> 
From: James M Snell 
Date: Mon, 7 Jan 2013 20:47:17 -0800
Message-ID: 
To: "Murray S. Kucherawy" 
Content-Type: multipart/alternative; boundary=14dae934120f1f514304d2bfa505
Cc: IETF Apps Discuss , Mark Nottingham , IETF Discussion 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 04:47:39 -0000

--14dae934120f1f514304d2bfa505
Content-Type: text/plain; charset=UTF-8

If I may, I would follow this up with a suggestion that a separate I-D that
provides a more complete treatment of fully-concurrent patch operations
would be helpful. JSON-Patch is largely designed around atomic and
sequential modification operations and is not, necessarily a great match
for the kind of OT-style mechanisms Robert was referencing. I don't
personally have any use cases that would require the level of concurrency
Robert is suggesting but it would be an interesting pursuit nonetheless.


On Mon, Jan 7, 2013 at 8:40 PM, Murray S. Kucherawy wrote:

> I apologize for being absent for this thread until now.  Vacation and
> medical matters interfered with me keeping current.
>
> First, with my participant hat on:
>
> I've been occasionally comparing this work to conventional UNIX "patch" to
> try to maintain a point of reference as these works developed.  As such,
> I'm swayed by the argument (which, as I recall, was part of working group
> deliberations prior to WGLC) that we have the "test" operations, so people
> generating patch documents should use them to ensure proper context before
> applying any of the operations that alter the target.  UNIX "patch"
> accomplishes this by default by surrounding the lines to be changed in the
> target with context lines that aren't changed, and so must exist precisely
> as-is before the change can be made or the change is rejected.  Consider a
> target file comprising 26 lines, each containing the next character of the
> upper-case English alphabet and a newline, but the M and the N lines are
> swapped.  A typical patch to fix this would look like so:
>
> --- x   Mon Jan  7 20:27:36 2013
> +++ y   Mon Jan  7 20:27:40 2013
> @@ -10,8 +10,8 @@
>  J
>  K
>  L
> -N
>  M
> +N
>  O
>  P
>  Q
>
> The default for UNIX "diff" is to produce three lines of context above and
> below the change to be made to ensure the change is being made in the right
> place.  One could also request no lines of context, yielding:
>
> --- x   Mon Jan  7 20:27:36 2013
> +++ y   Mon Jan  7 20:27:40 2013
> @@ -13 +12,0 @@
> -N
> @@ -14,0 +14 @@
> +N
>
> But this doesn't bother to check any context, except of course to ensure
> that the target file is at least 14 lines long.  Although the top one is
> clearly safer, both are actually legal patches.
>
> In my view, these two JSON documents present a language for referencing
> and object and changing it, and also for querying for context, just like
> the conventional UNIX diff/patch format does.  But in neither the UNIX case
> nor the proposed JSON case is the context part mandatory to use (though one
> could certainly argue it's foolish to skip doing so).  That seems fine to
> me.
>
> Then, with my co-chair hat on:
>
> Although I hear and understand Robert's position that this is an important
> thing that needs to be addressed, it is not my view after reviewing this
> thread that there's rough consensus to reopen the question.  Please note
> that this is not an "it's too late in the process to change this" position,
> but rather one that notes that the burden of supporting a change to
> something that already has rough consensus is on the person proposing the
> change, and I don't believe Robert has succeeded here.
>
> That said, I would ask the document editors to consider adding a paragraph
> or an appendix indicating this issue was considered during development of
> the work and the current format was deliberately selected, preferably with
> some supporting text.  This will ensure future readers will not interpret
> the chosen design as a bug, but rather an intentional design choice.
>
> -MSK, APPSAWG co-chair
>
> On Mon, Jan 7, 2013 at 5:33 PM, Paul C. Bryan  wrote:
>
>> **
>> On Sun, 2013-01-06 at 16:01 -0800, Robert Sayre wrote:
>>
>>  This last assertion really isn't qualified very well.
>>
>>
>> It would have been better for me to state this is my opinion, based on
>> discussions that were animated from similar objections raised in the past.
>>
>> 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
>
>

--14dae934120f1f514304d2bfa505
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


If I may, I would fo=
llow this up with a suggestion that a separate I-D that provides a more com=
plete treatment of fully-concurrent patch operations would be helpful. JSON=
-Patch is largely designed around atomic and sequential modification operat=
ions and is not, necessarily a great match for the kind of OT-style mechani=
sms Robert was referencing. I don't personally have any use cases that =
would require the level of concurrency Robert is suggesting but it would be=
 an interesting pursuit nonetheless.





On Mon, Jan 7=
, 2013 at 8:40 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:



I apologize for being absent for this thread until now.=C2=A0 =
Vacation and medical matters interfered with me keeping current.



First, with my participant hat on:


I've been occasionally comparing this work to conventional UNIX &qu=
ot;patch" to try to maintain a point of reference as these works devel=
oped.=C2=A0 As such, I'm swayed by the argument (which, as I recall, wa=
s part of working group deliberations prior to WGLC) that we have the "=
;test" operations, so people generating patch documents should use the=
m to ensure proper context before applying any of the operations that alter=
 the target.=C2=A0 UNIX "patch" accomplishes this by default by s=
urrounding the lines to be changed in the target with context lines that ar=
en't changed, and so must exist precisely as-is before the change can b=
e made or the change is rejected.=C2=A0 Consider a target file comprising 2=
6 lines, each containing the next character of the upper-case English alpha=
bet and a newline, but the M and the N lines are swapped.=C2=A0 A typical p=
atch to fix this would look like so:





--- x=C2=A0=C2=A0 Mon Jan=C2=A0 7 20:27:36 2013
+++ y=C2=A0=C2=
=A0 Mon Jan=C2=A0 7 20:27:40 2013
@@ -10,8 +10,8 @@
=C2=A0J
=C2=A0=
K
=C2=A0L
-N
=C2=A0M
+N
=C2=A0O
=C2=A0P
=C2=A0Q
The default for UNIX "diff" is to produce three lines of c=
ontext above and below the change to be made to ensure the change is being =
made in the right place.=C2=A0 One could also request no lines of context, =
yielding:




--- x=C2=A0=C2=A0 Mon Jan=C2=A0 7 20:27:36 2013
+++ y=C2=A0=C2=A0 Mo=
n Jan=C2=A0 7 20:27:40 2013
@@ -13 +12,0 @@
-N
@@ -14,0 +14 @@
=
+N

But this doesn't bother to check any context, except of=
 course to ensure that the target file is at least 14 lines long.=C2=A0 Alt=
hough the top one is clearly safer, both are actually legal patches.




In my view, these two JSON documents present a language for refer=
encing and object and changing it, and also for querying for context, just =
like the conventional UNIX diff/patch format does.=C2=A0 But in neither the=
 UNIX case nor the proposed JSON case is the context part mandatory to use =
(though one could certainly argue it's foolish to skip doing so).=C2=A0=
 That seems fine to me.




Then, with my co-chair hat on:

Although I hear and u=
nderstand Robert's position that this is an important thing that needs =
to be addressed, it is not my view after reviewing this thread that there&#=
39;s rough consensus to reopen the question.=C2=A0 Please note that this is=
 not an "it's too late in the process to change this" positio=
n, but rather one that notes that the burden of supporting a change to some=
thing that already has rough consensus is on the person proposing the chang=
e, and I don't believe Robert has succeeded here.




That said, I would ask the document editors to consider adding a =
paragraph or an appendix indicating this issue was considered during develo=
pment of the work and the current format was deliberately selected, prefera=
bly with some supporting text.=C2=A0 This will ensure future readers will n=
ot interpret the chosen design as a bug, but rather an intentional design c=
hoice.




-MSK, APPSAWG co-chair

On Mon, Jan 7, 2013 at 5:33 PM, Paul C. Bryan <pbryan@anode.ca> wrote:







 =20
 =20



On Sun, 2013-01-06 at 16:01 -0800, Robert Sayre wrote:






This last assertion really isn't qualified very well.






It would have been better for me to state this is my opinion, based on disc=
ussions that were animated from similar objections raised in the past. 
=



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





--14dae934120f1f514304d2bfa505--

From mmorley@mpcm.com  Mon Jan  7 22:26:32 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1823721F87D9 for ; Mon,  7 Jan 2013 22:26:32 -0800 (PST)
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 l8rZuDGNYweg for ; Mon,  7 Jan 2013 22:26:31 -0800 (PST)
Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by ietfa.amsl.com (Postfix) with ESMTP id A219821F8782 for ; Mon,  7 Jan 2013 22:26:30 -0800 (PST)
Received: by mail-la0-f52.google.com with SMTP id fq12so68272lab.39 for ; Mon, 07 Jan 2013 22:26:29 -0800 (PST)
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=tVGR3V0bZ63/hoDM4AfDUCweXtPnFIX93lv4LwUUXP4=; b=JfW98rjNCHaf7SUAvSaUCLWdxEriq38AbVVb2O2tkqSP9L2d9+oQUPRyw6EfYs1/PI YtjTb3DvXnPgbBmobF7dyau+WpY+gSt/5mowd2Cleb1RnB4kN+vrszN8IUS1gzICI4lP 3MlPXOmR28oi/jQT8cPm1qOP6q3AUg/wrKT6ltxG30QVgwV1i7bPiH7MTLXDqODUPah7 UjAlWa0a1dDAqANWuwUmKTJ/hEFjlq1dE3urATBgnVYG05CgVZlmS0eq4a/fLazitGfK WSiACOQJBWwATyok7RMu7URoHjnKRpG04/NDRuWIpGCZrSagsgeml5V2hpWL2Zbsj2QH yFBw==
MIME-Version: 1.0
Received: by 10.152.110.18 with SMTP id hw18mr60995840lab.22.1357626389332; Mon, 07 Jan 2013 22:26:29 -0800 (PST)
Sender: mmorley@mpcm.com
Received: by 10.114.38.137 with HTTP; Mon, 7 Jan 2013 22:26:29 -0800 (PST)
In-Reply-To: <50EB4E8B.30700@versi.edu.au>
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>    <50EB4E8B.30700@versi.edu.au>
Date: Tue, 8 Jan 2013 01:26:29 -0500
X-Google-Sender-Auth: Hp6htB9KvhJjezXNY49bilk8pH4
Message-ID: 
From: Matthew Morley 
To: Conal Tuohy 
Content-Type: multipart/alternative; boundary=bcaec54d4de8ac81d404d2c10686
X-Gm-Message-State: ALoCoQk7dFMj3in3P0opeN4exerJc6kFS6aFzx/V8AZ29AyseKbu+wtAFxVLhtvv0gSqN3lGxQlE
Cc: IESG , Mark Nottingham , IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 06:26:32 -0000

--bcaec54d4de8ac81d404d2c10686
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jan 7, 2013 at 5:39 PM, Conal Tuohy wrote:

>  On 07/01/13 13:23, Matthew Morley wrote:
>
>
> For me the deficiency is not in the pointer, but patch format being
> generated.
>
> One approach is to push that *one* test, structure conformity, into the
> pointer syntax. Another is via the type operation.
>
> If a vague patch is generated, vague results are to be expected.
>
> It seems to me, on the contrary, that the deficiency is in the pointer
> syntax, and I think it would be a mistake to try to work around that
> deficiency in JSON Patch. Because aren't there other things which one might
> do with JSON Pointer than use it with JSON Patch? There's been mention of
> having it registered as a URI fragment identifier syntax for JSON for
> example. JSON Pointers could then end up all over the place, outside of
> patches. IMHO JSON Pointer needs to be taken seriously as a technology in
> its own right.
>

Couldn't agree more about it being taken seriously in its own right. :)

JSON Pointer for me exists outside of JSON Patch, always has and will do
the way we think about structures. As it represents both a resolution path
and an identity string (both ends of the path concept). I see value from
the identity view, in describing a location that is aware of being inside
an array.

But JSON Pointer should not be changed just because of issues with JSON
Patch, especially when JSON Patch is attempting to address those issues
with other mechanisms within the specification. That is all I was trying to
express. The syntax change should be for other reasons, if it is going to
be made.

My personal experience (for what its worth): In the past I've tried a
number of syntaxes like JSON Pointer. Mostly a.b.c.0 and even a.b.c:0 at
times to address the same issues suggested here. Though my experiences
pushed me towards a single syntax using a.b.c.0, and thus my support for
/a/b/c/0 over /a/b/c:0.

The system at first used the . or : syntax, combined with dynamic tokens,
being pointers themselves, to resolve other pointers. So it was not
reasonable to know ahead of time if an end point was an array or an object.
 "a.b.c.{d.e.f}" could end up in an array or in an object, depending on the
value at d.e.f at the time of resolution. Especially with many layers of
tokens to resolve, and changing data structures.

I found in practice, it didn't really matter, so the choice of . or : was
phased out. At the end of the day the two syntaxes point to mutually
exclusive points within the data, so that `meta data` about the structure
was removed from the syntax we used. It didn't add value, even if it added
clarity at times. We also had functions at the end of paths, but that goes
beyond the JSON focus of the JSON Pointer goals, so those points are not
relevant here.

This discussion thread seems to be getting overly complicated, but JSON
Pointer changes should come from the JSON Pointer view point and that
specifications goals, not from short comings in JSON Patch.

-- 
Matthew P. C. Morley

--bcaec54d4de8ac81d404d2c10686
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 7, 2013 at 5:39 PM, Conal Tuohy <conal.tuohy@versi.ed=
u.au> wrote:


 =20
   =20
 =20
  

    
On 07/01/13 13:23, Matthew Morley
      wrote:

    

    

     =20
      

      For me the deficiency is not in the pointer, but patch format
      being generated.

      

      One approach is to push that *one* test, structure=A0conformity,
      into the pointer syntax.=A0Another is via the type operation.

      

      If a vague patch is generated, vague results are to be expected.

    

    It seems to me, on the contrary, that the deficiency is in the
    pointer syntax, and I think it would be a mistake to try to work
    around that deficiency in JSON Patch. Because aren't there other
    things which one might do with JSON Pointer than use it with JSON
    Patch? There's been mention of having it registered as a URI
    fragment identifier syntax for JSON for example. JSON Pointers could
    then end up all over the place, outside of patches. IMHO JSON
    Pointer needs to be taken seriously as a technology in its own
    right.=A0

Couldn't agree more about it b=
eing taken seriously in its own right. :)

JSON Pointer for me exists=
 outside of JSON Patch, always has and will do the way we think about struc=
tures. As it represents both a resolution path and an identity string (both=
 ends of the path concept). I see value from the identity view, in describi=
ng a location that is aware of being inside an array.



But JSON Pointer should not be changed just because of issues with=
 JSON Patch, especially when JSON Patch is attempting to address those issu=
es with other mechanisms within the specification. That is all I was trying=
 to express. The syntax change should be for other reasons, if it is going =
to be made.


My personal experience (for what its worth): In the past I&#=
39;ve tried a number of syntaxes like JSON Pointer. Mostly a.b.c.0 and even=
 a.b.c:0 at times to address the same issues suggested here. Though my expe=
riences pushed me towards a single syntax using a.b.c.0, and thus my suppor=
t for /a/b/c/0 over /a/b/c:0.


The system at first used the . or : syntax, combined with dynamic token=
s, being pointers themselves, to resolve other pointers. So it was not reas=
onable to know ahead of time if an end point was an array or an object. =A0=
"a.b.c.{d.e.f}" could end up in an array or in an object, dependi=
ng on the value at d.e.f at the time of resolution. Especially with many la=
yers of tokens to resolve, and changing data structures.


I found in practice, it didn't really matter, so the choice of . or=
 : was phased out. At the end of the day the two syntaxes point to mutually=
 exclusive points within the data, so that `meta data` about the structure =
was removed from the syntax we used. It didn't add value, even if it ad=
ded clarity at times. We also had functions at the end of paths, but that g=
oes beyond the JSON focus of the JSON Pointer goals, so those points are no=
t relevant here.



This discussion thread seems to be getting overly comp=
licated, but JSON Pointer changes should come from the JSON Pointer view po=
int and that specifications goals, not from short comings in JSON Patch.

-- 
Matthew P. C. Morley

--bcaec54d4de8ac81d404d2c10686--

From sayrer@gmail.com  Mon Jan  7 22:33:04 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478AE21F87AB; Mon,  7 Jan 2013 22:33:04 -0800 (PST)
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 ZWnmRhm-gH7c; Mon,  7 Jan 2013 22:33:03 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A64021F8495; Mon,  7 Jan 2013 22:33:03 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id dr12so37720wgb.35 for ; Mon, 07 Jan 2013 22:33:02 -0800 (PST)
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=+J3QendoWh4gfNc8MPvXB04WrjNfms4WaT2TVLaPF+M=; b=KZyS8vZDxDKcr7PdbwlmoOGUvxJEJ4GrCcXjKHVY7fqqJ0K0Gjz3onOrexxU7mf2Bw a2A3qCt2LaLJ43c1NfqyaAZ4aEv2gs8HXobQKCv1QxW45gm9RPg6GSYG4IORyJfP92Mh ZgfC82aNr4pV3ydCq8CrfFNJC6177937RBwOI+odqkC3Cy3xGtuwikuwJAmw2qhNF1Gk V/WhciVK1hm8wG8dCfUhZaRRZ6zxwjqzwN4nSx0ru4BdomGorDcWkzkZ8uGWvJckWQpA UQbitllhtkJ3aeQNag4UcfzD8azI1C9SWS8m9ip1RN1qzigzuSX/ByZ3MRgek7zzkBnF lKzQ==
MIME-Version: 1.0
Received: by 10.180.88.40 with SMTP id bd8mr12679682wib.33.1357626782367; Mon, 07 Jan 2013 22:33:02 -0800 (PST)
Received: by 10.194.1.101 with HTTP; Mon, 7 Jan 2013 22:33:02 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>  <1357608790.27936.223.camel@pbryan-wsl.internal.salesforce.com> 
Date: Mon, 7 Jan 2013 22:33:02 -0800
Message-ID: 
From: Robert Sayre 
To: "Murray S. Kucherawy" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF Apps Discuss , Mark Nottingham , IETF Discussion 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 06:33:04 -0000

On Mon, Jan 7, 2013 at 8:40 PM, Murray S. Kucherawy  wrote:
>
> we have the "test" operations, so people
> generating patch documents should use them to ensure proper context before
> applying any of the operations that alter the target.

I don't see how can the "test" operation be used to determine the
intended target structure of an operation with a JSON Pointer of "/1".
Maybe there should be an example in the draft.

- Rob

From sayrer@gmail.com  Mon Jan  7 23:57:57 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CAD21F87D5; Mon,  7 Jan 2013 23:57:56 -0800 (PST)
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 j41HsCgllxhM; Mon,  7 Jan 2013 23:57:56 -0800 (PST)
Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id 208A921F87D1; Mon,  7 Jan 2013 23:57:55 -0800 (PST)
Received: by mail-we0-f178.google.com with SMTP id x43so82389wey.37 for ; Mon, 07 Jan 2013 23:57:55 -0800 (PST)
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=f4Zm3pUIP9ZOlZA5ntLnSiy8H727h7I7Az+pKb5N7v8=; b=ohI1YR3QlHZ84yadzyq45o1K6uX2Zi3BFvUN90nT5yS6R2i7/R6VRhKs9bE/uIQuyW 81t/zXlVqvu+kM2QNSfCQo7iEJ9PQs43iTQ68WFT9fmRv/D+v8h6xfPhOiRiFaJuNxlr dCSQoSexSwFTX00MYCtoU/qav7zJ+zvl1Q+oH1x1qr2ul+NdaobJmcWP3oyIOYRg1QKr /UDpCgsKZ+/1DpDY4cX+YcKn6SPweDybE7mH+Bo9LHHFyXM/AVu4wA/51zxqzYaPHX5U G9Z1PwKURaEEMaTIhCL0aBxHoVk9bGylCK/wc83j6Vw4u4GnZcZ4C94gec9xZ3/5Uq20 k/Jg==
MIME-Version: 1.0
Received: by 10.194.23.37 with SMTP id j5mr99616912wjf.28.1357631875372; Mon, 07 Jan 2013 23:57:55 -0800 (PST)
Received: by 10.194.1.101 with HTTP; Mon, 7 Jan 2013 23:57:55 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>  <1357608790.27936.223.camel@pbryan-wsl.internal.salesforce.com> 
Date: Mon, 7 Jan 2013 23:57:55 -0800
Message-ID: 
From: Robert Sayre 
To: "Murray S. Kucherawy" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF Apps Discuss , Mark Nottingham , IETF Discussion 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 07:57:57 -0000

On Mon, Jan 7, 2013 at 8:40 PM, Murray S. Kucherawy  wrote:
>
> Then, with my co-chair hat on:
>
> it is not my view after reviewing this
> thread that there's rough consensus to reopen the question.

I agree with this assessment.

- Rob

From cabo@tzi.org  Tue Jan  8 00:19:16 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FC621F8700; Tue,  8 Jan 2013 00:19:16 -0800 (PST)
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 VkwOx1T5JOfZ; Tue,  8 Jan 2013 00:19:15 -0800 (PST)
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 99AE421F8514; Tue,  8 Jan 2013 00:19:15 -0800 (PST)
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 r088J60f022874; Tue, 8 Jan 2013 09:19:06 +0100 (CET)
Received: from [192.168.217.105] (p54892470.dip.t-dialin.net [84.137.36.112]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6D28DBDE; Tue,  8 Jan 2013 09:19:06 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann 
In-Reply-To: 
Date: Tue, 8 Jan 2013 09:19:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <018651D6-83D4-42D6-86EB-0FAA5DE10DDA@tzi.org>
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com> 
To: Robert Sayre 
X-Mailer: Apple Mail (2.1499)
Cc: IETF Apps Discuss , IETF Discussion 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 08:19:16 -0000

For those who wonder what all the fuzz in this thread is about, let me =
try to explain this with some different terminology, exposing what kind =
of intuition these widely diverging value judgements might derive from.

In programming, there are two camps: static typers and dynamic typers.  =
Static typers want to annotate their programs with information about the =
objects being manipulated so the compiler can help them catch careless =
mistakes even before the program runs.  Dynamic typers don't care about =
that as much, because they know they have to write tests anyway (not all =
programming errors are exposable as type errors) and these will uncover =
the same careless mistakes.  [The runtime system will actually check =
types once the specific context of execution is available, that's why =
it's called "dynamic typing".]

The programming debate is beside the point here for a number of =
reasons*), but it does shape the thinking of programmers, and it seems =
in particular it shaped the thinking of some of the commenters here.

/a/1/b/2 is something that a dynamic typer would come up with.  The =
specific semantics are well-defined, but only in the specific execution =
context (what JSON document this is being applied to).
/a:1/b:2 (to use James' strawman syntax that distinguishes JSON object =
keys from array indices) exposes more typing info, so it is more =
statically typed, and it will catch mismatches between the types that =
the JSON pointer assumed to be present and those that actually are.

For a static-typing fundamentalist, it is viscerally unacceptable to =
forego the opportunity of catching this kind of "type error".

For a non-fundamentalist, this is more of an issue of probabilities, and =
the interlocking of mechanisms. =20
Which percentage of usage errors will be caught by this?
Many, many mismatches between JSON pointers and JSON instances to will =
just not happen to trigger this particular type error.
So it can be argued that the ability to catch it doesn't really help =
much: If you care about mismatch errors, you already need to have =
something else in place to catch them -- relying only on the likelihood =
of a mismatch to trigger an array/object mismatch would be imprudent. So =
in reality, the ability to catch the type error buys you nothing.
(Or, actually, very little, as improved diagnostics is always worth =
something in a debugging situation.)

TL;DR: there is no "ambiguity" at all.  Please stop referring to an =
"ambiguity".  There is none.
Just a missed opportunity to catch an error, caused by not sending along =
(redundant) type information.

(You will gather that my 2 cents for this change are "not worth it", but =
I was more interested in explaining the mere existence of this =
discussion, first.  Applying the wrong intuitions to an engineering =
decision is one of the major causes of suboptimal design...)

Gr=FC=DFe, Carsten

*) Well, for a start, we are not here to catch errors in programming.  =
Programming languages are difficult because they are the human interface =
to the computer's programmability.  JSON pointers are a pure =
machine-to-machine mechanism, so most of the issues in programming just =
don't arise.  Porting your intuitions from programming to this is not =
going to work very well.


From jsr@10gen.com  Tue Jan  8 00:26:39 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF9921F88AE for ; Tue,  8 Jan 2013 00:26:39 -0800 (PST)
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 aeEy1VMCRLgU for ; Tue,  8 Jan 2013 00:26:35 -0800 (PST)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 81EE021F88B1 for ; Tue,  8 Jan 2013 00:26:35 -0800 (PST)
Received: by mail-vb0-f44.google.com with SMTP id fc26so119762vbb.3 for ; Tue, 08 Jan 2013 00:26:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=eoGvVPUa/PXDhUq6iowTaeAsPk3HXROUAbbQHIuwgiI=; b=fa72UgSvmPwu8tLnz3g+dZ7b5xToFkM4gCLOmX7v45c5L7MW4bGuO4bOpPWDclX4Td plqUx3jLOykr7PInYEutv1XpFbUIIyVn3T8PZWYzkcPQNDwFJb6Ju0S5ZdQ3uSGCYlCc ZCydYv7SaquwzlrfjEGzFiUfAdlgNlUlE6MOlsU+VaT/ldRo0FLcjCM0QbVfSlTzofOl j00SR6QnzEhHQvZQ3cXHo1yQ+TodmsePSbn3Le8HZve+4b1ei/BQa4/gah2EwIkttJUR MX4U3zMIm9LJYLvgXSlNRMHc4YPc7OVx/BIhZnEhgKMqXx0Z7xnOrg56L1cTgLcwyO15 FQlQ==
MIME-Version: 1.0
Received: by 10.220.247.204 with SMTP id md12mr86099296vcb.27.1357633594934; Tue, 08 Jan 2013 00:26:34 -0800 (PST)
Received: by 10.59.5.6 with HTTP; Tue, 8 Jan 2013 00:26:34 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>    <50EB4E8B.30700@versi.edu.au> 
Date: Tue, 8 Jan 2013 00:26:34 -0800
Message-ID: 
From: Jared Rosoff 
To: Matthew Morley 
Content-Type: multipart/alternative; boundary=bcaec54eede829467104d2c2b4ba
X-Gm-Message-State: ALoCoQkYu4hEWFAU4dkyji9pWICYeH5BGeIl1KkeUELQZWlf+HaLXmiSj1Xb2JCLPZbpGoh+ETUD
Cc: Mark Nottingham , IESG , IETF Apps Discuss , IETF Discussion 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 08:27:50 -0000

--bcaec54eede829467104d2c2b4ba
Content-Type: text/plain; charset=ISO-8859-1

hi team, i'm new to the discussion here, but wanted to jump in. i work on
mongodb, a json database, and i wanted to share how we deal with these
issues.

mongodb uses almost the same notation for pointers ("a.b.c" instead of
"/a/b/c"). We also index arrays in the same way as json pointer ( "a.0"
refers to the 0th element of the array called "a"). and this works fine in
practice. (ref: http://docs.mongodb.org/manual/core/document/#dot-notation)

our update syntax is different tho. the verbs in mongodb updates for json
documents are more specific:

set / unset / rename (operations on fields)
inc (increment integer values)
push / pop / pull (operations on arrays)
addToSet / removeFromSet (operations on arrays)

(ref http://docs.mongodb.org/manual/reference/operators/#update)

since update operations are more specific and type dependent, it's easy to
throw an error if an unexpected type is encountered (e.g. try to push onto
a field that has a non-array value) and to act smartly on empty fields ( if
path to push is empty, we assume it should be an array, create it, and then
push the value onto it).

i concur the the pointer syntax is fine and ambiguity comes from the
definition of operators in json patch.

-j


On Mon, Jan 7, 2013 at 10:26 PM, Matthew Morley  wrote:

> On Mon, Jan 7, 2013 at 5:39 PM, Conal Tuohy wrote:
>
>>  On 07/01/13 13:23, Matthew Morley wrote:
>>
>>
>> For me the deficiency is not in the pointer, but patch format being
>> generated.
>>
>> One approach is to push that *one* test, structure conformity, into the
>> pointer syntax. Another is via the type operation.
>>
>> If a vague patch is generated, vague results are to be expected.
>>
>> It seems to me, on the contrary, that the deficiency is in the pointer
>> syntax, and I think it would be a mistake to try to work around that
>> deficiency in JSON Patch. Because aren't there other things which one might
>> do with JSON Pointer than use it with JSON Patch? There's been mention of
>> having it registered as a URI fragment identifier syntax for JSON for
>> example. JSON Pointers could then end up all over the place, outside of
>> patches. IMHO JSON Pointer needs to be taken seriously as a technology in
>> its own right.
>>
>
> Couldn't agree more about it being taken seriously in its own right. :)
>
> JSON Pointer for me exists outside of JSON Patch, always has and will do
> the way we think about structures. As it represents both a resolution path
> and an identity string (both ends of the path concept). I see value from
> the identity view, in describing a location that is aware of being inside
> an array.
>
> But JSON Pointer should not be changed just because of issues with JSON
> Patch, especially when JSON Patch is attempting to address those issues
> with other mechanisms within the specification. That is all I was trying to
> express. The syntax change should be for other reasons, if it is going to
> be made.
>
> My personal experience (for what its worth): In the past I've tried a
> number of syntaxes like JSON Pointer. Mostly a.b.c.0 and even a.b.c:0 at
> times to address the same issues suggested here. Though my experiences
> pushed me towards a single syntax using a.b.c.0, and thus my support for
> /a/b/c/0 over /a/b/c:0.
>
> The system at first used the . or : syntax, combined with dynamic tokens,
> being pointers themselves, to resolve other pointers. So it was not
> reasonable to know ahead of time if an end point was an array or an object.
>  "a.b.c.{d.e.f}" could end up in an array or in an object, depending on the
> value at d.e.f at the time of resolution. Especially with many layers of
> tokens to resolve, and changing data structures.
>
> I found in practice, it didn't really matter, so the choice of . or : was
> phased out. At the end of the day the two syntaxes point to mutually
> exclusive points within the data, so that `meta data` about the structure
> was removed from the syntax we used. It didn't add value, even if it added
> clarity at times. We also had functions at the end of paths, but that goes
> beyond the JSON focus of the JSON Pointer goals, so those points are not
> relevant here.
>
> This discussion thread seems to be getting overly complicated, but JSON
> Pointer changes should come from the JSON Pointer view point and that
> specifications goals, not from short comings in JSON Patch.
>
> --
> Matthew P. C. Morley
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

--bcaec54eede829467104d2c2b4ba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


hi team, i'm new to the discussion here, but wanted to jump in. i =
work on mongodb, a json database, and i wanted to share how we deal with th=
ese issues.=A0

mongodb uses almost the same notation fo=
r pointers ("a.b.c" instead of "/a/b/c"). We also index=
 arrays in the same way as json pointer ( "a.0" refers to the 0th=
 element of the array called "a"). and this works fine in practic=
e. (ref:=A0http://docs.mongodb.org/manual/core/document/#dot-notation)=A0

our update syntax is different tho. the verbs in mongodb upd=
ates for json documents are more specific:=A0

set =
/ unset / rename (operations on fields)=A0
inc (increment integer=
 values)=A0


push / pop / pull (operations on arrays)=A0
addToSet / remov=
eFromSet (operations on arrays)=A0




since update operations are more specific and type depe=
ndent, it's easy to throw an error if an unexpected type is encountered=
 (e.g. try to push onto a field that has a non-array value) and to act smar=
tly on empty fields ( if path to push is empty, we assume it should be an a=
rray, create it, and then push the value onto it).=A0



i concur the the pointer syntax is fine and ambiguity c=
omes from the definition of operators in json patch.=A0

-j


On Mon, Ja=
n 7, 2013 at 10:26 PM, Matthew Morley <matt@mpcm.com> wrote:


On Mon, Jan 7, 2013 at 5:3=
9 PM, Conal Tuohy <conal.tuohy@versi.edu.au> wrote:



 =20
   =20
 =20
  

    
On 07/01/13 13:23, Matthew Morley
      wrote:

    

    

     =20
      

      For me the deficiency is not in the pointer, but patch format
      being generated.

      

      One approach is to push that *one* test, structure=A0conformity,
      into the pointer syntax.=A0Another is via the type operation.

      

      If a vague patch is generated, vague results are to be expected.

    

    It seems to me, on the contrary, that the deficiency is in the
    pointer syntax, and I think it would be a mistake to try to work
    around that deficiency in JSON Patch. Because aren't there other
    things which one might do with JSON Pointer than use it with JSON
    Patch? There's been mention of having it registered as a URI
    fragment identifier syntax for JSON for example. JSON Pointers could
    then end up all over the place, outside of patches. IMHO JSON
    Pointer needs to be taken seriously as a technology in its own
    right.=A0

Couldn't agree more abou=
t it being taken seriously in its own right. :)

JSON Pointer for me =
exists outside of JSON Patch, always has and will do the way we think about=
 structures. As it represents both a resolution path and an identity string=
 (both ends of the path concept). I see value from the identity view, in de=
scribing a location that is aware of being inside an array.




But JSON Pointer should not be changed just because of issues with=
 JSON Patch, especially when JSON Patch is attempting to address those issu=
es with other mechanisms within the specification. That is all I was trying=
 to express. The syntax change should be for other reasons, if it is going =
to be made.



My personal experience (for what its worth): In the past I&#=
39;ve tried a number of syntaxes like JSON Pointer. Mostly a.b.c.0 and even=
 a.b.c:0 at times to address the same issues suggested here. Though my expe=
riences pushed me towards a single syntax using a.b.c.0, and thus my suppor=
t for /a/b/c/0 over /a/b/c:0.



The system at first used the . or : syntax, combined with dynamic token=
s, being pointers themselves, to resolve other pointers. So it was not reas=
onable to know ahead of time if an end point was an array or an object. =A0=
"a.b.c.{d.e.f}" could end up in an array or in an object, dependi=
ng on the value at d.e.f at the time of resolution. Especially with many la=
yers of tokens to resolve, and changing data structures.



I found in practice, it didn't really matter, so the choice of . or=
 : was phased out. At the end of the day the two syntaxes point to mutually=
 exclusive points within the data, so that `meta data` about the structure =
was removed from the syntax we used. It didn't add value, even if it ad=
ded clarity at times. We also had functions at the end of paths, but that g=
oes beyond the JSON focus of the JSON Pointer goals, so those points are no=
t relevant here.




This discussion thread seems to be getting overly comp=
licated, but JSON Pointer changes should come from the JSON Pointer view po=
int and that specifications goals, not from short comings in JSON Patch.



-- <=
br>Matthew P. C. Morley

_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--bcaec54eede829467104d2c2b4ba--

From markus.lanthaler@gmx.net  Tue Jan  8 02:13:34 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818DE21F88F5 for ; Tue,  8 Jan 2013 02:13:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.758
X-Spam-Level: 
X-Spam-Status: No, score=0.758 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_ILLEGAL_IP=1.908]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRF8yV0B4qLI for ; Tue,  8 Jan 2013 02:13:33 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 61B7E21F88FB for ; Tue,  8 Jan 2013 02:13:33 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Ll3jn-1TK0mP1qBJ-00appx for ; Tue, 08 Jan 2013 11:13:32 +0100
Received: (qmail invoked by alias); 08 Jan 2013 10:13:31 -0000
Received: from net-2-34-222-137.cust.dsl.vodafone.it (EHLO Vostro3500) [2.34.222.137] by mail.gmx.net (mp017) with SMTP; 08 Jan 2013 11:13:31 +0100
X-Authenticated: #419883
X-Provags-ID: V01U2FsdGVkX1+n/Mwv5tWndEk8xXeor5RzUnSwhyncWJv48YoyjQ Ay6B8Ke9T5UdPQ
From: "Markus Lanthaler" 
To: "'Conal Tuohy'" , "'Matthew Morley'" 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com>	<50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>		<50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>							<1357515310.6827.23.camel@polyglot>			 <50EB4E8B.30700@versi.edu.au>
In-Reply-To: <50EB4E8B.30700@versi.edu.au>
Date: Tue, 8 Jan 2013 11:13:27 +0100
Message-ID: <012401cded88$cf33b520$6d9b1f60$@lanthaler@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac3tJ+OAEKBBA7A8SiKxpzd4U1tVmQAX70lw
Content-Language: de
X-Y-GMX-Trusted: 0
Cc: 'Mark Nottingham' , 'IESG' , 'IETF Apps Discuss' , 'IETF Discussion' 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 10:13:34 -0000

On Monday, January 07, 2013 11:39 PM, Conal Tuohy wrote:

> On 07/01/13 13:23, Matthew Morley wrote:
>
> > For me the deficiency is not in the pointer, but patch
> > format being generated.
> >
> > One approach is to push that *one* test, structure=A0conformity,
> >  into the pointer syntax.=A0Another is via the type operation.
> >
> > If a vague patch is generated, vague results are to be expected.
>
> It seems to me, on the contrary, that the deficiency is in the
> pointer syntax, and I think it would be a mistake to try to work
> around that deficiency in JSON Patch. Because aren't there other
> things which one might do with JSON Pointer than use it with JSON
> Patch? There's been mention of having it registered as a URI
> fragment identifier syntax for JSON for example. JSON Pointers
> could then end up all over the place, outside of patches. IMHO
> JSON Pointer needs to be taken seriously as a technology in its
> own right.

I would like to second that. Since JSON Pointer and JSON Patch will be =
two
independent standards I expect (hope) that JSON Pointer will be used for
many other things than patching and that's exactly the reason why I =
raised
this in the first place.

I still believe that the current ambiguity might hinder many valuable =
use
cases in the future. I do understand that we are already quite late in =
the
process but since the fix is rather trivial I don't see a compelling =
reason
to not resolve this now.


Cheers,
Markus



--
Markus Lanthaler
@markuslanthaler


From sayrer@gmail.com  Tue Jan  8 08:19:23 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4923D21F85C2; Tue,  8 Jan 2013 08:19:23 -0800 (PST)
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 7q7lQcCMzRFg; Tue,  8 Jan 2013 08:19:21 -0800 (PST)
Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id F245421F85C3; Tue,  8 Jan 2013 08:19:20 -0800 (PST)
Received: by mail-wg0-f54.google.com with SMTP id fg15so463845wgb.33 for ; Tue, 08 Jan 2013 08:19:14 -0800 (PST)
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=16UXqXdN60Yfl5fuz9rxKqd7LzfCwN8C/zf4TwZl46E=; b=QQt6kfCtZ3c9TpxDRn6YUaN9XeFzzj0qSGj+QFfo/8zAU1GroU1mnK6IvuUiPNCO/n jBgN5ptXfpRLY/RHYT+kIAVL3oOIhfpG4TEHc18ggl5+r3b2RyyYyacgiz+6pvRO5l0G SIq47ESuS0KeHJcnmIs43uFgbawhvTuyvDO5plxgUiyg5ChvyS0tXmimDcpYMWk0V2pU k/UTJ1htq1m7yNa1xp92t9Z7vrXMGmpMs+02kLU5KOHxYMsAO5yqj+qt03Il2X+3TnZ+ lbqC5WduY3Uw4pjs8gEpTqwGt2Hqig+slhD9y+xYKRu+TVOXqH9liZVuU/NYDEUT9ZM5 08hQ==
MIME-Version: 1.0
Received: by 10.180.103.136 with SMTP id fw8mr15592842wib.27.1357661947770; Tue, 08 Jan 2013 08:19:07 -0800 (PST)
Received: by 10.194.1.101 with HTTP; Tue, 8 Jan 2013 08:19:07 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>    <50EB4E8B.30700@versi.edu.au>  
Date: Tue, 8 Jan 2013 08:19:07 -0800
Message-ID: 
From: Robert Sayre 
To: Jared Rosoff 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss , IESG 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 16:19:23 -0000

Hi Jared,

Earlier in the thread, I actually directly asked whether software that
operates on arbitrary JSON was in scope for this WG (my example was
CouchDB), after having suggested either changing the path syntax or
renaming the array operations.[0]

The editors didn't respond, except with process points or simple
contradictions without rationale. My conclusion is that software such
as MongoDB must be out of scope here. To their credit, the editors did
point out that anyone is free to try again, and I plan to do just
that. There's no reason to hold up this WG, since they seem to be
burnt out.

- Rob

[0] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg08552.html


On Tue, Jan 8, 2013 at 12:26 AM, Jared Rosoff  wrote:
> hi team, i'm new to the discussion here, but wanted to jump in. i work on
> mongodb, a json database, and i wanted to share how we deal with these
> issues.
>
> mongodb uses almost the same notation for pointers ("a.b.c" instead of
> "/a/b/c"). We also index arrays in the same way as json pointer ( "a.0"
> refers to the 0th element of the array called "a"). and this works fine in
> practice. (ref: http://docs.mongodb.org/manual/core/document/#dot-notation)
>
> our update syntax is different tho. the verbs in mongodb updates for json
> documents are more specific:
>
> set / unset / rename (operations on fields)
> inc (increment integer values)
> push / pop / pull (operations on arrays)
> addToSet / removeFromSet (operations on arrays)
>
> (ref http://docs.mongodb.org/manual/reference/operators/#update)
>
> since update operations are more specific and type dependent, it's easy to
> throw an error if an unexpected type is encountered (e.g. try to push onto a
> field that has a non-array value) and to act smartly on empty fields ( if
> path to push is empty, we assume it should be an array, create it, and then
> push the value onto it).
>
> i concur the the pointer syntax is fine and ambiguity comes from the
> definition of operators in json patch.
>
> -j
>
>
> On Mon, Jan 7, 2013 at 10:26 PM, Matthew Morley  wrote:
>>
>> On Mon, Jan 7, 2013 at 5:39 PM, Conal Tuohy 
>> wrote:
>>>
>>> On 07/01/13 13:23, Matthew Morley wrote:
>>>
>>>
>>> For me the deficiency is not in the pointer, but patch format being
>>> generated.
>>>
>>> One approach is to push that *one* test, structure conformity, into the
>>> pointer syntax. Another is via the type operation.
>>>
>>> If a vague patch is generated, vague results are to be expected.
>>>
>>> It seems to me, on the contrary, that the deficiency is in the pointer
>>> syntax, and I think it would be a mistake to try to work around that
>>> deficiency in JSON Patch. Because aren't there other things which one might
>>> do with JSON Pointer than use it with JSON Patch? There's been mention of
>>> having it registered as a URI fragment identifier syntax for JSON for
>>> example. JSON Pointers could then end up all over the place, outside of
>>> patches. IMHO JSON Pointer needs to be taken seriously as a technology in
>>> its own right.
>>
>>
>> Couldn't agree more about it being taken seriously in its own right. :)
>>
>> JSON Pointer for me exists outside of JSON Patch, always has and will do
>> the way we think about structures. As it represents both a resolution path
>> and an identity string (both ends of the path concept). I see value from the
>> identity view, in describing a location that is aware of being inside an
>> array.
>>
>> But JSON Pointer should not be changed just because of issues with JSON
>> Patch, especially when JSON Patch is attempting to address those issues with
>> other mechanisms within the specification. That is all I was trying to
>> express. The syntax change should be for other reasons, if it is going to be
>> made.
>>
>> My personal experience (for what its worth): In the past I've tried a
>> number of syntaxes like JSON Pointer. Mostly a.b.c.0 and even a.b.c:0 at
>> times to address the same issues suggested here. Though my experiences
>> pushed me towards a single syntax using a.b.c.0, and thus my support for
>> /a/b/c/0 over /a/b/c:0.
>>
>> The system at first used the . or : syntax, combined with dynamic tokens,
>> being pointers themselves, to resolve other pointers. So it was not
>> reasonable to know ahead of time if an end point was an array or an object.
>> "a.b.c.{d.e.f}" could end up in an array or in an object, depending on the
>> value at d.e.f at the time of resolution. Especially with many layers of
>> tokens to resolve, and changing data structures.
>>
>> I found in practice, it didn't really matter, so the choice of . or : was
>> phased out. At the end of the day the two syntaxes point to mutually
>> exclusive points within the data, so that `meta data` about the structure
>> was removed from the syntax we used. It didn't add value, even if it added
>> clarity at times. We also had functions at the end of paths, but that goes
>> beyond the JSON focus of the JSON Pointer goals, so those points are not
>> relevant here.
>>
>> This discussion thread seems to be getting overly complicated, but JSON
>> Pointer changes should come from the JSON Pointer view point and that
>> specifications goals, not from short comings in JSON Patch.
>>
>> --
>> Matthew P. C. Morley
>> _______________________________________________
>> 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  Tue Jan  8 09:07:13 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DAA21F84E0; Tue,  8 Jan 2013 09:07:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.036
X-Spam-Level: 
X-Spam-Status: No, score=-4.036 tagged_above=-999 required=5 tests=[AWL=-0.438, 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 Vywmc-YQNH+b; Tue,  8 Jan 2013 09:07:12 -0800 (PST)
Received: from mail-ia0-f179.google.com (mail-ia0-f179.google.com [209.85.210.179]) by ietfa.amsl.com (Postfix) with ESMTP id DB80821F84C0; Tue,  8 Jan 2013 09:07:11 -0800 (PST)
Received: by mail-ia0-f179.google.com with SMTP id o25so561155iad.10 for ; Tue, 08 Jan 2013 09:07:11 -0800 (PST)
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=a8mUXHBc/lhQAOsrQLKZhHZSou57RXlD5TzUU91Kv9M=; b=BYM2as89e5+kSXXnASNb/uq4X3C+CRDwFYwZUxCqp2Eg5S5Ff25aR3RBXIQy/0aGfA OnIY13hbaCFeo/Qw5574i+76p9EsOy+qwrVODOYrpeAFTEx/BGNedMDLYMF33bUSDIAn MqInw15BhMoXKOQAjKImejhfa+DkJbPjUuYhI0eRAvFRJOZjRZiKYXmBPqcme1FKK75p xEnhAqHWbKBctl2/tfSf3JIyHE+nLlxwBPEjIZVgWPuiJnxjQBNgRPMg849AdtcrhASP BUfGjtC9GNaH1ffAB5NX091eaumfiHlc/hAalstWa40dzsn9kgP2L0qPjLb0fRSNyIhs TqsQ==
Received: by 10.50.150.174 with SMTP id uj14mr9636735igb.19.1357664831403; Tue, 08 Jan 2013 09:07:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.7.19 with HTTP; Tue, 8 Jan 2013 09:06:50 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>    <50EB4E8B.30700@versi.edu.au>  
From: James M Snell 
Date: Tue, 8 Jan 2013 09:06:50 -0800
Message-ID: 
To: Jared Rosoff 
Content-Type: multipart/alternative; boundary=f46d043d644bfff78a04d2c9f9f6
Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss , IESG 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 17:07:13 -0000

--f46d043d644bfff78a04d2c9f9f6
Content-Type: text/plain; charset=UTF-8

Fortunately the JSON-Patch syntax is designed such that it is possible to
extend the range of defined operations without breaking basic structure...
much as I have done with the json-predicates draft. You would need to
define a new media type to associate with the extensions but that's not
difficult.

Consider something along the lines of.. application/json-patch-ext...

[
  {"op": "unset", "path": "/a/b"},
  {"op": "inc", "path": "/a/c"},
  {"op": "push", "path": "/a/d", "value": 1}
]

- James



On Tue, Jan 8, 2013 at 12:26 AM, Jared Rosoff  wrote:

> hi team, i'm new to the discussion here, but wanted to jump in. i work on
> mongodb, a json database, and i wanted to share how we deal with these
> issues.
>
> mongodb uses almost the same notation for pointers ("a.b.c" instead of
> "/a/b/c"). We also index arrays in the same way as json pointer ( "a.0"
> refers to the 0th element of the array called "a"). and this works fine in
> practice. (ref: http://docs.mongodb.org/manual/core/document/#dot-notation
> )
>
> our update syntax is different tho. the verbs in mongodb updates for json
> documents are more specific:
>
> set / unset / rename (operations on fields)
> inc (increment integer values)
> push / pop / pull (operations on arrays)
> addToSet / removeFromSet (operations on arrays)
>
> (ref http://docs.mongodb.org/manual/reference/operators/#update)
>
> since update operations are more specific and type dependent, it's easy to
> throw an error if an unexpected type is encountered (e.g. try to push onto
> a field that has a non-array value) and to act smartly on empty fields ( if
> path to push is empty, we assume it should be an array, create it, and then
> push the value onto it).
>
> i concur the the pointer syntax is fine and ambiguity comes from the
> definition of operators in json patch.
>
> -j
>
>
> On Mon, Jan 7, 2013 at 10:26 PM, Matthew Morley  wrote:
>
>> On Mon, Jan 7, 2013 at 5:39 PM, Conal Tuohy wrote:
>>
>>>  On 07/01/13 13:23, Matthew Morley wrote:
>>>
>>>
>>> For me the deficiency is not in the pointer, but patch format being
>>> generated.
>>>
>>> One approach is to push that *one* test, structure conformity, into the
>>> pointer syntax. Another is via the type operation.
>>>
>>> If a vague patch is generated, vague results are to be expected.
>>>
>>> It seems to me, on the contrary, that the deficiency is in the pointer
>>> syntax, and I think it would be a mistake to try to work around that
>>> deficiency in JSON Patch. Because aren't there other things which one might
>>> do with JSON Pointer than use it with JSON Patch? There's been mention of
>>> having it registered as a URI fragment identifier syntax for JSON for
>>> example. JSON Pointers could then end up all over the place, outside of
>>> patches. IMHO JSON Pointer needs to be taken seriously as a technology in
>>> its own right.
>>>
>>
>> Couldn't agree more about it being taken seriously in its own right. :)
>>
>> JSON Pointer for me exists outside of JSON Patch, always has and will do
>> the way we think about structures. As it represents both a resolution path
>> and an identity string (both ends of the path concept). I see value from
>> the identity view, in describing a location that is aware of being inside
>> an array.
>>
>> But JSON Pointer should not be changed just because of issues with JSON
>> Patch, especially when JSON Patch is attempting to address those issues
>> with other mechanisms within the specification. That is all I was trying to
>> express. The syntax change should be for other reasons, if it is going to
>> be made.
>>
>> My personal experience (for what its worth): In the past I've tried a
>> number of syntaxes like JSON Pointer. Mostly a.b.c.0 and even a.b.c:0 at
>> times to address the same issues suggested here. Though my experiences
>> pushed me towards a single syntax using a.b.c.0, and thus my support for
>> /a/b/c/0 over /a/b/c:0.
>>
>> The system at first used the . or : syntax, combined with dynamic tokens,
>> being pointers themselves, to resolve other pointers. So it was not
>> reasonable to know ahead of time if an end point was an array or an object.
>>  "a.b.c.{d.e.f}" could end up in an array or in an object, depending on the
>> value at d.e.f at the time of resolution. Especially with many layers of
>> tokens to resolve, and changing data structures.
>>
>> I found in practice, it didn't really matter, so the choice of . or : was
>> phased out. At the end of the day the two syntaxes point to mutually
>> exclusive points within the data, so that `meta data` about the structure
>> was removed from the syntax we used. It didn't add value, even if it added
>> clarity at times. We also had functions at the end of paths, but that goes
>> beyond the JSON focus of the JSON Pointer goals, so those points are not
>> relevant here.
>>
>> This discussion thread seems to be getting overly complicated, but JSON
>> Pointer changes should come from the JSON Pointer view point and that
>> specifications goals, not from short comings in JSON Patch.
>>
>> --
>> Matthew P. C. Morley
>> _______________________________________________
>> 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
>
>

--f46d043d644bfff78a04d2c9f9f6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Fortunately the JSON=
-Patch syntax is designed such that it is possible to extend the range of d=
efined operations without breaking basic structure... much as I have done w=
ith the json-predicates draft. You would need to define a new media type to=
 associate with the extensions but that's not difficult.



Consider something along the lines of.. applic=
ation/json-patch-ext...




[
=C2=A0 {"op": "uns=
et", "path": "/a/b"},



=C2=
=A0 {"op": "inc", "path": "/a/c"},<=
/span>
=C2=A0 {"op": "push", "path": "/=
a/d", "value": 1}



]
<=
font face=3D"courier new, monospace">
- James






On Tue, Jan 8, 2013 at 12:26 AM, Jared Rosoff <<=
a href=3D"mailto:jsr@10gen.com" target=3D"_blank">jsr@10gen.com> wrote:



hi team, i'm new to the discussion =
here, but wanted to jump in. i work on mongodb, a json database, and i want=
ed to share how we deal with these issues.=C2=A0




mongodb uses almost the same notation for pointers ("a.=
b.c" instead of "/a/b/c"). We also index arrays in the same =
way as json pointer ( "a.0" refers to the 0th element of the arra=
y called "a"). and this works fine in practice. (ref:=C2=A0http://docs.mongodb.org/manual/core/document/#dot-notation)=C2=
=A0




our update syntax is different tho. the verbs in mongodb upd=
ates for json documents are more specific:=C2=A0

s=
et / unset / rename (operations on fields)=C2=A0
inc (increment i=
nteger values)=C2=A0




push / pop / pull (operations on arrays)=C2=A0
addToSet / re=
moveFromSet (operations on arrays)=C2=A0






since update operations are more specific and type depe=
ndent, it's easy to throw an error if an unexpected type is encountered=
 (e.g. try to push onto a field that has a non-array value) and to act smar=
tly on empty fields ( if path to push is empty, we assume it should be an a=
rray, create it, and then push the value onto it).=C2=A0





i concur the the pointer syntax is fine and ambiguity c=
omes from the definition of operators in json patch.=C2=A0

-j





On=
 Mon, Jan 7, 2013 at 10:26 PM, Matthew Morley <matt@mpcm.com> wr=
ote:




On M=
on, Jan 7, 2013 at 5:39 PM, Conal Tuohy <conal.tuohy@versi.edu.au> wrote:






 =20
   =20
 =20
  

    
On 07/01/13 13:23, Matthew Morley
      wrote:

    

    

     =20
      

      For me the deficiency is not in the pointer, but patch format
      being generated.

      

      One approach is to push that *one* test, structure=C2=A0conformity,
      into the pointer syntax.=C2=A0Another is via the type operation.

      

      If a vague patch is generated, vague results are to be expected.

    

    It seems to me, on the contrary, that the deficiency is in the
    pointer syntax, and I think it would be a mistake to try to work
    around that deficiency in JSON Patch. Because aren't there other
    things which one might do with JSON Pointer than use it with JSON
    Patch? There's been mention of having it registered as a URI
    fragment identifier syntax for JSON for example. JSON Pointers could
    then end up all over the place, outside of patches. IMHO JSON
    Pointer needs to be taken seriously as a technology in its own
    right.=C2=A0






But JSON Pointer should not be changed just because of issues with=
 JSON Patch, especially when JSON Patch is attempting to address those issu=
es with other mechanisms within the specification. That is all I was trying=
 to express. The syntax change should be for other reasons, if it is going =
to be made.





My personal experience (for what its worth): In the past I&#=
39;ve tried a number of syntaxes like JSON Pointer. Mostly a.b.c.0 and even=
 a.b.c:0 at times to address the same issues suggested here. Though my expe=
riences pushed me towards a single syntax using a.b.c.0, and thus my suppor=
t for /a/b/c/0 over /a/b/c:0.





The system at first used the . or : syntax, combined with dynamic token=
s, being pointers themselves, to resolve other pointers. So it was not reas=
onable to know ahead of time if an end point was an array or an object. =C2=
=A0"a.b.c.{d.e.f}" could end up in an array or in an object, depe=
nding on the value at d.e.f at the time of resolution. Especially with many=
 layers of tokens to resolve, and changing data structures.





I found in practice, it didn't really matter, so the choice of . or=
 : was phased out. At the end of the day the two syntaxes point to mutually=
 exclusive points within the data, so that `meta data` about the structure =
was removed from the syntax we used. It didn't add value, even if it ad=
ded clarity at times. We also had functions at the end of paths, but that g=
oes beyond the JSON focus of the JSON Pointer goals, so those points are no=
t relevant here.





-- 
Matthew P. C. =
Morley

___________________________=
____________________

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





--f46d043d644bfff78a04d2c9f9f6--

From jsr@10gen.com  Tue Jan  8 09:52:49 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F64E11E80E7 for ; Tue,  8 Jan 2013 09:52:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.92
X-Spam-Level: 
X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.056,  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 WzSi46wpSmPd for ; Tue,  8 Jan 2013 09:52:48 -0800 (PST)
Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id E6DDC11E80E5 for ; Tue,  8 Jan 2013 09:52:47 -0800 (PST)
Received: by mail-vc0-f180.google.com with SMTP id p16so664691vcq.25 for ; Tue, 08 Jan 2013 09:52:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=hWvlWUgyBzGxVf3BD8C5pk42gDKT0VZ0M2m3TadsEPA=; b=Zqopb1rOHhx8OIl9lgaxnxoav7Hzg9iOtP4JJyQobO0oMuMlOjl1iVORbLhFJI9HJA 67Obog8WdAn0Ssh1RL6t2DwAnHakzoId3wFovyG5Jppjh4HjkIMXlwMJKuvs+bg3gS+X iCmw+hOdnh7dsgNcmFLN27BGnbac3f5PMv3w+oVoLAtTuq20Np5J/Sg8Tql/HAhk16+1 X2nmCM9QmaEUQXDSw4X6V8hfFmfppUT+lc/5+6kopLHz8+uDM5u9M/iGSXKSdXsJDc/O fT8c9QPhs8YDdwTKQPVRQR07YIlDdmpSt2yCAahar/lflBfNoM6GM2aj9Szwh7tlbGo2 0PxQ==
MIME-Version: 1.0
Received: by 10.220.247.204 with SMTP id md12mr87769130vcb.27.1357667567088; Tue, 08 Jan 2013 09:52:47 -0800 (PST)
Received: by 10.59.5.6 with HTTP; Tue, 8 Jan 2013 09:52:46 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>    <50EB4E8B.30700@versi.edu.au>   
Date: Tue, 8 Jan 2013 09:52:46 -0800
Message-ID: 
From: Jared Rosoff 
To: Robert Sayre 
Content-Type: multipart/alternative; boundary=bcaec54eede80f34f104d2ca9dbc
X-Gm-Message-State: ALoCoQk3D+25/mxljQKqpwExJb4iihvsndGo4QpXxgt6OCmER9GzlM0gtl2TTG9UEwGaX5lDfZMo
Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss , IESG 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 17:52:49 -0000

--bcaec54eede80f34f104d2ca9dbc
Content-Type: text/plain; charset=ISO-8859-1

I'm definitely not trying to expand the scope beyond the current draft.
More trying to share some experience with an existing implementation of
something similar.

A few comments on path syntax based on this experience.

1) It seems like some of the examples raised on this thread conflate JSON
documents with Javascript objects. According to the json spec, an object
always starts with an "{" and ends with a "}". Therefore, while the json
path "/1" could refer to elements in { "1": "a" } and [1,2], the latter is
not a correct JSON object.

2) Should a JSON pointer be able to refer to the "whole document"? In the
spec, it says that the path "" would refer to the whole JSON document. I
don't think this should be possible. If you want to replace the entire
document, you should be using an HTTP PUT to replace the content, rather
than a patch. Eliminating the ability to refer to the whole document would
also release some ambiguity in certain cases.

For example, earlier it was pointed out that if i have this document

{ "a": 1 }

And then apply this patch

{ op: "add", path: "", value: [1,2,3] }

then it would result in the document after patch being

[1,2,3]

however, this is not a valid json document as it is not enclosed by { }.

Instead, I think that the empty path should refer to the element of the
document named with an empty string.

So with { a: 1 }, and the op { op: "add", path: "", value: [1,2,3] }
would result in this document:

{ a: 1, "": [1,2,3] }

This also means that the leading slash is somewhat superfluous and could be
omitted from the syntax (since the paths "", and "/" would both resolve to
the "" named element of the document. This makes parsing paths easier as
well, since you can just split the path on the "/" and take the count of
parts to figure out how deep you're going.

Given { a: 1, "": [1,2,3] }, i would refer to the 2nd array element with
the path "/2". When parsing this i'd split on "/", which gives me two
tokens, the empty string (on the left of hte /) and the number 2 (on the
right of the /).

-j

On Tue, Jan 8, 2013 at 8:19 AM, Robert Sayre  wrote:

> Hi Jared,
>
> Earlier in the thread, I actually directly asked whether software that
> operates on arbitrary JSON was in scope for this WG (my example was
> CouchDB), after having suggested either changing the path syntax or
> renaming the array operations.[0]
>
> The editors didn't respond, except with process points or simple
> contradictions without rationale. My conclusion is that software such
> as MongoDB must be out of scope here. To their credit, the editors did
> point out that anyone is free to try again, and I plan to do just
> that. There's no reason to hold up this WG, since they seem to be
> burnt out.
>
> - Rob
>
> [0]
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg08552.html
>
>
> On Tue, Jan 8, 2013 at 12:26 AM, Jared Rosoff  wrote:
> > hi team, i'm new to the discussion here, but wanted to jump in. i work on
> > mongodb, a json database, and i wanted to share how we deal with these
> > issues.
> >
> > mongodb uses almost the same notation for pointers ("a.b.c" instead of
> > "/a/b/c"). We also index arrays in the same way as json pointer ( "a.0"
> > refers to the 0th element of the array called "a"). and this works fine
> in
> > practice. (ref:
> http://docs.mongodb.org/manual/core/document/#dot-notation)
> >
> > our update syntax is different tho. the verbs in mongodb updates for json
> > documents are more specific:
> >
> > set / unset / rename (operations on fields)
> > inc (increment integer values)
> > push / pop / pull (operations on arrays)
> > addToSet / removeFromSet (operations on arrays)
> >
> > (ref http://docs.mongodb.org/manual/reference/operators/#update)
> >
> > since update operations are more specific and type dependent, it's easy
> to
> > throw an error if an unexpected type is encountered (e.g. try to push
> onto a
> > field that has a non-array value) and to act smartly on empty fields ( if
> > path to push is empty, we assume it should be an array, create it, and
> then
> > push the value onto it).
> >
> > i concur the the pointer syntax is fine and ambiguity comes from the
> > definition of operators in json patch.
> >
> > -j
> >
> >
> > On Mon, Jan 7, 2013 at 10:26 PM, Matthew Morley  wrote:
> >>
> >> On Mon, Jan 7, 2013 at 5:39 PM, Conal Tuohy 
> >> wrote:
> >>>
> >>> On 07/01/13 13:23, Matthew Morley wrote:
> >>>
> >>>
> >>> For me the deficiency is not in the pointer, but patch format being
> >>> generated.
> >>>
> >>> One approach is to push that *one* test, structure conformity, into the
> >>> pointer syntax. Another is via the type operation.
> >>>
> >>> If a vague patch is generated, vague results are to be expected.
> >>>
> >>> It seems to me, on the contrary, that the deficiency is in the pointer
> >>> syntax, and I think it would be a mistake to try to work around that
> >>> deficiency in JSON Patch. Because aren't there other things which one
> might
> >>> do with JSON Pointer than use it with JSON Patch? There's been mention
> of
> >>> having it registered as a URI fragment identifier syntax for JSON for
> >>> example. JSON Pointers could then end up all over the place, outside of
> >>> patches. IMHO JSON Pointer needs to be taken seriously as a technology
> in
> >>> its own right.
> >>
> >>
> >> Couldn't agree more about it being taken seriously in its own right. :)
> >>
> >> JSON Pointer for me exists outside of JSON Patch, always has and will do
> >> the way we think about structures. As it represents both a resolution
> path
> >> and an identity string (both ends of the path concept). I see value
> from the
> >> identity view, in describing a location that is aware of being inside an
> >> array.
> >>
> >> But JSON Pointer should not be changed just because of issues with JSON
> >> Patch, especially when JSON Patch is attempting to address those issues
> with
> >> other mechanisms within the specification. That is all I was trying to
> >> express. The syntax change should be for other reasons, if it is going
> to be
> >> made.
> >>
> >> My personal experience (for what its worth): In the past I've tried a
> >> number of syntaxes like JSON Pointer. Mostly a.b.c.0 and even a.b.c:0 at
> >> times to address the same issues suggested here. Though my experiences
> >> pushed me towards a single syntax using a.b.c.0, and thus my support for
> >> /a/b/c/0 over /a/b/c:0.
> >>
> >> The system at first used the . or : syntax, combined with dynamic
> tokens,
> >> being pointers themselves, to resolve other pointers. So it was not
> >> reasonable to know ahead of time if an end point was an array or an
> object.
> >> "a.b.c.{d.e.f}" could end up in an array or in an object, depending on
> the
> >> value at d.e.f at the time of resolution. Especially with many layers of
> >> tokens to resolve, and changing data structures.
> >>
> >> I found in practice, it didn't really matter, so the choice of . or :
> was
> >> phased out. At the end of the day the two syntaxes point to mutually
> >> exclusive points within the data, so that `meta data` about the
> structure
> >> was removed from the syntax we used. It didn't add value, even if it
> added
> >> clarity at times. We also had functions at the end of paths, but that
> goes
> >> beyond the JSON focus of the JSON Pointer goals, so those points are not
> >> relevant here.
> >>
> >> This discussion thread seems to be getting overly complicated, but JSON
> >> Pointer changes should come from the JSON Pointer view point and that
> >> specifications goals, not from short comings in JSON Patch.
> >>
> >> --
> >> Matthew P. C. Morley
> >> _______________________________________________
> >> 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
> >
>

--bcaec54eede80f34f104d2ca9dbc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'm definitely not trying to expand the scope beyond the current draft.=
 More trying to share some experience with an existing implementation of so=
mething similar.=A0

A few comments on path syntax based =
on this experience.=A0



1) It seems like some of the examples raised on this th=
read conflate JSON documents with Javascript objects. According to the json=
 spec, an object always starts with an "{" and ends with a "=
}". Therefore, while the json path "/1" could refer to eleme=
nts in { "1": "a" } and [1,2], the latter is not a corr=
ect JSON object.=A0



2) Should a JSON pointer be able to refer to the "=
whole document"? In the spec, it says that the path "" would=
 refer to the whole JSON document. I don't think this should be possibl=
e. If you want to replace the entire document, you should be using an HTTP =
PUT to replace the content, rather than a patch. Eliminating the ability to=
 refer to the whole document would also release some ambiguity in certain c=
ases.=A0



For example, earlier it was pointed out that if i have =
this document=A0

{ "a": 1 }=A0

And then apply this patch=A0

{ op:=
 "add", path: "", value: [1,2,3] }=A0



then it would result in the document after patch being=
=A0

[1,2,3]=A0

however, t=
his is not a valid json document as it is not enclosed by { }.=A0



Instead, I think that the empty path should refer to the element=
 of the document named with an empty string.=A0

So=
 with { a: 1 }, and the op { op: "add", path: "", value=
: [1,2,3] }=A0


would result in this document:=A0

{ a: 1, &qu=
ot;": [1,2,3] }=A0

This also means that the l=
eading slash is somewhat superfluous and could be omitted from the syntax (=
since the paths "", and "/" would both resolve to the &=
quot;" named element of the document. This makes parsing paths easier =
as well, since you can just split the path on the "/" and take th=
e count of parts to figure out how deep you're going.=A0



Given { a: 1, "": [1,2,3] }, i would refer to=
 the 2nd array element with the path "/2". When parsing this i=
9;d split on "/", which gives me two tokens, the empty string (on=
 the left of hte /) and the number 2 (on the right of the /).=A0



-j=A0

On Tue, =
Jan 8, 2013 at 8:19 AM, Robert Sayre <sayrer@gmail.com> wrote=
:

Hi Jared,



Earlier in the thread, I actually directly asked whether software that

operates on arbitrary JSON was in scope for this WG (my example was

CouchDB), after having suggested either changing the path syntax or

renaming the array operations.[0]



The editors didn't respond, except with process points or simple

contradictions without rationale. My conclusion is that software such

as MongoDB must be out of scope here. To their credit, the editors did

point out that anyone is free to try again, and I plan to do just

that. There's no reason to hold up this WG, since they seem to be

burnt out.



- Rob



[0] http://www.ietf.org/mail-archive/web/apps-di=
scuss/current/msg08552.html






On Tue, Jan 8, 2013 at 12:26 AM, Jared Rosoff <jsr@10gen.com> wrote:

> hi team, i'm new to the discussion here, but wanted to jump in. i =
work on

> mongodb, a json database, and i wanted to share how we deal with these=


> issues.

>

> mongodb uses almost the same notation for pointers ("a.b.c" =
instead of

> "/a/b/c"). We also index arrays in the same way as json poin=
ter ( "a.0"

> refers to the 0th element of the array called "a"). and this=
 works fine in

> practice. (ref: http://docs.mongodb.org/manual/core/docu=
ment/#dot-notation)

>

> our update syntax is different tho. the verbs in mongodb updates for j=
son

> documents are more specific:

>

> set / unset / rename (operations on fields)

> inc (increment integer values)

> push / pop / pull (operations on arrays)

> addToSet / removeFromSet (operations on arrays)

>

> (ref http://docs.mongodb.org/manual/reference/operators/=
#update)

>

> since update operations are more specific and type dependent, it's=
 easy to

> throw an error if an unexpected type is encountered (e.g. try to push =
onto a

> field that has a non-array value) and to act smartly on empty fields (=
 if

> path to push is empty, we assume it should be an array, create it, and=
 then

> push the value onto it).

>

> i concur the the pointer syntax is fine and ambiguity comes from the
> definition of operators in json patch.

>

> -j

>

>

> On Mon, Jan 7, 2013 at 10:26 PM, Matthew Morley <matt@mpcm.com> wrote:

>>

>> On Mon, Jan 7, 2013 at 5:39 PM, Conal Tuohy <conal.tuohy@versi.edu.au>

>> wrote:

>>>

>>> On 07/01/13 13:23, Matthew Morley wrote:

>>>

>>>

>>> For me the deficiency is not in the pointer, but patch format =
being

>>> generated.

>>>

>>> One approach is to push that *one* test, structure conformity,=
 into the

>>> pointer syntax. Another is via the type operation.

>>>

>>> If a vague patch is generated, vague results are to be expecte=
d.

>>>

>>> It seems to me, on the contrary, that the deficiency is in the=
 pointer

>>> syntax, and I think it would be a mistake to try to work aroun=
d that

>>> deficiency in JSON Patch. Because aren't there other thing=
s which one might

>>> do with JSON Pointer than use it with JSON Patch? There's =
been mention of

>>> having it registered as a URI fragment identifier syntax for J=
SON for

>>> example. JSON Pointers could then end up all over the place, o=
utside of

>>> patches. IMHO JSON Pointer needs to be taken seriously as a te=
chnology in

>>> its own right.

>>

>>

>> Couldn't agree more about it being taken seriously in its own =
right. :)

>>

>> JSON Pointer for me exists outside of JSON Patch, always has and w=
ill do

>> the way we think about structures. As it represents both a resolut=
ion path

>> and an identity string (both ends of the path concept). I see valu=
e from the

>> identity view, in describing a location that is aware of being ins=
ide an

>> array.

>>

>> But JSON Pointer should not be changed just because of issues with=
 JSON

>> Patch, especially when JSON Patch is attempting to address those i=
ssues with

>> other mechanisms within the specification. That is all I was tryin=
g to

>> express. The syntax change should be for other reasons, if it is g=
oing to be

>> made.

>>

>> My personal experience (for what its worth): In the past I've =
tried a

>> number of syntaxes like JSON Pointer. Mostly a.b.c.0 and even a.b.=
c:0 at

>> times to address the same issues suggested here. Though my experie=
nces

>> pushed me towards a single syntax using a.b.c.0, and thus my suppo=
rt for

>> /a/b/c/0 over /a/b/c:0.

>>

>> The system at first used the . or : syntax, combined with dynamic =
tokens,

>> being pointers themselves, to resolve other pointers. So it was no=
t

>> reasonable to know ahead of time if an end point was an array or a=
n object.

>> "a.b.c.{d.e.f}" could end up in an array or in an object=
, depending on the

>> value at d.e.f at the time of resolution. Especially with many lay=
ers of

>> tokens to resolve, and changing data structures.

>>

>> I found in practice, it didn't really matter, so the choice of=
 . or : was

>> phased out. At the end of the day the two syntaxes point to mutual=
ly

>> exclusive points within the data, so that `meta data` about the st=
ructure

>> was removed from the syntax we used. It didn't add value, even=
 if it added

>> clarity at times. We also had functions at the end of paths, but t=
hat goes

>> beyond the JSON focus of the JSON Pointer goals, so those points a=
re not

>> relevant here.

>>

>> This discussion thread seems to be getting overly complicated, but=
 JSON

>> Pointer changes should come from the JSON Pointer view point and t=
hat

>> specifications goals, not from short comings in JSON Patch.

>>

>> --

>> Matthew P. C. Morley

>> _______________________________________________

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

>





--bcaec54eede80f34f104d2ca9dbc--

From jasnell@gmail.com  Tue Jan  8 09:58:45 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747F221F8684; Tue,  8 Jan 2013 09:58:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.987
X-Spam-Level: 
X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[AWL=-0.389, 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 pxPHpQI0F7Wv; Tue,  8 Jan 2013 09:58:45 -0800 (PST)
Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id C99DE21F8678; Tue,  8 Jan 2013 09:58:44 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id qd14so894304ieb.34 for ; Tue, 08 Jan 2013 09:58:44 -0800 (PST)
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=DcNmtxw0FoMdjQxYFdWxxj0M/HMzLPcCqpqp8I00kyk=; b=IBQSxgzYCGQSKb0tRgHkmdbVPsxeR2GM2CD9km27Fo3xINZINnKY+s2VQz7KjbMbJC uhWG+HWCfTZnHpWVKKO8OxsU7b2B4VaUmBqLSexBeQ0URVNxluST1tK/k0VLYVuDUi7N PpFo8vMA4snjY4fj9B9fTPLHUEtTBT74PQrdFtSnw2D5NCh/W9bFkm2Mo+k+vm7A8hkN AgHo+E5cWFxyipRa98e6Y++GgZSvpnpFkwHqektp65DjLavMlTry/fmaK05wBujUjGZ8 gIvhev8C45L17sKxK5bI3aUm4Cj79Pa9QXy4zWhjsBI9y3kC4fkQPYpYv/R4804t1juM vwBQ==
Received: by 10.50.150.174 with SMTP id uj14mr9771408igb.19.1357667924440; Tue, 08 Jan 2013 09:58:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.7.19 with HTTP; Tue, 8 Jan 2013 09:58:24 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>    <50EB4E8B.30700@versi.edu.au>    
From: James M Snell 
Date: Tue, 8 Jan 2013 09:58:24 -0800
Message-ID: 
To: Jared Rosoff 
Content-Type: multipart/alternative; boundary=f46d043d644b5bf4f504d2cab295
Cc: IESG , Mark Nottingham , IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 17:58:45 -0000

--f46d043d644b5bf4f504d2cab295
Content-Type: text/plain; charset=UTF-8

On Tue, Jan 8, 2013 at 9:52 AM, Jared Rosoff  wrote:

> [snip]
> then it would result in the document after patch being
>
> [1,2,3]
>
> however, this is not a valid json document as it is not enclosed by { }.
> [snip]
>

The root of a JSON Document can be either an object or an array.

- James

--f46d043d644b5bf4f504d2cab295
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Jan 8, 2013 at 9:52 AM, Jared Rosoff <jsr@10gen.com>=
 wrote:



[snip]
then it would result in the do=
cument after patch being=C2=A0




[1,2,3]=C2=A0

however, this is=
 not a valid json document as it is not enclosed by { }.=C2=A0
[snip]

The root of a JSON D=
ocument can be either an object or an array.




- James



--f46d043d644b5bf4f504d2cab295--

From jsr@10gen.com  Tue Jan  8 10:14:12 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFA911E80F6 for ; Tue,  8 Jan 2013 10:14:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.935
X-Spam-Level: 
X-Spam-Status: No, score=-2.935 tagged_above=-999 required=5 tests=[AWL=0.041,  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 0GGMR9sN56vH for ; Tue,  8 Jan 2013 10:14:11 -0800 (PST)
Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id DE8DC11E80F1 for ; Tue,  8 Jan 2013 10:14:09 -0800 (PST)
Received: by mail-vb0-f51.google.com with SMTP id fq11so712701vbb.10 for ; Tue, 08 Jan 2013 10:14:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=32UVGIeS12HBR4tosl5xnEuOE9iA2UC8x5TpSYEB1M4=; b=Elapi1YweoRvP+B0xYBwl635APMY3qZYaCePNsSn5dPpG+bDAOWd2wQE2Xu2zJPRPj 6NHnJy96QWA2EckhWz5QjWbtZjpNnxGNc2yaqWpWegbpPXl0mfQ00Vt8gtzr/AgT4r2E WveCnZkPdZbBCljrKsPqE4lJA57P7UP+X96RB20BzXZ/fGVfjHfWM4ZguCc3DI/QxbeA osYhZTSp5n/3R/XvgiyFM7eu4gXPst7iHhk3ex2D4bdIilrvEli363tqhU8KfQ8q1Hmr IRA4R8Y/CLgWhIJsuEeplLtgy+CMvVMOBuLImnG9GAcRvAu3clXpOxDZeiRjRKp/CYZm N1vA==
MIME-Version: 1.0
Received: by 10.220.151.83 with SMTP id b19mr86396979vcw.25.1357668839893; Tue, 08 Jan 2013 10:13:59 -0800 (PST)
Received: by 10.59.5.6 with HTTP; Tue, 8 Jan 2013 10:13:59 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>    <50EB4E8B.30700@versi.edu.au>     
Date: Tue, 8 Jan 2013 10:13:59 -0800
Message-ID: 
From: Jared Rosoff 
To: James M Snell 
Content-Type: multipart/alternative; boundary=f46d0434bf1eeca99404d2cae8d7
X-Gm-Message-State: ALoCoQntwXlNd02occJXoJITHu5Wtz+hdUOzcUWOPaMc73SXKz0neBf4yqauLTVw5KE07KLQ/4BI
Cc: IESG , Mark Nottingham , IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 18:14:12 -0000

--f46d0434bf1eeca99404d2cae8d7
Content-Type: text/plain; charset=ISO-8859-1

my bad.

regardless, if you want to replace the whole document, is that a patch? or
should that better be done with PUT?

On Tue, Jan 8, 2013 at 9:58 AM, James M Snell  wrote:

>
>
> The root of a JSON Document can be either an object or an array.
>
> - James
>
>

--f46d0434bf1eeca99404d2cae8d7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

my bad.=A0

regardless, if you want to replace the whole =
document, is that a patch? or should that better be done with PUT?=A0
On Tue, Jan 8, 2013 at 9:58 AM, James M Snell =
<jasnell@gmail.com> wrote:


=



The root of a JSON Docum=
ent can be either an object or an array.





- James






--f46d0434bf1eeca99404d2cae8d7--

From jasnell@gmail.com  Tue Jan  8 10:15:20 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8B71F0CFA; Tue,  8 Jan 2013 10:15:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.948
X-Spam-Level: 
X-Spam-Status: No, score=-3.948 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 PmDIXymg6fj2; Tue,  8 Jan 2013 10:15:19 -0800 (PST)
Received: from mail-ia0-f174.google.com (mail-ia0-f174.google.com [209.85.210.174]) by ietfa.amsl.com (Postfix) with ESMTP id AAEE91F0CB3; Tue,  8 Jan 2013 10:15:19 -0800 (PST)
Received: by mail-ia0-f174.google.com with SMTP id y25so619502iay.5 for ; Tue, 08 Jan 2013 10:15:19 -0800 (PST)
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=BRlfGcHRkZ4zfzqSPWMpGPzKrrkT6e2ejNKUXdSKH74=; b=U/wdJoeu4Wf2EgeH5NdQm3nR54aApDT0jzg/J4KHa5l9gPphZ+Jae+PHAYroFn2XXm wfDOkkytT4YYEK4bYLfAzzk+caf81Fk5jIRFuiu8z7gVryF7t5efenLxEQBF14Zf69t3 g2m/xzN+aRbdLiRr70tTcJGXBad3UQNfC5GOGIXcxpG4ONRm7Tpbzz3gx5fYNpZWuZ6Q 20WxR/LECi/5GSAV6F40g8QrKXZNWwZLG7SLlLmIrxpvpnDCrioLzKwdRx72BcZsbcN8 EumO21UbKTkgPPsXYVicljwZkGJmj43sKeENbYIhlJ2O1+VTT2zdUFXwsGlkhwBgCiL3 vFlg==
Received: by 10.50.158.170 with SMTP id wv10mr10077538igb.75.1357668919260; Tue, 08 Jan 2013 10:15:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.7.19 with HTTP; Tue, 8 Jan 2013 10:14:59 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>    <50EB4E8B.30700@versi.edu.au>      
From: James M Snell 
Date: Tue, 8 Jan 2013 10:14:59 -0800
Message-ID: 
To: Jared Rosoff 
Content-Type: multipart/alternative; boundary=14dae9340f21a7b5f704d2caed7f
Cc: IESG , Mark Nottingham , IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 18:15:20 -0000

--14dae9340f21a7b5f704d2caed7f
Content-Type: text/plain; charset=UTF-8

+1


On Tue, Jan 8, 2013 at 10:13 AM, Jared Rosoff  wrote:

> my bad.
>
> regardless, if you want to replace the whole document, is that a patch? or
> should that better be done with PUT?
>
>
> On Tue, Jan 8, 2013 at 9:58 AM, James M Snell  wrote:
>
>>
>>
>> The root of a JSON Document can be either an object or an array.
>>
>> - James
>>
>>
>

--14dae9340f21a7b5f704d2caed7f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1=C2=A0


On Tue, Jan 8, =
2013 at 10:13 AM, Jared Rosoff <jsr@10gen.com> wrote:



my bad.=C2=A0

regardless,=
 if you want to replace the whole document, is that a patch? or should that=
 better be done with PUT?=C2=A0




On Tue, Jan 8, 2013 at 9:58 AM, James M =
Snell <jasnell@gmail.com> wrote:


=



The root of a JSON Docum=
ent can be either an object or an array.







- James









--14dae9340f21a7b5f704d2caed7f--

From sayrer@gmail.com  Tue Jan  8 10:57:03 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C396421F8446; Tue,  8 Jan 2013 10:57:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500,  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 72cswcpjSDeB; Tue,  8 Jan 2013 10:57:03 -0800 (PST)
Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6D221F8442; Tue,  8 Jan 2013 10:57:01 -0800 (PST)
Received: by mail-lb0-f171.google.com with SMTP id gf7so641234lbb.30 for ; Tue, 08 Jan 2013 10:57:01 -0800 (PST)
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=WRDPit+3DGAsj/F43jvA6CbBefrcpcSZELhCupHfJeI=; b=VQSjKdnccxSHIg0dyCkaw1Jph28q5v6J9R1Sbd+zLEBDgxKctzDfZkFppkyNM/FbC2 qa2+NV9w9qfbT6ujfQD7lOFJoRYJcwOKqK2Zy2nXv6UAq0wzZp6w7yhIZfY9KzrVSIja spmQWXMusU4xPK5SU3ofxahys6csLXrqBcL76yZdZjPNVgF6qF7RZOwdfhkQXDZq1Q4i yDJvv7ydVZ2ah/WXDHJHyveyHTIuiUOfVsD4TFDSuTyyuQ5eJBLxJrwfucsyxSQm42Gv cPzO06m33n5RQzC2Qpiw2wVGVAkMb69yuT2Dpl691FM2gE+jjJk1sX6GBRC32Pa+QWKh YEmw==
MIME-Version: 1.0
Received: by 10.152.121.212 with SMTP id lm20mr61998011lab.42.1357671421098; Tue, 08 Jan 2013 10:57:01 -0800 (PST)
Received: by 10.112.43.226 with HTTP; Tue, 8 Jan 2013 10:57:00 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>    <50EB4E8B.30700@versi.edu.au>    
Date: Tue, 8 Jan 2013 10:57:00 -0800
Message-ID: 
From: Robert Sayre 
To: Jared Rosoff 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Mark Nottingham , IETF Discussion , IETF Apps Discuss , IESG 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 18:57:03 -0000

On Tue, Jan 8, 2013 at 9:52 AM, Jared Rosoff  wrote:
>
> 1) It seems like some of the examples raised on this thread conflate JSON
> documents with Javascript objects. According to the json spec, an object
> always starts with an "{" and ends with a "}". Therefore, while the json
> path "/1" could refer to elements in { "1": "a" } and [1,2], the latter is
> not a correct JSON object.

>From a JS shell session:

% JSON.stringify([1,2])
"[1,2]"

- Rob

From barryleiba.mailing.lists@gmail.com  Tue Jan  8 13:41:08 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4492E1F0CFA for ; Tue,  8 Jan 2013 13:41:08 -0800 (PST)
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.243, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Y5HFmHFpqQPb for ; Tue,  8 Jan 2013 13:41:07 -0800 (PST)
Received: from mail-vb0-f46.google.com (mail-vb0-f46.google.com [209.85.212.46]) by ietfa.amsl.com (Postfix) with ESMTP id 82EAB21F84EA for ; Tue,  8 Jan 2013 13:41:07 -0800 (PST)
Received: by mail-vb0-f46.google.com with SMTP id b13so902333vby.19 for ; Tue, 08 Jan 2013 13:41:07 -0800 (PST)
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=TX9HZYRqF7JEGDF1qFmkk/Bksn0AFfs0byyCJAH5jBI=; b=GF/FO3RDHlYogXdzOa4HuBaPdyRDr7KyLZJ3vIHEqm7gxh6Qr9Pj5IVyUXz26FEkSd zrvLNbgxwE2uqXef3cqwKIatsd1H7E9fsZ/T04ezdmTfTk8nmDpaG3YOOHUh7Z+g8ZwI eh+w7NvfUm0OJ2pjKjyhC98w6pRotIyWUC03rUseku7YNeoIfKpiE16xvVO0UIthmT6V rPkRkU8aGN70EQrEyaD4PlIE05loCffvHpz3xDHTSGYhdpV4bUU/CiWumeqzMifenekh u8ZvScaklIC9hknUUOPkGNZiapsg9dMczdTZd1FLwDWQ/LArJYdC3Tr19fEXZo/YP/32 5YXw==
MIME-Version: 1.0
Received: by 10.58.18.239 with SMTP id z15mr90814038ved.27.1357681267059; Tue, 08 Jan 2013 13:41:07 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Tue, 8 Jan 2013 13:41:06 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>    <50EB4E8B.30700@versi.edu.au>       
Date: Tue, 8 Jan 2013 16:41:06 -0500
X-Google-Sender-Auth: 8fh-jg4d5iVKRl2DpBCeY_R6hRY
Message-ID: 
From: Barry Leiba 
To: James M Snell 
Content-Type: multipart/alternative; boundary=047d7b6d9116a42d8804d2cdcd34
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Tue, 08 Jan 2013 21:41:08 -0000

--047d7b6d9116a42d8804d2cdcd34
Content-Type: text/plain; charset=ISO-8859-1

Let me suggest that y'all remove the IESG and the main IETF discussion list
(and me) from the CC list if you continue this discussion (which you're
welcome to do).  Actually, I suggest that if you do continue it, you start
a new thread with a new subject, on apps-discuss only.

Thanks.

Barry

--047d7b6d9116a42d8804d2cdcd34
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Let me suggest that y'all remove the IESG and the main IETF discussion =
list (and me) from the CC list if you continue this discussion (which you&#=
39;re welcome to do). =A0Actually, I suggest that if you do continue it, yo=
u start a new thread with a new subject, on apps-discuss only.


Thanks.

Barry


--047d7b6d9116a42d8804d2cdcd34--

From sayrer@gmail.com  Wed Jan  9 00:17:26 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D39721F877B; Wed,  9 Jan 2013 00:17:26 -0800 (PST)
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.250,  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 6c+cgWolmuY2; Wed,  9 Jan 2013 00:17:26 -0800 (PST)
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9126A21F8775; Wed,  9 Jan 2013 00:17:25 -0800 (PST)
Received: by mail-wi0-f175.google.com with SMTP id hm11so357393wib.8 for ; Wed, 09 Jan 2013 00:17:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Xd1RihbKxaiTnnczkWg1Ms9fnSNzd/y+XVcnC4a+y5Y=; b=Pkiq8hizfI5z8Yt9jv45FhnHBe6zP7pieMvMeAZGaGXStnQ/xQxt4C4wIGz6y7kXXa fieI2+ettD+SwRTGzGSZL0f9lomHpwQfftzMZRwMlHpDCp6D5ysTsshI8lQbYhkC9ASr cuGJIyxzAfCzV+qYwj8b3cCiajIVm5QnFRZo5tFMu43tbISfSRiJkK9Hy6KfCdiJeUc4 uLBsI2EmY/Co3vXrCAZnF0G/r6+SUtgTXGsengicuwG1wMLa/I2mGzKavXLOhLgK9m+L dn6L2/i6+kGb7iUPBjXqTOm3W7Ujs+X37n96vpmkxZ2LCizYiSIHb22x2NkMcQX3pZ/P tY7g==
MIME-Version: 1.0
X-Received: by 10.180.72.146 with SMTP id d18mr1618720wiv.33.1357719444742; Wed, 09 Jan 2013 00:17:24 -0800 (PST)
Received: by 10.194.32.100 with HTTP; Wed, 9 Jan 2013 00:17:24 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>    <50EB4E8B.30700@versi.edu.au>        
Date: Wed, 9 Jan 2013 00:17:24 -0800
Message-ID: 
From: Robert Sayre 
To: Barry Leiba 
Content-Type: text/plain; charset=ISO-8859-1
Cc: IESG , IETF Apps Discuss , IETF discussion list 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Wed, 09 Jan 2013 08:17:26 -0000

Awesome news: JSON Patch has enough IESG votes to become a standards
track document, even though JSON Pointer still has a discuss. This way
of doing things is very efficient--lots of documents can be approved
this way.

- Rob

On Tue, Jan 8, 2013 at 1:41 PM, Barry Leiba  wrote:
> Let me suggest that y'all remove the IESG and the main IETF discussion list
> (and me) from the CC list if you continue this discussion (which you're
> welcome to do).  Actually, I suggest that if you do continue it, you start a
> new thread with a new subject, on apps-discuss only.
>
> Thanks.
>
> Barry
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From James.H.Manger@team.telstra.com  Wed Jan  9 06:08:22 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C4621F8759 for ; Wed,  9 Jan 2013 06:08:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[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 SGUoLZtztmlA for ; Wed,  9 Jan 2013 06:08:21 -0800 (PST)
Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 217FF21F8745 for ; Wed,  9 Jan 2013 06:08:18 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.84,438,1355058000";  d="scan'208,217";a="109610935"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 10 Jan 2013 01:08:18 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6949"; a="106658405"
Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbni.tcif.telstra.com.au with ESMTP; 10 Jan 2013 01:08:18 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Thu, 10 Jan 2013 01:08:17 +1100
From: "Manger, James H" 
To: IETF Apps Discuss 
Date: Thu, 10 Jan 2013 01:08:16 +1100
Thread-Topic: JSON pointer: allow /7, but not /07, as an array index
Thread-Index: Ac3ucsUbjQUxz6nBSwif9ztmSPw8nw==
Message-ID: <255B9BB34FB7D647A506DC292726F6E115049AF54E@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_255B9BB34FB7D647A506DC292726F6E115049AF54EWSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: [apps-discuss] JSON pointer: allow /7, but not /07, as an array index
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Jan 2013 14:08:22 -0000

--_000_255B9BB34FB7D647A506DC292726F6E115049AF54EWSMSG3153Vsrv_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Q2FuIEkgYWdhaW4gYXNrIHRoYXQgd2UgZGlzYWxsb3cgdW5uZWNlc3NhcnkgbGVhZGluZyB6ZXJv
cyBpbiBhcnJheSBpbmRpY2VzIGluIEpTT04gcG9pbnRlcnMuDQoNCkFuIGV4dHJhIHJlYXNvbiBp
cyB0byBtYWtlIGl0IGVhc2llciB0byBiZSBhYmxlIHRvIHRlbGwgd2hlbiBvbmUgcG9pbnRlciBp
cyBhIOKAnHByb3BlciBwcmVmaXjigJ0gb2YgYW5vdGhlciwgYW5kIHRvIG1ha2UgdGhpcyB0ZXN0
IHBvc3NpYmxlIHdpdGhvdXQgbmVlZGluZyB0aGUgY29udGV4dCBvZiBhIHNwZWNpZmljIEpTT04g
dGV4dC4NCkZvciBleGFtcGxlLCBpcyAvZm9vLzA3L2JhciBhIOKAnHByb3BlciBwcmVmaXjigJ0g
KHBvaW50ZXIgdG8gYSBwYXJlbnQpIG9mIC9mb28vNy9iYXIveHh4Pw0KQ3VycmVudGx5IGl0IG1p
Z2h0IGJlLCBvciBpdCBtaWdodCBub3QgYmUg4oCTIGRlcGVuZGluZyBvbiB3aGV0aGVyIHRoZSB2
YWx1ZSBvZiAvZm9vIGlzIGFuIGFycmF5IG9yIGFuIG9iamVjdC4NClRoaXMgdW5uZWNlc3Nhcnkg
Y29tcGxpY2F0ZXMgY29kZSB0aGF0IHdhbnQgdG8gaW1wbGVtZW50IHRoZSDigJxtb3Zl4oCdIG9w
ZXJhdGlvbiBpbiBqc29uLXBhdGNoLCB3aGljaCBzYXlzIHRoZSDigJxmcm9t4oCdIGxvY2F0aW9u
IE1VU1QgTk9UIGJlIGEgcHJvcGVyIHByZWZpeCBvZiB0aGUg4oCccGF0aOKAnSBsb2NhdGlvbi4N
Cg0KW0ZvciBvdGhlciByZWFzb25zIChhbmQgc3VnZ2VzdGVkIHRleHQpIHNlZSBhbiBlYXJsaWVy
IHRocmVhZDogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FwcHMtZGlzY3Vz
cy9jdXJyZW50L21zZzA3NzI1Lmh0bWxdDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0K

--_000_255B9BB34FB7D647A506DC292726F6E115049AF54EWSMSG3153Vsrv_
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+Q2FuIEkgYWdhaW4gYXNrIHRoYXQg
d2UgZGlzYWxsb3cgdW5uZWNlc3NhcnkgbGVhZGluZyB6ZXJvcyBpbiBhcnJheSBpbmRpY2VzIGlu
IEpTT04gcG9pbnRlcnMuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5BbiBleHRyYSByZWFzb24gaXMgdG8gbWFr
ZSBpdCBlYXNpZXIgdG8gYmUgYWJsZSB0byB0ZWxsIHdoZW4gb25lIHBvaW50ZXIgaXMgYSDigJxw
cm9wZXIgcHJlZml44oCdIG9mIGFub3RoZXIsIGFuZCB0byBtYWtlIHRoaXMgdGVzdCBwb3NzaWJs
ZSB3aXRob3V0IG5lZWRpbmcgdGhlIGNvbnRleHQgb2YgYSBzcGVjaWZpYyBKU09OIHRleHQuPG86
cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkZvciBleGFtcGxlLCBpcyAvZm9vLzA3L2Jh
ciBhIOKAnHByb3BlciBwcmVmaXjigJ0gKHBvaW50ZXIgdG8gYSBwYXJlbnQpIG9mIC9mb28vNy9i
YXIveHh4PzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5DdXJyZW50bHkgaXQgbWln
aHQgYmUsIG9yIGl0IG1pZ2h0IG5vdCBiZSDigJMgZGVwZW5kaW5nIG9uIHdoZXRoZXIgdGhlIHZh
bHVlIG9mIC9mb28gaXMgYW4gYXJyYXkgb3IgYW4gb2JqZWN0LjxvOnA+PC9vOnA+PC9wPjxwIGNs
YXNzPU1zb05vcm1hbD5UaGlzIHVubmVjZXNzYXJ5IGNvbXBsaWNhdGVzIGNvZGUgdGhhdCB3YW50
IHRvIGltcGxlbWVudCB0aGUg4oCcbW92ZeKAnSBvcGVyYXRpb24gaW4ganNvbi1wYXRjaCwgd2hp
Y2ggc2F5cyB0aGUg4oCcZnJvbeKAnSBsb2NhdGlvbiBNVVNUIE5PVCBiZSBhIHByb3BlciBwcmVm
aXggb2YgdGhlIOKAnHBhdGjigJ0gbG9jYXRpb24uPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv
Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5bRm9yIG90aGVy
IHJlYXNvbnMgKGFuZCBzdWdnZXN0ZWQgdGV4dCkgc2VlIGFuIGVhcmxpZXIgdGhyZWFkOiBodHRw
Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYXBwcy1kaXNjdXNzL2N1cnJlbnQvbXNn
MDc3MjUuaHRtbF08bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8
L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPi0tPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv
Tm9ybWFsPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpw
PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg==

--_000_255B9BB34FB7D647A506DC292726F6E115049AF54EWSMSG3153Vsrv_--

From hsantos@isdg.net  Tue Jan  8 15:59:43 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D83811E80E3 for ; Tue,  8 Jan 2013 15:59:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.445
X-Spam-Level: 
X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 e7VTijICa1pg for ; Tue,  8 Jan 2013 15:59:42 -0800 (PST)
Received: from mail.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B52E511E80CC for ; Tue,  8 Jan 2013 15:59:41 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5502; t=1357689567; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=27BlMqfqTE51ywf8xIdHQ0NIWKY=; b=O/smO7w9VVHDVaDejoIa zqxGVFCp+ZjmWzYPjKoYByRslZg98yMmP7tBe0fnug04slphexSzp1sNB/MqJePl aoVBIDv2UvouL8n0qLHq7JDXagY+o+xVMSmGGs1hWPCh0iHqiIuJ6srnI0WRwTh6 +CpAM118WuwpjpFrCEvr6rI=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 08 Jan 2013 18:59:27 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 826325984.4432.1244; Tue, 08 Jan 2013 18:59:26 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5502; t=1357689512; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Kr35vII is8N1NpWkcVLX790CpKiA8xmP3OZ0VZmLcAs=; b=aNEHm9dzxKMa+ducTidEadW ACD6u4OzYSYmSFNLLm5MrxkcDFCUsI16XeqHNWWAg77DmHqsTwV0iYI1WvJy32dH w92UO6de9r8TJaFOjzBCGjIcWx/IhuXJp0fhGt+MfAmsjSFg3VKVlJkUdsvsl/T2 b/EyzNywqM4Y5YoQGYA8=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 08 Jan 2013 18:58:32 -0500
Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1425027679.10.5212; Tue, 08 Jan 2013 18:58:31 -0500
Message-ID: <50ECB2CD.7090700@isdg.net>
Date: Tue, 08 Jan 2013 18:59:09 -0500
From: Hector Santos 
Organization: Santronics Software, Inc.
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Carsten Bormann 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com>	<50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>		<50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>	 <018651D6-83D4-42D6-86EB-0FAA5DE10DDA@tzi.org>
In-Reply-To: <018651D6-83D4-42D6-86EB-0FAA5DE10DDA@tzi.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Wed, 09 Jan 2013 08:37:05 -0800
Cc: IETF Discussion , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:	 (JSON Pointer) 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: Tue, 08 Jan 2013 23:59:43 -0000

Thanks Carsten for your explanations.  As having experience with both 
styles of programming as you describe and also interpretive vs p-code 
vs static compiler writing for our servers and clients, it would seem 
to me that if the both syntaxes are possible, then the solution is 
more implementator specific. In other words, implementators can deal 
with both if robustness is desired.  It sounds "kludgy" but it sounds 
like there exist both styles in practice already, so unless breaking 
existing implementators is not a concern in the name of going with the 
"correct and prefer" syntax, then both need to be supported.

The first thing that came to mind when this interesting thread started 
is whether a solution is desired for a public open-ended query 
client/server system versus this being more proprietary (presuming the 
idea of "patching" is an high authentication required concept).  It 
would seem to me that they might be various clients used against a 
server and it would be up to the server to support all possibilities 
to remain robust.   The client itself is probably having its "JIT" 
(Just-In-Time) parsing/compiling/error trapping, etc or it might be 
more static to catch canned solutions.  The client can perhaps have 
all its data I/O resolved by the "ide" new JSON support for data C/S 
(including "AJAX") transactions.  Come to think to it, the server 
implementation itself COULD have its syntax checking before release 
the page for production and/or if dynamically generated then it would 
probably use a preferred syntax.

It seems the answer is to support both syntaxes IFF there is compiler 
or interpretation logic capability to trapping both and if there are 
already existing clients and servers, note (highlight) that servers 
|need to|SHOULD| be ready for both.

I will say one thing, if we ever needed a HTTP based patching need or 
requirement to add support to our product web server component, it 
doesn't seem I have any choice - it would be prudent to support both 
especially on the client side.  What method I would use for our own 
data exchanges may be preferred method, but the server would need to 
do both.

--
HLS


Carsten Bormann wrote:
> For those who wonder what all the fuzz in this thread is about, let me try to explain this with some different terminology, exposing what kind of intuition these widely diverging value judgements might derive from.
> 
> In programming, there are two camps: static typers and dynamic typers.  Static typers want to annotate their programs with information about the objects being manipulated so the compiler can help them catch careless mistakes even before the program runs.  Dynamic typers don't care about that as much, because they know they have to write tests anyway (not all programming errors are exposable as type errors) and these will uncover the same careless mistakes.  [The runtime system will actually check types once the specific context of execution is available, that's why it's called "dynamic typing".]
> 
> The programming debate is beside the point here for a number of reasons*), but it does shape the thinking of programmers, and it seems in particular it shaped the thinking of some of the commenters here.
> 
> /a/1/b/2 is something that a dynamic typer would come up with.  The specific semantics are well-defined, but only in the specific execution context (what JSON document this is being applied to).
> /a:1/b:2 (to use James' strawman syntax that distinguishes JSON object keys from array indices) exposes more typing info, so it is more statically typed, and it will catch mismatches between the types that the JSON pointer assumed to be present and those that actually are.
> 
> For a static-typing fundamentalist, it is viscerally unacceptable to forego the opportunity of catching this kind of "type error".
> 
> For a non-fundamentalist, this is more of an issue of probabilities, and the interlocking of mechanisms.  
> Which percentage of usage errors will be caught by this?
> Many, many mismatches between JSON pointers and JSON instances to will just not happen to trigger this particular type error.
> So it can be argued that the ability to catch it doesn't really help much: If you care about mismatch errors, you already need to have something else in place to catch them -- relying only on the likelihood of a mismatch to trigger an array/object mismatch would be imprudent. So in reality, the ability to catch the type error buys you nothing.
> (Or, actually, very little, as improved diagnostics is always worth something in a debugging situation.)
> 
> TL;DR: there is no "ambiguity" at all.  Please stop referring to an "ambiguity".  There is none.
> Just a missed opportunity to catch an error, caused by not sending along (redundant) type information.
> 
> (You will gather that my 2 cents for this change are "not worth it", but I was more interested in explaining the mere existence of this discussion, first.  Applying the wrong intuitions to an engineering decision is one of the major causes of suboptimal design...)
> 
> Gr��e, Carsten
> 
> *) Well, for a start, we are not here to catch errors in programming.  Programming languages are difficult because they are the human interface to the computer's programmability.  JSON pointers are a pure machine-to-machine mechanism, so most of the issues in programming just don't arise.  Porting your intuitions from programming to this is not going to work very well.
> 
> 
> 

-- 
HLS



From barryleiba@gmail.com  Wed Jan  9 10:26:17 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CF921F89CB; Wed,  9 Jan 2013 10:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.207
X-Spam-Level: 
X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=-0.230, 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 INUtvlHMT4Sd; Wed,  9 Jan 2013 10:26:16 -0800 (PST)
Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id CD5B121F8848; Wed,  9 Jan 2013 10:26:13 -0800 (PST)
Received: by mail-lb0-f176.google.com with SMTP id k6so1305842lbo.35 for ; Wed, 09 Jan 2013 10:26:10 -0800 (PST)
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=Zi2YLFs8vQ3+v//0LnIRT51yAQYizUSoktwxoZtFLwY=; b=sPImnNYTvNnnuusJy2HiBJFMvzjxZGjVv9cuGNw4LI6MTcQ8oj2wezzdK46xvEjcoG fdfXE3eL4DHIOU1jlXDjX50HjhWPurfcP+pSNqmEo4A7c2jSNbiM1r77jIdw47Y+3Ewv YnvOTMlsR7915B7zm5Suibsp1yu97fCG7A+GC8G76l9h0TZ0Fim2PigrYE9W/8WFhLvu 7VTjaYiqokdhQ4nq8hJiZd/Id23lsnI7oymScpNBZDtoi28gkBXxknL2uWZVTSVaMRE7 rPFuzmctBV+4jSg8+yfEvnOUjLMNdwFLff9fm6vOZDfoN2C8M+IGzLoggMFVrKfg4KPy A/iw==
MIME-Version: 1.0
Received: by 10.152.109.238 with SMTP id hv14mr7674368lab.30.1357755969946; Wed, 09 Jan 2013 10:26:09 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.112.81.194 with HTTP; Wed, 9 Jan 2013 10:26:09 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>    <50EB4E8B.30700@versi.edu.au>         
Date: Wed, 9 Jan 2013 13:26:09 -0500
X-Google-Sender-Auth: ly7KweMyFsaf3sqNbZty604yGGU
Message-ID: 
From: Barry Leiba 
To: Robert Sayre 
Content-Type: text/plain; charset=ISO-8859-1
Cc: IESG , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Wed, 09 Jan 2013 18:26:17 -0000

> Awesome news: JSON Patch has enough IESG votes to become a standards
> track document, even though JSON Pointer still has a discuss. This way
> of doing things is very efficient--lots of documents can be approved
> this way.

Sarcasm aside, you raise a good question, so let me explain:
We are, or at least we mostly try to be, more than just automata
blindly following process.  And so:

1. If there are documents that go together as a group, the responsible
AD (me, in this case) will usually not give the final approval for any
before they are all ready.  We did this recently with four EAI
documents (there were two with DISCUSS positions, and we held all four
back until everything was resolved), and we'll doing it again with the
six httpbis documents (I can't imagine giving final approval to, say,
four parts while two others sit in continued discussion).  We have a
status for this: "Approved, Point Raised".

2. Even if there are no DISCUSS positions held (as is now the case,
since Adrian cleared his this morning) we can and often do (and it's
certain that I will tomorrow) use the "Approved, Point Raised" status
to hold off the final approval until the responsible AD is satisfied
that everything's ready, to the extent that "everything" is ever ready
here.

3. And even if I should be inattentive or misguided enough to give the
final approval for Patch while still holding Pointer back for
discussion, because Patch has a normative reference to Pointer it will
not be published, and will wait in the RFC Editor queue in a "missing
reference" hold.

So just because a document meets the formal process criteria for
approval, we do use our judgment and try to do the right thing.
People will disagree about whether, in the end, the right thing has
been done, but nothing is automatic.

Barry

From sayrer@gmail.com  Wed Jan  9 10:32:06 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB50121F8472; Wed,  9 Jan 2013 10:32:05 -0800 (PST)
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 7gvvOrL0jIg7; Wed,  9 Jan 2013 10:32:05 -0800 (PST)
Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 0110F21F8CEC; Wed,  9 Jan 2013 10:32:04 -0800 (PST)
Received: by mail-wg0-f53.google.com with SMTP id fn15so1211981wgb.32 for ; Wed, 09 Jan 2013 10:32:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=10wCFSG4fOEwySUWjgMxssiPfg+xvQpvSv4w0fIv/TI=; b=vLtiz3JLsmbyPsr9hzf7N0+0XPQgqnwcrsbWZ8XCyDHVV0QE1B+8nVegi1fxHU2lqH R7/Fn6gPpTKRoqihYSMGNXO4Ed2gNolPK9Y3icp1Q3EI4alot4NZ3rqwt2adslRApWpj cQHyUe4HDsxWs0l71jHSYiLse+PNBmIzG2CJptS9wsbSXamz1ODKyDz2TfvRe7IqdZ+y 8mZcwpNWEu/9BN5szL189v8CbNy19PGCoXNYvNUh8f3MtfeOW1iaVk+Jrr3AQsPkwW0l HlyLk/afSpOxJfqoGSfELbj2VQ06RLqTQf4gkxm7iFrOgcUJ6r1+9IWCJXFOdrdW/DUQ ZCbQ==
MIME-Version: 1.0
X-Received: by 10.180.80.170 with SMTP id s10mr4444409wix.27.1357756323936; Wed, 09 Jan 2013 10:32:03 -0800 (PST)
Received: by 10.194.32.100 with HTTP; Wed, 9 Jan 2013 10:32:03 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>    <50EB4E8B.30700@versi.edu.au>          
Date: Wed, 9 Jan 2013 10:32:03 -0800
Message-ID: 
From: Robert Sayre 
To: Barry Leiba 
Content-Type: text/plain; charset=ISO-8859-1
Cc: IESG , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Wed, 09 Jan 2013 18:32:06 -0000

On Wed, Jan 9, 2013 at 10:26 AM, Barry Leiba  wrote:
>
> 2. Even if there are no DISCUSS positions held (as is now the case,
> since Adrian cleared his this morning) we can and often do (and it's
> certain that I will tomorrow) use the "Approved, Point Raised" status
> to hold off the final approval until the responsible AD is satisfied

Since you say it's certain, what is the reasoning? The WG seems
satisfied with their work.

- Rob

From barryleiba@gmail.com  Wed Jan  9 10:54:14 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6F121F8D49; Wed,  9 Jan 2013 10:54:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.201
X-Spam-Level: 
X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=-0.224, 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 InYdMWLPcrHK; Wed,  9 Jan 2013 10:54:12 -0800 (PST)
Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 98CC721F8C3C; Wed,  9 Jan 2013 10:54:10 -0800 (PST)
Received: by mail-lb0-f181.google.com with SMTP id ge1so1310571lbb.40 for ; Wed, 09 Jan 2013 10:54:09 -0800 (PST)
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=9X/elWmey/7pY4xgKE7vcoyl+Y6P8HFvml5l62/Ag2A=; b=ui0SnRXLQ6NJeUkaXXRpfubD5r1nJduDPtzy8w5qY8ivifZhIt1aZ0z3X1o4e8GlIK /NEYIMpw2sj4gssEdIVCCAXAUVFWh1OiNjBYQ6xSajimiFiZHYUVcNWljC+POS+yI7Py Coou3ZNEtkDpsB9+Qmnjzn0PhWZL5mCXgK2fZxtSzax+RO6DWL19ryNYUHMaZAyj797A 7QM7BCV8lY9cydUf0hBvxjvuyRtwriR+ymrO8HHKRHkXadRiOESi4ciapPw49lx1rQZE AZOwJYO/3pQCIXEDzQ6rBiXFwxLwYdFymqDQXYyNzgGMVpEhpJlFng2mozu/IiryOddN H9Lg==
MIME-Version: 1.0
Received: by 10.112.38.72 with SMTP id e8mr24040639lbk.123.1357757649033; Wed, 09 Jan 2013 10:54:09 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.112.81.194 with HTTP; Wed, 9 Jan 2013 10:54:08 -0800 (PST)
In-Reply-To: 
References: <20121211150057.28223.93310.idtracker@ietfa.amsl.com> <50cb04b9.86df440a.72fe.1e20SMTPIN_ADDED_BROKEN@mx.google.com>  <50cb5f3c.694c420a.38fb.39afSMTPIN_ADDED_BROKEN@mx.google.com>       <1357515310.6827.23.camel@polyglot>    <50EB4E8B.30700@versi.edu.au>           
Date: Wed, 9 Jan 2013 13:54:08 -0500
X-Google-Sender-Auth: 23ceqihlsuYH2gJLkiizVQsAYWM
Message-ID: 
From: Barry Leiba 
To: Robert Sayre 
Content-Type: text/plain; charset=ISO-8859-1
Cc: IESG , IETF Apps Discuss 
Subject: Re: [apps-discuss] Last Call:  (JSON Pointer) 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: Wed, 09 Jan 2013 18:54:15 -0000

>> 2. Even if there are no DISCUSS positions held (as is now the case,
>> since Adrian cleared his this morning) we can and often do (and it's
>> certain that I will tomorrow) use the "Approved, Point Raised" status
>> to hold off the final approval until the responsible AD is satisfied
>
> Since you say it's certain, what is the reasoning? The WG seems
> satisfied with their work.

I want to double-check a few things, first with the chairs and then
perhaps with the WG.  You'll probably see mail about it next week.

Barry

From superuser@gmail.com  Wed Jan  9 13:27:20 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002B821F8480 for ; Wed,  9 Jan 2013 13:27:19 -0800 (PST)
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 v7vXZlYKIFi1 for ; Wed,  9 Jan 2013 13:27:19 -0800 (PST)
Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0425221F8497 for ; Wed,  9 Jan 2013 13:27:18 -0800 (PST)
Received: by mail-lb0-f175.google.com with SMTP id gg13so1413411lbb.20 for ; Wed, 09 Jan 2013 13:27:15 -0800 (PST)
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=j4LPy5pHIaKoA+1o0u+NBAjPVnDPmVjY/iten4rDRm8=; b=IHWtsJLl7ocL024HbwHimNt8JCVJso25NTLXx5RPS7MGgPijuJHjQOrYY9dn3gXwcc Hq+j7DGgYc1b+SsDHBkfVJL7kbmrQ+7i0TBdg+nedjOqGZLBzOq5MHV8Qsj97IjTrb5P a8VyXWUYhwqUbAo52q8kdlyj4ESBSxoCar9XyCc+DkQgR2yuw8AsTkG65CkeS3ub/jcl kYX1JLRnnIRR6fLEYNxJciEmXZRQyDKXBsaYX6lsYIO89OoGl1X6irxPRhR/9XOqnHad Ygwq3+IP+M3qxTunW62dYNsUtHqcd3jBZ0Q5E05YvSSBQJhmoW/8cmnxANToMA77VTbe W0eA==
MIME-Version: 1.0
Received: by 10.112.87.104 with SMTP id w8mr28883527lbz.49.1357766834952; Wed, 09 Jan 2013 13:27:14 -0800 (PST)
Received: by 10.112.61.67 with HTTP; Wed, 9 Jan 2013 13:27:14 -0800 (PST)
Date: Wed, 9 Jan 2013 13:27:14 -0800
Message-ID: 
From: "Murray S. Kucherawy" 
To: IETF Apps Discuss 
Content-Type: multipart/alternative; boundary=bcaec554e0f6e29a9f04d2e1b9dd
Subject: [apps-discuss] draft-snell-merge-patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Jan 2013 21:27:20 -0000

--bcaec554e0f6e29a9f04d2e1b9dd
Content-Type: text/plain; charset=ISO-8859-1

APPSAWG,

I have a request to process the above draft through APPSAWG.  It is a small
document that has already received some review attention on the list, and
seems to be compatible with the two small JSON drafts we are already
processing (which are now in IESG Evaluation).

Can I get a sense of the group as to whether we want to handle this here,
probably briefly?  The alternative is to send it through as an AD-sponsored
individual submission, which is also fine; I'll shepherd it either way.

Opinions, please?

-MSK, APPSAWG co-chair

--bcaec554e0f6e29a9f04d2e1b9dd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


APPSAWG,

I have a request to process the above=
 draft through APPSAWG.=A0 It is a small document that has already received=
 some review attention on the list, and seems to be compatible with the two=
 small JSON drafts we are already processing (which are now in IESG Evaluat=
ion).


Can I get a sense of the group as to whether we want to handle this her=
e, probably briefly?=A0 The alternative is to send it through as an AD-spon=
sored individual submission, which is also fine; I'll shepherd it eithe=
r way.


Opinions, please?

-MSK, APPSAWG co-chair



--bcaec554e0f6e29a9f04d2e1b9dd--

From duerst@it.aoyama.ac.jp  Wed Jan  9 17:24:26 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651DC21F857B for ; Wed,  9 Jan 2013 17:24:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.417
X-Spam-Level: 
X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=-2.627, 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 f+Kh49nOi+wZ for ; Wed,  9 Jan 2013 17:24:25 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7B18B21F857A for ; Wed,  9 Jan 2013 17:24:24 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r0A1ONQY009764 for ; Thu, 10 Jan 2013 10:24:23 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 7ea7_4757_7711e71e_5ac4_11e2_8333_001d096c566a; Thu, 10 Jan 2013 10:24:22 +0900
Received: from [IPv6:::1] ([133.2.210.1]:48036) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 10 Jan 2013 10:24:25 +0900
Message-ID: <50EE1840.50804@it.aoyama.ac.jp>
Date: Thu, 10 Jan 2013 10:24:16 +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: "Murray S. Kucherawy" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] draft-snell-merge-patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Jan 2013 01:24:26 -0000

Fine with me.   Regards,   Martin.

On 2013/01/10 6:27, Murray S. Kucherawy wrote:
> APPSAWG,
>
> I have a request to process the above draft through APPSAWG.  It is a small
> document that has already received some review attention on the list, and
> seems to be compatible with the two small JSON drafts we are already
> processing (which are now in IESG Evaluation).
>
> Can I get a sense of the group as to whether we want to handle this here,
> probably briefly?  The alternative is to send it through as an AD-sponsored
> individual submission, which is also fine; I'll shepherd it either way.
>
> Opinions, please?
>
> -MSK, APPSAWG co-chair
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From lear@cisco.com  Thu Jan 10 04:50:16 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48DC21F879B; Thu, 10 Jan 2013 04:50:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level: 
X-Spam-Status: No, score=-110.598 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 dsulbJmNaoka; Thu, 10 Jan 2013 04:50:11 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 016F221F874F; Thu, 10 Jan 2013 04:50:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10120; q=dns/txt; s=iport; t=1357822210; x=1359031810; h=message-id:date:from:mime-version:to:subject; bh=lKGTD2dM3Xz8huteD+BKS5iRg9Dilx3zYN+kIIXlijc=; b=K8MISzfXhUbnSvebh5JU4JqoflofJGE2WDGJk32h9d2oLNN+0qjt+tZj uP4d0Mhiqdg6ZqZQ8rttden8J1wjc/aObJit2Xz/VIKgawhqyVFheA50u s+AzkVyY1nC3VVr/S9k15dx4mUm76iCO1N0Zxkr59EP2dUAkO1aDvSD9Z c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjEIAHi47lCQ/khM/2dsb2JhbABEg0eCcoVesVUWc4JIVTANFgsCCwMCAQIBSwEMCAEBiBUMpQ+PPoxcgzCBEwOSWYMzgRyPLYJ2
X-IronPort-AV: E=Sophos;i="4.84,443,1355097600"; d="scan'208,217";a="79655222"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 10 Jan 2013 12:50:08 +0000
Received: from dhcp-10-55-89-141.cisco.com (dhcp-10-55-89-141.cisco.com [10.55.89.141]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0ACo7Qm022946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jan 2013 12:50:08 GMT
Message-ID: <50EEB8FF.8080801@cisco.com>
Date: Thu, 10 Jan 2013 13:50:07 +0100
From: Eliot Lear 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: draft-laurie-pki-sunlight-05.all@tools.ietf.org, "apps-discuss@ietf.org" , "'IESG'" 
X-Enigmail-Version: 1.4.6
Content-Type: multipart/alternative; boundary="------------040200060705040409030300"
Subject: [apps-discuss] apps area review of draft-laurie-pki-sunlight-05 (Eliot's version)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Jan 2013 12:50:16 -0000

This is a multi-part message in MIME format.
--------------040200060705040409030300
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Gents,

Thanks for contributing an experimental doc to the IETF.

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).


Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-laurie-pki-sunlight-5
Title: Certificate Transparency
Reviewer: Eliot Lear
Review Date: 10 Jan 2012
IETF Last Call Date: 20 Dec. 2012

Summary: This document requires relatively minor revision prior to
publication.  Noting that its intended status is experimental, I've
focused on clarity of what problem is being solved and the clarity of
how it is being solved so that the experiment can be performed and
appropriate analysis performed.  In particular there seem to be two
goals: for an owner to monitor what certs have been signed for a given
subject, and for an auditor to review ALL certs on a log, perhaps
relevant to a particular CA or multiple CAs.  Anyway, get more clear
please in the beginning.

Major issues:

Note: I haven't tested your formal assertions in Section 3.  That's for
implementers of your specification.

Introduction:

I would prefer to see a clearer statement of the problem, such that it
is clear that the complexity of Merkle trees is warranted.  In the
absence of such a statement, a reference to something would suffice.  In
particular, how large a data set would alternatively be returned in a
linear fashion?  What is being optimized, and what is being traded off? 
I don't expect this is a major effort to correct, but it will be a major
flaw if it is not corrected (thus listed here).

Please include a reference to what you mean by Log or define it formally.

Minor issues:

Abstract:

Do you really mean "log signatures" in your last paragraph?  What if the
log itself has its private key stolen?

"Misissued" is not a word.  This might seem like a nit but you make it
quite hard for non-native speakers to understand what you are trying to
say when they can't use a dictionary to figure it out.

Introduction

Consider including an Existing Work subsection.

Section 2.1.1:

   In other words, the audit path consists of the list of
   missing nodes required to compute the nodes leading from a leaf to


Did you really mean "missing nodes" or just "nodes" or
"internal/interior nodes"?

In that section, more clearly define "m".

3. Log Format

   Anyone can submit certificates to certificate logs for public
   auditing, however, since certificates will not be accepted by clients
   unless logged, it is expected that certificate owners or their CAs
   will usually submit them.

This might be clear if we understood more clearly what problem you were
solving.  Also, fix the run-on sentence.

Section 3.1:

   Anyone can submit a certificate to any log.  In order to enable
   attribution of each logged certificate to its issuer, the log SHALL
   publish a list of acceptable root certificates (this list might
   usefully be the union of root certificates trusted by major browser
   vendors).

There is an implication that really authorization occurs through the
accepted list of CAs.  I don't know that you need to or want to state
the first sentence.  Rather you've provided a RESTful interface.  Why
not allow for appropriate HTTP/TLS authentication and leave it to
deployments?

Section 4

Please indicate the appropriate MIME type for responses (e.g., Accept:)
as well as for your POSTs.
Nits:

1. Informal introduction

Introduction is enough, unless you are going to have both a formal
introduction AND an informal introduction...

Please add a citation for Merkle Trees.  Here's one:
Merkle, R. "Secrecy, authentication and public key systems / A certified
digital signature". Ph.D. Dissertation, Stanford University, 1979.

Section  3 and elsewhere

Your formal description language requires a reference.



--------------040200060705040409030300
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    Gents,

    
    
Thanks for contributing an experimental doc to the IETF.

    
I have been selected as the Applications Area Directorate
      reviewer for this draft (for background on appsdir, please see ​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
      ).
    

    

      Please resolve these comments along with any other Last Call
      comments you may receive. Please wait for direction from your
      document shepherd or AD before posting a new version of the draft.

    
    Document: draft-laurie-pki-sunlight-5

    Title:
    
    Certificate Transparency

    Reviewer: Eliot Lear

    Review Date: 10 Jan 2012

    IETF Last Call Date: 20 Dec. 2012

    

    Summary: This document requires relatively minor revision prior to
    publication.  Noting that its intended status is experimental, I've
    focused on clarity of what problem is being solved and the clarity
    of how it is being solved so that the experiment can be performed
    and appropriate analysis performed.  In particular there seem to be
    two goals: for an owner to monitor what certs have been signed for a
    given subject, and for an auditor to review ALL certs on a log,
    perhaps relevant to a particular CA or multiple CAs.  Anyway, get
    more clear please in the beginning.

    

    Major issues:

    

    Note: I haven't tested your formal assertions in Section 3.  That's
    for implementers of your specification.

    

    Introduction:

    

    I would prefer to see a clearer statement of the problem, such that
    it is clear that the complexity of Merkle trees is warranted.  In
    the absence of such a statement, a reference to something would
    suffice.  In particular, how large a data set would alternatively be
    returned in a linear fashion?  What is being optimized, and what is
    being traded off?  I don't expect this is a major effort to correct,
    but it will be a major flaw if it is not corrected (thus listed
    here).

    

    Please include a reference to what you mean by Log or define it
    formally.

    

    Minor issues:

    

    Abstract:

    

    Do you really mean "log signatures" in your last paragraph?  What if
    the log itself has its private key stolen?

    

    "Misissued" is not a word.  This might seem like a nit but you make
    it quite hard for non-native speakers to understand what you are
    trying to say when they can't use a dictionary to figure it out.

    

    Introduction

    

    Consider including an Existing Work subsection.

    

    Section 2.1.1:

    

    
    
   In other words, the audit path consists of the list of
   missing nodes required to compute the nodes leading from a leaf to


    

    Did you really mean "missing nodes" or just "nodes" or
    "internal/interior nodes"?

    

    In that section, more clearly define "m".

    

    3. Log Format

    

    
   Anyone can submit certificates to certificate logs for public
   auditing, however, since certificates will not be accepted by clients
   unless logged, it is expected that certificate owners or their CAs
   will usually submit them.



    This might be clear if we understood more clearly what problem you
    were solving.  Also, fix the run-on sentence.

    

    Section 3.1:

    

    
    
   Anyone can submit a certificate to any log.  In order to enable
   attribution of each logged certificate to its issuer, the log SHALL
   publish a list of acceptable root certificates (this list might
   usefully be the union of root certificates trusted by major browser
   vendors).

    There is an implication that really authorization occurs through the
    accepted list of CAs.  I don't know that you need to or want to
    state the first sentence.  Rather you've provided a RESTful
    interface.  Why not allow for appropriate HTTP/TLS authentication
    and leave it to deployments?

    

    Section 4

    

    Please indicate the appropriate MIME type for responses (e.g.,
    Accept:) as well as for your POSTs.

    Nits:

    

    1. Informal introduction

    

    Introduction is enough, unless you are going to have both a formal
    introduction AND an informal introduction...

    

    Please add a citation for Merkle Trees.  Here's one:

    Merkle, R. "Secrecy, authentication and public key systems / A
    certified digital signature". Ph.D. Dissertation, Stanford
    University, 1979.

    

    Section  3 and elsewhere

    

    Your formal description language requires a reference.

    

    

  


--------------040200060705040409030300--

From James.H.Manger@team.telstra.com  Thu Jan 10 05:12:45 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB8C21F8844 for ; Thu, 10 Jan 2013 05:12:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[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 7vuId9TXS9Ki for ; Thu, 10 Jan 2013 05:12:44 -0800 (PST)
Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id D51EB21F84C2 for ; Thu, 10 Jan 2013 05:12:42 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.84,444,1355058000";  d="scan'208,217";a="113496863"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 11 Jan 2013 00:12:39 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6950"; a="105622570"
Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcdvi.tcif.telstra.com.au with ESMTP; 11 Jan 2013 00:12:37 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Fri, 11 Jan 2013 00:12:39 +1100
From: "Manger, James H" 
To: "Murray S. Kucherawy" , IETF Apps Discuss 
Date: Fri, 11 Jan 2013 00:12:35 +1100
Thread-Topic: [apps-discuss] draft-snell-merge-patch
Thread-Index: Ac3usCE19CPYJZQ8SlO45KI2AaxDnAAfQGow
Message-ID: <255B9BB34FB7D647A506DC292726F6E11504A34CCC@WSMSG3153V.srv.dir.telstra.com>
References: 
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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11504A34CCCWSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: Re: [apps-discuss] draft-snell-merge-patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Jan 2013 13:12:45 -0000

--_000_255B9BB34FB7D647A506DC292726F6E11504A34CCCWSMSG3153Vsrv_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

PiBwcm9jZXNzIHRoZSBhYm92ZSBkcmFmdCB0aHJvdWdoIEFQUFNBV0cNCg0KU291bmRzIGxpa2Ug
YSBnb29kIGlkZWEgdG8gbWUuIGRyYWZ0LXNuZWxsLW1lcmdlLXBhdGNoLTA4IGlzIGEgZGVjZW50
IHNwZWM7IGEgbmljZSBhZGp1bmN0IHRvIHRoZSBqc29uLXBhdGNoIHNwZWMuDQoNCi0tDQpKYW1l
cyBNYW5nZXINCg0KRnJvbTogYXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzph
cHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE11cnJheSBTLiBLdWNo
ZXJhd3kNClNlbnQ6IFRodXJzZGF5LCAxMCBKYW51YXJ5IDIwMTMgODoyNyBBTQ0KVG86IElFVEYg
QXBwcyBEaXNjdXNzDQpTdWJqZWN0OiBbYXBwcy1kaXNjdXNzXSBkcmFmdC1zbmVsbC1tZXJnZS1w
YXRjaA0KDQpBUFBTQVdHLA0KDQpJIGhhdmUgYSByZXF1ZXN0IHRvIHByb2Nlc3MgdGhlIGFib3Zl
IGRyYWZ0IHRocm91Z2ggQVBQU0FXRy4gIEl0IGlzIGEgc21hbGwgZG9jdW1lbnQgdGhhdCBoYXMg
YWxyZWFkeSByZWNlaXZlZCBzb21lIHJldmlldyBhdHRlbnRpb24gb24gdGhlIGxpc3QsIGFuZCBz
ZWVtcyB0byBiZSBjb21wYXRpYmxlIHdpdGggdGhlIHR3byBzbWFsbCBKU09OIGRyYWZ0cyB3ZSBh
cmUgYWxyZWFkeSBwcm9jZXNzaW5nICh3aGljaCBhcmUgbm93IGluIElFU0cgRXZhbHVhdGlvbiku
DQoNCkNhbiBJIGdldCBhIHNlbnNlIG9mIHRoZSBncm91cCBhcyB0byB3aGV0aGVyIHdlIHdhbnQg
dG8gaGFuZGxlIHRoaXMgaGVyZSwgcHJvYmFibHkgYnJpZWZseT8gIFRoZSBhbHRlcm5hdGl2ZSBp
cyB0byBzZW5kIGl0IHRocm91Z2ggYXMgYW4gQUQtc3BvbnNvcmVkIGluZGl2aWR1YWwgc3VibWlz
c2lvbiwgd2hpY2ggaXMgYWxzbyBmaW5lOyBJJ2xsIHNoZXBoZXJkIGl0IGVpdGhlciB3YXkuDQpP
cGluaW9ucywgcGxlYXNlPw0KDQotTVNLLCBBUFBTQVdHIGNvLWNoYWlyDQo=

--_000_255B9BB34FB7D647A506DC292726F6E11504A34CCCWSMSG3153Vsrv_
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
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu
MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu
V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx
MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg
Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1F
Ti1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs
YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZndDsgPC9zcGFuPnByb2Nlc3Mg
dGhlIGFib3ZlIGRyYWZ0IHRocm91Z2ggQVBQU0FXRzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z
b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Tb3VuZHMgbGlrZSBh
IGdvb2QgaWRlYSB0byBtZS4gZHJhZnQtc25lbGwtbWVyZ2UtcGF0Y2gtMDggaXMgYSBkZWNlbnQg
c3BlYzsgYSBuaWNlIGFkanVuY3QgdG8gdGhlIGpzb24tcGF0Y2ggc3BlYy48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx
RjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
O2NvbG9yOiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz
cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw
dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt
Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwv
Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU
YWhvbWEiLCJzYW5zLXNlcmlmIic+IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWls
dG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+TXVy
cmF5IFMuIEt1Y2hlcmF3eTxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIDEwIEphbnVhcnkgMjAx
MyA4OjI3IEFNPGJyPjxiPlRvOjwvYj4gSUVURiBBcHBzIERpc2N1c3M8YnI+PGI+U3ViamVjdDo8
L2I+IFthcHBzLWRpc2N1c3NdIGRyYWZ0LXNuZWxsLW1lcmdlLXBhdGNoPG86cD48L286cD48L3Nw
YW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv
cD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBw
dCc+QVBQU0FXRyw8YnI+PGJyPkkgaGF2ZSBhIHJlcXVlc3QgdG8gcHJvY2VzcyB0aGUgYWJvdmUg
ZHJhZnQgdGhyb3VnaCBBUFBTQVdHLiZuYnNwOyBJdCBpcyBhIHNtYWxsIGRvY3VtZW50IHRoYXQg
aGFzIGFscmVhZHkgcmVjZWl2ZWQgc29tZSByZXZpZXcgYXR0ZW50aW9uIG9uIHRoZSBsaXN0LCBh
bmQgc2VlbXMgdG8gYmUgY29tcGF0aWJsZSB3aXRoIHRoZSB0d28gc21hbGwgSlNPTiBkcmFmdHMg
d2UgYXJlIGFscmVhZHkgcHJvY2Vzc2luZyAod2hpY2ggYXJlIG5vdyBpbiBJRVNHIEV2YWx1YXRp
b24pLjxicj48YnI+Q2FuIEkgZ2V0IGEgc2Vuc2Ugb2YgdGhlIGdyb3VwIGFzIHRvIHdoZXRoZXIg
d2Ugd2FudCB0byBoYW5kbGUgdGhpcyBoZXJlLCBwcm9iYWJseSBicmllZmx5PyZuYnNwOyBUaGUg
YWx0ZXJuYXRpdmUgaXMgdG8gc2VuZCBpdCB0aHJvdWdoIGFzIGFuIEFELXNwb25zb3JlZCBpbmRp
dmlkdWFsIHN1Ym1pc3Npb24sIHdoaWNoIGlzIGFsc28gZmluZTsgSSdsbCBzaGVwaGVyZCBpdCBl
aXRoZXIgd2F5LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n
bWFyZ2luLWJvdHRvbToxMi4wcHQnPk9waW5pb25zLCBwbGVhc2U/PGJyPjxicj4tTVNLLCBBUFBT
QVdHIGNvLWNoYWlyPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRt
bD4=

--_000_255B9BB34FB7D647A506DC292726F6E11504A34CCCWSMSG3153Vsrv_--

From superuser@gmail.com  Thu Jan 10 07:39:17 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C065521F87B9 for ; Thu, 10 Jan 2013 07:39:17 -0800 (PST)
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 Gzd01+NjQw3P for ; Thu, 10 Jan 2013 07:39:15 -0800 (PST)
Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) by ietfa.amsl.com (Postfix) with ESMTP id 17BD421F87B2 for ; Thu, 10 Jan 2013 07:39:14 -0800 (PST)
Received: by mail-la0-f41.google.com with SMTP id em20so754152lab.28 for ; Thu, 10 Jan 2013 07:39:13 -0800 (PST)
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=EYbdn19XwHuWoALZW+hq3qAtUu3hfFV2Ib9RRpmQC8Q=; b=cLcpT0KtRFeXee8Yc6BeYOtpyK5+4n6gIIUygwzOBBamczLRlYt5LkXuuDX13VOHXh alpTdQOkwItUstIWtWba/fSqjU9t8a0vItxCUrZGJHzJz6pDke6oxVeIH3fH5xt93TXR XCaqaNoJMEdv44H3JVpe3bBBZkuIjJk5A8qvwy7tHDPCOJsNkD0sTWpTKI79YGUi0pUv bvyWN6O/Ijjs2kPlAa3T/O7INrkKweEzFg0jcjy15VyeNo2cLBUBWLIK7lVqIgg+2/ke JtXOrxHQS/cNwxpBM2utVruMo60Kd1ecaqpUFEurDNYLlD+G98EJ7envTK9TOoiDFC+A eK6A==
MIME-Version: 1.0
Received: by 10.152.144.130 with SMTP id sm2mr69541214lab.49.1357832353599; Thu, 10 Jan 2013 07:39:13 -0800 (PST)
Received: by 10.112.61.67 with HTTP; Thu, 10 Jan 2013 07:39:13 -0800 (PST)
Date: Thu, 10 Jan 2013 07:39:13 -0800
Message-ID: 
From: "Murray S. Kucherawy" 
To: IETF Apps Discuss 
Content-Type: multipart/alternative; boundary=e89a8f2348a919cf6004d2f0fbaf
Subject: [apps-discuss] IETF 86 agenda items
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Jan 2013 15:39:18 -0000

--e89a8f2348a919cf6004d2f0fbaf
Content-Type: text/plain; charset=ISO-8859-1

Colleagues,

I've just made our usual request for a 2.5-hour meeting first thing on the
Monday morning of IETF 86, coinciding with the APPAREA meeting.

If you wish to make a presentation, please send a note as soon as possible
to appsawg-chairs@tools.ietf.org including the topic and the amount of time
you would like.  We may also invite specific people to present on topics of
particular interest.  It's also common for us to reach out to BoF chairs
and chairs of new working groups to give short presentations.

The due date for us to submit preliminary agendas is February 27th, so we
have some time.  However, you SHOULD NOT wait until the last minute to send
us your request.  Ours is usually a packed schedule and it is very
difficult to accommodate all requests, much less last-minute ones.

Thanks,
-MSK, APPSAWG co-chair

--e89a8f2348a919cf6004d2f0fbaf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Colleagues,

I've just made our usual =
request for a 2.5-hour meeting first thing on the Monday morning of IETF 86=
, coinciding with the APPAREA meeting.

If you wish to make a p=
resentation, please send a note as soon as possible to appsawg-chairs@tools.ietf.org including th=
e topic and the amount of time you would like.=A0 We may also invite specif=
ic people to present on topics of particular interest.=A0 It's also com=
mon for us to reach out to BoF chairs and chairs of new working groups to g=
ive short presentations.


The due date for us to submit preliminary agendas is February 27th, so =
we have some time.=A0 However, you SHOULD NOT wait until the last minute to=
 send us your request.=A0 Ours is usually a packed schedule and it is very =
difficult to accommodate all requests, much less last-minute ones.


Thanks,
-MSK, APPSAWG co-chair



--e89a8f2348a919cf6004d2f0fbaf--

From vkg@bell-labs.com  Thu Jan 10 08:30:26 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7003F21F8930; Thu, 10 Jan 2013 08:30:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.274
X-Spam-Level: 
X-Spam-Status: No, score=-107.274 tagged_above=-999 required=5 tests=[AWL=-0.675, 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 9Rbx5m5ljijm; Thu, 10 Jan 2013 08:30:25 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB3A21F892F; Thu, 10 Jan 2013 08:30:25 -0800 (PST)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r0AGUMgQ019893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Jan 2013 10:30:23 -0600 (CST)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r0AGULAA026725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Jan 2013 10:30:22 -0600
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r0AGULoK023424; Thu, 10 Jan 2013 10:30:21 -0600 (CST)
Message-ID: <50EEED15.5080508@bell-labs.com>
Date: Thu, 10 Jan 2013 10:32:21 -0600
From: "Vijay K. Gurbani" 
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org" , draft-ietf-avtcore-srtp-encrypted-header-ext@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Cc: IESG IESG 
Subject: [apps-discuss] APPSDIR review of draft-ietf-avtcore-srtp-encrypted-header-ext-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Jan 2013 16:30:26 -0000

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-avtcore-srtp-encrypted-header-ext-04
Title: Encryption of Header Extensions in the Secure Real-Time Transport
        Protocol (SRTP)
Reviewer: Vijay K. Gurbani
Review Date: Jan-10-2013
IETF Last Call Date: Jan-17-2013
IESG Telechat Date: Not known

Summary: This draft is ready for publication as an Proposed Standard.

Major issues: 0
Minor issues: 0
Major issues: 0

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/

From ted.ietf@gmail.com  Fri Jan 11 10:25:11 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECB321F884A; Fri, 11 Jan 2013 10:25:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.059
X-Spam-Level: 
X-Spam-Status: No, score=-3.059 tagged_above=-999 required=5 tests=[AWL=0.540,  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 5olNvMbm8mt0; Fri, 11 Jan 2013 10:25:09 -0800 (PST)
Received: from mail-ia0-f175.google.com (mail-ia0-f175.google.com [209.85.210.175]) by ietfa.amsl.com (Postfix) with ESMTP id E6C7921F8749; Fri, 11 Jan 2013 10:25:08 -0800 (PST)
Received: by mail-ia0-f175.google.com with SMTP id 21so1773734iay.20 for ; Fri, 11 Jan 2013 10:25:08 -0800 (PST)
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=+3sTxCMvlWHlEpjmeW/fOt/AtA2jav8N1AJeHlbiNcc=; b=zYiaZplFNTm4fZC+NzAHsblyafoVH2FmeMZKduhrvj8+VFbHnZglqVZ7swkw+FQlfz Mkg9TdM/Abold89GX2kFF9PuyYvxj3jh1jsNq/jBONMyPiMzSW0iGLFNsD02FojKNI0e xJIpGZ7ASucJxC3LaLGSuZiLEuS6aslyD54NfdiQX5vYl9Efr26e+czK06WdR9uOJMsy LRle1LSi6DanAohp2A71gG9vDVMNPy4P9VWKvmZwFR7buKyb/HSVL+4hspbRWPmnQ4Vx lMNuNI9e7wrBrpiOnXLntmYAyQ3CWi0aE+wSDGjyg3E6CT2e84hwsCco2AiSoG12K1v5 ij6w==
MIME-Version: 1.0
Received: by 10.42.48.147 with SMTP id s19mr57286984icf.18.1357928708259; Fri, 11 Jan 2013 10:25:08 -0800 (PST)
Received: by 10.43.94.5 with HTTP; Fri, 11 Jan 2013 10:25:08 -0800 (PST)
Date: Fri, 11 Jan 2013 10:25:08 -0800
Message-ID: 
From: Ted Hardie 
To: apps-discuss@ietf.org,  draft-ietf-6man-ipv6-atomic-fragments.all@tools.ietf.org,  IESG 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [apps-discuss] Applications Directorate review of draft-ietf-6man-ipv6-atomic-fragments-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, 11 Jan 2013 18:25:11 -0000

Document:draft-ietf-6man-ipv6-atomic-fragments-03
Title: Processing of IPv6 "atomic" fragments
Reviewer: Ted Hardie
Review Date: January 11, 2012
IETF Last Call Date:January 2, 2012

Summary: This document sets out the problem and solution clearly and
succinctly, and I believe it
                   is ready for publication as a Standards Track RFC.

Major Issues: None seen.

Minor Issues: None seen.

Nits: Other than those raised by Ray Hunter, I would suggest dropping
Appendix A on publication.
         The list of operating systems tested is not comprehensive,
and the information will (hopefully)
          quickly become stale.  This is, however, largely a stylistic
choice, hence its classification as
          a nit. .

From dret@berkeley.edu  Sat Jan 12 05:48:04 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBEA21F850C for ; Sat, 12 Jan 2013 05:48:04 -0800 (PST)
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 7u-rWftLKgGf for ; Sat, 12 Jan 2013 05:48:03 -0800 (PST)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7FB21F84CA for ; Sat, 12 Jan 2013 05:48:03 -0800 (PST)
Received: from 91-66-137-169-dynip.superkabel.de ([91.66.137.169] helo=dretair.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1Tu1RG-0006O5-Ey; Sat, 12 Jan 2013 05:48:01 -0800
Message-ID: <50F16991.6060909@berkeley.edu>
Date: Sat, 12 Jan 2013 14:48:01 +0100
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org application-layer protocols" ,  REST Discuss , LDP WG 
References: <20130112134425.7207.30058.idtracker@ietfa.amsl.com>
In-Reply-To: <20130112134425.7207.30058.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20130112134425.7207.30058.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Michael Hausenblas , Jeni Tennison 
Subject: [apps-discuss] New Version Notification for draft-hausenblas-csv-fragment-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: Sat, 12 Jan 2013 13:48:04 -0000

A new version of I-D, draft-hausenblas-csv-fragment-02.txt
has been successfully submitted by Erik Wilde and posted to the
IETF repository.

Filename:	 draft-hausenblas-csv-fragment
Revision:	 02
Title:		 URI Fragment Identifiers for the text/csv Media Type
Creation date:	 2013-01-12
WG ID:		 Individual Submission
Number of pages: 11
URL: 
http://www.ietf.org/internet-drafts/draft-hausenblas-csv-fragment-02.txt
Status: 
http://datatracker.ietf.org/doc/draft-hausenblas-csv-fragment
Htmlized:        http://tools.ietf.org/html/draft-hausenblas-csv-fragment-02
Diff: 
http://www.ietf.org/rfcdiff?url2=draft-hausenblas-csv-fragment-02

Abstract:
    This memo defines URI fragment identifiers for text/csv MIME
    entities.  These fragment identifiers make it possible to refer to
    parts of a text/csv MIME entity, identified by row, column, or cell.
    Fragment identification can use single items, or ranges.

Note to Readers

    This draft should be discussed on the apps-discuss mailing list [1].
    Online access to all versions and files is available at github [2].

[1] https://www.ietf.org/mailman/listinfo/apps-discuss
[2] https://github.com/dret/I-D/tree/master/csv-fragment

From andy@hxr.us  Sun Jan 13 07:29:50 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7BA21F86C9 for ; Sun, 13 Jan 2013 07:29:50 -0800 (PST)
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 DtYwMvZeqwRk for ; Sun, 13 Jan 2013 07:29:49 -0800 (PST)
Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by ietfa.amsl.com (Postfix) with ESMTP id 95F6D21F86BC for ; Sun, 13 Jan 2013 07:29:49 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id x48so1626832wey.8 for ; Sun, 13 Jan 2013 07:29:48 -0800 (PST)
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=kluyQg4KYRmZTMm9xYGXXqYuMiJ16C4K2p+toAwif9g=; b=mjPW6uk5wczJr2wOV3+NeE7T27KcdTufXy+La9bF17l/kf2D2291/w3iV3qtohRm0d I/cAgmUDvBvqhJRzFbajlr4FmTXaVsF37VGdfDbAWQ5z7siDT0E1HM0iCGTFRLf7Wawy WpWAiR3Rv6m4DjE4zuzQBkkyYxVJ+vsezwhtJvhFu63/ZxFtu5ptypHrD0bUqQiItOgy Q2JW9VH64UrGyBNObSUMNiXxJs/55zUb0iA04H99W2YmYKNY4j1OacvEWMifNLEl79ua HFSNmk5kEow9r5PG6eR9o+9x4EruDtW3RdBsSFgkfGtchyycmEV7tjSAkuZcEe9JUkKv fpkA==
MIME-Version: 1.0
Received: by 10.181.13.75 with SMTP id ew11mr8200361wid.9.1358090988769; Sun, 13 Jan 2013 07:29:48 -0800 (PST)
Received: by 10.216.6.86 with HTTP; Sun, 13 Jan 2013 07:29:48 -0800 (PST)
X-Originating-IP: [71.191.219.28]
Date: Sun, 13 Jan 2013 10:29:48 -0500
Message-ID: 
From: Andrew Newton 
To: "apps-discuss@ietf.org" 
Content-Type: multipart/alternative; boundary=f46d04388e1bf552cd04d32d324d
X-Gm-Message-State: ALoCoQkMPc7K0FTmKuDMINXPKnKwlr+j6Z/TTNGk5oEZzLUeAd16Mw5GPOf0x6uv2ziHPtNLwN2o
Subject: [apps-discuss] New Version Notification for draft-newton-json-content-rules-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: Sun, 13 Jan 2013 15:29:50 -0000

--f46d04388e1bf552cd04d32d324d
Content-Type: text/plain; charset=ISO-8859-1

Abstract:
   This document describes a language useful for documenting the
   expected content of JSON structures found in specifications using
   JSON.

This version adds ABNF provided by Byron Ellacott and a section about root
rules.

Filename: draft-newton-json-content-rules
Revision: 01
Title: A Language for Rules Describing JSON Content
Creation date: 2013-01-13
WG ID: Individual Submission
Number of pages: 32
URL:
http://www.ietf.org/internet-drafts/draft-newton-json-content-rules-01.txt
Status:
http://datatracker.ietf.org/doc/draft-newton-json-content-rules
Htmlized:
http://tools.ietf.org/html/draft-newton-json-content-rules-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-newton-json-content-rules-01

--f46d04388e1bf552cd04d32d324d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Abstract:
=A0 =A0This document describ=
es a language useful for documenting the
=A0 =A0expected content =
of JSON structures found in specifications using
=A0 =A0JSON.


This version adds ABNF provided by Byron Ellacott and =
a section about root rules.

Filename:	 draft-newton-json-content-rules

Revision:	 01
<=
div>Title:		 A Language f=
or Rules Describing JSON Content
Creation date:	 2013-01-13


WG ID:		 Individual =
Submission
Number of pages: 32







--f46d04388e1bf552cd04d32d324d--

From dret@berkeley.edu  Mon Jan 14 02:09:49 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD91921F88E1 for ; Mon, 14 Jan 2013 02:09:48 -0800 (PST)
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 rLjYfAwZPGyA for ; Mon, 14 Jan 2013 02:09:48 -0800 (PST)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 050F221F88BD for ; Mon, 14 Jan 2013 02:09:48 -0800 (PST)
Received: from 91-66-137-169-dynip.superkabel.de ([91.66.137.169] helo=dretair.local) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TugzB-0000yl-M6; Mon, 14 Jan 2013 02:09:47 -0800
Message-ID: <50F3D96F.3090705@berkeley.edu>
Date: Mon, 14 Jan 2013 11:09:51 +0100
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org application-layer protocols" 
References: <20130114100538.5686.34264.idtracker@ietfa.amsl.com>
In-Reply-To: <20130114100538.5686.34264.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20130114100538.5686.34264.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: REST Discuss 
Subject: [apps-discuss] Fwd: New Version Notification for draft-wilde-xml-patch-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, 14 Jan 2013 10:09:49 -0000

A new version of I-D, draft-wilde-xml-patch-00.txt has been successfully 
submitted by Erik Wilde and posted to the IETF repository.

Filename:	 draft-wilde-xml-patch
Revision:	 00
Title:		 A Media Type for XML Patch Operations
Creation date:	 2013-01-14
WG ID:		 Individual Submission
Number of pages: 9
URL: 
http://www.ietf.org/internet-drafts/draft-wilde-xml-patch-00.txt
Status:          http://datatracker.ietf.org/doc/draft-wilde-xml-patch
Htmlized:        http://tools.ietf.org/html/draft-wilde-xml-patch-00


Abstract:
    The XML Patch media type "application/xml-patch" defines an XML
    document structure for expressing a sequence of patch operations that
    are applied to an XML document.  The XML Patch document format's
    foundations are defined in RFC 5261, this specification defines a
    document format and a media type registration, so that XML Patch
    documents can be labeled with a media type, for example in HTTP
    conversations.

Note to Readers

    This draft should be discussed on the apps-discuss mailing list [8].
    Online access to all versions and files is available at github [9].

    [8]  https://www.ietf.org/mailman/listinfo/apps-discuss
    [9]  https://github.com/dret/I-D/tree/master/xml-patch

From Peter.Rushforth@NRCan-RNCan.gc.ca  Mon Jan 14 07:41:11 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C55421F8930 for ; Mon, 14 Jan 2013 07:41:11 -0800 (PST)
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 L+y4GtU0qW-I for ; Mon, 14 Jan 2013 07:41:11 -0800 (PST)
Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id B086321F88E6 for ; Mon, 14 Jan 2013 07:41:09 -0800 (PST)
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.4; Mon, 14 Jan 2013 10:41:07 -0500
Received: from S-BSC-MBX1.nrn.nrcan.gc.ca ([169.254.1.98]) by S-BSC-CAS2.nrn.nrcan.gc.ca ([fe80::48d4:f168:78ba:d4e8%19]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 10:41:07 -0500
From: "Rushforth, Peter" 
To: "apps-discuss@ietf.org" 
Thread-Topic: Re: New Version Notification for draft-wilde-xml-patch-00.txt
Thread-Index: Ac3ybZD+3ia0sCpESBu6ZGtR1ihclg==
Date: Mon, 14 Jan 2013 15:41:06 +0000
Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF2495A4A7@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] New Version Notification for draft-wilde-xml-patch-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, 14 Jan 2013 15:41:11 -0000

Hi Erik and Mark,

Why is the media type
 application/xml-patch and not something along the lines of application/xml=
-patch+xml ?


Thanks,
Peter Rushforth


From jasnell@gmail.com  Mon Jan 14 07:44:37 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D59921F8770 for ; Mon, 14 Jan 2013 07:44:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.845
X-Spam-Level: 
X-Spam-Status: No, score=-4.845 tagged_above=-999 required=5 tests=[AWL=-1.247, 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 6IzLXEnKX2Pa for ; Mon, 14 Jan 2013 07:44:36 -0800 (PST)
Received: from mail-ia0-f178.google.com (mail-ia0-f178.google.com [209.85.210.178]) by ietfa.amsl.com (Postfix) with ESMTP id B718C21F8609 for ; Mon, 14 Jan 2013 07:44:36 -0800 (PST)
Received: by mail-ia0-f178.google.com with SMTP id k25so3650051iah.23 for ; Mon, 14 Jan 2013 07:44:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=AZ3XZUSZdTQqBjj/mu1s6PKf+HKkZQ3DDed+s3bKBR0=; b=uqtYHLbPx3rHLqGNyYowjxVbmIbL7udnljrn0mRWlOCr1LmnMTUgWwjjt0DUnhrnhV wzHGBv14fKeri+SckIzhpIr2PXN9y7704QzzBYKHia/ipew32Fyle2laYkxj0no+rFZB tpIIDa24t9429d/wd3xQDVnLHrXeFs+kfZMDyfupgWbE52Snw44bzJ63z4ZRoSQKB3AV NCUe2l5a2Ctm615M1mlvorpla3D88KrJyvvXe8I8GcZMA9M/MEIGHVxgckL36N8EEFMI MZS/9koiJU90MwGAUdiSBz8OnAkapLfbT20T2LQQ/bvsXU+Dm872yRBwtdw3eSGCxUxz d8eQ==
X-Received: by 10.50.219.233 with SMTP id pr9mr7137966igc.19.1358178270964; Mon, 14 Jan 2013 07:44:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.26.137 with HTTP; Mon, 14 Jan 2013 07:44:10 -0800 (PST)
In-Reply-To: <1CD55F04538DEA4F85F3ADF7745464AF2495A4A7@S-BSC-MBX1.nrn.nrcan.gc.ca>
References: <1CD55F04538DEA4F85F3ADF7745464AF2495A4A7@S-BSC-MBX1.nrn.nrcan.gc.ca>
From: James M Snell 
Date: Mon, 14 Jan 2013 07:44:10 -0800
Message-ID: 
To: "Rushforth, Peter" 
Content-Type: multipart/alternative; boundary=14dae934120f61eb1504d3418593
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] New Version Notification for draft-wilde-xml-patch-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, 14 Jan 2013 15:44:37 -0000

--14dae934120f61eb1504d3418593
Content-Type: text/plain; charset=UTF-8

Because xml-patch+xml is just silly? ;-)

To be serious, I have to assume that it's to maintain consistency with some
of the other patch formats that are on the table (e.g.
application/json-patch, application/json-merge-patch,
application/json-test-patch, etc)

- James


On Mon, Jan 14, 2013 at 7:41 AM, Rushforth, Peter <
Peter.Rushforth@nrcan-rncan.gc.ca> wrote:

> Hi Erik and Mark,
>
> Why is the media type
>  application/xml-patch and not something along the lines of
> application/xml-patch+xml ?
>
>
> Thanks,
> Peter Rushforth
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--14dae934120f61eb1504d3418593
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Because xml-patch+xml=
 is just silly? ;-)=C2=A0

To be serious, I have to assume that it's to maint=
ain consistency with some of the other patch formats that are on the table =
(e.g. application/json-patch, application/json-merge-patch, application/jso=
n-test-patch, etc)




- James


On Mon, Jan 14, 2013 a=
t 7:41 AM, Rushforth, Peter <Peter.Rushforth@nrcan-rncan.g=
c.ca> wrote:



Hi Erik and Mark,



Why is the media type

=C2=A0application/xml-patch and not something along the lines of applicatio=
n/xml-patch+xml ?





Thanks,

Peter Rushforth




_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--14dae934120f61eb1504d3418593--

From julian.reschke@gmx.de  Mon Jan 14 07:56:09 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F67D21F891A for ; Mon, 14 Jan 2013 07:56:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.556
X-Spam-Level: 
X-Spam-Status: No, score=-104.556 tagged_above=-999 required=5 tests=[AWL=-1.957, 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 9fib3pDdaqCV for ; Mon, 14 Jan 2013 07:56:08 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 7211821F88C8 for ; Mon, 14 Jan 2013 07:56:08 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.32]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MMZH6-1Ts2Z71dV8-008FXT for ; Mon, 14 Jan 2013 16:56:07 +0100
Received: (qmail invoked by alias); 14 Jan 2013 15:56:07 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.104]) [217.91.35.233] by mail.gmx.net (mp032) with SMTP; 14 Jan 2013 16:56:07 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+ouqxLoiiofuHHGj1/CMsajbye8hF/NmGZNuyb/9 4eRqZIx7QgtmM+
Message-ID: <50F42A91.4050302@gmx.de>
Date: Mon, 14 Jan 2013 16:56:01 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: James M Snell 
References: <1CD55F04538DEA4F85F3ADF7745464AF2495A4A7@S-BSC-MBX1.nrn.nrcan.gc.ca> 
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] New Version Notification for draft-wilde-xml-patch-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, 14 Jan 2013 15:56:09 -0000

On 2013-01-14 16:44, James M Snell wrote:
> Because xml-patch+xml is just silly? ;-)
>
> To be serious, I have to assume that it's to maintain consistency with
> some of the other patch formats that are on the table (e.g.
> application/json-patch, application/json-merge-patch,
> application/json-test-patch, etc)

So for consistency with formats where we could ask the same question?

Best regards, Julian


From dret@berkeley.edu  Mon Jan 14 08:03:59 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E7B21F86C1 for ; Mon, 14 Jan 2013 08:03:59 -0800 (PST)
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 5k5eWwoBezQU for ; Mon, 14 Jan 2013 08:03:58 -0800 (PST)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3C221F86BA for ; Mon, 14 Jan 2013 08:03:58 -0800 (PST)
Received: from 91-66-137-169-dynip.superkabel.de ([91.66.137.169] helo=dretair.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TumVs-000222-BQ; Mon, 14 Jan 2013 08:03:58 -0800
Message-ID: <50F42C62.1080002@berkeley.edu>
Date: Mon, 14 Jan 2013 17:03:46 +0100
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
References: <1CD55F04538DEA4F85F3ADF7745464AF2495A4A7@S-BSC-MBX1.nrn.nrcan.gc.ca> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] New Version Notification for draft-wilde-xml-patch-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, 14 Jan 2013 16:03:59 -0000

hello peter.


On 2013-01-14 16:44 , James M Snell wrote:
>> On Mon, Jan 14, 2013 at 7:41 AM, Rushforth, Peter
>> > > wrote:
>>     Why is the media type
>>       application/xml-patch and not something along the lines of
>>     application/xml-patch+xml ?
> Because xml-patch+xml is just silly? ;-)
> To be serious, I have to assume that it's to maintain consistency with
> some of the other patch formats that are on the table (e.g.
> application/json-patch, application/json-merge-patch,
> application/json-test-patch, etc)

yes, that's the reason. for now, we have decided to follow this naming 
pattern of media types already under development. also, 
application/xml-patch+xml does indeed look a bit strange and doesn't buy 
you much (unless the "we should have a media subtype suffix registry" 
movement picks up steam). changing the media type's name of course would 
be trivial.

cheers,

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 dret@berkeley.edu  Mon Jan 14 08:16:10 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E6A21F8959 for ; Mon, 14 Jan 2013 08:16:10 -0800 (PST)
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 gQTiStEVviyU for ; Mon, 14 Jan 2013 08:16:10 -0800 (PST)
Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id EC1E921F8824 for ; Mon, 14 Jan 2013 08:16:09 -0800 (PST)
Received: from 91-66-137-169-dynip.superkabel.de ([91.66.137.169] helo=dretair.local) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1Tumhf-0002cQ-IQ; Mon, 14 Jan 2013 08:16:09 -0800
Message-ID: <50F42F3E.9030401@berkeley.edu>
Date: Mon, 14 Jan 2013 17:15:58 +0100
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Julian Reschke , James M Snell 
References: <1CD55F04538DEA4F85F3ADF7745464AF2495A4A7@S-BSC-MBX1.nrn.nrcan.gc.ca>  <50F42A91.4050302@gmx.de>
In-Reply-To: <50F42A91.4050302@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] New Version Notification for draft-wilde-xml-patch-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, 14 Jan 2013 16:16:10 -0000

hello julian.

On 2013-01-14 16:56 , Julian Reschke wrote:
> On 2013-01-14 16:44, James M Snell wrote:
>> To be serious, I have to assume that it's to maintain consistency with
>> some of the other patch formats that are on the table (e.g.
>> application/json-patch, application/json-merge-patch,
>> application/json-test-patch, etc)
> So for consistency with formats where we could ask the same question?

yes, that's one way to look at it. personally, i mostly care about a 
format and a name being defined and registered; what the name should 
look like is not absolutely essential. it would be nice, though, if 
patch formats would be named a bit consistently, and that's the 
motivation for the current name. i cannot remember seeing a debate 
around the other names, and maybe there should be one so that when RDF 
comes along with a patch model that can be serialized in a variety of 
ways, there's some guidance on how these ways should be named.

cheers,

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 jasnell@gmail.com  Mon Jan 14 08:47:31 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573F821F86C8 for ; Mon, 14 Jan 2013 08:47:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.776
X-Spam-Level: 
X-Spam-Status: No, score=-4.776 tagged_above=-999 required=5 tests=[AWL=-1.178, 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 tGfl4KznvDTw for ; Mon, 14 Jan 2013 08:47:30 -0800 (PST)
Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7223B21F8546 for ; Mon, 14 Jan 2013 08:47:30 -0800 (PST)
Received: by mail-ie0-f177.google.com with SMTP id k13so5078549iea.8 for ; Mon, 14 Jan 2013 08:47:30 -0800 (PST)
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=Vf0LCgxM2FpvU6M/SY0AQkpdv1+L8bbyX5GfV4crjUY=; b=Yf0RCcvuy5dwkXyQt9Pqx+IbWnQKspdUGAHg4ObcCbF6cqgLmxpFf7mHoRSyLqx/Dz +jaUsWprhQZWwcyFkih0HAT609oPCUsuL8Rm1WkOxaBm5XjAgb7RL2g8koxhMF53eNOv FOPpD+sMA9ECtWBcvHHQNgnXBVRrMoZHEbjRVjyaLtM+NzbIkLLum/laIZz+8EPz1D0A OHbTFP/s0zq5LX5j6nIWMM7HCTbgjdeA4QuvQ0SEaqH7qg+gAmUkeZZ7280rxMXLS2F9 WWHtDu7Cz/gDObB5pqpbThxV6NsGOuSsRENLH5RsvfgKBDL2kqj8X++hocQ4LEZRyd+4 ErDw==
Received: by 10.50.150.174 with SMTP id uj14mr7302463igb.19.1358182050046; Mon, 14 Jan 2013 08:47:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.26.137 with HTTP; Mon, 14 Jan 2013 08:47:09 -0800 (PST)
In-Reply-To: <50F42F3E.9030401@berkeley.edu>
References: <1CD55F04538DEA4F85F3ADF7745464AF2495A4A7@S-BSC-MBX1.nrn.nrcan.gc.ca>  <50F42A91.4050302@gmx.de> <50F42F3E.9030401@berkeley.edu>
From: James M Snell 
Date: Mon, 14 Jan 2013 08:47:09 -0800
Message-ID: 
To: Erik Wilde 
Content-Type: multipart/alternative; boundary=f46d043d644ba220f404d34266b4
Cc: Julian Reschke , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] New Version Notification for draft-wilde-xml-patch-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, 14 Jan 2013 16:47:31 -0000

--f46d043d644ba220f404d34266b4
Content-Type: text/plain; charset=UTF-8

Just a random thinking here... I've often thought that if there were a
critical mass of patch formats being developed, it would be interesting to
pursue a new top-level patch content type.. e.g. "patch/json",
"patch/json-merge", "patch/xml", "patch/text", "patch/octet-stream", etc.
Would seem to be a rather useful thing, really...


On Mon, Jan 14, 2013 at 8:15 AM, Erik Wilde  wrote:

> hello julian.
>
>
> On 2013-01-14 16:56 , Julian Reschke wrote:
>
>> On 2013-01-14 16:44, James M Snell wrote:
>>
>>> To be serious, I have to assume that it's to maintain consistency with
>>> some of the other patch formats that are on the table (e.g.
>>> application/json-patch, application/json-merge-patch,
>>> application/json-test-patch, etc)
>>>
>> So for consistency with formats where we could ask the same question?
>>
>
> yes, that's one way to look at it. personally, i mostly care about a
> format and a name being defined and registered; what the name should look
> like is not absolutely essential. it would be nice, though, if patch
> formats would be named a bit consistently, and that's the motivation for
> the current name. i cannot remember seeing a debate around the other names,
> and maybe there should be one so that when RDF comes along with a patch
> model that can be serialized in a variety of ways, there's some guidance on
> how these ways should be named.
>
>
> cheers,
>
> 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 |
>

--f46d043d644ba220f404d34266b4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Just a random thinki=
ng here... I've often thought that if there were a critical mass of pat=
ch formats being developed, it would be interesting to pursue a new top-lev=
el patch content type.. e.g. "patch/json", "patch/json-merge=
", "patch/xml", "patch/text", "patch/octet-st=
ream", etc. Would seem to be a rather useful thing, really...




On Mon, Jan 1=
4, 2013 at 8:15 AM, Erik Wilde <dret@berkeley.edu> wrote:


hello julian.




On 2013-01-14 16:56 , Julian Reschke wrote:



On 2013-01-14 16:44, James M Snell wrote:



To be serious, I have to assume that it's to maintain consistency with<=
br>
some of the other patch formats that are on the table (e.g.

application/json-patch, application/json-merge-patch,

application/json-test-patch, etc)



So for consistency with formats where we could ask the same question?





yes, that's one way to look at it. personally, i mostly care about a fo=
rmat and a name being defined and registered; what the name should look lik=
e is not absolutely essential. it would be nice, though, if patch formats w=
ould be named a bit consistently, and that's the motivation for the cur=
rent name. i cannot remember seeing a debate around the other names, and ma=
ybe there should be one so that when RDF comes along with a patch model tha=
t can be serialized in a variety of ways, there's some guidance on how =
these ways should be named.







cheers,



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=A0School=
 of Information (ISchool) |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://dret.net/netdret http://twitter.com/dret |





--f46d043d644ba220f404d34266b4--

From ned.freed@mrochek.com  Mon Jan 14 11:42:06 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E868B21F8AF4 for ; Mon, 14 Jan 2013 11:42:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtjvuygB9oBC for ; Mon, 14 Jan 2013 11:42:06 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 746DB21F8AE5 for ; Mon, 14 Jan 2013 11:42:06 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OOZ8YZ0RDS005BT5@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 14 Jan 2013 11:37:04 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OOJ8U2Q2U800008S@mauve.mrochek.com>; Mon, 14 Jan 2013 11:37:01 -0800 (PST)
Message-id: <01OOZ8YX62N000008S@mauve.mrochek.com>
Date: Mon, 14 Jan 2013 11:33:29 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 14 Jan 2013 17:03:46 +0100" <50F42C62.1080002@berkeley.edu>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format=flowed
References: <1CD55F04538DEA4F85F3ADF7745464AF2495A4A7@S-BSC-MBX1.nrn.nrcan.gc.ca>  <50F42C62.1080002@berkeley.edu>
To: Erik Wilde 
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] New Version Notification for	draft-wilde-xml-patch-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, 14 Jan 2013 19:42:07 -0000

> yes, that's the reason. for now, we have decided to follow this naming
> pattern of media types already under development. also,
> application/xml-patch+xml does indeed look a bit strange and doesn't buy
> you much (unless the "we should have a media subtype suffix registry"
> movement picks up steam).

Since in fact we do have such a registry now, you can take that as given.

And the use of the suffix is now a SHOULD; you can only not do it if you have a
very good reason for that choice. I personally don't think that name
consistency with other types is even close to rising to that level; YMMV.

				Ned

From dret@berkeley.edu  Tue Jan 15 00:26:57 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A3321F8AC0 for ; Tue, 15 Jan 2013 00:26:57 -0800 (PST)
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 rUeL2qnSwZpJ for ; Tue, 15 Jan 2013 00:26:57 -0800 (PST)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 292C921F8AB0 for ; Tue, 15 Jan 2013 00:26:57 -0800 (PST)
Received: from 91-66-137-169-dynip.superkabel.de ([91.66.137.169] helo=dretair.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1Tv1rD-000280-86; Tue, 15 Jan 2013 00:26:56 -0800
Message-ID: <50F512CA.6040003@berkeley.edu>
Date: Tue, 15 Jan 2013 09:26:50 +0100
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Ned Freed 
References: <1CD55F04538DEA4F85F3ADF7745464AF2495A4A7@S-BSC-MBX1.nrn.nrcan.gc.ca>  <50F42C62.1080002@berkeley.edu> <01OOZ8YX62N000008S@mauve.mrochek.com>
In-Reply-To: <01OOZ8YX62N000008S@mauve.mrochek.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] New Version Notification for draft-wilde-xml-patch-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, 15 Jan 2013 08:26:58 -0000

hello ned.

On 2013-01-14 20:33 , Ned Freed wrote:
> Since in fact we do have such a registry now, you can take that as given.
> And the use of the suffix is now a SHOULD; you can only not do it if you
> have a
> very good reason for that choice. I personally don't think that name
> consistency with other types is even close to rising to that level; YMMV.

http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-08 
is what you're referring to and this one is going to get published soon, 
right? in that case you'd recommend to go the xml-patch+xml way for the 
subtype, i guess?

i am really wondering how this is going to play out for RDF, have their 
been discussions on how to handle this case (multiple serializations of 
the same data model) for the suffix registry? the reason why i am asking 
is that RDF needs a patch type as well, and there it will become an 
issue how to handle the fact that usually, a patch type's semantics are 
targeted at a model, while the type's syntax is based on some specific 
serialization.

thanks and cheers,

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 derhoermi@gmx.net  Tue Jan 15 09:58:40 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346F821F85B4 for ; Tue, 15 Jan 2013 09:58:40 -0800 (PST)
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 EYAkJY4ANViz for ; Tue, 15 Jan 2013 09:58:39 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1C12821F85B2 for ; Tue, 15 Jan 2013 09:58:38 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LpReN-1TG3Cq3awH-00fASo for ; Tue, 15 Jan 2013 18:58:37 +0100
Received: (qmail invoked by alias); 15 Jan 2013 17:58:37 -0000
Received: from pD9539D0F.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [217.83.157.15] by mail.gmx.net (mp012) with SMTP; 15 Jan 2013 18:58:37 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1/49OgK0Lz4XOQflJgxSt4kKG9xnvrD6MCjIy2bwP YbB0aJT5Am0r5w
From: Bjoern Hoehrmann 
To: Erik Wilde 
Date: Tue, 15 Jan 2013 18:58:35 +0100
Message-ID: 
References: <1CD55F04538DEA4F85F3ADF7745464AF2495A4A7@S-BSC-MBX1.nrn.nrcan.gc.ca>  <50F42C62.1080002@berkeley.edu> <01OOZ8YX62N000008S@mauve.mrochek.com> <50F512CA.6040003@berkeley.edu>
In-Reply-To: <50F512CA.6040003@berkeley.edu>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: Ned Freed , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] New Version Notification for draft-wilde-xml-patch-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, 15 Jan 2013 17:58:40 -0000

* Erik Wilde wrote:
>On 2013-01-14 20:33 , Ned Freed wrote:
>> Since in fact we do have such a registry now, you can take that as given.
>> And the use of the suffix is now a SHOULD; you can only not do it if you
>> have a
>> very good reason for that choice. I personally don't think that name
>> consistency with other types is even close to rising to that level; YMMV.
>
>http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-08 
>is what you're referring to and this one is going to get published soon, 
>right? in that case you'd recommend to go the xml-patch+xml way for the 
>subtype, i guess?

That sounds about right to me.

>i am really wondering how this is going to play out for RDF, have their 
>been discussions on how to handle this case (multiple serializations of 
>the same data model) for the suffix registry? the reason why i am asking 
>is that RDF needs a patch type as well, and there it will become an 
>issue how to handle the fact that usually, a patch type's semantics are 
>targeted at a model, while the type's syntax is based on some specific 
>serialization.

That does not seem very relevant to the suffix registry. The logic here
is that XML formats should use +xml types so "generic" applications can
recognize XML content more easily and more reliably, for instance, so a
program can offer the user the option to edit such a document in an XML
editor, or a web server might decide to compress the content on transfer
because XML content is known to compress well, without having to know
the specific type and without having to analyse any instance documents.

If someone made a format that expresses differences between "RDF files"
or some sort, and that format is based on JSON, the argument would most
likely be to use +json for the corresponding media type.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From ned.freed@mrochek.com  Tue Jan 15 10:46:22 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC1911E80C5 for ; Tue, 15 Jan 2013 10:46:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPhQXJqf64Ua for ; Tue, 15 Jan 2013 10:46:22 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id F0C0711E80A6 for ; Tue, 15 Jan 2013 10:46:21 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OP0LGF5EJ4005A9E@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 15 Jan 2013 10:45:32 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OOJ8U2Q2U800008S@mauve.mrochek.com>; Tue, 15 Jan 2013 10:45:27 -0800 (PST)
Message-id: <01OP0LGBJ20S00008S@mauve.mrochek.com>
Date: Tue, 15 Jan 2013 10:36:42 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 15 Jan 2013 09:26:50 +0100" <50F512CA.6040003@berkeley.edu>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <1CD55F04538DEA4F85F3ADF7745464AF2495A4A7@S-BSC-MBX1.nrn.nrcan.gc.ca>  <50F42C62.1080002@berkeley.edu> <01OOZ8YX62N000008S@mauve.mrochek.com> <50F512CA.6040003@berkeley.edu>
To: Erik Wilde 
Cc: Ned Freed , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] New Version Notification for draft-wilde-xml-patch-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, 15 Jan 2013 18:46:22 -0000

> hello ned.

> On 2013-01-14 20:33 , Ned Freed wrote:
> > Since in fact we do have such a registry now, you can take that as given.
> > And the use of the suffix is now a SHOULD; you can only not do it if you
> > have a
> > very good reason for that choice. I personally don't think that name
> > consistency with other types is even close to rising to that level; YMMV.

> http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-08
> is what you're referring to and this one is going to get published soon,
> right?

When it gets published is irrelevant. It's already approved as a standard
and specifies the current rules we operate under. The relevant IANA web
pages already cite it.

I'll note in passing that this use by IANA and others of documents that haven't
completed the publication process is not up to me; it's just how things work.

> in that case you'd recommend to go the xml-patch+xml way for the
> subtype, i guess?

Yes, that's what I would recommend, but really, it's not a question of what I
recommend. It's instead a question of what the standards require. I already
stated the requirements; if you believe you can make a compelling case for
omitting the suffix for this type you are free to do so.

> i am really wondering how this is going to play out for RDF, have their
> been discussions on how to handle this case (multiple serializations of
> the same data model) for the suffix registry? the reason why i am asking
> is that RDF needs a patch type as well, and there it will become an
> issue how to handle the fact that usually, a patch type's semantics are
> targeted at a model, while the type's syntax is based on some specific
> serialization.

That a question to be answered if and when someone proposes a suffix for rdf.
AFAIK there isn't one at present. I personally don't know enough about RDF and
how it is used to comment, although I'll note that the XML format has the
application/rdf+xml assigned. I will also note that EXI was considered and
rejected as a suffix.

				Ned

From dret@berkeley.edu  Wed Jan 16 00:49:02 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC4321F866E for ; Wed, 16 Jan 2013 00:49:02 -0800 (PST)
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 mPXQrqZ0RRvV for ; Wed, 16 Jan 2013 00:49:02 -0800 (PST)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 29F7C21F84E0 for ; Wed, 16 Jan 2013 00:49:02 -0800 (PST)
Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretair.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TvOg4-0001yv-AW; Wed, 16 Jan 2013 00:48:57 -0800
Message-ID: <50F6697A.8030608@berkeley.edu>
Date: Wed, 16 Jan 2013 09:48:58 +0100
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
References: <1CD55F04538DEA4F85F3ADF7745464AF2495A4A7@S-BSC-MBX1.nrn.nrcan.gc.ca>  <50F42C62.1080002@berkeley.edu> <01OOZ8YX62N000008S@mauve.mrochek.com> <50F512CA.6040003@berkeley.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Bjoern Hoehrmann 
Subject: Re: [apps-discuss] New Version Notification for draft-wilde-xml-patch-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: Wed, 16 Jan 2013 08:49:02 -0000

hello bjoern.

thanks for the feedback.

On 2013-01-15 18:58 , Bjoern Hoehrmann wrote:
> * Erik Wilde wrote:
>> i am really wondering how this is going to play out for RDF, have their
>> been discussions on how to handle this case (multiple serializations of
>> the same data model) for the suffix registry? the reason why i am asking
>> is that RDF needs a patch type as well, and there it will become an
>> issue how to handle the fact that usually, a patch type's semantics are
>> targeted at a model, while the type's syntax is based on some specific
>> serialization.
> That does not seem very relevant to the suffix registry. The logic here
> is that XML formats should use +xml types so "generic" applications can
> recognize XML content more easily and more reliably, for instance, so a
> program can offer the user the option to edit such a document in an XML
> editor, or a web server might decide to compress the content on transfer
> because XML content is known to compress well, without having to know
> the specific type and without having to analyse any instance documents.

this opens up all kinds of interesting discussions. RDF currently uses 
application/rdf+xml, which to some extent is useful and correct (it's an 
XML-based syntax), but on the other hand using generic XML software on 
top of RDF/XML (apart from compression) is not very useful. but there 
very likely isn't a simple answer to this, since many data formats have 
more than just two layers these days.

> If someone made a format that expresses differences between "RDF files"
> or some sort, and that format is based on JSON, the argument would most
> likely be to use +json for the corresponding media type.

my point was more that an RDF patch format more likely would patch the 
RDF model, and not a specific RDF syntax. thus, it might use "rdf-patch" 
as the starting point, but then the patch format itself probably would 
be defined as RDF, and thus could be serialized in different ways, so 
that we might have rdf-patch+rdfxml and rdf-patch+turtle, if there were 
specific suffixes for different RDF serializations. this is all 
hypothetical right now as there aren't any RDF suffixes, but i was 
wondering whether this would be the direction all of this would move 
towards.

cheers,

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 dret@berkeley.edu  Wed Jan 16 02:57:08 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DF021F865B for ; Wed, 16 Jan 2013 02:57:08 -0800 (PST)
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 y4jzaeUJwqLz for ; Wed, 16 Jan 2013 02:57:07 -0800 (PST)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6906F21F865D for ; Wed, 16 Jan 2013 02:57:07 -0800 (PST)
Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretair.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TvQg5-0000GS-6j; Wed, 16 Jan 2013 02:57:06 -0800
Message-ID: <50F6877E.8080604@berkeley.edu>
Date: Wed, 16 Jan 2013 11:57:02 +0100
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org application-layer protocols" 
References: <20130116104350.17257.13004.idtracker@ietfa.amsl.com>
In-Reply-To: <20130116104350.17257.13004.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20130116104350.17257.13004.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: REST Discuss 
Subject: [apps-discuss] Fwd: New Version Notification for draft-wilde-xml-patch-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jan 2013 10:57:08 -0000

hello.

the two main changes in this updated version are as follows:

- the media type now is application/xml-patch+xml, since the new media 
type suffix registry says that media types should use registered suffixes.

- http://tools.ietf.org/html/draft-wilde-xml-patch-01#appendix-B now 
contains an ABNF grammar that has been reverse-engineered from the 
XSD-based grammar in RFC 5261. this should make it easier to implement 
the spec.

thanks and cheers,

dret.


-------- Original Message --------
Subject: New Version Notification for draft-wilde-xml-patch-01.txt
Date: Wed, 16 Jan 2013 02:43:50 -0800
From: internet-drafts@ietf.org


A new version of I-D, draft-wilde-xml-patch-01.txt
has been successfully submitted by Erik Wilde and posted to the
IETF repository.

Filename:	 draft-wilde-xml-patch
Revision:	 01
Title:		 A Media Type for XML Patch Operations
Creation date:	 2013-01-16
WG ID:		 Individual Submission
Number of pages: 10
URL: 
http://www.ietf.org/internet-drafts/draft-wilde-xml-patch-01.txt
Status:          http://datatracker.ietf.org/doc/draft-wilde-xml-patch
Htmlized:        http://tools.ietf.org/html/draft-wilde-xml-patch-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-wilde-xml-patch-01

Abstract:
    The XML Patch media type "application/xml-patch+xml" defines an XML
    document structure for expressing a sequence of patch operations that
    are applied to an XML document.  The XML Patch document format's
    foundations are defined in RFC 5261, this specification defines a
    document format and a media type registration, so that XML Patch
    documents can be labeled with a media type, for example in HTTP
    conversations.

Note to Readers

    This draft should be discussed on the apps-discuss mailing list [8].
    Online access to all versions and files is available at github [9].

From vesely@tana.it  Wed Jan 16 07:55:49 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113BA21F8AB7 for ; Wed, 16 Jan 2013 07:55:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level: 
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 3TZfOoCIFGy6 for ; Wed, 16 Jan 2013 07:55:48 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9D121F8AA8 for ; Wed, 16 Jan 2013 07:55:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1358351744; bh=ntEEy+zSIn2YM10X1Qyfl07XTg3v3RWPjlIwJNow0go=; l=3177; h=Date:From:To:References:In-Reply-To; b=tfZZxd4XBy3GjOJfIkq1AsL7Cy/PWgR36P3C1CL6BHR7sI1OhwALUlQE3clKjpFtz o/7hVU4R3uJKXKmIYH89cMqPWGhflx3NC8Mv0m0HZZ4dJc9iMtUjdUx3tH+hTg3wMW 2/qX3fW5dnNRaj6dCRhDyd9qVSR4IsNJyXfF74T4=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Wed, 16 Jan 2013 16:55:44 +0100 id 00000000005DC04B.0000000050F6CD80.000058CB
Message-ID: <50F6CD80.5080807@tana.it>
Date: Wed, 16 Jan 2013 16:55:44 +0100
From: Alessandro Vesely 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Murray S. Kucherawy" , apps-discuss@ietf.org
References:  <50DD45C1.4040605@bbiw.net>  <6.2.5.6.2.20130106010843.0a41a920@elandnews.com>
In-Reply-To: <6.2.5.6.2.20130106010843.0a41a920@elandnews.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Comments on draft-kucherawy-rfc5451bis-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jan 2013 15:55:49 -0000

On Sun 06/Jan/2013 19:07:11 +0100 SM wrote:
> 
>   "[DOMAINKEYS] is also referenced here, though it has "Historic" status
>    as it is no longer common.  This proposal is not intended to be
>    restricted to domain-based authentication, but this has proven to be
>    a good starting point for implementations."
> 
> I suggest dropping DomainKeys as it's historic.  Implementers can
> reference RFC 5451 if they need the information.

I agree, if at the same times the I-D marks the domainkeys method and
related result names as "deprecated" in IANA registries.

> Section 2.3
> 
>   'Examples of valid authentication identifiers are "example.com",
>    "mail.example.org", "ms1.newyork.example.com", and "example-auth".'
> 
> "example-auth" cannot be guaranteed to be unique.  It violates the
> "MUST".

That "example-auth" reinforces that identifiers are only meaningful
within a given ADMD.  They cannot be unique for a generic MUA that
fetches messages from unrelated, possibly non-conforming servers.

Even if all servers are conforming, the technique described in the
first paragraph of Section 5 can only work within a single ADMD.  It
is not interoperable, in the sense that the indication that "the
header field was added within example.com" is an unspecified
implementation detail.  IMHO, 5451bis can be improved by specifying
it.  Otherwise, I'd strike that sentence (The uniqueness of the
identifier MUST be guaranteed by the ADMD that generates it and MUST
pertain to exactly that one ADMD) as it's difficult to make any sense
of it.

Section 2.3 also says:

   Moreover, some implementations have considered appending a
   delimiter such as "/" and following it with useful transport
   tracing data such as the [SMTP] queue ID or a timestamp.

I gather only the first part is to be checked, in that case.

Finally, the "MUST delete" at the beginning of Section 5 can be
softened to "MUST delete or rename", e.g. transforming it into an
harmless but debuggable field like:

   Old-Authentication-Results: unknown.id; ...

> The following entries in the Email Authentication Result Name
> Registry are updated to reference this document:
> 
>    +-----------+----------+-------------+------------------------------+
>    |   Code    | Defined  | Auth        | Meaning                      |
>    |           |          | Method(s)   |                              |
>    +-----------+----------+-------------+------------------------------+

Let's not forget there's a Status column too.

> As a FYI, RFC 6577 amended the Email Authentication Methods and Email
> Authentication Result Names registries.  The registries use "Expert
> Review".  "Experts are expected to apply applicable documented review
> or vetting procedures, or in the absence of documented criteria,
> follow generally accepted norms".

In that case, the bottom paragraph of Section 2.5.2 could be softened
so as to require ignoring just the resinfo clauses related to unknown
methods, not the whole header field.

> "The evaluation process is not intended to be secretive or bestow
> unquestioned power on the expert".  I suggest:
> 
>  (i)   Identifying a mailing list for the registration requests and
>        discussions.

Is that going to be apps-discuss?

From barryleiba@gmail.com  Wed Jan 16 10:18:03 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E0D21F880F for ; Wed, 16 Jan 2013 10:18:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.125
X-Spam-Level: 
X-Spam-Status: No, score=-103.125 tagged_above=-999 required=5 tests=[AWL=-0.148, 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 SIenooQkXUE2 for ; Wed, 16 Jan 2013 10:18:02 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE4321F87F9 for ; Wed, 16 Jan 2013 10:18:02 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id y2so1265374lbk.31 for ; Wed, 16 Jan 2013 10:18:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=aKoua3GNBStDDKvApBxwXs36e8DPzOvFVohhCJx/thA=; b=wiosbH0O6X9dZuPxSjXEm+BapGpY4Es/4Jn5WO3ZZRGVx/IOXme3OZWRc7at82VJ4u kCovcYcZI1tX20YW1fWmwaMXrXJOeyj/vXt5iHAob7Rmdz0r4yCNwvrgZElNZMRSydxj o7RspE1m5KsS3MA3Q9QoO0HZ6Vlf8dfYn4a/qvH4fKAyEkzX1GyCAEAvIxwMpVMMnpls JZ4xFfYaQDXSCgxcFtwzrhYaS/sjAMFOvxgXozmoHDittFL7MrZ71j1Uy5fCQW4lg9p1 fpBWVA+7bEjSnQGN2xf+4Bqvw5vyiNXzzQda+50KUm+7KoDINxbewfcNU+KnnnwQGWAz GtyQ==
MIME-Version: 1.0
X-Received: by 10.112.50.98 with SMTP id b2mr867023lbo.4.1358360281177; Wed, 16 Jan 2013 10:18:01 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.112.47.168 with HTTP; Wed, 16 Jan 2013 10:18:00 -0800 (PST)
Date: Wed, 16 Jan 2013 13:18:00 -0500
X-Google-Sender-Auth: WP5p-uEcqUc49ThR4vXk0PyNLjU
Message-ID: 
From: Barry Leiba 
To: Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [apps-discuss] The "array vs object" issue in JSON Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jan 2013 18:18:03 -0000

As everyone who's been reading the JSON threads knows, there's been
controversy about one aspect of JSON pointer: specifically, that while
JSON itself makes a distinction between arrays and objects, the JSON
Pointer syntax does not.  Users of the pointers have to know what
they're pointing to (or have to be in an application situation where
it doesn't matter).

It's clear that the discussion has been had, that the working group
has rough consensus on the document as it stands, that what we have
meets the current use cases and represents running code, and that
those pushing for a change to this, to make a syntactic distinction
between a pointer to an array element and one to an object member, are
in the rough.

That said, I find the arguments for the change sufficiently compelling
to ask folks to have one more think on it.  I do NOT want to make this
a free-for-all where we have the whole argument all over again.  We
all know what's been said.  Carsten's note about its coming down to
how strong you want the typing to be is a useful one.  So I want to
ask the question a particular way.

Consider these points:

1. Failing to make the distinction now pretty much locks us into it
for good.  What we have might meet the use cases we have now, but are
we really sure we're never going to regret that, that next week or
next month or next year we might not have a new use case that tips the
balance?

2. There's running code, but *if* we're going to make a change, now's
the time, and the running code can be changed.  If, as we say, the
current uses of Pointer know whether they're talking about arrays or
objects, then the code can be changed to use the appropriate syntax
for the appropriate type.  How hard is it, *really*, to change this?

3. On the other side, the heartburn is exacerbated by the fact that
JSON Patch applies the same operations differently for arrays and
objects.  That's an issue with Patch, not with Pointer, but it's hard
not to blend them and say that distinguishing the syntax for Pointer
would at least partially meliorate the issue in Patch.

Given those considerations, the question is this: Does the working
group stand by its rough consensus for the JSON Pointer syntax as it
stands?  Or might it be better to make a syntactic distinction between
arrays and objects now, while we can, to be more robust for the
future?  (Or, on the other hand, for those who have three hands, would
it actually *harm* the protocol to change this?)

Again, repeating:
Of course the rough consensus in appsawg is what wins, and if
everyone's *really sure* that we want to go ahead with things as they
are, then we will.  The IESG has already given its approval for that.
I'd just like people to take a moment to be certain about that before
we move on.

Barry, trying to be responsible as AD

From derhoermi@gmx.net  Wed Jan 16 11:05:25 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146DF21F88CB for ; Wed, 16 Jan 2013 11:05:25 -0800 (PST)
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 VSGoEt6MxUKe for ; Wed, 16 Jan 2013 11:05:23 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 687E721F88E1 for ; Wed, 16 Jan 2013 11:05:23 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MUBZ6-1TUVDk0XWU-00QyMx for ; Wed, 16 Jan 2013 20:05:22 +0100
Received: (qmail invoked by alias); 16 Jan 2013 19:05:21 -0000
Received: from p57A1E09E.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [87.161.224.158] by mail.gmx.net (mp029) with SMTP; 16 Jan 2013 20:05:21 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1/cF2ArRNvcz59m9Nrq3zE0a9OSUhjUMqJFXTeP8E b5RPUHYCccd4gd
From: Bjoern Hoehrmann 
To: Barry Leiba 
Date: Wed, 16 Jan 2013 20:05:13 +0100
Message-ID: 
References: 
In-Reply-To: 
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: Apps Discuss 
Subject: Re: [apps-discuss] The "array vs object" issue in JSON Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jan 2013 19:05:25 -0000

* Barry Leiba wrote:
>Given those considerations, the question is this: Does the working
>group stand by its rough consensus for the JSON Pointer syntax as it
>stands?  Or might it be better to make a syntactic distinction between
>arrays and objects now, while we can, to be more robust for the
>future?  (Or, on the other hand, for those who have three hands, would
>it actually *harm* the protocol to change this?)

I think there is no reason to force users of JSON Pointer to encode the
distinction between arrays and objects in pointers; it's a feature that
they do not have to do so. But it would be bad if people who want such a
distinction came up with a competing "A/O-sensitive JSON Pointer" speci-
fication where users have to be careful not to use the wrong variant all
the time. I would have liked more discussion of making this an optional
feature.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From jasnell@gmail.com  Wed Jan 16 11:32:53 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE74421F8667 for ; Wed, 16 Jan 2013 11:32:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.157
X-Spam-Level: 
X-Spam-Status: No, score=-5.157 tagged_above=-999 required=5 tests=[AWL=-1.559, 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 ciFknvZC2zqV for ; Wed, 16 Jan 2013 11:32:52 -0800 (PST)
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id 01ABE21F8644 for ; Wed, 16 Jan 2013 11:32:51 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id c14so3276583ieb.14 for ; Wed, 16 Jan 2013 11:32:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=YRTD0YeYi79vNsSCPrV8c3vCWhpP3kIjDZaF/W+eVAQ=; b=u5Oq/DLPdHh0U+gFg63BdMjKa8sIa69YTHhAMaeISz2fV90IB4KBDj63XvsmprB7XF zo6Mb1tzKpHdczzSzDLCzuqsgjv5fX+zohpWQ5huY2gSKFW9S0E42Mu9/9s/wUlrBBOF BeWxx4vD3HLLB3Hif9GpIWdkEeRoKq0LPi7uwSr7wRVMQk7QgPtPXTSD+YqVTSHuJcUg 9pcfYsPsecgoXHiyuvNbv6cQdtmu72wDTMU+y+iXjq3AitDrbN8PQb25uO1sxtP37ZB4 +TSQmZdhQf5ihVqrpCQNY+UFLvneD2taApEQcpOcCAaawR16oqG68irHmEYkERg1Lmep 1Qiw==
X-Received: by 10.50.150.174 with SMTP id uj14mr1651020igb.19.1358364771574; Wed, 16 Jan 2013 11:32:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.26.137 with HTTP; Wed, 16 Jan 2013 11:32:31 -0800 (PST)
In-Reply-To: 
References: 
From: James M Snell 
Date: Wed, 16 Jan 2013 11:32:31 -0800
Message-ID: 
To: Barry Leiba 
Content-Type: multipart/alternative; boundary=f46d043d644baf636a04d36cf101
Cc: Apps Discuss 
Subject: Re: [apps-discuss] The "array vs object" issue in JSON Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jan 2013 19:32:53 -0000

--f46d043d644baf636a04d36cf101
Content-Type: text/plain; charset=UTF-8

I believe the current decision is sufficient as is. For the various use
cases that have been presented in favor of making the change, alternative
solutions have been put on the table (e.g. my predicates draft). For other
cases (fully concurrent editing) there is not yet enough implementation
experience to justify making changes (that is, it's not at all clear that
making this change alone would be enough to fully address such cases).

- James


On Wed, Jan 16, 2013 at 10:18 AM, Barry Leiba wrote:

> As everyone who's been reading the JSON threads knows, there's been
> controversy about one aspect of JSON pointer: specifically, that while
> JSON itself makes a distinction between arrays and objects, the JSON
> Pointer syntax does not.  Users of the pointers have to know what
> they're pointing to (or have to be in an application situation where
> it doesn't matter).
>
> It's clear that the discussion has been had, that the working group
> has rough consensus on the document as it stands, that what we have
> meets the current use cases and represents running code, and that
> those pushing for a change to this, to make a syntactic distinction
> between a pointer to an array element and one to an object member, are
> in the rough.
>
> That said, I find the arguments for the change sufficiently compelling
> to ask folks to have one more think on it.  I do NOT want to make this
> a free-for-all where we have the whole argument all over again.  We
> all know what's been said.  Carsten's note about its coming down to
> how strong you want the typing to be is a useful one.  So I want to
> ask the question a particular way.
>
> Consider these points:
>
> 1. Failing to make the distinction now pretty much locks us into it
> for good.  What we have might meet the use cases we have now, but are
> we really sure we're never going to regret that, that next week or
> next month or next year we might not have a new use case that tips the
> balance?
>
> 2. There's running code, but *if* we're going to make a change, now's
> the time, and the running code can be changed.  If, as we say, the
> current uses of Pointer know whether they're talking about arrays or
> objects, then the code can be changed to use the appropriate syntax
> for the appropriate type.  How hard is it, *really*, to change this?
>
> 3. On the other side, the heartburn is exacerbated by the fact that
> JSON Patch applies the same operations differently for arrays and
> objects.  That's an issue with Patch, not with Pointer, but it's hard
> not to blend them and say that distinguishing the syntax for Pointer
> would at least partially meliorate the issue in Patch.
>
> Given those considerations, the question is this: Does the working
> group stand by its rough consensus for the JSON Pointer syntax as it
> stands?  Or might it be better to make a syntactic distinction between
> arrays and objects now, while we can, to be more robust for the
> future?  (Or, on the other hand, for those who have three hands, would
> it actually *harm* the protocol to change this?)
>
> Again, repeating:
> Of course the rough consensus in appsawg is what wins, and if
> everyone's *really sure* that we want to go ahead with things as they
> are, then we will.  The IESG has already given its approval for that.
> I'd just like people to take a moment to be certain about that before
> we move on.
>
> Barry, trying to be responsible as AD
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--f46d043d644baf636a04d36cf101
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I believe the curren=
t decision is sufficient as is. For the various use cases that have been pr=
esented in favor of making the change, alternative solutions have been put =
on the table (e.g. my predicates draft). For other cases (fully concurrent =
editing) there is not yet enough implementation experience to justify makin=
g changes (that is, it's not at all clear that making this change alone=
 would be enough to fully address such cases).



- James


On Wed, Jan 16, 2013 at 10:18 AM,=
 Barry Leiba <barryleiba@computer.org> wrote:



As everyone who's been reading the JSON =
threads knows, there's been

controversy about one aspect of JSON pointer: specifically, that while

JSON itself makes a distinction between arrays and objects, the JSON

Pointer syntax does not. =C2=A0Users of the pointers have to know what

they're pointing to (or have to be in an application situation where
it doesn't matter).



It's clear that the discussion has been had, that the working group

has rough consensus on the document as it stands, that what we have

meets the current use cases and represents running code, and that

those pushing for a change to this, to make a syntactic distinction

between a pointer to an array element and one to an object member, are

in the rough.



That said, I find the arguments for the change sufficiently compelling

to ask folks to have one more think on it. =C2=A0I do NOT want to make this=


a free-for-all where we have the whole argument all over again. =C2=A0We
all know what's been said. =C2=A0Carsten's note about its coming do=
wn to

how strong you want the typing to be is a useful one. =C2=A0So I want to
ask the question a particular way.



Consider these points:



1. Failing to make the distinction now pretty much locks us into it

for good. =C2=A0What we have might meet the use cases we have now, but are<=
br>
we really sure we're never going to regret that, that next week or

next month or next year we might not have a new use case that tips the

balance?



2. There's running code, but *if* we're going to make a change, now=
's

the time, and the running code can be changed. =C2=A0If, as we say, the

current uses of Pointer know whether they're talking about arrays or
objects, then the code can be changed to use the appropriate syntax

for the appropriate type. =C2=A0How hard is it, *really*, to change this?


3. On the other side, the heartburn is exacerbated by the fact that

JSON Patch applies the same operations differently for arrays and

objects. =C2=A0That's an issue with Patch, not with Pointer, but it'=
;s hard

not to blend them and say that distinguishing the syntax for Pointer

would at least partially meliorate the issue in Patch.



Given those considerations, the question is this: Does the working

group stand by its rough consensus for the JSON Pointer syntax as it

stands? =C2=A0Or might it be better to make a syntactic distinction between=


arrays and objects now, while we can, to be more robust for the

future? =C2=A0(Or, on the other hand, for those who have three hands, would=


it actually *harm* the protocol to change this?)



Again, repeating:

Of course the rough consensus in appsawg is what wins, and if

everyone's *really sure* that we want to go ahead with things as they
are, then we will. =C2=A0The IESG has already given its approval for that.<=
br>
I'd just like people to take a moment to be certain about that before
we move on.



Barry, trying to be responsible as AD

_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--f46d043d644baf636a04d36cf101--

From nico@cryptonector.com  Wed Jan 16 11:34:41 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C21E21F8AA3 for ; Wed, 16 Jan 2013 11:34:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.977
X-Spam-Level: 
X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 u41RVZiJVjvI for ; Wed, 16 Jan 2013 11:34:40 -0800 (PST)
Received: from homiemail-a33.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEF621F8A3F for ; Wed, 16 Jan 2013 11:34:39 -0800 (PST)
Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 3D8E0594061 for ; Wed, 16 Jan 2013 11:34:38 -0800 (PST)
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=vfYHKPPdbu9jKAtWysrM 7EFVaG4=; b=W3UhudZKsFEJjIlthNvjgIN4AirCumC6eB1txs627w9uMNhAeZez k/Jr33H4y/XLC+kta6QDak1z5pmm9EaiWu/Q4iGAIO5fWL/6sbz2FvE7DGQezuT8 6+bdVcJJr57xfri6EHA5jROH75FZ/vu5r5ArQ6JmeixYJHJQzUO2Ssk=
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 0850059405E for ; Wed, 16 Jan 2013 11:34:34 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id dr12so1123697wgb.35 for ; Wed, 16 Jan 2013 11:34:33 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.80.73 with SMTP id p9mr4410972wjx.4.1358364873068; Wed, 16 Jan 2013 11:34:33 -0800 (PST)
Received: by 10.217.82.73 with HTTP; Wed, 16 Jan 2013 11:34:32 -0800 (PST)
In-Reply-To: 
References: 
Date: Wed, 16 Jan 2013 13:34:32 -0600
Message-ID: 
From: Nico Williams 
To: Barry Leiba 
Content-Type: text/plain; charset=UTF-8
Cc: Apps Discuss 
Subject: Re: [apps-discuss] The "array vs object" issue in JSON Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jan 2013 19:34:41 -0000

IMO it's a feature that path components of JSON Pointer don't
distinguish between arrays and dicts.

I can see how it might be useful to do so for lazy schema validation
purposes, even so I'm not sure I care.  It might help to have a very
specific example of what the new syntax might be.

As it happens I was coding JSON Pointer two nights ago, so thinking
about incompatibilities resulting from changes to JSON Pointer now...
I'd have to say that the right way to have done this would have been
to reserve more ~ escapes for future use, and the right way to do this
going forward is to call new syntaxes JSON PointerN and have separate
functions/methods for using one or another syntax.  Given that we can
always do this later, then, what's the compelling rationale for making
a backwards-incompatible change this late?

Nico
--

From nico@cryptonector.com  Wed Jan 16 12:01:44 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D1F21F8AE6 for ; Wed, 16 Jan 2013 12:01:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level: 
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=-4.000, 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 SWW86S5fEDAF for ; Wed, 16 Jan 2013 12:01:43 -0800 (PST)
Received: from homiemail-a84.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id EED5621F8B47 for ; Wed, 16 Jan 2013 12:01:39 -0800 (PST)
Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id AB59A1DE060 for ; Wed, 16 Jan 2013 12:01:39 -0800 (PST)
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=B4dlgVt7EK946mrUhJHI 4L5TomI=; b=OlntSooTZo7BFPd2HbHUyMYeSSi4xUk0OXh6QZK46ngAvDnYZ393 BLH67yZ8CZol0+1VhzOGDX+lQc6g6vl1UbjaNANhJPEEjA6vr55sixL7VX0BLSht bcPPDp9+hPVPKK1nWgskKBtAcF4DSNLy+CK1BM0SmCcJ6XslijDLuVo=
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 58A5E1DE05D for ; Wed, 16 Jan 2013 12:01:39 -0800 (PST)
Received: by mail-wi0-f174.google.com with SMTP id hq4so3829078wib.13 for ; Wed, 16 Jan 2013 12:01:38 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.108.236 with SMTP id hn12mr12042338wib.6.1358366498002;  Wed, 16 Jan 2013 12:01:38 -0800 (PST)
Received: by 10.217.82.73 with HTTP; Wed, 16 Jan 2013 12:01:37 -0800 (PST)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115049AF54E@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E115049AF54E@WSMSG3153V.srv.dir.telstra.com>
Date: Wed, 16 Jan 2013 14:01:37 -0600
Message-ID: 
From: Nico Williams 
To: "Manger, James H" 
Content-Type: text/plain; charset=UTF-8
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] JSON pointer: allow /7, but not /07, as an array index
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jan 2013 20:01:44 -0000

On Wed, Jan 9, 2013 at 8:08 AM, Manger, James H
 wrote:
> Can I again ask that we disallow unnecessary leading zeros in array indices
> in JSON pointers.

But it could be a dict key.

Nico
--

From nico@cryptonector.com  Wed Jan 16 12:33:44 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E442511E80B8 for ; Wed, 16 Jan 2013 12:33:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.644
X-Spam-Level: 
X-Spam-Status: No, score=-4.644 tagged_above=-999 required=5 tests=[AWL=-2.667, 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 am+j0E+I0Yey for ; Wed, 16 Jan 2013 12:33:44 -0800 (PST)
Received: from homiemail-a67.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE8E11E80AE for ; Wed, 16 Jan 2013 12:33:44 -0800 (PST)
Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id F20A027BC05F for ; Wed, 16 Jan 2013 12:33:43 -0800 (PST)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id A51E427BC05E for ; Wed, 16 Jan 2013 12:33:43 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id hn17so3862198wib.0 for ; Wed, 16 Jan 2013 12:33:42 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.33.44 with SMTP id o12mr12384729wii.28.1358368422452; Wed, 16 Jan 2013 12:33:42 -0800 (PST)
Received: by 10.217.82.73 with HTTP; Wed, 16 Jan 2013 12:33:42 -0800 (PST)
In-Reply-To: 
References:  
Date: Wed, 16 Jan 2013 14:33:42 -0600
Message-ID: 
From: Nico Williams 
To: Barry Leiba 
Content-Type: text/plain; charset=UTF-8
Cc: Apps Discuss 
Subject: Re: [apps-discuss] The "array vs object" issue in JSON Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jan 2013 20:33:45 -0000

Also, going back over discussions I missed I'd have to say that I
don't think the lack of array/dict distinction in Pointer sytax is a
problem for JSON Patch either, nor do I think it's a good idea to
forbid leading zeros in otherwise all-digits path components (except
that they must be treated as strings, not numbers, and then they apply
only to dicts).

Nico
--

From fgaliegue@gmail.com  Wed Jan 16 14:18:23 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9789721F844F for ; Wed, 16 Jan 2013 14:18:23 -0800 (PST)
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 yzMQBYTWSVxs for ; Wed, 16 Jan 2013 14:18:23 -0800 (PST)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 12E1821F8523 for ; Wed, 16 Jan 2013 14:18:23 -0800 (PST)
Received: by mail-oa0-f44.google.com with SMTP id n5so2004829oag.3 for ; Wed, 16 Jan 2013 14:18:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=6BLnrWN7TswE+vhJYmwcXd3VA7HlNFF/MxPRhrLKdbI=; b=VF6e646yoFJKaJ8bYeusO4GW2B+NBZkowm9qinSSW4xZ+vHQRjGlPRu4A4FUmzAKRI 54c6+vWY8ezQkDfhL/FeFnoE1XS3+5O7r1fWkdLx5D+IwY0Ei5lq85I0x5XUCD4mc42s mIk3C85dzMx9FVqKuWDXwjiEdmEXmIz/INlzHsJ7rysxKUD3iLbBmZ3Jd2FeReD85YLy yJguyol0/g30jgGNNoDbMVUf6L+T7rq554e/M+RgMvEBc5yOQ4I2rbOi37sfeGWFw9Pn k+eXQtnFDW8ipbyGvBu7gM04YNx4vKHuHouUFHSlx3TPyp5GIVKTh2z0Wy4bmqOw07Vn NFfw==
MIME-Version: 1.0
X-Received: by 10.182.188.69 with SMTP id fy5mr2194792obc.74.1358374702648; Wed, 16 Jan 2013 14:18:22 -0800 (PST)
Received: by 10.60.13.231 with HTTP; Wed, 16 Jan 2013 14:18:22 -0800 (PST)
In-Reply-To: 
References: 
Date: Wed, 16 Jan 2013 23:18:22 +0100
Message-ID: 
From: Francis Galiegue 
To: Barry Leiba 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Apps Discuss 
Subject: Re: [apps-discuss] The "array vs object" issue in JSON Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jan 2013 22:18:23 -0000

On Wed, Jan 16, 2013 at 7:18 PM, Barry Leiba  wrot=
e:
> As everyone who's been reading the JSON threads knows, there's been
> controversy about one aspect of JSON pointer: specifically, that while
> JSON itself makes a distinction between arrays and objects, the JSON
> Pointer syntax does not.  Users of the pointers have to know what
> they're pointing to (or have to be in an application situation where
> it doesn't matter).
>

There are only two things that an array/object specific syntax can
bring to JSON Pointer:

* easiness for some language (which one? I wonder) to interpret them
and complexity for other languages,
* impossibility to address some otherwise valid members of a JSON Object.

JSON Pointer as it is currently defined guarantees that any part of
any existing JSON text can be reliably addressed by any language
without even encoding/decoding issues. You cannot really ask for much
more than this.

--
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 mmorley@mpcm.com  Wed Jan 16 19:39:53 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C847E11E80EA for ; Wed, 16 Jan 2013 19:39:53 -0800 (PST)
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 N+eVFoQgpm-8 for ; Wed, 16 Jan 2013 19:39:53 -0800 (PST)
Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by ietfa.amsl.com (Postfix) with ESMTP id F244F11E80E5 for ; Wed, 16 Jan 2013 19:39:52 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id ep20so2122618lab.4 for ; Wed, 16 Jan 2013 19:39:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=aATGfwTdJdKzBvk/jHgBxtkLtE2+JL9wXeCRBX+E6VQ=; b=MeqVGK4yaF4dK57I9Co+xa0TPAGrJjmaJH3nM3GEpiEg0/zqkzBWrzx09IJNeQc3rl 7AwXII1F+G1JVQtDItMlqg3RAhKLJ+JK3XSlAnd8L4kjXMRItwQkDXKUEYY81HvV1Z58 djk0KOWoru153froA2F9hADQImrs408PI1pygt//hHh6NHttVkBVHeeQTMWlxK+NwLUv 43tp1gwqAn6z0QBBpt0eyhGsd2tKEwQLb0flyAA0RZlgrxwWcISU7VFCMAjfFUoVyU4K Srbe7bKIl0A983dNOklpfPXO7MPpGoLzDOlML0hMSaub4/bY71tG15uYRw80UlQC3lr8 HDCA==
MIME-Version: 1.0
X-Received: by 10.112.23.233 with SMTP id p9mr1592307lbf.6.1358393991681; Wed, 16 Jan 2013 19:39:51 -0800 (PST)
Sender: mmorley@mpcm.com
Received: by 10.114.79.66 with HTTP; Wed, 16 Jan 2013 19:39:51 -0800 (PST)
In-Reply-To: 
References: <255B9BB34FB7D647A506DC292726F6E115049AF54E@WSMSG3153V.srv.dir.telstra.com> 
Date: Wed, 16 Jan 2013 22:39:51 -0500
X-Google-Sender-Auth: tz_y-stDKg_eRVqMMGD1Hlie6HE
Message-ID: 
From: Matthew Morley 
To: Nico Williams 
Content-Type: multipart/alternative; boundary=485b390f79ec56d8c704d373bf17
X-Gm-Message-State: ALoCoQkVgYweIuRT9B3l6xUlxNZei8T3MnJi5UVdXuTtFRnh5npWGzHNxaoTWW8wyljmnzgNemKp
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] JSON pointer: allow /7, but not /07, as an array index
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jan 2013 03:39:54 -0000

--485b390f79ec56d8c704d373bf17
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 16, 2013 at 3:01 PM, Nico Williams wrote:

> On Wed, Jan 9, 2013 at 8:08 AM, Manger, James H
>  wrote:
> > Can I again ask that we disallow unnecessary leading zeros in array
> indices
> > in JSON pointers.
>
> But it could be a dict key.


For me, this is why leading zeros should not be supported. Leading zeros in
a python dict will map to the same value:
>>> dict([(7,'a'), (07,'b')])
{7: 'b'}

At the same time, it is worth noting that JSON pointers cannot represent
all of the possible keys of a python dict to begin with, as JSON itself
does not.
>>> json.dumps(dict([(7,'a'), (07,'b'), ('7', 'c'), ('07', 'd')]))
'{"07": "d", "7": "c", "7": "b"}'

-- 
Matt (MPCM)

--485b390f79ec56d8c704d373bf17
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 16, 2013 at 3:01 PM, Nico Williams <nico@cryptonector.com<=
/a>> wrote:


On Wed, Jan 9, 2013 at 8:08 AM, Manger, James H

<James.H.Manger@team.=
telstra.com> wrote:

> Can I again ask that we disallow unnecessary leading zeros in array in=
dices

> in JSON pointers.




But it could be a dict key.

For me, this is why =
leading zeros should not be supported.=A0Leading zeros in a python dict wil=
l map to the same value:
>>> dict([(7,'a'), (=
07,'b')])


{7: 'b'}

At the same time, it is worth not=
ing that JSON pointers cannot represent all of the possible keys of a pytho=
n dict to begin with, as JSON itself does not.
>>> json.dumps(d=
ict([(7,'a'), (07,'b'), ('7', 'c'), ('0=
7', 'd')]))


'{"07": "d", "7": "c", &qu=
ot;7": "b"}'

-- Matt (MPCM)

--485b390f79ec56d8c704d373bf17--

From nico@cryptonector.com  Wed Jan 16 19:47:07 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CB711E80EC for ; Wed, 16 Jan 2013 19:47:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.25
X-Spam-Level: 
X-Spam-Status: No, score=-5.25 tagged_above=-999 required=5 tests=[AWL=-3.273,  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 w1m2iKK0nrtu for ; Wed, 16 Jan 2013 19:47:06 -0800 (PST)
Received: from homiemail-a87.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAD311E809A for ; Wed, 16 Jan 2013 19:47:06 -0800 (PST)
Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id EE30726C06F for ; Wed, 16 Jan 2013 19:47:02 -0800 (PST)
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=rrPDAbCkjun5ZM99rM/f VTXk4Co=; b=UD3YrQhIZbZ5Q9eYy8vzebCl4P2Bv9ZQJ2a20VjjtsJb8T9qL67/ 4OzoUw+7IouRqO9YcF1XqyfTgP0T72TqaOoNFAAGNt2jB2XzmuUwV9YdWzS8ej0E f+prABh9GaqsN6svr7XC6VefvRK9f4cZxK5etRVwvi3gXMfWPXMDlJU=
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (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 982E726C057 for ; Wed, 16 Jan 2013 19:47:02 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id o1so1921114wic.0 for ; Wed, 16 Jan 2013 19:47:01 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.8.130 with SMTP id r2mr5735082wia.28.1358394421359; Wed, 16 Jan 2013 19:47:01 -0800 (PST)
Received: by 10.217.82.73 with HTTP; Wed, 16 Jan 2013 19:47:01 -0800 (PST)
In-Reply-To: 
References: <255B9BB34FB7D647A506DC292726F6E115049AF54E@WSMSG3153V.srv.dir.telstra.com>  
Date: Wed, 16 Jan 2013 21:47:01 -0600
Message-ID: 
From: Nico Williams 
To: Matthew Morley 
Content-Type: text/plain; charset=UTF-8
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] JSON pointer: allow /7, but not /07, as an array index
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jan 2013 03:47:07 -0000

On Wed, Jan 16, 2013 at 9:39 PM, Matthew Morley  wrote:
> On Wed, Jan 16, 2013 at 3:01 PM, Nico Williams 
> wrote:
>>
>> On Wed, Jan 9, 2013 at 8:08 AM, Manger, James H
>>  wrote:
>> > Can I again ask that we disallow unnecessary leading zeros in array
>> > indices
>> > in JSON pointers.
>>
>> But it could be a dict key.
>
>
> For me, this is why leading zeros should not be supported. Leading zeros in
> a python dict will map to the same value:

This isn't Python.  It's JSON, and keys must be strings.

And looking at the latest I-D leading zeros are forbidden, but only
when a component names an array index, which is exactly what I want.

Nico
--

From mmorley@mpcm.com  Wed Jan 16 20:12:58 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78F321F8727 for ; Wed, 16 Jan 2013 20:12:58 -0800 (PST)
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 BQtNOoFVpC2x for ; Wed, 16 Jan 2013 20:12:58 -0800 (PST)
Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) by ietfa.amsl.com (Postfix) with ESMTP id B66C121F86D8 for ; Wed, 16 Jan 2013 20:12:57 -0800 (PST)
Received: by mail-la0-f47.google.com with SMTP id fh20so2126108lab.6 for ; Wed, 16 Jan 2013 20:12:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=2vo1HBHBS+v1AMUBk6Qyv4ruUOAoeh3aUXL7hrl3U1k=; b=ntRILFeKbumWl+KbcTwxseNYmfsFOfjL9peYqTyU5u2jP2rI5C9Bds6b83Euktrdrr hDy22V49R7xwvJ4jBxYn4nOo9jL7JwYiHDxsCWe6kHR8CfR4D3vJWTmDicl9kZAxFVnX A/hjycvi4vL342BJBeZvJoDsxEeXsLWdsp0Zfl+vOIK0sJ9EkCl00LHtzima2HulzdQv Y29UmkD8uSMCK8JA7NF+Ke3A9vcLhaVGhYZiIFvekImb+jjPilrF2D3e2V2OIqBzVM4e lq6+bs2j+AFgxPzyukWKwNoITiNakHE+ll+cvCVhC5TjTCuF2IuwpLjGFAo/8xMyGwyE vgAw==
MIME-Version: 1.0
X-Received: by 10.112.28.65 with SMTP id z1mr1570338lbg.119.1358395976665; Wed, 16 Jan 2013 20:12:56 -0800 (PST)
Sender: mmorley@mpcm.com
Received: by 10.114.79.66 with HTTP; Wed, 16 Jan 2013 20:12:56 -0800 (PST)
In-Reply-To: 
References: 
Date: Wed, 16 Jan 2013 23:12:56 -0500
X-Google-Sender-Auth: iJMlZO29ZgUa0BY7JQcaxI2sW3k
Message-ID: 
From: Matthew Morley 
To: Barry Leiba 
Content-Type: multipart/alternative; boundary=bcaec554d9d6a74cb704d37435e9
X-Gm-Message-State: ALoCoQlRgPDEJxYF3fdosqDuE5tl76XV1u82Y9djsrxZb57RzvnsDr1qDQfCwG1I8cK7tWui2fgQ
Cc: Apps Discuss 
Subject: Re: [apps-discuss] The "array vs object" issue in JSON Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jan 2013 04:12:59 -0000

--bcaec554d9d6a74cb704d37435e9
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 16, 2013 at 1:18 PM, Barry Leiba wrote:

> 1. Failing to make the distinction now pretty much locks us into it
> for good.  What we have might meet the use cases we have now, but are
> we really sure we're never going to regret that, that next week or
> next month or next year we might not have a new use case that tips the
> balance?
>

I find the reverse is be more true. The downside to the syntax change,
would be that pointers which might otherwise have been resolved would now
fail. Even though the only reasonable action would been to attempt to map
the provided key against the provided structure.

Part of this is that pointer itself is a string, so not unlike a numerical
value in middle of a URI, it is already a string and it does not simply map
to a specific structural construct intuitively. Otherwise we would have
seen a syntax like below strongly promoted by the community as the correct
approach?

http://example.com/user:0/name


> 2. There's running code, but *if* we're going to make a change, now's
> the time, and the running code can be changed.  If, as we say, the
> current uses of Pointer know whether they're talking about arrays or
> objects, then the code can be changed to use the appropriate syntax
> for the appropriate type.  How hard is it, *really*, to change this?
>

Running code should not be a consideration either way on this issue. There
is no time like the present to make the right decision for the right
reasons. :)

3. On the other side, the heartburn is exacerbated by the fact that
> JSON Patch applies the same operations differently for arrays and
> objects.  That's an issue with Patch, not with Pointer, but it's hard
> not to blend them and say that distinguishing the syntax for Pointer
> would at least partially meliorate the issue in Patch.
>

JSON Patch needs to address this issue within its own specification. It is
not clear to me at this point, that anything but optimistic patching is
truly a requirement. Being more specific via layering is often the best
approach, while baking that specificity into the pointer string offers
little actual advantage.

-- 
Matt (MPCM)

--bcaec554d9d6a74cb704d37435e9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 16, 2013 at 1:18 PM, Barry Leiba <barryleiba@computer.o=
rg> wrote:=A0

1. Failing to make the distinction now pretty much locks us into it

for good. =A0What we have might meet the use cases we have now, but are

we really sure we're never going to regret that, that next week or

next month or next year we might not have a new use case that tips the

balance?

I find the reverse is be more true.=A0The=
 downside to the syntax change, would be that pointers which might otherwis=
e have been resolved would now fail. Even though the only reasonable action=
 would been to attempt to map the provided key against the provided structu=
re.


Part of this is that pointer itself is a string, so not unlike a numeri=
cal value in middle of a URI, it is already a string and it does not simply=
 map to a specific structural construct intuitively. Otherwise we would hav=
e seen a syntax like below strongly promoted by the community as the correc=
t approach?


http://example.com/user:0/na=
me
=A0
2. There's running co=
de, but *if* we're going to make a change, now's


the time, and the running code can be changed. =A0If, as we say, the

current uses of Pointer know whether they're talking about arrays or
objects, then the code can be changed to use the appropriate syntax

for the appropriate type. =A0How hard is it, *really*, to change this?
<=
/blockquote>

Running code should not be a consideration either way =
on this issue. There is no time like the present to make the right decision=
 for the right reasons. :)



3. On the other side, the heartburn is exacerbated by the fact that

JSON Patch applies the same operations differently for arrays and

objects. =A0That's an issue with Patch, not with Pointer, but it's =
hard

not to blend them and say that distinguishing the syntax for Pointer

would at least partially meliorate the issue in Patch.

JSON Patch needs to address this issue within its own specification. I=
t is not clear to me at this point, that anything but optimistic patching i=
s truly a requirement. Being more specific via layering is often the best a=
pproach, while baking that specificity into the pointer string offers littl=
e actual advantage.


-- 
Matt (MPCM)

--bcaec554d9d6a74cb704d37435e9--

From mmorley@mpcm.com  Wed Jan 16 20:22:11 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EA311E8117 for ; Wed, 16 Jan 2013 20:22:11 -0800 (PST)
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 IOW39SNiWWtb for ; Wed, 16 Jan 2013 20:22:10 -0800 (PST)
Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 20AA911E8111 for ; Wed, 16 Jan 2013 20:22:09 -0800 (PST)
Received: by mail-la0-f51.google.com with SMTP id fj20so2191232lab.38 for ; Wed, 16 Jan 2013 20:22:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=l+Ogm/3UOWw7lpIqpjiglzG0IfiqfGlsaKWG0b72XTQ=; b=BM2fA/npmMGUxwjEYC04LX4wiBw2bV7NpnvtPNR0hR3fSKBcPO1/JalC3iB1y6wy1k aewJyTRmgrrQS3cY2yM/Co0V5yUJYpzUnU75tHcMlteo8pAvvVECnnApTjrsLMA4qet7 abp8Sl/byGKCIdzi+3sdXc0KFZCsnXMP3lHjQ0umR4XHg9BfqXKSO901N/+ENr3U7gi9 fmajIjhHZWEe68JbYpGok45Xi+TCtX0n3EIp0KYPbTHB+vqYn7Pe+LaAkakwyzv1zAwd MJKgxMQkVS2SN2D4u826WMMIYp0ylzSTpJOK20V0HluvBFIf1V7xiJh2d01OMeaLWaXw L0QA==
MIME-Version: 1.0
X-Received: by 10.152.145.37 with SMTP id sr5mr3409489lab.33.1358396528989; Wed, 16 Jan 2013 20:22:08 -0800 (PST)
Sender: mmorley@mpcm.com
Received: by 10.114.79.66 with HTTP; Wed, 16 Jan 2013 20:22:08 -0800 (PST)
In-Reply-To: 
References: <255B9BB34FB7D647A506DC292726F6E115049AF54E@WSMSG3153V.srv.dir.telstra.com>   
Date: Wed, 16 Jan 2013 23:22:08 -0500
X-Google-Sender-Auth: xFhhiz7lZeGR7oigjrUZPIcKX9A
Message-ID: 
From: Matthew Morley 
To: Nico Williams 
Content-Type: multipart/alternative; boundary=e89a8f2346859313f604d3745665
X-Gm-Message-State: ALoCoQnlCaEGl3vZTxqxc+2hYSurDgO92JK6LnC83BwPIe6ga94D3MLvEiN/rPTXDXp1nA78tSch
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] JSON pointer: allow /7, but not /07, as an array index
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jan 2013 04:22:11 -0000

--e89a8f2346859313f604d3745665
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 16, 2013 at 10:47 PM, Nico Williams wrote:

> On Wed, Jan 16, 2013 at 9:39 PM, Matthew Morley  wrote:
> > On Wed, Jan 16, 2013 at 3:01 PM, Nico Williams 
> > wrote:
> >>
> >> On Wed, Jan 9, 2013 at 8:08 AM, Manger, James H
> >>  wrote:
> >> > Can I again ask that we disallow unnecessary leading zeros in array
> >> > indices
> >> > in JSON pointers.
> >>
> >> But it could be a dict key.
> >
> > For me, this is why leading zeros should not be supported. Leading zeros
> in
> > a python dict will map to the same value:
>
> This isn't Python.  It's JSON, and keys must be strings.
>
> And looking at the latest I-D leading zeros are forbidden, but only
> when a component names an array index, which is exactly what I want
>

We are in agreement, I misunderstood your original post.

-- 
Matt (MPCM)

--e89a8f2346859313f604d3745665
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 16, 2013 at 10:47 PM, Nico Williams <nico@cryptonector.com=
> wrote:


On Wed, Jan 16, 2013 at 9:39 PM, Matthew Morley <matt@mpcm.com> wrote:

> On Wed, Jan 16, 2013 at 3:01 PM, Nico Williams <nico@cryptonector.com>

> wrote:

>>

>> On Wed, Jan 9, 2013 at 8:08 AM, Manger, James H

>> <James.H.Man=
ger@team.telstra.com> wrote:

>> > Can I again ask that we disallow unnecessary leading zeros in=
 array

>> > indices

>> > in JSON pointers.

>>

>> But it could be a dict key.
>

> For me, this is why leading zeros should not be supported. Leading zer=
os in

> a python dict will map to the same value:




This isn't Python. =A0It's JSON, and keys must be strings.


And looking at the latest I-D leading zeros are forbidden, but only

when a component names an array index, which is exactly what I want

We are in agreement, I misunderstood your orig=
inal post.=A0

-- 
Matt (MPCM)

--e89a8f2346859313f604d3745665--

From william_john_mills@yahoo.com  Wed Jan 16 21:55:38 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B782621F88DD for ; Wed, 16 Jan 2013 21:55:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level: 
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[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 7ADLrNxVZp9z for ; Wed, 16 Jan 2013 21:55:36 -0800 (PST)
Received: from nm11-vm2.bullet.mail.ne1.yahoo.com (nm11-vm2.bullet.mail.ne1.yahoo.com [98.138.90.159]) by ietfa.amsl.com (Postfix) with ESMTP id DC2DB21F88DA for ; Wed, 16 Jan 2013 21:55:35 -0800 (PST)
Received: from [98.138.226.176] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 17 Jan 2013 05:55:32 -0000
Received: from [98.138.89.164] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 17 Jan 2013 05:55:32 -0000
Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 17 Jan 2013 05:55:32 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 406265.59410.bm@omp1020.mail.ne1.yahoo.com
Received: (qmail 80571 invoked by uid 60001); 17 Jan 2013 05:55:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358402131; bh=x0v5fxU18M8HeAIX3FyYAjxjgm6NeQbiQ3GQcdOBd1s=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=NTDUeYCZSJtnZkGfVgTj8VP3CrHaJ3dp6SC6f5KhnWhOOauhbuJQ5BhElshsch1B873i9SxYPB/nQL6u1BKN8184jnoWxANRurlgEIp1d0hkW9WasJRH0fA/SUtM4COLBwZKbgfbURXH+j/WyRK0uMtDdaKcrZQ/qzhNKg1UukI=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ZtBmgsDuE/8Mbgk5XsRCpq3L+RpZSw3WIOnoB3d6d4cMzECkM4PfJvO2qKts8irxagvCCMqfoZGWM0AueSzvzvTXTuwnEPLZlJuKAPxHmLLnyamV3G54P8oGHut9qnAbvc1qDJ2vvh27IBbFk7Ofb1b/kblUcZevl/8g/IHuZDM=;
X-YMail-OSG: 6WR74BQVM1keYQ._zhmAcI3XnmRjJqtUYFI1AxkLyxMF5gZ cYfWtoXFBbf12l15V_x0JBZvEyxpiAZuus_dEOgJ.o7EI4E2_X.XNBkme34E bUmvEjhaROW75CJK_9PlI.yfsQrjt9jOzVYiMXlWt2e6HKGxbBI.WXSM0JiX PkFDaQA.3Ebm7.324gqjrYXL.mqBEYjOhdrfVxnHEh7sk_77D.YaaATevCTp V00pPwoyEUUwmx7nTF0wNQWj6aIyu_Swg5MYkoHUKHf9CCEgUdojVQGKSlJk vJ6v9n9sEuD.YF7OlCfyDghrCzv0t2D6Wbi5j2q0WwAi2ekjsQ5_xLuwlN.e LjWxvAFkYP9dGgbCYz2n9hSdPQpWe4XX6E3DkkxuqC4PXU532dArbqGzF2pR MSoJfBEweQ74xcGbgmSqY2rviJM_11OJoxMgeges5HoFxJxG8mxIJHpkENGH uhu1_mFIvPaILFUh3o4dRgQ9UrNLXRcqUAaF8yes-
Received: from [209.131.62.115] by web31804.mail.mud.yahoo.com via HTTP; Wed, 16 Jan 2013 21:55:31 PST
X-Rocket-MIMEInfo: 001.001, KzEuwqAgQW55b25lIHVzaW5nIGF0b2koKSB3aWxsIGdldCBjb2xsaXNpb25zLsKgIEFsbG93aW5nIGxlYWRpbmcgemVyb2VzIGlzIGJhZC7CoCBpbiBmYWN0IHlvdSBzaG91bGQgbWFrZSBzdXJlIHlvdSBoYXZlIGEgdmVyeSBzdHJpY3QgaW50ZWdlciA.PTAgZGVmaW5pdGlvbi7CoCBTb21ldGhpbmcgbGlrZSBbMC05XS9bMS85XVswLTldKwoKCgoKCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo.IEZyb206IE1hdHRoZXcgTW9ybGV5IDxtYXR0QG1wY20uY29tPgo.VG86IE5pY28gV2lsbGlhbXMBMAEBAQE-
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.130.496
References: <255B9BB34FB7D647A506DC292726F6E115049AF54E@WSMSG3153V.srv.dir.telstra.com>  
Message-ID: <1358402131.72902.YahooMailNeo@web31804.mail.mud.yahoo.com>
Date: Wed, 16 Jan 2013 21:55:31 -0800 (PST)
From: William Mills 
To: Matthew Morley , Nico Williams 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="835683298-2035712355-1358402131=:72902"
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] JSON pointer: allow /7, but not /07, as an array index
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, 17 Jan 2013 05:55:38 -0000

--835683298-2035712355-1358402131=:72902
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

+1.=A0 Anyone using atoi() will get collisions.=A0 Allowing leading zeroes =
is bad.=A0 in fact you should make sure you have a very strict integer >=3D=
0 definition.=A0 Something like [0-9]/[1/9][0-9]+=0A=0A=0A=0A=0A=0A>_______=
_________________________=0A> From: Matthew Morley =0A>To: N=
ico Williams  =0A>Cc: IETF Apps Discuss  =0A>Sent: Wednesday, January 16, 2013 7:39 PM=0A>Subject: Re: [=
apps-discuss] JSON pointer: allow /7, but not /07, as an array index=0A> =
=0A>=0A>On Wed, Jan 16, 2013 at 3:01 PM, Nico Williams  wrote:=0A>=0A>On Wed, Jan 9, 2013 at 8:08 AM, Manger, James H=0A>> wrote:=0A>>> Can I again ask that we disallow =
unnecessary leading zeros in array indices=0A>>> in JSON pointers.=0A>>=0A>=
>But it could be a dict key.=0A>=0A>For me, this is why leading zeros shoul=
d not be supported.=A0Leading zeros in a python dict will map to the same v=
alue:=0A>=0A>>>> dict([(7,'a'), (07,'b')])=0A>{7: 'b'}=0A>=0A>At the same t=
ime, it is worth noting that JSON pointers cannot represent all of the poss=
ible keys of a python dict to begin with, as JSON itself does not.=0A>>>> j=
son.dumps(dict([(7,'a'), (07,'b'), ('7', 'c'), ('07', 'd')]))=0A>=0A>'{"07"=
: "d", "7": "c", "7": "b"}'=0A>=0A>-- =0A>Matt (MPCM) =0A>_________________=
______________________________=0A>apps-discuss mailing list=0A>apps-discuss=
@ietf.org=0A>https://www.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A>
--835683298-2035712355-1358402131=:72902
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


+1. =
 Anyone using atoi() will get collisions.  Allowing leading zeroes is =
bad.  in fact you should make sure you have a very strict integer >=
=3D0 definition.  Something like [0-9]/[1/9][0-9]+

<=
/span>

  
 
 
  
  From: Ma=
tthew Morley <matt@mpcm.com>
 Cc: IETF Apps Discuss <apps-dis=
cuss@ietf.org> 
 Sent: Wednesday, January 16, 2013 7:39 PM
 Subject: Re: [apps-discuss] JSON pointer: allow /7, but no=
t /07, as an array index
  
 
On=
 Wed, Jan 16, 2013 at 3:01 PM, Nico Williams <nico@cryptonector.com> wr=
ote:
=0A
On Wed, Jan 9, 2013 at 8:0=
8 AM, Manger, James H
=0A<James.H.Manger@team.telstra.com> wrote:
=0A>=
; Can I again ask that we disallow unnecessary leading zeros in array indic=
es
=0A> in JSON pointers.
=0A
=0A
But it could be a dict k=
ey.

For me, this is why leading zeros should not be su=
pported. Leading zeros in a python dict will map to the same value:
>>> dict([(7,'a'), (07,'b')])
=0A
{7: 'b'}

At the same time, it is worth noting that JSON pointers ca=
nnot represent all of the possible keys of a python dict to begin with, as =
JSON itself does not.
>>> json.dumps(dict([(7,'a'), (07,'b'), (=
'7', 'c'), ('07', 'd')]))
=0A
'{"07": "d", "7": "c", "7": "b"}'

-- 
Matt (MPCM)=0A

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


 
 
 
   

--835683298-2035712355-1358402131=:72902--

From nico@cryptonector.com  Wed Jan 16 22:05:31 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2156A21F8938 for ; Wed, 16 Jan 2013 22:05:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.977
X-Spam-Level: 
X-Spam-Status: No, score=-4.977 tagged_above=-999 required=5 tests=[AWL=-3.000, 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 GJ-2aUX9rLHe for ; Wed, 16 Jan 2013 22:05:30 -0800 (PST)
Received: from homiemail-a27.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id B42D621F8911 for ; Wed, 16 Jan 2013 22:05:29 -0800 (PST)
Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id AB6E459805F for ; Wed, 16 Jan 2013 22:05:23 -0800 (PST)
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=dxYmwqH7DjlP9vv4oBpT LycSeS8=; b=rrpy45cc5T+1VQAhRZVSyh58gCFTK0wP9hThvAlVL8pnADtJo+al iBnxVUl5FHCThk1KH7KTmXOHwottujsOrL0exZH8d6KsSspdw1Dlnhm7wKRFy3ew vuS2BEtw9Egl4QBfoPVk8sV5cg9C4aqtxrr/aSqYUYdCHy8OO7e+MoE=
Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 8D959598057 for ; Wed, 16 Jan 2013 22:05:23 -0800 (PST)
Received: by mail-ie0-f179.google.com with SMTP id k14so4133372iea.38 for ; Wed, 16 Jan 2013 22:05:23 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.152.137 with SMTP id uy9mr2836103igb.62.1358402723095; Wed, 16 Jan 2013 22:05:23 -0800 (PST)
Received: by 10.64.12.69 with HTTP; Wed, 16 Jan 2013 22:05:22 -0800 (PST)
In-Reply-To: <1358402131.72902.YahooMailNeo@web31804.mail.mud.yahoo.com>
References: <255B9BB34FB7D647A506DC292726F6E115049AF54E@WSMSG3153V.srv.dir.telstra.com>   <1358402131.72902.YahooMailNeo@web31804.mail.mud.yahoo.com>
Date: Thu, 17 Jan 2013 00:05:22 -0600
Message-ID: 
From: Nico Williams 
To: William Mills 
Content-Type: text/plain; charset=UTF-8
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] JSON pointer: allow /7, but not /07, as an array index
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jan 2013 06:05:31 -0000

On Wed, Jan 16, 2013 at 11:55 PM, William Mills  wrote:
> +1.  Anyone using atoi() will get collisions.  Allowing leading zeroes is
> bad.  in fact you should make sure you have a very strict integer >=0
> definition.  Something like [0-9]/[1/9][0-9]+

The I-D already says no leading zeros allowed when indexing arrays.

From sayrer@gmail.com  Thu Jan 17 00:31:14 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7946A21F87D1 for ; Thu, 17 Jan 2013 00:31:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.433
X-Spam-Level: 
X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.167,  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 ZbSZ9kz5xamS for ; Thu, 17 Jan 2013 00:31:13 -0800 (PST)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 893C321F87CE for ; Thu, 17 Jan 2013 00:31:13 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id eb20so1205585lab.17 for ; Thu, 17 Jan 2013 00:31:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Bd33tAG5wEOTLciX2TRj4tCHf6AA8weyUfpwrxzersY=; b=oKV3bBLso7TXiJMfm1UfRZGKFo8HvAU8g1r7U7Lo/eqkgACLbPUGMH6yFYZzFzdra7 YF+pOLSiGJgp5Z1wUR72hE+3cdnghu/eUW1Tv2t+w2/naMqZVp7t/4JTNNvM5gmvP71c QpK6zoS3k6+pbdCOUeYYcs+24W31LRh3xcJvP7vAXaWBKer49mJhoZ6h0hg+koDWt7hi knUQmx/rQSghNETX9mfuAEZ91JlL8seJlZiPSdRkpQI4KTVdNlbnZJOlyeGM8V51bogR CELu4F9bML909tv5az14kfPTXIjJRT0hWl8hLkkGK47NH9f1kJwPQY8v/n/4vYAbatLT 8Byw==
MIME-Version: 1.0
X-Received: by 10.112.100.195 with SMTP id fa3mr1897018lbb.38.1358411472382; Thu, 17 Jan 2013 00:31:12 -0800 (PST)
Received: by 10.112.137.225 with HTTP; Thu, 17 Jan 2013 00:31:12 -0800 (PST)
In-Reply-To: 
References: 
Date: Thu, 17 Jan 2013 00:31:12 -0800
Message-ID: 
From: Robert Sayre 
To: Barry Leiba 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Apps Discuss 
Subject: Re: [apps-discuss] The "array vs object" issue in JSON Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jan 2013 08:31:14 -0000

On Wed, Jan 16, 2013 at 10:18 AM, Barry Leiba  wrote:
>
> It's clear that the discussion has been had

Agree.

>
> Consider these points:

All good points, which deserve to be addressed directly and
substantively. According to the metrics in [1], each of the three
should be addressed at level 6.

For me, this means that there better be very concrete reasons for the
type system of JSON Pointer and JSON Patch to diverge from the rules
specified by JSON itself. RFC4627 is short, and section 2 of that RFC
is easy to understand.

>
> Barry, trying to be responsible as AD

Succeeding. However, we will not be "stuck with" the decision of this
WG. It's actually quite easy to ignore.

- Rob

[1] http://www.paulgraham.com/disagree.html

From yoshiro.yoneya@jprs.co.jp  Thu Jan 17 01:10:18 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482F521F8878; Thu, 17 Jan 2013 01:10:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 Cx12ua016OH9; Thu, 17 Jan 2013 01:10:02 -0800 (PST)
Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBB821F8871; Thu, 17 Jan 2013 01:10:02 -0800 (PST)
Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id r0H9A0mR020677; Thu, 17 Jan 2013 18:10:01 +0900
X-AuditID: ac120820-b7fec6d000005acc-7a-50f7bfe88bc2
Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 65.05.23244.8EFB7F05; Thu, 17 Jan 2013 18:10:00 +0900 (JST)
Date: Thu, 17 Jan 2013 18:09:58 +0900
From: Yoshiro YONEYA 
To: apps-discuss@ietf.org, draft-ietf-radext-radius-extensions.all@tools.ietf.org
Message-Id: <20130117180958.bbe07f26ac659d782bffbf02@jprs.co.jp>
X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32)
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsWyRoiFT/fF/u8BBlv3mVusfrmCzeLklwZ2 ixl/JjJbdLVtZnFg8Viy5CeTx9/771g9vlz+zBbAHMVlk5Kak1mWWqRvl8CVceV8UkEnX8Xd 5YdYGhgncHcxcnJICJhIrGucxQRhi0lcuLeerYuRi0NI4DijRO+5+4wgCRYBVYnVy14wg9hs AgYSv5b9BmsQEQiWmLDlM1icWUBQoun9KxYQW1jAUaJj8kc2EJtXwEGi/dEvZogFFhIXmjrY uxg5gOKCEn93CIOYzALqEuvnCUFMkZdo3jqbeQIj7yyEolkIRbOQFC1gZF7FKJOflqZbnJqX UpybbmCoV1KZr5dVUFSslwyiNzGCA45DYQfjjFMGhxgFOBiVeHgnXv0WIMSaWFZcmXuIUZKD SUmU9/Oe7wFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHhV9gHleFMSK6tSi/JhUtIcLErivMfP 7vATEkhPLEnNTk0tSC2CycpwcChJ8JaBNAoWpaanVqRl5pQgpJk4OEGG8wANPwc2vLggMbc4 Mx0if4pRUkqcdy9IQgAkkVGaB9f7ilEc6AVh3vUgWR5g8oDregU0kAlo4Ka9n0EGliQipKQa GFmm3a12nf3yz6nPPGcenTmq0CNXK30qQJJdP4GnKX7b7wL5M5ukfgb+VVMqjXRxzjGr9j2w htdZ+dOhLw8vHS56pFqwI+jC09RKTYmNEr9ucLnbBT79nf/koZ7cyYP/daaamd+7XOfZ9MD1 pNiJNzJTmQpT2y7xcH9dmZH3+fW6p8kLygOSvyqxFGckGmoxFxUnAgD0ioH/2wIAAA==
Cc: iesg@ietf.org
Subject: [apps-discuss] APPSDIR review of draft-ietf-radext-radius-extensions-08
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jan 2013 09:10:18 -0000

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see 
​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive.  Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-radext-radius-extensions-08
Title: Remote Authentication Dial In User Service (RADIUS) Protocol Extensions
Reviewer: Yoshiro Yoneya
Review Date: 2013-01-17
IETF Last Call Date: 2013-01-25
IESG Telechat Date: unknown

Summary:

This draft is ready for publication as a Proposed Standard RFC.

Major Issues:
  none

Minor Issues:
  none

Nits:

- Section 1.1.1. [Page 6]
  One gaol which was not ...
  -> One goal which was not ...

- Section 2. [Page 9]
  ...
  so that the definition of the Length field remains unchanged.  The
  new attribute formats are designed to be compatible with the
  ...
  so that the definition of the Length field remains unchanged.
  -> [The same sentences are repeated twice.  Remove duplicated one.]

- Section 6.5. [Page 40]
  Specifications which allocate many attributes MUST NOT request that
  allocation be made from from the standard space.
  -> Specifications which allocate many attributes MUST NOT request that
     allocation be made from the standard space.
  
- Section 6.6. [Page 41]
  Where a group of TLVs is strictly defined, and not expected to
  change, and and totals less than 247 octets of data,
  -> Where a group of TLVs is strictly defined, and not expected to
     change, and totals less than 247 octets of data,

Regards,

-- 
Yoshiro YONEYA 


From aland@deployingradius.com  Thu Jan 17 05:24:46 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5771C21F886D; Thu, 17 Jan 2013 05:24:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.494
X-Spam-Level: 
X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 wWjcb2mr7oGL; Thu, 17 Jan 2013 05:24:45 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 74DE821F8868; Thu, 17 Jan 2013 05:24:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 5D3742240F0C; Thu, 17 Jan 2013 14:24:44 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyyyeFTXHSqR; Thu, 17 Jan 2013 14:24:43 +0100 (CET)
Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id 178752240821; Thu, 17 Jan 2013 14:24:42 +0100 (CET)
Message-ID: <50F7FB9A.6020006@deployingradius.com>
Date: Thu, 17 Jan 2013 08:24:42 -0500
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Yoshiro YONEYA 
References: <20130117180958.bbe07f26ac659d782bffbf02@jprs.co.jp>
In-Reply-To: <20130117180958.bbe07f26ac659d782bffbf02@jprs.co.jp>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Thu, 17 Jan 2013 08:23:05 -0800
Cc: "Benoit Claise \(bclaise\)" , "radext@ietf.org" , iesg@ietf.org, apps-discuss@ietf.org, draft-ietf-radext-radius-extensions.all@tools.ietf.org
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-radext-radius-extensions-08
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jan 2013 13:24:46 -0000

  Thanks.  I've made the changes, and they will appear in the next rev
of the document.

Yoshiro YONEYA wrote:
> I have been selected as the Applications Area Directorate reviewer for 
> this draft (for background on appsdir, please see 
> ​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.  Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-ietf-radext-radius-extensions-08
> Title: Remote Authentication Dial In User Service (RADIUS) Protocol Extensions
> Reviewer: Yoshiro Yoneya
> Review Date: 2013-01-17
> IETF Last Call Date: 2013-01-25
> IESG Telechat Date: unknown
> 
> Summary:
> 
> This draft is ready for publication as a Proposed Standard RFC.
> 
> Major Issues:
>   none
> 
> Minor Issues:
>   none
> 
> Nits:
> 
> - Section 1.1.1. [Page 6]
>   One gaol which was not ...
>   -> One goal which was not ...
> 
> - Section 2. [Page 9]
>   ...
>   so that the definition of the Length field remains unchanged.  The
>   new attribute formats are designed to be compatible with the
>   ...
>   so that the definition of the Length field remains unchanged.
>   -> [The same sentences are repeated twice.  Remove duplicated one.]
> 
> - Section 6.5. [Page 40]
>   Specifications which allocate many attributes MUST NOT request that
>   allocation be made from from the standard space.
>   -> Specifications which allocate many attributes MUST NOT request that
>      allocation be made from the standard space.
>   
> - Section 6.6. [Page 41]
>   Where a group of TLVs is strictly defined, and not expected to
>   change, and and totals less than 247 octets of data,
>   -> Where a group of TLVs is strictly defined, and not expected to
>      change, and totals less than 247 octets of data,
> 
> Regards,
> 


From alexey.melnikov@isode.com  Thu Jan 17 11:27:59 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EEA21F84DD; Thu, 17 Jan 2013 11:27:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.385
X-Spam-Level: 
X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 V9a1mB-bFJJv; Thu, 17 Jan 2013 11:27:55 -0800 (PST)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 7333421F84DA; Thu, 17 Jan 2013 11:27:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1358450870; d=isode.com; s=selector; i=@isode.com; bh=Ykn0Do/xMPfDduTzeY3BriTkUCp+duXg6uxRYoT9gwA=; 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=JevNYyGh8lv+bpAl5OdY2TiT+RCyLHdflomrGudDfq1QTAONRz1Uy0ABfttM0CEl87FVIi j901hVqA3N6bFcyTvYRJW86z4/kDcxGdnZ//2XPTEYg1c7T/Mj/iplhgI8okA3KkLJ8dFg Y8+Z9S3Scg/exqcFKcMg9gySeVjo7QA=;
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, 17 Jan 2013 19:27:50 +0000
Message-ID: <50F850BC.8010203@isode.com>
Date: Thu, 17 Jan 2013 19:27:56 +0000
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, draft-ietf-nea-pt-eap.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
Cc: iesg@ietf.org
Subject: [apps-discuss] APPSDIR review of draft-ietf-nea-pt-eap-06
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jan 2013 19:27:59 -0000

I have been selected as the Applications Area Directorate reviewer for=20
this draft (for background on appsdir, please see =E2=80=8B=20
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive.  Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-nea-pt-eap-06
Title: PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods
Reviewer: Alexey Melnikov
Review Date: 2013-01-17
IETF Last Call Date: 2013-01-16
IESG Telechat Date: unknown

Summary:

This draft is ready for publication as a Proposed Standard RFC, with=20
some minor issues with references.

Major Issues:
   none

Minor Issues:

TEAP reference is normative, as it is mandatory-to-implement. (last=20
sentence in 4.3). Also, is last sentence of 4.3 is contradicting the 2nd=20
paragraph in Section 5?

Similarly, tls-unique reference looks normative as well.

Nits:
  none

From hallam@gmail.com  Thu Jan 17 14:20:36 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA62F21F8A41 for ; Thu, 17 Jan 2013 14:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.055
X-Spam-Level: 
X-Spam-Status: No, score=-4.055 tagged_above=-999 required=5 tests=[AWL=-0.457, 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 KT74007VXEwP for ; Thu, 17 Jan 2013 14:20:36 -0800 (PST)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 76E2A21F8A22 for ; Thu, 17 Jan 2013 14:20:35 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id eb20so2091949lab.3 for ; Thu, 17 Jan 2013 14:20:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=pFsaKm9z2BjFmLJnCK09dPnC+iQvsuK0vtoBaJlQkVc=; b=dNpiuwPM40nRQ0Re2l4Gf02Imf9qpdgCtMB8meEIIXU5NOBKRMd5gNSQWIpmLV9WK5 geQxY/8Ewlc69TgurzcU9wS/qNvv9IHwGhx/Da7jzV5nqI+m3XDLW+OgtWndX/2yptNn /mhGAhS2sCO97TfX0T7Q/rDsgaRhGjkjkWhRr0iXglcaF+uSQmRchlYfcjTT+SbxbN+1 6XFIZ8nMdz3zIkZrcTdeCtTwm4d0EpdaDEIqxx2Fuw3yz+NWOSriiYTizFhLXmCSBZBG WxNxiuOBxL2LryU4lo4xY+lQuReaPfEvFcEb50RGu3Nax/1E21TcIbOw4RiNmRjZPgDY ayaw==
MIME-Version: 1.0
X-Received: by 10.112.28.133 with SMTP id b5mr2907757lbh.79.1358461234360; Thu, 17 Jan 2013 14:20:34 -0800 (PST)
Received: by 10.112.10.36 with HTTP; Thu, 17 Jan 2013 14:20:33 -0800 (PST)
Date: Thu, 17 Jan 2013 17:20:33 -0500
Message-ID: 
From: Phillip Hallam-Baker 
To: General discussion of application-layer protocols 
Content-Type: multipart/alternative; boundary=bcaec554d8e450b09b04d38367b0
Subject: [apps-discuss] Using the .well-known registry for SRV (and other purposes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jan 2013 22:20:37 -0000

--bcaec554d8e450b09b04d38367b0
Content-Type: text/plain; charset=ISO-8859-1

When setting up a web service it would be really nice to be able to use SRV
records for discovery.

That then sets up the question of where to look for the service on the HTTP
server which might be dedicated to just one web service or support more
than one.

There is a DNS URI scheme that is intended to address this issue but this
gives more flexibility than we actually need. The idea of using something
like the URI scheme for discovery is so that we can tell someone about our
web service by specifying no more than the domain name and the service name
- e.g. "example.com" and "omnibroker". We don't need to be able to put that
anywhere on the web server, just somewhere that it isn't going to conflict.

Now chances are that the .well-known string and the SRV string (if
assigned) are going to be the same. So how about we could use the
.well-known registry for BOTH purposes?

So imagine my Web Service name is omnibroker

SRV Prefix: _omnibroker._well-known.example.com
URI stem: http://example.com/.well-known/omnibroker/

This would seem to cover all the bases. We can argue as to what the SRV
prefix should be. _well-known has two types of separator, maybe _ws would
be simpler.


Finally, we might want to also define a default URI scheme at the same
time, options for this would be:

omnibroker:example.com
ws:omnibroker:example.com

The first is a lot cleaner but probably involves more IETF plumbing than
people are going to accept. The second is pretty simple and has the
advantage that code knows that what is being dealt with here is a web
service type thing.

Note that if SRV discovery is being used there is no need to specify a
port. If SRV discovery is not to be used then the web service endpoint
would specify the port directly:

wks:omnibroker:example.com:80


This approach would effectively collapse what are currently three separate
requests into a single request. It would also encourage every web service
to make use of URI format identifiers.

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

--bcaec554d8e450b09b04d38367b0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

When setting up a web service it would be really nice to be able to use SRV=
 records for discovery.

That then sets up the question o=
f where to look for the service on the HTTP server which might be dedicated=
 to just one web service or support more than one.=A0



There is a DNS URI scheme that is intended to address t=
his issue but this gives more flexibility than we actually need. The idea o=
f using something like the URI scheme for discovery is so that we can tell =
someone about our web service by specifying no more than the domain name an=
d the service name - e.g. "example.com<=
/a>" and "omnibroker". We don't need to be able to put t=
hat anywhere on the web server, just somewhere that it isn't going to c=
onflict.=A0



Now chances are that the .well-known string and the SRV=
 string (if assigned) are going to be the same. So how about we could use t=
he .well-known registry for BOTH purposes?

So imag=
ine my Web Service name is omnibroker






This would seem to cover all the bases. We can argue as=
 to what the SRV prefix should be. _well-known has two types of separator, =
maybe _ws would be simpler.


Finally=
, we might want to also define a default URI scheme at the same time, optio=
ns for this would be:



omnibroker:example.com
ws:omnibroker:example.com

The first is a lot cleaner but probably involves mo=
re IETF plumbing than people are going to accept. The second is pretty simp=
le and has the advantage that code knows that what is being dealt with here=
 is a web service type thing.



Note that if SRV discovery is being used there is no ne=
ed to specify a port. If SRV discovery is not to be used then the web servi=
ce endpoint would specify the port directly:

wks:o=
mnibroker:example.com:80




This approach would effectively collapse=
 what are currently three separate requests into a single request. It would=
 also encourage every web service to make use of URI format identifiers.


--bcaec554d8e450b09b04d38367b0--

From nico@cryptonector.com  Thu Jan 17 14:39:30 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80AF21F89F9 for ; Thu, 17 Jan 2013 14:39:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-2.222, 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 tSl-AuQliKav for ; Thu, 17 Jan 2013 14:39:30 -0800 (PST)
Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3285B21F88BC for ; Thu, 17 Jan 2013 14:39:28 -0800 (PST)
Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id AA707438081 for ; Thu, 17 Jan 2013 14:39:28 -0800 (PST)
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=TXOQrvDsoNKHgwNtUN87 uHH3N10=; b=sVWMnCT+EexygRmizvswIskb+g6lj7Gm2Wdh53k5gKqMXrg1NcEU ygPpEfmJtc2dtUqrr2swAAmyWzJYeW8PCMjkMsG1N7S91b59tyLbfXFHM/yT3ryN OmlUIADELF8oCLT2PDi/u4ASY+RMULbOCpaMxGaORY+eWX4zabW+/DA=
Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 54AE9438072 for ; Thu, 17 Jan 2013 14:39:28 -0800 (PST)
Received: by mail-we0-f175.google.com with SMTP id z53so532476wey.6 for ; Thu, 17 Jan 2013 14:39:27 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.8.130 with SMTP id r2mr493048wia.28.1358462367120; Thu, 17 Jan 2013 14:39:27 -0800 (PST)
Received: by 10.217.82.73 with HTTP; Thu, 17 Jan 2013 14:39:26 -0800 (PST)
In-Reply-To: 
References: 
Date: Thu, 17 Jan 2013 16:39:26 -0600
Message-ID: 
From: Nico Williams 
To: Phillip Hallam-Baker 
Content-Type: text/plain; charset=UTF-8
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Using the .well-known registry for SRV (and other purposes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jan 2013 22:39:30 -0000

On Thu, Jan 17, 2013 at 4:20 PM, Phillip Hallam-Baker  wrote:
> Finally, we might want to also define a default URI scheme at the same time,
> options for this would be:
>
> omnibroker:example.com
> ws:omnibroker:example.com

The latter.  For the reasons you surmise.

> Note that if SRV discovery is being used there is no need to specify a port.
> If SRV discovery is not to be used then the web service endpoint would
> specify the port directly:
>
> wks:omnibroker:example.com:80

Well, we might use well-known to find the port number by asking the
server at port 80.

Would this say anything to the user-agent about how to authenticate
the service?  For example, when using Kerberos this might indicate to
the user-agent that the service principal should be
omnibroker/.  But we might need to be able to specify
naming/security options for other mechanisms (and even for Kerberos,
we might want to say what the realm is).

Anyways, I think I like this.  We badly need service discovery!

Nico
--

From hallam@gmail.com  Thu Jan 17 15:35:43 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE18921F863F for ; Thu, 17 Jan 2013 15:35:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.998
X-Spam-Level: 
X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 ux2HJwYiiwzk for ; Thu, 17 Jan 2013 15:35:43 -0800 (PST)
Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8C88821F86FF for ; Thu, 17 Jan 2013 15:35:42 -0800 (PST)
Received: by mail-lb0-f173.google.com with SMTP id gf7so1408964lbb.4 for ; Thu, 17 Jan 2013 15:35:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UDqa3S16AusD4ZhvW3DGBH0Z804tXUEgOQF+RjEDWEU=; b=ThnMHTOqDTQONSrcB7s0uIRtkdmfLICng/7rXHThZ3ZTjlfWC8pDEUAnPfo8CkYISR O5pf0/rkefdElGl93lvkwKOCBPFyq/qR4X25PPwkEcCLOTFoQUerwZL91oLoGcB1/vNr ZX7dPsym4O1tlvyEtYBtWZ1DdhEF8S7rUDUmt9+X3vY2Afo5zEfcJNrZPn1EslQo3dgO Q2x0yQznmzhfnf+CVgyfRNAB2npysGG5ZshjB1//GyyGrBMdVhV9U8mMlARpyCKq9lIS S0ale70XE+hYpJHB0sEwUqM5SsTiqEfJxvYAcvPHPamObb5agZUueEN1sf8PRPK0JuxD Uu5Q==
MIME-Version: 1.0
X-Received: by 10.152.46.17 with SMTP id r17mr25688lam.47.1358465741484; Thu, 17 Jan 2013 15:35:41 -0800 (PST)
Received: by 10.112.10.36 with HTTP; Thu, 17 Jan 2013 15:35:41 -0800 (PST)
In-Reply-To: 
References:  
Date: Thu, 17 Jan 2013 18:35:41 -0500
Message-ID: 
From: Phillip Hallam-Baker 
To: Nico Williams 
Content-Type: multipart/alternative; boundary=bcaec5524106f5f36d04d384734c
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Using the .well-known registry for SRV (and other purposes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jan 2013 23:35:44 -0000

--bcaec5524106f5f36d04d384734c
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 17, 2013 at 5:39 PM, Nico Williams wrote:

> On Thu, Jan 17, 2013 at 4:20 PM, Phillip Hallam-Baker 
> wrote:
> > Finally, we might want to also define a default URI scheme at the same
> time,
> > options for this would be:
> >
> > omnibroker:example.com
> > ws:omnibroker:example.com
>
> The latter.  For the reasons you surmise.


Yeah, I suspected as much.


> > Note that if SRV discovery is being used there is no need to specify a
> port.
> > If SRV discovery is not to be used then the web service endpoint would
> > specify the port directly:
> >
> > wks:omnibroker:example.com:80
>
> Well, we might use well-known to find the port number by asking the
> server at port 80.
>

I am not sure what you mean there. It is certainly possible to do an
internal redirect or an explicit redirect.

The idea I had for resolving the URI was as follows:

1) If the port is specified explicitly, use the specified port and domain
2) Otherwise, try to retrieve an SRV record at the specified domain
3) Otherwise, default to port 80

Which now strongly suggests that what we actually need are wk: and wks:
prefixes.

wk: use http, default port is 80
wks: use http over tls, default port is 443


Would this say anything to the user-agent about how to authenticate
> the service?  For example, when using Kerberos this might indicate to
> the user-agent that the service principal should be
> omnibroker/.  But we might need to be able to specify
> naming/security options for other mechanisms (and even for Kerberos,
> we might want to say what the realm is).
>

I don't see a need to specify that inband. We could certainly specify a
mechanism as part of HTTP authentication but I don't think we need to bring
that forward into the URI.



> Anyways, I think I like this.  We badly need service discovery!
>
> Nico
> --
>



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

--bcaec5524106f5f36d04d384734c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Thu, Jan 17, 2013 at 5:39 PM, Nico Wi=
lliams <nico@cryptonector.com> wrote:


On Thu, Jan 17, 2013 at 4:20 PM, Phillip Hallam-Baker <=
;hallam@gmail.com> wrote:

> Finally, we might want to also define a default URI scheme at the same=
 time,

> options for this would be:

>

> omnibroker:example.co=
m

> ws:omnibroker:example=
.com




The latter. =A0For the reasons you surmise.

Yeah, I suspected as much.
=A0



> Note that if SRV discovery is being used there is no need to specify a=
 port.

> If SRV discovery is not to be used then the web service endpoint would=


> specify the port directly:

>

> wks:omnibroker:exa=
mple.com:80




Well, we might use well-known to find the port number by asking the
server at port 80.

I am not sure what y=
ou mean there. It is certainly possible to do an internal redirect or an ex=
plicit redirect.

The idea I had for resolving the =
URI was as follows:



1) If the port is specified explicitly, use the specifi=
ed port and domain
2) Otherwise, try to retrieve an SRV record at=
 the specified domain
3) Otherwise, default to port 80


Which now strongly suggests that what we actually need are w=
k: and wks: prefixes.

wk: use http, default port i=
s 80
wks: use http over tls, default port is 443=A0




Would this say anything to the user-agent about how to authenticate

the service? =A0For example, when using Kerberos this might indicate to

the user-agent that the service principal should be

omnibroker/<server>. =A0But we might need to be able to specify

naming/security options for other mechanisms (and even for Kerberos,

we might want to say what the realm is).

I don't see a need to specify that inband. We could certainly specify=
 a mechanism as part of HTTP authentication but I don't think we need t=
o bring that forward into the URI.



=A0

Anyways, I think I like this. =A0We badly need service discovery!



Nico

--





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


--bcaec5524106f5f36d04d384734c--

From nico@cryptonector.com  Thu Jan 17 15:41:57 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A47021F8917 for ; Thu, 17 Jan 2013 15:41:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.082
X-Spam-Level: 
X-Spam-Status: No, score=-4.082 tagged_above=-999 required=5 tests=[AWL=-2.105, 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 3dUxrSi3rjuq for ; Thu, 17 Jan 2013 15:41:56 -0800 (PST)
Received: from homiemail-a88.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 3734F21F84F4 for ; Thu, 17 Jan 2013 15:41:56 -0800 (PST)
Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id D6B5F26405D for ; Thu, 17 Jan 2013 15:41:55 -0800 (PST)
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=aLvbVdzChztpGUp5pHgb DLJ4YN0=; b=ClKKzMmtbvkPxa9J3YU9OLxoK1xjJrbr5nETYf+sBtuQT0GR8bJE 4/35bqb0grlycex47magu4A1tb6hAFFiGP2FPf/2/h7duYTLPOEfjx1zOEEN/EOk 9FzSHtVEMH84QdGweEO2uEigwL94iMteOamdImg0VqwmoAF3KSCgR4Q=
Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (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 81056264058 for ; Thu, 17 Jan 2013 15:41:55 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id u3so565058wey.30 for ; Thu, 17 Jan 2013 15:41:54 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.80.73 with SMTP id p9mr11305999wjx.4.1358466114306; Thu, 17 Jan 2013 15:41:54 -0800 (PST)
Received: by 10.217.82.73 with HTTP; Thu, 17 Jan 2013 15:41:54 -0800 (PST)
In-Reply-To: 
References:   
Date: Thu, 17 Jan 2013 17:41:54 -0600
Message-ID: 
From: Nico Williams 
To: Phillip Hallam-Baker 
Content-Type: text/plain; charset=UTF-8
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Using the .well-known registry for SRV (and other purposes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jan 2013 23:41:57 -0000

On Thu, Jan 17, 2013 at 5:35 PM, Phillip Hallam-Baker  wrote:
> On Thu, Jan 17, 2013 at 5:39 PM, Nico Williams 
> wrote:
>> Would this say anything to the user-agent about how to authenticate
>> the service?  For example, when using Kerberos this might indicate to
>> the user-agent that the service principal should be
>> omnibroker/.  But we might need to be able to specify
>> naming/security options for other mechanisms (and even for Kerberos,
>> we might want to say what the realm is).
>
> I don't see a need to specify that inband. We could certainly specify a
> mechanism as part of HTTP authentication but I don't think we need to bring
> that forward into the URI.

But since we're doing service discovery, the discovery service can
tell us information we need *before* we start authentication.  For
example, it might tell us what CA issues the real servers' certs --
nothing else could do that (well, DNSSEC, that is, other discovery
mechanisms could) as we couldn't trust a server to tell us how to
authenticate it.

Nico
--

From hallam@gmail.com  Thu Jan 17 15:58:15 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B81621F888A for ; Thu, 17 Jan 2013 15:58:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.937
X-Spam-Level: 
X-Spam-Status: No, score=-2.937 tagged_above=-999 required=5 tests=[AWL=-1.373, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_URI_EQUALS=1.666, URI_HEX=0.368]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAM-ZXor5l9F for ; Thu, 17 Jan 2013 15:58:14 -0800 (PST)
Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id 322F721F884B for ; Thu, 17 Jan 2013 15:58:14 -0800 (PST)
Received: by mail-la0-f54.google.com with SMTP id gw10so2492763lab.27 for ; Thu, 17 Jan 2013 15:58:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7kMNjTFmdAqx3sxeu160o7Cqv/T8U4MNfTrDmhRmpcU=; b=PN6tnPjtcda/6IZ8lNZSCWWq3puwgN0A1adRhRdGRZbwxfZMkd3flwi2w6ZHbKhM7m +f5vHfWEhHrUGYBo3uYjMspkve6p1Vzvg0D5XQlZ4QWjbB1wtHV6SfyUClTdMazOxgvY 7FmAVxdfcIJpbvH+dXmIWT5SzgOKHBGkDtzr0cdk3a0eVd1VqJ62xs0rVKYprLD4s/1u Hu/lS4KsXjcigv1bRuccISyFUPQTLbaXVW0szXuc9/da3Lpuk4bb9MC3rQotBQDbyItX q6wXGS201CjoJYoO5ccCWpV6Coin30oscTjl+umfOR+fdMsMMGj+6wUbJ/cw/lBseAWK nO3w==
MIME-Version: 1.0
X-Received: by 10.152.102.177 with SMTP id fp17mr1829525lab.0.1358467093083; Thu, 17 Jan 2013 15:58:13 -0800 (PST)
Received: by 10.112.10.36 with HTTP; Thu, 17 Jan 2013 15:58:12 -0800 (PST)
In-Reply-To: 
References:    
Date: Thu, 17 Jan 2013 18:58:12 -0500
Message-ID: 
From: Phillip Hallam-Baker 
To: Nico Williams 
Content-Type: multipart/alternative; boundary=f46d0408d69b85b4f504d384c48a
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Using the .well-known registry for SRV (and other purposes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jan 2013 23:58:15 -0000

--f46d0408d69b85b4f504d384c48a
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 17, 2013 at 6:41 PM, Nico Williams wrote:

> On Thu, Jan 17, 2013 at 5:35 PM, Phillip Hallam-Baker 
> wrote:
> > On Thu, Jan 17, 2013 at 5:39 PM, Nico Williams 
> > wrote:
> >> Would this say anything to the user-agent about how to authenticate
> >> the service?  For example, when using Kerberos this might indicate to
> >> the user-agent that the service principal should be
> >> omnibroker/.  But we might need to be able to specify
> >> naming/security options for other mechanisms (and even for Kerberos,
> >> we might want to say what the realm is).
> >
> > I don't see a need to specify that inband. We could certainly specify a
> > mechanism as part of HTTP authentication but I don't think we need to
> bring
> > that forward into the URI.
>
> But since we're doing service discovery, the discovery service can
> tell us information we need *before* we start authentication.  For
> example, it might tell us what CA issues the real servers' certs --
> nothing else could do that (well, DNSSEC, that is, other discovery
> mechanisms could) as we couldn't trust a server to tell us how to
> authenticate it.
>

Oh you mean add the CA key fingerprint to the service URI?

wks:omnibroker:example.com:ca=
6ac3c336e4094835293a3fed8a4b5fedde1b5e2626d9838fed50693bba00af0e

Or similar DANE like things.


We could do that but the amount of arguing involved would be significant.

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

--f46d0408d69b85b4f504d384c48a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Thu, Jan 17, 2013 at 6:41 PM, Nico Wi=
lliams <nico@cryptonector.com> wrote:


On Thu, Jan 17, 2013 at 5:35 PM, Phillip Hallam-Baker <=
;hallam@gmail.com> wrote:

> On Thu, Jan 17, 2013 at 5:39 PM, Nico Williams <nico@cryptonector.com>

> wrote:


>> Would this say anything to the user-agent =
about how to authenticate

>> the service? =A0For example, when using Kerberos this might indica=
te to

>> the user-agent that the service principal should be

>> omnibroker/<server>. =A0But we might need to be able to spec=
ify

>> naming/security options for other mechanisms (and even for Kerbero=
s,

>> we might want to say what the realm is).

>

> I don't see a need to specify that inband. We could certainly spec=
ify a

> mechanism as part of HTTP authentication but I don't think we need=
 to bring

> that forward into the URI.




But since we're doing service discovery, the discovery service ca=
n

tell us information we need *before* we start authentication. =A0For

example, it might tell us what CA issues the real servers' certs --

nothing else could do that (well, DNSSEC, that is, other discovery

mechanisms could) as we couldn't trust a server to tell us how to

authenticate it.

Oh you mean add the CA=
 key fingerprint to the service URI?

wks:omnibroke=
r:example.com:ca=3D6ac3c336e4094835293a3fed8a4b5fedde1b5e2626d9838fed50693bba0=
0af0e



Or similar DANE like things.


We could do that but the amount of arguing involved would=
 be significant.



-- 
Website: ht=
tp://hallambaker.com/


--f46d0408d69b85b4f504d384c48a--

From nico@cryptonector.com  Thu Jan 17 16:03:17 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB8121F8972 for ; Thu, 17 Jan 2013 16:03:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.977
X-Spam-Level: 
X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 uXi+D24NxRuo for ; Thu, 17 Jan 2013 16:03:17 -0800 (PST)
Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id F26AC21F8971 for ; Thu, 17 Jan 2013 16:03:16 -0800 (PST)
Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id AD8BF678055 for ; Thu, 17 Jan 2013 16:03:16 -0800 (PST)
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=X4AdACO3fFucjN1EojCH H2ylFwU=; b=mbP0Eg49TIiMUrBqHMC3G5ppZTLKCS5kVUk7jXRvtV6gZCb7nAkh Nqe20VCYI1o/wIGdo3qw9lv2UhoHkgz5jp3eS3QZUVoWpPQrUTTBni7m7wWSfpKK aGh/uIidH5hdDEbsJoJlCq4a+tWFmiYFhkEmE/HlFQyQuqFmZfJEIjY=
Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 58235678063 for ; Thu, 17 Jan 2013 16:03:16 -0800 (PST)
Received: by mail-we0-f176.google.com with SMTP id r5so570965wey.35 for ; Thu, 17 Jan 2013 16:03:15 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.80.73 with SMTP id p9mr11362567wjx.4.1358467394997; Thu, 17 Jan 2013 16:03:14 -0800 (PST)
Received: by 10.217.82.73 with HTTP; Thu, 17 Jan 2013 16:03:14 -0800 (PST)
In-Reply-To: 
References:     
Date: Thu, 17 Jan 2013 18:03:14 -0600
Message-ID: 
From: Nico Williams 
To: Phillip Hallam-Baker 
Content-Type: text/plain; charset=UTF-8
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Using the .well-known registry for SRV (and other purposes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 00:03:17 -0000

On Thu, Jan 17, 2013 at 5:58 PM, Phillip Hallam-Baker  wrote:
> We could do that but the amount of arguing involved would be significant.

What an optimist!  :)

From nico@cryptonector.com  Thu Jan 17 20:39:15 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B5921F8ABA for ; Thu, 17 Jan 2013 20:39:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.858
X-Spam-Level: 
X-Spam-Status: No, score=-4.858 tagged_above=-999 required=5 tests=[AWL=-2.881, 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 ua13gseQxaV2 for ; Thu, 17 Jan 2013 20:39:14 -0800 (PST)
Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3B79E21F8A35 for ; Thu, 17 Jan 2013 20:39:13 -0800 (PST)
Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 4AF93678075 for ; Thu, 17 Jan 2013 20:39:03 -0800 (PST)
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=19S0B0tL4QhjNA6FYq+v Ozy1l1o=; b=FiVIbufhJuTZEnmpBUUZkaB0tkbtkKN+0mbDoI8FuWE/PPsySZnx VAIGE20ffOWN3leXaxUF9UB0cTskTHi+bjgb5gGcRem8XoXb765zxpl9Hpzz8Hq4 UWxp8r8ALtAFcw7+wAKTocNK1NkLJcyguV5LCGFTpds03lRLa8Tctd0=
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id E70E7678071 for ; Thu, 17 Jan 2013 20:39:02 -0800 (PST)
Received: by mail-wi0-f176.google.com with SMTP id hm6so4986236wib.9 for ; Thu, 17 Jan 2013 20:39:01 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.33.44 with SMTP id o12mr1411812wii.28.1358483941551; Thu, 17 Jan 2013 20:39:01 -0800 (PST)
Received: by 10.217.82.73 with HTTP; Thu, 17 Jan 2013 20:39:01 -0800 (PST)
In-Reply-To: 
References: 
Date: Thu, 17 Jan 2013 22:39:01 -0600
Message-ID: 
From: Nico Williams 
To: Barry Leiba 
Content-Type: text/plain; charset=UTF-8
Cc: Apps Discuss 
Subject: Re: [apps-discuss] The "array vs object" issue in JSON Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 04:39:15 -0000

On Wed, Jan 16, 2013 at 12:18 PM, Barry Leiba  wrote:
> Consider these points:
>
> 1. Failing to make the distinction now pretty much locks us into it
> for good.  What we have might meet the use cases we have now, but are
> we really sure we're never going to regret that, that next week or
> next month or next year we might not have a new use case that tips the
> balance?

For some purposes this is true, and for some it isn't.  In any case,
this is only a problem if it is a problem to not indicate the type of
a container at any point in the Pointer path.  Let's set #1 aside --
it is not the fundamental issue here.

> 2. There's running code, but *if* we're going to make a change, now's
> the time, and the running code can be changed.  If, as we say, the
> current uses of Pointer know whether they're talking about arrays or
> objects, then the code can be changed to use the appropriate syntax
> for the appropriate type.  How hard is it, *really*, to change this?

If there's a serious bug then "but there's running code" is not a
problem.  But if there isn't then #2 becomes a serious impediment to
making changes to JSON Pointer now.  Changing running code is hard, so
we need strong justification for doing so.

> 3. On the other side, the heartburn is exacerbated by the fact that
> JSON Patch applies the same operations differently for arrays and
> objects.  That's an issue with Patch, not with Pointer, but it's hard
> not to blend them and say that distinguishing the syntax for Pointer
> would at least partially meliorate the issue in Patch.

Many, many programming languages provide generic syntax for indexing
several types of containers where the syntax indicates nothing about
the container type.

This is not new.  I don't think it's a problem here.  I also don't
think it's a problem in any one programming language (so maybe it
prevents type inference, but so what, if I want a language with strong
typing and type inferencing then I'll use one that provides that).

Note that not one of the above issues is serious.  Not one of them
points to something that breaks because JSON Pointer has no way to
indicate the _expected_ type of containers in path.

And by the way, I think there are more serious issues with JSON
Pointer.  Quick, what's ~0, and what's ~1?  Is ~0 / and ~1 ~, or is it
the other way around?!  This is extremely annoying.  It's a wart, but
not a fundamental problem, so let's let it slide.

But maybe we can think of new ~ escapes that can be used to indicate
expected container types.  A specific proposal for how to add type
expectation would help those arguing that we must address that now.
So I'd propose ~A at the beginning of a component means "this had
better be an array or I'll have a kitten" and ~O means "this better be
an object or I'll eat a kitten".

> Given those considerations, the question is this: Does the working
> group stand by its rough consensus for the JSON Pointer syntax as it
> stands?  Or might it be better to make a syntactic distinction between
> arrays and objects now, while we can, to be more robust for the
> future?  (Or, on the other hand, for those who have three hands, would
> it actually *harm* the protocol to change this?)

Looking back over this thread the answer to the first question is "yes".

But if someone were to make a specific proposal then maybe the answer
would be different.

Nico
--

From paf@frobbit.se  Thu Jan 17 21:32:37 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFAD21F8C01 for ; Thu, 17 Jan 2013 21:32:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-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 UOhjE74sOhUe for ; Thu, 17 Jan 2013 21:32:37 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id B9F5F21F8B90 for ; Thu, 17 Jan 2013 21:32:36 -0800 (PST)
Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) by mail.frobbit.se (Postfix) with ESMTPSA id DF9BF205B9; Fri, 18 Jan 2013 06:32:34 +0100 (CET)
Content-Type: multipart/alternative; boundary="Apple-Mail=_99F12466-CD02-44C6-A29D-1ADFD45223D8"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
In-Reply-To: 
Date: Fri, 18 Jan 2013 06:32:34 +0100
Message-Id: <2644CBB3-5D5E-4247-A79F-430B7358EAA4@frobbit.se>
References: 
To: Phillip Hallam-Baker 
X-Mailer: Apple Mail (2.1499)
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Using the .well-known registry for SRV (and other purposes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 05:32:37 -0000

--Apple-Mail=_99F12466-CD02-44C6-A29D-1ADFD45223D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On 17 jan 2013, at 23:20, Phillip Hallam-Baker  wrote:

> There is a DNS URI scheme that is intended to address this issue but =
this gives more flexibility than we actually need. The idea of using =
something like the URI scheme for discovery is so that we can tell =
someone about our web service by specifying no more than the domain name =
and the service name - e.g. "example.com" and "omnibroker". We don't =
need to be able to put that anywhere on the web server, just somewhere =
that it isn't going to conflict.=20

Can you expand on this please.

When reading what you write, I thought this was exactly what you =
described:

_omnibroker._well-known.example.com. IN URL ....

   Patrik


--Apple-Mail=_99F12466-CD02-44C6-A29D-1ADFD45223D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

hallam@gmail.com> =
wrote:

There is a DNS URI scheme that is =
intended to address this issue but this gives more flexibility than we =
actually need. The idea of using something like the URI scheme for =
discovery is so that we can tell someone about our web service by =
specifying no more than the domain name and the service name - e.g. =
"" and "omnibroker". We don't need to =
be able to put that anywhere on the web server, just somewhere that it =
isn't going to conflict. 

Can you =
expand on this please.

When reading what you =
write, I thought this was exactly what you =
described:


  =
 Patrik

=

--Apple-Mail=_99F12466-CD02-44C6-A29D-1ADFD45223D8--

From paf@frobbit.se  Thu Jan 17 21:39:38 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD5D21F85D0 for ; Thu, 17 Jan 2013 21:39:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[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 4IQj+2zfy-Ie for ; Thu, 17 Jan 2013 21:39:35 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 5675021F845A for ; Thu, 17 Jan 2013 21:39:35 -0800 (PST)
Received: from [192.165.72.14] (unknown [192.165.72.14]) by mail.frobbit.se (Postfix) with ESMTPSA id AD3B220539; Fri, 18 Jan 2013 06:39:34 +0100 (CET)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
In-Reply-To: <2644CBB3-5D5E-4247-A79F-430B7358EAA4@frobbit.se>
Date: Fri, 18 Jan 2013 06:39:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <718EC148-9317-4419-8CDF-AB45CFA4C5D9@frobbit.se>
References:  <2644CBB3-5D5E-4247-A79F-430B7358EAA4@frobbit.se>
To: Phillip Hallam-Baker 
X-Mailer: Apple Mail (2.1499)
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Using the .well-known registry for SRV (and other purposes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 05:39:38 -0000

On 18 jan 2013, at 06:32, Patrik F=E4ltstr=F6m  wrote:

> On 17 jan 2013, at 23:20, Phillip Hallam-Baker  =
wrote:
>=20
>> There is a DNS URI scheme that is intended to address this issue but =
this gives more flexibility than we actually need. The idea of using =
something like the URI scheme for discovery is so that we can tell =
someone about our web service by specifying no more than the domain name =
and the service name - e.g. "example.com" and "omnibroker". We don't =
need to be able to put that anywhere on the web server, just somewhere =
that it isn't going to conflict.=20
>=20
> Can you expand on this please.
>=20
> When reading what you write, I thought this was exactly what you =
described:
>=20
> _omnibroker._well-known.example.com. IN URL ....

Sigh, before morning coffee...

_omnibroker._well-known.example.com. IN URI 0 0 =
"scheme://host:port/more_stuff"

   Patrik



From hallam@gmail.com  Thu Jan 17 22:02:36 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAF421F8BA7 for ; Thu, 17 Jan 2013 22:02:36 -0800 (PST)
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.368, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3VYI8drwMvV4 for ; Thu, 17 Jan 2013 22:02:34 -0800 (PST)
Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by ietfa.amsl.com (Postfix) with ESMTP id 325EA21F8B46 for ; Thu, 17 Jan 2013 22:02:34 -0800 (PST)
Received: by mail-la0-f50.google.com with SMTP id er20so1764102lab.37 for ; Thu, 17 Jan 2013 22:02:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PK7I0Kj5gYtsGjBjULnJA1uewq/kcfhowg90avugERs=; b=OZnYoPokvpnk+LP4sJZiG53jm5PvP549a7xHMWtk3sOUu3/5SYeZNHFOsuBzHtpaHc d6wx1KzK4qBpZVtflbZY+zA7rwt8gYacZ9V7CrGiUWPqe1SsnVNGC8MP710GJ3OGs5MY +oZqS4kdzxAfG7fd8LBJu1ZdLifzgozJi1rKwi1sdJs8oknvZTwdxCywgsHcSBYS0yod 48RaXb8Ce1TYamX3PgkFS4PLfOeGh4Sb0uXUuzEdklo7Djyz91K5Th80mot66OdhWO/E AZH+uzBULf11rOGfrGwSQxP0Z3ky4vfTzKGAbGL+61C97eaB/BfCsA9CTLGOe02+bwr0 9DDw==
MIME-Version: 1.0
X-Received: by 10.152.108.48 with SMTP id hh16mr7241027lab.25.1358488952863; Thu, 17 Jan 2013 22:02:32 -0800 (PST)
Received: by 10.112.10.36 with HTTP; Thu, 17 Jan 2013 22:02:32 -0800 (PST)
In-Reply-To: <718EC148-9317-4419-8CDF-AB45CFA4C5D9@frobbit.se>
References:  <2644CBB3-5D5E-4247-A79F-430B7358EAA4@frobbit.se> <718EC148-9317-4419-8CDF-AB45CFA4C5D9@frobbit.se>
Date: Fri, 18 Jan 2013 01:02:32 -0500
Message-ID: 
From: Phillip Hallam-Baker 
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
Content-Type: multipart/alternative; boundary=bcaec54fb9d2777bf704d389dbe5
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Using the .well-known registry for SRV (and other purposes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 06:02:36 -0000

--bcaec54fb9d2777bf704d389dbe5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

My point is that in the context of mashing the .well-known registry and the
DNS prefix registry together, we have already decided that the deployer
does not get to choose where the endpoint goes on the Web server.

So URI gives us more flexibility, but not flexibility that we necessarily
need. We certainly don't need the URI stem part at any rate.


What would have value though is being able to specify the protocol. For
example:

_omnibroker._well-known.example.com. IN URI 0 0 "
http://w1.example.com/.well-known/omnibroker/"
_omnibroker._well-known.example.com. IN URI 0 0 "https://
w1.example.com/.well-known/omnibroker/"
_omnibroker._well-known.example.com. IN URI 0 0 "coap://
w1.example.com/.well-known/omnibroker/"

That lets us extend the signalling to give the transport and in particular
specify whether to use http or http over SSL.

Switching to http2 could also be signaled in the same way.


So I didn't see a use for URI for the stem part alone, but the scheme part
is certainly useful. And if we are using URI then of course we would let
the URI specify the stem and this would be an eventual route out of
.well-known

So the discovery would be

1) If there is a port specified on the URI (wk:omnibroker://example.com:80/=
)
then use the speficied domain and port

2) Otherwise use URI for discovery

3) Otherwise try the default port and http for wk or https for wks


What I do think is that we should either choose SRV or URI not have a
choice or both.

On Fri, Jan 18, 2013 at 12:39 AM, Patrik F=E4ltstr=F6m  wro=
te:

> On 18 jan 2013, at 06:32, Patrik F=E4ltstr=F6m  wrote:
>
> > On 17 jan 2013, at 23:20, Phillip Hallam-Baker  wrote=
:
> >
> >> There is a DNS URI scheme that is intended to address this issue but
> this gives more flexibility than we actually need. The idea of using
> something like the URI scheme for discovery is so that we can tell someon=
e
> about our web service by specifying no more than the domain name and the
> service name - e.g. "example.com" and "omnibroker". We don't need to be
> able to put that anywhere on the web server, just somewhere that it isn't
> going to conflict.
> >
> > Can you expand on this please.
> >
> > When reading what you write, I thought this was exactly what you
> described:
> >
> > _omnibroker._well-known.example.com. IN URL ....
>
> Sigh, before morning coffee...
>
> _omnibroker._well-known.example.com. IN URI 0 0
> "scheme://host:port/more_stuff"
>
>    Patrik
>
>
>


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

--bcaec54fb9d2777bf704d389dbe5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

My point is that in the context of mashing the .well-known registry and the=
 DNS prefix registry together, we have already decided that the deployer do=
es not get to choose where the endpoint goes on the Web server.



So URI gives us more flexibility, but not flexibility that we ne=
cessarily need. We certainly don't need the URI stem part at any rate.<=
/div>


What would have value though is bei=
ng able to specify the protocol. For example:







That lets us extend the sig=
nalling to give the transport and in particular specify whether to use http=
 or http over SSL.



Switching to http2 could al=
so be signaled in the same way.




So I didn't see a use for URI for the stem part alone, but the=
 scheme part is certainly useful. And if we are using URI then of course we=
 would let the URI specify the stem and this would be an eventual route out=
 of .well-known



So the discovery would be



1) If there is a port speci=
fied on the URI (wk:omnibroker://example=
.com:80/) then use the speficied domain and port



2) Otherwise use URI for di=
scovery



3) Otherwise try the defaul=
t port and http for wk or https for wks




What I do think is that we should either choose SRV or URI not hav=
e a choice or both.



On Fri, Jan 18, 20=
13 at 12:39 AM, Patrik F=E4ltstr=F6m <paf@frobbit.se> wrote:

On 1=
8 jan 2013, at 06:32, Patrik F=E4ltstr=F6m <paf@frobbit.se> wrote:




> On 17 jan 2013, at 23:20, Phillip Hallam-Baker <hallam@gmail.com> wrote:

>

>> There is a DNS URI scheme that is intended to address this issue b=
ut this gives more flexibility than we actually need. The idea of using som=
ething like the URI scheme for discovery is so that we can tell someone abo=
ut our web service by specifying no more than the domain name and the servi=
ce name - e.g. "examp=
le.com" and "omnibroker". We don't need to be able t=
o put that anywhere on the web server, just somewhere that it isn't goi=
ng to conflict.


>

> Can you expand on this please.

>

> When reading what you write, I thought this was exactly what you descr=
ibed:

>

> _omnibroker._well-known.example.com. IN URL ....




Sigh, before morning coffee...



_omnibroker._we=
ll-known.example.com. IN URI 0 0 "scheme://host:port/more_stuff&qu=
ot;



=A0 =A0Patrik









-- Website: http://hallambaker.com/<=
br>



--bcaec54fb9d2777bf704d389dbe5--

From hallam@gmail.com  Thu Jan 17 22:06:44 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071AE21F8BAB for ; Thu, 17 Jan 2013 22:06:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.633
X-Spam-Level: 
X-Spam-Status: No, score=-3.633 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 qpevThf6aTyH for ; Thu, 17 Jan 2013 22:06:42 -0800 (PST)
Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id BD70921F8BA7 for ; Thu, 17 Jan 2013 22:06:41 -0800 (PST)
Received: by mail-lb0-f177.google.com with SMTP id gm6so304654lbb.22 for ; Thu, 17 Jan 2013 22:06:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yq5VOeREtOqmWDvI4U2Md47gRsInvCqHYARd8+Dc6Lo=; b=p9ZY54k0GT67Sq0LOe7Cp8dlPYLLXEJn7kwIZ0UAaA9gsUHl918nZxKuwGPsPF43qw PRWPP4en7yvms+iJqZW9YQ6K52NLSwY0pE0pEzs8dd3fL0tib2s2LESie3L6zXloHoK4 u8M4gfVFHpRMnZHhaC2/wzQuOCu4Pkad/olJT5Xa6hiSa+CU/fGDXB59SIc8up9TNUm2 cm+tMM08xg3tMcnan65K6nUXMdNPDWI4cv3vCEImCctzQCKfF342Oce+ZShgtA0AhAP7 FUrwZwGtyXmlHfPovhdnxfzsWLaR3ghursuoFTX+0Q2ikn37GBL7h18wG6PDL7mCq8Q9 B2BQ==
MIME-Version: 1.0
X-Received: by 10.112.11.105 with SMTP id p9mr3124026lbb.129.1358489200456; Thu, 17 Jan 2013 22:06:40 -0800 (PST)
Received: by 10.112.10.36 with HTTP; Thu, 17 Jan 2013 22:06:40 -0800 (PST)
In-Reply-To: <718EC148-9317-4419-8CDF-AB45CFA4C5D9@frobbit.se>
References:  <2644CBB3-5D5E-4247-A79F-430B7358EAA4@frobbit.se> <718EC148-9317-4419-8CDF-AB45CFA4C5D9@frobbit.se>
Date: Fri, 18 Jan 2013 01:06:40 -0500
Message-ID: 
From: Phillip Hallam-Baker 
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
Content-Type: multipart/alternative; boundary=bcaec54eeaea39758d04d389ea40
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Using the .well-known registry for SRV (and other purposes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 06:06:44 -0000

--bcaec54eeaea39758d04d389ea40
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

My point is that in the context of mashing the .well-known registry and the
DNS prefix registry together, we have already decided that the deployer
does not get to choose where the endpoint goes on the Web server.

So URI gives us more flexibility, but not flexibility that we necessarily
need. We certainly don't need the URI stem part at any rate.


What would have value though is being able to specify the protocol. For
example:

_omnibroker._well-known.example.com. IN URI 0 0 "
http://w1.example.com/.well-known/omnibroker/"
_omnibroker._well-known.example.com. IN URI 0 0 "https://
w1.example.com/.well-known/omnibroker/"
_omnibroker._well-known.example.com. IN URI 0 0 "coap://
w1.example.com/.well-known/omnibroker/"

That lets us extend the signalling to give the transport and in particular
specify whether to use http or http over SSL.

Switching to http2 could also be signaled in the same way.


So I didn't see a use for URI for the stem part alone, but the scheme part
is certainly useful. And if we are using URI then of course we would let
the URI specify the stem and this would be an eventual route out of
.well-known

So the discovery would be

1) If there is a port specified on the URI (wk:omnibroker://example.com:80/=
)
then use the speficied domain and port



On Fri, Jan 18, 2013 at 12:39 AM, Patrik F=E4ltstr=F6m  wro=
te:

> On 18 jan 2013, at 06:32, Patrik F=E4ltstr=F6m  wrote:
>
> > On 17 jan 2013, at 23:20, Phillip Hallam-Baker  wrote=
:
> >
> >> There is a DNS URI scheme that is intended to address this issue but
> this gives more flexibility than we actually need. The idea of using
> something like the URI scheme for discovery is so that we can tell someon=
e
> about our web service by specifying no more than the domain name and the
> service name - e.g. "example.com" and "omnibroker". We don't need to be
> able to put that anywhere on the web server, just somewhere that it isn't
> going to conflict.
> >
> > Can you expand on this please.
> >
> > When reading what you write, I thought this was exactly what you
> described:
> >
> > _omnibroker._well-known.example.com. IN URL ....
>
> Sigh, before morning coffee...
>
> _omnibroker._well-known.example.com. IN URI 0 0
> "scheme://host:port/more_stuff"
>
>    Patrik
>
>
>


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

--bcaec54eeaea39758d04d389ea40
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

My point is that in the context of mashing the .well-known registry and the=
 DNS prefix registry together, we have already decided that the deployer do=
es not get to choose where the endpoint goes on the Web server.




So URI gives us more flexibility, but not flexibility that we ne=
cessarily need. We certainly don't need the URI stem part at any rate.<=
/div>


What would have value though is bei=
ng able to specify the protocol. For example:










That lets us extend the sig=
nalling to give the transport and in particular specify whether to use http=
 or http over SSL.




Switching to http2 could al=
so be signaled in the same way.





So I didn't see a use for URI for the stem part alone, but the=
 scheme part is certainly useful. And if we are using URI then of course we=
 would let the URI specify the stem and this would be an eventual route out=
 of .well-known




So the discovery would be




1) If there is a port speci=
fied on the URI (wk:omnibroker://example.com:80/) then use the speficied domain and port









On Fri, Jan 18, 2013 at 12:39 AM, =
Patrik F=E4ltstr=F6m <paf@frobbit.se> wrote:



On 18 jan 2013, at 06:32, Patrik F=E4ltstr=F6m <paf@frobbit.se> wrote:



> On 17 jan 2013, at 23:20, Phillip Hallam-Baker <hallam@gmail.com> wrote:

>

>> There is a DNS URI scheme that is intended to address this issue b=
ut this gives more flexibility than we actually need. The idea of using som=
ething like the URI scheme for discovery is so that we can tell someone abo=
ut our web service by specifying no more than the domain name and the servi=
ce name - e.g. "examp=
le.com" and "omnibroker". We don't need to be able t=
o put that anywhere on the web server, just somewhere that it isn't goi=
ng to conflict.



>

> Can you expand on this please.

>

> When reading what you write, I thought this was exactly what you descr=
ibed:

>

> _omnibroker._well-known.example.com. IN URL ....




Sigh, before morning coffee...



_omnibroker._we=
ll-known.example.com. IN URI 0 0 "scheme://host:port/more_stuff&qu=
ot;



=A0 =A0Patrik









-- Website: http://hal=
lambaker.com/



--bcaec54eeaea39758d04d389ea40--

From mnot@mnot.net  Thu Jan 17 23:24:23 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCAE21F8A18 for ; Thu, 17 Jan 2013 23:24:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.226
X-Spam-Level: 
X-Spam-Status: No, score=-105.226 tagged_above=-999 required=5 tests=[AWL=-2.627, 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 SrJTuRoNZism for ; Thu, 17 Jan 2013 23:24:21 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D3D4B21F89CB for ; Thu, 17 Jan 2013 23:24:21 -0800 (PST)
Received: from [192.168.1.80] (unknown [118.209.240.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5557822E200 for ; Fri, 18 Jan 2013 02:24:15 -0500 (EST)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net>
Date: Fri, 18 Jan 2013 18:24:11 +1100
To: Apps Discuss 
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Subject: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 07:24:23 -0000

It's becoming apparent that there are likely to be a few different =
flavours of JSON Patch out there, so it may make sense to give the one =
we're working on now a bit more of a distinctive name.

I'd suggest Simple JSON Patch, with the media type =
application/simple-json-patch.

I've talked to Murray and Barry about it, but wanted to make sure people =
here (especially those who might already be using it) a heads-up. Make =
sense? Any concerns?

Cheers,

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




From duerst@it.aoyama.ac.jp  Fri Jan 18 00:12:01 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F255321F8919 for ; Fri, 18 Jan 2013 00:12:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.293
X-Spam-Level: 
X-Spam-Status: No, score=-103.293 tagged_above=-999 required=5 tests=[AWL=-3.503, 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 rQf6wISPbrFj for ; Fri, 18 Jan 2013 00:12:00 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 332F621F88CA for ; Fri, 18 Jan 2013 00:11:59 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r0I8BqQE006753 for ; Fri, 18 Jan 2013 17:11:52 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 6c18_bbd2_b7686300_6146_11e2_b493_001d096c566a; Fri, 18 Jan 2013 17:11:51 +0900
Received: from [IPv6:::1] ([133.2.210.1]:33916) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Fri, 18 Jan 2013 17:11:54 +0900
Message-ID: <50F903BF.1050903@it.aoyama.ac.jp>
Date: Fri, 18 Jan 2013 17:11:43 +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: Barry Leiba 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps Discuss 
Subject: Re: [apps-discuss] The "array vs object" issue in JSON Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 08:12:01 -0000

Hello Barry, others,

I have thought about this a bit. I'm totally fine with the current state 
of things. The reason for this is that JavaScript itself also allows me 
to be totally ignorant of whether I'm using arrays or objects if I use 
indexing with [] and string values inside.

So given that we would know by now about this being a serious problem in 
JavaScript if it were one, but that I have seen a lot of different 
problems discussed for JavaScript, but not this one, I think we can 
safely ignore it.

This is different e.g. from child elements vs. attributes in XPointer, 
because there can be a child element (actually more than one) and an 
attribute of the same name.

Regards,    Martin.

On 2013/01/17 3:18, Barry Leiba wrote:
> As everyone who's been reading the JSON threads knows, there's been
> controversy about one aspect of JSON pointer: specifically, that while
> JSON itself makes a distinction between arrays and objects, the JSON
> Pointer syntax does not.  Users of the pointers have to know what
> they're pointing to (or have to be in an application situation where
> it doesn't matter).
>
> It's clear that the discussion has been had, that the working group
> has rough consensus on the document as it stands, that what we have
> meets the current use cases and represents running code, and that
> those pushing for a change to this, to make a syntactic distinction
> between a pointer to an array element and one to an object member, are
> in the rough.
>
> That said, I find the arguments for the change sufficiently compelling
> to ask folks to have one more think on it.  I do NOT want to make this
> a free-for-all where we have the whole argument all over again.  We
> all know what's been said.  Carsten's note about its coming down to
> how strong you want the typing to be is a useful one.  So I want to
> ask the question a particular way.
>
> Consider these points:
>
> 1. Failing to make the distinction now pretty much locks us into it
> for good.  What we have might meet the use cases we have now, but are
> we really sure we're never going to regret that, that next week or
> next month or next year we might not have a new use case that tips the
> balance?
>
> 2. There's running code, but *if* we're going to make a change, now's
> the time, and the running code can be changed.  If, as we say, the
> current uses of Pointer know whether they're talking about arrays or
> objects, then the code can be changed to use the appropriate syntax
> for the appropriate type.  How hard is it, *really*, to change this?
>
> 3. On the other side, the heartburn is exacerbated by the fact that
> JSON Patch applies the same operations differently for arrays and
> objects.  That's an issue with Patch, not with Pointer, but it's hard
> not to blend them and say that distinguishing the syntax for Pointer
> would at least partially meliorate the issue in Patch.
>
> Given those considerations, the question is this: Does the working
> group stand by its rough consensus for the JSON Pointer syntax as it
> stands?  Or might it be better to make a syntactic distinction between
> arrays and objects now, while we can, to be more robust for the
> future?  (Or, on the other hand, for those who have three hands, would
> it actually *harm* the protocol to change this?)
>
> Again, repeating:
> Of course the rough consensus in appsawg is what wins, and if
> everyone's *really sure* that we want to go ahead with things as they
> are, then we will.  The IESG has already given its approval for that.
> I'd just like people to take a moment to be certain about that before
> we move on.
>
> Barry, trying to be responsible as AD
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From duerst@it.aoyama.ac.jp  Fri Jan 18 02:57:10 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A8221F892D for ; Fri, 18 Jan 2013 02:57:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.074
X-Spam-Level: 
X-Spam-Status: No, score=-103.074 tagged_above=-999 required=5 tests=[AWL=-3.284, 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 8c3paex4B9WW for ; Fri, 18 Jan 2013 02:57:09 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id F24DC21F892A for ; Fri, 18 Jan 2013 02:57:02 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r0IAut5O026218 for ; Fri, 18 Jan 2013 19:56:58 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 6c1b_b5c2_c600eb1e_615d_11e2_a502_001d096c566a; Fri, 18 Jan 2013 19:56:54 +0900
Received: from [IPv6:::1] ([133.2.210.1]:44163) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Fri, 18 Jan 2013 19:56:57 +0900
Message-ID: <50F92A6D.1030105@it.aoyama.ac.jp>
Date: Fri, 18 Jan 2013 19:56:45 +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: Mark Nottingham 
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net>
In-Reply-To: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps Discuss 
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 10:57:10 -0000

Shouldn't the name end in +json, because the patch data itself is JSON?

And couldn't the simple one just have a simple name (as simple as 
leaving out the "simple")? Others can then still invent their own names, 
there's no shortage of them.

Regards,   Martin.

On 2013/01/18 16:24, Mark Nottingham wrote:
> It's becoming apparent that there are likely to be a few different flavours of JSON Patch out there, so it may make sense to give the one we're working on now a bit more of a distinctive name.
>
> I'd suggest Simple JSON Patch, with the media type application/simple-json-patch.
>
> I've talked to Murray and Barry about it, but wanted to make sure people here (especially those who might already be using it) a heads-up. Make sense? Any concerns?
>
> Cheers,
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From mnot@mnot.net  Fri Jan 18 02:59:54 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0867F21F8936 for ; Fri, 18 Jan 2013 02:59:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.003
X-Spam-Level: 
X-Spam-Status: No, score=-105.003 tagged_above=-999 required=5 tests=[AWL=-2.704, BAYES_00=-2.599, 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 jIfEvoOPmiJC for ; Fri, 18 Jan 2013 02:59:53 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6752D21F8931 for ; Fri, 18 Jan 2013 02:59:53 -0800 (PST)
Received: from [192.168.1.80] (unknown [118.209.240.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BBE8822E257; Fri, 18 Jan 2013 05:59:46 -0500 (EST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: <50F92A6D.1030105@it.aoyama.ac.jp>
Date: Fri, 18 Jan 2013 21:59:42 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <16C16775-CCE9-4010-9566-A0D24480665B@mnot.net>
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net> <50F92A6D.1030105@it.aoyama.ac.jp>
To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
X-Mailer: Apple Mail (2.1499)
Cc: Apps Discuss 
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 10:59:54 -0000

On 18/01/2013, at 9:56 PM, "Martin J. D=FCrst"  =
wrote:

> Shouldn't the name end in +json, because the patch data itself is =
JSON?

The answer we've come to is that it isn't, because the important bit is =
that this is a patch format *for* JSON; the fact that it's encoded in =
JSON is (relatively) insignificant.


> And couldn't the simple one just have a simple name (as simple as =
leaving out the "simple")? Others can then still invent their own names, =
there's no shortage of them.

I think that's reasonable. To be clear -- I'm not pushing this *at all*; =
if we think the name is fine as-is, that's great by me (because a bunch =
of existing implementations won't feel the need to re-name).

If no one shouts and says "this needs a new name!", I'll leave it as-is; =
I just wanted to make sure we double-checked it before shipping.

Cheers,


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




From conal.tuohy@gmail.com  Fri Jan 18 04:36:15 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7788D21F88AE for ; Fri, 18 Jan 2013 04:36:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.668
X-Spam-Level: 
X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, J_CHICKENPOX_55=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 xfMOMgQoYU3q for ; Fri, 18 Jan 2013 04:36:14 -0800 (PST)
Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id 76FDA21F88B0 for ; Fri, 18 Jan 2013 04:36:14 -0800 (PST)
Received: by mail-pa0-f45.google.com with SMTP id bg2so2105305pad.32 for ; Fri, 18 Jan 2013 04:36:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=98kbz7wgW847XKhLVVfgqgwUeNn0YKdVYkxcT8FNua4=; b=bZ81+2w18B6LGjmpicKUr9jcbrpViC26XQNpJ2FCstcaxhAQaJiXgG5O8vMi3m6x3K DDal60UiLqbiWsBGZrrxhAlpUnnkczo0YCTZfsy0dd0h79uDUx7nlOK8JMpkBwhP5sxO x7ixTZarhfiqGw4OrqFZlLKuhfrYwkm82xv1u+0LaAoF+vaYHsT/MasuDZ8N/IzxGvQK XJ18MsOjCQ1Ty3V8qyt8QUDIdTpaysNjM0mam6+vP3PpOrley+XTuNLWUTv/1tqv/mVi /UDvW7kU1KxsztL9eidI7kkioiQjxrmcwGj7Hpgmzj0lnA0c9/W1MAJqJwolxvRxPZjD 0hpA==
X-Received: by 10.68.223.135 with SMTP id qu7mr4830964pbc.134.1358512574138; Fri, 18 Jan 2013 04:36:14 -0800 (PST)
Received: from [10.1.1.6] (d58-106-8-154.rdl801.qld.optusnet.com.au. [58.106.8.154]) by mx.google.com with ESMTPS id th10sm3025539pbc.76.2013.01.18.04.36.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 04:36:13 -0800 (PST)
Sender: Conal Tuohy 
Message-ID: <50F941B8.40009@versi.edu.au>
Date: Fri, 18 Jan 2013 22:36:08 +1000
From: Conal Tuohy 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net> <50F92A6D.1030105@it.aoyama.ac.jp> <16C16775-CCE9-4010-9566-A0D24480665B@mnot.net>
In-Reply-To: <16C16775-CCE9-4010-9566-A0D24480665B@mnot.net>
Content-Type: multipart/alternative; boundary="------------020106000906060602090902"
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 12:36:15 -0000

This is a multi-part message in MIME format.
--------------020106000906060602090902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

On 18/01/13 20:59, Mark Nottingham wrote:
> On 18/01/2013, at 9:56 PM, "Martin J. Dürst"  wrote:
>
>> Shouldn't the name end in +json, because the patch data itself is JSON?
> The answer we've come to is that it isn't, because the important bit is that this is a patch format *for* JSON; the fact that it's encoded in JSON is (relatively) insignificant.
I agree with Martin, that the Internet Media Type name should end in 
"+json".

It's true that in an obvious sense the semantics of JSON Patch documents 
are more significant that their syntax, but I don't think that has any 
bearing on whether to use the "+json" suffix or not.

The point of the "+json" suffix is that a media type can declare that it 
follows JSON syntax, _independently_ of its particular semantics. The 
"+json" suffix is to allow generic JSON processors to recognise JSON 
documents of whatever sub-type, so as to perform generic processing at 
the JSON syntax level; syntax highlighting, XML conversion, etc.

If there's any value at all in a "+json" suffix, even if only for 
browsers to do JSON syntax highlighting, why not allow it? Is there any 
cost to having the suffix?



-- 
Conal Tuohy
HuNI  Technical Coordinator 

Victorian eResearch Strategic Initiative 

Skype: conal.tuohy
Twitter: @conal_tuohy 
Mobile: +61-466324297 


--------------020106000906060602090902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 18/01/13 20:59, Mark Nottingham
      wrote:

    

    

      
On 18/01/2013, at 9:56 PM, "Martin J. Dürst" <duerst@it.aoyama.ac.jp> wrote:



      

        
Shouldn't the name end in +json, because the patch data itself is JSON?


      

      
The answer we've come to is that it isn't, because the important bit is that this is a patch format *for* JSON; the fact that it's encoded in JSON is (relatively) insignificant.


    

    I agree with Martin, that the Internet Media Type name should end in
    "+json".

    

    It's true that in an obvious sense the semantics of JSON Patch
    documents are more significant that their syntax, but I don't think
    that has any bearing on whether to use the "+json" suffix or not. 

    

    The point of the "+json" suffix is that a media type can declare
    that it follows JSON syntax, _independently_ of its particular
    semantics. The "+json" suffix is to allow generic JSON processors to
    recognise JSON documents of whatever sub-type, so as to perform
    generic processing at the JSON syntax level; syntax highlighting,
    XML conversion, etc. 

    

    If there's any value at all in a "+json" suffix, even if only for
    browsers to do JSON syntax highlighting, why not allow it? Is there
    any cost to having the suffix?

    

    

    

    
-- 

      

        Conal Tuohy

        HuNI Technical
          Coordinator

        Victorian
          eResearch Strategic Initiative

        Skype: conal.tuohy

        Twitter: @conal_tuohy

        Mobile: +61-466324297
      

    

  


--------------020106000906060602090902--

From dret@berkeley.edu  Fri Jan 18 04:43:53 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8837C21F889A for ; Fri, 18 Jan 2013 04:43:53 -0800 (PST)
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 1FaUdURODQ0f for ; Fri, 18 Jan 2013 04:43:52 -0800 (PST)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2851B21F874F for ; Fri, 18 Jan 2013 04:43:42 -0800 (PST)
Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretair.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TwBIJ-0004zD-7Z; Fri, 18 Jan 2013 04:43:42 -0800
Message-ID: <50F94379.1060005@berkeley.edu>
Date: Fri, 18 Jan 2013 13:43:37 +0100
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net> <50F92A6D.1030105@it.aoyama.ac.jp> <16C16775-CCE9-4010-9566-A0D24480665B@mnot.net> <50F941B8.40009@versi.edu.au>
In-Reply-To: <50F941B8.40009@versi.edu.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 12:43:53 -0000

hello.

On 2013-01-18 13:36 , Conal Tuohy wrote:
> On 18/01/13 20:59, Mark Nottingham wrote:
>> On 18/01/2013, at 9:56 PM, "Martin J. Dürst"  wrote:
>>> Shouldn't the name end in +json, because the patch data itself is JSON?
>> The answer we've come to is that it isn't, because the important bit is that this is a patch format *for* JSON; the fact that it's encoded in JSON is (relatively) insignificant.
> I agree with Martin, that the Internet Media Type name should end in
> "+json".
> It's true that in an obvious sense the semantics of JSON Patch documents
> are more significant that their syntax, but I don't think that has any
> bearing on whether to use the "+json" suffix or not.

+1, and fwiw, http://tools.ietf.org/html/draft-wilde-xml-patch-01 now 
has changed from application/xml-patch to application/xml-patch+xml, 
because according to 
http://tools.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-08.txt, 
media types should use the suffix, unless there's a good reason not to.

cheers,

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 julian.reschke@gmx.de  Fri Jan 18 05:24:05 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E4D21F874F for ; Fri, 18 Jan 2013 05:24:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.289
X-Spam-Level: 
X-Spam-Status: No, score=-105.289 tagged_above=-999 required=5 tests=[AWL=-2.690, 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 TzZfnLlIhrSf for ; Fri, 18 Jan 2013 05:24:04 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 8F47321F871D for ; Fri, 18 Jan 2013 05:24:04 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.31]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M5Jbd-1T0FHa3MuF-00zUoM for ; Fri, 18 Jan 2013 14:24:01 +0100
Received: (qmail invoked by alias); 18 Jan 2013 13:24:01 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.102]) [217.91.35.233] by mail.gmx.net (mp031) with SMTP; 18 Jan 2013 14:24:01 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX191ndMvRIp1DdFoe7Bg65rJE5K3RUJFnEhcpHLCMi 2KddFd6VtaFEMm
Message-ID: <50F94CF0.5030206@gmx.de>
Date: Fri, 18 Jan 2013 14:24:00 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Conal Tuohy 
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net> <50F92A6D.1030105@it.aoyama.ac.jp> <16C16775-CCE9-4010-9566-A0D24480665B@mnot.net> <50F941B8.40009@versi.edu.au>
In-Reply-To: <50F941B8.40009@versi.edu.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 13:24:05 -0000

On 2013-01-18 13:36, Conal Tuohy wrote:
> On 18/01/13 20:59, Mark Nottingham wrote:
>> On 18/01/2013, at 9:56 PM, "Martin J. Dürst"  wrote:
>>
>>> Shouldn't the name end in +json, because the patch data itself is JSON?
>> The answer we've come to is that it isn't, because the important bit is that this is a patch format *for* JSON; the fact that it's encoded in JSON is (relatively) insignificant.
> I agree with Martin, that the Internet Media Type name should end in
> "+json".
>
> It's true that in an obvious sense the semantics of JSON Patch documents
> are more significant that their syntax, but I don't think that has any
> bearing on whether to use the "+json" suffix or not.
>
> The point of the "+json" suffix is that a media type can declare that it
> follows JSON syntax, _independently_ of its particular semantics. The
> "+json" suffix is to allow generic JSON processors to recognise JSON
> documents of whatever sub-type, so as to perform generic processing at
> the JSON syntax level; syntax highlighting, XML conversion, etc.
>
> If there's any value at all in a "+json" suffix, even if only for
> browsers to do JSON syntax highlighting, why not allow it? Is there any
> cost to having the suffix?
> ...

+1


From ben@nocarrier.co.uk  Fri Jan 18 05:24:13 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC0821F88B2 for ; Fri, 18 Jan 2013 05:24:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.691
X-Spam-Level: 
X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 OuXNpFHDiAU0 for ; Fri, 18 Jan 2013 05:24:13 -0800 (PST)
Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id C178921F88B0 for ; Fri, 18 Jan 2013 05:24:12 -0800 (PST)
Received: by mail-wg0-f54.google.com with SMTP id fg15so2164220wgb.21 for ; Fri, 18 Jan 2013 05:24:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=GRMbgWw1pHPuvuvU9lmZy/tKv5U+bfija+wh/o1A9ac=; b=gJjUKTn5DSLH0EyvwNBqvcyfj/sul2PRtBI1QoqByJWd3KWY8ZQcrzUS8EaX8dCILx hqm+BEXOXa32fuNwHLwCpZmpJAiq3YItzkhpG8tbMm0x9zLQKlce035SyCVJuBlO/XDE Zd0s2TNMxwaP1LhudTkzmv0uTnLixuDP9HGBzuF5bhI/mRHA8h/oaB+0dNHfvTGj6tJj Hv0CN8pUEzMjtKa7kU/t3PUtvhO1md/ajonFP4s0GVKqXIxLoUVeVhyh0eHXLiCL+w77 bZCAIP3flC22OiNHWDfttbLu7o8izUJ9OngKePh20viTNXQ+2ST89QIi+UEBD6GNoxYt yPIQ==
X-Received: by 10.194.84.68 with SMTP id w4mr2612638wjy.51.1358515449995; Fri, 18 Jan 2013 05:24:09 -0800 (PST)
Received: from [192.168.0.17] (02dce988.bb.sky.com. [2.220.233.136]) by mx.google.com with ESMTPS id g2sm3849871wiy.0.2013.01.18.05.24.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 05:24:08 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ben Longden 
In-Reply-To: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net>
Date: Fri, 18 Jan 2013 13:24:06 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <17597429-83E9-47AA-B7EC-1CB2244DB57A@nocarrier.co.uk>
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net>
To: Apps Discuss 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkpqdbk8BY5x3LL/ixdbes11iuwtz+BQrpZYm0o6Mc2itH/g65x+XtsR9rd45ywwKvMnrGh
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 13:24:13 -0000

On 18 Jan 2013, at 07:24, Mark Nottingham  wrote:

> I'd suggest Simple JSON Patch, with the media type =
application/simple-json-patch.

I'm also in the +json camp=85

application/simple-patch+json

or just application/patch+json

Ben=

From cyrus@daboo.name  Fri Jan 18 06:43:32 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458B221F8859 for ; Fri, 18 Jan 2013 06:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.169
X-Spam-Level: 
X-Spam-Status: No, score=-102.169 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_RMML_Stock10=0.13, 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 UKHvZBpr1dQG for ; Fri, 18 Jan 2013 06:43:31 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9D44721F8855 for ; Fri, 18 Jan 2013 06:43:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 8EC313B3B115; Fri, 18 Jan 2013 09:43:30 -0500 (EST)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9shqZJsYBrP; Fri, 18 Jan 2013 09:43:29 -0500 (EST)
Received: from [17.45.162.221] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id C70A23B3B101; Fri, 18 Jan 2013 09:43:28 -0500 (EST)
Date: Fri, 18 Jan 2013 09:43:29 -0500
From: Cyrus Daboo 
To: Phillip Hallam-Baker , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= 
Message-ID: <48B79BFC380C7720A8DDE536@cyrus.local>
In-Reply-To: 
References:  <2644CBB3-5D5E-4247-A79F-430B7358EAA4@frobbit.se> <718EC148-9317-4419-8CDF-AB45CFA4C5D9@frobbit.se> 
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=2717
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Using the .well-known registry for SRV (and other purposes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 14:43:32 -0000

Hi Phillip,

--On January 18, 2013 1:06:40 AM -0500 Phillip Hallam-Baker 
 wrote:

> My point is that in the context of mashing the .well-known registry and
> the DNS prefix registry together, we have already decided that the
> deployer does not get to choose where the endpoint goes on the Web server.
>
>
> So URI gives us more flexibility, but not flexibility that we necessarily
> need. We certainly don't need the URI stem part at any rate.
>

Please see draft-daboo-srv-caldav (in RFC ed queue for 800+ days now). That 
spec uses new IANA service types to allow SRV->web-service mapping with 
.well-known mappings also registered. Initially the spec just mapped 
SRV->.well-known. During final reviews there was a TSV-Dir review that 
requested to make it more flexible and that resulted in the addition of an 
option to have an accompanying TXT record with a path= attribute that 
effectively defined the URI path segment (stem part in your terminology) to 
be defined. I was never keen on that, and as it has turned out I am not 
aware of anyone who has deployed with a TXT (and indeed the additional spec 
reference required by that is the one that has held up publication for so 
long). Anyway, there was a lot of discussion on this at the time on 
ietf@ietf.org so you can see why it ended up the way it did by reviewing 
those if you care.

There was also discussion on whether Patrik's URI RR should be used instead.

In any case, buy-in from TSV/DNS folks will be needed to move your idea 
forward, and having that done earlier rather than later would be best...

I should note that there are other drafts using is similar 
SRV/TXT/.well-known approach too: draft-douglass-timezone-service, 
draft-desruisseaux-ischedule, and draft-daboo-aggregated-service-discovery. 
The idea of putting all the registered .well-known services "automatically" 
under a DNS namespace (by defining _well-known as the service type) seems 
attractive if we expect a lot of folks to want to do SRV->.well-known. The 
one downside is not being able to encode the scheme via a single service 
type - instead we had to have _caldav and _caldavs for http and https 
mappings. That is something where the URI RR has an advantage...

Another thing to point out: Section 1.1 in RFC5785 indicates that 
.well-known is not meant for "general information retrieval". That 
statement required srv-caldav to state that the .well-known URI could not 
be the actual service endpoint, and instead an HTTP redirect to the actual 
service would need to be done. So the original intent of .well-known needs 
to be considered before opening the flood gates for any/all web services to 
be exposed that way.

-- 
Cyrus Daboo


From cyrus@daboo.name  Fri Jan 18 06:50:38 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958F821F8865 for ; Fri, 18 Jan 2013 06:50:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.686
X-Spam-Level: 
X-Spam-Status: No, score=-101.686 tagged_above=-999 required=5 tests=[AWL=-0.483, 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 VOG733q-IsSR for ; Fri, 18 Jan 2013 06:50:35 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0385B21F8859 for ; Fri, 18 Jan 2013 06:50:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 8BCB83B3B25C; Fri, 18 Jan 2013 09:50:34 -0500 (EST)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-1vJtCyhqEV; Fri, 18 Jan 2013 09:50:33 -0500 (EST)
Received: from [17.45.162.221] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id EAE7E3B3B24D; Fri, 18 Jan 2013 09:50:32 -0500 (EST)
Date: Fri, 18 Jan 2013 09:50:35 -0500
From: Cyrus Daboo 
To: Ben Longden , Apps Discuss 
Message-ID: 
In-Reply-To: <17597429-83E9-47AA-B7EC-1CB2244DB57A@nocarrier.co.uk>
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net> <17597429-83E9-47AA-B7EC-1CB2244DB57A@nocarrier.co.uk>
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; size=764
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 14:50:38 -0000

Hi Ben,

--On January 18, 2013 1:24:06 PM +0000 Ben Longden =20
wrote:

>> I'd suggest Simple JSON Patch, with the media type
>> application/simple-json-patch.
>
> I'm also in the +json camp=E2=80=A6
>
> application/simple-patch+json
>
> or just application/patch+json

The trouble with those is that they do not explicitly indicate what type of =

data is being patched, only that the patch format itself is in JSON. Not=20
sure if that is a big deal or not...

Someone else had suggested that there ought to be a regular syntax for=20
patch media types. One suggestion was a new top-level type, e.g.=20
patch/json+json, patch/xml+xml. Another option is to define something like=20
'application/patch-xxx+yyy' as the appropriate regular form.

--=20
Cyrus Daboo


From jasnell@gmail.com  Fri Jan 18 07:46:14 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888EE21F8890 for ; Fri, 18 Jan 2013 07:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.933
X-Spam-Level: 
X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 aBX7kTy6SmKu for ; Fri, 18 Jan 2013 07:46:14 -0800 (PST)
Received: from mail-ia0-x230.google.com (ia-in-x0230.1e100.net [IPv6:2607:f8b0:4001:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id DF66921F888E for ; Fri, 18 Jan 2013 07:46:13 -0800 (PST)
Received: by mail-ia0-f176.google.com with SMTP id i18so1542479iac.21 for ; Fri, 18 Jan 2013 07:46:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6YtEJVAHsSyD3kxMsEJiTTYTBf2SPSjbnGPvhlZhVyc=; b=aMRiqWjXGjYqAtFdPC9t13lMp9yKvDF/7VGib27is91aDc4nLTVB+/UpDElDCnXbCn OAo04LHPr3gydYe5pTQenhnYaO1EflxtRLILnH+C+ivT+dzyUAV0BgTiuvIcvk9XFohy 9imN5zPugHsXo/4wMrGWNOJX8wPAjHAAeDzDi13v+qpvL0mCYczboNSNKmu/TamqNe8d 4wGOlInye7PADVv7RVCX8IblSAyGiFMKGvEdVxklP6ar6o9TCu1GTkZhKJz0WAny81ln qZMlAQqVStW/wZ8+US2Idi7TMCV5+3IaK3P+0Yo3/oRiNjL7uWaHZ7nOwdvyBaFNRDQ8 ibhw==
MIME-Version: 1.0
X-Received: by 10.42.32.71 with SMTP id c7mr6378087icd.35.1358523973212; Fri, 18 Jan 2013 07:46:13 -0800 (PST)
Received: by 10.64.26.137 with HTTP; Fri, 18 Jan 2013 07:46:12 -0800 (PST)
Received: by 10.64.26.137 with HTTP; Fri, 18 Jan 2013 07:46:12 -0800 (PST)
In-Reply-To: 
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net> <17597429-83E9-47AA-B7EC-1CB2244DB57A@nocarrier.co.uk> 
Date: Fri, 18 Jan 2013 07:46:12 -0800
Message-ID: 
From: James M Snell 
To: Cyrus Daboo 
Content-Type: multipart/alternative; boundary=bcaec517cda8d79b8904d3920252
Cc: Apps Discuss 
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 15:46:14 -0000

--bcaec517cda8d79b8904d3920252
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I am currently working on what I imagine will be a fairly controversial
draft that introduces a new top level media type for patch documents...
examples:

patch/json
patch/json-merge
patch/xml
patch/text
patch/html
...

The draft ought to be published by early next week.
On Jan 18, 2013 6:50 AM, "Cyrus Daboo"  wrote:

> Hi Ben,
>
> --On January 18, 2013 1:24:06 PM +0000 Ben Longden 
> wrote:
>
>  I'd suggest Simple JSON Patch, with the media type
>>> application/simple-json-patch.
>>>
>>
>> I'm also in the +json camp=E2=80=A6
>>
>> application/simple-patch+json
>>
>> or just application/patch+json
>>
>
> The trouble with those is that they do not explicitly indicate what type
> of data is being patched, only that the patch format itself is in JSON. N=
ot
> sure if that is a big deal or not...
>
> Someone else had suggested that there ought to be a regular syntax for
> patch media types. One suggestion was a new top-level type, e.g.
> patch/json+json, patch/xml+xml. Another option is to define something lik=
e
> 'application/patch-xxx+yyy' as the appropriate regular form.
>
> --
> Cyrus Daboo
>
> ______________________________**_________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/**listinfo/apps-discuss
>

--bcaec517cda8d79b8904d3920252
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I am currently working on what I imagine will be a fairly co=
ntroversial draft that introduces a new top level media type for patch docu=
ments... examples:


patch/json

patch/json-merge

patch/xml

patch/text

patch/html 

...


The draft ought to be published by early next week.


On Jan 18, 2013 6:50 AM, "Cyrus Daboo"=
 <cyrus@daboo.name> wrote:

Hi Ben,



--On January 18, 2013 1:24:06 PM +0000 Ben Longden <ben@nocarrier.co.uk> wrote:





I'd suggest Simple JSON Patch, with the media type

application/simple-json-patch.





I'm also in the +json camp=E2=80=A6



application/simple-patch+json



or just application/patch+json





The trouble with those is that they do not explicitly indicate what type of=
 data is being patched, only that the patch format itself is in JSON. Not s=
ure if that is a big deal or not...



Someone else had suggested that there ought to be a regular syntax for patc=
h media types. One suggestion was a new top-level type, e.g. patch/json+jso=
n, patch/xml+xml. Another option is to define something like 'applicati=
on/patch-xxx+yyy' as the appropriate regular form.




-- 

Cyrus Daboo



_______________________________________________

apps-discuss mailing list

apps-discuss@iet=
f.org

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




--bcaec517cda8d79b8904d3920252--

From hallam@gmail.com  Fri Jan 18 08:22:24 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D6121F87E7 for ; Fri, 18 Jan 2013 08:22:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.69
X-Spam-Level: 
X-Spam-Status: No, score=-3.69 tagged_above=-999 required=5 tests=[AWL=-0.222,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqRhgEyvuYJp for ; Fri, 18 Jan 2013 08:22:22 -0800 (PST)
Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by ietfa.amsl.com (Postfix) with ESMTP id ECD3321F8780 for ; Fri, 18 Jan 2013 08:22:21 -0800 (PST)
Received: by mail-la0-f50.google.com with SMTP id er20so2366017lab.9 for ; Fri, 18 Jan 2013 08:22:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=z5lfCYgO+t0TdLOwrwOENLV69adjQCXkpMKBwaF3m8E=; b=GgJaJ49Jnhk3FtY8qCsp6uZWMAf3dP00417+1dgg8r5mZjIg5RdLBAoEpqEyG6p6sT RFsaE3Lh8K+TFR167iW2ycICyz3qCe7IztOMsZk4gqbj/dbdcFy6BdWPpgZHj2P/qJ4Q meVr6XPdmyWDcfL5ANow2Xnie0ZNXIxnqHu49Bz1FBab9sggbrWOSqc6Qk+EfihKeW2d MdckYI8nutMauv+pfEZZ6bdlE2YlrhxVMfaSGhfcuXxI/+t5Y0loTCpI0G0ipxXwPyRY pPndsOnYZxrbCXxfWy9blO1P2o3I5zGg27hBnt+rpEYBxGZUJ3sB5Aatf75th3XMUQxP 99ow==
MIME-Version: 1.0
X-Received: by 10.112.32.101 with SMTP id h5mr4058369lbi.3.1358526140785; Fri, 18 Jan 2013 08:22:20 -0800 (PST)
Received: by 10.112.10.36 with HTTP; Fri, 18 Jan 2013 08:22:20 -0800 (PST)
In-Reply-To: <48B79BFC380C7720A8DDE536@cyrus.local>
References:  <2644CBB3-5D5E-4247-A79F-430B7358EAA4@frobbit.se> <718EC148-9317-4419-8CDF-AB45CFA4C5D9@frobbit.se>  <48B79BFC380C7720A8DDE536@cyrus.local>
Date: Fri, 18 Jan 2013 11:22:20 -0500
Message-ID: 
From: Phillip Hallam-Baker 
To: Cyrus Daboo 
Content-Type: multipart/alternative; boundary=bcaec554de400a235804d39284a2
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Using the .well-known registry for SRV (and other purposes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 16:22:24 -0000

--bcaec554de400a235804d39284a2
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jan 18, 2013 at 9:43 AM, Cyrus Daboo  wrote:

> Hi Phillip,
>
>
> --On January 18, 2013 1:06:40 AM -0500 Phillip Hallam-Baker <
> hallam@gmail.com> wrote:
>
>  My point is that in the context of mashing the .well-known registry and
>> the DNS prefix registry together, we have already decided that the
>> deployer does not get to choose where the endpoint goes on the Web server.
>>
>>
>> So URI gives us more flexibility, but not flexibility that we necessarily
>> need. We certainly don't need the URI stem part at any rate.
>>
>>
> Please see draft-daboo-srv-caldav (in RFC ed queue for 800+ days now).
> That spec uses new IANA service types to allow SRV->web-service mapping
> with .well-known mappings also registered. Initially the spec just mapped
> SRV->.well-known. During final reviews there was a TSV-Dir review that
> requested to make it more flexible and that resulted in the addition of an
> option to have an accompanying TXT record with a path= attribute that
> effectively defined the URI path segment (stem part in your terminology) to
> be defined. I was never keen on that, and as it has turned out I am not
> aware of anyone who has deployed with a TXT (and indeed the additional spec
> reference required by that is the one that has held up publication for so
> long). Anyway, there was a lot of discussion on this at the time on
> ietf@ietf.org so you can see why it ended up the way it did by reviewing
> those if you care.
>
> There was also discussion on whether Patrik's URI RR should be used
> instead.
>

800+ days in the queue strongly suggests that is what you should do.

It sounds like the draft is blocked because

1) People insisted on more flexibility
2) The mechanism proposed to achieve the additional flexibility was not
acceptable
3) The issue was not raised with sufficient force in the places that a
decision might be made

On issues like this where the only thing that really matters is that the
IETF just pick one way to do something, it is a process failure if we end
up with delays of 90 days let alone three years.

Directorates have no formal standing in IETF. They can comment on a
document during last call but those comments have no more force than any
other reviewer. Only an AD can block a draft. So your problem would be with
the AD rather than the directorate.


In any case, buy-in from TSV/DNS folks will be needed to move your idea
> forward, and having that done earlier rather than later would be best...
>

No, I think the thing to do here is to put a solution on the table that
anticipates their position based on the already exhaustive discussions they
have had.

The whole point of making the proposal in the first place is that the
current scheme has too many moving parts. If the IAB is going to have
architecture in its name then this is the sort of issue where they should
be taking a lead if a deadlock occurs.

If architecture is going to make any sense there should be one discovery
mechanism that we are heading towards.


As I see it there are two options for going forward on CALDAV:

1) Adopt URI as a replacement for SRV
2) Drop the TXT record hack

Given the installed base of CALDAV the de facto standard is to only
retrieve SRV records and any site that attempts to advertise a service that
is not backwards compatible is going to break.

So I think we have to consider CALDAV as a legacy case. We already have a
huge amount of well known port legacy that is going to hand around for 20
years. Having CALDAV do SRV instead of URI is hardly going to hurt much.

Note that under my proposed scheme there would also be a wk:caldav: URI
scheme that would be available for use if this was desirable.



> I should note that there are other drafts using is similar
> SRV/TXT/.well-known approach too: draft-douglass-timezone-**service,
> draft-desruisseaux-ischedule, and draft-daboo-aggregated-**service-discovery.
> The idea of putting all the registered .well-known services "automatically"
> under a DNS namespace (by defining _well-known as the service type) seems
> attractive if we expect a lot of folks to want to do SRV->.well-known. The
> one downside is not being able to encode the scheme via a single service
> type - instead we had to have _caldav and _caldavs for http and https
> mappings. That is something where the URI RR has an advantage...
>

I saw that as well. There is a slight difference in the semantics. The
caldavs: has an explicit 'must use TLS' policy that is bound to the
identifier. Putting that information in the DNS means that the policy is
acquired during discovery and is only as good as the DNS security. There is
a significant change in semantics there even if you use DNSSEC to secure
the DNS.

I think you actually need both.


Another thing to point out: Section 1.1 in RFC5785 indicates that
> .well-known is not meant for "general information retrieval". That
> statement required srv-caldav to state that the .well-known URI could not
> be the actual service endpoint, and instead an HTTP redirect to the actual
> service would need to be done. So the original intent of .well-known needs
> to be considered before opening the flood gates for any/all web services to
> be exposed that way.


I think 'they' are confused bunnies and don't understand what the
restriction was about.

I think that the point of the restriction is to avoid conflict between Web
Services and Web Browsing. Most Web Services are at least 90% idempotent
information retrieval with no change of state. But they are implemented in
a very different way. They are not static data, they are dynamically
generated content.

Probably a good test for whether something is a Web Service or a Web
Content is whether you are likely to want to have a link to the actual Web
Service appear in a URL or not.


So one final thought here that struck me while writing this is that what we
probably want is not Patrick's URI proposal but a very slight modification
so that we have two slots, one for the URI and one for an optional policy
specification. That would then allow the service endpoint to include
relevant descriptive information such as the minimum and maximum supported
versions and credential requirements etc.

It seems much better to glue that information to the discovery record
advertising the service than any other technique:

Ownername TTL Class URI Priority Weight Target


becomes

Ownername TTL Class URI Priority Weight Target [Policy]


If we make the field optional people can still use existing configurations
(there are plenty of DNS RRs with optional fields)

So we might have something like:

_omnibroker._wk.example.com URI 1 1 https://w1.example.com "max=2"
_omnibroker._wk.example.com URI 1 1 https://w1.example.com "min=2.0"
_omnibroker._wk.example.com URI 1 1 coap://w1.example.com "ipsec"

So now when we are searching for an implementation of omnibroker, the
client can make a choice that is informed by the version of the protocol it
supports and we have a peg from which we can hang other security schemes
than TLS.


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

--bcaec554de400a235804d39284a2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Fri, Jan 18, 2013 at 9:43 AM, Cyrus D=
aboo <cyrus@daboo.name> wrote:

Hi Phillip,




--On January 18, 2013 1:06:40 AM -0500 Phillip Hallam-Baker <hallam@gmail.com> wrote:<=
br>




My point is that in the context of mashing the .well-known registry and

the DNS prefix registry together, we have already decided that the

deployer does not get to choose where the endpoint goes on the Web server.<=
br>




So URI gives us more flexibility, but not flexibility that we necessarily
need. We certainly don't need the URI stem part at any rate.







Please see draft-daboo-srv-caldav (in RFC ed queue for 800+ days now). That=
 spec uses new IANA service types to allow SRV->web-service mapping with=
 .well-known mappings also registered. Initially the spec just mapped SRV-&=
gt;.well-known. During final reviews there was a TSV-Dir review that reques=
ted to make it more flexible and that resulted in the addition of an option=
 to have an accompanying TXT record with a path=3D attribute that effective=
ly defined the URI path segment (stem part in your terminology) to be defin=
ed. I was never keen on that, and as it has turned out I am not aware of an=
yone who has deployed with a TXT (and indeed the additional spec reference =
required by that is the one that has held up publication for so long). Anyw=
ay, there was a lot of discussion on this at the time on ietf@ietf.org so you can see why it en=
ded up the way it did by reviewing those if you care.




There was also discussion on whether Patrik's URI RR should be used ins=
tead.

800+ days in the queue strongly s=
uggests that is what you should do.

It sounds like=
 the draft is blocked because



1) People insisted on more flexibility
2) The=
 mechanism proposed to achieve the additional flexibility was not acceptabl=
e
3) The issue was not raised with sufficient force in the places=
 that a decision might be made



On issues like this where the only thing that really ma=
tters is that the IETF just pick one way to do something, it is a process f=
ailure if we end up with delays of 90 days let alone three years.



Directorates have no formal standing in IETF. They can =
comment on a document during last call but those comments have no more forc=
e than any other reviewer. Only an AD can block a draft. So your problem wo=
uld be with the AD rather than the directorate.





In any case, buy-in from TSV/DNS folks will be needed to move your idea for=
ward, and having that done earlier rather than later would be best...

No, I think the thing to do here is to put a=
 solution on the table that anticipates their position based on the already=
 exhaustive discussions they have had.



The whole point of making the proposal in the first pla=
ce is that the current scheme has too many moving parts. If the IAB is goin=
g to have architecture in its name then this is the sort of issue where the=
y should be taking a lead if a deadlock occurs.



If architecture is going to make any sense there should=
 be one discovery mechanism that we are heading towards.


As I see it there are two options for going forward o=
n CALDAV:



1) Adopt URI as a replacement for SRV
2) Drop=
 the TXT record hack

Given the installed base of C=
ALDAV the de facto standard is to only retrieve SRV records and any site th=
at attempts to advertise a service that is not backwards compatible is goin=
g to break.



So I think we have to consider CALDAV as a legacy case.=
 We already have a huge amount of well known port legacy that is going to h=
and around for 20 years. Having CALDAV do SRV instead of URI is hardly goin=
g to hurt much.



Note that under my proposed scheme there would also be =
a wk:caldav: URI scheme that would be available for use if this was desirab=
le.

=A0


I should note that there are other drafts using is similar SRV/TXT/.well-kn=
own approach too: draft-douglass-timezone-service, draft-desruisseau=
x-ischedule, and draft-daboo-aggregated-service-discovery. The idea =
of putting all the registered .well-known services "automatically"=
; under a DNS namespace (by defining _well-known as the service type) seems=
 attractive if we expect a lot of folks to want to do SRV->.well-known. =
The one downside is not being able to encode the scheme via a single servic=
e type - instead we had to have _caldav and _caldavs for http and https map=
pings. That is something where the URI RR has an advantage...



I saw that as well. There is a slight diff=
erence in the semantics. The caldavs: has an explicit 'must use TLS'=
; policy that is bound to the identifier. Putting that information in the D=
NS means that the policy is acquired during discovery and is only as good a=
s the DNS security. There is a significant change in semantics there even i=
f you use DNSSEC to secure the DNS.



I think you actually need both.



Another thing to point out: Section 1.1 in RFC5785 indicates that .well-kno=
wn is not meant for "general information retrieval". That stateme=
nt required srv-caldav to state that the .well-known URI could not be the a=
ctual service endpoint, and instead an HTTP redirect to the actual service =
would need to be done. So the original intent of .well-known needs to be co=
nsidered before opening the flood gates for any/all web services to be expo=
sed that way.



I think 'they' are confused bunnies and don'=
;t understand what the restriction was about.

I th=
ink that the point of the restriction is to avoid conflict between Web Serv=
ices and Web Browsing. Most Web Services are at least 90% idempotent inform=
ation retrieval with no change of state. But they are implemented in a very=
 different way. They are not static data, they are dynamically generated co=
ntent.



Probably a good test for whether something is a Web Ser=
vice or a Web Content is whether you are likely to want to have a link to t=
he actual Web Service appear in a URL or not.




So one final thought here that struck me while writing =
this is that what we probably want is not Patrick's URI proposal but a =
very slight modification so that we have two slots, one for the URI and one=
 for an optional policy specification. That would then allow the service en=
dpoint to include relevant descriptive information such as the minimum and =
maximum supported versions and credential requirements etc.



It seems much better to glue that information to the di=
scovery record advertising the service than any other technique:
=

Ownername TTL Class URI Priority Weight Target

becomes

Ownername TTL Class URI Priority Weight Target [Policy]
If we make the field optional people can still use existing con=
figurations (there are plenty of DNS RRs with optional fields)


So we might have something like:

_o=
mnibroker._wk.example.com URI 1 1 https://w1.example.com "max=3D2&qu=
ot;


_omnibroker._wk.example.com URI =
1 1 https://w1.example.com "min=
=3D2.0"
_omnibroker._wk.ex=
ample.com URI 1 1 coap://w1.example.c=
om "ipsec"



So now when we are searching for an implementation of o=
mnibroker, the client can make a choice that is informed by the version of =
the protocol it supports and we have a peg from which we can hang other sec=
urity schemes than TLS.




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


--bcaec554de400a235804d39284a2--

From barryleiba.mailing.lists@gmail.com  Fri Jan 18 10:59:46 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127BD21F8738 for ; Fri, 18 Jan 2013 10:59:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.107
X-Spam-Level: 
X-Spam-Status: No, score=-103.107 tagged_above=-999 required=5 tests=[AWL=-0.130, 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 Qe1L5qGAESEO for ; Fri, 18 Jan 2013 10:59:45 -0800 (PST)
Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 14FD421F8732 for ; Fri, 18 Jan 2013 10:59:45 -0800 (PST)
Received: by mail-vb0-f54.google.com with SMTP id l1so3962359vba.41 for ; Fri, 18 Jan 2013 10:59:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=niQ4E/Qf8YN/FV9IdI88jVudPS2ZMTa/6k2FOfHUqPI=; b=UF0/Zilku8QPgPOJHmklAz8DdJiBtNdsmwiderU+orvDBD4rl5RXSpQYY3DdOqvuZ9 wEaCI+S3sx9sOXa7rD20f6D7eAA8kOHAkWHt5y6XTnnFafG+rS6J8s8XxAPwB3P3dyhT W2oEFbQtzswoCWZ15J16S+XKcjEhrz2czjol8VwYDCTW0yZISV31sWV1yR2OAYGGeqql Oe5FI/o8L/CLKWOlrEPZOTyOr7Ob6/yZdZlr0A3AmwwfLSkU2OIM80FVX8jpUrV60R3o mf2NeVkeTOxO9TwBZKCJ4VQFJGg3C0xslEFclNB6g486pPZ1nr/eFzwWixjtQSaBaQ0o qrdQ==
MIME-Version: 1.0
X-Received: by 10.52.67.198 with SMTP id p6mr9538598vdt.3.1358535584333; Fri, 18 Jan 2013 10:59:44 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Fri, 18 Jan 2013 10:59:44 -0800 (PST)
In-Reply-To: 
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net> <17597429-83E9-47AA-B7EC-1CB2244DB57A@nocarrier.co.uk>  
Date: Fri, 18 Jan 2013 13:59:44 -0500
X-Google-Sender-Auth: 7rwa2VC-poYxZpr6Hz61F-RMdgk
Message-ID: 
From: Barry Leiba 
To: James M Snell 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: Apps Discuss 
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 18:59:46 -0000

On Fri, Jan 18, 2013 at 10:46 AM, James M Snell  wrote:
> I am currently working on what I imagine will be a fairly controversial
> draft that introduces a new top level media type for patch documents...

Ned Freed is on this list, but it would be a good idea to explicitly
call his attention to this proposal -- perhaps sending it to him
before you post it as a -00 I-D.  It'll help you cross "i"s and dot
"t"s before he comes after you with a shotgun or a twibil.

Barry

> examples:
>
> patch/json
> patch/json-merge
> patch/xml
> patch/text
> patch/html
> ...
>
> The draft ought to be published by early next week.
>
> On Jan 18, 2013 6:50 AM, "Cyrus Daboo"  wrote:
>>
>> Hi Ben,
>>
>> --On January 18, 2013 1:24:06 PM +0000 Ben Longden 
>> wrote:
>>
>>>> I'd suggest Simple JSON Patch, with the media type
>>>> application/simple-json-patch.
>>>
>>>
>>> I'm also in the +json camp=85
>>>
>>> application/simple-patch+json
>>>
>>> or just application/patch+json
>>
>>
>> The trouble with those is that they do not explicitly indicate what type
>> of data is being patched, only that the patch format itself is in JSON. =
Not
>> sure if that is a big deal or not...
>>
>> Someone else had suggested that there ought to be a regular syntax for
>> patch media types. One suggestion was a new top-level type, e.g.
>> patch/json+json, patch/xml+xml. Another option is to define something li=
ke
>> 'application/patch-xxx+yyy' as the appropriate regular form.
>>
>> --
>> Cyrus Daboo
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss

From cyrus@daboo.name  Fri Jan 18 11:06:46 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E7821F879A for ; Fri, 18 Jan 2013 11:06:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 IQkH5vux95Kc for ; Fri, 18 Jan 2013 11:06:46 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id D8EA821F8759 for ; Fri, 18 Jan 2013 11:06:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 76B673B3F1EE; Fri, 18 Jan 2013 14:06:45 -0500 (EST)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4GoYg1f60j6; Fri, 18 Jan 2013 14:06:45 -0500 (EST)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id A55553B3F1E3; Fri, 18 Jan 2013 14:06:43 -0500 (EST)
Date: Fri, 18 Jan 2013 14:06:40 -0500
From: Cyrus Daboo 
To: Phillip Hallam-Baker 
Message-ID: <4F54680FFD7BC0C3285A56DC@caldav.corp.apple.com>
In-Reply-To: 
References:  <2644CBB3-5D5E-4247-A79F-430B7358EAA4@frobbit.se> <718EC148-9317-4419-8CDF-AB45CFA4C5D9@frobbit.se>  <48B79BFC380C7720A8DDE536@cyrus.local> 
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=1268
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Using the .well-known registry for SRV (and other purposes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 19:06:46 -0000

Hi Phillip,

--On January 18, 2013 at 11:22:20 AM -0500 Phillip Hallam-Baker 
 wrote:

> As I see it there are two options for going forward on CALDAV:
>
>
> 1) Adopt URI as a replacement for SRV
> 2) Drop the TXT record hack
>
>
> Given the installed base of CALDAV the de facto standard is to only
> retrieve SRV records and any site that attempts to advertise a service
> that is not backwards compatible is going to break.
>
>
> So I think we have to consider CALDAV as a legacy case. We already have a
> huge amount of well known port legacy that is going to hand around for 20
> years. Having CALDAV do SRV instead of URI is hardly going to hurt much.
>
>
> Note that under my proposed scheme there would also be a wk:caldav: URI
> scheme that would be available for use if this was desirable.

Actually the goal we have for CalDAV service discovery is to define a 
generic client account configuration service to cover all aspects of a 
typical device setup, something akin to 
draft-daboo-aggregated-service-discovery - several of us are working on 
putting together a BOF to move that forward. Now that document does 
currently define SRV->.well-known too - but that could shift to URI if 
there were consensus around that.

-- 
Cyrus Daboo


From barryleiba.mailing.lists@gmail.com  Fri Jan 18 11:11:17 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF7321F8775 for ; Fri, 18 Jan 2013 11:11:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.105
X-Spam-Level: 
X-Spam-Status: No, score=-103.105 tagged_above=-999 required=5 tests=[AWL=-0.128, 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 iJx92JQ45OfA for ; Fri, 18 Jan 2013 11:11:10 -0800 (PST)
Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id A62B121F866D for ; Fri, 18 Jan 2013 11:11:09 -0800 (PST)
Received: by mail-vc0-f178.google.com with SMTP id m8so3204531vcd.37 for ; Fri, 18 Jan 2013 11:11:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xpkhpXEuF+cveQnlmjk0uZmqt/Yv2aRU21NnQiufETo=; b=0anE1Jd+mwryShz7vr+2RhLee23tQSu5UDo31MPmQdyKP5dCK5dbx1fXbhSNR0rK/A kwY1tJ8xU2IAS7cs6rMEEJyEBUD7ZOi+Un3P154sHQx6TzZjquw64+MlkQWUEKShvIVM a3tvx43/OaTe7I0SRN9roI1nXxbWI75j9ndk2IJLXPW6FPGfXArGVBVPyxxG2T39W6h1 b1KGnDyZVp1FDE3pt9swu7b4DCMHY/odfQHRHXSQRzk/fod2KBIugfzfKfGZtMh9KwuH hMz4xfc5wbl4yd7lZxvQWlsKXmQELlFRWjqHU445gdMIL3qy71gb86Cbr5i9UfdMMxUb rrwQ==
MIME-Version: 1.0
X-Received: by 10.52.88.33 with SMTP id bd1mr9409125vdb.70.1358536265727; Fri, 18 Jan 2013 11:11:05 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Fri, 18 Jan 2013 11:11:05 -0800 (PST)
In-Reply-To: 
References:  <2644CBB3-5D5E-4247-A79F-430B7358EAA4@frobbit.se> <718EC148-9317-4419-8CDF-AB45CFA4C5D9@frobbit.se>  <48B79BFC380C7720A8DDE536@cyrus.local> 
Date: Fri, 18 Jan 2013 14:11:05 -0500
X-Google-Sender-Auth: G3J2diP2qYC4-eVkcUzcqUrtPCg
Message-ID: 
From: Barry Leiba 
To: Phillip Hallam-Baker 
Content-Type: text/plain; charset=ISO-8859-1
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Using the .well-known registry for SRV (and other purposes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 19:11:17 -0000

>> Please see draft-daboo-srv-caldav (in RFC ed queue for 800+ days now).
>
> 800+ days in the queue strongly suggests that is what you should do.
>
> It sounds like the draft is blocked because
>
> 1) People insisted on more flexibility
> 2) The mechanism proposed to achieve the additional flexibility was not
> acceptable
> 3) The issue was not raised with sufficient force in the places that a
> decision might be made
>
> On issues like this where the only thing that really matters is that the
> IETF just pick one way to do something, it is a process failure if we end up
> with delays of 90 days let alone three years.

To be clear: the draft has been stuck in the RFC Editor queue because
of a normative-reference mess in what the IESG has come to think of as
"that cursed Cluster 83."  See
http://www.rfc-editor.org/cluster_info.php?cid=C83

Cyrus's document has a normative reference to
draft-cheshire-dnsext-dns-sd, and that document has a normative
reference to draft-cheshire-dnsext-multicastdns.  Both of those
documents have been stuck for a long time.

I agree that this is a process failure.

Barry

From hallam@gmail.com  Fri Jan 18 11:32:06 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B3421F86D5 for ; Fri, 18 Jan 2013 11:32:06 -0800 (PST)
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, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, NO_RELAYS=-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 nWgOKfzIwZmk for ; Fri, 18 Jan 2013 11:32:06 -0800 (PST)
Received: from mail-we0-x22a.google.com (we-in-x022a.1e100.net [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE8421F8684 for ; Fri, 18 Jan 2013 11:32:05 -0800 (PST)
Received: by mail-we0-f170.google.com with SMTP id r1so1041703wey.15 for ; Fri, 18 Jan 2013 11:32:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1iOujkzxa+QKcX6puTD1pi6AbHli2KlMTVp4jV3ck8g=; b=0CmBUWVst4ewOmv1VIlSoz4qYJnTAA0fy3p2xf3JCsvsd3tuZNlcIKaBxyiEGfXdx1 bBU7klCANZDKBOLUkMKpQnXwiNdjB+6mVxcnZlHup9/Luo+tGq7oiBGaE7Rld/5zoSgl VWG8bWCn2iDwGJlmT4GLeiqgtNItBjvP+K1tCnx94OvZlBlf6uh6FjXslbSZSqd81vlx rbkPdGkYlg3x2ciXnWtwtFUD8g82MQuOQlcHcebUeaEyeKXlJV6TT4sjo2XEFK/5p9qG v/JHWYAyiXGimNI1pkOePWGt9wryU7f93UxkxHSODnLHOZ3iSS7w36aV14TtNHNQmyQn MZIg==
MIME-Version: 1.0
X-Received: by 10.180.101.104 with SMTP id ff8mr5410968wib.11.1358537524503; Fri, 18 Jan 2013 11:32:04 -0800 (PST)
Received: by 10.194.59.10 with HTTP; Fri, 18 Jan 2013 11:32:04 -0800 (PST)
In-Reply-To: <4F54680FFD7BC0C3285A56DC@caldav.corp.apple.com>
References:  <2644CBB3-5D5E-4247-A79F-430B7358EAA4@frobbit.se> <718EC148-9317-4419-8CDF-AB45CFA4C5D9@frobbit.se>  <48B79BFC380C7720A8DDE536@cyrus.local>  <4F54680FFD7BC0C3285A56DC@caldav.corp.apple.com>
Date: Fri, 18 Jan 2013 14:32:04 -0500
Message-ID: 
From: Phillip Hallam-Baker 
To: Cyrus Daboo 
Content-Type: multipart/alternative; boundary=f46d041826c88fe61704d3952acc
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] Using the .well-known registry for SRV (and other purposes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jan 2013 19:32:07 -0000

--f46d041826c88fe61704d3952acc
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jan 18, 2013 at 2:06 PM, Cyrus Daboo  wrote:

> Hi Phillip,
>
>
> --On January 18, 2013 at 11:22:20 AM -0500 Phillip Hallam-Baker <
> hallam@gmail.com> wrote:
>
>  As I see it there are two options for going forward on CALDAV:
>>
>>
>> 1) Adopt URI as a replacement for SRV
>> 2) Drop the TXT record hack
>>
>>
>> Given the installed base of CALDAV the de facto standard is to only
>> retrieve SRV records and any site that attempts to advertise a service
>> that is not backwards compatible is going to break.
>>
>>
>> So I think we have to consider CALDAV as a legacy case. We already have a
>> huge amount of well known port legacy that is going to hand around for 20
>> years. Having CALDAV do SRV instead of URI is hardly going to hurt much.
>>
>>
>> Note that under my proposed scheme there would also be a wk:caldav: URI
>> scheme that would be available for use if this was desirable.
>>
>
> Actually the goal we have for CalDAV service discovery is to define a
> generic client account configuration service to cover all aspects of a
> typical device setup, something akin to draft-daboo-aggregated-**service-discovery
> - several of us are working on putting together a BOF to move that forward.
> Now that document does currently define SRV->.well-known too - but that
> could shift to URI if there were consensus around that.


Actually, I have now moved on to wanting the policy info in the same record
so its a little more than URI. So now its WK instead of URI.

The way I would resolve this is to specify that the caldav: URI scheme is
resolved using SRV with an optional fallback to WK and the wk:caldav is
only resolved using WK alone.

This allows the wk:caldav version to be used to force use of the new
discovery scheme that provides for expressing specific endpoints and policy
etc.


The way I would manage the transition from where we are now to where we
want to be is by using a protocol like the one I propose in Omnibroker that
provides a high level interface to the DNS for service announcement.

So when a caldev server came online it would announce itself to the
omnibroker service which would know that this is a special legacy case and
so it has to mint an SRV record set as well as the WK record set that
includes additional information.

Legacy protocols using well known ports that we might want to add policy
information could be managed in the exact same way only the service
announcement service (which could be omnibroker or something else) would
then be configuring an A or AAAA record instead of the SRV record.

This would also configure things like the firewall/NAT box so that the
appropriate ports were opened up.


The basic idea here is that discovery is currently a mess that lacks
consistency. So to get to a consistent place we first of all define one
discovery mechanism that can support the whole range of needs, then we put
all the complexity and special case handling into the interface to that
mechanism.

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

--f46d041826c88fe61704d3952acc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Fri, Jan 18, 2013 at 2:06 PM, Cyrus D=
aboo <cyrus@daboo.name> wrote:

Hi Phillip,




--On January 18, 2013 at 11:22:20 AM -0500 Phillip Hallam-Baker <hallam@gmail.com> wro=
te:





As I see it there are two options for going forward on CALDAV:





1) Adopt URI as a replacement for SRV

2) Drop the TXT record hack





Given the installed base of CALDAV the de facto standard is to only

retrieve SRV records and any site that attempts to advertise a service

that is not backwards compatible is going to break.





So I think we have to consider CALDAV as a legacy case. We already have a
huge amount of well known port legacy that is going to hand around for 20
years. Having CALDAV do SRV instead of URI is hardly going to hurt much.




Note that under my proposed scheme there would also be a wk:caldav: URI

scheme that would be available for use if this was desirable.





Actually the goal we have for CalDAV service discovery is to define a gener=
ic client account configuration service to cover all aspects of a typical d=
evice setup, something akin to draft-daboo-aggregated-service-discov=
ery - several of us are working on putting together a BOF to move that forw=
ard. Now that document does currently define SRV->.well-known too - but =
that could shift to URI if there were consensus around that.



Actually, I have now moved on to wanting the policy inf=
o in the same record so its a little more than URI. So now its WK instead o=
f URI.

The way I would resolve this is to specify =
that the caldav: URI scheme is resolved using SRV with an optional fallback=
 to WK and the wk:caldav is only resolved using WK alone.



This allows the wk:caldav version to be used to force u=
se of the new discovery scheme that provides for expressing specific endpoi=
nts and policy etc.


The way I would=
 manage the transition from where we are now to where we want to be is by u=
sing a protocol like the one I propose in Omnibroker that provides a high l=
evel interface to the DNS for service announcement.



So when a caldev server came online it would announce i=
tself to the omnibroker service which would know that this is a special leg=
acy case and so it has to mint an SRV record set as well as the WK record s=
et that includes additional information.



Legacy protocols using well known ports that we m=
ight want to add policy information could be managed in the exact same way =
only the service announcement service (which could be omnibroker or somethi=
ng else) would then be configuring an A or AAAA record instead of the SRV r=
ecord.



This would also configure things like the firewall/NAT =
box so that the appropriate ports were opened up.

=

The basic idea here is that discovery is currently a mess th=
at lacks consistency. So to get to a consistent place we first of all defin=
e one discovery mechanism that can support the whole range of needs, then w=
e put all the complexity and special case handling into the interface to th=
at mechanism.



-- 
Website: http://h=
allambaker.com/


--f46d041826c88fe61704d3952acc--

From duerst@it.aoyama.ac.jp  Sat Jan 19 00:19:47 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1720921F8505 for ; Sat, 19 Jan 2013 00:19:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.617
X-Spam-Level: 
X-Spam-Status: No, score=-104.617 tagged_above=-999 required=5 tests=[AWL=-0.827, 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 ZoBYUVeTRtbz for ; Sat, 19 Jan 2013 00:19:46 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9C421F84D9 for ; Sat, 19 Jan 2013 00:19:45 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r0J8Jecs014338 for ; Sat, 19 Jan 2013 17:19:42 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 7efc_0493_f89136ca_6210_11e2_922b_001d096c5782; Sat, 19 Jan 2013 17:19:39 +0900
Received: from [IPv6:::1] ([133.2.210.1]:45782) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Sat, 19 Jan 2013 17:19:41 +0900
Message-ID: <50FA5713.5040904@it.aoyama.ac.jp>
Date: Sat, 19 Jan 2013 17:19: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: Cyrus Daboo 
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net>	<17597429-83E9-47AA-B7EC-1CB2244DB57A@nocarrier.co.uk> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps Discuss 
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Jan 2013 08:19:47 -0000

On 2013/01/18 23:50, Cyrus Daboo wrote:

> --On January 18, 2013 1:24:06 PM +0000 Ben Longden 
> wrote:

>> or just application/patch+json
>
> The trouble with those is that they do not explicitly indicate what type
> of data is being patched, only that the patch format itself is in JSON.
> Not sure if that is a big deal or not...

Well, what about just assuming that a patch format in json is for json, 
and so on. I'm sure there are exceptions to that, but for these, we can 
use longer names when they come up.

Regards,   Martin.

From dret@berkeley.edu  Sat Jan 19 00:32:05 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2224021F8573 for ; Sat, 19 Jan 2013 00:32:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.751
X-Spam-Level: 
X-Spam-Status: No, score=-5.751 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, 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 JqrwMUJ1PC1m for ; Sat, 19 Jan 2013 00:32:04 -0800 (PST)
Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id B449121F8570 for ; Sat, 19 Jan 2013 00:32:04 -0800 (PST)
Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=[192.168.0.10]) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TwTqI-00013W-Ii; Sat, 19 Jan 2013 00:32:00 -0800
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net> <17597429-83E9-47AA-B7EC-1CB2244DB57A@nocarrier.co.uk>  <50FA5713.5040904@it.aoyama.ac.jp>
In-Reply-To: <50FA5713.5040904@it.aoyama.ac.jp>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Message-Id: <376DFD56-5DD4-4759-9932-9D6C250B6514@berkeley.edu>
X-Mailer: iPad Mail (10A523)
From: Erik Wilde 
Date: Sat, 19 Jan 2013 09:31:56 +0100
To: =?utf-8?Q?"Martin_J._D=C3=BCrst"?= 
Cc: Apps Discuss 
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Jan 2013 08:32:05 -0000

hello martin.

On Jan 19, 2013, at 9:19, "Martin J. D=C3=BCrst"  wr=
ote:
> On 2013/01/18 23:50, Cyrus Daboo wrote:
>>=20
>> The trouble with those is that they do not explicitly indicate what type
>> of data is being patched, only that the patch format itself is in JSON.
>> Not sure if that is a big deal or not...
> Well, what about just assuming that a patch format in json is for json, an=
d so on. I'm sure there are exceptions to that, but for these, we can use lo=
nger names when they come up.

the first exception that comes to mind is a patch format for RDF, which (at a=
 lower syntax level) will be in XML, but actually is in RDF/XML. the best fi=
x for this might be to have suffixes for all RDF syntaxes (something along t=
he lines of ...+rdfxml), but right now RDF/XML uses application/rdf+xml.

cheers,

dret.=

From mnot@mnot.net  Sat Jan 19 16:02:41 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E34721F8767 for ; Sat, 19 Jan 2013 16:02:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.143
X-Spam-Level: 
X-Spam-Status: No, score=-105.143 tagged_above=-999 required=5 tests=[AWL=-2.544, 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 2Jua2MB4-PFc for ; Sat, 19 Jan 2013 16:02:40 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 942AF21F875F for ; Sat, 19 Jan 2013 16:02:40 -0800 (PST)
Received: from [192.168.1.80] (unknown [118.209.240.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5E5CA22E1FA; Sat, 19 Jan 2013 19:02:31 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: 
Date: Sun, 20 Jan 2013 11:02:27 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <05E6BE8E-AD72-407A-B15C-AC796494CED5@mnot.net>
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net> <17597429-83E9-47AA-B7EC-1CB2244DB57A@nocarrier.co.uk>  
To: James M Snell 
X-Mailer: Apple Mail (2.1499)
Cc: Apps Discuss 
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Jan 2013 00:02:41 -0000

Wow, are we really going to boil this ocean?

I mean, go ahead, but let's not block publication on the question of =
"what opaque string of characters should we use to identify this =
format", OK?  This is the ultimate bikeshed issue.=20

[ regarding the thread, not James' proposal ]


On 19/01/2013, at 2:46 AM, James M Snell  wrote:

> I am currently working on what I imagine will be a fairly =
controversial draft that introduces a new top level media type for patch =
documents... examples:
>=20
> patch/json
> patch/json-merge
> patch/xml
> patch/text
> patch/html=20
> ...
>=20
> The draft ought to be published by early next week.
>=20
> On Jan 18, 2013 6:50 AM, "Cyrus Daboo"  wrote:
> Hi Ben,
>=20
> --On January 18, 2013 1:24:06 PM +0000 Ben Longden =
 wrote:
>=20
> I'd suggest Simple JSON Patch, with the media type
> application/simple-json-patch.
>=20
> I'm also in the +json camp=85
>=20
> application/simple-patch+json
>=20
> or just application/patch+json
>=20
> The trouble with those is that they do not explicitly indicate what =
type of data is being patched, only that the patch format itself is in =
JSON. Not sure if that is a big deal or not...
>=20
> Someone else had suggested that there ought to be a regular syntax for =
patch media types. One suggestion was a new top-level type, e.g. =
patch/json+json, patch/xml+xml. Another option is to define something =
like 'application/patch-xxx+yyy' as the appropriate regular form.
>=20
> --=20
> Cyrus Daboo
>=20
> _______________________________________________
> 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/




From internet-drafts@ietf.org  Sat Jan 19 17:44:34 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB1D21F8797; Sat, 19 Jan 2013 17:44:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.464
X-Spam-Level: 
X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 mui+kfcJiT3L; Sat, 19 Jan 2013 17:44:33 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B1021F87B9; Sat, 19 Jan 2013 17:43:57 -0800 (PST)
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.37
Message-ID: <20130120014357.24854.63563.idtracker@ietfa.amsl.com>
Date: Sat, 19 Jan 2013 17:43:57 -0800
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-10.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, 20 Jan 2013 01:44:34 -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-10.txt
	Pages           : 17
	Date            : 2013-01-19

Abstract:
   JSON Patch defines a JSON document structure for expressing a
   sequence of operations to apply to a JavaScript Object Notation
   (JSON) document, suitable for use with the HTTP PATCH method.  The
   "application/json-patch" media type is used to identify such patch
   documents.


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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-patch-10


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From conal.tuohy@gmail.com  Sun Jan 20 05:19:46 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71ABD21F8506 for ; Sun, 20 Jan 2013 05:19:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.683
X-Spam-Level: 
X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, J_CHICKENPOX_55=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 sPmq8cwaQumv for ; Sun, 20 Jan 2013 05:19:45 -0800 (PST)
Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA1321F8505 for ; Sun, 20 Jan 2013 05:19:45 -0800 (PST)
Received: by mail-pa0-f49.google.com with SMTP id bi1so2890210pad.8 for ; Sun, 20 Jan 2013 05:19:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=17nFF5kB9P6hTLVh5k1P/MIadJoaX7UMvCWKv/Bg4Zw=; b=fyVxF6BXLNahsAKp8frn7QN6lHIb0ji3ver03Rn2XFIt05edjYwGVXEgHxo+HcQSml SFx5N0JqsybU9vrOAp00VPlBVGyPAfxcEIFwJviWw25b8a7GbJmyl5KFldxQ5VLhXuU1 O4TW4jIjqg0KGRbD1L15zPsqI9YtGCG3GaJWQEcxu3IAsztOv+aqXryH4m2gcdvyprQp sb0f96xpdbXCQRyKqU+sosZ/czHuTy0T0mxDhvlHO2oWZJHtXEOlUkhIn9ma9XZ/kiGS 6vqhTv6AIzukZ7c0XfkKR1s8ZPQ8L1e/7y/SCgSpy+r1QmDsDheridRa/FawPFuFf4Iv xTxA==
X-Received: by 10.68.228.2 with SMTP id se2mr22253424pbc.93.1358687984226; Sun, 20 Jan 2013 05:19:44 -0800 (PST)
Received: from [10.1.1.6] (d58-106-8-154.rdl801.qld.optusnet.com.au. [58.106.8.154]) by mx.google.com with ESMTPS id z10sm7275084pay.7.2013.01.20.05.19.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jan 2013 05:19:42 -0800 (PST)
Sender: Conal Tuohy 
Message-ID: <50FBEEE8.7020408@versi.edu.au>
Date: Sun, 20 Jan 2013 23:19:36 +1000
From: Conal Tuohy 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net> <17597429-83E9-47AA-B7EC-1CB2244DB57A@nocarrier.co.uk>  <50FA5713.5040904@it.aoyama.ac.jp> <376DFD56-5DD4-4759-9932-9D6C250B6514@berkeley.edu>
In-Reply-To: <376DFD56-5DD4-4759-9932-9D6C250B6514@berkeley.edu>
Content-Type: multipart/alternative; boundary="------------020605060402020408030802"
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Jan 2013 13:19:46 -0000

This is a multi-part message in MIME format.
--------------020605060402020408030802
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 19/01/13 18:31, Erik Wilde wrote:
> hello martin.
>
> On Jan 19, 2013, at 9:19, "Martin J. Dürst"  wrote:
>> On 2013/01/18 23:50, Cyrus Daboo wrote:
>>> The trouble with those is that they do not explicitly indicate what type
>>> of data is being patched, only that the patch format itself is in JSON.
>>> Not sure if that is a big deal or not...
>> Well, what about just assuming that a patch format in json is for json, and so on. I'm sure there are exceptions to that, but for these, we can use longer names when they come up.
> the first exception that comes to mind is a patch format for RDF, which (at a lower syntax level) will be in XML, but actually is in RDF/XML. the best fix for this might be to have suffixes for all RDF syntaxes (something along the lines of ...+rdfxml), but right now RDF/XML uses application/rdf+xml.
If you had access to an RDF/XML file on the web you could patch it with 
XML Patch. And I guess you could patch JSON-LD using JSON Patch. But 
IMHO if you are patching RDF graphs you would really want to treat them 
at a different level of abstraction; as RDF graphs, rather than RDF/XML 
documents or JSON-LD documents. Personally, I would use a SPARQL graph 
store, and I'd patch graphs using a SPARQL query (which of course 
already has a media type defined), as suggested in 
http://www.w3.org/TR/sparql11-http-rdf-update/#http-patch



-- 
Conal Tuohy
HuNI  Technical Coordinator 

Victorian eResearch Strategic Initiative 

Skype: conal.tuohy
Twitter: @conal_tuohy 
Mobile: +61-466324297 


--------------020605060402020408030802
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 19/01/13 18:31, Erik Wilde wrote:

    

    

      
hello martin.

On Jan 19, 2013, at 9:19, "Martin J. Dürst" <duerst@it.aoyama.ac.jp> wrote:


      

        
On 2013/01/18 23:50, Cyrus Daboo wrote:


        

          
The trouble with those is that they do not explicitly indicate what type
of data is being patched, only that the patch format itself is in JSON.
Not sure if that is a big deal or not...


        

        
Well, what about just assuming that a patch format in json is for json, and so on. I'm sure there are exceptions to that, but for these, we can use longer names when they come up.


      

      
the first exception that comes to mind is a patch format for RDF, which (at a lower syntax level) will be in XML, but actually is in RDF/XML. the best fix for this might be to have suffixes for all RDF syntaxes (something along the lines of ...+rdfxml), but right now RDF/XML uses application/rdf+xml.

    

    If you had access to an RDF/XML file on the web you could patch it
    with XML Patch. And I guess you could patch JSON-LD using JSON
    Patch. But IMHO if you are patching RDF graphs you would really want
    to treat them at a different level of abstraction; as RDF graphs,
    rather than RDF/XML documents or JSON-LD documents. Personally, I
    would use a SPARQL graph store, and I'd patch graphs using a SPARQL
    query (which of course already has a media type defined), as
    suggested in
    http://www.w3.org/TR/sparql11-http-rdf-update/#http-patch

    

    

    

    
-- 

      

        Conal Tuohy

        HuNI Technical
          Coordinator

        Victorian
          eResearch Strategic Initiative

        Skype: conal.tuohy

        Twitter: @conal_tuohy

        Mobile: +61-466324297
      

    

  


--------------020605060402020408030802--

From dret@berkeley.edu  Sun Jan 20 08:05:31 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A427C21F858E for ; Sun, 20 Jan 2013 08:05:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.493
X-Spam-Level: 
X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106,  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 4qG805+Ewtwk for ; Sun, 20 Jan 2013 08:05:30 -0800 (PST)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id A8F5021F858C for ; Sun, 20 Jan 2013 08:05:30 -0800 (PST)
Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretpro.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TwxOh-0000iJ-8e; Sun, 20 Jan 2013 08:05:28 -0800
Message-ID: <50FC15C3.6020106@berkeley.edu>
Date: Sun, 20 Jan 2013 17:05:23 +0100
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Conal Tuohy 
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net> <17597429-83E9-47AA-B7EC-1CB2244DB57A@nocarrier.co.uk>  <50FA5713.5040904@it.aoyama.ac.jp> <376DFD56-5DD4-4759-9932-9D6C250B6514@berkeley.edu> <50FBEEE8.7020408@versi.edu.au>
In-Reply-To: <50FBEEE8.7020408@versi.edu.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Jan 2013 16:05:31 -0000

hello conal.

On 2013-01-20 14:19 , Conal Tuohy wrote:
> If you had access to an RDF/XML file on the web you could patch it with
> XML Patch.

you could, yes, but that would be like trying to PATCH XML with a 
text-based diff method: Not A Good Idea.

> And I guess you could patch JSON-LD using JSON Patch. But
> IMHO if you are patching RDF graphs you would really want to treat them
> at a different level of abstraction; as RDF graphs, rather than RDF/XML
> documents or JSON-LD documents. Personally, I would use a SPARQL graph
> store, and I'd patch graphs using a SPARQL query (which of course
> already has a media type defined), as suggested in
> http://www.w3.org/TR/sparql11-http-rdf-update/#http-patch

yes, i've seen SPARQL being suggested for RDF patch. to me it feels a 
bit like patching XML with XQuery: possible, but pulling in a lot of 
machinery that may be overkill. 
http://semanticweb.com/http-patch-and-tracking-rdf-changes_b15382 
suggests that SPARQL is one way to, but there are less complex 
possibilities as well (ChangeSets).

one way or the other, the point i was trying to make was actually that 
any kind of RDF patch format probably would be defined in RDF (SPARQL 
may be an exception here), and thus could be encoded in the various 
syntaxes that RDF has. the patch format would apply to RDF (the model), 
and would be serialized in some RDF syntax. both of these facts would 
need to be captured in a media type name.

cheers,

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 jyee@afilias.info  Sun Jan 20 20:00:09 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3C621F869C for ; Sun, 20 Jan 2013 20:00:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.622
X-Spam-Level: 
X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[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 OIGSRxnuKBB2 for ; Sun, 20 Jan 2013 20:00:09 -0800 (PST)
Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id DE4E921F88E2 for ; Sun, 20 Jan 2013 20:00:08 -0800 (PST)
Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1Tx8YJ-0003fo-44 for apps-discuss@ietf.org; Mon, 21 Jan 2013 04:00:07 +0000
Received: from mail-oa0-f70.google.com ([209.85.219.70]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Tx8YJ-0003qa-3p for apps-discuss@ietf.org; Mon, 21 Jan 2013 04:00:07 +0000
Received: by mail-oa0-f70.google.com with SMTP id k14so28040785oag.5 for ; Sun, 20 Jan 2013 20:00:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=XU6cyFEoLBuMZXTzgdoMaBSQf55zlINgzVe5noz7v+s=; b=QGXRybtW/DR6z/EXYxVwGzbCv4lTXO9vMzlIv63OglZuEGFI16DV4o7mf94Jx78AEM uOM0VNOdmcJCB6K5WRlWECrJScyYxTJv1ozSWqgSeZNKxzeGkPGMWSiIt0i/BSUw/uCW WzYfip69+gBIkvoQgqHgAHvg1ZpJ2LozVKtpUq3BYn3+4MGWRcxfUPmfofjoO89TljWj 82Pmf6GjfXj1vHvTxDM5xKYSdsccYNbzqEyIvjsCg9cWQmWrGgOK8PljnUlTIfaLJe7q zH11VRYuFJEaiHyNRA6iJQqzdDxnHDfq/DvFOdrtz4bh0+60l2hqG77WCCJAlII4FC1c x0dg==
X-Received: by 10.182.152.9 with SMTP id uu9mr3050936obb.9.1358740801733; Sun, 20 Jan 2013 20:00:01 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.152.9 with SMTP id uu9mr3050934obb.9.1358740801644; Sun, 20 Jan 2013 20:00:01 -0800 (PST)
Received: by 10.76.23.68 with HTTP; Sun, 20 Jan 2013 20:00:01 -0800 (PST)
Date: Sun, 20 Jan 2013 23:00:01 -0500
Message-ID: 
From: Joseph Yee 
To: apps-discuss@ietf.org, draft-ietf-rmt-fcast.all@tools.ietf.org
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQngWpZeqBQ45EuppWWpxPbz9RyT/sL2kvyXrwT46p6XhKTG5X3nLL3C/7+m4QUY9HKaKNMwiAn3dTqTTBVqp1kQ0zYl5FJaOKfxFV2XHYUnuYpIdUaV1BqKv8HXN5k0m9r9iljXSQLy08y4MBIEv1RaRepj1g==
Cc: The IESG 
Subject: [apps-discuss] APPSDIR review of draft-ietf-rmt-fcast-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Jan 2013 04:00:09 -0000

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-rmt-fcast-07
Title: FCAST: Scalable Object Delivery for the ALC and NORM Protocols
Reviewer: Joseph Yee
Review Date: 2013-01-20
IETF Last Call Date: 2013-01-22
IESG Telechat Date: 2013-01-24

Summary: This draft is almost ready for publication as Proposed Standard


Major Issues:
    None

Minor Issues:

    It takes me awhile to understand the document, partly I think the
information flow is broken (another part is that I'm not familiar with
the subject).  If the principle section (Section 3) was followed by
Implementation section (Section 5) instead, I think it will be better
to reader.  IMHO, the order of FCAST Principles -> Requirement for
Compliant Implementation -> Security Consideration would be a better
flow.

Nits:
    None, maybe a little xml comment to ask RFC Editors to help
reordering references based on RFC numbers :)

From salvatore.loreto@ericsson.com  Mon Jan 21 05:36:14 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097F421F8620; Mon, 21 Jan 2013 05:36:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.248
X-Spam-Level: 
X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 oBpK59E4hPZQ; Mon, 21 Jan 2013 05:36:13 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D671421F8600; Mon, 21 Jan 2013 05:36:10 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-18-50fd4449df77
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 07.2C.32353.9444DF05; Mon, 21 Jan 2013 14:36:09 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 21 Jan 2013 14:36:09 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 458E724ED; Mon, 21 Jan 2013 15:36:09 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 82A7654104; Mon, 21 Jan 2013 15:36:07 +0200 (EET)
Received: from n94.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3615953DEE; Mon, 21 Jan 2013 15:36:07 +0200 (EET)
Message-ID: <50FD4448.7030002@ericsson.com>
Date: Mon, 21 Jan 2013 15:36:08 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "apps-discuss@ietf.org" ,  draft-ietf-rmt-flute-sdp@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------080601070309080708050009"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUyM+Jvra6ny98Agz27TS1Wv1zBZnHy1RlG ixl/JjI7MHssWfKTyePL5c9sAUxRXDYpqTmZZalF+nYJXBldUz+xFiwzq5jVZtrAuFq3i5GT Q0LARGLS8aWsELaYxIV769m6GLk4hAROMkpMnHOUGSQhJLCBUeJuNwdEYhejxP+/n5kgnLWM Eq/WHWWEcJYySpx/cowNpIVXQFvi8ZZv7CA2i4CqxPtHl8B2sAmYSTx/uAVsrKhAssTHO9dY IeoFJU7OfMICYosIxEssuNvDCGIzC8hIHD2zEiwuDNR7bc1NNoh4mMTRpfcZIe5Wk7h6bhPU qVoSvWc7mSYwCs1CMnYWkhYI21biwpzrUHF5ie1v5zBD2LoSF/5PQRFfwMi2ipE9NzEzJ73c fBMjMAIObvltsINx032xQ4zSHCxK4rzhrhcChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAG /19m5cqzXeW0yKF9W/9+/hPetKzagenZb8ZiXs4qltu2B+8cOl8rx77zwvQrHTMXfGBK3XJa 4Hb0ZqO8pYdXyngcv2Uxz0Fo7p1qrWddcXUHFxyzSOZ8Yr2i/EqekN+VizpVLi5GixNcSzX+ 8tby5avkq5tyuHovTUq/+FvjSe/jGemrgo4qsRRnJBpqMRcVJwIAN+y4y04CAAA=
Cc: The IESG 
Subject: [apps-discuss] APPSDIR review of draft-ietf-rmt-flute-sdp-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: Mon, 21 Jan 2013 13:36:14 -0000

--------------080601070309080708050009
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate  ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-rmt-flute-sdp-03
Title: SDP Descriptors for FLUTE
Reviewer: Salvatore Loreto
Review Date: 2013-01-21
IETF Last Call Date: 2013-01-22
IESG Telechat Date: 2013-01-24

Summary: This draft is almost ready for publication as Proposed Standard


Major Issues:
     None

Minor Issues:
-------------
1)3.2.1.  Composite Session Semantics for FLUTE Sessions


  
1.1) second paragraph, the first sentence states:

    "The Composite Session provides an unambiguous way to define multiple
    FLUTE sessions as distinct from multiple the media-sessions semantics
    of RTP."

I guess it should be somethin glike

    "The Composite Session provides an unambiguous way to define multiple
    FLUTE sessions as distinct.


1.2) the following sentece in the same paragraph states:

    "It is used for describing more than one FLUTE session in an
    SDP instance and so its general use and support in SDP are OPTIONAL."

I would suggest to change in something like

    As it is used for describing more than one FLUTE session in an
    SDP instance this SDP parameter is OPTIONAL.

2) the follow sentence should be added to the end of the section "Section 6.1 Transport Protocol"

These proto values should be registered by the IANA under "Session Description Protocol (SDP) Parameters" under "proto".

3) in Section 6.2 Attribute Name

the sentence

    As recommended by [RFC4566  ], the new attribute names "flute-tsi",
    "flute-ch", "FEC-declaration", "FEC", "FEC-OTI-extension" and
    "content-desc" should be registered with IANA, as follows:

should be modified in

    As recommended by [RFC4566  ], the new attribute names "flute-tsi",
    "flute-ch", "FEC-declaration", "FEC", "FEC-OTI-extension" and
    "content-desc" should beregistered by IANA under "Session
     Description Protocol (SDP) Parameters" under "att-field"  as
    follows:

please also check which "att-field" is the right one for each attribute the draft is requesting registration!


Nits:
-----
- the draft still refence the draft-ietf-rmt-flute-revised-16 while it is now RFC 6726




--------------080601070309080708050009
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  

    
  
  
    
I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-rmt-flute-sdp-03
Title: SDP Descriptors for FLUTE
Reviewer: Salvatore Loreto
Review Date: 2013-01-21
IETF Last Call Date: 2013-01-22
IESG Telechat Date: 2013-01-24

Summary: This draft is almost ready for publication as Proposed Standard


Major Issues:
    None

Minor Issues:
-------------
1) 3.2.1.  Composite Session Semantics for FLUTE Sessions

 
1.1) second paragraph, the first sentence states:

   "The Composite Session provides an unambiguous way to define multiple
   FLUTE sessions as distinct from multiple the media-sessions semantics
   of RTP."

I guess it should be somethin glike 

   "The Composite Session provides an unambiguous way to define multiple
   FLUTE sessions as distinct. 

1.2) the following sentece in the same paragraph states:

   "It is used for describing more than one FLUTE session in an
   SDP instance and so its general use and support in SDP are OPTIONAL."

I would suggest to change in something like

   As it is used for describing more than one FLUTE session in an
   SDP instance this SDP parameter is OPTIONAL.


2) the follow sentence should be added to the end of the section "Section 6.1 Transport Protocol" 

These proto values should be registered by the IANA under "Session Description Protocol (SDP) Parameters" under "proto".


3) in Section 6.2 Attribute Name

the sentence

   As recommended by [RFC4566], the new attribute names "flute-tsi",
   "flute-ch", "FEC-declaration", "FEC", "FEC-OTI-extension" and
   "content-desc" should be registered with IANA, as follows:
should be modified in 

   As recommended by [RFC4566], the new attribute names "flute-tsi",
   "flute-ch", "FEC-declaration", "FEC", "FEC-OTI-extension" and
   "content-desc" should be registered by IANA under "Session  
    Description Protocol (SDP) Parameters" under "att-field"  as  
   follows:
please also check which "att-field" is the right one for each attribute the draft is requesting registration!



Nits:
-----
- the draft still refence the draft-ietf-rmt-flute-revised-16 while it is now RFC 6726    





  


--------------080601070309080708050009--

From paul.hoffman@vpnc.org  Mon Jan 21 08:08:09 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03CE21F8536 for ; Mon, 21 Jan 2013 08:08:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 v+-8BZWS9WQC for ; Mon, 21 Jan 2013 08:08:08 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 94BBA21F852C for ; Mon, 21 Jan 2013 08:08:08 -0800 (PST)
Received: from [10.20.30.101] (50-1-51-83.dsl.dynamic.fusionbroadband.com [50.1.51.83]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r0LG7OvG024407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 21 Jan 2013 09:08:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
From: Paul Hoffman 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Mon, 21 Jan 2013 08:08:07 -0800
To: "apps-discuss@ietf.org Discuss" 
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Subject: [apps-discuss] New proposal for a DNS API
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Jan 2013 16:08:10 -0000

Greetings again. There are a few DNS application programming interfaces =
(APIs) available that cover things like DNSSEC and non-address records, =
but none that have garnered much interest from the application =
developers who should be their primary audience. To remedy that, I have =
created a new design for such an API. I did that outside the IETF, of =
course, given the IETF's general "we don't do APIs" stance.

Please see http://www.vpnc.org/getdns-api/ for the current API proposal =
and description of the design principles I used to put it together. I am =
still seeking input from application developers to say what they would =
really want to see in an API, and from DNS people to say which parts of =
the DNS should be exposed in what ways to application developers. I =
based the design on input from an informal gang of application =
developers, but I'm sure that other application developers have thought =
"what I really want from the DNS is X and I want to be able to ask in =
with an API that does Y". At some point in the not-distant-future, I =
will call the design "finished" and hopefully someone will want to =
implement it.

Please don't discuss the design on the Application Area mailing list; it =
is really not appropriate here given that this is not IETF work. I just =
wanted to alert folks of this work.

--Paul Hoffman=

From alexey.melnikov@isode.com  Mon Jan 21 10:40:44 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DBF21F8B8A; Mon, 21 Jan 2013 10:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 xSApjDUtHPgz; Mon, 21 Jan 2013 10:40:43 -0800 (PST)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 29E4721F8992; Mon, 21 Jan 2013 10:40:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1358793642; d=isode.com; s=selector; i=@isode.com; bh=NwTvC10DAHMviOS2dDsNfG3KjgtF53s2kTN/zHX0HPE=; 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=cKz20NBCozOdPDvTRMfOx0KLbi8gw2+nf71NsHjnR8U5DZFtwswryXBe9KyhXBlWis9FAa 2sQ8id/QXrZidx95VcFKG/NqZLtGU3VsI6cm1dj0e8rRuAIot9oIpUmTfbZfCnQdcfiM5K DYUaZF5RtVvPEWD59BxYOUsT+PPR0fM=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250])  by statler.isode.com (submission channel) via TCP with ESMTPA  id ; Mon, 21 Jan 2013 18:40:41 +0000
Message-ID: <50FD8BB8.9060200@isode.com>
Date: Mon, 21 Jan 2013 18:40:56 +0000
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, draft-laurie-pki-sunlight.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
Cc: iesg@ietf.org
Subject: [apps-discuss] APPSDIR review of draft-laurie-pki-sunlight-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Jan 2013 18:40:44 -0000

I have been selected as the Applications Area Directorate reviewer for=20
this draft (for background on appsdir, please see =E2=80=8B=20
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive.  Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-laurie-pki-sunlight-05
Title: Certificate Transparency
Reviewer: Alexey Melnikov
Review Date: 2013-01-21
IETF Last Call Date: 2013-01-24
IESG Telechat Date: unknown

Summary:

This draft is nearly ready for publication as an Experimental RFC. I=20
think a revision should be able to address my issues (and issues raised=20
by Eliot earlier).

Major Issues:
   none

Minor Issues:

1) There are no references for SHA-256/TLS/RSA in the document. They are=20
Normative and should be added.

2) Section 4 needs references for JSON, base64 and HTTP.

3) Section 4.1: it would be good to have an example.

4) In 4.5/4.6: are indexes 0-based or 1-based?

From internet-drafts@ietf.org  Mon Jan 21 14:25:00 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E007B21F86D8; Mon, 21 Jan 2013 14:25:00 -0800 (PST)
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 AUz8RtRkmuAL; Mon, 21 Jan 2013 14:25:00 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6062521F85C3; Mon, 21 Jan 2013 14:25:00 -0800 (PST)
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.37
Message-ID: <20130121222500.14613.91525.idtracker@ietfa.amsl.com>
Date: Mon, 21 Jan 2013 14:25:00 -0800
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-09.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, 21 Jan 2013 22:25:01 -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           : JavaScript Object Notation (JSON) Pointer
	Author(s)       : Paul C. Bryan
                          Kris Zyp
                          Mark Nottingham
	Filename        : draft-ietf-appsawg-json-pointer-09.txt
	Pages           : 8
	Date            : 2013-01-21

Abstract:
   JSON Pointer defines a string syntax for identifying a specific value
   within a JavaScript Object Notation (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-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-pointer-09


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From barryleiba.mailing.lists@gmail.com  Mon Jan 21 14:34:54 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83B321F843E for ; Mon, 21 Jan 2013 14:34:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.805
X-Spam-Level: 
X-Spam-Status: No, score=-103.805 tagged_above=-999 required=5 tests=[AWL=-0.828, 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 OeAreufklR-O for ; Mon, 21 Jan 2013 14:34:54 -0800 (PST)
Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3B13A21F8430 for ; Mon, 21 Jan 2013 14:34:54 -0800 (PST)
Received: by mail-vb0-f41.google.com with SMTP id l22so2236111vbn.0 for ; Mon, 21 Jan 2013 14:34:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TLPx+lYYm6d8EpzrM39bd3sna+426Bmmg+upmviAehA=; b=h49GI7CLdBoWsu6u6DWRGI3NFERY8uyur2e2xyhynufpTyE2GImpCA81A7oboDgx9C YeSQ5aFz9FW+0kvcZoPEgGwrLLVF5h/9AOj739Z42w+OOGNveVKP1KfRSZ/ORrtzaIIz OkjTkK8BxDWFsUu0Qj8rjY6Xyc2E06urOFgBHOjUSAyVqzkExt5QYJQM7gcGRdo5xXvL q8oaA/oEmnrZKq3FMyNaju8mX5jMTT90SqmBGFOLW6dIPNFRWp10yHCQpD/OY2Xp3l5e YN9NuVoh1JomyMuZEGgjUHp4ANAKPl+AntYlwv2qQv7BCyFyv1Jp0hNYKeY0wgQrl1sE TSnw==
MIME-Version: 1.0
X-Received: by 10.52.91.142 with SMTP id ce14mr18637617vdb.84.1358807692241; Mon, 21 Jan 2013 14:34:52 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Mon, 21 Jan 2013 14:34:51 -0800 (PST)
In-Reply-To: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net>
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net>
Date: Mon, 21 Jan 2013 17:34:51 -0500
X-Google-Sender-Auth: shPBc3nzupsurTc_gO3JmuhPfbY
Message-ID: 
From: Barry Leiba 
To: Mark Nottingham 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Apps Discuss 
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Jan 2013 22:34:55 -0000

> It's becoming apparent that there are likely to be a few different flavours of JSON
> Patch out there, so it may make sense to give the one we're working on now a bit
> more of a distinctive name.

It strikes me, on reading the responses to this, that we have no
consensus for any change.  While it's true that this should have been
developed with a "+json" suffix, and that perhaps we should have used
a different name in the first place, there are too many differing
opinons on what the right fix is, it's a very late stage to be trying
to make this change now, and it's not important enough for it to be
worth running the document back through any process at this point.

So I'm going to go ahead and give the final approval for the document
as it stands.

Barry, Applications AD

From barryleiba.mailing.lists@gmail.com  Mon Jan 21 14:37:59 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24BB421F843E for ; Mon, 21 Jan 2013 14:37:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.139
X-Spam-Level: 
X-Spam-Status: No, score=-103.139 tagged_above=-999 required=5 tests=[AWL=-1.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 DUYWQga7LmFp for ; Mon, 21 Jan 2013 14:37:58 -0800 (PST)
Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id 96A0C21F8430 for ; Mon, 21 Jan 2013 14:37:58 -0800 (PST)
Received: by mail-ve0-f174.google.com with SMTP id c13so364376vea.19 for ; Mon, 21 Jan 2013 14:37:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=JWjOfdgfjIutvOvaIAvdS2+JzPFBAB7c6arcbVsKeUE=; b=ps0XWb6zg7NX2sMJm540pV0TjCDyeCHr3a3T7BP21mEse68/43CJmVJPrq8Wm76DCR W0XN5iaZwulNnlrrgRJO0hYU+bFkQf8xoCGfxi0PT03A9Uyk0s/g7kKckU3EWxfQ4P1A UuY5X3Rjd/QaDiO+Zi/T8Cj01hB8i0jMoaRhqlan6kVxE2UQyLvsQELxld/cyTSUl05R 35EVlfYhKJLEb1BidEPJuvZ+pbb5JPNvlbODWbd6CsJKoykaicCv/Y/q50SYb94HD4Ta HiIb1hXZFcFZI86Cd0uYHIoNrwHUXhwP05BeqyY4ZUJvDlSifYbwwtArImRNPKXBN2gM qy2Q==
MIME-Version: 1.0
X-Received: by 10.52.88.33 with SMTP id bd1mr18415765vdb.70.1358807877999; Mon, 21 Jan 2013 14:37:57 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Mon, 21 Jan 2013 14:37:57 -0800 (PST)
In-Reply-To: 
References: 
Date: Mon, 21 Jan 2013 17:37:57 -0500
X-Google-Sender-Auth: lzoJpLJPD0fjUl8KnMVf5QfEGuA
Message-ID: 
From: Barry Leiba 
To: Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [apps-discuss] The "array vs object" issue in JSON Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Jan 2013 22:37:59 -0000

> Given those considerations, the question is this: Does the working
> group stand by its rough consensus for the JSON Pointer syntax as it
> stands?  Or might it be better to make a syntactic distinction between
> arrays and objects now, while we can, to be more robust for the
> future?  (Or, on the other hand, for those who have three hands, would
> it actually *harm* the protocol to change this?)

The answer to my set of questions is clear, given the responses I've
seen: the working group is not interested in thinking about this
further and no one has changed her mind.  The consensus stands.  I've
asked Mark to post a final draft update that fixes a minor wording
thing, and I'm going to push the "approval" button.

I personally would have preferred a different outcome, but the working
group has the decision and has made it.  And I thank everyone for
taking the time to re-iterate that clearly.

Barry, Applications AD

From conal.tuohy@gmail.com  Mon Jan 21 14:52:29 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392AF21F86EA for ; Mon, 21 Jan 2013 14:52:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.743
X-Spam-Level: 
X-Spam-Status: No, score=-2.743 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, J_CHICKENPOX_55=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 05fm3YY2d9dz for ; Mon, 21 Jan 2013 14:52:28 -0800 (PST)
Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB1521F875C for ; Mon, 21 Jan 2013 14:52:27 -0800 (PST)
Received: by mail-pb0-f51.google.com with SMTP id ro12so3568775pbb.24 for ; Mon, 21 Jan 2013 14:52:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=onTtdmo5JPlT6ksNwbRHe/Qd8pa6SIesNCbP6qeO5pQ=; b=CCSdYpw9IqicNVN9frUp1Gozsf7TJ+zCUOWywwCUAd3Ba60k0r+EenaiPwR8OKiJM3 US1g0B2qesBeEuvH376OWx3gZTSizmglxVvXMle2jVlJS66bYA9tt4fA+CvWTW0Y1LyM rFBCx0ZNgHkwGcnJ/IBMQGzzrU7oS53IbTrkIXI12y9NgVvxNUcPlP6BEWh+nWLIqxQK zjjmshO4Kx+3x9vPK14E37UN8W7Qv59+R8KKiHcqNB5WLGvxDv05noBi/AVGsicKdcZK mrHH1sCgrwPjzvxsL3GuKDXiW3UJnzvcQCiuuahveGL2kJPRvVp1NpKmzNymT8mWKvQX TaoQ==
X-Received: by 10.66.78.168 with SMTP id c8mr51066273pax.16.1358808746596; Mon, 21 Jan 2013 14:52:26 -0800 (PST)
Received: from [130.56.26.120] ([130.56.26.120]) by mx.google.com with ESMTPS id sy1sm9413551pbc.66.2013.01.21.14.52.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jan 2013 14:52:24 -0800 (PST)
Sender: Conal Tuohy 
Message-ID: <50FDC6A4.8040700@versi.edu.au>
Date: Tue, 22 Jan 2013 08:52:20 +1000
From: Conal Tuohy 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070501060701060602060301"
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Jan 2013 22:52:29 -0000

This is a multi-part message in MIME format.
--------------070501060701060602060301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Barry

It seemed to me, on the contrary, that there was a broad consensus at 
least that the +json should be used. I think it would be a shame if the 
differences of opinion about the name *as a whole* were an obstacle to 
accepting the suffix, because the usefulness of the suffix is generally 
accepted, and it applies regardless of what the rest of the name is. 
Given that, I'd suggest that it would make sense to append the suffix be 
appended to the current name. Is there any reason not to do that?

Con

On 22/01/13 08:34, Barry Leiba wrote:
>> It's becoming apparent that there are likely to be a few different flavours of JSON
>> Patch out there, so it may make sense to give the one we're working on now a bit
>> more of a distinctive name.
> It strikes me, on reading the responses to this, that we have no
> consensus for any change.  While it's true that this should have been
> developed with a "+json" suffix, and that perhaps we should have used
> a different name in the first place, there are too many differing
> opinons on what the right fix is, it's a very late stage to be trying
> to make this change now, and it's not important enough for it to be
> worth running the document back through any process at this point.
>
> So I'm going to go ahead and give the final approval for the document
> as it stands.
>
> Barry, Applications AD
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>


-- 
Conal Tuohy
HuNI  Technical Coordinator 

Victorian eResearch Strategic Initiative 

Skype: conal.tuohy
Twitter: @conal_tuohy 
Mobile: +61-466324297 


--------------070501060701060602060301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Barry

      

      It seemed to me, on the contrary, that there was a broad consensus
      at least that the +json should be used. I think it would be a
      shame if the differences of opinion about the name *as a whole*
      were an obstacle to accepting the suffix, because the usefulness
      of the suffix is generally accepted, and it applies regardless of
      what the rest of the name is. Given that, I'd suggest that it
      would make sense to append the suffix be appended to the current
      name. Is there any reason not to do that? 

      

      Con

      

      On 22/01/13 08:34, Barry Leiba wrote:

    

    

      

        
It's becoming apparent that there are likely to be a few different flavours of JSON
Patch out there, so it may make sense to give the one we're working on now a bit
more of a distinctive name.


      

      
It strikes me, on reading the responses to this, that we have no
consensus for any change.  While it's true that this should have been
developed with a "+json" suffix, and that perhaps we should have used
a different name in the first place, there are too many differing
opinons on what the right fix is, it's a very late stage to be trying
to make this change now, and it's not important enough for it to be
worth running the document back through any process at this point.

So I'm going to go ahead and give the final approval for the document
as it stands.

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



    

    

    

    
-- 

      

        Conal Tuohy

        HuNI Technical
          Coordinator

        Victorian
          eResearch Strategic Initiative

        Skype: conal.tuohy

        Twitter: @conal_tuohy

        Mobile: +61-466324297
      

    

  


--------------070501060701060602060301--

From duerst@it.aoyama.ac.jp  Mon Jan 21 16:16:41 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA8321F8464 for ; Mon, 21 Jan 2013 16:16:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.79
X-Spam-Level: 
X-Spam-Status: No, score=-99.79 tagged_above=-999 required=5 tests=[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 25LPbeq3v45l for ; Mon, 21 Jan 2013 16:16:37 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id B4C9F21F8460 for ; Mon, 21 Jan 2013 16:16:33 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r0M0GS1V024782 for ; Tue, 22 Jan 2013 09:16:28 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 5c43_2de5_f755858a_6428_11e2_9f59_001d096c566a; Tue, 22 Jan 2013 09:16:28 +0900
Received: from [IPv6:::1] ([133.2.210.1]:35915) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Tue, 22 Jan 2013 09:16:28 +0900
Message-ID: <50FDDA5A.5090805@it.aoyama.ac.jp>
Date: Tue, 22 Jan 2013 09:16:26 +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: Conal Tuohy 
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net>	 <50FDC6A4.8040700@versi.edu.au>
In-Reply-To: <50FDC6A4.8040700@versi.edu.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Jan 2013 00:16:42 -0000

+1.   Regards,   Martin.

On 2013/01/22 7:52, Conal Tuohy wrote:
> Hi Barry
>
> It seemed to me, on the contrary, that there was a broad consensus at
> least that the +json should be used. I think it would be a shame if the
> differences of opinion about the name *as a whole* were an obstacle to
> accepting the suffix, because the usefulness of the suffix is generally
> accepted, and it applies regardless of what the rest of the name is.
> Given that, I'd suggest that it would make sense to append the suffix be
> appended to the current name. Is there any reason not to do that?
>
> Con

From stefan@skoegl.net  Mon Jan 21 23:02:47 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE05621F886F for ; Mon, 21 Jan 2013 23:02:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.874
X-Spam-Level: 
X-Spam-Status: No, score=-0.874 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HELO_IS_SMALL6=0.556, HOST_EQ_AT=0.745]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUgeeMaS7Za9 for ; Mon, 21 Jan 2013 23:02:47 -0800 (PST)
Received: from k-wh.at (k-wh.at [83.169.20.177]) by ietfa.amsl.com (Postfix) with ESMTP id 24C8721F8746 for ; Mon, 21 Jan 2013 23:02:46 -0800 (PST)
Received: by k-wh.at (Postfix, from userid 33) id 5B5E99308001; Tue, 22 Jan 2013 08:02:45 +0100 (CET)
To: apps-discuss@ietf.org
MIME-Version: 1.0
Date: Tue, 22 Jan 2013 08:02:45 +0100
From: 
Message-ID: 
X-Sender: stefan@skoegl.net
User-Agent: RoundCube Webmail/0.2.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Jan 2013 07:02:47 -0000

On 21.01.2013 23:52, Conal Tuohy wrote:
> It seemed to me, on the contrary, that there was a broad consensus at
> least that the +json should be used. I think it would be a shame if the
> differences of opinion about the name *as a whole* were an obstacle to
> accepting the suffix, because the usefulness of the suffix is generally
> accepted, and it applies regardless of what the rest of the name is.
> Given that, I'd suggest that it would make sense to append the suffix be
> appended to the current name. Is there any reason not to do that?

+1


From cabo@tzi.org  Mon Jan 21 23:40:59 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F4621F84C7 for ; Mon, 21 Jan 2013 23:40:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.099
X-Spam-Level: 
X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 1dVsPXU6VEg1 for ; Mon, 21 Jan 2013 23:40:59 -0800 (PST)
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 2313321F845E for ; Mon, 21 Jan 2013 23:40:58 -0800 (PST)
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 r0M7eokW000924; Tue, 22 Jan 2013 08:40:50 +0100 (CET)
Received: from [192.168.217.105] (p548919DD.dip.t-dialin.net [84.137.25.221]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C8000325; Tue, 22 Jan 2013 08:40:49 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <50F903BF.1050903@it.aoyama.ac.jp>
Date: Tue, 22 Jan 2013 08:40:48 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <387A8EF6-B188-47AE-A134-16983A3B8D20@tzi.org>
References:  <50F903BF.1050903@it.aoyama.ac.jp>
To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= 
X-Mailer: Apple Mail (2.1499)
Cc: Apps Discuss 
Subject: Re: [apps-discuss] The "array vs object" issue in JSON Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Jan 2013 07:41:00 -0000

On Jan 18, 2013, at 09:11, Martin J. D=FCrst  =
wrote:

> The reason for this is that JavaScript itself also allows me

Right outcome, wrong reasoning.
What is good in a programming language may or may not be good in a =
protocol.

Gr=FC=DFe, Carsten

PS.: Yes, thinking in analogies can sometimes help elicit good =
arguments.
But these arguments still need to be validated in the target =
environment.

I think what caused most people in the WG to want to stick with the =
current version is that nobody has demonstrated a good enough reason for =
wanting this feature in the protocol.

(Sorry for being off-topic by contributing to reopening the discussion.
I just think there is something that can be learned from it.)


From nico@cryptonector.com  Tue Jan 22 00:36:42 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCF021F8692 for ; Tue, 22 Jan 2013 00:36:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 CEMQdV4y+UgX for ; Tue, 22 Jan 2013 00:36:42 -0800 (PST)
Received: from homiemail-a98.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 341CA21F85C6 for ; Tue, 22 Jan 2013 00:36:42 -0800 (PST)
Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 9FDA22C2060 for ; Tue, 22 Jan 2013 00:36:37 -0800 (PST)
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=lVfboZTPGEktTTdukTECcwczbec=; b=Djc881loGCY 3eomYwwnMnn4gSMdXv9o3Mk7F8RDBO9iUAXp9N/fLoHm1zX9XQkklpo7VaH6wFWC +GRAgHjVaSjXexJ5Z1DNWgGYJtZ2JfZfFnirmBNDBnXfX1d0/QdvjKW+LLs79z7b DgSIyivJtWI7Q2D8Ymf4pxgkixYcMDgY=
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 495042C2059 for ; Tue, 22 Jan 2013 00:36:37 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id hm2so5663604wib.16 for ; Tue, 22 Jan 2013 00:36:35 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.58.113 with SMTP id p17mr30706998wjq.27.1358843795501; Tue, 22 Jan 2013 00:36:35 -0800 (PST)
Received: by 10.216.43.8 with HTTP; Tue, 22 Jan 2013 00:36:35 -0800 (PST)
In-Reply-To: <387A8EF6-B188-47AE-A134-16983A3B8D20@tzi.org>
References:  <50F903BF.1050903@it.aoyama.ac.jp> <387A8EF6-B188-47AE-A134-16983A3B8D20@tzi.org>
Date: Tue, 22 Jan 2013 02:36:35 -0600
Message-ID: 
From: Nico Williams 
To: Carsten Bormann 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Apps Discuss 
Subject: Re: [apps-discuss] The "array vs object" issue in JSON Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Jan 2013 08:36:43 -0000

On Tue, Jan 22, 2013 at 1:40 AM, Carsten Bormann  wrote:
> On Jan 18, 2013, at 09:11, Martin J. D=C3=BCrst  =
wrote:
>
>> The reason for this is that JavaScript itself also allows me
>
> Right outcome, wrong reasoning.
> What is good in a programming language may or may not be good in a protoc=
ol.

The protocol is built on a subset of *the* language from which JSON is
derived.  (And it may well be implemented using that language in some
cases.)

That there's a protocol involved doesn't change the fundamental
property of the language on which it is modeled: that type errors are
run-time errors.  Indeed, adding type hints to JSON Pointer wouldn't
even change that property: protocol errors are also run-time errors in
this case.

Martin's point was a good one.

Nico
--

From nico@cryptonector.com  Tue Jan 22 00:40:51 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A449321F8611 for ; Tue, 22 Jan 2013 00:40:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.528
X-Spam-Level: 
X-Spam-Status: No, score=-4.528 tagged_above=-999 required=5 tests=[AWL=-2.551, 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 yCNRcoYrpEPm for ; Tue, 22 Jan 2013 00:40:51 -0800 (PST)
Received: from homiemail-a30.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 1795E21F85E8 for ; Tue, 22 Jan 2013 00:40:51 -0800 (PST)
Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id DB4D721DE6F for ; Tue, 22 Jan 2013 00:40:50 -0800 (PST)
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=wlTbGu6n24acZYggd4tj7XumKhA=; b=UCbrTRuqmkX 1VtNQ5uQce8DZ9NV75VPBzbwPvCKz9Op1B6Qr2iMxx1iUTkLZZ0djooj3uh5dOKm G7bDxFF92TgWifoadfnfBogsMJGu+giA+DyxfPMoncd8Nn/Uy7HCSwv75YOoTPEW Es8nr8SF9GhN7u77T6IB8+ywv2nTl4e4=
Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 73B5821DE59 for ; Tue, 22 Jan 2013 00:40:50 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id u3so1962525wey.30 for ; Tue, 22 Jan 2013 00:40:49 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.80.230 with SMTP id u6mr19385648wix.20.1358844049036; Tue, 22 Jan 2013 00:40:49 -0800 (PST)
Received: by 10.216.43.8 with HTTP; Tue, 22 Jan 2013 00:40:48 -0800 (PST)
In-Reply-To: 
References: 
Date: Tue, 22 Jan 2013 02:40:48 -0600
Message-ID: 
From: Nico Williams 
To: Paul Hoffman 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] New proposal for a DNS API
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Jan 2013 08:40:51 -0000

On Mon, Jan 21, 2013 at 10:08 AM, Paul Hoffman  wrot=
e:
> Greetings again. There are a few DNS application programming interfaces (=
APIs) available that cover things like DNSSEC and non-address records, but =
none that have garnered much interest from the application developers who s=
hould be their primary audience. To remedy that, I have created a new desig=
n for such an API. I did that outside the IETF, of course, given the IETF's=
 general "we don't do APIs" stance.

Please stop spreading that very false truism.

There are several examples of IETF APIs.  For example: SCTP sockets
bindings, GSS-API (including an abstract API as well as C and Java
bindings).

And nowadays, with the spreading propensity to create HTTP-based APIs,
we could easily say that XMPP and *DAV are APIs.

So please, stop it.  All of you who have ever said that the IETF
doesn't do APIs, you're wrong.  You might say that the IETF shouldn't
do APIs, but it won't matter: it has, does and it will continue to
develop standard APIs.

Thank you,

Nico
--

From sayrer@gmail.com  Tue Jan 22 00:45:46 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B0821F8775 for ; Tue, 22 Jan 2013 00:45:46 -0800 (PST)
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 AUy-QNiPD3Qw for ; Tue, 22 Jan 2013 00:45:45 -0800 (PST)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 609A021F874B for ; Tue, 22 Jan 2013 00:45:45 -0800 (PST)
Received: by mail-wi0-f174.google.com with SMTP id hq4so7898287wib.1 for ; Tue, 22 Jan 2013 00:45:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=DWuRc0VwP66hzTrVzOtA9UpRKAeYycIxygrOiwYzsC0=; b=cqXRfuWDup3ukdv4wJwZmUbJHz3/6LSsyZHUYIMLQkfV/mSt2DlR5DTKdWI2CJfhg6 JCR8aMNGif8lkFcWzViu+z01AZgNF1aFqY5cOnW9LeClwsSHleUlCD1Q8MJNAGOyEaFe hk0qnGvORO+9xqyLa25+JhF4w7TtAS5jb1upFXApCLzchKLbvT5hSfkD38YzDlGL4BXN 8gz2sjKwJ3e3Qg4tZlLOXattr+KSUVHmlaR/jd4vkgrvuXxHukBskuNQIlhduIiFmz+S 7ZinLCiEaqivk0AauQh04BIrxcRe00GJl8lmdBWvyIYR78t1HMEdkWxkTXUKcYsw0wGV GjTg==
MIME-Version: 1.0
X-Received: by 10.194.23.37 with SMTP id j5mr30684312wjf.28.1358844344398; Tue, 22 Jan 2013 00:45:44 -0800 (PST)
Received: by 10.194.32.100 with HTTP; Tue, 22 Jan 2013 00:45:44 -0800 (PST)
In-Reply-To: 
References:  <50F903BF.1050903@it.aoyama.ac.jp> <387A8EF6-B188-47AE-A134-16983A3B8D20@tzi.org> 
Date: Tue, 22 Jan 2013 00:45:44 -0800
Message-ID: 
From: Robert Sayre 
To: Nico Williams 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Apps Discuss 
Subject: Re: [apps-discuss] The "array vs object" issue in JSON Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Jan 2013 08:45:46 -0000

On Tue, Jan 22, 2013 at 12:36 AM, Nico Williams  wro=
te:
> On Tue, Jan 22, 2013 at 1:40 AM, Carsten Bormann  wrote:
>> On Jan 18, 2013, at 09:11, Martin J. D=FCrst  wr=
ote:
>>
>>> The reason for this is that JavaScript itself also allows me
>>
>> Right outcome, wrong reasoning.
>> What is good in a programming language may or may not be good in a proto=
col.
>
> The protocol is built on a subset of *the* language from which JSON is
> derived.  (And it may well be implemented using that language in some
> cases.)
>
> That there's a protocol involved doesn't change the fundamental
> property of the language on which it is modeled: that type errors are
> run-time errors.

This is just wrong. Type errors don't occur in JavaScript in the case
at hand (you can set named properties on arrays). Furthermore, the
"leading zero" issue in the pointer syntax shows that JSON pointer
can't accurately point at things.

> Indeed, adding type hints to JSON Pointer wouldn't
> even change that property: protocol errors are also run-time errors in
> this case.
>
> Martin's point was a good one.

Not really. It seems obvious that a pointer syntax that differentiated
between objects and arrays could be simplified by an implementation.
Don't need to differentiate between object types? Don't do it.

This email is not an objection.

- Rob

From nico@cryptonector.com  Tue Jan 22 00:59:30 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B177321F85C3 for ; Tue, 22 Jan 2013 00:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.252
X-Spam-Level: 
X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[AWL=-1.275, 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 YwsHR2X4EINf for ; Tue, 22 Jan 2013 00:59:30 -0800 (PST)
Received: from homiemail-a74.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id DDA7421F856F for ; Tue, 22 Jan 2013 00:59:29 -0800 (PST)
Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id B927F67C072 for ; Tue, 22 Jan 2013 00:59:29 -0800 (PST)
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=c/agfiEmbm9KrJuesDEoGXuaFz0=; b=brvlZ8Tc7jT 7fy2cstD0c3Y1bqoygQEzjtxZMuqKRLI7SWzB8ocvwEO64AzYjTkBGkwJeO3BNet ZpVCv/P4t0YBhowFDCwNtG66yuUyJQM1y+fgSmxsrkdPSpuDw5aj+y6LOQYF3Sfk UqbtY7JXEjTOS0p/2qZnA3n1H3OIKuog=
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (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 631B767C06D for ; Tue, 22 Jan 2013 00:59:29 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id dq12so4435999wgb.24 for ; Tue, 22 Jan 2013 00:59:28 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.58.113 with SMTP id p17mr30815969wjq.27.1358845168120; Tue, 22 Jan 2013 00:59:28 -0800 (PST)
Received: by 10.216.43.8 with HTTP; Tue, 22 Jan 2013 00:59:28 -0800 (PST)
In-Reply-To: 
References:  <50F903BF.1050903@it.aoyama.ac.jp> <387A8EF6-B188-47AE-A134-16983A3B8D20@tzi.org>  
Date: Tue, 22 Jan 2013 02:59:28 -0600
Message-ID: 
From: Nico Williams 
To: Robert Sayre 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Apps Discuss 
Subject: Re: [apps-discuss] The "array vs object" issue in JSON Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Jan 2013 08:59:30 -0000

On Tue, Jan 22, 2013 at 2:45 AM, Robert Sayre  wrote:
> On Tue, Jan 22, 2013 at 12:36 AM, Nico Williams  w=
rote:
>> On Tue, Jan 22, 2013 at 1:40 AM, Carsten Bormann  wrote:
>>> On Jan 18, 2013, at 09:11, Martin J. D=C3=BCrst  wrote:
>>>
>>>> The reason for this is that JavaScript itself also allows me
>>>
>>> Right outcome, wrong reasoning.
>>> What is good in a programming language may or may not be good in a prot=
ocol.
>>
>> The protocol is built on a subset of *the* language from which JSON is
>> derived.  (And it may well be implemented using that language in some
>> cases.)
>>
>> That there's a protocol involved doesn't change the fundamental
>> property of the language on which it is modeled: that type errors are
>> run-time errors.
>
> This is just wrong. Type errors don't occur in JavaScript in the case
> at hand (you can set named properties on arrays). Furthermore, the
> "leading zero" issue in the pointer syntax shows that JSON pointer
> can't accurately point at things.

You're right, I was thinking more of Python since I use that much more
often than JS (but I should change that).  This error of mine doesn't
change my view though.  It's harmless to not have type information in
Pointer (it might not be useless, but it is harmless).

Nico
--

From julian.reschke@gmx.de  Tue Jan 22 01:51:31 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195A721F87E0 for ; Tue, 22 Jan 2013 01:51:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 IuqrM3I4y5in for ; Tue, 22 Jan 2013 01:51:30 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE9921F85BC for ; Tue, 22 Jan 2013 01:51:30 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.32]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M7nFW-1T2Tir0Jto-00vNij for ; Tue, 22 Jan 2013 10:51:29 +0100
Received: (qmail invoked by alias); 22 Jan 2013 09:51:28 -0000
Received: from p5DD94CD8.dip.t-dialin.net (EHLO [192.168.1.100]) [93.217.76.216] by mail.gmx.net (mp032) with SMTP; 22 Jan 2013 10:51:28 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/SfnNKf1PSJlqBEJVHylBQlo3LJyNspP4AVfG6Zh 19MzWmYKowDdrw
Message-ID: <50FE6120.8020400@gmx.de>
Date: Tue, 22 Jan 2013 10:51:28 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Conal Tuohy 
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net>  <50FDC6A4.8040700@versi.edu.au>
In-Reply-To: <50FDC6A4.8040700@versi.edu.au>
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 Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Jan 2013 09:51:31 -0000

On 2013-01-21 23:52, Conal Tuohy wrote:
> Hi Barry
>
> It seemed to me, on the contrary, that there was a broad consensus at
> least that the +json should be used. I think it would be a shame if the
> differences of opinion about the name *as a whole* were an obstacle to
> accepting the suffix, because the usefulness of the suffix is generally
> accepted, and it applies regardless of what the rest of the name is.
> Given that, I'd suggest that it would make sense to append the suffix be
> appended to the current name. Is there any reason not to do that?
>
> Con
> ...

Indeed.


From markus.lanthaler@gmx.net  Tue Jan 22 02:43:11 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E008821F88FD for ; Tue, 22 Jan 2013 02:43:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level: 
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrc6e2ZDFpTD for ; Tue, 22 Jan 2013 02:43:11 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3231621F88ED for ; Tue, 22 Jan 2013 02:43:11 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0ME0gb-1TgnWT1C0N-00HOdl for ; Tue, 22 Jan 2013 11:43:10 +0100
Received: (qmail invoked by alias); 22 Jan 2013 10:43:10 -0000
Received: from 84-115-182-43.dynamic.vdsl.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp024) with SMTP; 22 Jan 2013 11:43:10 +0100
X-Authenticated: #419883
X-Provags-ID: V01U2FsdGVkX19mqhxZtexmGlg/56LJNhQHEkzloSXNaRPxtGEYzG j5JIwamLxGaDJT
From: "Markus Lanthaler" 
To: 
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net>		<50FDC6A4.8040700@versi.edu.au> <50FE6120.8020400@gmx.de>
In-Reply-To: <50FE6120.8020400@gmx.de>
Date: Tue, 22 Jan 2013 11:43:06 +0100
Message-ID: <013101cdf88d$4432f5c0$cc98e140$@lanthaler@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac34hg/rNfdrLTxjSwuyDPKwNLyYqQAByFEQ
Content-Language: de
X-Y-GMX-Trusted: 0
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Jan 2013 10:43:12 -0000

On 2013-01-21 23:52, Conal Tuohy wrote:
> Hi Barry
>
> It seemed to me, on the contrary, that there was a broad consensus at
> least that the +json should be used. I think it would be a shame if the
> differences of opinion about the name *as a whole* were an obstacle to
> accepting the suffix, because the usefulness of the suffix is generally
> accepted, and it applies regardless of what the rest of the name is.
> Given that, I'd suggest that it would make sense to append the suffix be
> appended to the current name. Is there any reason not to do that?

+1



--
Markus Lanthaler
@markuslanthaler


From hallam@gmail.com  Tue Jan 22 05:14:59 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E6921F8863 for ; Tue, 22 Jan 2013 05:14:59 -0800 (PST)
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 4o+xNB0QqPg0 for ; Tue, 22 Jan 2013 05:14:58 -0800 (PST)
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id C08C321F8814 for ; Tue, 22 Jan 2013 05:14:57 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id hj13so5890688wib.7 for ; Tue, 22 Jan 2013 05:14:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mMjokvU+26voQeRk5illV32FNHJbHlvG/9KYgAfJW8M=; b=ddemINJIPDoyUWuhYItCTcPNPOO7dxc4u15YI2f6ElDfekjycdZntYpAzhbpm31L7E yHjwDJtZa1ecX0G/x1e91/hahAANVCll2GO8VrATzR5CeMikWvf+8nuqf4QWK/acZyQK cWQXydXHNtrm21vLK8LKV8YkOH6VZjxU6VD5e6IJhfkQJ0G7bBWfLbWHeYCLGHUvccGj /9YJiu0gT7MQglhrbZgRTnqL4byHPMh8dXltNcKl3zSiJQKPfA+mMgkJOv99lSPhW6bi PCkMoQgy4WoPqfu/nyay8NgNdk4eyRkOEsplMktntB3kooQsbVrfj/ZU93u09rvaCJR4 wftg==
MIME-Version: 1.0
X-Received: by 10.194.88.98 with SMTP id bf2mr32414558wjb.49.1358860496861; Tue, 22 Jan 2013 05:14:56 -0800 (PST)
Received: by 10.194.59.10 with HTTP; Tue, 22 Jan 2013 05:14:56 -0800 (PST)
In-Reply-To: 
References:  
Date: Tue, 22 Jan 2013 08:14:56 -0500
Message-ID: 
From: Phillip Hallam-Baker 
To: Nico Williams 
Content-Type: multipart/alternative; boundary=089e010d825a36f99704d3e05d54
Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] New proposal for a DNS API
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Jan 2013 13:14:59 -0000

--089e010d825a36f99704d3e05d54
Content-Type: text/plain; charset=ISO-8859-1

Doing an API for a protocol like DNS is going to be very hard as DNS is an
inherently asynchronous request protocol. The typical advanced interaction
involves sending out requests in parallel.

While that is pretty straightforward in itself, the patterns for
implementing that type of scheme look very different in different
programming frameworks. The API I would use for .NET is very different from
the API I would use for Java.The differences between the systems are not
that big but they do handle asynchronous patterns very differently.


What we need is an abstract application discovery API, no because we
necessarily expect this to be implemented in code but because we need to
clarify and regularize the interface between the Internet resource
discovery infrastructures and the application layer.

The DNS is only one infrastructure that applications need to take
information from.


On Tue, Jan 22, 2013 at 3:40 AM, Nico Williams wrote:

> On Mon, Jan 21, 2013 at 10:08 AM, Paul Hoffman 
> wrote:
> > Greetings again. There are a few DNS application programming interfaces
> (APIs) available that cover things like DNSSEC and non-address records, but
> none that have garnered much interest from the application developers who
> should be their primary audience. To remedy that, I have created a new
> design for such an API. I did that outside the IETF, of course, given the
> IETF's general "we don't do APIs" stance.
>
> Please stop spreading that very false truism.
>
> There are several examples of IETF APIs.  For example: SCTP sockets
> bindings, GSS-API (including an abstract API as well as C and Java
> bindings).
>
> And nowadays, with the spreading propensity to create HTTP-based APIs,
> we could easily say that XMPP and *DAV are APIs.
>
> So please, stop it.  All of you who have ever said that the IETF
> doesn't do APIs, you're wrong.  You might say that the IETF shouldn't
> do APIs, but it won't matter: it has, does and it will continue to
> develop standard APIs.
>
> Thank you,
>
> Nico
> --
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>



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

--089e010d825a36f99704d3e05d54
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Doing an API for a protocol like DNS is going to be very hard as DNS is an =
inherently asynchronous request protocol. The typical advanced interaction =
involves sending out requests in parallel.

While that is pretty stra=
ightforward in itself, the patterns for implementing that type of scheme lo=
ok very different in different programming frameworks. The API I would use =
for .NET is very different from the API I would use for Java.The difference=
s between the systems are not that big but they do handle asynchronous patt=
erns very differently.



What we need is an abstract application disco=
very API, no because we necessarily expect this to be implemented in code b=
ut because we need to clarify and regularize the interface between the Inte=
rnet resource discovery infrastructures and the application layer.



The DNS is only one infrastructure that applications ne=
ed to take information from.=A0


On Tu=
e, Jan 22, 2013 at 3:40 AM, Nico Williams <nico@cryptonector.com&g=
t; wrote:


On Mon, Jan 21, 2013 at 10=
:08 AM, Paul Hoffman <paul.hoff=
man@vpnc.org> wrote:


> Greetings again. There are a few DNS application programming interface=
s (APIs) available that cover things like DNSSEC and non-address records, b=
ut none that have garnered much interest from the application developers wh=
o should be their primary audience. To remedy that, I have created a new de=
sign for such an API. I did that outside the IETF, of course, given the IET=
F's general "we don't do APIs" stance.





Please stop spreading that very false truism.



There are several examples of IETF APIs. =A0For example: SCTP sockets

bindings, GSS-API (including an abstract API as well as C and Java

bindings).



And nowadays, with the spreading propensity to create HTTP-based APIs,

we could easily say that XMPP and *DAV are APIs.



So please, stop it. =A0All of you who have ever said that the IETF

doesn't do APIs, you're wrong. =A0You might say that the IETF shoul=
dn't

do APIs, but it won't matter: it has, does and it will continue to

develop standard APIs.



Thank you,



Nico

--


___________________________________=
____________

apps-discuss mailing list

apps-discuss@ietf.org

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





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



--089e010d825a36f99704d3e05d54--

From nickshanks@gmail.com  Tue Jan 22 07:19:32 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149B221F8A11 for ; Tue, 22 Jan 2013 07:19:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.477
X-Spam-Level: 
X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=-3.500, 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 g6PWEhAGlQUE for ; Tue, 22 Jan 2013 07:19:31 -0800 (PST)
Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 287A921F8A0D for ; Tue, 22 Jan 2013 07:19:30 -0800 (PST)
Received: by mail-lb0-f175.google.com with SMTP id n3so4943382lbo.6 for ; Tue, 22 Jan 2013 07:19:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=I8OTX8ad1FZMm4ZrF2nhSvio0qXkdeeUWwdXnahCIDs=; b=cyjmWBFD/W0UzELz/Iksc0XM0jZihhysxBgfqXaOL86lYYJKH/sMwJN4q6L5GBdFoW 4B/jlPc7mu6fSql7LY7+n7bAa7YP77P7Qi8TazQcgZyAuf0Zl3iTWlfY5FdZXYdJbmkH bxqL8w3wmYu2hDNwZYg689nPqE9XqGrv8lkmZYIIMupqoH4n24ke0jKHt2o+fPd317ZO 4tDM2vWB8t+0iOEVsQf66BbhNnExBbMYHHIr7/IyxRYImRaSckDrrNBT701eCqNAOHFL 7cQeAkEifs5wCgjIqXQb+8Ri5lK0xbZeFjaV1C9S52AagTwFS2kI96TfSuShz4vyYLqW z/BQ==
X-Received: by 10.112.100.41 with SMTP id ev9mr913352lbb.34.1358867970063; Tue, 22 Jan 2013 07:19:30 -0800 (PST)
MIME-Version: 1.0
Sender: nickshanks@gmail.com
Received: by 10.114.18.40 with HTTP; Tue, 22 Jan 2013 07:18:49 -0800 (PST)
In-Reply-To: <50F6697A.8030608@berkeley.edu>
References: <1CD55F04538DEA4F85F3ADF7745464AF2495A4A7@S-BSC-MBX1.nrn.nrcan.gc.ca>  <50F42C62.1080002@berkeley.edu> <01OOZ8YX62N000008S@mauve.mrochek.com> <50F512CA.6040003@berkeley.edu>  <50F6697A.8030608@berkeley.edu>
From: Nicholas Shanks 
Date: Tue, 22 Jan 2013 15:18:49 +0000
X-Google-Sender-Auth: iBrkbGjUXIV0E95fhUJdgZF95UU
Message-ID: 
To: "apps-discuss@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Cc: ietf-http-wg@w3.org
Subject: Re: [apps-discuss] New Version Notification for draft-wilde-xml-patch-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, 22 Jan 2013 15:19:32 -0000

[Cross-posting to HTTP WG since my brain dump affects them too]

On 16 January 2013 08:48, Erik Wilde  wrote:
> On 2013-01-15 18:58 , Bjoern Hoehrmann wrote:
>> If someone made a format that expresses differences between "RDF files"
>> or some sort, and that format is based on JSON, the argument would most
>> likely be to use +json for the corresponding media type.
>
> my point was more that an RDF patch format more likely would patch the RDF
> model, and not a specific RDF syntax. thus, it might use "rdf-patch" as the
> starting point, but then the patch format itself probably would be defined
> as RDF, and thus could be serialized in different ways, so that we might
> have rdf-patch+rdfxml and rdf-patch+turtle, if there were specific suffixes
> for different RDF serializations. this is all hypothetical right now as
> there aren't any RDF suffixes, but i was wondering whether this would be the
> direction all of this would move towards.

The best solution to this mess, in my opinion, would be to adopt
Universal Type Identifiers[1] as a replacement for MIME types across
the internet. During a transitional period, both will have to be
present, but I'm hopping that shouldn't be too much of a burden (see
below for why not). Eventually Apple ought to transfer control of the
public.* registry to the IETF too, but that's a bridge that can be
crossed at a later date.

In short, the benefits of UTIs over MIME types are that you get
multiple inheritance and don't have to stuff all of the inheritance
hierarchy into one label.
RDF Patch inherits from RDF, RDF inherits from XML in one
serialization, and XML inherits from Plain Text. In MIME parlance that
ought to be text/rdf-patch+rdf+xml, and that syntax only allows a
single inheritance chain. Multiple inheritance can be useful in
selecting alternative software to edit a resource.
The draw-backs to using UTIs are that clients have to be smarter: they
have to have advance knowledge of the public.* hierarchy and the
inheritance paths of any custom types which they can handle.

Since forward slashes are prohibited in UTIs, a MIME type and a UTI
can be crudely distinguished by the presence or absence of this
character. It may be possible therefore to permit multiple values for
the Content-Type header such as "text/html, public.html" without
confusing clients and intermediaries. I'd prefer that to inventing a
new HTTP header, since the semantics being conveyed are identical.

Before any of this can become a possibility though, the HTTPbis WG
should specify in p2 section 3.1.1.5, that all clients must split the
Content-Type header into constituent values per the rules for doing
so, then ignore but retain any header values which it does not
understand (with their attendant parameters, if any). Clients can then
use their own heuristic in determining what type to process a resource
as. This could even allow headers such as "Content-Type:
application/rdf-patch, application/rdf, application/xml, text/plain"
as a way of providing a type hierarchy to clients. It makes sense to
list more precise types first, but ordering should not matter to
clients that are multi-value aware. Very dumb clients can just chop at
the first comma, leaving us with what we have presently.

[1] read some of the results from
https://www.google.com/search?q=apple+uti for more info

-- 
Nicholas.

From paul.hoffman@vpnc.org  Tue Jan 22 07:44:36 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0608221F8A56 for ; Tue, 22 Jan 2013 07:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 uloAzFyxEYYx for ; Tue, 22 Jan 2013 07:44:35 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC3C21F8A50 for ; Tue, 22 Jan 2013 07:44:35 -0800 (PST)
Received: from [10.20.30.101] (50-1-51-83.dsl.dynamic.fusionbroadband.com [50.1.51.83]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r0MFiWDB081304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Jan 2013 08:44:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Paul Hoffman 
In-Reply-To: 
Date: Tue, 22 Jan 2013 07:44:33 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  
To: Nico Williams 
X-Mailer: Apple Mail (2.1499)
Cc: "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] New proposal for a DNS API
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Jan 2013 15:44:36 -0000

On Jan 22, 2013, at 12:40 AM, Nico Williams  =
wrote:

> On Mon, Jan 21, 2013 at 10:08 AM, Paul Hoffman  =
wrote:
>> Greetings again. There are a few DNS application programming =
interfaces (APIs) available that cover things like DNSSEC and =
non-address records, but none that have garnered much interest from the =
application developers who should be their primary audience. To remedy =
that, I have created a new design for such an API. I did that outside =
the IETF, of course, given the IETF's general "we don't do APIs" stance.
>=20
> Please stop spreading that very false truism.

It is not a "false truism". I worded the sentence very carefully. The =
IETF has a *general* stance that "we don't do APIs". You correctly =
listed two real APIs, and some other things that can be considered APIs =
if you squint a bit. However, in the earlier discussions of doing an =
APIs for DNS, the resounding chorus was "we don't do APIs". The fact =
that the IETF does a few didn't matter to those saying it.

--Paul Hoffman=

From hallam@gmail.com  Tue Jan 22 07:52:26 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CFA21F85D7 for ; Tue, 22 Jan 2013 07:52:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.499,  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 UuRc+7+zFVlb for ; Tue, 22 Jan 2013 07:52:25 -0800 (PST)
Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 13CE921F8415 for ; Tue, 22 Jan 2013 07:52:22 -0800 (PST)
Received: by mail-wg0-f54.google.com with SMTP id fg15so4697792wgb.9 for ; Tue, 22 Jan 2013 07:52:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=P5yRidV1kU4ssTJ/8JFXfFJFmC4kACH4Xh76oNVonjk=; b=QuXCyIcv0EwwxqyRvr5xpEpwo9PLMJV4PYxoC0rWQUyrjaa72OxsdrqGppnkn+mL1R Vjil/CrdTanO2kcwPOtjanonZgZjSCGYnkZtQFGJOf/313RCeB+vI6h+pwRFFZRo/8TH 8We9nB8QP87j5Ak4duJdM4rj5ZeKtQE53yI6a94xB1e0k7gZMOE4KlAJlp0l7c6fWtU+ Hb2n77hbQgdLIE6B0pKvwrKKO+qfxc+WLqlhNzFbA3EmjtfU6cXioruJP5uLUKWt3uBi +Q86poed2sGtZeSJvrdCX275YC109K68ehWSY8E+70hOwS85rcBP1QEQbVpdKehaZ4f7 jy6Q==
MIME-Version: 1.0
X-Received: by 10.194.235.100 with SMTP id ul4mr33491357wjc.7.1358869940471; Tue, 22 Jan 2013 07:52:20 -0800 (PST)
Received: by 10.194.59.10 with HTTP; Tue, 22 Jan 2013 07:52:20 -0800 (PST)
In-Reply-To: 
References:  <50F903BF.1050903@it.aoyama.ac.jp> <387A8EF6-B188-47AE-A134-16983A3B8D20@tzi.org>  
Date: Tue, 22 Jan 2013 10:52:20 -0500
Message-ID: 
From: Phillip Hallam-Baker 
To: Robert Sayre 
Content-Type: multipart/alternative; boundary=089e0149418819063904d3e290bb
Cc: Apps Discuss 
Subject: Re: [apps-discuss] The "array vs object" issue in JSON Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Jan 2013 15:52:26 -0000

--089e0149418819063904d3e290bb
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 22, 2013 at 3:45 AM, Robert Sayre  wrote:

> On Tue, Jan 22, 2013 at 12:36 AM, Nico Williams 
> wrote:
> > On Tue, Jan 22, 2013 at 1:40 AM, Carsten Bormann  wrote:
> >> On Jan 18, 2013, at 09:11, Martin J. D=FCrst 
> wrote:
> >>
> >>> The reason for this is that JavaScript itself also allows me
> >>
> >> Right outcome, wrong reasoning.
> >> What is good in a programming language may or may not be good in a
> protocol.
> >
> > The protocol is built on a subset of *the* language from which JSON is
> > derived.  (And it may well be implemented using that language in some
> > cases.)
> >
> > That there's a protocol involved doesn't change the fundamental
> > property of the language on which it is modeled: that type errors are
> > run-time errors.
>
> This is just wrong. Type errors don't occur in JavaScript in the case
> at hand (you can set named properties on arrays). Furthermore, the
> "leading zero" issue in the pointer syntax shows that JSON pointer
> can't accurately point at things.
>
> > Indeed, adding type hints to JSON Pointer wouldn't
> > even change that property: protocol errors are also run-time errors in
> > this case.
> >
> > Martin's point was a good one.
>
> Not really. It seems obvious that a pointer syntax that differentiated
> between objects and arrays could be simplified by an implementation.
> Don't need to differentiate between object types? Don't do it.
>

I think the example that makes this very clear is C++ vs C#.

C# is pretty much the most technically rigorous modern language in general
use out there right now. It has more ways to enforce static type checking
than anything else that I know of that can actually be used to write real
programs.

In C+ you ended up with this type of syntax:

instance::pointer->structure.member.submember->referent

In C# you have just:

instance.pointer.structure.member.submember.referent

The compiler knows which is which and there is no possibility of ambiguity
arising. So why have the programmer tell the compiler what it should
already know?

The C# approach is vastly more convenient to use and allows programs to be
refactored easily without affecting the code that calls them.


Note my use of the past tense with respect to C++. I have never used it and
never intend to. In my view C is a vast improvement on C++. The only C++
feature I see as an advantage is the addition of single line comments. The
only case where I would use C++ is as one option for the target language of
a code generator.

Static type checking is good when it distinguishes between cases where a
programmer might otherwise make an error. I don't like using languages like
python or JavaScript because I prefer having integer arithmetic clearly
separated from real and have the compiler warn me if something odd is about
to happen.

But this isn't making that type of check. It is makework type checking of
the type that make Pascal a completely wirthless enterprise (or rather it
would have been better if it had been wirthless).


This email is not an objection.


Ditto



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

--089e0149418819063904d3e290bb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Tue, Jan 22, 2013 at 3:45 AM, Robert =
Sayre <sayrer@gmail.com> wrote:


On Tue, Jan 22, 2013 at 12:36 AM, Nico Williams <nico@cryptonector.com> wrote:
> On Tue, Jan 22, 2013 at 1:40 AM, Carsten Bormann <cabo@tzi.org> wrote:

>> On Jan 18, 2013, at 09:11, Martin J. D=FCrst <duerst@it.aoyama.ac.jp> wrote:

>>

>>> The reason for this is that JavaScript itself also allows me
>>

>> Right outcome, wrong reasoning.

>> What is good in a programming language may or may not be good in a=
 protocol.

>

> The protocol is built on a subset of *the* language from which JSON is=


> derived. =A0(And it may well be implemented using that language in som=
e

> cases.)

>

> That there's a protocol involved doesn't change the fundamenta=
l

> property of the language on which it is modeled: that type errors are<=
br>
> run-time errors.




This is just wrong. Type errors don't occur in JavaScript in the =
case

at hand (you can set named properties on arrays). Furthermore, the

"leading zero" issue in the pointer syntax shows that JSON pointe=
r

can't accurately point at things.




> Indeed, adding type hints to JSON Pointer wouldn't

> even change that property: protocol errors are also run-time errors in=


> this case.

>

> Martin's point was a good one.




Not really. It seems obvious that a pointer syntax that differentiate=
d

between objects and arrays could be simplified by an implementation.

Don't need to differentiate between object types? Don't do it.
<=
/blockquote>

I think the example that makes this very cl=
ear is C++ vs C#.

C# is pretty much the most techn=
ically rigorous modern language in general use out there right now. It has =
more ways to enforce static type checking than anything else that I know of=
 that can actually be used to write real programs.



In C+ you ended up with this type of syntax:
=

instance::pointer->structure.member.submember->referen=
t

In C# you have just:


instance.pointer.structure.member.submember.referent

The compiler knows which is which and there is no possibility of ambigui=
ty arising. So why have the programmer tell the compiler what it should alr=
eady know?



The C# approach is vastly more convenient to use and al=
lows programs to be refactored easily without affecting the code that calls=
 them.

=A0
Note my use of the past tense=
 with respect to C++. I have never used it and never intend to. In my view =
C is a vast improvement on C++. The only C++ feature I see as an advantage =
is the addition of single line comments. The only case where I would use C+=
+ is as one option for the target language of a code generator.



Static type checking is good when it distinguishes betw=
een cases where a programmer might otherwise make an error. I don't lik=
e using languages like python or JavaScript because I prefer having integer=
 arithmetic clearly separated from real and have the compiler warn me if so=
mething odd is about to happen.



But this isn't making that type of check. It is mak=
ework type checking of the type that make Pascal a completely wirthless ent=
erprise (or rather it would have been better if it had been wirthless).




This email is not an objection.

Ditto=A0



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


--089e0149418819063904d3e290bb--

From hallam@gmail.com  Tue Jan 22 07:57:28 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15C121F86EF for ; Tue, 22 Jan 2013 07:57:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 cfZufOX87XR6 for ; Tue, 22 Jan 2013 07:57:27 -0800 (PST)
Received: from mail-we0-x229.google.com (we-in-x0229.1e100.net [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0F07C21F86AE for ; Tue, 22 Jan 2013 07:57:22 -0800 (PST)
Received: by mail-we0-f169.google.com with SMTP id t11so1912525wey.0 for ; Tue, 22 Jan 2013 07:57:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZRTje+98xt3FZFVOyBE9lzIr18sc7FmeAdhaHZgc5jc=; b=i/nvT5Lx3MIXqytmYaZh59i2N1U1AmgHh/wU6QgWHJEKhX3O0NguevUTrOc/mmkdTr eYpX+RZYoV92/fPQOl95lmleenNaElO19N6dHi0AUvoxo4A+9O9kXrkS+LdDGNEzEUQd LPdebb1FdeLp2cGh+RbqIqMaFLil/iVBrI63XDRNo7iLrMyDRcFqE//h5GD663vHGqii dp7HZB+3uJZNh4a6pvEc6eK2o7y8ukradTv0Ros0lug9vH0nFshZLCp+JOpAhojfHfnp 5i/tyM5+hMBVjUE6ufU0lO2OVwOtSBUOFh0Rwk5dVO6aExLE6SmXFQobJFLbIR8r+Npr na+w==
MIME-Version: 1.0
X-Received: by 10.194.90.116 with SMTP id bv20mr33236284wjb.33.1358870242095;  Tue, 22 Jan 2013 07:57:22 -0800 (PST)
Received: by 10.194.59.10 with HTTP; Tue, 22 Jan 2013 07:57:21 -0800 (PST)
In-Reply-To: 
References:   
Date: Tue, 22 Jan 2013 10:57:21 -0500
Message-ID: 
From: Phillip Hallam-Baker 
To: Paul Hoffman 
Content-Type: multipart/alternative; boundary=047d7bfd031c13709304d3e2a24d
Cc: "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] New proposal for a DNS API
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Jan 2013 15:57:28 -0000

--047d7bfd031c13709304d3e2a24d
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 22, 2013 at 10:44 AM, Paul Hoffman wrote:

>
> On Jan 22, 2013, at 12:40 AM, Nico Williams  wrote:
>
> > On Mon, Jan 21, 2013 at 10:08 AM, Paul Hoffman 
> wrote:
> >> Greetings again. There are a few DNS application programming interfaces
> (APIs) available that cover things like DNSSEC and non-address records, but
> none that have garnered much interest from the application developers who
> should be their primary audience. To remedy that, I have created a new
> design for such an API. I did that outside the IETF, of course, given the
> IETF's general "we don't do APIs" stance.
> >
> > Please stop spreading that very false truism.
>
> It is not a "false truism". I worded the sentence very carefully. The IETF
> has a *general* stance that "we don't do APIs". You correctly listed two
> real APIs, and some other things that can be considered APIs if you squint
> a bit. However, in the earlier discussions of doing an APIs for DNS, the
> resounding chorus was "we don't do APIs". The fact that the IETF does a few
> didn't matter to those saying it.


The IETF 'doesn't do schemas' either, except for MIBs.

I think that we need to think about the way that the DNS infrastructure
interfaces with the application layer and the types of information that
should flow between the two. At the moment the interface is in practice
limited to 'gethostbyname' on many platforms which is ridiculous.


One tool that might help here is a piece of code I am working on called
Domainer which is a generator for DNS Resource Record parsers.

At the moment the only language I am targeting is C# but the synthesizer
could generate code in any language, ones that would make best sense are
probably C and HTML.

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

--047d7bfd031c13709304d3e2a24d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 22, 2013 at 10:44 AM, Paul Hoffman <paul.hoffman@vpnc.org<=
/a>> wrote:




On Jan 22, 2013, at 12:40 AM, Nico Williams <nico@cryptonector.com> wrote:



> On Mon, Jan 21, 2013 at 10:08 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

>> Greetings again. There are a few DNS application programming inter=
faces (APIs) available that cover things like DNSSEC and non-address record=
s, but none that have garnered much interest from the application developer=
s who should be their primary audience. To remedy that, I have created a ne=
w design for such an API. I did that outside the IETF, of course, given the=
 IETF's general "we don't do APIs" stance.


>

> Please stop spreading that very false truism.




It is not a "false truism". I worded the sentence very care=
fully. The IETF has a *general* stance that "we don't do APIs"=
;. You correctly listed two real APIs, and some other things that can be co=
nsidered APIs if you squint a bit. However, in the earlier discussions of d=
oing an APIs for DNS, the resounding chorus was "we don't do APIs&=
quot;. The fact that the IETF does a few didn't matter to those saying =
it.



The IETF 'doesn't do schemas' either, excep=
t for MIBs.=A0

I think that we need to think about the way t=
hat the DNS infrastructure interfaces with the application layer and the ty=
pes of information that should flow between the two. At the moment the inte=
rface is in practice limited to 'gethostbyname' on many platforms w=
hich is ridiculous.



One tool that might help here is a piece of c=
ode I am working on called Domainer which is a generator for DNS Resource R=
ecord parsers.

At the moment the only language I a=
m targeting is C# but the synthesizer could generate code in any language, =
ones that would make best sense are probably C and HTML.



-- 
Website: http://h=
allambaker.com/




--047d7bfd031c13709304d3e2a24d--

From barryleiba.mailing.lists@gmail.com  Tue Jan 22 10:36:36 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2308921F899F for ; Tue, 22 Jan 2013 10:36:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.693
X-Spam-Level: 
X-Spam-Status: No, score=-102.693 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 5Bxl4Ld6-kNF for ; Tue, 22 Jan 2013 10:36:35 -0800 (PST)
Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9B20A21F89AE for ; Tue, 22 Jan 2013 10:36:35 -0800 (PST)
Received: by mail-ve0-f176.google.com with SMTP id jz10so654801veb.7 for ; Tue, 22 Jan 2013 10:36:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=koTW5R3DxyYo5/+xYUOoLxhp/KcDk+7s2f9E8opEyDQ=; b=tO7L9z98C/MdTxdAbEm7lrIfZk+mHZRu1OeiznjDmfX+Am3jim7gZTZNmn+stCrN2l vKKdluDE2VBUGOyx8Tv3OJY2qcy3BsBD7xTeLh1DHt5MYQEQ2uCnQbGFssKMwvLm02ul twbkeXS4yWOddEZSwM0t3vWZT3hUXH/H75R83mfLOkU38/HhAuqOvkdByGr6WUZCQVKe 7wu/XSY7dqB67pZMCAtiW11xFweiefKoZ/QGW5DXv2gK6Suqac9SOy85CkkndvRCd3aN Kq/UkEAqjhsoW6yXlpd6IC9R6pkjmMETfI+kbGRrmoY+uHF6R4MpnwWKU/jJSbTH7GFw OeJA==
MIME-Version: 1.0
X-Received: by 10.52.72.232 with SMTP id g8mr21531940vdv.69.1358879794740; Tue, 22 Jan 2013 10:36:34 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Tue, 22 Jan 2013 10:36:34 -0800 (PST)
In-Reply-To: <50FDC6A4.8040700@versi.edu.au>
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net>  <50FDC6A4.8040700@versi.edu.au>
Date: Tue, 22 Jan 2013 13:36:34 -0500
X-Google-Sender-Auth: aPuzmbbHJUfvKUPPYIj7-qMihZ8
Message-ID: 
From: Barry Leiba 
To: Conal Tuohy 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Jan 2013 18:36:36 -0000

> It seemed to me, on the contrary, that there was a broad consensus at least
> that the +json should be used. I think it would be a shame if the
> differences of opinion about the name *as a whole* were an obstacle to
> accepting the suffix, because the usefulness of the suffix is generally
> accepted, and it applies regardless of what the rest of the name is. Given
> that, I'd suggest that it would make sense to append the suffix be appended
> to the current name. Is there any reason not to do that?

Given the agreement posted so far to this, it sounds like that's an
acceptable way to go.  Let me ask, then, for any objections to this
path, which will make the media type name
"application/json-patch+json".  If you *object* to that change, post
here very soon.  I will put it in as an editor note now.

Barry

From Jeff.Hodges@KingsMountain.com  Tue Jan 22 13:38:56 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6EA21F88EE for ; Tue, 22 Jan 2013 13:38:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.349
X-Spam-Level: 
X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 1Uc0knebcCrb for ; Tue, 22 Jan 2013 13:38:44 -0800 (PST)
Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 38D0821F854E for ; Tue, 22 Jan 2013 13:38:44 -0800 (PST)
Received: (qmail 21460 invoked by uid 0); 22 Jan 2013 21:38:22 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 22 Jan 2013 21:38:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=bXYQYAUl85CLIDTEGI5w0JXfgsjXGlL38dzkx6Mx0ks=;  b=Vc2wqFd9NoiO5lK/r8laPByequdVd3xD/LstqnTmJtPE0TpFjWSX/j6G8EZnbWTnXXyvp6w3tISfSR+eKVN4SrTovEJ/V9b1B1QTmTKPI8d5WPvk1g5iV91zaN3B+v0P;
Received: from [216.113.168.128] (port=53674 helo=[10.244.137.234]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1TxlXx-0007dD-MJ; Tue, 22 Jan 2013 14:38:21 -0700
Message-ID: <50FF06CD.2050002@KingsMountain.com>
Date: Tue, 22 Jan 2013 13:38:21 -0800
From: =JeffH 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Eliot Lear 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Cc: draft-laurie-pki-sunlight-05.all@tools.ietf.org, therightkey@ietf.org, The IESG , Apps Discuss 
Subject: Re: [apps-discuss] "mis-issued" was: apps area review of draft-laurie-pki-sunlight-05 (Eliot's version)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Jan 2013 21:38:56 -0000

 > "Misissued" is not a word.

but "mis-issued" is a legit contraction, so perhaps it's simply misspelled (and 
a definition should probably be provided).

"mis-issue" and "mis-issued" refer to the situation where a CA issues a cert for 
a given subject (i.e. domain name) when they should not have. C.f. Diginotar.

See also: https://tools.ietf.org/html/draft-ietf-pkix-caa-15

HTH,

=JeffH

From James.H.Manger@team.telstra.com  Tue Jan 22 16:18:13 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A53E21F8862 for ; Tue, 22 Jan 2013 16:18:13 -0800 (PST)
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 CUX-NNcOhKRd for ; Tue, 22 Jan 2013 16:18:12 -0800 (PST)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id E999D21F86D8 for ; Tue, 22 Jan 2013 16:18:10 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.84,518,1355058000"; d="scan'208";a="114076056"
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 23 Jan 2013 11:18:07 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6963"; a="107408884"
Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcbvi.tcif.telstra.com.au with ESMTP; 23 Jan 2013 11:18:07 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Wed, 23 Jan 2013 11:18:07 +1100
From: "Manger, James H" 
To: Barry Leiba 
Date: Wed, 23 Jan 2013 11:18:05 +1100
Thread-Topic: [apps-discuss] JSON Patch name
Thread-Index: Ac34z2zNy3ZM05N1SDKsmodIy9bE8wALrksw
Message-ID: <255B9BB34FB7D647A506DC292726F6E11504F4D6D3@WSMSG3153V.srv.dir.telstra.com>
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net>  <50FDC6A4.8040700@versi.edu.au> 
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 name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Jan 2013 00:18:13 -0000

PiAtLS0tLS0tLS0tDQo+IEZyb206IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWls
dG86YXBwcy1kaXNjdXNzLQ0KPiBib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmFycnkg
TGVpYmENCj4gU2VudDogV2VkbmVzZGF5LCAyMyBKYW51YXJ5IDIwMTMgNTozNyBBTQ0KPiANCj4g
PiBJdCBzZWVtZWQgdG8gbWUsIG9uIHRoZSBjb250cmFyeSwgdGhhdCB0aGVyZSB3YXMgYSBicm9h
ZCBjb25zZW5zdXMgYXQNCj4gPiBsZWFzdCB0aGF0IHRoZSAranNvbiBzaG91bGQgYmUgdXNlZC4g
SSB0aGluayBpdCB3b3VsZCBiZSBhIHNoYW1lIGlmDQo+ID4gdGhlIGRpZmZlcmVuY2VzIG9mIG9w
aW5pb24gYWJvdXQgdGhlIG5hbWUgKmFzIGEgd2hvbGUqIHdlcmUgYW4NCj4gPiBvYnN0YWNsZSB0
byBhY2NlcHRpbmcgdGhlIHN1ZmZpeCwgYmVjYXVzZSB0aGUgdXNlZnVsbmVzcyBvZiB0aGUNCj4g
c3VmZml4DQo+ID4gaXMgZ2VuZXJhbGx5IGFjY2VwdGVkLCBhbmQgaXQgYXBwbGllcyByZWdhcmRs
ZXNzIG9mIHdoYXQgdGhlIHJlc3Qgb2YNCj4gPiB0aGUgbmFtZSBpcy4gR2l2ZW4gdGhhdCwgSSdk
IHN1Z2dlc3QgdGhhdCBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvDQo+ID4gYXBwZW5kIHRoZSBzdWZm
aXggYmUgYXBwZW5kZWQgdG8gdGhlIGN1cnJlbnQgbmFtZS4gSXMgdGhlcmUgYW55DQo+IHJlYXNv
biBub3QgdG8gZG8gdGhhdD8NCj4gDQo+IEdpdmVuIHRoZSBhZ3JlZW1lbnQgcG9zdGVkIHNvIGZh
ciB0byB0aGlzLCBpdCBzb3VuZHMgbGlrZSB0aGF0J3MgYW4NCj4gYWNjZXB0YWJsZSB3YXkgdG8g
Z28uICBMZXQgbWUgYXNrLCB0aGVuLCBmb3IgYW55IG9iamVjdGlvbnMgdG8gdGhpcw0KPiBwYXRo
LCB3aGljaCB3aWxsIG1ha2UgdGhlIG1lZGlhIHR5cGUgbmFtZSAiYXBwbGljYXRpb24vanNvbi0N
Cj4gcGF0Y2granNvbiIuICBJZiB5b3UgKm9iamVjdCogdG8gdGhhdCBjaGFuZ2UsIHBvc3QgaGVy
ZSB2ZXJ5IHNvb24uICBJDQo+IHdpbGwgcHV0IGl0IGluIGFzIGFuIGVkaXRvciBub3RlIG5vdy4N
Cj4gDQo+IEJhcnJ5DQoNCklmIHdlIHJlYWxseSB3YW50IGEgK2pzb24gc3VmZml4LCBqdXN0IG1h
a2UgaXQ6DQogIGFwcGxpY2F0aW9uL3BhdGNoK2pzb24NCg0KUmVwZWF0aW5nICJqc29uIiB0d2lj
ZSwgd2l0aCAiLSIgYW5kICIrIiwganVzdCBndWFyYW50ZWVzIHR5cG9zIGFuZCBjb25mdXNpb24u
DQoNCi0tDQpKYW1lcyBNYW5nZXINCg0K

From lear@cisco.com  Tue Jan 22 22:07:33 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8014121F84B6; Tue, 22 Jan 2013 22:07:33 -0800 (PST)
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 YwTlCSAhVloE; Tue, 22 Jan 2013 22:07:32 -0800 (PST)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB2921F84C9; Tue, 22 Jan 2013 22:07:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=628; q=dns/txt; s=iport; t=1358921252; x=1360130852; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=IHpHzkU+hCIrY7Uh9MmT8geXRf+ityodLsHjvNCKE3M=; b=T71PQBPfoRrGXp8eB/xIi1qETAOzAXHzbe++T3ZzHEoHK//pUIHBOkfS Vi37TW6H7PETlU4vQwCylcrCLDk6B2okcKra5Fg0s7R1sCIVScwUSQDJN 2qhdh48ZfNdUrNzcCBNHyc0FYbsn2/4VQaJZu7BxqXR2ZAZ0aYQYm1Rd9 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhEFANp8/1CQ/khR/2dsb2JhbABEhX5Ht2UWc4IeAQEBBCNVARALGAICBRYLAgIJAwIBAgFFBg0BBwEBiBUMqhWSZwSBI48AgRMDlgyQSYJ2
X-IronPort-AV: E=Sophos;i="4.84,520,1355097600"; d="scan'208";a="11265509"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 23 Jan 2013 06:07:30 +0000
Received: from dhcp-10-55-93-149.cisco.com (dhcp-10-55-93-149.cisco.com [10.55.93.149]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0N67Ujq027905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2013 06:07:30 GMT
Message-ID: <50FF7E24.3070908@cisco.com>
Date: Wed, 23 Jan 2013 07:07:32 +0100
From: Eliot Lear 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: =JeffH 
References: <50FF06CD.2050002@KingsMountain.com>
In-Reply-To: <50FF06CD.2050002@KingsMountain.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: draft-laurie-pki-sunlight-05.all@tools.ietf.org, therightkey@ietf.org, The IESG , Apps Discuss 
Subject: Re: [apps-discuss] "mis-issued" was: apps area review of draft-laurie-pki-sunlight-05 (Eliot's version)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Jan 2013 06:07:33 -0000

Defining it on first use is fine.  That would also go with explaining
the use-case for this experiment better.  Just keep in mind your
non-native readers.

On 1/22/13 10:38 PM, =JeffH wrote:
> > "Misissued" is not a word.
>
> but "mis-issued" is a legit contraction, so perhaps it's simply
> misspelled (and a definition should probably be provided).
>
> "mis-issue" and "mis-issued" refer to the situation where a CA issues
> a cert for a given subject (i.e. domain name) when they should not
> have. C.f. Diginotar.
>
> See also: https://tools.ietf.org/html/draft-ietf-pkix-caa-15
>
> HTH,
>
> =JeffH
>
>


From julian.reschke@gmx.de  Wed Jan 23 07:36:48 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BBA21F86D9 for ; Wed, 23 Jan 2013 07:36:48 -0800 (PST)
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 dKJSnYaUlhpS for ; Wed, 23 Jan 2013 07:36:47 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 646F121F86D2 for ; Wed, 23 Jan 2013 07:36:47 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lg2uj-1UneYT1UPz-00pdvh for ; Wed, 23 Jan 2013 16:36:42 +0100
Received: (qmail invoked by alias); 23 Jan 2013 15:36:42 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.102]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 23 Jan 2013 16:36:42 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18CSRFNcQACqcoBRo4FpT5MNel+l5aFIO4lC2tYpn LqPdrV/Xkg2WC3
Message-ID: <51000384.2030608@gmx.de>
Date: Wed, 23 Jan 2013 16:36:36 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Manger, James H" 
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net>  <50FDC6A4.8040700@versi.edu.au>  <255B9BB34FB7D647A506DC292726F6E11504F4D6D3@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11504F4D6D3@WSMSG3153V.srv.dir.telstra.com>
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] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Jan 2013 15:36:48 -0000

On 2013-01-23 01:18, Manger, James H wrote:
>> ----------
>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>> bounces@ietf.org] On Behalf Of Barry Leiba
>> Sent: Wednesday, 23 January 2013 5:37 AM
>>
>>> It seemed to me, on the contrary, that there was a broad consensus at
>>> least that the +json should be used. I think it would be a shame if
>>> the differences of opinion about the name *as a whole* were an
>>> obstacle to accepting the suffix, because the usefulness of the
>> suffix
>>> is generally accepted, and it applies regardless of what the rest of
>>> the name is. Given that, I'd suggest that it would make sense to
>>> append the suffix be appended to the current name. Is there any
>> reason not to do that?
>>
>> Given the agreement posted so far to this, it sounds like that's an
>> acceptable way to go.  Let me ask, then, for any objections to this
>> path, which will make the media type name "application/json-
>> patch+json".  If you *object* to that change, post here very soon.  I
>> will put it in as an editor note now.
>>
>> Barry
>
> If we really want a +json suffix, just make it:
>    application/patch+json
>
> Repeating "json" twice, with "-" and "+", just guarantees typos and confusion.
> ...

I agree that this simpler, but wouldn't object to Barry's choice.

Best regards, Julian

From barryleiba@gmail.com  Wed Jan 23 07:45:52 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C82821F871C for ; Wed, 23 Jan 2013 07:45:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.105
X-Spam-Level: 
X-Spam-Status: No, score=-103.105 tagged_above=-999 required=5 tests=[AWL=-0.128, 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 NznxsT3Jukxp for ; Wed, 23 Jan 2013 07:45:51 -0800 (PST)
Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2A59021F8703 for ; Wed, 23 Jan 2013 07:45:50 -0800 (PST)
Received: by mail-la0-f48.google.com with SMTP id fq13so3793472lab.21 for ; Wed, 23 Jan 2013 07:45:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eba+VgFgoe19GgDm+YW9CTHz+BtxnxgXYiu45AXdnXc=; b=nb3XZRNJwYXDtIPxI/jMkhJjhv+Ms+xUu6w9LE47ERdJwsW8aeRRG70+02d7AzAo70 LWLedXIxPsoG9EdDRuAaHd/zfuOoiIcccsvj2z4elH6MAA+qiGdqJv5ivfIytaoTR9mx Cfx62sSEVb+Mm8hLkwmBwiRordCtQiyeFSMrhfYgQkLo6F6IB3W3t8dCM3zaazYAa62F jqecq3i23h/ffgn4f03h4Xw/oInS5n/ra9/Om6ibvyU56QY59EJK+8iKL1fjZdFwV8oW YWg1/FyVbbhxbj01sKtxdqJi3bFPwwATPzKIvCuevGHF2WZuBTAUhpYxvTcvawxbd2k2 oysA==
MIME-Version: 1.0
X-Received: by 10.112.47.168 with SMTP id e8mr918258lbn.46.1358955945098; Wed, 23 Jan 2013 07:45:45 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.112.47.168 with HTTP; Wed, 23 Jan 2013 07:45:44 -0800 (PST)
In-Reply-To: <51000384.2030608@gmx.de>
References: <030009EF-15AD-4CAC-B2BF-036936FC68FD@mnot.net>  <50FDC6A4.8040700@versi.edu.au>  <255B9BB34FB7D647A506DC292726F6E11504F4D6D3@WSMSG3153V.srv.dir.telstra.com> <51000384.2030608@gmx.de>
Date: Wed, 23 Jan 2013 10:45:44 -0500
X-Google-Sender-Auth: iX9vellwuxu0uU5bjJ7EYiuRC3Y
Message-ID: 
From: Barry Leiba 
To: Julian Reschke 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Jan 2013 15:45:52 -0000

>>> Given the agreement posted so far to this, it sounds like that's an
>>> acceptable way to go.  Let me ask, then, for any objections to this
>>> path, which will make the media type name "application/json-
>>> patch+json".  If you *object* to that change, post here very soon.  I
>>> will put it in as an editor note now.
>>
>> If we really want a +json suffix, just make it:
>>    application/patch+json
>>
>> Repeating "json" twice, with "-" and "+", just guarantees typos and
>> confusion.
>
> I agree that this simpler, but wouldn't object to Barry's choice.

Indeed, and what James wants is not an option -- it's exactly that
discussion that had me initially say that we don't have consensus on
where to go.  The only options on the table for now, because of the
late change, are these:

1. application/json-patch
2. application/json-patch+json

I see strong consensus for (2), and am *only* asking for objections to
that.  You might prefer something else, but do you *object* to (2)?
That's the only question.

James, are you OK with (2), given that it's not your preference?

[By the way: IANA made the registration for (2) yesterday:
http://www.iana.org/assignments/media-types/application
If we have to revert it because of objections here, we can.]

Barry

From James.H.Manger@team.telstra.com  Wed Jan 23 13:54:17 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D721D21F87EE for ; Wed, 23 Jan 2013 13:54:17 -0800 (PST)
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 iRpmGHkDOVKg for ; Wed, 23 Jan 2013 13:54:11 -0800 (PST)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 08E2721F87ED for ; Wed, 23 Jan 2013 13:54:09 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.84,524,1355058000"; d="scan'208";a="114239579"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 24 Jan 2013 08:54:07 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6964"; a="107659400"
Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcdvi.tcif.telstra.com.au with ESMTP; 24 Jan 2013 08:54:06 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Thu, 24 Jan 2013 08:54:06 +1100
From: "Manger, James H" 
To: "barryleiba@computer.org" 
Date: Thu, 24 Jan 2013 08:54:05 +1100
Thread-Topic: [apps-discuss] JSON Patch name
Thread-Index: Ac35gLf4ztlPm7+uSF+EKlME8dLLfQAM3G1X
Message-ID: 
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] JSON Patch name
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Jan 2013 21:54:18 -0000

Ok. I don't object.

--
James Manger

----- Reply message -----
From: "Barry Leiba" 
Date: Thu, Jan 24, 2013 2:45 am
Subject: [apps-discuss] JSON Patch name
To: "Julian Reschke" 
Cc: "Manger, James H" , "apps-discuss@ietf=
.org" 

>>> Given the agreement posted so far to this, it sounds like that's an
>>> acceptable way to go.  Let me ask, then, for any objections to this
>>> path, which will make the media type name "application/json-
>>> patch+json".  If you *object* to that change, post here very soon.  I
>>> will put it in as an editor note now.
>>
>> If we really want a +json suffix, just make it:
>>    application/patch+json
>>
>> Repeating "json" twice, with "-" and "+", just guarantees typos and
>> confusion.
>
> I agree that this simpler, but wouldn't object to Barry's choice.

Indeed, and what James wants is not an option -- it's exactly that
discussion that had me initially say that we don't have consensus on
where to go.  The only options on the table for now, because of the
late change, are these:

1. application/json-patch
2. application/json-patch+json

I see strong consensus for (2), and am *only* asking for objections to
that.  You might prefer something else, but do you *object* to (2)?
That's the only question.

James, are you OK with (2), given that it's not your preference?

[By the way: IANA made the registration for (2) yesterday:
http://www.iana.org/assignments/media-types/application
If we have to revert it because of objections here, we can.]

Barry

From m.kofahl@gmx.de  Thu Jan 24 05:00:56 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C02021F8A27 for ; Thu, 24 Jan 2013 05:00:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Level: 
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdHRwX8a1kYg for ; Thu, 24 Jan 2013 05:00:56 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 96A0621F8A43 for ; Thu, 24 Jan 2013 05:00:55 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.33]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MNwO5-1U5EJp38fb-007WkB for ; Thu, 24 Jan 2013 14:00:54 +0100
Received: (qmail 1606 invoked by uid 0); 24 Jan 2013 13:00:54 -0000
Received: from 194.25.108.94 by www021.gmx.net with HTTP; Thu, 24 Jan 2013 14:00:52 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Date: Thu, 24 Jan 2013 14:00:52 +0100
From: "Martin Kofahl" 
Message-ID: <20130124130052.272540@gmx.net>
MIME-Version: 1.0
To: apps-discuss@ietf.org
X-Authenticated: #403240
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX1/wQCBGM2XwfFpDHUqPcItqzHl2zOhn7dlMw6mNsR A6VjUsCBJon9sqWgL9Qw+zsfiSML4+t4gqIg== 
Content-Transfer-Encoding: 8bit
X-GMX-UID: 01VzcRILeSEqQ0lEbXQhqCZ+IGRvb4CN
Subject: [apps-discuss] JSON Patch not suitable for GeoJSON?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Jan 2013 14:42:56 -0000

Hello. I came across the draft-ietf-appsawg-json-patch-10 proposal and hope that's the right here place to put a question.

As far I can see any remove, replace, etc. operations can be applied on object members or numbered array elements, only. I don't think this is sufficient for some formats. Taking GeoJSON 

{ "type": "FeatureCollection",
  "features": [
    { "type": "Feature",
      "id": "2",
      "geometry": {"type": "Point", "coordinates": [102.0, 0.5]},
      "properties": {"prop0": "value0"}
    },
    ...
  ]
}

as an example, operations may have to be applied on objects filtered by some key-value-conditions in its leafs.

A JSON Patch document may have to look like this:

[
  { "op": "remove", "path": "/features/*/[\"id\"=\"2\"]::parent" }
]

Maybe you can exert this suggestion.

Kind regards,
Martin

From julian.reschke@gmx.de  Thu Jan 24 06:57:37 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA2D21F84D5 for ; Thu, 24 Jan 2013 06:57:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.266
X-Spam-Level: 
X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=-2.667, 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 yr2QM7Dx4sTF for ; Thu, 24 Jan 2013 06:57:37 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 35B0621F84D1 for ; Thu, 24 Jan 2013 06:57:37 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MhPBM-1UKsug1V3a-00Mb2H for ; Thu, 24 Jan 2013 15:57:36 +0100
Received: (qmail invoked by alias); 24 Jan 2013 14:57:36 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.102]) [217.91.35.233] by mail.gmx.net (mp019) with SMTP; 24 Jan 2013 15:57:36 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18HIbMeP00H7eKtrNdYADPcAfWadncIMYYI0Tqzr4 +HFAMqjMhzovsE
Message-ID: <51014BDE.7080706@gmx.de>
Date: Thu, 24 Jan 2013 15:57:34 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Martin Kofahl 
References: <20130124130052.272540@gmx.net>
In-Reply-To: <20130124130052.272540@gmx.net>
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 Patch not suitable for GeoJSON?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Jan 2013 14:57:38 -0000

On 2013-01-24 14:00, Martin Kofahl wrote:
> Hello. I came across the draft-ietf-appsawg-json-patch-10 proposal and hope that's the right here place to put a question.
>
> As far I can see any remove, replace, etc. operations can be applied on object members or numbered array elements, only. I don't think this is sufficient for some formats. Taking GeoJSON
>
> { "type": "FeatureCollection",
>    "features": [
>      { "type": "Feature",
>        "id": "2",
>        "geometry": {"type": "Point", "coordinates": [102.0, 0.5]},
>        "properties": {"prop0": "value0"}
>      },
>      ...
>    ]
> }
>
> as an example, operations may have to be applied on objects filtered by some key-value-conditions in its leafs.
>
> A JSON Patch document may have to look like this:
>
> [
>    { "op": "remove", "path": "/features/*/[\"id\"=\"2\"]::parent" }
> ]
>
> Maybe you can exert this suggestion.
> ...

Essentially you're asking for XPath-like expression (which I sympathize 
with :-).

However, the design goal was to keep things as simple as possible, and 
furthermore the spec just has been approved.

So, too late as well :-)

Best regards, Julian

From barryleiba.mailing.lists@gmail.com  Thu Jan 24 07:56:57 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2778221F8941 for ; Thu, 24 Jan 2013 07:56:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.566
X-Spam-Level: 
X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 3ALApFPOM8wD for ; Thu, 24 Jan 2013 07:56:56 -0800 (PST)
Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDE321F8884 for ; Thu, 24 Jan 2013 07:56:56 -0800 (PST)
Received: by mail-ve0-f174.google.com with SMTP id c13so1562948vea.33 for ; Thu, 24 Jan 2013 07:56:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tk2Y4feJy46xvxCdq/gHaIUeVLqf8RpSYqpuE+I7xrM=; b=EFln3mkjwpMF08NV8ZIHV8+cnDaIXw2yhENgJl+WpIPHDcPlzbRSP5dkhll3F2ntlI CdevPts7ixJv9TZ2rvoOJIqLjA7JEdx3QajCtVBgSz44tlTCLoNWF7HmJkKkIApcYj0F 6BBOPe/0jkrQgplMoXNoc830o5NV7u9mHC5pfw386/w5SEZWPvcb8K9QORE+aGrn653i qX9G47mLr7G6GAuVOM346WaeSRVwsCtHpbm6+5v4708KdWpOZJUA7hCsCNZDttiAEyUi bLJn7F8MPR3K2KK9NfaK7h/MJmzatnHmY1UOKn+qJhm7/AasLBJHggpQgg6Xkik/3LhS +UzQ==
MIME-Version: 1.0
X-Received: by 10.220.116.5 with SMTP id k5mr2362151vcq.55.1359043016075; Thu, 24 Jan 2013 07:56:56 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Thu, 24 Jan 2013 07:56:55 -0800 (PST)
In-Reply-To: <51014BDE.7080706@gmx.de>
References: <20130124130052.272540@gmx.net> <51014BDE.7080706@gmx.de>
Date: Thu, 24 Jan 2013 10:56:55 -0500
X-Google-Sender-Auth: 34T-0NyMYg72dfgFHgO7ZbYJLzY
Message-ID: 
From: Barry Leiba 
To: Martin Kofahl 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] JSON Patch not suitable for GeoJSON?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Jan 2013 15:56:57 -0000

>> as an example, operations may have to be applied on objects filtered by
>> some key-value-conditions in its leafs.
>>
>> A JSON Patch document may have to look like this:
>>
>> [
>>    { "op": "remove", "path": "/features/*/[\"id\"=\"2\"]::parent" }
>> ]
>>
>> Maybe you can exert this suggestion.
>
> Essentially you're asking for XPath-like expression (which I sympathize with
> :-).
>
> However, the design goal was to keep things as simple as possible, and
> furthermore the spec just has been approved.

But you could always write up a proposal for an alternative patch
format -- it's perfectly possible to have multiple different patch
formats for different use cases.

Barry

From jasnell@gmail.com  Thu Jan 24 08:08:30 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B9921F8A51 for ; Thu, 24 Jan 2013 08:08:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.933
X-Spam-Level: 
X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 IUeQnK1N8Jt2 for ; Thu, 24 Jan 2013 08:08:29 -0800 (PST)
Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED9921F8573 for ; Thu, 24 Jan 2013 08:08:25 -0800 (PST)
Received: by mail-ia0-f177.google.com with SMTP id h8so5063045iaa.36 for ; Thu, 24 Jan 2013 08:08:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qm3NlBUzraf97aXT3ZzBNH5z29jo88ruwuXH0LuRGaA=; b=xhekIAfVEMo0v7G5KxJSOY2hSdlUoUpob7lcOu/bbzgpKf75xwW+yx7ZcfpwG0/Lb+ VqnIzTyxzvw4bD6drHcI5G/Cm1pz3WZJR9PacA9gD5qvN0acOcACv4bLePSMKKC5aza4 f74aMKX25/B95nJCY7vB+hsOXuxdmaLKZHxywjHTcz1wlEfWRx3vOFM/nw105lW85q2t V97z1ktPF+tmFFcJVu71w7IEz1z0reEJ4zYw3dM8G7f41jCtghtbiHShTDEuipMMPM/Y z7vZK3UDmYB9fdI7yZAcBa1YLsGxAuNCveHPuHgQokylTj2fwRUQcl2r1BuRr/EpY/50 qnYQ==
MIME-Version: 1.0
X-Received: by 10.42.42.69 with SMTP id s5mr1522597ice.2.1359043701971; Thu, 24 Jan 2013 08:08:21 -0800 (PST)
Received: by 10.64.26.137 with HTTP; Thu, 24 Jan 2013 08:08:21 -0800 (PST)
Received: by 10.64.26.137 with HTTP; Thu, 24 Jan 2013 08:08:21 -0800 (PST)
In-Reply-To: <51014BDE.7080706@gmx.de>
References: <20130124130052.272540@gmx.net> <51014BDE.7080706@gmx.de>
Date: Thu, 24 Jan 2013 08:08:21 -0800
Message-ID: 
From: James M Snell 
To: Julian Reschke 
Content-Type: multipart/alternative; boundary=bcaec50fe5f5171aaf04d40b05ab
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] JSON Patch not suitable for GeoJSON?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Jan 2013 16:08:30 -0000

--bcaec50fe5f5171aaf04d40b05ab
Content-Type: text/plain; charset=UTF-8

You may want to take a look at my json predicates draft. It provides an
extension for json-patch that addresses a broader range of cases.
 On 2013-01-24 14:00, Martin Kofahl wrote:

> Hello. I came across the draft-ietf-appsawg-json-patch-**10 proposal and
> hope that's the right here place to put a question.
>
> As far I can see any remove, replace, etc. operations can be applied on
> object members or numbered array elements, only. I don't think this is
> sufficient for some formats. Taking GeoJSON
>
> { "type": "FeatureCollection",
>    "features": [
>      { "type": "Feature",
>        "id": "2",
>        "geometry": {"type": "Point", "coordinates": [102.0, 0.5]},
>        "properties": {"prop0": "value0"}
>      },
>      ...
>    ]
> }
>
> as an example, operations may have to be applied on objects filtered by
> some key-value-conditions in its leafs.
>
> A JSON Patch document may have to look like this:
>
> [
>    { "op": "remove", "path": "/features/*/[\"id\"=\"2\"]::**parent" }
> ]
>
> Maybe you can exert this suggestion.
> ...
>

Essentially you're asking for XPath-like expression (which I sympathize
with :-).

However, the design goal was to keep things as simple as possible, and
furthermore the spec just has been approved.

So, too late as well :-)

Best regards, Julian
______________________________**_________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/**listinfo/apps-discuss

--bcaec50fe5f5171aaf04d40b05ab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


You may want to take a look at my json predicates draft. It =
provides an extension for json-patch that addresses a broader range of case=
s.




On 2013-01-24 14:00, Martin K=
ofahl wrote:



Hello. I came across the draft-ietf-appsawg-json-patch-10 proposal a=
nd hope that's the right here place to put a question.



As far I can see any remove, replace, etc. operations can be applied on obj=
ect members or numbered array elements, only. I don't think this is suf=
ficient for some formats. Taking GeoJSON



{ "type": "FeatureCollection",

=C2=A0 =C2=A0"features": [

=C2=A0 =C2=A0 =C2=A0{ "type": "Feature",

=C2=A0 =C2=A0 =C2=A0 =C2=A0"id": "2",

=C2=A0 =C2=A0 =C2=A0 =C2=A0"geometry": {"type": "P=
oint", "coordinates": [102.0, 0.5]},

=C2=A0 =C2=A0 =C2=A0 =C2=A0"properties": {"prop0": &quo=
t;value0"}

=C2=A0 =C2=A0 =C2=A0},

=C2=A0 =C2=A0 =C2=A0...

=C2=A0 =C2=A0]

}



as an example, operations may have to be applied on objects filtered by som=
e key-value-conditions in its leafs.



A JSON Patch document may have to look like this:



[

=C2=A0 =C2=A0{ "op": "remove", "path": "=
/features/*/[\"id\"=3D\"2\"]::parent" }

]



Maybe you can exert this suggestion.

...





Essentially you're asking for XPath-like expression (which I sympathize=
 with :-).



However, the design goal was to keep things as simple as possible, and furt=
hermore the spec just has been approved.



So, too late as well :-)



Best regards, Julian

_______________________________________________

apps-discuss mailing list

apps-discuss@iet=
f.org

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




--bcaec50fe5f5171aaf04d40b05ab--

From jasnell@gmail.com  Thu Jan 24 08:42:43 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DC621F8503 for ; Thu, 24 Jan 2013 08:42:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.766
X-Spam-Level: 
X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 8yibZQm0VIY4 for ; Thu, 24 Jan 2013 08:42:42 -0800 (PST)
Received: from mail-ia0-x22c.google.com (ia-in-x022c.1e100.net [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8602B21F84F3 for ; Thu, 24 Jan 2013 08:42:41 -0800 (PST)
Received: by mail-ia0-f172.google.com with SMTP id u8so5147584iag.31 for ; Thu, 24 Jan 2013 08:42:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=2yaV1r2PCdk08Tf0d9sKcbHR27FmN2hmioVw8EwH+bc=; b=xxtZMHQADD7ZZg4/nOPcx7iPIirRRF1b2Z68ReNFdfVLl3/1A5XWE2w+sT0VBpzYmr f0pkxtK6CX6RGZGV6v7iZ75alrSw/KHanfq0sHAHQGXDVeqBo3tQIm5c7KIVEoaKYsC2 rTwrO7QigIrGR5S0Mcm4SNDPH6eS+SxmrLYZR1R9YMcFb3wjI8uFHVzGCHc6rWL6pzMo 8R4dwX3aQ4LnBl2DBc9wDpzOJZtkxTULvp4XMg01MDh1DF1HohByjwCbNd7pImZBAdiF XIrYn/a2VS7HGsSfZVdbrQaG1R8IN/isy5tHtWX41isDNldsMTjcaibVE1zn+aoGcqMw Nzxw==
X-Received: by 10.42.58.202 with SMTP id j10mr1517760ich.39.1359045761088; Thu, 24 Jan 2013 08:42:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.26.137 with HTTP; Thu, 24 Jan 2013 08:42:21 -0800 (PST)
In-Reply-To: <20130124130052.272540@gmx.net>
References: <20130124130052.272540@gmx.net>
From: James M Snell 
Date: Thu, 24 Jan 2013 08:42:21 -0800
Message-ID: 
To: Martin Kofahl 
Content-Type: multipart/alternative; boundary=20cf30334613d2bc6904d40b7f55
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] JSON Patch not suitable for GeoJSON?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Jan 2013 16:42:43 -0000

--20cf30334613d2bc6904d40b7f55
Content-Type: text/plain; charset=UTF-8

On Thu, Jan 24, 2013 at 5:00 AM, Martin Kofahl  wrote:

> Hello. I came across the draft-ietf-appsawg-json-patch-10 proposal and
> hope that's the right here place to put a question.
>
> As far I can see any remove, replace, etc. operations can be applied on
> object members or numbered array elements, only. I don't think this is
> sufficient for some formats. Taking GeoJSON
>
> { "type": "FeatureCollection",
>   "features": [
>     { "type": "Feature",
>       "id": "2",
>       "geometry": {"type": "Point", "coordinates": [102.0, 0.5]},
>       "properties": {"prop0": "value0"}
>     },
>     ...
>   ]
> }
>
> as an example, operations may have to be applied on objects filtered by
> some key-value-conditions in its leafs.
>
> A JSON Patch document may have to look like this:
>
> [
>   { "op": "remove", "path": "/features/*/[\"id\"=\"2\"]::parent" }
> ]
>
> Maybe you can exert this suggestion.
>
>
Take a look at
http://tools.ietf.org/html/draft-snell-json-test-05#section-2.5.1

[
  {
    "op": "remove",
    "path": "/features/0",
    "if": {
      "op": "test",
      "path": "/features/0/id",
      "value": "2"
    }
]

Yes, I know it's not quite the same as your example but it's closer. I
could get it closer by defining an iterator operation... e.g.

[
  {
    "op": "each",
    "path": "/features",
    "apply": {
      "op": "remove",
      "if": {
        "op": "test",
        "path": "/id",
        "value": "2"
      }
    }
  }
]

The way to interpret this would be: For each member of /features (whether
it's an array or object), set the member as the context object and apply
the remove operation only if the condition holds for that item.

Alternatively, we can use the json-predicates draft as the base to
introduce a more complete pointer expression syntax... e.g.

[
  { "op": "remove", "exp": "/features/*/[\"id\"=\"2\"]::parent" }
]

Note the use of "exp" instead of "path"... the hope with json-pointer is to
coexist with json-patch, not replace it...

- James


> Kind regards,
> Martin
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--20cf30334613d2bc6904d40b7f55
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Thu, Jan 24, 2013 at 5:00 AM, Martin Kofahl <M.Kofahl@gmx.de> wrote:



Hello. I came across the draft-ietf-appsawg-json-patch-10 =
proposal and hope that's the right here place to put a question.





As far I can see any remove, replace, etc. operations can be applied on obj=
ect members or numbered array elements, only. I don't think this is suf=
ficient for some formats. Taking GeoJSON



{ "type": "FeatureCollection",

=C2=A0 "features": [

=C2=A0 =C2=A0 { "type": "Feature",

=C2=A0 =C2=A0 =C2=A0 "id": "2",

=C2=A0 =C2=A0 =C2=A0 "geometry": {"type": "Point&q=
uot;, "coordinates": [102.0, 0.5]},

=C2=A0 =C2=A0 =C2=A0 "properties": {"prop0": "valu=
e0"}

=C2=A0 =C2=A0 },

=C2=A0 =C2=A0 ...

=C2=A0 ]

}



as an example, operations may have to be applied on objects filtered by som=
e key-value-conditions in its leafs.



A JSON Patch document may have to look like this:



[

=C2=A0 { "op": "remove", "path": "/featu=
res/*/[\"id\"=3D\"2\"]::parent" }

]



Maybe you can exert this suggestion.






[
=C2=A0 {
=C2=A0 =C2=
=A0 "op": "remove",=C2=A0
=C2=A0 =C2=A0=
 "path": "/features/0",=C2=A0
=C2=A0 =
=C2=A0 "if": {
=C2=A0 =C2=A0 =C2=A0 "op"=
;: "test",



=C2=A0 =C2=A0 =C2=A0 "path": "/features/0/id"=
;,
=C2=A0 =C2=A0 =C2=A0 "value": "2"
=C2=A0 =C2=A0 }
]

<=
div style>Yes, I know it's not quite the same as your example but it=
9;s closer. I could get it closer by defining an iterator operation... e.g.=
=C2=A0




[
=C2=A0 {
=
=C2=A0 =C2=A0 "op": "each",
=C2=A0 =C2=
=A0 "path": "/features",
=C2=A0 =C2=A0 =
"apply": {


=C2=A0 =C2=A0 =C2=A0 "op": "remove",
=
=C2=A0 =C2=A0 =C2=A0 "if": {
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 "op": "test",
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 "path": "/id",
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 "value": "2"



=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }
]

The =
way to interpret this would be: For each member of /features (whether it=
9;s an array or object), set the member as the context object and apply the=
 remove operation only if the condition holds for that item.=C2=A0




Alternatively, we can use the json-predicat=
es draft as the base to introduce a more complete pointer expression syntax=
... e.g.=C2=A0

[
=C2=A0 { "op&=
quot;: "remove", "exp": "/features/*/[\"id\&q=
uot;=3D\"2\"]::parent" }


]

Note the use of "exp" =
instead of "path"... the hope with json-pointer is to coexist wit=
h json-patch, not replace it...

- Jame=
s



=C2=A0

Kind regards,

Martin

_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--20cf30334613d2bc6904d40b7f55--

From ncamwing@cisco.com  Fri Jan 25 18:50:13 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F2021F842C; Fri, 25 Jan 2013 18:50:13 -0800 (PST)
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 xZ3eV50FpP0Y; Fri, 25 Jan 2013 18:50:12 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A0AD821F88D6; Fri, 25 Jan 2013 18:50:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1996; q=dns/txt; s=iport; t=1359168612; x=1360378212; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=sI2SCjZL8Nuv5xAffGlFMjXuDCNrnJPJm7K2aqDHAmE=; b=YEw9/OnEg0C0VDPPYlQlKSNNpWDFCLRwcQvdSVUoii+dNQGEZFFfOkDd 1yCKYZFG7WGLZpuqVYgoHaJrdnzRHMK/BOXYn+uEuViZdv3s4Lljw49Ce 21nF+9kDa1qI/0Eh0rEd8phrrQ+iO0yQIEwRi5F732AX5bs0AZH6+eJpp c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAAJEA1GtJV2Z/2dsb2JhbABFhka3I3YWc4IgAQQjEUUSAQgUBgIGIAIEMBUQAgQBDQUIiAcMrAaSSIEjjwkyYQOXKY8sgneCJA
X-IronPort-AV: E=Sophos;i="4.84,542,1355097600"; d="scan'208";a="168395143"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jan 2013 02:50:00 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0Q2o0g2010626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Jan 2013 02:50:00 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 20:49:59 -0600
From: "Nancy Cam-Winget (ncamwing)" 
To: Alexey Melnikov , "apps-discuss@ietf.org" , "draft-ietf-nea-pt-eap.all@tools.ietf.org" 
Thread-Topic: APPSDIR review of draft-ietf-nea-pt-eap-06
Thread-Index: AQHN9OjE4LjtJY2ffE2xtLDK9PL1bJha1E6A
Date: Sat, 26 Jan 2013 02:49:57 +0000
Message-ID: 
In-Reply-To: <50F850BC.8010203@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.1.120420
x-originating-ip: [10.21.85.142]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Mailman-Approved-At: Sat, 26 Jan 2013 10:44:31 -0800
Cc: "iesg@ietf.org" 
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-nea-pt-eap-06
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Jan 2013 02:50:13 -0000

SGkgQWxleGV5LA0KDQpNYW55IHRoYW5rcyBmb3IgdGhlIHJldmlldyBhbmQgYXBvbG9naWVzIGZv
ciB0aGUgZGVsYXllZCByZXNwb25zZS4NCg0KWW91IGFyZSByaWdodCwgSSB3YXMgcmVtaXNzIGlu
IGRvaW5nIGEgZnVsbCB1cGRhdGUgd2hlbiB3ZSBzd2l0Y2hlZCB0bw0KaW5jbHVkZSBURUFQIGFz
IHRoZSBNVEkgbWV0aG9kLCBzbyB3aWxsIG1vdmUgaXRzIHJlZmVyZW5jZSB0bw0Kbm9ybWF0aXZl
4oCmLnNpbWlsYXJseSwgSSB3aWxsIGRvIHRoZSBzYW1lIGZvciB0bHMtdW5pcXVlLg0KDQpUaGFu
a3MgYWdhaW4sDQogICBOYW5jeS4NCg0KT24gMS8xNy8xMyAxMToyNyBBTSwgIkFsZXhleSBNZWxu
aWtvdiIgPGFsZXhleS5tZWxuaWtvdkBpc29kZS5jb20+IHdyb3RlOg0KDQo+SSBoYXZlIGJlZW4g
c2VsZWN0ZWQgYXMgdGhlIEFwcGxpY2F0aW9ucyBBcmVhIERpcmVjdG9yYXRlIHJldmlld2VyIGZv
cg0KPnRoaXMgZHJhZnQgKGZvciBiYWNrZ3JvdW5kIG9uIGFwcHNkaXIsIHBsZWFzZSBzZWUg4oCL
DQo+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9hcHAvdHJhYy93aWtpL0FwcGxpY2F0
aW9uc0FyZWFEaXJlY3RvcmF0ZSkNCj4uDQo+DQo+UGxlYXNlIHJlc29sdmUgdGhlc2UgY29tbWVu
dHMgYWxvbmcgd2l0aCBhbnkgb3RoZXIgTGFzdCBDYWxsIGNvbW1lbnRzDQo+eW91IG1heSByZWNl
aXZlLiAgUGxlYXNlIHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgc2hlcGhl
cmQNCj5vciBBRCBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCj4N
Cj5Eb2N1bWVudDogZHJhZnQtaWV0Zi1uZWEtcHQtZWFwLTA2DQo+VGl0bGU6IFBULUVBUDogUG9z
dHVyZSBUcmFuc3BvcnQgKFBUKSBQcm90b2NvbCBGb3IgRUFQIFR1bm5lbCBNZXRob2RzDQo+UmV2
aWV3ZXI6IEFsZXhleSBNZWxuaWtvdg0KPlJldmlldyBEYXRlOiAyMDEzLTAxLTE3DQo+SUVURiBM
YXN0IENhbGwgRGF0ZTogMjAxMy0wMS0xNg0KPklFU0cgVGVsZWNoYXQgRGF0ZTogdW5rbm93bg0K
Pg0KPlN1bW1hcnk6DQo+DQo+VGhpcyBkcmFmdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24gYXMg
YSBQcm9wb3NlZCBTdGFuZGFyZCBSRkMsIHdpdGgNCj5zb21lIG1pbm9yIGlzc3VlcyB3aXRoIHJl
ZmVyZW5jZXMuDQo+DQo+TWFqb3IgSXNzdWVzOg0KPiAgIG5vbmUNCj4NCj5NaW5vciBJc3N1ZXM6
DQo+DQo+VEVBUCByZWZlcmVuY2UgaXMgbm9ybWF0aXZlLCBhcyBpdCBpcyBtYW5kYXRvcnktdG8t
aW1wbGVtZW50LiAobGFzdA0KPnNlbnRlbmNlIGluIDQuMykuIEFsc28sIGlzIGxhc3Qgc2VudGVu
Y2Ugb2YgNC4zIGlzIGNvbnRyYWRpY3RpbmcgdGhlIDJuZA0KPnBhcmFncmFwaCBpbiBTZWN0aW9u
IDU/DQo+DQo+U2ltaWxhcmx5LCB0bHMtdW5pcXVlIHJlZmVyZW5jZSBsb29rcyBub3JtYXRpdmUg
YXMgd2VsbC4NCj4NCj5OaXRzOg0KPiAgbm9uZQ0KDQo=

From ncamwing@cisco.com  Fri Jan 25 19:22:44 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABEC21F85B6; Fri, 25 Jan 2013 19:22:44 -0800 (PST)
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 TqeEFr9iUSe7; Fri, 25 Jan 2013 19:22:44 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1B24E21F84BC; Fri, 25 Jan 2013 19:22:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1812; q=dns/txt; s=iport; t=1359170564; x=1360380164; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=U3OcjndIMB9rY6d/uQwbqxQm2pvCmuiTp02yptZ7qfY=; b=kc8SKee1l0jZJp99rVQr3s0wAWwj1br+ydDa9+mAtkpomGhTf6H8IeBz unjYpPuhq22zdnTo6+FDFqOWKZUzyWlu3h7NDsp9YRq4Tjd4bgOIzrYVC CdVnljtIDu1fjApL6E4k17KBKavp/ttwIfK7n64+tyCPGAlc8+NYyTnzR w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAGJKA1GtJV2d/2dsb2JhbABFhka3JnYWc4IgAQQjEUUSAQgUBgIGIAIEMBUQAgQBDQUIiAcMrASSRoEjjwkyYQOXKY8sgneCJA
X-IronPort-AV: E=Sophos;i="4.84,542,1355097600"; d="scan'208";a="168190599"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jan 2013 03:22:43 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0Q3MhGq011894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Jan 2013 03:22:43 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 21:22:43 -0600
From: "Nancy Cam-Winget (ncamwing)" 
To: Alexey Melnikov , "apps-discuss@ietf.org" , "draft-ietf-nea-pt-eap.all@tools.ietf.org" 
Thread-Topic: APPSDIR review of draft-ietf-nea-pt-eap-06
Thread-Index: AQHN9OjE4LjtJY2ffE2xtLDK9PL1bJha3XGA
Date: Sat, 26 Jan 2013 03:22:40 +0000
Message-ID: 
In-Reply-To: <50F850BC.8010203@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.1.120420
x-originating-ip: [10.21.85.142]
Content-Type: text/plain; charset="utf-8"
Content-ID: <35448F8B9CDE344B952BAC6927E7B92C@cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Mailman-Approved-At: Sat, 26 Jan 2013 10:44:44 -0800
Cc: "iesg@ietf.org" 
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-nea-pt-eap-06
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Jan 2013 03:22:44 -0000

Rm9yZ290IHRvIGFsc28gdGhhbmsgeW91IGZvciBjYXRjaGluZyB0aGUgaW5jb25zaXN0ZW5jeSBp
biBTZWN0aW9uIDUsIHdpbGwNCmNoYW5nZSBpdCB0byBzdGF0ZSB0aGF0IFRFQVAgaXMgdGhlIG1h
bmRhdG9yeSB0byBpbXBsZW1lbnQgdHVubmVsIG1ldGhvZC4NCg0KVGhhbmtzIQ0KICBOYW5jeS4N
Cg0KT24gMS8xNy8xMyAxMToyNyBBTSwgIkFsZXhleSBNZWxuaWtvdiIgPGFsZXhleS5tZWxuaWtv
dkBpc29kZS5jb20+IHdyb3RlOg0KDQo+SSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIEFwcGxp
Y2F0aW9ucyBBcmVhIERpcmVjdG9yYXRlIHJldmlld2VyIGZvcg0KPnRoaXMgZHJhZnQgKGZvciBi
YWNrZ3JvdW5kIG9uIGFwcHNkaXIsIHBsZWFzZSBzZWUg4oCLDQo+aHR0cDovL3RyYWMudG9vbHMu
aWV0Zi5vcmcvYXJlYS9hcHAvdHJhYy93aWtpL0FwcGxpY2F0aW9uc0FyZWFEaXJlY3RvcmF0ZSkN
Cj4uDQo+DQo+UGxlYXNlIHJlc29sdmUgdGhlc2UgY29tbWVudHMgYWxvbmcgd2l0aCBhbnkgb3Ro
ZXIgTGFzdCBDYWxsIGNvbW1lbnRzDQo+eW91IG1heSByZWNlaXZlLiAgUGxlYXNlIHdhaXQgZm9y
IGRpcmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgc2hlcGhlcmQNCj5vciBBRCBiZWZvcmUgcG9z
dGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCj4NCj5Eb2N1bWVudDogZHJhZnQtaWV0
Zi1uZWEtcHQtZWFwLTA2DQo+VGl0bGU6IFBULUVBUDogUG9zdHVyZSBUcmFuc3BvcnQgKFBUKSBQ
cm90b2NvbCBGb3IgRUFQIFR1bm5lbCBNZXRob2RzDQo+UmV2aWV3ZXI6IEFsZXhleSBNZWxuaWtv
dg0KPlJldmlldyBEYXRlOiAyMDEzLTAxLTE3DQo+SUVURiBMYXN0IENhbGwgRGF0ZTogMjAxMy0w
MS0xNg0KPklFU0cgVGVsZWNoYXQgRGF0ZTogdW5rbm93bg0KPg0KPlN1bW1hcnk6DQo+DQo+VGhp
cyBkcmFmdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24gYXMgYSBQcm9wb3NlZCBTdGFuZGFyZCBS
RkMsIHdpdGgNCj5zb21lIG1pbm9yIGlzc3VlcyB3aXRoIHJlZmVyZW5jZXMuDQo+DQo+TWFqb3Ig
SXNzdWVzOg0KPiAgIG5vbmUNCj4NCj5NaW5vciBJc3N1ZXM6DQo+DQo+VEVBUCByZWZlcmVuY2Ug
aXMgbm9ybWF0aXZlLCBhcyBpdCBpcyBtYW5kYXRvcnktdG8taW1wbGVtZW50LiAobGFzdA0KPnNl
bnRlbmNlIGluIDQuMykuIEFsc28sIGlzIGxhc3Qgc2VudGVuY2Ugb2YgNC4zIGlzIGNvbnRyYWRp
Y3RpbmcgdGhlIDJuZA0KPnBhcmFncmFwaCBpbiBTZWN0aW9uIDU/DQo+DQo+U2ltaWxhcmx5LCB0
bHMtdW5pcXVlIHJlZmVyZW5jZSBsb29rcyBub3JtYXRpdmUgYXMgd2VsbC4NCj4NCj5OaXRzOg0K
PiAgbm9uZQ0KDQo=

From salvatore.loreto@ericsson.com  Mon Jan 28 05:24:47 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134B721F8585 for ; Mon, 28 Jan 2013 05:24:47 -0800 (PST)
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_SE=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 fCFWOsYDSyqm for ; Mon, 28 Jan 2013 05:24:46 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8CE21F843A for ; Mon, 28 Jan 2013 05:24:46 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-7d-51067c1c8f8d
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5A.F2.19728.C1C76015; Mon, 28 Jan 2013 14:24:45 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Mon, 28 Jan 2013 14:24:44 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id D400F236D; Mon, 28 Jan 2013 15:24:44 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 12ED15407D; Mon, 28 Jan 2013 15:24:43 +0200 (EET)
Received: from n94.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C4BEC53F90; Mon, 28 Jan 2013 15:24:42 +0200 (EET)
Message-ID: <51067C1C.2050509@ericsson.com>
Date: Mon, 28 Jan 2013 15:24:44 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvra5sDVugQdcfPovVL1ewWUz83sDm wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGVsuX2EvaCHpWL/ln72BsZlzF2MHBwSAiYS 7ScEuhg5gUwxiQv31rN1MXJxCAmcZJRouTKBHSQhJLCBUaLpgT9EYhejxP1969ghnLWMEv9f T2WBcJYySmx51MQE0sIroC2x5NVmZhCbRUBVYu+JXhYQm03ATOL5wy1gcVGBZImPd66xQtQL Spyc+QSsRkTAWGLS5iVsIDazgL5Ew5o5YDXCAs4S0zccY4SI20pcmHOdBcKWl9j+dg4zxA9q ElfPbWKGOFtLovdsJ9MERuFZSFbMQtI+C0n7AkbmVYzsuYmZOenlRpsYgWF8cMtv1R2Md86J HGKU5mBREucNd70QICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExLntN9JzsjUJ8YpN6CrYq PerntJnus2b79s93OSf71ZYrHi351fZ97sfqnG+Gr5KvcazveijGurO+8IfcYX/9hTeDl3M9 MGJ5MTvUM2Jdv2/ey+vZTXEevPf7J3Gd8HM7F2jWzdxpHjBhT00UV6owv24w73SnOfry82pt 6gtWVvl+FgtqNFViKc5INNRiLipOBAApck3SMQIAAA==
Subject: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jan 2013 13:24:47 -0000

Dear WG partecipants,


I would like to initiate a 2 weeks WG Last Call on
draft-ietf-appsawg-acct-uri-02.txt ("The 'acct' URI Scheme")
http://tools.ietf.org/id/draft-ietf-appsawg-acct-uri-02.txt


Please send your reviews, as well as expression of support regarding
document readiness for IESG (or not) either to the *apps-discuss* 
mailing list,
or directly to the WG chairs (Murray Kucherawy and myself).


The WG LC will end on Friday, February 8th.


Thank you,
Salvatore as an APPSAWG co-chair.



From stephen.farrell@cs.tcd.ie  Mon Jan 28 07:30:09 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ADA21F8786; Mon, 28 Jan 2013 07:30:09 -0800 (PST)
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_23=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 IUwlEaFpUHhz; Mon, 28 Jan 2013 07:30:09 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2707721F8763; Mon, 28 Jan 2013 07:30:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 87988BE33; Mon, 28 Jan 2013 15:29:47 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5R-obiGss9Zk; Mon, 28 Jan 2013 15:29:42 +0000 (GMT)
Received: from [IPv6:2001:770:10:203:d03a:b6e9:52e7:3e1e] (unknown [IPv6:2001:770:10:203:d03a:b6e9:52e7:3e1e]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 254EABE6B; Mon, 28 Jan 2013 15:29:39 +0000 (GMT)
Message-ID: <51069964.2070208@cs.tcd.ie>
Date: Mon, 28 Jan 2013 15:29:40 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "tls@ietf.org" , Apps Discuss 
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] independent submission for IRC/TLS
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jan 2013 15:30:10 -0000

Hiya,

The IESG will do an RFC 5742 review of this [1] draft on
Feb 7. The draft registers a port basically and says
that that port is used for irc/tls.

I reckon that it doesn't conflict with work that the IETF
is doing.

I'll probably have comments on the draft, but 5742 review is
just to see that it doesn't conflict with work we're doing
or plan to do (roughly, read the RFC if you care more) so my
and other AD comments will be treated the same as anyone else's.
If you have technical comments, I'm sure the authors and the
independent submission editor would be interested in those,
so send them that way rather than discuss them on these
lists. (You can do that by sending a mail to:
draft-hartmann-default-port-for-irc-via-tls-ssl@tools.ietf.org
cc'ing rfc-ise@rfc-editor.org)

*Please* don't reply to this unless your reply is relevant
to the 5742 review.

Cheers,
S.

[1]
https://datatracker.ietf.org/doc/draft-hartmann-default-port-for-irc-via-tls-ssl/

From internet-drafts@ietf.org  Mon Jan 28 08:19:22 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E8021F891D; Mon, 28 Jan 2013 08:19:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.52
X-Spam-Level: 
X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 daArkmF66eOS; Mon, 28 Jan 2013 08:19:16 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D123221F8901; Mon, 28 Jan 2013 08:19:15 -0800 (PST)
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.37
Message-ID: <20130128161915.25113.71244.idtracker@ietfa.amsl.com>
Date: Mon, 28 Jan 2013 08:19:15 -0800
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-09.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, 28 Jan 2013 16:19:22 -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           : WebFinger
	Author(s)       : Paul E. Jones
                          Gonzalo Salgueiro
                          Joseph Smarr
	Filename        : draft-ietf-appsawg-webfinger-09.txt
	Pages           : 20
	Date            : 2013-01-28

Abstract:
   This specification defines the WebFinger protocol, which can be used
   to discover information about people or other entities on the
   Internet using standard HTTP methods.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-09


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From benl@google.com  Mon Jan 28 06:16:21 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A76C21F8820 for ; Mon, 28 Jan 2013 06:16:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.832
X-Spam-Level: 
X-Spam-Status: No, score=-102.832 tagged_above=-999 required=5 tests=[AWL=0.145, 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 FfNYw+ZXcUYm for ; Mon, 28 Jan 2013 06:16:20 -0800 (PST)
Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 96BB321F881E for ; Mon, 28 Jan 2013 06:16:20 -0800 (PST)
Received: by mail-vc0-f181.google.com with SMTP id d16so1870705vcd.40 for ; Mon, 28 Jan 2013 06:16:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/tn9lS7irVAo3e7LZA3dVlOrwBNKhQGQYHSboZ3TXr4=; b=avys5gYFgX9n60Vc287oqDm0AGd+bA7iKwMTAcPRQ6f6zNvqTTBfJE3AtPVLMKLNOj hhuYn0QBUkW8rRGcLq8d1Jx42+v05KU/cR2F4qfGnRSe0xGfzMDqIOaOhSBAjzREwACt PqbVnA8QrBDm7WQ5VJ3eyodwZA63nEBhAzTGrv4oBbWxSH4pcCg+nS61wyF2FF/7X/N1 2a+HgJk7eM4Mtf7j3vi6EXxrnPc9XmoiLVZob3NoZN1+LuE41ITOTUh/1ULrwjF4elOP CsQ0kifgavOE6Ig6st4chXFP1nZDZxFky0j0Qhj4dZTAQAmBBew6wiuDAnQpAYbco6Rz JeWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=/tn9lS7irVAo3e7LZA3dVlOrwBNKhQGQYHSboZ3TXr4=; b=hgHhVfSbnHCjaae2Xlfe7q04KIDFxqhpNfLcZAE/rbftiuF5XD4xs2vD8T0FsLDC9/ 2nwhy2DrvRoBnsngxEh1No6J7KMgOinS2XRqryscP0MiYHKUXrKgJyEHEiShDd0yR2Tt TjKjCx2PZg2MUy8GEy+NkWNvE7MnrfRho//z/euzItQboF132yR8zPxJmDo/SlpuVIkY rzlI+4OzBmqEPscwXxig5R03oemudAGDd+ajKkePmVkaigtmqdRNxsOLL4YrkA7EMOI0 O9JDVNKlpNWcKx2TmODcfI/5plmUUFy/VveNojwmReLjacE6N3ZfO7IfPrhHKWNLa1N0 Gq1A==
MIME-Version: 1.0
X-Received: by 10.52.67.133 with SMTP id n5mr13005827vdt.24.1359382579786; Mon, 28 Jan 2013 06:16:19 -0800 (PST)
Received: by 10.220.67.143 with HTTP; Mon, 28 Jan 2013 06:16:18 -0800 (PST)
In-Reply-To: <50FD8BB8.9060200@isode.com>
References: <50FD8BB8.9060200@isode.com>
Date: Mon, 28 Jan 2013 14:16:18 +0000
Message-ID: 
From: Ben Laurie 
To: Alexey Melnikov 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmXpTNnZVC5UsV5JfbA8nLbMORSRJfq4NsAwuotF9tFqH+AQ56g92hw/0UmutznfrPWefnELpBQLq95/yVyQakGQ52Qxei55q7x17ZsLSl0jmOxNriOKk3Yy1RAjS50tqyOifuose1zKnyLWKfLcJ0o2WLekuDtHptKWwHD26mQq/l2xbc9MAlRSAEFZzohiHboR1eK
X-Mailman-Approved-At: Mon, 28 Jan 2013 09:49:11 -0800
Cc: draft-laurie-pki-sunlight.all@tools.ietf.org, "apps-discuss@ietf.org" , The IESG 
Subject: Re: [apps-discuss] APPSDIR review of draft-laurie-pki-sunlight-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jan 2013 14:16:21 -0000

On 21 January 2013 18:40, Alexey Melnikov  wrote:
> I have been selected as the Applications Area Directorate reviewer for this
> draft (for background on appsdir, please see
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.  Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
>
> Document: draft-laurie-pki-sunlight-05
> Title: Certificate Transparency
> Reviewer: Alexey Melnikov
> Review Date: 2013-01-21
> IETF Last Call Date: 2013-01-24
> IESG Telechat Date: unknown
>
> Summary:
>
> This draft is nearly ready for publication as an Experimental RFC. I think a
> revision should be able to address my issues (and issues raised by Eliot
> earlier).
>
> Major Issues:
>   none
>
> Minor Issues:
>
> 1) There are no references for SHA-256/TLS/RSA in the document. They are
> Normative and should be added.

Done.

> 2) Section 4 needs references for JSON, base64 and HTTP.

Done.

> 3) Section 4.1: it would be good to have an example.

Why 4.1 particularly?

> 4) In 4.5/4.6: are indexes 0-based or 1-based?

0-based.

From salvatore.loreto@ericsson.com  Mon Jan 28 10:16:52 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCD421F89A4 for ; Mon, 28 Jan 2013 10:16:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.248
X-Spam-Level: 
X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 qpNpKeNcxpEd for ; Mon, 28 Jan 2013 10:16:51 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D153D21F899E for ; Mon, 28 Jan 2013 10:16:50 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-a7-5106c09191b7
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BA.11.32353.190C6015; Mon, 28 Jan 2013 19:16:50 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Mon, 28 Jan 2013 19:16:49 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 6C5512ACC; Mon, 28 Jan 2013 20:16:49 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 98C185417B; Mon, 28 Jan 2013 20:16:47 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3FC4253F8F; Mon, 28 Jan 2013 20:16:47 +0200 (EET)
Message-ID: <5106C090.8080403@ericsson.com>
Date: Mon, 28 Jan 2013 20:16:48 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
References: <5106BFDC.2030706@ericsson.com>
In-Reply-To: <5106BFDC.2030706@ericsson.com>
X-Forwarded-Message-Id: <5106BFDC.2030706@ericsson.com>
Content-Type: multipart/mixed; boundary="------------010501000402020307030603"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGfG3VnfSAbZAg2/mFqtfrmCzmPi9gc2B yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgyjhzroOlYLJWxbSeKywNjGsVuhg5OCQETCQO TqnpYuQEMsUkLtxbz9bFyMUhJHCSUWLn+9vMEM4GRonl62aygVQJCexilDi/WQIisZZRov/R Y1YIZxujxJXVO8CqeAW0JTbc+ccMYrMIqEq0z3oIZrMJmEk8f7gFzBYVSJb4eOcaK0S9oMTJ mU9YQGwRAWOJSZuXgM1hFtCXaFgzB6xGWMBF4tKWfYwQV2hL7N+3HCzOKaAjsW3CeWaIH8wl GtatYwJ5jVkgQOLpl0yIsJrE1XObmCFatSR6z3YyTWAUnYVk8yyEjllgi8Mkbr59zA5h20pc mHOdBcKWl9j+dg4zhK0rceH/FCzi7hKNbzejiYOMd5S4+0pjASPXKkb23MTMnPRy802MwLg8 uOW3wQ7GTffFDjFKc7AoifOGu14IEBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cAokaS5mG/h +dKrs6c39J0STcrI+yzF7L3usN9MJTO/i4pz5l+8IjoxKuGi5aJ+DV7vfz/jzT2DEvfnv2/v 2bRagfHFOt4c6WfX2T/Gzm+afPi2sOuxT0JqExq5dxzZMzco5sOZqflnfpWb8/+tlV8cf+33 zMJzWg0MBptirHfMN986ozdCkWu5EktxRqKhFnNRcSIA/XWE1ZkCAAA=
Subject: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-webfinger-09
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jan 2013 18:16:52 -0000

--------------010501000402020307030603
Content-Type: multipart/alternative;
	boundary="------------060504010705000107040907"

--------------060504010705000107040907
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

FYI

the 2 weeks WGLC on draft-ietf-appsawg-webfinger is started.
Please see the mail below and note that the right venue for discussion is
the *webfinger* mailing list

best regards
Salvatore

-------- Original Message --------
Subject: 	[webfinger] Working Group Last Call for 
draft-ietf-appsawg-webfinger-09
Date: 	Mon, 28 Jan 2013 20:13:48 +0200
From: 	Salvatore Loreto 
To: 	
CC: 	Murray S. Kucherawy 



Dear WG partecipants,


I would like to initiate a 2 weeks WG Last Call on
draft-ietf-appsawg-webfinger-09.txt ("WebFinger")
http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt


Please send your reviews, as well as expression of support regarding
document readiness for IESG (or not) either to the *webfinger* mailing 
list (webfinger@ietf.org),
or directly to the WG chairs (Murray Kucherawy and myself).

Comments like "I've read the document and it is Ok to publish" or
"I've read the document and it has the following issues"
are useful and would be gratefully accepted by chairs.


The WG LC will end on Friday, February 8th.


Thank you,
Salvatore as an APPSAWG co-chair.





--------------060504010705000107040907
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  

    
  
  
    FYI

    

    
the 2 weeks WGLC on
      draft-ietf-appsawg-webfinger is started.

      Please see the mail below and note that the right venue for
      discussion is 

      the *webfinger* mailing list

      

      best regards

      Salvatore

      

      -------- Original Message --------
      

        
          

            Subject:
            
            [webfinger] Working Group Last Call for
              draft-ietf-appsawg-webfinger-09
          

          

            Date: 
            Mon, 28 Jan 2013 20:13:48 +0200
          

          

            From: 
            Salvatore Loreto <salvatore.loreto@ericsson.com>
          

          

            To: 
            <webfinger@ietf.org>
          

          

            CC: 
            Murray S. Kucherawy <superuser@gmail.com>
          

        
      

      

      

      
      Dear WG partecipants, 

      

      

      I would like to initiate a 2 weeks WG Last Call on 

      draft-ietf-appsawg-webfinger-09.txt ("WebFinger") 

      http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt

      

      

      Please send your reviews, as well as expression of support
      regarding 

      document readiness for IESG (or not) either to the *webfinger* mailing list (webfinger@ietf.org), 

      or directly to the WG chairs (Murray Kucherawy and myself). 

      

      Comments like "I've read the document and it is Ok to publish" or
      

      "I've read the document and it has the following issues"

      are useful and would be gratefully accepted by chairs. 

      

      

      The WG LC will end on Friday, February 8th. 

      

      

      Thank you, 

      Salvatore as an APPSAWG co-chair. 

      

      

      

    

    

  


--------------060504010705000107040907--

--------------010501000402020307030603
Content-Type: text/plain; charset="UTF-8"; name="Attached Message Part"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="Attached Message Part"

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


--------------010501000402020307030603--

From sm@resistor.net  Mon Jan 28 11:16:45 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED8A21F8696 for ; Mon, 28 Jan 2013 11:16:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 a-65CA2cQA-C for ; Mon, 28 Jan 2013 11:16:43 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9E721F8694 for ; Mon, 28 Jan 2013 11:16:43 -0800 (PST)
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 r0SJGW5t007209; Mon, 28 Jan 2013 11:16:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359400599; bh=3QAHHP++3kGQTbijtIBgIY92V064fSVWVkWipvUHurc=; h=Date:To:From:Subject:In-Reply-To:References; b=leS5tUfJnvu7JH8km2Y6C2qpKdujFf8vL3v+2L0gJ1iOeaHBKq6LK0HL762JGj7j5 IATatkmcSbbSuLMyFBPyuNlr8cRNwvbwjY1m/knxx7Yv0Pp1qnui76FmTPGhG6WYer 6gghgDPu46jRAt3dPvbpkNUZRhiJR3kEmbfBARFE=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1359400599; i=@resistor.net; bh=3QAHHP++3kGQTbijtIBgIY92V064fSVWVkWipvUHurc=; h=Date:To:From:Subject:In-Reply-To:References; b=iV8Z972d67hU9paShjFsiN0AXx7DS4m2w5T7aIphkXe9rIhvbnCyyMJrT7SC4QtWy 9Oqk4b998pyiiCvxTqrFRyHLd998OY5QbXicu2ttfKXeElj6PiNneg9JESRrmyXiN7 JoJGzbq2r5BvjEcBLU96s9jyan4q5P3ESomLEWf0=
Message-Id: <6.2.5.6.2.20130128104820.0a9afb08@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 28 Jan 2013 11:07:52 -0800
To: Salvatore Loreto , apps-discuss@ietf.org
From: SM 
In-Reply-To: <51067C1C.2050509@ericsson.com>
References: <51067C1C.2050509@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jan 2013 19:16:45 -0000

At 05:24 28-01-2013, Salvatore Loreto wrote:
>I would like to initiate a 2 weeks WG Last Call on
>draft-ietf-appsawg-acct-uri-02.txt ("The 'acct' URI Scheme")
>http://tools.ietf.org/id/draft-ietf-appsawg-acct-uri-02.txt

I took a quick look at the draft.  Shouldn't the draft define a 
registry for protocols that use the scheme?

Regards,
-sm 


From wmills@yahoo-inc.com  Mon Jan 28 11:23:19 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6477021F870E for ; Mon, 28 Jan 2013 11:23:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level: 
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[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 BBIfFmTDvnEq for ; Mon, 28 Jan 2013 11:23:18 -0800 (PST)
Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE9D21F86F6 for ; Mon, 28 Jan 2013 11:23:18 -0800 (PST)
Received: from GQ1-EX10-CAHT08.y.corp.yahoo.com (gq1-ex10-caht08.corp.gq1.yahoo.com [10.73.118.87]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r0SJMgQt055147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2013 11:22:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1359400963; bh=riwXDrvOC3TMLdQKWrS9vU1bFRdYz0uaUihUQWwjhLc=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=dCwK/m95FzYy8xoZ4Op+CS04xurh8TCdkf+Lhk7kVJSn5XpbmiP4jQWBXbrPHVxOA VEjMJ5KxQEtKMd0xn+2ivzzziNzj1Flvoh/EGSbGdR98eXyt+VtWM0Cv6X5/TcgpR1 jgqTPUi3XzrQZ5dan9NvG2FPKFpvHS5FktSryi/g=
Received: from GQ1-EX10-MB02.y.corp.yahoo.com ([fe80::4044:a0ab:236b:859]) by GQ1-EX10-CAHT08.y.corp.yahoo.com ([fe80::1da1:7b65:cb46:5de4%16]) with mapi id 14.02.0328.009; Mon, 28 Jan 2013 11:22:41 -0800
From: William Mills 
To: SM , Salvatore Loreto , "apps-discuss@ietf.org" 
Thread-Topic: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
Thread-Index: AQHN/YxThAP+9LZcF02NsXxgyeElzJhfHc4w
Date: Mon, 28 Jan 2013 19:22:41 +0000
Message-ID: <794576CB4DC5004FADDFC06E090A873D12BFC0BB@GQ1-EX10-MB02.y.corp.yahoo.com>
References: <51067C1C.2050509@ericsson.com> <6.2.5.6.2.20130128104820.0a9afb08@resistor.net>
In-Reply-To: <6.2.5.6.2.20130128104820.0a9afb08@resistor.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.72.165.52]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Milter-Version: master.31+4-gbc07cd5+
X-CLX-ID: 400963001
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jan 2013 19:23:19 -0000

I don't believe so, as I don't think a registry would serve a useful purpos=
e.  Applications supporting WebFinger service discovery for example may sup=
port it, but what would an app do when it sees multiple registered protocol=
s that support "acct:"?

Regards,

-bill

-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of SM
Sent: Monday, January 28, 2013 11:08 AM
To: Salvatore Loreto; apps-discuss@ietf.org
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-=
acct-uri-02

At 05:24 28-01-2013, Salvatore Loreto wrote:
>I would like to initiate a 2 weeks WG Last Call on=20
>draft-ietf-appsawg-acct-uri-02.txt ("The 'acct' URI Scheme")=20
>http://tools.ietf.org/id/draft-ietf-appsawg-acct-uri-02.txt

I took a quick look at the draft.  Shouldn't the draft define a registry fo=
r protocols that use the scheme?

Regards,
-sm=20

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

From sm@resistor.net  Mon Jan 28 12:29:09 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D52121F8625 for ; Mon, 28 Jan 2013 12:29:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 pBbGwzuu0MiU for ; Mon, 28 Jan 2013 12:29:08 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD6F21F865D for ; Mon, 28 Jan 2013 12:29:07 -0800 (PST)
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 r0SKT1N7016215; Mon, 28 Jan 2013 12:29:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359404945; bh=sJhoxzxyVPLoKMQFuTZEtEFdpC/KoIhqE4q5Pq0rweg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wwAqASJ7JW1PgdtxeZpWTP3U289H0XTgxJj7LexVQ3V+TB195Il38qZoz/xj5bLqw SE9XIHp7GRFMb7PPxJvdA2I1OG9vzAm406+RMcFYvBy1/xLN1hwaIfxJyvqRIotqon uzuLE648nFIDRJfRzjbAmsdRVgr4WIKR1tlFVxiU=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1359404945; i=@resistor.net; bh=sJhoxzxyVPLoKMQFuTZEtEFdpC/KoIhqE4q5Pq0rweg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dKgFTmh7iyLjVLDlCIEpkoI8goGUA2p2eOBIMGlKoAgroWkUOmJRI44CzX5J+w3Lz BvcfZNEsyT3sb8RyBUm13WnQZwIDbHfJIXsro8JcrB07RwmEGmYKhQjHd/a1jjVYfv IVkq1ctuLgT3S6qDmqNMCBHI1ziO1k0N+4W917x4=
Message-Id: <6.2.5.6.2.20130128120445.0a08ad70@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 28 Jan 2013 12:28:21 -0800
To: William Mills 
From: SM 
In-Reply-To: <794576CB4DC5004FADDFC06E090A873D12BFC0BB@GQ1-EX10-MB02.y.c orp.yahoo.com>
References: <51067C1C.2050509@ericsson.com> <6.2.5.6.2.20130128104820.0a9afb08@resistor.net> <794576CB4DC5004FADDFC06E090A873D12BFC0BB@GQ1-EX10-MB02.y.corp.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jan 2013 20:29:09 -0000

Hi Bill,
At 11:22 28-01-2013, William Mills wrote:
>I don't believe so, as I don't think a registry would serve a useful 
>purpose.  Applications supporting WebFinger service discovery for 
>example may support it, but what would an app do when it sees 
>multiple registered protocols that support "acct:"?

Good question.  This draft is basically the paperwork to get the 
"acct" scheme registered.  Based on what you mentioned about the 
draft might not qualify as a Proposed Standard.

Section 4.7 mentions that there aren't any interoperability 
considerations.  As a quick reaction I would say there would be 
interoperability issues when you have the same "identifier" used in 
different protocols to get different things.  If the application 
supports multiple protocols it would have to pick one of them to 
deference the URI.

Regards,
-sm 


From wmills@yahoo-inc.com  Mon Jan 28 12:43:23 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8987221F86FF for ; Mon, 28 Jan 2013 12:43:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level: 
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[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 ShRNXZZJlwcy for ; Mon, 28 Jan 2013 12:43:22 -0800 (PST)
Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by ietfa.amsl.com (Postfix) with ESMTP id A132221F86EC for ; Mon, 28 Jan 2013 12:43:21 -0800 (PST)
Received: from GQ1-EX10-CAHT07.y.corp.yahoo.com (gq1-ex10-caht07.corp.gq1.yahoo.com [10.73.118.86]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r0SKgvCI086862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 28 Jan 2013 12:42:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1359405778; bh=fMfHvsC1Ao3mEZ5lim1U8WpxsS0euOEoBJgz/ncEMBs=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=R7h88VyThKOOsR4b0iLw/FsJTNeGv4Sfip36SmgheqKDxrnpGN5h2fr1o9GlSP/4N 0P9/UM6xUiThbPs0A/WKtstO0kSlMJnC85JYmpB99Wt6+tXYKmR3H6UVHia6+RkdfW LFF3m//uzg9XLKGyoIB3yd6ZE7++5N50ntRtVUA4=
Received: from omp1067.mail.ne1.yahoo.com (98.138.226.166) by GQ1-EX10-CAHT07.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server id 14.2.328.9; Mon, 28 Jan 2013 12:42:56 -0800
Received: (qmail 5449 invoked by uid 1000); 28 Jan 2013 20:42:56 -0000
Received: (qmail 96482 invoked by uid 60001); 28 Jan 2013 20:42:56 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1359405776; bh=8ozvVIs3c63wI/GhTIDLAx8SDWiMZ5+GoPYQl6SMz0o=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aKkRqXUlo+rvsaJK9HXeGB1HgcVmiKBv0YHpw+8rdjT7PFZdnZJn5+IglJTEOy4Er3ZM8ZZfi8g3wHLLegbuIfWuDLaid6sp0pze4SKh8B9AnDnbXOY710hGpuUs/hp9cJhW5IKW1AlTEjk2opvwluwKdsj1biAhUYFcfSL/Fok=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=snake; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=pUu919xRtLd+hkQU3flJITvRcbzexpFu1nE3qj9rHmbShxekpGMWAXM6yAeY1hcH  ;
X-YMail-OSG: 0JV7P4QVM1krKDvxYCqk0XfeM_nKWni56ePkfp8k8_Lz4fJ di1XllGSB1kqQuFxB4WzIs2Z0MliusnQFaeAcpaOmhRyuDFXKRHpX5k2mbkN Mrus.w0f8d0UtReyaqzGhjpnoc11PPVNVz5bzY6D51aQyzz3Ins6Oktd.Otj U_CTI0ppslLNva_HPh4XedRJnnaycGg23f9xXQdbJkfI.314iKWaja.Vyw.f x5PGyyssl7CNBIN9uWQZmWQnc4M9ah03y9hU8fqDSc0ER0uMUezIKfCmbMkM rsWfktjHEcoC7lKffJvERBoz0x_TfKKLJNV6I_w2Hhk1QcgUrPLiYQCRne_. GBoaiQUC9tFeSuxVAR2_C4yxVSGijgVQ0ro3FasWiM.H4ipJzn17ZBOjoQDA xzZ1uzN0kKROoghB_hULAklyr1ArxVUnFXE573SOskpVLF3cn3.lLoswF3Ta 1E.oNNJ0sn61YHU3T.GX3
Received: from [209.131.62.113] by web125604.mail.ne1.yahoo.com via HTTP; Mon, 28 Jan 2013 12:42:56 PST
X-Rocket-MIMEInfo: 001.001, SXQncyBwb3NzaWJsZSB0byBoYXZlIGR1cGxpY2F0ZSBpbmRlbnRpZmllcnMgaW4gdGhlIHdvcmxkIGFzIGFjY3Q6IHN1cHBvcnRzICJsb2NhbCIgaWRlbnRpZmllcnMuwqAgQXMgb3Bwb3NlZCB0byBQcm9wb3NlZCBTdGFuZGFyZCBpcyB0aGlzIHRoZW4gaW5mb3JtYXRpb25hbD8KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJvbTogU00gPHNtQHJlc2lzdG9yLm5ldD4KVG86IFdpbGxpYW0gTWlsbHMgPHdtaWxsc0B5YWhvby1pbmMuY29tPiAKQ2M6IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZyABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.131.499
References: <51067C1C.2050509@ericsson.com> <6.2.5.6.2.20130128104820.0a9afb08@resistor.net> <794576CB4DC5004FADDFC06E090A873D12BFC0BB@GQ1-EX10-MB02.y.corp.yahoo.com> <6.2.5.6.2.20130128120445.0a08ad70@resistor.net>
Message-ID: <1359405776.94138.YahooMailNeo@web125604.mail.ne1.yahoo.com>
Date: Mon, 28 Jan 2013 12:42:56 -0800
From: Bill Mills 
To: SM 
In-Reply-To: <6.2.5.6.2.20130128120445.0a08ad70@resistor.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-685807438-1770047401-1359405776=:94138"
X-Milter-Version: master.31+4-gbc07cd5+
X-CLX-ID: 405778000
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Bill Mills 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jan 2013 20:43:23 -0000

---685807438-1770047401-1359405776=:94138
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

It's possible to have duplicate indentifiers in the world as acct: supports=
 "local" identifiers.=A0 As opposed to Proposed Standard is this then infor=
mational?=0A=0A=0A=0A________________________________=0AFrom: SM =0ATo: William Mills  =0ACc: apps-discuss@ietf=
.org =0ASent: Monday, January 28, 2013 12:28 PM=0ASubject: RE: [apps-discus=
s] Working Group Last Call for draft-ietf-appsawg-acct-uri-02=0A=0AHi Bill,=
=0AAt 11:22 28-01-2013, William Mills wrote:=0A> I don't believe so, as I d=
on't think a registry would serve a useful purpose.=A0 Applications support=
ing WebFinger service discovery for example may support it, but what would =
an app do when it sees multiple registered protocols that support "acct:"?=
=0A=0AGood question.=A0 This draft is basically the paperwork to get the "a=
cct" scheme registered.=A0 Based on what you mentioned about the draft migh=
t not qualify as a Proposed Standard.=0A=0ASection 4.7 mentions that there =
aren't any interoperability considerations.=A0 As a quick reaction I would =
say there would be interoperability issues when you have the same "identifi=
er" used in different protocols to get different things.=A0 If the applicat=
ion supports multiple protocols it would have to pick one of them to defere=
nce the URI.=0A=0ARegards,=0A-sm 
---685807438-1770047401-1359405776=:94138
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


It's possible to have duplicate indentifi=
ers in the world as acct: supports "local" identifiers.  As opposed to=
 Proposed Standard is this then informational?











From:=
 SM <sm@resistor.net>
To: William Mills <wmills@yahoo-inc.com> 
Cc: apps-discuss@ietf.org 
Sent: Monday, January 28, 2013 12=
:28 PM
Subject: RE: [app=
s-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02

Hi Bill,
At 11:22 28-01-2013, William Mills wrote:
>=
; I don't believe so, as I don't think a registry would serve a useful purp=
ose. 
 Applications supporting WebFinger service discovery for example may suppor=
t it, but what would an app do when it sees multiple registered protocols t=
hat support "acct:"?

Good question.  This draft is basically th=
e paperwork to get the "acct" scheme registered.  Based on what you me=
ntioned about the draft might not qualify as a Proposed Standard.

Se=
ction 4.7 mentions that there aren't any interoperability considerations.&n=
bsp; As a quick reaction I would say there would be interoperability issues=
 when you have the same "identifier" used in different protocols to get dif=
ferent things.  If the application supports multiple protocols it woul=
d have to pick one of them to deference the URI.

Regards,
-sm 


---685807438-1770047401-1359405776=:94138--

From sm@resistor.net  Mon Jan 28 13:37:22 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729E321F854E for ; Mon, 28 Jan 2013 13:37:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 KR-43Yu7zcAU for ; Mon, 28 Jan 2013 13:37:21 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5289621F854B for ; Mon, 28 Jan 2013 13:37:21 -0800 (PST)
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 r0SLbGPc027830; Mon, 28 Jan 2013 13:37:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359409040; bh=HblA80I0lhQojlAXUqjNRVfw2sQMj+pfSbx+50ezJ3Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=33t8d7FjXnD96KV40BvUV8ht1sNRxBYqSiYHc4KOw3SHX2EQTzng72NrJU8WgWyr8 YS/acQics5NrI6KAiVpnzKxISQgIReqHhqsqwBt2BEhw0UMfnW1glEQ/fmezrr5l/r 9Ai0lxzD8DbdKDcdXiNgR13YDjYwDNTDxkNLNGYI=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1359409040; i=@resistor.net; bh=HblA80I0lhQojlAXUqjNRVfw2sQMj+pfSbx+50ezJ3Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QdEy8nIFHCc44vCeh0vMxEkOw50DC602xKrBjbm7yMOgFJgaiqdzikq/27uG4axip ig5VNNku9yG1FoOeYUcC8RXAQ4TOs2DSjYfbJwHYhj3scqlnu1EUf9SwTyNqwlIEj0 cCJWngEoAa/8nI48DF2Nkg9iCXLroYhcv84mKsUQ=
Message-Id: <6.2.5.6.2.20130128132446.09bca850@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 28 Jan 2013 13:36:04 -0800
To: Bill Mills 
From: SM 
In-Reply-To: <1359405776.94138.YahooMailNeo@web125604.mail.ne1.yahoo.com >
References: <51067C1C.2050509@ericsson.com> <6.2.5.6.2.20130128104820.0a9afb08@resistor.net> <794576CB4DC5004FADDFC06E090A873D12BFC0BB@GQ1-EX10-MB02.y.corp.yahoo.com> <6.2.5.6.2.20130128120445.0a08ad70@resistor.net> <1359405776.94138.YahooMailNeo@web125604.mail.ne1.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jan 2013 21:37:22 -0000

Hi Bill,
At 12:42 28-01-2013, Bill Mills wrote:
>It's possible to have duplicate indentifiers in the world as acct: 
>supports "local" identifiers.  As opposed to Proposed Standard is 
>this then informational?

Yes.  I flagged it as an issue as it is easier if it is considered now.

Regards,
-sm 


From daniel@pocock.com.au  Mon Jan 28 14:01:24 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E32121F8739 for ; Mon, 28 Jan 2013 14:01:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJPaExWsWUXr for ; Mon, 28 Jan 2013 14:01:23 -0800 (PST)
Received: from mail1.trendhosting.net (mail1.trendhosting.net [195.8.117.5]) by ietfa.amsl.com (Postfix) with ESMTP id 889AC21F8713 for ; Mon, 28 Jan 2013 14:01:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail1.trendhosting.net (Postfix) with ESMTP id B7F89150B7 for ; Mon, 28 Jan 2013 22:01:21 +0000 (GMT)
Received: from mail1.trendhosting.net ([127.0.0.1]) by localhost (thp003.trendhosting.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yo5T4pEjt4cX for ; Mon, 28 Jan 2013 22:01:18 +0000 (GMT)
Message-ID: <5106F52D.3070101@pocock.com.au>
Date: Mon, 28 Jan 2013 23:01:17 +0100
From: Daniel Pocock 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <51046708.2040806@pocock.com.au>
In-Reply-To: <51046708.2040806@pocock.com.au>
X-Enigmail-Version: 1.4.1
X-Forwarded-Message-Id: <51046708.2040806@pocock.com.au>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: [apps-discuss] Fwd: draft-ietf-appsawg-acct-uri-02 Re: [Operators] Protocol agnostic URI for voice or video call?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jan 2013 22:02:40 -0000

Just forwarding my feedback on draft-ietf-appsawg-acct-uri - see
comments further below

The prefix `acct:' may not be the right solution for what was intended
in my original query on xmpp-operators, but if it is not suitable, then
that may imply that some other prefix is also needed in addition to acct:

For example, rtc:daniel@pocock.com.au could be defined in another draft
to imply any type of real-time communication (im, sip or xmpp) perhaps?




-------- Original Message --------
Subject: Re: [Operators] Protocol agnostic URI for voice or video call?
Date: Sun, 27 Jan 2013 00:30:16 +0100
From: Daniel Pocock 
To: Mikko Lehto 
CC: XMPP Operators Group , psaintan@cisco.com



On 26/01/13 22:03, Mikko Lehto wrote:
> 2013-01-07 (Mon) 15:16 UTC +0100  Daniel Pocock :
> 
>> However, im: implies text chat only.  Are there equivalent prefixes to suggest voice and/or video sessions, and is there any generic prefix to suggest any arbitrary possibility (including smtp) at the caller's discretion?
> 
> Hi Daniel
> 
> Are you aware of acct: URI scheme¹ ?
> Maybe that can be utilized.
> 
> [1] draft-ietf-appsawg-acct-uri


Thanks for bringing that to my attention, I think it almost addresses
what I had in mind

s4.7 interoperability doesn't mention the fact that xmpp: and sip: have
slightly different sets of permitted characters for the user@ portion of
a URI.  s4.3 could probably be extended to define a subset that is
compatible with mailto:, xmpp: and sip: all at once



From wmills@yahoo-inc.com  Mon Jan 28 14:35:38 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192EB21F86F5 for ; Mon, 28 Jan 2013 14:35:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level: 
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[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 r713aLjaqAGo for ; Mon, 28 Jan 2013 14:35:37 -0800 (PST)
Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0AF21F86D8 for ; Mon, 28 Jan 2013 14:35:28 -0800 (PST)
Received: from BF1-EX10-CAHT01.y.corp.yahoo.com (bf1-ex10-caht01.corp.bf1.yahoo.com [10.74.209.56]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r0SMYtHr031747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 28 Jan 2013 14:34:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1359412495; bh=ZlMWjKpsTl9tLYILeRHQz/SejFpt0WZfz3SEQWm0H70=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To: MIME-Version:Content-Type; b=beLyZi9Yfko+i50txlD+RWtfjqFPBsYWlnKxpoVskCV7NjQURhg3BP3cX7C8N/gbY ++hh0Ktb8riFNNd4Tsnaw9GlNuvGalqDejVZLBVa0QxpHL8G1vJDE2ThhQVCt93a3c fAYDEw3oFWzmhLInBrriThQ6OKP0DvO8DPpqpt6A=
Received: from omp1040.mail.ne1.yahoo.com (98.138.89.248) by BF1-EX10-CAHT01.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server id 14.2.328.9; Mon, 28 Jan 2013 17:34:54 -0500
Received: (qmail 86116 invoked by uid 1000); 28 Jan 2013 22:34:54 -0000
Received: (qmail 80025 invoked by uid 60001); 28 Jan 2013 22:34:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1359412494; bh=jbJaiKvcnpQZ49BriaPDGL9wiKUNZdbetyUX0VOCEvA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=KTkBNZ2t3JmsT/2G/XqT0eBpqMgks3ywBsWWcZjJ69wAY6MXBwm7IY0QhD4k0IT/rs6X+wj/1JA/VCmVu5ltvUlVOoNuSo4pFWWn+xgGc45lDdPj3VNCNoM/QjG4UAuDW3k6uWY9NkuIpSTLeHNiopvs3X2NToYwVsZGFL7ulOk=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=snake; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=iquodbGfYwixikXW2qAruVMpEWRbi/lswCjNaKkDW9dmPCMlarhWIv5GTWiHghFN  ;
X-YMail-OSG: q20ERsIVM1mSaPTl79PZUpEuNmPehw1CQ17Y6Ad4SgaANWg rjqnnwFk2_f63ab86VOaC_g41UQTGM5jt8di6dY2KtEnEhAnzulCnbJRPr2i xBOAwzKlA8tMnTB9S7QF3lHi5Yv.Sc5ke3TtHaIUO3p5URz19fc_DNh9iFCi 67kbwLkk9b8beG5Z9NofznQXOTBRf0rhPuDe.PtEiaRZktG4ViIQvZ47I7Nk rlAiU3untGeU46gMUtPOyc1fhCes.owuESxaPZEBTO5N60SDzQY2.RacErxr HjGt8xxu.RJEUHou66LajlGBfURVCrWbaUbbHBNvCMz9DtA46.cU7b9hWxpP eZzsCcf9g9EF5hmd877YMzB_2MbjluIPFxqE.DGcGw7esguJDinwovgvXGRe iOZw_JjxWlHUZl9FpwUhQJX2HVB5GVS51_0YXDgJtwaogmfpZP87aoM3bue9 GE9E.n6bEh5O5wdFvww--
Received: from [209.131.62.113] by web125606.mail.ne1.yahoo.com via HTTP; Mon, 28 Jan 2013 14:34:54 PST
X-Rocket-MIMEInfo: 001.001, SSB0aGluayB5b3UnZCBuZWVkIHRvIGhhdmUgcnRjOnhtcHA6ZGFuaWVsQHBvY29jay5jb20uYXUsIG9yIHdlcmUgeW91IHRoaW5raW5nIHRoYXQgdGhlcmUgd291bGQgYmUgYSB1c2VyIHNwZWNpZmljIGxvb2t1cCB0byBkZXRlcm1pbmUgd2hhdCBSVEMgcHJvdG9jb2wgYSB1c2VyIGFkdmVydGlzZXM_CgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkZyb206IERhbmllbCBQb2NvY2sgPGRhbmllbEBwb2NvY2suY29tLmF1PgpUbzogYXBwcy1kaXNjdXNzQGlldGYub3JnIApTZW50OiBNb25kYXkBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.131.499
References: <51046708.2040806@pocock.com.au> <5106F52D.3070101@pocock.com.au>
Message-ID: <1359412494.64276.YahooMailNeo@web125606.mail.ne1.yahoo.com>
Date: Mon, 28 Jan 2013 14:34:54 -0800
From: Bill Mills 
To: Daniel Pocock , "apps-discuss@ietf.org" 
In-Reply-To: <5106F52D.3070101@pocock.com.au>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="607277540-512054399-1359412494=:64276"
X-Milter-Version: master.31+4-gbc07cd5+
X-CLX-ID: 412495004
Subject: Re: [apps-discuss] Fwd: draft-ietf-appsawg-acct-uri-02 Re: [Operators] Protocol agnostic URI for voice or video call?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Bill Mills 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jan 2013 22:35:38 -0000

--607277540-512054399-1359412494=:64276
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I think you'd need to have rtc:xmpp:daniel@pocock.com.au, or were you think=
ing that there would be a user specific lookup to determine what RTC protoc=
ol a user advertises?=0A=0A=0A=0A________________________________=0AFrom: D=
aniel Pocock =0ATo: apps-discuss@ietf.org =0ASent: Mo=
nday, January 28, 2013 2:01 PM=0ASubject: [apps-discuss] Fwd: draft-ietf-ap=
psawg-acct-uri-02 Re: [Operators] Protocol agnostic URI for voice or video =
call?=0A=0A=0A=0AJust forwarding my feedback on draft-ietf-appsawg-acct-uri=
 - see=0Acomments further below=0A=0AThe prefix `acct:' may not be the righ=
t solution for what was intended=0Ain my original query on xmpp-operators, =
but if it is not suitable, then=0Athat may imply that some other prefix is =
also needed in addition to acct:=0A=0AFor example, rtc:daniel@pocock.com.au=
 could be defined in another draft=0Ato imply any type of real-time communi=
cation (im, sip or xmpp) perhaps?=0A=0A=0A=0A=0A-------- Original Message -=
-------=0ASubject: Re: [Operators] Protocol agnostic URI for voice or video=
 call?=0ADate: Sun, 27 Jan 2013 00:30:16 +0100=0AFrom: Daniel Pocock =0ATo: Mikko Lehto =0ACC: XMPP Operators Gr=
oup , psaintan@cisco.com=0A=0A=0A=0AOn 26/01/13 22:03, =
Mikko Lehto wrote:=0A> 2013-01-07 (Mon) 15:16 UTC +0100=A0 Daniel Pocock :=0A> =0A>> However, im: implies text chat only.=A0 Are=
 there equivalent prefixes to suggest voice and/or video sessions, and is t=
here any generic prefix to suggest any arbitrary possibility (including smt=
p) at the caller's discretion?=0A> =0A> Hi Daniel=0A> =0A> Are you aware of=
 acct: URI scheme=B9 ?=0A> Maybe that can be utilized.=0A> =0A> [1] draft-i=
etf-appsawg-acct-uri=0A=0A=0AThanks for bringing that to my attention, I th=
ink it almost addresses=0Awhat I had in mind=0A=0As4.7 interoperability doe=
sn't mention the fact that xmpp: and sip: have=0Aslightly different sets of=
 permitted characters for the user@ portion of=0Aa URI.=A0 s4.3 could proba=
bly be extended to define a subset that is=0Acompatible with mailto:, xmpp:=
 and sip: all at once=0A=0A=0A_____________________________________________=
__=0Aapps-discuss mailing list=0Aapps-discuss@ietf.org=0Ahttps://www.ietf.o=
rg/mailman/listinfo/apps-discuss
--607277540-512054399-1359412494=:64276
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


I think you'd need to have rtc:xmpp:daniel@pocock.com.au, or were you thinking that t=
here would be a user specific lookup to determine what RTC protocol a user =
advertises?











From:=
 Daniel Pocock <daniel@pocock.com.au>
To: apps-discuss@ietf.org 
Sent: Monday, January 28, 2013 2:01 PMSubject: [apps-discuss] Fw=
d: draft-ietf-appsawg-acct-uri-02 Re: [Operators] Protocol agnostic URI for=
 voice or video call?



Just forwarding my feedba=
ck on draft-ietf-appsawg-acct-uri - see
comments further below

Th=
e prefix `acct:' may not be the right solution for what was intended
in =
my original
 query on xmpp-operators, but if it is not suitable, then
that may imply=
 that some other prefix is also needed in addition to acct:

For exam=
ple, rtc:daniel@pocock.com.au could be defin=
ed in another draft
to imply any type of real-time communication (im, si=
p or xmpp) perhaps?




-------- Original Message --------Subject: Re: [Operators] Protocol agnostic URI for voice or video call?Date: Sun, 27 Jan 2013 00:30:16 +0100
From: Daniel Pocock <da=
niel@pocock.com.au>
To: Mikko Lehto <mslehto@iki.fi>
CC: XM=
PP Operators Group <operators@xmpp.org>, psaintan@cisco.com


On 26/01/13 22:03, Mikko Lehto wrote:
> 2013-01-07 (Mon) 15:16 UTC =
+0100  Daniel Pocock <daniel@pocock.com.au>:
> >> However, im: implies text chat only.  Are there equivalent =
prefixes to suggest voice and/or video sessions, and is there any generic p=
refix to suggest any arbitrary possibility (including smtp) at the caller's=
 discretion?
> 
> Hi Daniel
> 
> Are you aware of a=
cct: URI scheme=B9 ?
> Maybe that can be utilized.
> 
> [=
1] draft-ietf-appsawg-acct-uri


Thanks for bringing that to my at=
tention, I think it almost addresses
what I had in mind

s4.7 inte=
roperability doesn't mention the fact that xmpp: and sip: have
slightly =
different sets of permitted characters for the user@ portion of
a
 URI.  s4.3 could probably be extended to define a subset that is
c=
ompatible with mailto:, xmpp: and sip: all at once


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



--607277540-512054399-1359412494=:64276--

From stpeter@stpeter.im  Mon Jan 28 14:42:10 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E6021F85B0 for ; Mon, 28 Jan 2013 14:42:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 Iv0eQMmhwrNe for ; Mon, 28 Jan 2013 14:42:09 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D087B21F8540 for ; Mon, 28 Jan 2013 14:42:08 -0800 (PST)
Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EE5264004E; Mon, 28 Jan 2013 15:48:20 -0700 (MST)
Message-ID: <5106FEC2.8050606@stpeter.im>
Date: Mon, 28 Jan 2013 15:42:10 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Daniel Pocock 
References: <51046708.2040806@pocock.com.au> <5106F52D.3070101@pocock.com.au>
In-Reply-To: <5106F52D.3070101@pocock.com.au>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: draft-ietf-appsawg-acct-uri-02 Re: [Operators] Protocol agnostic URI for voice or video call?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jan 2013 22:42:10 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/28/13 3:01 PM, Daniel Pocock wrote:
> 
> 
> Just forwarding my feedback on draft-ietf-appsawg-acct-uri - see 
> comments further below
> 
> The prefix `acct:' may not be the right solution for what was
> intended in my original query on xmpp-operators, but if it is not
> suitable, then that may imply that some other prefix is also needed
> in addition to acct:
> 
> For example, rtc:daniel@pocock.com.au could be defined in another
> draft to imply any type of real-time communication (im, sip or
> xmpp) perhaps?

Actually, both im: and pres: are of the form you're thinking about
(they are "meta-URIs", if you will, which could trigger interaction
via some particular protocol like SIP or XMPP). However, they are
rarely used perhaps because the resolution process is somewhat complex
(see RFC 3859, RFC 3860, and RFC 3861), so I don't think they provide
a good model to follow.

Peter

> 
> 
> 
> 
> -------- Original Message -------- Subject: Re: [Operators]
> Protocol agnostic URI for voice or video call? Date: Sun, 27 Jan
> 2013 00:30:16 +0100 From: Daniel Pocock  To:
> Mikko Lehto  CC: XMPP Operators Group
> , psaintan@cisco.com
> 
> 
> 
> On 26/01/13 22:03, Mikko Lehto wrote:
>> 2013-01-07 (Mon) 15:16 UTC +0100  Daniel Pocock
>> :
>> 
>>> However, im: implies text chat only.  Are there equivalent
>>> prefixes to suggest voice and/or video sessions, and is there
>>> any generic prefix to suggest any arbitrary possibility
>>> (including smtp) at the caller's discretion?
>> 
>> Hi Daniel
>> 
>> Are you aware of acct: URI scheme¹ ? Maybe that can be utilized.
>> 
>> [1] draft-ietf-appsawg-acct-uri
> 
> 
> Thanks for bringing that to my attention, I think it almost
> addresses what I had in mind
> 
> s4.7 interoperability doesn't mention the fact that xmpp: and sip:
> have slightly different sets of permitted characters for the user@
> portion of a URI.  s4.3 could probably be extended to define a
> subset that is compatible with mailto:, xmpp: and sip: all at once
> 
> 
> _______________________________________________ apps-discuss
> mailing list apps-discuss@ietf.org 
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEG/sIACgkQNL8k5A2w/vxSUACeLIHYkGXSh47XA7ADRbKf6LF9
yY8Ani4OymgzshVliSX4Nji2lOIx7Biv
=AHBk
-----END PGP SIGNATURE-----

From daniel@pocock.com.au  Mon Jan 28 14:53:49 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA36C21E8039 for ; Mon, 28 Jan 2013 14:53:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.373
X-Spam-Level: 
X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226,  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 3dO-LF3N0OG5 for ; Mon, 28 Jan 2013 14:53:48 -0800 (PST)
Received: from mail1.trendhosting.net (mail1.trendhosting.net [195.8.117.5]) by ietfa.amsl.com (Postfix) with ESMTP id EC6BA21E8030 for ; Mon, 28 Jan 2013 14:53:47 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail1.trendhosting.net (Postfix) with ESMTP id D5310150B7; Mon, 28 Jan 2013 22:53:46 +0000 (GMT)
Received: from mail1.trendhosting.net ([127.0.0.1]) by localhost (thp003.trendhosting.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FnB-VRBYwQZR; Mon, 28 Jan 2013 22:53:43 +0000 (GMT)
Message-ID: <51070176.1020008@pocock.com.au>
Date: Mon, 28 Jan 2013 23:53:42 +0100
From: Daniel Pocock 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11
MIME-Version: 1.0
To: Peter Saint-Andre 
References: <51046708.2040806@pocock.com.au> <5106F52D.3070101@pocock.com.au> <5106FEC2.8050606@stpeter.im>
In-Reply-To: <5106FEC2.8050606@stpeter.im>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: draft-ietf-appsawg-acct-uri-02 Re: [Operators] Protocol agnostic URI for voice or video call?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jan 2013 22:53:49 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 28/01/13 23:42, Peter Saint-Andre wrote:
> On 1/28/13 3:01 PM, Daniel Pocock wrote:
> 
> 
>> Just forwarding my feedback on draft-ietf-appsawg-acct-uri - see
>>  comments further below
> 
>> The prefix `acct:' may not be the right solution for what was 
>> intended in my original query on xmpp-operators, but if it is
>> not suitable, then that may imply that some other prefix is also
>> needed in addition to acct:
> 
>> For example, rtc:daniel@pocock.com.au could be defined in
>> another draft to imply any type of real-time communication (im,
>> sip or xmpp) perhaps?
> 
> Actually, both im: and pres: are of the form you're thinking about 
> (they are "meta-URIs", if you will, which could trigger
> interaction via some particular protocol like SIP or XMPP).
> However, they are rarely used perhaps because the resolution
> process is somewhat complex (see RFC 3859, RFC 3860, and RFC 3861),
> so I don't think they provide a good model to follow.
> 


I agree it is not easy, but from an end-user perspective, having a
single omni-URI (omni:stpeter@stpeter.im ?) has very compelling
ease-of-use benefits.

In the wild, my Lumicall implementation hunts for mailto: addresses in
your phone and if their domains have boilerplate SRV records (e.g.
_sips._tcp.example.org), assumes the full email address
mailto:user@example.org can be adapted to sip:user@example.org - most
likely it will check for NAPTR records too in the near future, and
offer xmpp: with the same paradigm.


http://www.lumicall.org has a brief demo video deducing
sip:bob@lumicall.org from the mailto: address



> Peter
> 
> 
> 
> 
> 
>> -------- Original Message -------- Subject: Re: [Operators] 
>> Protocol agnostic URI for voice or video call? Date: Sun, 27 Jan 
>> 2013 00:30:16 +0100 From: Daniel Pocock 
>> To: Mikko Lehto  CC: XMPP Operators Group 
>> , psaintan@cisco.com
> 
> 
> 
>> On 26/01/13 22:03, Mikko Lehto wrote:
>>> 2013-01-07 (Mon) 15:16 UTC +0100  Daniel Pocock 
>>> :
>>> 
>>>> However, im: implies text chat only.  Are there equivalent 
>>>> prefixes to suggest voice and/or video sessions, and is
>>>> there any generic prefix to suggest any arbitrary
>>>> possibility (including smtp) at the caller's discretion?
>>> 
>>> Hi Daniel
>>> 
>>> Are you aware of acct: URI scheme¹ ? Maybe that can be
>>> utilized.
>>> 
>>> [1] draft-ietf-appsawg-acct-uri
> 
> 
>> Thanks for bringing that to my attention, I think it almost 
>> addresses what I had in mind
> 
>> s4.7 interoperability doesn't mention the fact that xmpp: and
>> sip: have slightly different sets of permitted characters for the
>> user@ portion of a URI.  s4.3 could probably be extended to
>> define a subset that is compatible with mailto:, xmpp: and sip:
>> all at once
> 
> 
>> _______________________________________________ apps-discuss 
>> mailing list apps-discuss@ietf.org 
>> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJRBwF2AAoJEOm1uwJp1aqDEQoQAIpN/KdpRGrSgL/skIH29buU
X02LCwwvKglFw+BHwEec5ysGFFBv2fuLn7uVG9pQuL34A/l5w0vNTWj0i3bp77kQ
WHvWqGQlzFU+Abcsgnf+C7E7OGwSvhJwTSlfZyEHauiz9cKqg4xkjEilPj5NKyZX
RMV6QYMRFhPii9gIsiR1N0KaATdPFK7go1mvWfFZ0Ez6m7GA3YoOqsf0P13QGNpw
KDZEu7pKRTI4SZAyuVXg3QhOFVmdVoeq2vz3Em6LVyOWGeWpsA9Sdknri0/yfhTm
vrUAu6ZkDlgFXHPW2LHCLqRiSZjgngjNNNG/bu8mxKXpXfQwTUnqu4gK2m1bwmaw
LPCdS92hF42c/CSPSJS0yvWyKIqStH7pZDXRoezwQqdErRoMRFk5lRQ2Hk3LCfIb
MvqAIey5jwagd8L7I/3rQiJ2PTetAmaNUczC6srrEJCBwdhA3cPQKpWFxMKAqac+
FA/Zv83aL1LkFhSzdqqHk/zAMdla3NTQpD638omYO1XywGrHX8Ij72D2ii9+gP6y
u647PvyCvA76enVWQt6rGFy8wlq0ORpZCaCIXC38DZHOYZy/maR9Olhle0y552st
scA7u4dqBJouryeXmKDjTUKcpxVSsB8WFUriWFo9q/tRpgjkztLOEBpP5XkMYB9X
Ap5YUE7MoKYIpedcE+cs
=3zuO
-----END PGP SIGNATURE-----

From superuser@gmail.com  Mon Jan 28 15:04:50 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62AB21F8475 for ; Mon, 28 Jan 2013 15:04:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.466
X-Spam-Level: 
X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 U5xS-IQtWulo for ; Mon, 28 Jan 2013 15:04:50 -0800 (PST)
Received: from mail-we0-x22e.google.com (we-in-x022e.1e100.net [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2358621F8477 for ; Mon, 28 Jan 2013 15:04:49 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id r6so1873096wey.5 for ; Mon, 28 Jan 2013 15:04:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=h+gDXR50QNcZdE7EvPk8tvjDTqzL+0TgAXSZ0HsSDns=; b=g9RHEBZVWjDTDunLtv5yhdodPBmw4wpv0I8al0M6hKkzY8tY/miG0qoEcGOwRsuoqV ZUCsrkGAUYsU6g7Q7NwwkI4QSeeNXY53d4iuF431cAJwfyCuT+FNmL80bhYGDIOK2SYe kiAhdxy/BlZpWvbr2Y3571Qa1mjpy9LBZ5zawKZHeKZcyTOFe7OHy6+/snQfgcXniWO5 AQMBmPmia1ZR2jJSTjN9H4pvy6HatoLYvKA6rTb0d3c0x2EZ7KqW22vTPEhfoGFIhoEs HExhLrigbyes/nLOMpyVf8kjtxLTuoceKo46l/FDXQckXt2rx6y3tKzrCSr58r97J7TL 2uaQ==
MIME-Version: 1.0
X-Received: by 10.180.86.36 with SMTP id m4mr12458581wiz.5.1359414289279; Mon, 28 Jan 2013 15:04:49 -0800 (PST)
Received: by 10.180.164.43 with HTTP; Mon, 28 Jan 2013 15:04:48 -0800 (PST)
In-Reply-To: <6.2.5.6.2.20130128120445.0a08ad70@resistor.net>
References: <51067C1C.2050509@ericsson.com> <6.2.5.6.2.20130128104820.0a9afb08@resistor.net> <794576CB4DC5004FADDFC06E090A873D12BFC0BB@GQ1-EX10-MB02.y.corp.yahoo.com> <6.2.5.6.2.20130128120445.0a08ad70@resistor.net>
Date: Mon, 28 Jan 2013 15:04:48 -0800
Message-ID: 
From: "Murray S. Kucherawy" 
To: SM 
Content-Type: multipart/alternative; boundary=f46d0442859cd0a99604d4614d08
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jan 2013 23:04:50 -0000

--f46d0442859cd0a99604d4614d08
Content-Type: text/plain; charset=ISO-8859-1

SM,

Can you please elaborate on your point about qualification as a PS?

-MSK


On Mon, Jan 28, 2013 at 12:28 PM, SM  wrote:

> Hi Bill,
>
> At 11:22 28-01-2013, William Mills wrote:
>
>> I don't believe so, as I don't think a registry would serve a useful
>> purpose.  Applications supporting WebFinger service discovery for example
>> may support it, but what would an app do when it sees multiple registered
>> protocols that support "acct:"?
>>
>
> Good question.  This draft is basically the paperwork to get the "acct"
> scheme registered.  Based on what you mentioned about the draft might not
> qualify as a Proposed Standard.
>
> Section 4.7 mentions that there aren't any interoperability
> considerations.  As a quick reaction I would say there would be
> interoperability issues when you have the same "identifier" used in
> different protocols to get different things.  If the application supports
> multiple protocols it would have to pick one of them to deference the URI.
>
>
> Regards,
> -sm
> ______________________________**_________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/**listinfo/apps-discuss
>

--f46d0442859cd0a99604d4614d08
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


SM,

Can you please elaborate on your poi=
nt about qualification as a PS?

-MSK


On Mon, Jan 28, 2013 at 12:28 PM, S=
M <sm@resistor.net> wrote:


Hi Bill,


At 11:22 28-01-2013, William Mills wrote:



I don't believe so, as I don't think a registry would serve a usefu=
l purpose. =A0Applications supporting WebFinger service discovery for examp=
le may support it, but what would an app do when it sees multiple registere=
d protocols that support "acct:"?






Good question. =A0This draft is basically the paperwork to get the "ac=
ct" scheme registered. =A0Based on what you mentioned about the draft =
might not qualify as a Proposed Standard.



Section 4.7 mentions that there aren't any interoperability considerati=
ons. =A0As a quick reaction I would say there would be interoperability iss=
ues when you have the same "identifier" used in different protoco=
ls to get different things. =A0If the application supports multiple protoco=
ls it would have to pick one of them to deference the URI.






Regards,

-sm 

_______________________________________________

apps-discuss mailing list

apps-discuss@iet=
f.org

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





--f46d0442859cd0a99604d4614d08--

From sm@resistor.net  Mon Jan 28 16:10:25 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F4911E8099 for ; Mon, 28 Jan 2013 16:10:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 attTz2AWv3KT for ; Mon, 28 Jan 2013 16:10:23 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFB711E8097 for ; Mon, 28 Jan 2013 16:10:22 -0800 (PST)
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 r0T0AE6p014838; Mon, 28 Jan 2013 16:10:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359418218; bh=Fr0xzDOwrkTcodu0HugnLxbMkQIWmFovLieFA8sMchA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sEBawG36T4Tk62fM3yxU9vca49QwDcAFZypiWuMq+zZblCOmdhERiANUDRIIRST8Q Z71aarVDgT5YEUiLX6TZ1mktRvkKCb4Pm/JJtJP4iiV9LPGT6+WkJTXfChIp5k1Ks8 1DOMr4t2ec624k7DqlPoCiFM4tFkZIt0a0NvxXgY=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1359418218; i=@resistor.net; bh=Fr0xzDOwrkTcodu0HugnLxbMkQIWmFovLieFA8sMchA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FcXeyTUgsCqwPTn0LSU2ND++E8EmGWONXgGRyOwDmYebkhrXCkGeRWp9mkMHEBBmA KY1klByMBpKF6DThElENQ1oHnNXRkKztrtZX51bf7LNpzpkN931gXjpvN30jldWicz /eEIE8k2yWxtk3adRD1Ed0WWCj2ceXpvRVkW0494=
Message-Id: <6.2.5.6.2.20130128155212.0a1841d0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 28 Jan 2013 16:07:00 -0800
To: "Murray S. Kucherawy" 
From: SM 
In-Reply-To: 
References: <51067C1C.2050509@ericsson.com> <6.2.5.6.2.20130128104820.0a9afb08@resistor.net> <794576CB4DC5004FADDFC06E090A873D12BFC0BB@GQ1-EX10-MB02.y.corp.yahoo.com> <6.2.5.6.2.20130128120445.0a08ad70@resistor.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 00:10:25 -0000

Hi Murray,
At 15:04 28-01-2013, Murray S. Kucherawy wrote:
>Can you please elaborate on your point about qualification as a PS?

There is an AppsDir review from Tim Bray about a previous scheme at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05435.html 
The issue may be different here.  I'll describe Proposed Standard as 
when interoperability is necessary.  I don't feel strongly about this.

Regards,
-sm 


From stpeter@stpeter.im  Mon Jan 28 17:26:35 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD14D21E805E for ; Mon, 28 Jan 2013 17:26:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 U879MdA5dKk2 for ; Mon, 28 Jan 2013 17:26:34 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C5C2021E805A for ; Mon, 28 Jan 2013 17:26:34 -0800 (PST)
Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 40E1C4004E; Mon, 28 Jan 2013 18:32:47 -0700 (MST)
Message-ID: <5107254F.6040401@stpeter.im>
Date: Mon, 28 Jan 2013 18:26:39 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: SM 
References: <51067C1C.2050509@ericsson.com> <6.2.5.6.2.20130128104820.0a9afb08@resistor.net> <794576CB4DC5004FADDFC06E090A873D12BFC0BB@GQ1-EX10-MB02.y.corp.yahoo.com> <6.2.5.6.2.20130128120445.0a08ad70@resistor.net>
In-Reply-To: <6.2.5.6.2.20130128120445.0a08ad70@resistor.net>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 01:26:35 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/28/13 1:28 PM, SM wrote:
> Hi Bill, At 11:22 28-01-2013, William Mills wrote:
>> I don't believe so, as I don't think a registry would serve a
>> useful purpose.  Applications supporting WebFinger service
>> discovery for example may support it, but what would an app do
>> when it sees multiple registered protocols that support "acct:"?
> 
> Good question.  This draft is basically the paperwork to get the
> "acct" scheme registered.  Based on what you mentioned about the
> draft might not qualify as a Proposed Standard.

I don't follow your logic there.

> Section 4.7 mentions that there aren't any interoperability 
> considerations.  As a quick reaction I would say there would be 
> interoperability issues when you have the same "identifier" used
> in different protocols to get different things.

That's not interoperability, that's multi-functionality. :-)

So let's say that we have lots of protocols using acct as a parameter
in various REST-based protocols...

a. WebFinger
http://example.com
  /.well-known/webfinger?resource=acct%3Abob%40example.com

b. mythical SendMessage protocol
http://example.com
  /.well-known/msg?resource=acct%3Abob%40example.com

c. Daniel Pocock's uber-RTC thingie
http://example.com
  /.well-known/callme?resource=acct%3Abob%40example.com

[etc.]

As we've discussed before, we're not encouraging people to do things
like Bob precisely because the
'acct' scheme is define primarily for the purpose of identification,
not interaction.

However, given that people are still confused about this after saying
it so many times, perhaps it needs to be even clearer in the spec? As
in, even, a MUST NOT?

> If the application supports multiple protocols it would have to
> pick one of them to deference the URI.

So don't shove the URI into hyperlinks and so on.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEHJU8ACgkQNL8k5A2w/vx2xQCeNULRwtMNUiUp9Mk+vO9a41jj
AjQAoOEIEzYuHE46DsEWqhwg/076SKov
=+FkY
-----END PGP SIGNATURE-----

From stpeter@stpeter.im  Mon Jan 28 18:01:43 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190541F0CF7 for ; Mon, 28 Jan 2013 18:01:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 d1NM8nEQmhX4 for ; Mon, 28 Jan 2013 18:01:42 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 352221F0CE4 for ; Mon, 28 Jan 2013 18:01:42 -0800 (PST)
Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B42E24004E; Mon, 28 Jan 2013 19:07:52 -0700 (MST)
Message-ID: <51072D88.6000502@stpeter.im>
Date: Mon, 28 Jan 2013 19:01:44 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: SM 
References: <51067C1C.2050509@ericsson.com> <6.2.5.6.2.20130128104820.0a9afb08@resistor.net> <794576CB4DC5004FADDFC06E090A873D12BFC0BB@GQ1-EX10-MB02.y.corp.yahoo.com> <6.2.5.6.2.20130128120445.0a08ad70@resistor.net>  <6.2.5.6.2.20130128155212.0a1841d0@resistor.net>
In-Reply-To: <6.2.5.6.2.20130128155212.0a1841d0@resistor.net>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 02:01:43 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/28/13 5:07 PM, SM wrote:
> Hi Murray, At 15:04 28-01-2013, Murray S. Kucherawy wrote:
>> Can you please elaborate on your point about qualification as a
>> PS?
> 
> There is an AppsDir review from Tim Bray about a previous scheme
> at 
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05435.html
>
> 
The issue may be different here.  I'll describe Proposed Standard as
> when interoperability is necessary.  I don't feel strongly about
> this.

Well, 'about' URIs are truly local -- each browser does something
different with them, supports different parameters, etc. The use of
'acct' URIs within WebFinger or other using protocols does have
implications for interoperability. However, per RFC 4395, the purpose
of the "Interoperability considerations" section in the URI scheme
registration is as follows:

      If you are aware of any details regarding your scheme that might
      impact interoperability, please identify them here.  For example:
      proprietary or uncommon encoding method; inability to support
      multibyte character sets; incompatibility with types or versions
      of any underlying protocol.

I don't see anything about the 'acct' scheme itself that would cause
interoperability problems of that kind (the scheme is handled
consistently, doesn't use a weird encoding scheme, etc.), but perhaps
you're right that we might want to mention that the scheme could be
reused by multiple different protocols, as you've noted.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEHLYgACgkQNL8k5A2w/vxZKQCg3QgtVITWpO6WuCDhkAQIfkVo
+hkAnRXVl8rB3yvtGozunXk7OT9zKoMy
=GRfG
-----END PGP SIGNATURE-----

From stpeter@stpeter.im  Mon Jan 28 18:26:35 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D190F21E805E for ; Mon, 28 Jan 2013 18:26:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 X6brnlB-UvKo for ; Mon, 28 Jan 2013 18:26:34 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA4921E8049 for ; Mon, 28 Jan 2013 18:26:27 -0800 (PST)
Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 82D514004E; Mon, 28 Jan 2013 19:32:41 -0700 (MST)
Message-ID: <5107335A.7040309@stpeter.im>
Date: Mon, 28 Jan 2013 19:26:34 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Daniel Pocock 
References: <51046708.2040806@pocock.com.au> <5106F52D.3070101@pocock.com.au> <5106FEC2.8050606@stpeter.im> <51070176.1020008@pocock.com.au>
In-Reply-To: <51070176.1020008@pocock.com.au>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: draft-ietf-appsawg-acct-uri-02 Re: [Operators] Protocol agnostic URI for voice or video call?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 02:26:35 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/28/13 3:53 PM, Daniel Pocock wrote:
> 
> 
> On 28/01/13 23:42, Peter Saint-Andre wrote:
>> On 1/28/13 3:01 PM, Daniel Pocock wrote:
> 
> 
>>> Just forwarding my feedback on draft-ietf-appsawg-acct-uri -
>>> see comments further below
> 
>>> The prefix `acct:' may not be the right solution for what was 
>>> intended in my original query on xmpp-operators, but if it is 
>>> not suitable, then that may imply that some other prefix is
>>> also needed in addition to acct:
> 
>>> For example, rtc:daniel@pocock.com.au could be defined in 
>>> another draft to imply any type of real-time communication
>>> (im, sip or xmpp) perhaps?
> 
>> Actually, both im: and pres: are of the form you're thinking
>> about (they are "meta-URIs", if you will, which could trigger 
>> interaction via some particular protocol like SIP or XMPP). 
>> However, they are rarely used perhaps because the resolution 
>> process is somewhat complex (see RFC 3859, RFC 3860, and RFC
>> 3861), so I don't think they provide a good model to follow.
> 
> 
> 
> I agree it is not easy, but from an end-user perspective, having a 
> single omni-URI (omni:stpeter@stpeter.im ?) has very compelling 
> ease-of-use benefits.

The problem is that the one ring to bind them all can also be used for
any purpose, and thus might be void for vagueness. Telling the end
user "omni:foo@example.com enables you to interact in every possible
way with foo" doesn't seem very helpful to me.

In any case, it's not the intent of the 'acct' scheme to enable every
kind of interaction with accounts, only to provide a generic
identifier for accounts. Unfortunately, the distinction between
identification and interaction seems to be hard for folks to grasp...

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEHM1oACgkQNL8k5A2w/vz/PgCfTf30C1+raBWiRcNezIkJ1tXc
p38AoLdbM0P9p5upgnzYk1XPHTLOH7yE
=5PES
-----END PGP SIGNATURE-----

From paulej@packetizer.com  Mon Jan 28 18:44:06 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAB321E8042 for ; Mon, 28 Jan 2013 18:44:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSbJT9MLCw+S for ; Mon, 28 Jan 2013 18:44:05 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 92A4A21E8049 for ; Mon, 28 Jan 2013 18:44:05 -0800 (PST)
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 r0T2i29Y021726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2013 21:44:04 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1359427444; bh=A04ATzkxv3uzHVRnnj3SmS0bGVwJXy+rXrIh3R9WWuc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=UV3AAYyofnU3MdQqmMv8Qin/kOPW8wDdpALPQTSV8/c27ul9KeLJKL/OpwGSY4Ymd tDcq8JZJQeJEMbyKw5Dn/gqq9VhqN+qInVPw19GWSApg4c3HB2GdlWckoEDkdBndEk hTEwtC/aBgcTGwi5zNeY354mt5Y/OrBYnyvjqoL8=
From: "Paul E. Jones" 
To: "'Peter Saint-Andre'" , "'SM'" 
References: <51067C1C.2050509@ericsson.com>	<6.2.5.6.2.20130128104820.0a9afb08@resistor.net>	<794576CB4DC5004FADDFC06E090A873D12BFC0BB@GQ1-EX10-MB02.y.corp.yahoo.com>	<6.2.5.6.2.20130128120445.0a08ad70@resistor.net> <5107254F.6040401@stpeter.im>
In-Reply-To: <5107254F.6040401@stpeter.im>
Date: Mon, 28 Jan 2013 21:44:04 -0500
Message-ID: <026701cdfdca$822de780$8689b680$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJKQwWxh+z/6fdCvvK6glZEzIsMvwI1xaLcAj4fki8CW02QIgIa48IGlx+8V1A=
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Working Group Last Call for	draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 02:44:06 -0000

Peter,

> As we've discussed before, we're not encouraging people to do things
> like Bob precisely because the 'acct'
> scheme is define primarily for the purpose of identification, not
> interaction.
> 
> However, given that people are still confused about this after saying it
> so many times, perhaps it needs to be even clearer in the spec? As in,
> even, a MUST NOT?

While the above might not be encouraged, people could still do that.  What
the browser does when it sees any URI scheme is really implementation
dependent.  There's a general agreement on what to do with http or https,
but there isn't agreement on what to do with mailto, ftp, sftp, etc.  Some
browsers do nothing.  Some launch default applications, usually
user-specified.  Personally, I think it would be cool if the browser
displayed some kind of user profile page for such URIs, but having MUST NOT
would make that illegal.

Paul



From stpeter@stpeter.im  Mon Jan 28 19:02:03 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D82321E808C for ; Mon, 28 Jan 2013 19:02:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 zHvhKCwfwwUf for ; Mon, 28 Jan 2013 19:02:02 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B93B021E808A for ; Mon, 28 Jan 2013 19:02:02 -0800 (PST)
Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 327FF4004E; Mon, 28 Jan 2013 20:08:16 -0700 (MST)
Message-ID: <51073BB1.7090403@stpeter.im>
Date: Mon, 28 Jan 2013 20:02:09 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Paul E. Jones" 
References: <51067C1C.2050509@ericsson.com>	<6.2.5.6.2.20130128104820.0a9afb08@resistor.net>	<794576CB4DC5004FADDFC06E090A873D12BFC0BB@GQ1-EX10-MB02.y.corp.yahoo.com>	<6.2.5.6.2.20130128120445.0a08ad70@resistor.net> <5107254F.6040401@stpeter.im> <026701cdfdca$822de780$8689b680$@packetizer.com>
In-Reply-To: <026701cdfdca$822de780$8689b680$@packetizer.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Working Group Last Call for	draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 03:02:03 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/28/13 7:44 PM, Paul E. Jones wrote:
> Peter,
> 
>> As we've discussed before, we're not encouraging people to do
>> things like Bob precisely
>> because the 'acct' scheme is define primarily for the purpose of
>> identification, not interaction.
>> 
>> However, given that people are still confused about this after
>> saying it so many times, perhaps it needs to be even clearer in
>> the spec? As in, even, a MUST NOT?
> 
> While the above might not be encouraged, people could still do
> that.  What the browser does when it sees any URI scheme is really
> implementation dependent.  There's a general agreement on what to
> do with http or https, but there isn't agreement on what to do with
> mailto, ftp, sftp, etc.  Some browsers do nothing.  Some launch
> default applications, usually user-specified.  Personally, I think
> it would be cool if the browser displayed some kind of user profile
> page for such URIs, but having MUST NOT would make that illegal.

Well, that's more of a UI issue than a protocol issue anyway, so I
don't think MUST NOT would be appropriate...

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEHO7EACgkQNL8k5A2w/vy0NwCdH0ojoHH47XgCHYuN49nSl4FC
eXkAoPX3WFUWGQWyVTNGVybN2OMBRB9t
=SdsB
-----END PGP SIGNATURE-----

From sm@resistor.net  Mon Jan 28 22:09:52 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A016321F899E for ; Mon, 28 Jan 2013 22:09:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 eBGrpbiNlzZ5 for ; Mon, 28 Jan 2013 22:09:51 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2302F21F8967 for ; Mon, 28 Jan 2013 22:09:51 -0800 (PST)
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 r0T69hvL029444; Mon, 28 Jan 2013 22:09:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359439790; bh=M6VDxufzvQj1VU+o3cMZFcRRd9BgBvEkfKjmgbljS9E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IdbGfFmhlAF9M8p1RuPMqgtZhHVhosDoMr0yRPL0BNlhueCG50KuxR+Coxm9DMRWv Yqr+OEfan9JcZlhrwVd3AS7UDm48t6mapha6K58I2ZxqDFRh8W6ESFxtVxnssOL3Jg o03PhAEq5bpDxhmZ98wTEPXgMkVrTWHGqiOTCA6A=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1359439790; i=@resistor.net; bh=M6VDxufzvQj1VU+o3cMZFcRRd9BgBvEkfKjmgbljS9E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=npY20wEv34QHeR7XEoyfhV1te/qwz8/QSCIkh0BIAz8F+hH7Vl0Nhjy4LUqNPG0bl Zu+U/un6DbaGd2O0VvqTYrhoQSs3r6UeiLyYT8JBO7DI5lmPw4bMQgCxN+yA1MUav2 AY2D+uthOqJVThYdMEiysX9TGsdL1AWqvDXokmV8=
Message-Id: <6.2.5.6.2.20130128213400.0a3ce4f0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 28 Jan 2013 21:57:20 -0800
To: Peter Saint-Andre 
From: SM 
In-Reply-To: <5107254F.6040401@stpeter.im>
References: <51067C1C.2050509@ericsson.com> <6.2.5.6.2.20130128104820.0a9afb08@resistor.net> <794576CB4DC5004FADDFC06E090A873D12BFC0BB@GQ1-EX10-MB02.y.corp.yahoo.com> <6.2.5.6.2.20130128120445.0a08ad70@resistor.net> <5107254F.6040401@stpeter.im>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 06:09:52 -0000

Hi Peter,
At 17:26 28-01-2013, Peter Saint-Andre wrote:
>That's not interoperability, that's multi-functionality. :-)

:-)

>So let's say that we have lots of protocols using acct as a parameter
>in various REST-based protocols...
>
>a. WebFinger
>http://example.com
>   /.well-known/webfinger?resource=acct%3Abob%40example.com
>
>b. mythical SendMessage protocol
>http://example.com
>   /.well-known/msg?resource=acct%3Abob%40example.com
>
>c. Daniel Pocock's uber-RTC thingie
>http://example.com
>   /.well-known/callme?resource=acct%3Abob%40example.com
>
>[etc.]
>
>As we've discussed before, we're not encouraging people to do things
>like Bob precisely because the
>'acct' scheme is define primarily for the purpose of identification,
>not interaction.
>
>However, given that people are still confused about this after saying
>it so many times, perhaps it needs to be even clearer in the spec? As
>in, even, a MUST NOT?

Thanks for the explanation.  I see what you mean by "typically passed 
around as a parameter in the background within a protocol flow so 
that an entity can interact with the resource identified".  I don't 
think a "MUST NOT" is needed.

>So don't shove the URI into hyperlinks and so on.

Ok.

Regards,
-sm  


From daniel@pocock.com.au  Tue Jan 29 01:10:20 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2233321F86F0 for ; Tue, 29 Jan 2013 01:10:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.151,  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 HOsRqe4QXCIu for ; Tue, 29 Jan 2013 01:10:18 -0800 (PST)
Received: from mail1.trendhosting.net (mail1.trendhosting.net [195.8.117.5]) by ietfa.amsl.com (Postfix) with ESMTP id BED9B21F8740 for ; Tue, 29 Jan 2013 01:10:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail1.trendhosting.net (Postfix) with ESMTP id BF248150B6 for ; Tue, 29 Jan 2013 09:10:16 +0000 (GMT)
Received: from mail1.trendhosting.net ([127.0.0.1]) by localhost (thp003.trendhosting.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cgGPEFPhijkf for ; Tue, 29 Jan 2013 09:10:05 +0000 (GMT)
Message-ID: <510791EB.6010003@pocock.com.au>
Date: Tue, 29 Jan 2013 10:10:03 +0100
From: Daniel Pocock 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <51067C1C.2050509@ericsson.com>	<6.2.5.6.2.20130128104820.0a9afb08@resistor.net>	<794576CB4DC5004FADDFC06E090A873D12BFC0BB@GQ1-EX10-MB02.y.corp.yahoo.com>	<6.2.5.6.2.20130128120445.0a08ad70@resistor.net>	<5107254F.6040401@stpeter.im> <6.2.5.6.2.20130128213400.0a3ce4f0@resistor.net>
In-Reply-To: <6.2.5.6.2.20130128213400.0a3ce4f0@resistor.net>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 09:10:20 -0000

On 29/01/13 06:57, SM wrote:
> Hi Peter,
> At 17:26 28-01-2013, Peter Saint-Andre wrote:
>> That's not interoperability, that's multi-functionality. :-)
>
> :-)
>
>> So let's say that we have lots of protocols using acct as a parameter
>> in various REST-based protocols...
>>
>> a. WebFinger
>> http://example.com
>>   /.well-known/webfinger?resource=acct%3Abob%40example.com
>>
>> b. mythical SendMessage protocol
>> http://example.com
>>   /.well-known/msg?resource=acct%3Abob%40example.com
>>
>> c. Daniel Pocock's uber-RTC thingie
>> http://example.com
>>   /.well-known/callme?resource=acct%3Abob%40example.com
>>
>> [etc.]
>>
>> As we've discussed before, we're not encouraging people to do things
>> like Bob precisely because the
>> 'acct' scheme is define primarily for the purpose of identification,
>> not interaction.
>>
>> However, given that people are still confused about this after saying
>> it so many times, perhaps it needs to be even clearer in the spec? As
>> in, even, a MUST NOT?
>
> Thanks for the explanation.  I see what you mean by "typically passed
> around as a parameter in the background within a protocol flow so that
> an entity can interact with the resource identified".  I don't think a
> "MUST NOT" is needed.
>
>> So don't shove the URI into hyperlinks and so on.
>
> Ok.
>

I don't want to be hijacking this draft for my own convenience with an
omni-URL, but I feel that proposing or even referring to such an
alternative might be the best way to show people how acct: is not
intended to be used.

Looking at the IANA registry, I notice the following

Permanent, generic:  im, pres, mailto, tel
Permanent, specific:  sip, xmpp, h323

Provisional, generic: sms, mms
Provisional, specific: callto   (for Netmeeting?)

Could callto: be suggested for (try any of) sip/xmpp/h323 (if a NAPTR
exists) and based on the client capabilities?

Could a more general prefix like `contact:' be useful to indicate that
an acct is contactable?



From laurentwalter.goix@telecomitalia.it  Tue Jan 29 02:22:24 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE9D21F86E8 for ; Tue, 29 Jan 2013 02:22:24 -0800 (PST)
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 QUhZvrJXg6Ha for ; Tue, 29 Jan 2013 02:22:23 -0800 (PST)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id DCDFF21F854E for ; Tue, 29 Jan 2013 02:22:22 -0800 (PST)
Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 29 Jan 2013 11:22:18 +0100
Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Tue, 29 Jan 2013 11:22:18 +0100
From: Goix Laurent Walter 
To: Peter Saint-Andre , "Paul E. Jones" 
Date: Tue, 29 Jan 2013 11:22:17 +0100
Thread-Topic: [apps-discuss] Working Group Last Call	for draft-ietf-appsawg-acct-uri-02
Thread-Index: Ac39zRFUqNSe+DegQUKIBGlJzXj8/wAPTeYg
Message-ID: 
References: <51067C1C.2050509@ericsson.com> <6.2.5.6.2.20130128104820.0a9afb08@resistor.net> <794576CB4DC5004FADDFC06E090A873D12BFC0BB@GQ1-EX10-MB02.y.corp.yahoo.com> <6.2.5.6.2.20130128120445.0a08ad70@resistor.net> <5107254F.6040401@stpeter.im> <026701cdfdca$822de780$8689b680$@packetizer.com> <51073BB1.7090403@stpeter.im>
In-Reply-To: <51073BB1.7090403@stpeter.im>
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
Cc: "apps-discuss@ietf.org" 
Subject: [apps-discuss] R: Working Group Last Call	for	draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 10:22:24 -0000

> -----Messaggio originale-----
> Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
Per
> conto di Peter Saint-Andre
> Inviato: marted=EC 29 gennaio 2013 4.02
> A: Paul E. Jones
> Cc: apps-discuss@ietf.org
> Oggetto: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsaw=
g-
> acct-uri-02
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 1/28/13 7:44 PM, Paul E. Jones wrote:
> > Peter,
> >
> >> As we've discussed before, we're not encouraging people to do
> >> things like Bob precisely
> >> because the 'acct' scheme is define primarily for the purpose of
> >> identification, not interaction.
> >>
> >> However, given that people are still confused about this after
> >> saying it so many times, perhaps it needs to be even clearer in
> >> the spec? As in, even, a MUST NOT?
> >
> > While the above might not be encouraged, people could still do
> > that.  What the browser does when it sees any URI scheme is really
> > implementation dependent.  There's a general agreement on what to
> > do with http or https, but there isn't agreement on what to do with
> > mailto, ftp, sftp, etc.  Some browsers do nothing.  Some launch
> > default applications, usually user-specified.  Personally, I think
> > it would be cool if the browser displayed some kind of user profile
> > page for such URIs, but having MUST NOT would make that illegal.
>
> Well, that's more of a UI issue than a protocol issue anyway, so I
> don't think MUST NOT would be appropriate...

+1 for the scenario and the consideration. Some browsers and mobile phones =
may trigger intents based on a click on an acct: uri. Then it is up to the =
app logic to offer other alternatives of "communication" if applicable (bec=
ause of the jrd answer containing some pointers for example), or of retriev=
ing additional information etc

walter

>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlEHO7EACgkQNL8k5A2w/vy0NwCdH0ojoHH47XgCHYuN49nSl4FC
> eXkAoPX3WFUWGQWyVTNGVybN2OMBRB9t
> =3DSdsB
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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 evan@status.net  Tue Jan 29 08:03:14 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373F021F88B2 for ; Tue, 29 Jan 2013 08:03:14 -0800 (PST)
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 TW07LH0I4W3j for ; Tue, 29 Jan 2013 08:03:13 -0800 (PST)
Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 7452B21F88A1 for ; Tue, 29 Jan 2013 08:03:13 -0800 (PST)
Received: from [10.0.1.34] (modemcable064.24-130-66.mc.videotron.ca [66.130.24.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 2DE4D8D4254 for ; Tue, 29 Jan 2013 16:17:04 +0000 (UTC)
Message-ID: <5107F2C0.2000700@status.net>
Date: Tue, 29 Jan 2013 11:03:12 -0500
From: Evan Prodromou 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
References: <51067C1C.2050509@ericsson.com>
In-Reply-To: <51067C1C.2050509@ericsson.com>
Content-Type: multipart/alternative; boundary="------------070004070405010103040804"
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 16:03:14 -0000

This is a multi-part message in MIME format.
--------------070004070405010103040804
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Section 3 says, in part,

    For example, an 'acct' URI would not be used as follows:

    find out more

For many kinds of accounts, there are reasonable ways to resolve that 
URI to an HTTP URL and show a representation of the account.

I believe there's been some experimental work on this with Webfinger in 
particular:

http://www.open-mike.org/entry/people-in-the-address-bar-with-webfinger

For accounts that don't support Webfinger, it's possible to do one-off 
resolution, e.g. changing a well-known domain like 
acct:evan.prodromou@facebook.com into an HTTP URL like 
https://www.facebook.com/evan.prodromou is a simple transformation.

Given that it's /possible/ to do this, and that it might even be 
/useful/, is there a reason we need to explicitly disavow it?

-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


--------------070004070405010103040804
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Section 3 says, in part,

      

        
For example, an 'acct' URI would not be used as follows:


        
<a href='acct:bob@example.com'>find out more</a>

      

      For many kinds of accounts, there are reasonable ways to resolve
      that URI to an HTTP URL and show a representation of the account.

      

      I believe there's been some experimental work on this with
      Webfinger in particular:

      

      http://www.open-mike.org/entry/people-in-the-address-bar-with-webfinger

      

      For accounts that don't support Webfinger, it's possible to do
      one-off resolution, e.g. changing a well-known domain like acct:evan.prodromou@facebook.com
      into an HTTP URL like https://www.facebook.com/evan.prodromou
      is a simple transformation.

      

      Given that it's possible to do this, and that it might
      even be useful, is there a reason we need to explicitly
      disavow it?

      

      -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

  


--------------070004070405010103040804--

From evan@e14n.com  Mon Jan 28 18:13:08 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A451F0D03 for ; Mon, 28 Jan 2013 18:13:08 -0800 (PST)
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 MNWI881ErFOY for ; Mon, 28 Jan 2013 18:13:08 -0800 (PST)
Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id CA0DB1F0D02 for ; Mon, 28 Jan 2013 18:13:07 -0800 (PST)
Received: from [192.168.0.107] (modemcable218.194-202-24.mc.videotron.ca [24.202.194.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id CCBBD8D4190 for ; Tue, 29 Jan 2013 02:26:57 +0000 (UTC)
Message-ID: <51073032.1080202@e14n.com>
Date: Mon, 28 Jan 2013 21:13:06 -0500
From: Evan Prodromou 
Organization: E14N
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
References: <51067C1C.2050509@ericsson.com>
In-Reply-To: <51067C1C.2050509@ericsson.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030408000108050907080706"
X-Mailman-Approved-At: Tue, 29 Jan 2013 08:05:48 -0800
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 02:13:08 -0000

This is a cryptographically signed message in MIME format.

--------------ms030408000108050907080706
Content-Type: multipart/alternative;
 boundary="------------040706070204040808080705"

This is a multi-part message in MIME format.
--------------040706070204040808080705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Section 3 says, in part,

    For example, an 'acct' URI would not be used as follows:

    find out more

For many kinds of accounts, there are reasonable ways to resolve that=20
URI and show a representation of the account in the browser.

I believe there's been some experimental work on this with Webfinger in=20
particular:

http://www.open-mike.org/entry/people-in-the-address-bar-with-webfinger

For accounts that don't support Webfinger, it's possible to do one-off=20
resolution, e.g. changing a well-known domain like=20
acct:evan.prodromou@facebook.com into an HTTP URL like=20
https://www.facebook.com/evan.prodromou is a simple transformation.

Given that it's /possible/ to do this, and that it might even be=20
/useful/, is there a reason we need to explicitly disavow it?

-Evan


--------------040706070204040808080705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Section 3 says, in part,

      

        
For example, an 'acct' URI would not be used as follows:


        
<a href=3D'acct:bob@example.com'>find out more&l=
t;/a>

      

      For many kinds of accounts, there are reasonable ways to resolve
      that URI and show a representation of the account in the browser.
      

      I believe there's been some experimental work on this with
      Webfinger in particular:

      

http://www.open-mike.org/entry=
/people-in-the-address-bar-with-webfinger

      

      For accounts that don't support Webfinger, it's possible to do
      one-off resolution, e.g. changing a well-known domain like
      acct:evan.prodromou@facebook.com into an HTTP URL=
 like
      https://www.facebook.com/evan.prodromou is a simple
      transformation.

      

      Given that it's possible to do this, and that it might
      even be useful, is there a reason we need to explicitly
      disavow it?

      

      -Evan

      

    

  


--------------040706070204040808080705--

--------------ms030408000108050907080706
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQTCC
BUswggQzoAMCAQICEEuui3coSgPxeBmm1kzS1rswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz
aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe
Fw0xMjExMjEwMDAwMDBaFw0xMzExMjEyMzU5NTlaMIIBDjEXMBUGA1UEChMOVmVyaVNpZ24s
IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52
ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp
OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ
RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FdmFuIFByb2Ry
b21vdTEcMBoGCSqGSIb3DQEJARYNZXZhbkBlMTRuLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAORmFCsNPJqt5UyhR02QZdZdUxvxQcPqu4jsZ6OEHSN5B+fUGFp87FLq
4PJZwfIu1Cv4QItq4AmIvVJi8AbrbBBNN45jzZvPNFCA7lvihd47aviNpfOdm0mx3YYfH+aU
4W5oXdSrCaIqWwAjxUnYWaJljCXi7kd9t4zL9mnl+W+IKw3L5sT2CWZpapAmCI+xO41PhLEJ
hyBWrQKgSwjINgJgoEVOhVien2v5pe3FxWGDRuS3UWiRHFPg+ZjmQIvmR6KJ5l3esRl7y1L2
QbNGlSC92LAW1MXDSo5T0WCypZs93NFBvcfsOcdWVBS+1p1gycpGtkDio5Itgqv2IzBA8c0C
AwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggr
BgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYD
VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9p
bmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNy
bDANBgkqhkiG9w0BAQUFAAOCAQEAPaHFMHt2vp6k7gmYqDdvn1upM2aJ2sVX4ybGJME97Hrg
/axsoTmtY69LtfTNHqOJAbjXgaqABXp9f+p1JqzI5Nkaac2rWDx2BFGUdUuQKeIzyiAPJ0Ou
wWNBThLS/tTUuipWx2V0jIJzPRP0gZuxBi6JQydnLsWEMZeup5jC8QhXCSPu1aaJ08SbdYCD
xYSpHUoPkpOxm7A/Vx4xN24edU0TvmH+xvXPMo3NgPNs+Qsjt2Tugg2O6XngESdsE/X9+JMC
aDRyDaC1oUe8TytFkOJvJ2AplXVwr5h3pI3IoDoq1EX86MZjf3QiloN2Qn0ELsIRcPkQZPeM
+O2qklmEJTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4g
LSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQ
dWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAw
MDAwMFoXDTE5MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln
biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy
bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV
BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBf
DUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY31
3DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGD
P3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbE
sq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOC
ArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNp
Z24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBW
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwIC
MB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0
cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7
0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAu
BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4E
FgQUeUdhCEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo
b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt
YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0G
CSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGT
gc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw8
4J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFY
m77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpI
DmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoO
f8GCMYIE+TCCBPUCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg
b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT
FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp
dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQS66LdyhKA/F4GabWTNLWuzAJBgUrDgMCGgUA
oIIC2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAxMjkw
MjEzMDZaMCMGCSqGSIb3DQEJBDEWBBSBqbaXNeCAldClA+fmDWDQEKM+tjBsBgkqhkiG9w0B
CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYB
BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x
HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVz
ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJz
b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh
bCBTdWJzY3JpYmVyIENBIC0gRzMCEEuui3coSgPxeBmm1kzS1rswggEFBgsqhkiG9w0BCRAC
CzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg
aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEczAhBLrot3KEoD8XgZptZM0ta7MA0GCSqGSIb3DQEBAQUABIIBAL9X
zGUNiu3tvIsQ5b1xmo/OXZ0K8s+rqJvcU8OPRMm2nf08F4zP+VuVP1X1tU+fNm8pQ1VqrTot
r8/EbJ14azExcuC2R3VOFSkzwHqydG8j94EUQCfDs7BJrZC2rPZ5FpPlbj4RWgswG7O1CXDC
SMecyAOv4n1t7ag9sP7ss+ZTll4Q3dwG4PuE7KNVaQxNSKcE+ydRch3DnTRbE00tfDExWRpE
qWFo7Ig+0OSLI7JQD+LdmHFdQV270umhBbA8iWpTyFI98n3ClfbYLzqAyyHfxP7/s0MPSaST
gTtvIva4KfaR+ucVp8fBRTkrh8VojaFZ5KNWpzGCGjqhhHjuQq4AAAAAAAA=
--------------ms030408000108050907080706--

From evan@status.net  Tue Jan 29 08:45:38 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215B921F890D for ; Tue, 29 Jan 2013 08:45:38 -0800 (PST)
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 94J0B-fdMgYg for ; Tue, 29 Jan 2013 08:45:37 -0800 (PST)
Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 7E16121F890F for ; Tue, 29 Jan 2013 08:45:37 -0800 (PST)
Received: from [10.0.1.34] (modemcable064.24-130-66.mc.videotron.ca [66.130.24.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 9E7688D44DC for ; Tue, 29 Jan 2013 16:59:28 +0000 (UTC)
Message-ID: <5107FCB0.4010402@status.net>
Date: Tue, 29 Jan 2013 11:45:36 -0500
From: Evan Prodromou 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
References: <51067C1C.2050509@ericsson.com> <51073032.1080202@e14n.com>
In-Reply-To: <51073032.1080202@e14n.com>
Content-Type: multipart/alternative; boundary="------------080505000605020404090300"
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 16:45:38 -0000

This is a multi-part message in MIME format.
--------------080505000605020404090300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 13-01-28 09:13 PM, Evan Prodromou wrote:
> Section 3 says, in part,
>
>     For example, an 'acct' URI would not be used as follows:
>
>     find out more
>
> For many kinds of accounts, there are reasonable ways to resolve that 
> URI and show a representation of the account in the browser.
>
> I believe there's been some experimental work on this with Webfinger 
> in particular:
>
> http://www.open-mike.org/entry/people-in-the-address-bar-with-webfinger
>
> For accounts that don't support Webfinger, it's possible to do one-off 
> resolution, e.g. changing a well-known domain like 
> acct:evan.prodromou@facebook.com into an HTTP URL like 
> https://www.facebook.com/evan.prodromou is a simple transformation.
>
> Given that it's /possible/ to do this, and that it might even be 
> /useful/, is there a reason we need to explicitly disavow it?
If acct: URIs are supposed to be URN-like, maybe it would make more 
sense for "acct" to be an URN namespace, per RFC 2141.

     urn:acct:bob@example.com

-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


--------------080505000605020404090300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 13-01-28 09:13 PM, Evan Prodromou
      wrote:

    

    

      
      
Section 3 says, in part,

        

          
For example, an 'acct' URI would not be used as follows:


          
<a href='acct:bob@example.com'>find out more</a>

        

        For many kinds of accounts, there are reasonable ways to resolve
        that URI and show a representation of the account in the
        browser.

        

        I believe there's been some experimental work on this with
        Webfinger in particular:

        

        http://www.open-mike.org/entry/people-in-the-address-bar-with-webfinger

        

        For accounts that don't support Webfinger, it's possible to do
        one-off resolution, e.g. changing a well-known domain like acct:evan.prodromou@facebook.com
        into an HTTP URL like https://www.facebook.com/evan.prodromou
        is a simple transformation.

        

        Given that it's possible to do this, and that it might
        even be useful, is there a reason we need to explicitly
        disavow it?

      

    

    If acct: URIs are supposed to be URN-like, maybe it would make more
    sense for "acct" to be an URN namespace, per RFC 2141.

    

        urn:acct:bob@example.com

    

    -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

  


--------------080505000605020404090300--

From melvincarvalho@gmail.com  Tue Jan 29 08:50:04 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DD621F890D for ; Tue, 29 Jan 2013 08:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 uvMBntQQfKfd for ; Tue, 29 Jan 2013 08:50:03 -0800 (PST)
Received: from mail-ia0-x22e.google.com (ia-in-x022e.1e100.net [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBDE21F892C for ; Tue, 29 Jan 2013 08:50:03 -0800 (PST)
Received: by mail-ia0-f174.google.com with SMTP id o25so856252iad.33 for ; Tue, 29 Jan 2013 08:50:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=v1YcZbWe8VAu9xqElKFi3c4seVktrZjgKsHHGzIdpg4=; b=Kp8X4hIhBfCm6f/E6IGhg8H+kdyxZARTqeBges488tERLOynPOku5o3yooY81YWoc7 A3+/mC5IdMdtvAFxrTIZEzLkbPx80ooFP/PeZFnoN/MEBwujfymc6wWddIHHAtJ8TWBg T1XUe0/NyApd5WQIQRo+qwPWMfImTBRX2LoYwDOCefxpmBsKoL2ft9khwESeXuXon123 eMHCaIPAeLi1tmBKcORPvrFhWg+90e84CAo7hiamFBl13Y+verVUVxmGLpD9V+XctvNd AavFUBE988PWmc1PKWeLURwiYli8VKeuvnL32iBhk+nSDiUqFNjL8bkbQvGjgD4dXdC3 kQpg==
MIME-Version: 1.0
X-Received: by 10.43.90.198 with SMTP id bj6mr1093794icc.11.1359478195827; Tue, 29 Jan 2013 08:49:55 -0800 (PST)
Received: by 10.43.63.135 with HTTP; Tue, 29 Jan 2013 08:49:55 -0800 (PST)
In-Reply-To: <5107FCB0.4010402@status.net>
References: <51067C1C.2050509@ericsson.com> <51073032.1080202@e14n.com> <5107FCB0.4010402@status.net>
Date: Tue, 29 Jan 2013 17:49:55 +0100
Message-ID: 
From: Melvin Carvalho 
To: Evan Prodromou 
Content-Type: multipart/alternative; boundary=bcaec5196bddf1332604d4702eb1
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 16:50:04 -0000

--bcaec5196bddf1332604d4702eb1
Content-Type: text/plain; charset=ISO-8859-1

On 29 January 2013 17:45, Evan Prodromou  wrote:

>  On 13-01-28 09:13 PM, Evan Prodromou wrote:
>
> Section 3 says, in part,
>
> For example, an 'acct' URI would not be used as follows:
>
> find out more
>
>  For many kinds of accounts, there are reasonable ways to resolve that URI
> and show a representation of the account in the browser.
>
> I believe there's been some experimental work on this with Webfinger in
> particular:
>
> http://www.open-mike.org/entry/people-in-the-address-bar-with-webfinger
>
> For accounts that don't support Webfinger, it's possible to do one-off
> resolution, e.g. changing a well-known domain like
> acct:evan.prodromou@facebook.com into an HTTP URL like
> https://www.facebook.com/evan.prodromou is a simple transformation.
>
> Given that it's *possible* to do this, and that it might even be *useful*,
> is there a reason we need to explicitly disavow it?
>
> If acct: URIs are supposed to be URN-like, maybe it would make more sense
> for "acct" to be an URN namespace, per RFC 2141.
>
>     urn:acct:bob@example.com
>

I think this question has come up a few times, without a strong consensus,
imho.

It strikes me that acct: is slightly more appropriate as a urn than as a
'top level' URI scheme.


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

--bcaec5196bddf1332604d4702eb1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On 29 January 2013 17:45, Evan Prodromou=
 <evan@status.net> wrote:


 =20
   =20
 =20
  

    
On 13-01-28 09:13 PM, Evan Prodromou
      wrote:

    

    

     =20
      
Section 3 says, in part,

        

          
For example, an 'acct' URI would not be used as foll=
ows:


          
<a href=3D'acct:bob@example.com'>find out more</a>
        

        For many kinds of accounts, there are reasonable ways to resolve
        that URI and show a representation of the account in the
        browser.

        

        I believe there's been some experimental work on this with
        Webfinger in particular:

        

        http://www.open-mike.org/entry/people-in=
-the-address-bar-with-webfinger

        

        For accounts that don't support Webfinger, it's possible to=
 do
        one-off resolution, e.g. changing a well-known domain like acct:evan.pr=
odromou@facebook.com
        into an HTTP URL like https://www.facebook.com/evan.prodromou
        is a simple transformation.

        

        Given that it's possible to do this, and that it might
        even be useful, is there a reason we need to explicitly
        disavow it?

      

    

    If acct: URIs are supposed to be URN-like, maybe it would make more
    sense for "acct" to be an URN namespace, per RFC 2141.

    

    =A0=A0=A0 urn:acct:bob@example.com

I think this quest=
ion has come up a few times, without a strong consensus, imho.=A0 

I=
t strikes me that acct: is slightly more appropriate as a urn than as a =
9;top level' URI scheme.

=A0


    

    -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





--bcaec5196bddf1332604d4702eb1--

From wmills@yahoo-inc.com  Tue Jan 29 08:56:07 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDEF21F87D2 for ; Tue, 29 Jan 2013 08:56:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level: 
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[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 qJg51Q+XqXL6 for ; Tue, 29 Jan 2013 08:56:06 -0800 (PST)
Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6038721F87D1 for ; Tue, 29 Jan 2013 08:56:06 -0800 (PST)
Received: from GQ1-EX10-CAHT08.y.corp.yahoo.com (gq1-ex10-caht08.corp.gq1.yahoo.com [10.73.118.87]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r0TGt5uH036196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 29 Jan 2013 08:55:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1359478507; bh=iaaLGeCu+0B7QQy3xNxjsiN5+iZa5VgRpcFo396jR+o=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=h+kl98vBwLKfzVUw0BNXaAI6AD97599Ten6piVlVrBRcYZKhL4HcJ48TQ5g00BG4n 0bAyNbaA0rQLnj22q1BAYIzQrJ5Ear/sea0O0A59xMZLjL8Xp1LFzREK7paui+Cihb 1+WW09v61CHl3Aa26+82w6xrRU8K0vyeWKhy3EZA=
Received: from omp1008.mail.ne1.yahoo.com (98.138.87.8) by GQ1-EX10-CAHT08.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server id 14.2.328.9; Tue, 29 Jan 2013 08:55:05 -0800
Received: (qmail 46221 invoked by uid 1000); 29 Jan 2013 16:55:05 -0000
Received: (qmail 72480 invoked by uid 60001); 29 Jan 2013 16:55:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1359478505; bh=B1B+3oTudCIgIN1TTR8ghkwE03L3uafRxBFbYn3i4NI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=5hXcE1hAP3c6kuGKcKJhyWEKgS3V9wnXrOsxNJuviyhdConRZ2sSXY6niJ8RIzySEkYWEmLGUKYUlCWQwtB6w6qJ5xjdi0EBOay0Z4U84fxmjxkp92EjSg4+OokmLXWB7fu6ZinLhfR4wGaKBzFFlltdDcKljvVjvm9c421kn1Y=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=snake; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hiIPKtaAjTosPPMXTPZ0Q8ky0VQ4FAOi9nJX/3HR68R/ceAdxEgc/sURWewT1I44  ;
X-YMail-OSG: 5ohMJ4QVM1lZCYWDjRHu8qYb5vgFxHmcWVcvFxrx.0Hac7y lgMiSual.F6yWqxWYmrB2kn7yjf29q_xzd7J9u9.16RMf4_lF8xUue4vqnh0 Ect5CPcjHp9uJ4ZxmEciXzmMlf1Ji1lP7qxhPsIblCAC0p54FHRWrcsgTO68 wDP7FKN8IK9QTcj.R7EGm6ueVpx24KAd5N.RUoeFDG_hXkKtEkN.GUhR2wrU gShGcE6D.kZvee9avRNhLli_OkteTi_AqnhLhfTYIgsdgSF3BHcue0yZvZld U8fy95kxyLS6kxzgit0uh40suz.7ibaMaR8asBoqti2eOeeVBsMOZ6ZNaYpu 2CMaNnjIQQTWGSEkrGyQPnY0alxcFsxRh5JWiomSKagDABvAnERXIV2lULPS 5tUAHrQaKzJGtOq04kadHO7Xg8K9Se4VJpIL0x2zaeUsZIJVPEdaSjLB7O3F APKuexha8khXMDHrNROV0h2qaJ86NelNxYZcWY8WVgrsbOnLhsLyWvPP36Si cVChWBIHjGbtdZRLCvfRRBqkYARlhvnnI9GYtJPwV_xbuQ1oPbyrLCpen5hC pKd1TGRLMPMIeOR3q43tG1zS86JFRUmR55rrl3lIubrsJSiCyGoL.0s8VFbd Tff77Be8.Zqp2oXpXQQkfeaUgjYjdClmKvg4I8EzVhCag7yE2Wkbq97oscFZ B.F4_cA--
Received: from [209.131.62.115] by web125604.mail.ne1.yahoo.com via HTTP; Tue, 29 Jan 2013 08:55:05 PST
X-Rocket-MIMEInfo: 001.001, SSBiZWxpZXZlIGFuIGFyZ3VtZW50IGFnYWluc3QgbWFraW5nIGl0IGEgdXJuIGlzIHRoYXQgdXJucyBzdXBwb3NlZCBvdCBiZSBnbG9iYWxseSB1bmlxdWU_wqAgYWNjdDogc3VwcG9ydHMgbG9ja2EgaWRlbnRpZmllcnMgc28gd29uJ3QgYmUgZ2xvYmFsbHkgdW5pcXVlLgoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IE1lbHZpbiBDYXJ2YWxobyA8bWVsdmluY2FydmFsaG9AZ21haWwuY29tPgpUbzogRXZhbiBQcm9kcm9tb3UgPGV2YW5Ac3RhdHVzLm5ldD4gCkNjOiAiYXBwcy0BMAEBAQE-
X-Mailer: YahooMailWebService/0.8.131.499
References: <51067C1C.2050509@ericsson.com> <51073032.1080202@e14n.com> <5107FCB0.4010402@status.net> 
Message-ID: <1359478505.19372.YahooMailNeo@web125604.mail.ne1.yahoo.com>
Date: Tue, 29 Jan 2013 08:55:05 -0800
From: Bill Mills 
To: Melvin Carvalho , Evan Prodromou 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-685807438-1601890338-1359478505=:19372"
X-Milter-Version: master.31+4-gbc07cd5+
X-CLX-ID: 478507005
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Bill Mills 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jan 2013 16:56:07 -0000

---685807438-1601890338-1359478505=:19372
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I believe an argument against making it a urn is that urns supposed ot be g=
lobally unique?=A0 acct: supports locka identifiers so won't be globally un=
ique.=0A=0A=0A=0A=0A________________________________=0A From: Melvin Carval=
ho =0ATo: Evan Prodromou  =0ACc:=
 "apps-discuss@ietf.org"  =0ASent: Tuesday, January =
29, 2013 8:49 AM=0ASubject: Re: [apps-discuss] Working Group Last Call for =
draft-ietf-appsawg-acct-uri-02=0A =0A=0A=0A=0A=0AOn 29 January 2013 17:45, =
Evan Prodromou  wrote:=0A=0AOn 13-01-28 09:13 PM, Evan Pro=
dromou wrote:=0A>=0A>Section 3 says, in part,=0A>>=0A>>For example, an 'acc=
t' URI would not be used as follows: =0A>>>find out more=0AFor many kinds of accounts, there are reasonable ways =
to resolve that URI and show a representation of the account in the browser=
.=0A>>=0A>>I believe there's been some experimental work on this with=0A   =
     Webfinger in particular:=0A>>=0A>>http://www.open-mike.org/entry/peopl=
e-in-the-address-bar-with-webfinger=0A>>=0A>>For accounts that don't suppor=
t Webfinger, it's possible to do=0A        one-off resolution, e.g. changin=
g a well-known domain like acct:evan.prodromou@facebook.com into an HTTP UR=
L like https://www.facebook.com/evan.prodromou is a simple transformation.=
=0A>>=0A>>Given that it's possible to do this, and that it might even be us=
eful, is there a reason we need to explicitly disavow it?=0A>>=0AIf acct: U=
RIs are supposed to be URN-like, maybe it would make more sense for "acct" =
to be an URN namespace, per RFC 2141.=0A>=0A>=A0=A0=A0 urn:acct:bob@example=
.com=0A=0AI think this question has come up a few times, without a strong c=
onsensus, imho.=A0 =0A=0AIt strikes me that acct: is slightly more appropri=
ate as a urn than as a 'top level' URI scheme.=0A=A0=0A=0A>=0A>-Evan=0A>=0A=
>-- =0AEvan Prodromou, CEO and Founder, StatusNet Inc.=0A1124 rue Marie-Ann=
e Est #32, Montreal, Quebec, Canada H2J 2B7=0AE: evan@status.net P: +1-514-=
554-3826=0A>_______________________________________________=0A>apps-discuss=
 mailing list=0A>apps-discuss@ietf.org=0A>https://www.ietf.org/mailman/list=
info/apps-discuss=0A>=0A>=0A=0A____________________________________________=
___=0Aapps-discuss mailing list=0Aapps-discuss@ietf.org=0Ahttps://www.ietf.=
org/mailman/listinfo/apps-discuss
---685807438-1601890338-1359478505=:19372
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


I believe an argument=
 against making it a urn is that urns supposed ot be globally unique? =
 acct: supports locka identifiers so won't be globally unique.


  
 
 
  
  From: Melvin Carvalho <melvincarvalho@gmail.co=
m>
 To: Evan Prodrom=
ou <evan@status.net> 
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org> 
 Sent: Tuesday, January 29, 2013 8=
:49 AM

 Subject: Re: [apps-discus=
s] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
  <=
/div> 


On 29 =
January 2013 17:45, Evan Prodromou <evan@status.net> wrote:
=0A=0A  =0A    =0A  =0A  
=0A    
On 13-01-28 09:13 PM, Evan Prodromou=0A      wrot=
e:
=0A    
=0A    
=0A      =0A      
=
Section 3 says, in part,
=0A        
=0A          
For ex=
ample, an 'acct' URI would not be used as follows:=0A
=0A          <a href=3D'acct:bob@example.co=
m'>find out more</a>=0A        
=0A        F=
or many kinds of accounts, there are reasonable ways to resolve=0A        t=
hat URI and show a representation of the account in the=0A        browser.<=
br>=0A        
=0A        I believe there's been some experimental work =
on this with=0A        Webfinger in particular:
=0A        
=0A      =
  http://www.open-mike.org/entr=
y/people-in-the-address-bar-with-webfinger
=0A        
=0A       =
 For accounts that don't support Webfinger, it's possible to do=0A        o=
ne-off resolution, e.g. changing a well-known domain like acct:evan.prodromou@facebook=
.com=0A        into an HTTP URL like https://www.facebook.c=
om/evan.prodromou=0A        is a simple transformation.
=0A        <=
br>=0A        Given that it's possible to do this, and that it might=
=0A        even be useful, is there a reason we need to explicitly=
=0A        disavow it?
=0A      
=0A    
=
=0A    If acct: URIs are supposed to be URN-like, maybe it would make more=
=0A    sense for "acct" to be an URN namespace, per RFC 2141.
=0A    =0A        =
urn:acct:bob@example.com

I think this questi=
on has come up a few times, without a strong consensus, imho.  
It strikes me that acct: is slightly more appropriate as a urn than as a '=
top level' URI scheme.
=0A 

=0A    
=0A    -Evan<=
br>=0A    
-- =0AEvan Prodromou, CEO and Founder, StatusNet Inc.=0A1124=
 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7=0AE: evan@status.net P: +1-5=
14-554-3826
=0A  
=0A=0A
___________________________=
____________________
=0Aapps-discuss mailing list
=0Aapps-discuss@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/apps-discuss
=0A

=0A

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


 
 
  
---685807438-1601890338-1359478505=:19372--

From Michael.Jones@microsoft.com  Tue Jan 29 10:38:54 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB4F21F8873 for ; Tue, 29 Jan 2013 10:38:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wJvtqFdDtMF for ; Tue, 29 Jan 2013 10:38:54 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.26]) by ietfa.amsl.com (Postfix) with ESMTP id 03DBB21F886D for ; Tue, 29 Jan 2013 10:38:53 -0800 (PST)
Received: from BL2FFO11FD012.protection.gbl (10.173.161.204) by BL2FFO11HUB021.protection.gbl (10.173.161.45) with Microsoft SMTP Server (TLS) id 15.0.596.13; Tue, 29 Jan 2013 18:38:50 +0000
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD012.mail.protection.outlook.com (10.173.161.18) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Tue, 29 Jan 2013 18:38:49 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.132]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Tue, 29 Jan 2013 18:38:21 +0000
From: Mike Jones 
To: Salvatore Loreto , "apps-discuss@ietf.org" 
Thread-Topic: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
Thread-Index: Ac3+T88t1arh5QfpRPGiu0vT2/hPQw==
Date: Tue, 29 Jan 2013 18:38:19 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943673DA63B@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.71]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(164054002)(13464002)(189002)(377454001)(33656001)(47736001)(46406002)(74662001)(79102001)(63696002)(46102001)(49866001)(55846006)(44976002)(20776003)(56776001)(5343655001)(31966008)(76482001)(54316002)(15202345001)(47776003)(50466001)(47446002)(16406001)(51856001)(59766001)(56816002)(53806001)(47976001)(23726001)(54356001)(50986001)(77982001)(4396001)(74502001)(57646009)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB021; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:; A:1; MX:3; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0741C77572
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 18:38:54 -0000

I believe that this document is ready for the IESG.

				Thanks,
				-- Mike

-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Salvatore Loreto
Sent: Monday, January 28, 2013 5:25 AM
To: apps-discuss@ietf.org
Subject: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct=
-uri-02

Dear WG partecipants,


I would like to initiate a 2 weeks WG Last Call on draft-ietf-appsawg-acct-=
uri-02.txt ("The 'acct' URI Scheme") http://tools.ietf.org/id/draft-ietf-ap=
psawg-acct-uri-02.txt


Please send your reviews, as well as expression of support regarding docume=
nt readiness for IESG (or not) either to the *apps-discuss* mailing list, o=
r directly to the WG chairs (Murray Kucherawy and myself).


The WG LC will end on Friday, February 8th.


Thank you,
Salvatore as an APPSAWG co-chair.


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

From jasnell@gmail.com  Tue Jan 29 10:42:40 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFF721F89E1 for ; Tue, 29 Jan 2013 10:42:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.558
X-Spam-Level: 
X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 9R49gxNYreeA for ; Tue, 29 Jan 2013 10:42:39 -0800 (PST)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2B521F89C0 for ; Tue, 29 Jan 2013 10:42:39 -0800 (PST)
Received: by mail-ie0-f177.google.com with SMTP id 16so641369iea.36 for ; Tue, 29 Jan 2013 10:42:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=HwvQFKH62OWAWyY3IR2QVeGR6shgMgxeSFmspY2bVkE=; b=v2SldMgboyhNAOyNjCNZbu/Ip9sFmqxhhrv04A+kuhig5Lh86/XMbVmM78Fn5uD8cx V2lvtAMkPH/zxiAtsLIMDpCJa7/XNGkhcpsHl2T+E158Ijha1ISeSgZntJNw8dyaQseW yh3jfblkpDmx3Ai8aL++j4d9cvf8ZDnPk46Y/AfbMIaT9qu4i1dq8bhCYg6q+o1cryTn ikK1mze3RZaNCNWyp89XN0rV0i2PtuhyZjLzJ4woFKIYD9RLz6iCwq7WASyzGhqIGBnO PcGj51LNfp/XEUSPrvNm/Y7IB32/DDd1tt/yOSwsfuVravptJkSTwPlqxqGWxsr0sTtB WWRw==
X-Received: by 10.42.157.68 with SMTP id c4mr1313452icx.35.1359484958950; Tue, 29 Jan 2013 10:42:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.26.137 with HTTP; Tue, 29 Jan 2013 10:42:18 -0800 (PST)
In-Reply-To: <6.2.5.6.2.20130128104820.0a9afb08@resistor.net>
References: <51067C1C.2050509@ericsson.com> <6.2.5.6.2.20130128104820.0a9afb08@resistor.net>
From: James M Snell 
Date: Tue, 29 Jan 2013 10:42:18 -0800
Message-ID: 
To: SM 
Content-Type: multipart/alternative; boundary=90e6ba613b320e458004d471c2b2
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 18:42:40 -0000

--90e6ba613b320e458004d471c2b2
Content-Type: text/plain; charset=UTF-8

I'm really just now starting to turn my attention to the acct uri aspect of
the WebFinger discussion.. generally speaking I'm +1 on the current
acct-uri draft. When going through various implementation scenarios,
however, one thought did strike me, although it may be a bit too late in
the game to put this on the table at all. I apologize for making this late
suggestion...

In some scenarios, such as hosted cloud application environments, a service
provider may wish to host the information about a given user within a
different domain. For instance, suppose Company Foo.com utilizes services
from ISV Bar.com. The user accounts, however, are drawn from Foo.com, but
Bar.com is the provider that actually hosts the profiles and account
information. What I want is something that identifies the user account AND
the service provider.

Example:

  acct:john.doe@foo.com?provider=bar.com

In a WebFinger type of scenario, resolving this would involve something
like...

  GET /.well-known/webfinger?resource=john.doe@foo.com
  Host: bar.com

Encoding the third party provider into the URL in this way provides a
fairly flexible way of enabling the third party support without complicated
redirects from foo.com to bar.com. It also gives domains a way of enabling
bits of information to be shared from multiple sources...
acct:john.doe@foo.com?provider=isv1.com
 vs. acct:john.doe@foo.com?provider=isv2.com

To enable this kind of thing, it would be helpful if the basic acct URI
syntax allowed for optional parameters like the mailto URI scheme does
(RFC2368). The specific parameters themselves can be figured out later...

- James

p.s. My apologies for those of you who received this comment twice, I
inadvertently posted it to the webfinger list as feedback to the WF last
call thread. It really belongs over here instead...



On Mon, Jan 28, 2013 at 11:07 AM, SM  wrote:

> At 05:24 28-01-2013, Salvatore Loreto wrote:
>
>> I would like to initiate a 2 weeks WG Last Call on
>> draft-ietf-appsawg-acct-uri-**02.txt ("The 'acct' URI Scheme")
>> http://tools.ietf.org/id/**draft-ietf-appsawg-acct-uri-**02.txt
>>
>
> I took a quick look at the draft.  Shouldn't the draft define a registry
> for protocols that use the scheme?
>
> Regards,
> -sm
> ______________________________**_________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/**listinfo/apps-discuss
>

--90e6ba613b320e458004d471c2b2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I'm really just now starting to turn my attention t=
o the acct uri aspect of the WebFinger discussion.. generally speaking I=
9;m +1 on the current acct-uri draft. When going through various implementa=
tion scenarios, however, one thought did strike me, although it may be a bi=
t too late in the game to put this on the table at all. I apologize for mak=
ing this late suggestion...



In some scenarios, such as hosted cloud application environ=
ments, a service provider may wish to host the information about a given us=
er within a different domain. For instance, suppose Company Foo.com utilize=
s services from ISV Bar.com. The user accounts, however, are drawn from Foo=
.com, but Bar.com is the provider that actually hosts the profiles and acco=
unt information. What I want is something that identifies the user account =
AND the service provider.=C2=A0



=

Example:=C2=A0



=




=

In a WebFinger type of scenario, resolving this would invo=
lve something like...



=




=
=C2=A0 Host:=C2=A0bar.com



Encoding the third party provider into the URL in this wa=
y provides a fairly flexible way of enabling the third party support withou=
t complicated redirects from=C2=A0foo.com=C2=A0to=C2=A0bar.com. It also gives domains a way of enabling bits of information t=
o be shared from multiple sources...=C2=A0acct:john.doe@foo.com?provid=
er=3Disv1.com=C2=A0vs.=C2=A0acct:john.doe@foo.com?provider=3Disv2.=
com



=

To enable this kind of thing, it would be helpful if the =
basic acct URI syntax allowed for optional parameters like the mailto URI s=
cheme does (RFC2368). The specific parameters themselves can be figured out=
 later...



=

- James



p.s. My apologies for those of you who received this comm=
ent twice, I inadvertently posted it to the webfinger list as feedback to t=
he WF last call thread. It really belongs over here instead...



=



On Mon, Jan 28, 2013 at 11:=
07 AM, SM <sm@resistor.net> wrote:



At 05:24 28-01-2013, Salvatore Loreto wrote:=




I would like to initiate a 2 weeks WG Last Call on

draft-ietf-appsawg-acct-uri-02.txt ("The 'acct' URI Sch=
eme")

http://tools.ietf.org/id/draft-ietf-appsawg-acct-uri-=
02.txt





I took a quick look at the draft. =C2=A0Shouldn't the draft define a re=
gistry for protocols that use the scheme?



Regards,

-sm 

_______________________________________________

apps-discuss mailing list

apps-discuss@iet=
f.org

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





--90e6ba613b320e458004d471c2b2--

From dave@cridland.net  Tue Jan 29 12:15:58 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB4321F8860 for ; Tue, 29 Jan 2013 12:15:58 -0800 (PST)
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 bGF25JMQ59dd for ; Tue, 29 Jan 2013 12:15:57 -0800 (PST)
Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDF721F885C for ; Tue, 29 Jan 2013 12:15:56 -0800 (PST)
Received: by mail-ob0-f176.google.com with SMTP id v19so862876obq.21 for ; Tue, 29 Jan 2013 12:15:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5TzCtC5Y84940LR7Cr9W3tGGus1ya2bCrAe/N5bWplw=; b=Z0M3chHnvLVBEWLFGGh6nCLpc48bej0Gx0C9WuaxQeaRdoOYNQu3CAFqZ9y9HwyxX9 6uzUkblaNNd3Gq5rDxLZk5DQNKU1/bAVDtmXL/VV2ZpMI0SLKBgd7k+OoRM/pM7qtVdx OjzEtO8+zGMcQnorW4l0fF8FQCuB4cMkMpPK8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=5TzCtC5Y84940LR7Cr9W3tGGus1ya2bCrAe/N5bWplw=; b=DnOK5VPd+6r9YXrXaIFjTafBZlWFv3A9J0cA80nQg4UhNUXF+w/oMkvCFqWaLaGzzZ zjgJbUSjIn56wkpu9nIgT7nJuCNSqbkCvp2oyY337Yjb+m+oYW0zwPEZPzFOAgWT/HP9 d8AOZL+nnxW7ABow1nAnxrPLF6r36fKiuMRa4r3qRAvXtOesYt8E+9zq7KbHZBSeZlqI 36XvtdGdH8XhwffOmhbBWYveuy0QHib5ju5yeefGxMBLCBJ/ZasOKkOwYgetrd/UhGWB aU6EObsRtv/11f7Gpd08Z4sTcJuoAMgytBtuH1U0iWqLGoonpqrcjKD3HwOK42torg2y Q2CQ==
MIME-Version: 1.0
X-Received: by 10.60.20.167 with SMTP id o7mr1718614oee.126.1359490556567; Tue, 29 Jan 2013 12:15:56 -0800 (PST)
Received: by 10.60.79.2 with HTTP; Tue, 29 Jan 2013 12:15:56 -0800 (PST)
Received: by 10.60.79.2 with HTTP; Tue, 29 Jan 2013 12:15:56 -0800 (PST)
In-Reply-To: <51067C1C.2050509@ericsson.com>
References: <51067C1C.2050509@ericsson.com>
Date: Tue, 29 Jan 2013 20:15:56 +0000
Message-ID: 
From: Dave Cridland 
To: Salvatore Loreto 
Content-Type: multipart/alternative; boundary=e89a8ff1c6eeb322f404d4730faf
X-Gm-Message-State: ALoCoQmNARhfLQNe+6DNoWkvqqMMRXTWJ6tVBV9oy/pYd2+/i1TmHSLV7AtLaeFsoPcImrGSNAyk
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 20:15:58 -0000

--e89a8ff1c6eeb322f404d4730faf
Content-Type: text/plain; charset=ISO-8859-1

I've read through the draft, and it seems essentially good.

I tend to agree that having an acct URI directly within an HTML anchor
element is not really something to be ruled out, but I understand the point
of that paragraph to be declaring the scheme to be protocol independent,
and not have a standard resolution.

I'll have a try at crafting some text.

Dave.

--e89a8ff1c6eeb322f404d4730faf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I've read through the draft, and it seems essentially good.


I tend to agree that having an acct URI directly within an HTML anchor e=
lement is not really something to be ruled out, but I understand the point =
of that paragraph to be declaring the scheme to be protocol independent, an=
d not have a standard resolution.



I'll have a try at crafting some text.


Dave.


--e89a8ff1c6eeb322f404d4730faf--

From dave@cridland.net  Tue Jan 29 12:21:18 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7898E21F8846 for ; Tue, 29 Jan 2013 12:21:18 -0800 (PST)
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 y7dJxpTJeqct for ; Tue, 29 Jan 2013 12:21:16 -0800 (PST)
Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by ietfa.amsl.com (Postfix) with ESMTP id 551DD21F87C4 for ; Tue, 29 Jan 2013 12:21:15 -0800 (PST)
Received: by mail-ob0-f175.google.com with SMTP id uz6so885050obc.34 for ; Tue, 29 Jan 2013 12:21:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bx7BNi0qJg985DPWfxlW20vORWExHH7FQB2h6Y39cJM=; b=hTJy+wtKhS2GXfIAB1/63fd5knhNPOazpwIoXcssZOOM9JKvhWGXBFOXc9NFGQMvLQ mZQA0b8+yXZtksZ+lTQTEj9zG25uzfhNUmjPZprTdx8CAIWunnibx7+slbsgqQMLqDoj eI8Rf88udQlwvpzvuEbnSplgDQFowNTcZrsnw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=bx7BNi0qJg985DPWfxlW20vORWExHH7FQB2h6Y39cJM=; b=L7U9rna4+S7yBYXT1H2rjV6sbMRBbJfbvT8ITBC5Jeq22guAbGAYMmqXoKsm4jwC80 lusaKBY5Acp9d5SVoMen1J32lmCZBHVFiWXSTiq+daVIeANiJSACB6B0YhqHUTdimfJN oznTkWxywryYYi+QOrdnBkYVd3qzIdNKhOUiXh57+tivv9kYA7AIeYUm8jBxA6c6cCYM aBRFVL/DRHNt5boa7NixCVdpXMgRbNFN82ttwncPfdDpMWDQkps3wEbfJak7ZvU8RVtb EeUF3mXciPLP73SxWnscrpfiaPDYAqVeVjBZS2kEnE1+3FT2+byww50ahaWu3MEfxRZb GKKQ==
MIME-Version: 1.0
X-Received: by 10.60.31.6 with SMTP id w6mr1796103oeh.65.1359490874775; Tue, 29 Jan 2013 12:21:14 -0800 (PST)
Received: by 10.60.79.2 with HTTP; Tue, 29 Jan 2013 12:21:14 -0800 (PST)
In-Reply-To: 
References: <51067C1C.2050509@ericsson.com> 
Date: Tue, 29 Jan 2013 20:21:14 +0000
Message-ID: 
From: Dave Cridland 
To: Salvatore Loreto 
Content-Type: multipart/alternative; boundary=e89a8fb1f016aa97ec04d4732249
X-Gm-Message-State: ALoCoQmWLxISq8eVMV5wOyKqhyOGabCa/RyrFYr9HIaVPHa9ZnV464r/G4xR/kACNyfNtSSafsF5
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2013 20:21:18 -0000

--e89a8fb1f016aa97ec04d4732249
Content-Type: text/plain; charset=ISO-8859-1

What about:

   Because an 'acct' URI enables abstract identification only and not
   interaction, this specification provides no method for deferencing
   an 'acct' URI on its own, e.g., as the value of the 'href' attribute of
   an HTML anchor element.  For example, there is no behaviour
   specified in this document for an 'acct' URI used as follows:

   find out more

   Instead, an 'acct' URI is employed indirectly and typically is passed
   around as a parameter in the background within a protocol flow so
   that an entity can interact with a resource related to that identified
   by the 'acct' URI in a particular way or for a particular purpose. [...
continues ...]


On Tue, Jan 29, 2013 at 8:15 PM, Dave Cridland  wrote:

> I've read through the draft, and it seems essentially good.
>
> I tend to agree that having an acct URI directly within an HTML anchor
> element is not really something to be ruled out, but I understand the point
> of that paragraph to be declaring the scheme to be protocol independent,
> and not have a standard resolution.
>
> I'll have a try at crafting some text.
>
> Dave.
>

--e89a8fb1f016aa97ec04d4732249
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


What about:

=A0 =A0Bec=
ause an 'acct' URI enables abstract identification only and not
=A0 =A0interaction, this specification provides no method for defere=
ncing


=A0 =A0an 'acct' URI on its own, e.g., as the value of the =
9;href' attribute of
=A0 =A0an HTML anchor element. =A0For ex=
ample, there is no behaviour
=A0 =A0specified in this document fo=
r an 'acct' URI used=A0as follows:



=A0 =A0<a href=3D'acct:bob@example.com'>find out more</a>
<=
div>
=A0 =A0Instead, an 'acct' URI is employed indire=
ctly and typically is passed


=A0 =A0around as a parameter in the background within a protocol flow =
so
=A0 =A0that an entity can interact with a resource related to =
that identified
=A0 =A0by the=A0'acct' URI in a particula=
r way or for a particular purpose. [... continues ...]




On Tue,=
 Jan 29, 2013 at 8:15 PM, Dave Cridland <dave@cridland.net> =
wrote:


I've read through the draft, and it s=
eems essentially good.


I tend to agree that having an acct URI directly within an HTML anchor e=
lement is not really something to be ruled out, but I understand the point =
of that paragraph to be declaring the scheme to be protocol independent, an=
d not have a standard resolution.




I'll have a try at crafting some text.


Dave.





--e89a8fb1f016aa97ec04d4732249--

From sm@resistor.net  Tue Jan 29 17:07:49 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9A321F866E for ; Tue, 29 Jan 2013 17:07:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 vLSNeuuql-yL for ; Tue, 29 Jan 2013 17:07:47 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E0A21F8837 for ; Tue, 29 Jan 2013 17:07:47 -0800 (PST)
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 r0U17bYE009522; Tue, 29 Jan 2013 17:07:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359508062; bh=ADYBbsnpAYYRbhBlSMdc7F1V0NdpK6IUwKZXLOp15dg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XAeRrrVUlxrz73vS3ByRHl+4b7ppBkPFVkREguMuTb3DbpFYOsnhcUFfE6fNEvZbF i8bd1lNpiSZrtOhG9wcbqjUbV8XoTgbYfbCapFsER6UxeV6BXWiXJvUvyd6dL/klb8 X104XXxMSmzu+xJ88ZDNUUEgpTybAUqvkNEYYh7k=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1359508062; i=@resistor.net; bh=ADYBbsnpAYYRbhBlSMdc7F1V0NdpK6IUwKZXLOp15dg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ad1lx2IwijP5sfveyQO0/QHOMiKAJHi+phmlXUPuHV4IOH4Cv1hjv4Ih2Kh5R+t5s M+/aLsnDplo1P0mqPhUqUM9qKaSWlNapWtCoNZKyM02QRH/hfgJJ+46q7lEdtlfbwD /u+0B0peMoU4MesLOEwgnq6ZMDOcTQv1TIu7p1qk=
Message-Id: <6.2.5.6.2.20130129164023.09760e40@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 29 Jan 2013 17:06:33 -0800
To: James M Snell 
From: SM 
In-Reply-To: 
References: <51067C1C.2050509@ericsson.com> <6.2.5.6.2.20130128104820.0a9afb08@resistor.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jan 2013 01:07:49 -0000

Hi James,
At 10:42 29-01-2013, James M Snell wrote:
>In some scenarios, such as hosted cloud application environments, a 
>service provider may wish to host the information about a given user 
>within a different domain. For instance, suppose Company Foo.com 
>utilizes services from ISV Bar.com. The user accounts, however, are 
>drawn from Foo.com, but Bar.com is the provider that actually hosts 
>the profiles and account information. What I want is something that 
>identifies the user account AND the service provider.

Section 2 of the draft mentions that:

   'The "Internet resource" identified by an 'acct' URI is a
    user's account hosted at a service provider, where the service
    provider is typically associated with a DNS domain name.'

The definition would have to be reviewed if you would like to cover 
vanity domains.  The problem could also be restated as a de-referencing issue.

Regards,
-sm 


From paulej@packetizer.com  Tue Jan 29 19:31:53 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2CB21F8447 for ; Tue, 29 Jan 2013 19:31:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.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 PjpTnbUA7sEr for ; Tue, 29 Jan 2013 19:31:52 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 681F121F8ACE for ; Tue, 29 Jan 2013 19:31:52 -0800 (PST)
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 r0U3VlL3028998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 Jan 2013 22:31:48 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1359516709; bh=hlRx8EgO3QhBySo1ZuJJ45ZRSzentJZQj8aqvsNGVR8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=VeetwG8z3aH1cIqM/ocm8d9H/zoalGMa4TPXAS8/iUcaSGMzO/B27ykQLrjIKebsC X4tH3drUyYUfgxkt9xzM9jxIzjse6nj1s/PL9q3sN878bC1ymkRLoQbxLi2YF/kiUI fd7sYCkHrIutxdKrhTEbVm9MfCtf3rxNU3o33/LE=
From: "Paul E. Jones" 
To: "'James M Snell'" , "'Salvatore Loreto'" 
References: <5106BFDC.2030706@ericsson.com> <5106C090.8080403@ericsson.com> 
In-Reply-To: 
Date: Tue, 29 Jan 2013 22:31:51 -0500
Message-ID: <039e01cdfe9a$58f17410$0ad45c30$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_039F_01CDFE70.701CCBA0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQE1BCY4ftSPh+1CSwbfjBRSkBwUGQIZkwMsAoJZMC2ZbkwAMA==
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] [webfinger] Working Group Last Call for	draft-ietf-appsawg-webfinger-09
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jan 2013 03:31:54 -0000

This is a multipart message in MIME format.

------=_NextPart_000_039F_01CDFE70.701CCBA0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

James,

=20

Since this is really an acct URI question, I think it should be =
redirected back to the apps-discuss list.

=20

One challenge I see with this kind of syntax is that the account =
information for a user is not necessarily always hosted at any certain =
provider.  Perhaps when acct: is used with WebFinger, the domain foo.com =
redirects the request to a different domain.  Perhaps for some other =
protocol that might utilize acct:, the means through which the =
information is returned is entirely different.  And what if the =
=E2=80=9Chosting provider=E2=80=9D changes next week?  I would not want =
a URI like acct:paulej@packetizer.com to become invalid simply because I =
decide to host my account information at a different provider next week.

=20

Paul

=20

From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On =
Behalf Of James M Snell
Sent: Tuesday, January 29, 2013 1:03 PM
To: Salvatore Loreto
Cc: webfinger@ietf.org
Subject: Re: [webfinger] [apps-discuss] Working Group Last Call for =
draft-ietf-appsawg-webfinger-09

=20

I'm really just now starting to turn my attention to the acct uri aspect =
of the WebFinger discussion.. generally speaking I'm +1 on the current =
draft. When going through various implementation scenarios, however, one =
thought did strike me, although it may be a bit too late in the game to =
put this on the table at all. I apologize for making this late =
suggestion...

=20

In some scenarios, such as hosted cloud application environments, a =
service provider may wish to host the information about a given user =
within a different domain. For instance, suppose Company Foo.com =
utilizes services from ISV Bar.com. The user accounts, however, are =
drawn from Foo.com, but Bar.com is the provider that actually hosts the =
profiles and account information. What I want is something that =
identifies the user account AND the service provider.=20

=20

Example:=20

=20

  acct:john.doe@foo.com?provider=3Dbar.com

=20

In a WebFinger type of scenario, resolving this would involve something =
like...

=20

  GET /.well-known/webfinger?resource=3Djohn.doe@foo.com

  Host: bar.com

=20

Encoding the third party provider into the URL in this way provides a =
fairly flexible way of enabling the third party support without =
complicated redirects from foo.com to bar.com. It also gives domains a =
way of enabling bits of information to be shared from multiple =
sources... acct:john.doe@foo.com?provider=3Disv1.com vs. =
acct:john.doe@foo.com?provider=3Disv2.com

=20

To enable this kind of thing, it would be helpful if the basic acct URI =
syntax allowed for optional parameters like the mailto URI scheme does =
(RFC2368). The specific parameters themselves can be figured out =
later...

=20

- James

=20

=20

=20

=20

=20

On Mon, Jan 28, 2013 at 10:16 AM, Salvatore Loreto =
 wrote:

FYI

the 2 weeks WGLC on draft-ietf-appsawg-webfinger is started.
Please see the mail below and note that the right venue for discussion =
is=20
the *webfinger* mailing list

best regards
Salvatore

-------- Original Message --------=20


Subject:=20

[webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09


Date:=20

Mon, 28 Jan 2013 20:13:48 +0200


From:=20

Salvatore Loreto   =



To:=20

  


CC:=20

Murray S. Kucherawy   



Dear WG partecipants,=20


I would like to initiate a 2 weeks WG Last Call on=20
draft-ietf-appsawg-webfinger-09.txt ("WebFinger")=20
http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt =
=20


Please send your reviews, as well as expression of support regarding=20
document readiness for IESG (or not) either to the *webfinger* mailing =
list (webfinger@ietf.org),=20
or directly to the WG chairs (Murray Kucherawy and myself).=20

Comments like "I've read the document and it is Ok to publish" or=20
"I've read the document and it has the following issues"
are useful and would be gratefully accepted by chairs.=20


The WG LC will end on Friday, February 8th.=20


Thank you,=20
Salvatore as an APPSAWG co-chair.=20




=20


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

=20


------=_NextPart_000_039F_01CDFE70.701CCBA0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


James,
 
Since this is really an acct URI question, I think it should be =
redirected back to the apps-discuss list.
 
One challenge I see with this kind of syntax is that the account =
information for a user is not necessarily always hosted at any certain =
provider.=C2=A0 Perhaps when acct: is used with WebFinger, the domain =
foo.com redirects the request to a different domain.=C2=A0 Perhaps for =
some other protocol that might utilize acct:, the means through which =
the information is returned is entirely different.=C2=A0 And what if the =
=E2=80=9Chosting provider=E2=80=9D changes next week?=C2=A0 I would not =
want a URI like acct:paulej@packetizer.com to become invalid simply =
because I decide to host my account information at a different provider =
next week.
 
Paul
 
From:=
 =
webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On =
Behalf Of James M Snell
Sent: Tuesday, January 29, 2013 =
1:03 PM
To: Salvatore Loreto
Cc: =
webfinger@ietf.org
Subject: Re: [webfinger] [apps-discuss] =
Working Group Last Call for =
draft-ietf-appsawg-webfinger-09
 
I'm really just now starting to turn =
my attention to the acct uri aspect of the WebFinger discussion.. =
generally speaking I'm +1 on the current draft. When going through =
various implementation scenarios, however, one thought did strike me, =
although it may be a bit too late in the game to put this on the table =
at all. I apologize for making this late =
suggestion...
 
In some =
scenarios, such as hosted cloud application environments, a service =
provider may wish to host the information about a given user within a =
different domain. For instance, suppose Company Foo.com utilizes =
services from ISV Bar.com. The user accounts, however, are drawn from =
Foo.com, but Bar.com is the provider that actually hosts the profiles =
and account information. What I want is something that identifies the =
user account AND the service =
provider. 
 
Example: 
 
 
In a =
WebFinger type of scenario, resolving this would involve something =
like...
 
  GET =
/.well-known/webfinger?resource=3Djohn.doe@foo.com
  Host: bar.com
 
Encoding the =
third party provider into the URL in this way provides a fairly flexible =
way of enabling the third party support without complicated redirects =
from foo.com to bar.com. It also gives domains a way of =
enabling bits of information to be shared from multiple sources... acct:john.doe@f=
oo.com?provider=3Disv1.com vs. acct:john.doe@f=
oo.com?provider=3Disv2.com
 
To enable =
this kind of thing, it would be helpful if the basic acct URI syntax =
allowed for optional parameters like the mailto URI scheme does =
(RFC2368). The specific parameters themselves can be figured out =
later...
 
- =
James
 
 
 
 
 
On Mon, Jan 28, 2013 at 10:16 AM, Salvatore Loreto =
<salvatore.loreto@ericsson.com> =
wrote:
FYI
the 2 weeks WGLC on draft-ietf-appsawg-webfinger is =
started.
Please see the mail below and note that the right venue for =
discussion is 
the *webfinger* mailing list

best =
regards
Salvatore

-------- Original Message -------- =

=

Subject: 
[webfinger] =
Working Group Last Call for =
draft-ietf-appsawg-webfinger-09
Date: =

Mon, 28 Jan 2013 20:13:48 =
+0200
From: 
Salvatore Loreto =
<salvatore.loreto@ericsson.com>
To: 
<webfinger@ietf.org>
CC: =

Murray S. Kucherawy <superuser@gmail.com>


Dear WG partecipants, =



I would like to initiate a 2 weeks WG Last Call on =

draft-ietf-appsawg-webfinger-09.txt ("WebFinger") 
http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-0=
9.txt


Please send your reviews, as well as expression of =
support regarding 
document readiness for IESG (or not) either to the =
*webfinger* mailing list (webfinger@ietf.org), 
or directly to the WG =
chairs (Murray Kucherawy and myself). 

Comments like "I've =
read the document and it is Ok to publish" or 
"I've read =
the document and it has the following issues"
are useful and =
would be gratefully accepted by chairs. 


The WG LC will end =
on Friday, February 8th. 


Thank you, 
Salvatore as an =
APPSAWG co-chair. 


 

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

------=_NextPart_000_039F_01CDFE70.701CCBA0--


From wwwrun@rfc-editor.org  Tue Jan 29 20:30:58 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8076221F8B06; Tue, 29 Jan 2013 20:30:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.357
X-Spam-Level: 
X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.243, 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 snxI9Q0GiNm8; Tue, 29 Jan 2013 20:30:57 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id DE6F221F8B02; Tue, 29 Jan 2013 20:30:57 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 7101E72E12D; Tue, 29 Jan 2013 20:19:20 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20130130041920.7101E72E12D@rfc-editor.org>
Date: Tue, 29 Jan 2013 20:19:20 -0800 (PST)
Cc: apps-discuss@ietf.org, rfc-editor@rfc-editor.org
Subject: [apps-discuss] BCP 13, RFC 6838 on Media Type Specifications and Registration Procedures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jan 2013 04:30:58 -0000

A new Request for Comments is now available in online RFC libraries.

        BCP 13        
        RFC 6838

        Title:      Media Type Specifications and Registration 
                    Procedures 
        Author:     N. Freed, J. Klensin,
                    T. Hansen
        Status:     Best Current Practice
        Stream:     IETF
        Date:       January 2013
        Mailbox:    ned+ietf@mrochek.com, 
                    john+ietf@jck.com, 
                    tony+mtsuffix@maillennium.att.com
        Pages:      32
        Characters: 72942
        Obsoletes:  RFC4288
        See Also:   BCP0013

        I-D Tag:    draft-ietf-appsawg-media-type-regs-14.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6838.txt

This document defines procedures for the specification and
registration of media types for use in HTTP, MIME, and other Internet
protocols.  This memo documents an Internet Best Current Practice.

This document is a product of the Applications Area Working Group Working Group of the IETF.


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. 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 wwwrun@rfc-editor.org  Tue Jan 29 20:31:36 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC0B21F8B20; Tue, 29 Jan 2013 20:31:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.364
X-Spam-Level: 
X-Spam-Status: No, score=-102.364 tagged_above=-999 required=5 tests=[AWL=0.236, 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 3-POnH7BGIUn; Tue, 29 Jan 2013 20:31:36 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0390D21F8B1D; Tue, 29 Jan 2013 20:31:36 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 2BCF172E13D; Tue, 29 Jan 2013 20:19:49 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20130130041949.2BCF172E13D@rfc-editor.org>
Date: Tue, 29 Jan 2013 20:19:49 -0800 (PST)
Cc: apps-discuss@ietf.org, rfc-editor@rfc-editor.org
Subject: [apps-discuss] RFC 6839 on Additional Media Type Structured Syntax Suffixes
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jan 2013 04:31:36 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6839

        Title:      Additional Media Type Structured Syntax 
                    Suffixes 
        Author:     T. Hansen, A. Melnikov
        Status:     Informational
        Stream:     IETF
        Date:       January 2013
        Mailbox:    tony+sss@maillennium.att.com, 
                    Alexey.Melnikov@isode.com
        Pages:      14
        Characters: 26071
        Updates:    RFC3023

        I-D Tag:    draft-ietf-appsawg-media-type-suffix-regs-08.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6839.txt

A content media type name sometimes includes partitioned meta-
information distinguished 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 provides a media type structured syntax suffix
registration form for the "+xml" structured syntax suffix.  This document 
is not an Internet Standards Track specification; it is published for 
informational purposes.

This document is a product of the Applications Area Working Group Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. 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 salvatore.loreto@ericsson.com  Wed Jan 30 00:41:16 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6D921F8792 for ; Wed, 30 Jan 2013 00:41:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.248
X-Spam-Level: 
X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 YBJ78U7+Mjgn for ; Wed, 30 Jan 2013 00:41:14 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0A94F21F8777 for ; Wed, 30 Jan 2013 00:41:13 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-f9-5108dca8fa07
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6B.27.10459.8ACD8015; Wed, 30 Jan 2013 09:41:13 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Wed, 30 Jan 2013 09:41:12 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 448A92AD5; Wed, 30 Jan 2013 10:41:12 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 72BBA5406B; Wed, 30 Jan 2013 10:41:10 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0789853D5A; Wed, 30 Jan 2013 10:41:09 +0200 (EET)
Message-ID: <5108DCA7.5090606@ericsson.com>
Date: Wed, 30 Jan 2013 10:41:11 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: 'James M Snell' 
References: <5106BFDC.2030706@ericsson.com> <5106C090.8080403@ericsson.com>  <039e01cdfe9a$58f17410$0ad45c30$@packetizer.com>
In-Reply-To: <039e01cdfe9a$58f17410$0ad45c30$@packetizer.com>
Content-Type: multipart/alternative; boundary="------------080904030207010500010001"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+Jvre7KOxyBBjsPcFusfrmCzeLRpB4W i/MXNjA5MHvsnHWX3WPJkp9MHg37jrIHMEdx2aSk5mSWpRbp2yVwZTz6e4+9YPtJxoon/b9Y GxgXtzN2MXJySAiYSLxfeJYJwhaTuHBvPVsXIxeHkMBJRol337ewQzgbGCWaPrazQDi7GCXO Xr7DBOGsZZT4s381lLONUWLKrp3MIMN4BbQlPr2ZwQJiswioSrybtAwsziZgJvH84RYwW1Qg WeLjnWusEPWCEidnPgGrFxFQl7i9cCGQzcHBLOAkcbZTEiQsDFS+7lgr1EkHGSWOHTnHBpLg FLCV2LFzLjNEfZjEwQ+lEP+oSVw9twlslZCAlkTv2U6mCYwis5Bsm4XQARJmFrCQWPzmIDuE LS/RvHU2M4StIbHgzj5GZPEFjGyrGNlzEzNz0ssNNzEC4+fglt+6OxhPnRM5xCjNwaIkzhvm eiFASCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2OYrNKPSc9PVXLM8vxiFyfgz6mX81Lkrt4V 9wRvU/ebRfn9/cWBEr8C3NOj7m9JLG4P+Z+y48FKb1NL+eYJhxr+XilQelzd0+0eGshmnWm6 MimzIlrjeO/zn3w83dKzFLIaX77JVe4qzesT8TkjwddUs0RHLnGPzdXoKwGGNVcmrUp8c/m8 EktxRqKhFnNRcSIAS1nmBm0CAAA=
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] [webfinger] Working Group Last Call for	draft-ietf-appsawg-webfinger-09
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jan 2013 08:41:16 -0000

--------------080904030207010500010001
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit


in principle I am not against to allow the basic 'acct' URI syntax for 
optional parameter.

However I am not convinced of the need to specify one for the actual 
cloud provider
for several reasons:
- the actual cloud provider can change over the time
- one user can decide to host different services to different cloud 
providers
- if a user has to provide the 'acct' URI with the 'provide' parameter
I don't understand the advantage to disclosure 
acct:john.doe@foo.com?provider=isv1.com 

vs disclosing directly acct:john.doe@isv1.com 


/Salvatore


On 1/30/13 5:31 AM, Paul E. Jones wrote:
>
> James,
>
> Since this is really an acct URI question, I think it should be 
> redirected back to the apps-discuss list.
>
> One challenge I see with this kind of syntax is that the account 
> information for a user is not necessarily always hosted at any certain 
> provider.  Perhaps when acct: is used with WebFinger, the domain 
> foo.com redirects the request to a different domain.  Perhaps for some 
> other protocol that might utilize acct:, the means through which the 
> information is returned is entirely different.  And what if the 
> “hosting provider†changes next week?  I would not want a URI like 
> acct:paulej@packetizer.com to become invalid simply because I decide 
> to host my account information at a different provider next week.
>
> Paul
>
> *From:*webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] 
> *On Behalf Of *James M Snell
> *Sent:* Tuesday, January 29, 2013 1:03 PM
> *To:* Salvatore Loreto
> *Cc:* webfinger@ietf.org
> *Subject:* Re: [webfinger] [apps-discuss] Working Group Last Call for 
> draft-ietf-appsawg-webfinger-09
>
> I'm really just now starting to turn my attention to the acct uri 
> aspect of the WebFinger discussion.. generally speaking I'm +1 on the 
> current draft. When going through various implementation scenarios, 
> however, one thought did strike me, although it may be a bit too late 
> in the game to put this on the table at all. I apologize for making 
> this late suggestion...
>
> In some scenarios, such as hosted cloud application environments, a 
> service provider may wish to host the information about a given user 
> within a different domain. For instance, suppose Company Foo.com 
> utilizes services from ISV Bar.com. The user accounts, however, are 
> drawn from Foo.com, but Bar.com is the provider that actually hosts 
> the profiles and account information. What I want is something that 
> identifies the user account AND the service provider.
>
> Example:
>
> acct:john.doe@foo.com?provider=bar.com 
> 
>
> In a WebFinger type of scenario, resolving this would involve 
> something like...
>
>   GET /.well-known/webfinger?resource=john.doe@foo.com 
> 
>
>   Host: bar.com 
>
> Encoding the third party provider into the URL in this way provides a 
> fairly flexible way of enabling the third party support without 
> complicated redirects from foo.com  to bar.com 
> . It also gives domains a way of enabling bits of 
> information to be shared from multiple sources... 
> acct:john.doe@foo.com?provider=isv1.com 
>  vs. 
> acct:john.doe@foo.com?provider=isv2.com 
> 
>
> To enable this kind of thing, it would be helpful if the basic acct 
> URI syntax allowed for optional parameters like the mailto URI scheme 
> does (RFC2368). The specific parameters themselves can be figured out 
> later...
>
> - James
>
> On Mon, Jan 28, 2013 at 10:16 AM, Salvatore Loreto 
> > 
> wrote:
>
> FYI
>
> the 2 weeks WGLC on draft-ietf-appsawg-webfinger is started.
> Please see the mail below and note that the right venue for discussion is
> the *webfinger* mailing list
>
> best regards
> Salvatore
>
> -------- Original Message --------
>
> *Subject: *
>
> 	
>
> [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09
>
> *Date: *
>
> 	
>
> Mon, 28 Jan 2013 20:13:48 +0200
>
> *From: *
>
> 	
>
> Salvatore Loreto  
> 
>
> *To: *
>
> 	
>
>  
>
> *CC: *
>
> 	
>
> Murray S. Kucherawy  
>
>
>
> Dear WG partecipants,
>
>
> I would like to initiate a 2 weeks WG Last Call on
> draft-ietf-appsawg-webfinger-09.txt ("WebFinger")
> http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt 
> 
>
>
> Please send your reviews, as well as expression of support regarding
> document readiness for IESG (or not) either to the **webfinger** 
> mailing list (webfinger@ietf.org ),
> or directly to the WG chairs (Murray Kucherawy and myself).
>
> Comments like "I've read the document and it is Ok to publish" or
> "I've read the document and it has the following issues"
> are useful and would be gratefully accepted by chairs.
>
>
> The WG LC will end on Friday, February 8th.
>
>
> Thank you,
> Salvatore as an APPSAWG co-chair.
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org 
> https://www.ietf.org/mailman/listinfo/apps-discuss
>


--------------080904030207010500010001
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    


      in principle I am not against to allow the basic 'acct' URI syntax
      for optional parameter.

      

      However I am not convinced of the need to specify one for the
      actual cloud provider

      for several reasons:

      - the actual cloud provider can change over the time

      - one user can decide to host different services to different
      cloud providers 

      - if a user has to provide the 'acct' URI with the 'provide'
      parameter

      I don't understand the advantage to disclosure acct:john.doe@foo.com?provider=isv1.com
      

      vs disclosing directly  acct:john.doe@isv1.com
      

      

      /Salvatore

      

      

      On 1/30/13 5:31 AM, Paul E. Jones wrote:

    

    

      
      
      
      

        
James,

        
 

        
Since
            this is really an acct URI question, I think it should be
            redirected back to the apps-discuss list.

        
 

        
One
            challenge I see with this kind of syntax is that the account
            information for a user is not necessarily always hosted at
            any certain provider.  Perhaps when acct: is used with
            WebFinger, the domain foo.com redirects the request to a
            different domain.  Perhaps for some other protocol that
            might utilize acct:, the means through which the information
            is returned is entirely different.  And what if the “hosting
            provider†changes next week?  I would not want a URI like
            acct:paulej@packetizer.com to become invalid simply because
            I decide to host my account information at a different
            provider next week.

      

    

     
    

      

        
Paul

        
 

        

          

            

              
From:
                  webfinger-bounces@ietf.org
                  [mailto:webfinger-bounces@ietf.org] On Behalf Of James
                  M Snell

                  Sent: Tuesday, January 29, 2013 1:03 PM

                  To: Salvatore Loreto

                  Cc: webfinger@ietf.org

                  Subject: Re: [webfinger] [apps-discuss] Working
                  Group Last Call for draft-ietf-appsawg-webfinger-09

            

          

          
 

          

            
I'm really just now starting to turn my
                attention to the acct uri aspect of the WebFinger
                discussion.. generally speaking I'm +1 on the current
                draft. When going through various implementation
                scenarios, however, one thought did strike me, although
                it may be a bit too late in the game to put this on the
                table at all. I apologize for making this late
                suggestion...

            

              
 

            

            

              
In some
                  scenarios, such as hosted cloud application
                  environments, a service provider may wish to host the
                  information about a given user within a different
                  domain. For instance, suppose Company Foo.com utilizes
                  services from ISV Bar.com. The user accounts, however,
                  are drawn from Foo.com, but Bar.com is the provider
                  that actually hosts the profiles and account
                  information. What I want is something that identifies
                  the user account AND the service provider. 

            

            

              
 

            

            

              
Example: 

            

            

              
 

            

            
            

              
 

            

            

              
In a
                  WebFinger type of scenario, resolving this would
                  involve something like...

            

            

              
 

            

            

              
  GET
                  /.well-known/webfinger?resource=john.doe@foo.com

            

            

              
  Host: bar.com

            

            

              
 

            

            

              
Encoding
                  the third party provider into the URL in this way
                  provides a fairly flexible way of enabling the third
                  party support without complicated redirects from foo.com
                  to bar.com.
                  It also gives domains a way of enabling bits of
                  information to be shared from multiple sources... acct:john.doe@foo.com?provider=isv1.com
                  vs. acct:john.doe@foo.com?provider=isv2.com

            

            

              
 

            

            

              
To enable
                  this kind of thing, it would be helpful if the basic
                  acct URI syntax allowed for optional parameters like
                  the mailto URI scheme does (RFC2368). The specific
                  parameters themselves can be figured out later...

            

            

              
 

            

            

              
- James

            

            

              
 

            

            

              
 

            

            

              
 

            

            

              
 

            

          

          

            
 

            

              
On Mon, Jan 28, 2013 at 10:16 AM,
                Salvatore Loreto <salvatore.loreto@ericsson.com>
                wrote:

              

                
FYI

                

                  
the 2 weeks WGLC on
                    draft-ietf-appsawg-webfinger is started.

                    Please see the mail below and note that the right
                    venue for discussion is 

                    the *webfinger* mailing list

                    

                    best regards

                    Salvatore

                    

                    -------- Original Message -------- 

                  

                    
                      

                        
                          
Subject: 

                        		
                        
                          
[webfinger] Working Group
                            Last Call for
                            draft-ietf-appsawg-webfinger-09

                        		
                      

                      

                        
                          
Date: 

                        		
                        
                          
Mon, 28 Jan 2013 20:13:48
                            +0200

                        		
                      

                      

                        
                          
From: 

                        		
                        
                          
Salvatore Loreto <salvatore.loreto@ericsson.com>

                        		
                      

                      

                        
                          
To: 

                        		
                        
                          
<webfinger@ietf.org>

                        		
                      

                      

                        
                          
CC: 

                        		
                        
                          
Murray S. Kucherawy <superuser@gmail.com>

                        		
                      

                    
                  

                  

                    

                      


                        

                        Dear WG partecipants, 

                        

                        

                        I would like to initiate a 2 weeks WG Last Call
                        on 

                        draft-ietf-appsawg-webfinger-09.txt
                        ("WebFinger") 

                        http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt

                        

                        

                        Please send your reviews, as well as expression
                        of support regarding 

                        document readiness for IESG (or not) either to
                        the *webfinger* mailing list (webfinger@ietf.org), 

                        or directly to the WG chairs (Murray Kucherawy
                        and myself). 

                        

                        Comments like "I've read the document and it is
                        Ok to publish" or 

                        "I've read the document and it has the following
                        issues"

                        are useful and would be gratefully accepted by
                        chairs. 

                        

                        

                        The WG LC will end on Friday, February 8th. 

                        

                        

                        Thank you, 

                        Salvatore as an APPSAWG co-chair. 

                        

                        

                        

                    

                  

                

                
 

              

              


                _______________________________________________

                apps-discuss mailing list

                apps-discuss@ietf.org

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

            

            
 

          

        

      

    

    

  


--------------080904030207010500010001--

From Michael.Jones@microsoft.com  Wed Jan 30 09:17:26 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBE221F8569 for ; Wed, 30 Jan 2013 09:17:26 -0800 (PST)
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 rq3OOdovM6dB for ; Wed, 30 Jan 2013 09:17:24 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.29]) by ietfa.amsl.com (Postfix) with ESMTP id AB60721F84EB for ; Wed, 30 Jan 2013 09:17:24 -0800 (PST)
Received: from BL2FFO11FD016.protection.gbl (10.173.161.204) by BL2FFO11HUB023.protection.gbl (10.173.161.47) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 30 Jan 2013 17:17:21 +0000
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD016.mail.protection.outlook.com (10.173.160.224) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 30 Jan 2013 17:17:21 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.132]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Wed, 30 Jan 2013 17:16:41 +0000
From: Mike Jones 
To: Salvatore Loreto , 'James M Snell' 
Thread-Topic: [apps-discuss] [webfinger] Working Group Last Call	for draft-ietf-appsawg-webfinger-09
Thread-Index: AQHN/pqILmYVkg4NjUmeMbolsa8irphhjeeAgACORTA=
Date: Wed, 30 Jan 2013 17:16:40 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943673E68F1@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <5106BFDC.2030706@ericsson.com> <5106C090.8080403@ericsson.com>  <039e01cdfe9a$58f17410$0ad45c30$@packetizer.com> <5108DCA7.5090606@ericsson.com>
In-Reply-To: <5108DCA7.5090606@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.34]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943673E68F1TK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(69234002)(377454001)(199002)(13464002)(479174001)(24454001)(31966008)(49866001)(44976002)(47976001)(54316002)(63696002)(74662001)(79102001)(550184003)(46102001)(47446002)(47736001)(59766001)(77982001)(5343635001)(74502001)(15202345001)(4396001)(20776003)(50986001)(5343655001)(56816002)(55846006)(56776001)(16406001)(16236675001)(54356001)(512874001)(33656001)(16601075001)(51856001)(53806001)(76482001)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB023; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0742443479
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] [webfinger] Working Group Last Call	for	draft-ietf-appsawg-webfinger-09
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jan 2013 17:17:26 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943673E68F1TK5EX14MBXC284r_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SWYgd2Ugd2VyZSB0byBzdXBwb3J0IHRoaXMsIGEgbW9yZSBjb25zaXN0ZW50IHN5bnRheCB3b3Vs
ZCBiZSB0byBhbHdheXMgaGF2ZSB0aGUgcHJvdmlkZXIgYmUgdGhlIHBhcnQgdG8gdGhlIHJpZ2h0
IG9mIHRoZSBsYXN0IOKAmEDigJkgYW5kIGhhdmUgZXZlcnl0aGluZyBlbHNlIGJlIHRoZSBhY2Nv
dW50IGlkZW50aWZpZXIgYXQgdGhlIHByb3ZpZGVyLiAgVGhlbiwgZm9yIGluc3RhbmNlLCBhY2N0
Om1iakBtaWNyb3NvZnQuY29tQGZhY2Vib29rLmNvbSB3b3VsZCBiZSBhIGxlZ2FsIGlkZW50aWZp
ZXIgZm9yIG15IEZhY2Vib29rIGFjY291bnQgYW5kIGFjY3Q6c2VsZmlzc3VlZEB0d2l0dGVyLmNv
bSB3b3VsZCBiZSBhIGxlZ2FsIGlkZW50aWZpZXIgZm9yIG15IFR3aXR0ZXIgYWNjb3VudC4gIElu
IGJvdGggY2FzZXMsIHRoZSBwcm92aWRlciBpcyB0aGUgcGFydCBhZnRlciB0aGUgbGFzdCDigJhA
4oCZLg0KDQpJ4oCZbSBub3QgY2VydGFpbiB0aGlzIGlzIG5lZWRlZCwgYnV0IHdvdWxkIHByZWZl
ciB0aGUg4oCYQOKAmSBzeW50YXggdG8gdGhlIOKAmD/igJkgc3ludGF4LCBpZiB3ZSBkbyB3YW50
IHRvIHN1cHBvcnQgYWNjb3VudCBpZGVudGlmaWVycyBvZiB0aGUgZm9ybSB1c2VyQGRvbWFpbiB3
aXRoIGEgcHJvdmlkZXIgYmVpbmcgc3BlY2lmaWVkIHRoYXTigJlzIGRpZmZlcmVudCB0aGFuIHRo
ZSBkb21haW4uICBXaGVyZWFzIGludHJvZHVjaW5nIHRoZSBmdWxsIOKAmD/igJkgc3ludGF4IHNl
ZW1zIGxpa2Ugb3ZlcmtpbGwsIGFuZCBJIHdvdWxkIGJlIGFnYWluc3QgdGhhdC4NCg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0g
TWlrZQ0KDQpGcm9tOiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMt
ZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2FsdmF0b3JlIExvcmV0bw0K
U2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDMwLCAyMDEzIDEyOjQxIEFNDQpUbzogJ0phbWVzIE0g
U25lbGwnDQpDYzogYXBwcy1kaXNjdXNzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2FwcHMtZGlz
Y3Vzc10gW3dlYmZpbmdlcl0gV29ya2luZyBHcm91cCBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYt
YXBwc2F3Zy13ZWJmaW5nZXItMDkNCg0KDQppbiBwcmluY2lwbGUgSSBhbSBub3QgYWdhaW5zdCB0
byBhbGxvdyB0aGUgYmFzaWMgJ2FjY3QnIFVSSSBzeW50YXggZm9yIG9wdGlvbmFsIHBhcmFtZXRl
ci4NCg0KSG93ZXZlciBJIGFtIG5vdCBjb252aW5jZWQgb2YgdGhlIG5lZWQgdG8gc3BlY2lmeSBv
bmUgZm9yIHRoZSBhY3R1YWwgY2xvdWQgcHJvdmlkZXINCmZvciBzZXZlcmFsIHJlYXNvbnM6DQot
IHRoZSBhY3R1YWwgY2xvdWQgcHJvdmlkZXIgY2FuIGNoYW5nZSBvdmVyIHRoZSB0aW1lDQotIG9u
ZSB1c2VyIGNhbiBkZWNpZGUgdG8gaG9zdCBkaWZmZXJlbnQgc2VydmljZXMgdG8gZGlmZmVyZW50
IGNsb3VkIHByb3ZpZGVycw0KLSBpZiBhIHVzZXIgaGFzIHRvIHByb3ZpZGUgdGhlICdhY2N0JyBV
Ukkgd2l0aCB0aGUgJ3Byb3ZpZGUnIHBhcmFtZXRlcg0KSSBkb24ndCB1bmRlcnN0YW5kIHRoZSBh
ZHZhbnRhZ2UgdG8gZGlzY2xvc3VyZSBhY2N0OmpvaG4uZG9lQGZvby5jb20/cHJvdmlkZXI9aXN2
MS5jb208aHR0cDovL2FjY3Q6am9obi5kb2VAZm9vLmNvbT9wcm92aWRlcj1pc3YxLmNvbT4NCnZz
IGRpc2Nsb3NpbmcgZGlyZWN0bHkgIGFjY3Q6am9obi5kb2VAaXN2MS5jb208aHR0cDovL2FjY3Q6
am9obi5kb2VAZm9vLmNvbT9wcm92aWRlcj1pc3YxLmNvbT4NCg0KL1NhbHZhdG9yZQ0KDQoNCk9u
IDEvMzAvMTMgNTozMSBBTSwgUGF1bCBFLiBKb25lcyB3cm90ZToNCkphbWVzLA0KDQpTaW5jZSB0
aGlzIGlzIHJlYWxseSBhbiBhY2N0IFVSSSBxdWVzdGlvbiwgSSB0aGluayBpdCBzaG91bGQgYmUg
cmVkaXJlY3RlZCBiYWNrIHRvIHRoZSBhcHBzLWRpc2N1c3MgbGlzdC4NCg0KT25lIGNoYWxsZW5n
ZSBJIHNlZSB3aXRoIHRoaXMga2luZCBvZiBzeW50YXggaXMgdGhhdCB0aGUgYWNjb3VudCBpbmZv
cm1hdGlvbiBmb3IgYSB1c2VyIGlzIG5vdCBuZWNlc3NhcmlseSBhbHdheXMgaG9zdGVkIGF0IGFu
eSBjZXJ0YWluIHByb3ZpZGVyLiAgUGVyaGFwcyB3aGVuIGFjY3Q6IGlzIHVzZWQgd2l0aCBXZWJG
aW5nZXIsIHRoZSBkb21haW4gZm9vLmNvbSByZWRpcmVjdHMgdGhlIHJlcXVlc3QgdG8gYSBkaWZm
ZXJlbnQgZG9tYWluLiAgUGVyaGFwcyBmb3Igc29tZSBvdGhlciBwcm90b2NvbCB0aGF0IG1pZ2h0
IHV0aWxpemUgYWNjdDosIHRoZSBtZWFucyB0aHJvdWdoIHdoaWNoIHRoZSBpbmZvcm1hdGlvbiBp
cyByZXR1cm5lZCBpcyBlbnRpcmVseSBkaWZmZXJlbnQuICBBbmQgd2hhdCBpZiB0aGUg4oCcaG9z
dGluZyBwcm92aWRlcuKAnSBjaGFuZ2VzIG5leHQgd2Vlaz8gIEkgd291bGQgbm90IHdhbnQgYSBV
UkkgbGlrZSBhY2N0OnBhdWxlakBwYWNrZXRpemVyLmNvbTxtYWlsdG86YWNjdDpwYXVsZWpAcGFj
a2V0aXplci5jb20+IHRvIGJlY29tZSBpbnZhbGlkIHNpbXBseSBiZWNhdXNlIEkgZGVjaWRlIHRv
IGhvc3QgbXkgYWNjb3VudCBpbmZvcm1hdGlvbiBhdCBhIGRpZmZlcmVudCBwcm92aWRlciBuZXh0
IHdlZWsuDQoNClBhdWwNCg0KRnJvbTogd2ViZmluZ2VyLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv
OndlYmZpbmdlci1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOndlYmZpbmdlci1ib3VuY2VzQGll
dGYub3JnXSBPbiBCZWhhbGYgT2YgSmFtZXMgTSBTbmVsbA0KU2VudDogVHVlc2RheSwgSmFudWFy
eSAyOSwgMjAxMyAxOjAzIFBNDQpUbzogU2FsdmF0b3JlIExvcmV0bw0KQ2M6IHdlYmZpbmdlckBp
ZXRmLm9yZzxtYWlsdG86d2ViZmluZ2VyQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt3ZWJmaW5n
ZXJdIFthcHBzLWRpc2N1c3NdIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRm
LWFwcHNhd2ctd2ViZmluZ2VyLTA5DQoNCkknbSByZWFsbHkganVzdCBub3cgc3RhcnRpbmcgdG8g
dHVybiBteSBhdHRlbnRpb24gdG8gdGhlIGFjY3QgdXJpIGFzcGVjdCBvZiB0aGUgV2ViRmluZ2Vy
IGRpc2N1c3Npb24uLiBnZW5lcmFsbHkgc3BlYWtpbmcgSSdtICsxIG9uIHRoZSBjdXJyZW50IGRy
YWZ0LiBXaGVuIGdvaW5nIHRocm91Z2ggdmFyaW91cyBpbXBsZW1lbnRhdGlvbiBzY2VuYXJpb3Ms
IGhvd2V2ZXIsIG9uZSB0aG91Z2h0IGRpZCBzdHJpa2UgbWUsIGFsdGhvdWdoIGl0IG1heSBiZSBh
IGJpdCB0b28gbGF0ZSBpbiB0aGUgZ2FtZSB0byBwdXQgdGhpcyBvbiB0aGUgdGFibGUgYXQgYWxs
LiBJIGFwb2xvZ2l6ZSBmb3IgbWFraW5nIHRoaXMgbGF0ZSBzdWdnZXN0aW9uLi4uDQoNCkluIHNv
bWUgc2NlbmFyaW9zLCBzdWNoIGFzIGhvc3RlZCBjbG91ZCBhcHBsaWNhdGlvbiBlbnZpcm9ubWVu
dHMsIGEgc2VydmljZSBwcm92aWRlciBtYXkgd2lzaCB0byBob3N0IHRoZSBpbmZvcm1hdGlvbiBh
Ym91dCBhIGdpdmVuIHVzZXIgd2l0aGluIGEgZGlmZmVyZW50IGRvbWFpbi4gRm9yIGluc3RhbmNl
LCBzdXBwb3NlIENvbXBhbnkgRm9vLmNvbSB1dGlsaXplcyBzZXJ2aWNlcyBmcm9tIElTViBCYXIu
Y29tLiBUaGUgdXNlciBhY2NvdW50cywgaG93ZXZlciwgYXJlIGRyYXduIGZyb20gRm9vLmNvbSwg
YnV0IEJhci5jb20gaXMgdGhlIHByb3ZpZGVyIHRoYXQgYWN0dWFsbHkgaG9zdHMgdGhlIHByb2Zp
bGVzIGFuZCBhY2NvdW50IGluZm9ybWF0aW9uLiBXaGF0IEkgd2FudCBpcyBzb21ldGhpbmcgdGhh
dCBpZGVudGlmaWVzIHRoZSB1c2VyIGFjY291bnQgQU5EIHRoZSBzZXJ2aWNlIHByb3ZpZGVyLg0K
DQpFeGFtcGxlOg0KDQogIGFjY3Q6am9obi5kb2VAZm9vLmNvbT9wcm92aWRlcj1iYXIuY29tPGh0
dHA6Ly9hY2N0OmpvaG4uZG9lQGZvby5jb20/cHJvdmlkZXI9YmFyLmNvbT4NCg0KSW4gYSBXZWJG
aW5nZXIgdHlwZSBvZiBzY2VuYXJpbywgcmVzb2x2aW5nIHRoaXMgd291bGQgaW52b2x2ZSBzb21l
dGhpbmcgbGlrZS4uLg0KDQogIEdFVCAvLndlbGwta25vd24vd2ViZmluZ2VyP3Jlc291cmNlPWpv
aG4uZG9lQGZvby5jb208bWFpbHRvOmpvaG4uZG9lQGZvby5jb20+DQogIEhvc3Q6IGJhci5jb208
aHR0cDovL2Jhci5jb20+DQoNCkVuY29kaW5nIHRoZSB0aGlyZCBwYXJ0eSBwcm92aWRlciBpbnRv
IHRoZSBVUkwgaW4gdGhpcyB3YXkgcHJvdmlkZXMgYSBmYWlybHkgZmxleGlibGUgd2F5IG9mIGVu
YWJsaW5nIHRoZSB0aGlyZCBwYXJ0eSBzdXBwb3J0IHdpdGhvdXQgY29tcGxpY2F0ZWQgcmVkaXJl
Y3RzIGZyb20gZm9vLmNvbTxodHRwOi8vZm9vLmNvbT4gdG8gYmFyLmNvbTxodHRwOi8vYmFyLmNv
bT4uIEl0IGFsc28gZ2l2ZXMgZG9tYWlucyBhIHdheSBvZiBlbmFibGluZyBiaXRzIG9mIGluZm9y
bWF0aW9uIHRvIGJlIHNoYXJlZCBmcm9tIG11bHRpcGxlIHNvdXJjZXMuLi4gYWNjdDpqb2huLmRv
ZUBmb28uY29tP3Byb3ZpZGVyPWlzdjEuY29tPGh0dHA6Ly9hY2N0OmpvaG4uZG9lQGZvby5jb20/
cHJvdmlkZXI9aXN2MS5jb20+IHZzLiBhY2N0OmpvaG4uZG9lQGZvby5jb20/cHJvdmlkZXI9aXN2
Mi5jb208aHR0cDovL2FjY3Q6am9obi5kb2VAZm9vLmNvbT9wcm92aWRlcj1pc3YyLmNvbT4NCg0K
VG8gZW5hYmxlIHRoaXMga2luZCBvZiB0aGluZywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB0aGUg
YmFzaWMgYWNjdCBVUkkgc3ludGF4IGFsbG93ZWQgZm9yIG9wdGlvbmFsIHBhcmFtZXRlcnMgbGlr
ZSB0aGUgbWFpbHRvIFVSSSBzY2hlbWUgZG9lcyAoUkZDMjM2OCkuIFRoZSBzcGVjaWZpYyBwYXJh
bWV0ZXJzIHRoZW1zZWx2ZXMgY2FuIGJlIGZpZ3VyZWQgb3V0IGxhdGVyLi4uDQoNCi0gSmFtZXMN
Cg0KDQoNCg0KDQpPbiBNb24sIEphbiAyOCwgMjAxMyBhdCAxMDoxNiBBTSwgU2FsdmF0b3JlIExv
cmV0byA8c2FsdmF0b3JlLmxvcmV0b0Blcmljc3Nvbi5jb208bWFpbHRvOnNhbHZhdG9yZS5sb3Jl
dG9AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpGWUkNCnRoZSAyIHdlZWtzIFdHTEMgb24gZHJhZnQt
aWV0Zi1hcHBzYXdnLXdlYmZpbmdlciBpcyBzdGFydGVkLg0KUGxlYXNlIHNlZSB0aGUgbWFpbCBi
ZWxvdyBhbmQgbm90ZSB0aGF0IHRoZSByaWdodCB2ZW51ZSBmb3IgZGlzY3Vzc2lvbiBpcw0KdGhl
ICp3ZWJmaW5nZXIqIG1haWxpbmcgbGlzdA0KDQpiZXN0IHJlZ2FyZHMNClNhbHZhdG9yZQ0KDQot
LS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0Og0KDQpbd2ViZmluZ2Vy
XSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdl
ci0wOQ0KDQpEYXRlOg0KDQpNb24sIDI4IEphbiAyMDEzIDIwOjEzOjQ4ICswMjAwDQoNCkZyb206
DQoNClNhbHZhdG9yZSBMb3JldG8gPHNhbHZhdG9yZS5sb3JldG9AZXJpY3Nzb24uY29tPjxtYWls
dG86c2FsdmF0b3JlLmxvcmV0b0Blcmljc3Nvbi5jb20+DQoNClRvOg0KDQo8d2ViZmluZ2VyQGll
dGYub3JnPjxtYWlsdG86d2ViZmluZ2VyQGlldGYub3JnPg0KDQpDQzoNCg0KTXVycmF5IFMuIEt1
Y2hlcmF3eSA8c3VwZXJ1c2VyQGdtYWlsLmNvbT48bWFpbHRvOnN1cGVydXNlckBnbWFpbC5jb20+
DQoNCg0KDQpEZWFyIFdHIHBhcnRlY2lwYW50cywNCg0KDQpJIHdvdWxkIGxpa2UgdG8gaW5pdGlh
dGUgYSAyIHdlZWtzIFdHIExhc3QgQ2FsbCBvbg0KZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdl
ci0wOS50eHQgKCJXZWJGaW5nZXIiKQ0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWll
dGYtYXBwc2F3Zy13ZWJmaW5nZXItMDkudHh0PGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFm
dC1pZXRmLWFwcHNhd2ctYWNjdC11cmktMDIudHh0Pg0KDQoNClBsZWFzZSBzZW5kIHlvdXIgcmV2
aWV3cywgYXMgd2VsbCBhcyBleHByZXNzaW9uIG9mIHN1cHBvcnQgcmVnYXJkaW5nDQpkb2N1bWVu
dCByZWFkaW5lc3MgZm9yIElFU0cgKG9yIG5vdCkgZWl0aGVyIHRvIHRoZSAqd2ViZmluZ2VyKiBt
YWlsaW5nIGxpc3QgKHdlYmZpbmdlckBpZXRmLm9yZzxtYWlsdG86d2ViZmluZ2VyQGlldGYub3Jn
PiksDQpvciBkaXJlY3RseSB0byB0aGUgV0cgY2hhaXJzIChNdXJyYXkgS3VjaGVyYXd5IGFuZCBt
eXNlbGYpLg0KDQpDb21tZW50cyBsaWtlICJJJ3ZlIHJlYWQgdGhlIGRvY3VtZW50IGFuZCBpdCBp
cyBPayB0byBwdWJsaXNoIiBvcg0KIkkndmUgcmVhZCB0aGUgZG9jdW1lbnQgYW5kIGl0IGhhcyB0
aGUgZm9sbG93aW5nIGlzc3VlcyINCmFyZSB1c2VmdWwgYW5kIHdvdWxkIGJlIGdyYXRlZnVsbHkg
YWNjZXB0ZWQgYnkgY2hhaXJzLg0KDQoNClRoZSBXRyBMQyB3aWxsIGVuZCBvbiBGcmlkYXksIEZl
YnJ1YXJ5IDh0aC4NCg0KDQpUaGFuayB5b3UsDQpTYWx2YXRvcmUgYXMgYW4gQVBQU0FXRyBjby1j
aGFpci4NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdA0KYXBwcy1kaXNjdXNzQGlldGYub3Jn
PG1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw0KDQoNCg==

--_000_4E1F6AAD24975D4BA5B1680429673943673E68F1TK5EX14MBXC284r_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29s
b3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz
aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0
YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6
IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE3
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5
bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxl
LW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt
c2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl
OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ
e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk
aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4
PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i
MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5
IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+
DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHdlIHdlcmUgdG8gc3VwcG9y
dCB0aGlzLCBhIG1vcmUgY29uc2lzdGVudCBzeW50YXggd291bGQgYmUgdG8gYWx3YXlzIGhhdmUg
dGhlIHByb3ZpZGVyIGJlIHRoZSBwYXJ0IHRvIHRoZSByaWdodCBvZiB0aGUgbGFzdCDigJhA4oCZ
IGFuZCBoYXZlIGV2ZXJ5dGhpbmcgZWxzZQ0KIGJlIHRoZSBhY2NvdW50IGlkZW50aWZpZXIgYXQg
dGhlIHByb3ZpZGVyLiZuYnNwOyBUaGVuLCBmb3IgaW5zdGFuY2UsIGFjY3Q6bWJqQG1pY3Jvc29m
dC5jb21AZmFjZWJvb2suY29tIHdvdWxkIGJlIGEgbGVnYWwgaWRlbnRpZmllciBmb3IgbXkgRmFj
ZWJvb2sgYWNjb3VudCBhbmQgYWNjdDpzZWxmaXNzdWVkQHR3aXR0ZXIuY29tIHdvdWxkIGJlIGEg
bGVnYWwgaWRlbnRpZmllciBmb3IgbXkgVHdpdHRlciBhY2NvdW50LiZuYnNwOyBJbiBib3RoIGNh
c2VzLCB0aGUNCiBwcm92aWRlciBpcyB0aGUgcGFydCBhZnRlciB0aGUgbGFzdCDigJhA4oCZLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+SeKAmW0gbm90IGNlcnRhaW4gdGhpcyBpcyBuZWVkZWQsIGJ1dCB3b3VsZCBwcmVm
ZXIgdGhlIOKAmEDigJkgc3ludGF4IHRvIHRoZSDigJg/4oCZIHN5bnRheCwgaWYgd2UgZG8gd2Fu
dCB0byBzdXBwb3J0IGFjY291bnQgaWRlbnRpZmllcnMgb2YgdGhlIGZvcm0gdXNlckBkb21haW4g
d2l0aA0KIGEgcHJvdmlkZXIgYmVpbmcgc3BlY2lmaWVkIHRoYXTigJlzIGRpZmZlcmVudCB0aGFu
IHRoZSBkb21haW4uJm5ic3A7IFdoZXJlYXMgaW50cm9kdWNpbmcgdGhlIGZ1bGwg4oCYP+KAmSBz
eW50YXggc2VlbXMgbGlrZSBvdmVya2lsbCwgYW5kIEkgd291bGQgYmUgYWdhaW5zdCB0aGF0Ljxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw
aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gYXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmcg
W21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8
L2I+U2FsdmF0b3JlIExvcmV0bzxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkg
MzAsIDIwMTMgMTI6NDEgQU08YnI+DQo8Yj5Ubzo8L2I+ICdKYW1lcyBNIFNuZWxsJzxicj4NCjxi
PkNjOjwvYj4gYXBwcy1kaXNjdXNzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb
YXBwcy1kaXNjdXNzXSBbd2ViZmluZ2VyXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgZHJh
ZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0wOTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQppbiBwcmluY2lwbGUgSSBhbSBub3QgYWdh
aW5zdCB0byBhbGxvdyB0aGUgYmFzaWMgJ2FjY3QnIFVSSSBzeW50YXggZm9yIG9wdGlvbmFsIHBh
cmFtZXRlci48YnI+DQo8YnI+DQpIb3dldmVyIEkgYW0gbm90IGNvbnZpbmNlZCBvZiB0aGUgbmVl
ZCB0byBzcGVjaWZ5IG9uZSBmb3IgdGhlIGFjdHVhbCBjbG91ZCBwcm92aWRlcjxicj4NCmZvciBz
ZXZlcmFsIHJlYXNvbnM6PGJyPg0KLSB0aGUgYWN0dWFsIGNsb3VkIHByb3ZpZGVyIGNhbiBjaGFu
Z2Ugb3ZlciB0aGUgdGltZTxicj4NCi0gb25lIHVzZXIgY2FuIGRlY2lkZSB0byBob3N0IGRpZmZl
cmVudCBzZXJ2aWNlcyB0byBkaWZmZXJlbnQgY2xvdWQgcHJvdmlkZXJzIDxicj4NCi0gaWYgYSB1
c2VyIGhhcyB0byBwcm92aWRlIHRoZSAnYWNjdCcgVVJJIHdpdGggdGhlICdwcm92aWRlJyBwYXJh
bWV0ZXI8YnI+DQpJIGRvbid0IHVuZGVyc3RhbmQgdGhlIGFkdmFudGFnZSB0byBkaXNjbG9zdXJl
IDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtz
ZXJpZiZxdW90OyI+DQo8YSBocmVmPSJodHRwOi8vYWNjdDpqb2huLmRvZUBmb28uY29tP3Byb3Zp
ZGVyPWlzdjEuY29tIj5hY2N0OmpvaG4uZG9lQGZvby5jb20/cHJvdmlkZXI9aXN2MS5jb208L2E+
DQo8L3NwYW4+PGJyPg0KdnMgZGlzY2xvc2luZyBkaXJlY3RseSZuYnNwOyA8c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxh
IGhyZWY9Imh0dHA6Ly9hY2N0OmpvaG4uZG9lQGZvby5jb20/cHJvdmlkZXI9aXN2MS5jb20iPmFj
Y3Q6am9obi5kb2VAaXN2MS5jb208L2E+DQo8L3NwYW4+PGJyPg0KPGJyPg0KL1NhbHZhdG9yZTxi
cj4NCjxicj4NCjxicj4NCk9uIDEvMzAvMTMgNTozMSBBTSwgUGF1bCBFLiBKb25lcyB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFtZXMsPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaW5jZSB0
aGlzIGlzIHJlYWxseSBhbiBhY2N0IFVSSSBxdWVzdGlvbiwgSSB0aGluayBpdCBzaG91bGQgYmUg
cmVkaXJlY3RlZCBiYWNrIHRvIHRoZSBhcHBzLWRpc2N1c3MgbGlzdC48L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9uZSBj
aGFsbGVuZ2UgSSBzZWUgd2l0aCB0aGlzIGtpbmQgb2Ygc3ludGF4IGlzIHRoYXQgdGhlIGFjY291
bnQgaW5mb3JtYXRpb24gZm9yIGEgdXNlciBpcyBub3QgbmVjZXNzYXJpbHkgYWx3YXlzIGhvc3Rl
ZCBhdCBhbnkgY2VydGFpbiBwcm92aWRlci4mbmJzcDsgUGVyaGFwcyB3aGVuDQogYWNjdDogaXMg
dXNlZCB3aXRoIFdlYkZpbmdlciwgdGhlIGRvbWFpbiBmb28uY29tIHJlZGlyZWN0cyB0aGUgcmVx
dWVzdCB0byBhIGRpZmZlcmVudCBkb21haW4uJm5ic3A7IFBlcmhhcHMgZm9yIHNvbWUgb3RoZXIg
cHJvdG9jb2wgdGhhdCBtaWdodCB1dGlsaXplIGFjY3Q6LCB0aGUgbWVhbnMgdGhyb3VnaCB3aGlj
aCB0aGUgaW5mb3JtYXRpb24gaXMgcmV0dXJuZWQgaXMgZW50aXJlbHkgZGlmZmVyZW50LiZuYnNw
OyBBbmQgd2hhdCBpZiB0aGUg4oCcaG9zdGluZyBwcm92aWRlcuKAnQ0KIGNoYW5nZXMgbmV4dCB3
ZWVrPyZuYnNwOyBJIHdvdWxkIG5vdCB3YW50IGEgVVJJIGxpa2UgPGEgaHJlZj0ibWFpbHRvOmFj
Y3Q6cGF1bGVqQHBhY2tldGl6ZXIuY29tIj4NCmFjY3Q6cGF1bGVqQHBhY2tldGl6ZXIuY29tPC9h
PiB0byBiZWNvbWUgaW52YWxpZCBzaW1wbHkgYmVjYXVzZSBJIGRlY2lkZSB0byBob3N0IG15IGFj
Y291bnQgaW5mb3JtYXRpb24gYXQgYSBkaWZmZXJlbnQgcHJvdmlkZXIgbmV4dCB3ZWVrLjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+DQo8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QYXVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8
ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu
MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86d2ViZmluZ2VyLWJvdW5jZXNAaWV0Zi5v
cmciPndlYmZpbmdlci1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOndlYmZp
bmdlci1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86d2ViZmluZ2VyLWJvdW5jZXNAaWV0Zi5vcmc8
L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KYW1lcyBNIFNuZWxsPGJyPg0KPGI+U2VudDo8L2I+
IFR1ZXNkYXksIEphbnVhcnkgMjksIDIwMTMgMTowMyBQTTxicj4NCjxiPlRvOjwvYj4gU2FsdmF0
b3JlIExvcmV0bzxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOndlYmZpbmdlckBpZXRm
Lm9yZyI+d2ViZmluZ2VyQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3dl
YmZpbmdlcl0gW2FwcHMtZGlzY3Vzc10gV29ya2luZyBHcm91cCBMYXN0IENhbGwgZm9yIGRyYWZ0
LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXItMDk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JJ20gcmVhbGx5IGp1c3Qgbm93IHN0
YXJ0aW5nIHRvIHR1cm4gbXkgYXR0ZW50aW9uIHRvIHRoZSBhY2N0IHVyaSBhc3BlY3Qgb2YgdGhl
IFdlYkZpbmdlciBkaXNjdXNzaW9uLi4gZ2VuZXJhbGx5IHNwZWFraW5nIEknbSAmIzQzOzEgb24g
dGhlIGN1cnJlbnQgZHJhZnQuIFdoZW4gZ29pbmcgdGhyb3VnaCB2YXJpb3VzIGltcGxlbWVudGF0
aW9uDQogc2NlbmFyaW9zLCBob3dldmVyLCBvbmUgdGhvdWdodCBkaWQgc3RyaWtlIG1lLCBhbHRo
b3VnaCBpdCBtYXkgYmUgYSBiaXQgdG9vIGxhdGUgaW4gdGhlIGdhbWUgdG8gcHV0IHRoaXMgb24g
dGhlIHRhYmxlIGF0IGFsbC4gSSBhcG9sb2dpemUgZm9yIG1ha2luZyB0aGlzIGxhdGUgc3VnZ2Vz
dGlvbi4uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVv
dDtzZXJpZiZxdW90OyI+SW4gc29tZSBzY2VuYXJpb3MsIHN1Y2ggYXMgaG9zdGVkIGNsb3VkIGFw
cGxpY2F0aW9uIGVudmlyb25tZW50cywgYSBzZXJ2aWNlIHByb3ZpZGVyIG1heSB3aXNoIHRvIGhv
c3QgdGhlIGluZm9ybWF0aW9uIGFib3V0IGEgZ2l2ZW4gdXNlciB3aXRoaW4gYSBkaWZmZXJlbnQg
ZG9tYWluLiBGb3IgaW5zdGFuY2UsIHN1cHBvc2UgQ29tcGFueQ0KIEZvby5jb20gdXRpbGl6ZXMg
c2VydmljZXMgZnJvbSBJU1YgQmFyLmNvbS4gVGhlIHVzZXIgYWNjb3VudHMsIGhvd2V2ZXIsIGFy
ZSBkcmF3biBmcm9tIEZvby5jb20sIGJ1dCBCYXIuY29tIGlzIHRoZSBwcm92aWRlciB0aGF0IGFj
dHVhbGx5IGhvc3RzIHRoZSBwcm9maWxlcyBhbmQgYWNjb3VudCBpbmZvcm1hdGlvbi4gV2hhdCBJ
IHdhbnQgaXMgc29tZXRoaW5nIHRoYXQgaWRlbnRpZmllcyB0aGUgdXNlciBhY2NvdW50IEFORCB0
aGUgc2VydmljZQ0KIHByb3ZpZGVyLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5FeGFtcGxlOiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZx
dW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsgPGEgaHJlZj0iaHR0cDovL2FjY3Q6am9obi5kb2VAZm9v
LmNvbT9wcm92aWRlcj1iYXIuY29tIj4NCmFjY3Q6am9obi5kb2VAZm9vLmNvbT9wcm92aWRlcj1i
YXIuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JbiBhIFdlYkZpbmdlciB0eXBlIG9mIHNjZW5hcmlv
LCByZXNvbHZpbmcgdGhpcyB3b3VsZCBpbnZvbHZlIHNvbWV0aGluZyBsaWtlLi4uPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYm
cXVvdDsiPiZuYnNwOyBHRVQgLy53ZWxsLWtub3duL3dlYmZpbmdlcj9yZXNvdXJjZT08YSBocmVm
PSJtYWlsdG86am9obi5kb2VAZm9vLmNvbSI+am9obi5kb2VAZm9vLmNvbTwvYT48L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVv
dDsiPiZuYnNwOyBIb3N0OiA8YSBocmVmPSJodHRwOi8vYmFyLmNvbSI+DQpiYXIuY29tPC9hPjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90
O3NlcmlmJnF1b3Q7Ij5FbmNvZGluZyB0aGUgdGhpcmQgcGFydHkgcHJvdmlkZXIgaW50byB0aGUg
VVJMIGluIHRoaXMgd2F5IHByb3ZpZGVzIGEgZmFpcmx5IGZsZXhpYmxlIHdheSBvZiBlbmFibGlu
ZyB0aGUgdGhpcmQgcGFydHkgc3VwcG9ydCB3aXRob3V0IGNvbXBsaWNhdGVkIHJlZGlyZWN0cyBm
cm9tDQo8YSBocmVmPSJodHRwOi8vZm9vLmNvbSI+Zm9vLmNvbTwvYT4gdG8gPGEgaHJlZj0iaHR0
cDovL2Jhci5jb20iPmJhci5jb208L2E+LiBJdCBhbHNvIGdpdmVzIGRvbWFpbnMgYSB3YXkgb2Yg
ZW5hYmxpbmcgYml0cyBvZiBpbmZvcm1hdGlvbiB0byBiZSBzaGFyZWQgZnJvbSBtdWx0aXBsZSBz
b3VyY2VzLi4uDQo8YSBocmVmPSJodHRwOi8vYWNjdDpqb2huLmRvZUBmb28uY29tP3Byb3ZpZGVy
PWlzdjEuY29tIj5hY2N0OmpvaG4uZG9lQGZvby5jb20/cHJvdmlkZXI9aXN2MS5jb208L2E+IHZz
Lg0KPGEgaHJlZj0iaHR0cDovL2FjY3Q6am9obi5kb2VAZm9vLmNvbT9wcm92aWRlcj1pc3YyLmNv
bSI+YWNjdDpqb2huLmRvZUBmb28uY29tP3Byb3ZpZGVyPWlzdjIuY29tPC9hPjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1
b3Q7Ij5UbyBlbmFibGUgdGhpcyBraW5kIG9mIHRoaW5nLCBpdCB3b3VsZCBiZSBoZWxwZnVsIGlm
IHRoZSBiYXNpYyBhY2N0IFVSSSBzeW50YXggYWxsb3dlZCBmb3Igb3B0aW9uYWwgcGFyYW1ldGVy
cyBsaWtlIHRoZSBtYWlsdG8gVVJJIHNjaGVtZSBkb2VzIChSRkMyMzY4KS4gVGhlIHNwZWNpZmlj
IHBhcmFtZXRlcnMgdGhlbXNlbHZlcw0KIGNhbiBiZSBmaWd1cmVkIG91dCBsYXRlci4uLjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nl
cmlmJnF1b3Q7Ij4tIEphbWVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t
OjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+T24gTW9uLCBKYW4gMjgsIDIwMTMgYXQgMTA6MTYgQU0sIFNhbHZhdG9yZSBMb3JldG8gJmx0
OzxhIGhyZWY9Im1haWx0bzpzYWx2YXRvcmUubG9yZXRvQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPnNhbHZhdG9yZS5sb3JldG9AZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0
b206MTIuMHB0Ij5GWUk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij50aGUgMiB3ZWVrcyBXR0xDIG9uIGRyYWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXIgaXMgc3Rh
cnRlZC48YnI+DQpQbGVhc2Ugc2VlIHRoZSBtYWlsIGJlbG93IGFuZCBub3RlIHRoYXQgdGhlIHJp
Z2h0IHZlbnVlIGZvciBkaXNjdXNzaW9uIGlzIDxicj4NCnRoZSAqd2ViZmluZ2VyKiBtYWlsaW5n
IGxpc3Q8YnI+DQo8YnI+DQpiZXN0IHJlZ2FyZHM8YnI+DQpTYWx2YXRvcmU8YnI+DQo8YnI+DQot
LS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tIDxvOnA+PC9vOnA+PC9wPg0KPHRhYmxl
IGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBh
ZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5
bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu
PSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPlN1YmplY3Q6IDwvYj48bzpwPjwv
bzpwPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPlt3ZWJmaW5nZXJdIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZv
ciBkcmFmdC1pZXRmLWFwcHNhd2ctd2ViZmluZ2VyLTA5PG86cD48L286cD48L3A+DQo8L3RkPg0K
PC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBp
biAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxl
PSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5EYXRlOiA8L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0K
PHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5Nb24sIDI4IEphbiAyMDEzIDIwOjEzOjQ4ICYjNDM7MDIwMDxvOnA+PC9vOnA+PC9wPg0KPC90
ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGlu
ZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBz
dHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+RnJvbTogPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90
ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+U2FsdmF0b3JlIExvcmV0byA8YSBocmVmPSJtYWlsdG86c2FsdmF0b3JlLmxvcmV0b0Bl
cmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj4NCiZsdDtzYWx2YXRvcmUubG9yZXRvQGVyaWNz
c29uLmNvbSZndDs8L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBu
b3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0
Ij48Yj5UbzogPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzow
aW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOndl
YmZpbmdlckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPiZsdDt3ZWJmaW5nZXJAaWV0Zi5vcmcm
Z3Q7PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIi
IHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+Q0M6
IDwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAw
aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk11cnJheSBTLiBLdWNoZXJhd3kgPGEgaHJl
Zj0ibWFpbHRvOnN1cGVydXNlckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj4NCiZsdDtzdXBl
cnVzZXJAZ21haWwuY29tJmd0OzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90
Ym9keT4NCjwvdGFibGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KRGVhciBXRyBwYXJ0ZWNpcGFudHMs
IDxicj4NCjxicj4NCjxicj4NCkkgd291bGQgbGlrZSB0byBpbml0aWF0ZSBhIDIgd2Vla3MgV0cg
TGFzdCBDYWxsIG9uIDxicj4NCmRyYWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXItMDkudHh0ICgm
cXVvdDtXZWJGaW5nZXImcXVvdDspIDxicj4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y
Zy9pZC9kcmFmdC1pZXRmLWFwcHNhd2ctYWNjdC11cmktMDIudHh0IiB0YXJnZXQ9Il9ibGFuayI+
aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXItMDku
dHh0PC9hPjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBzZW5kIHlvdXIgcmV2aWV3cywgYXMgd2Vs
bCBhcyBleHByZXNzaW9uIG9mIHN1cHBvcnQgcmVnYXJkaW5nIDxicj4NCmRvY3VtZW50IHJlYWRp
bmVzcyBmb3IgSUVTRyAob3Igbm90KSBlaXRoZXIgdG8gdGhlIDxiPip3ZWJmaW5nZXIqPC9iPiBt
YWlsaW5nIGxpc3QgKDxhIGhyZWY9Im1haWx0bzp3ZWJmaW5nZXJAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj53ZWJmaW5nZXJAaWV0Zi5vcmc8L2E+KSwNCjxicj4NCm9yIGRpcmVjdGx5IHRvIHRo
ZSBXRyBjaGFpcnMgKE11cnJheSBLdWNoZXJhd3kgYW5kIG15c2VsZikuIDxicj4NCjxicj4NCkNv
bW1lbnRzIGxpa2UgJnF1b3Q7SSd2ZSByZWFkIHRoZSBkb2N1bWVudCBhbmQgaXQgaXMgT2sgdG8g
cHVibGlzaCZxdW90OyBvciA8YnI+DQomcXVvdDtJJ3ZlIHJlYWQgdGhlIGRvY3VtZW50IGFuZCBp
dCBoYXMgdGhlIGZvbGxvd2luZyBpc3N1ZXMmcXVvdDs8YnI+DQphcmUgdXNlZnVsIGFuZCB3b3Vs
ZCBiZSBncmF0ZWZ1bGx5IGFjY2VwdGVkIGJ5IGNoYWlycy4gPGJyPg0KPGJyPg0KPGJyPg0KVGhl
IFdHIExDIHdpbGwgZW5kIG9uIEZyaWRheSwgRmVicnVhcnkgOHRoLiA8YnI+DQo8YnI+DQo8YnI+
DQpUaGFuayB5b3UsIDxicj4NClNhbHZhdG9yZSBhcyBhbiBBUFBTQVdHIGNvLWNoYWlyLiA8YnI+
DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KYXBwcy1k
aXNjdXNzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3NAaWV0
Zi5vcmciPmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3VzcyIgdGFyZ2V0PSJfYmxhbmsi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzPC9hPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_4E1F6AAD24975D4BA5B1680429673943673E68F1TK5EX14MBXC284r_--

From jasnell@gmail.com  Wed Jan 30 09:34:04 2013
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A9721F8718 for ; Wed, 30 Jan 2013 09:34:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 6D-ajGMugJvA for ; Wed, 30 Jan 2013 09:34:02 -0800 (PST)
Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2541A21F8700 for ; Wed, 30 Jan 2013 09:34:02 -0800 (PST)
Received: by mail-ia0-f181.google.com with SMTP id k25so2682601iah.12 for ; Wed, 30 Jan 2013 09:34:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=8QCS9l+7WlCW570OZ3vlKy/dbQZQt8rtRaBshCnOXWE=; b=kNsKTNZoAch+Li6GjMEL/66LUZiNOvh6zNEWIp6g9r7ARHSGd8Neg4T9GIctADwFBr npjqOyrj6MQVmyzQvSmrpdCXwoto0tYsOnzxzrSdVzyK8bRD7cATN2mUspY+cbIoY8Uo eX8lAfi040QCAmqKTOucGEE6YmLt/E9x5Sg0Lo49GWY459Lil50qfHULK80gkPIkVJti MFpuLrJ+ko14CYS14RKrxrvCD+5mp/teia8Soa9upSMkagJ1C2QVFhv9+oEXzH5gL3VF J6Dw3K1K1GehkKdgaZMHLceDxgXJ4VTZVjU+ZUFDSV/OvapUTjFRAoJXRroiDzNhfDrv Kvhg==
X-Received: by 10.42.42.69 with SMTP id s5mr3686461ice.2.1359567241395; Wed, 30 Jan 2013 09:34:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.53.237 with HTTP; Wed, 30 Jan 2013 09:33:41 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943673E68F1@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <5106BFDC.2030706@ericsson.com> <5106C090.8080403@ericsson.com>  <039e01cdfe9a$58f17410$0ad45c30$@packetizer.com> <5108DCA7.5090606@ericsson.com> <4E1F6AAD24975D4BA5B1680429673943673E68F1@TK5EX14MBXC284.redmond.corp.microsoft.com>
From: James M Snell 
Date: Wed, 30 Jan 2013 09:33:41 -0800
Message-ID: 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=bcaec50fe5f578bd8004d484ea1a
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jan 2013 17:34:04 -0000

--bcaec50fe5f578bd8004d484ea1a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

First off, The ? syntax is already well established practice for many URI
structures, particularly http and mailto, it makes a lot of sense to reuse
that, particularly since many existing URI parsers will give you support
for for free.

Second, the most I am suggesting for acct uri is the allowance of optional
query parameters. I am not suggesting, right now, that we ought to change
the semantics of WebFinger's resolution... but I do want to leave the door
open for alternative resolution mechanisms later. I used the ?provider=3D
bar.com as an example of the basic motivation for the parameters, but there
very well could be other interesting parameters that are worth considering.

Hypothetically, for instance, in the future we could have something like:

  Find my blog=
!

Allowing for optional query parameters gives us more flexibility long term
without introducing significant new complexity now.

Additional responses to Salvatore's comments inline below...


On Wed, Jan 30, 2013 at 9:16 AM, Mike Jones wr=
ote:

>  If we were to support this, a more consistent syntax would be to always
> have the provider be the part to the right of the last =E2=80=98@=E2=80=
=99 and have
> everything else be the account identifier at the provider.  Then, for
> instance, acct:mbj@microsoft.com@facebook.com would be a legal identifier
> for my Facebook account and acct:selfissued@twitter.com would be a legal
> identifier for my Twitter account.  In both cases, the provider is the pa=
rt
> after the last =E2=80=98@=E2=80=99.****
>
> ** **
>
> I=E2=80=99m not certain this is needed, but would prefer the =E2=80=98@=
=E2=80=99 syntax to the =E2=80=98?=E2=80=99
> syntax, if we do want to support account identifiers of the form user@dom=
ainwith a provider being specified that=E2=80=99s different than the domain=
.  Whereas
> introducing the full =E2=80=98?=E2=80=99 syntax seems like overkill, and =
I would be against
> that.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* apps-discuss-bounces@ietf.org [mailto:
> apps-discuss-bounces@ietf.org] *On Behalf Of *Salvatore Loreto
> *Sent:* Wednesday, January 30, 2013 12:41 AM
> *To:* 'James M Snell'
> *Cc:* apps-discuss@ietf.org
> *Subject:* Re: [apps-discuss] [webfinger] Working Group Last Call for
> draft-ietf-appsawg-webfinger-09****
>
> ** **
>
>
> in principle I am not against to allow the basic 'acct' URI syntax for
> optional parameter.
>
> However I am not convinced of the need to specify one for the actual clou=
d
> provider
> for several reasons:
> - the actual cloud provider can change over the time
>

Yes, the provider can change but the base account id would not...


>  - one user can decide to host different services to different cloud
> providers
>

And a single account ID could be used a multiple cloud providers... for
instance, I use my gmail address as my login ID at quite a few locations.


>
> - if a user has to provide the 'acct' URI with the 'provide' parameter
> I don't understand the advantage to disclosure
> acct:john.doe@foo.com?provider=3Disv1.com
> vs disclosing directly  acct:john.doe@isv1.com
>

Suppose I am an ISV hosting services for two separate companies, both of
which have a user named "joe"

acct:joe@foo.com?provider=3Disv.com
acct:joe@bar.com?provider=3Disv.com

Looking at this, there are two ways of resolving each..

1. To find out information about joe@foo.com..
   a. I can send a WF request to foo.com, which redirects to isv.com, or
   b. I can send a WF request to isv.com with resource=3Djoe@foo.com
2. To find out information about joe@bar.com..
   a. I can send a WF request to bar.com, which redirects to isv.com, or
   b. I can send a WF request to isv.com with resource=3Djoe@bar.com

Again, however, this is just an example. The most I am suggesting right now
is that we allow for optional query string parameters, I am not suggesting
that we define specific parameters at this time.

- James


>
>
> /Salvatore
>
>
> On 1/30/13 5:31 AM, Paul E. Jones wrote:****
>
> James,****
>
>  ****
>
> Since this is really an acct URI question, I think it should be redirecte=
d
> back to the apps-discuss list.****
>
>  ****
>
> One challenge I see with this kind of syntax is that the account
> information for a user is not necessarily always hosted at any certain
> provider.  Perhaps when acct: is used with WebFinger, the domain foo.comr=
edirects the request to a different domain.  Perhaps for some other
> protocol that might utilize acct:, the means through which the informatio=
n
> is returned is entirely different.  And what if the =E2=80=9Chosting prov=
ider=E2=80=9D
> changes next week?  I would not want a URI like acct:paulej@packetizer.co=
mto become invalid simply because I decide to host my account information a=
t
> a different provider next week.****
>
>   ****
>
> Paul****
>
>  ****
>
> *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org]
> *On Behalf Of *James M Snell
> *Sent:* Tuesday, January 29, 2013 1:03 PM
> *To:* Salvatore Loreto
> *Cc:* webfinger@ietf.org
> *Subject:* Re: [webfinger] [apps-discuss] Working Group Last Call for
> draft-ietf-appsawg-webfinger-09****
>
>  ****
>
> I'm really just now starting to turn my attention to the acct uri aspect
> of the WebFinger discussion.. generally speaking I'm +1 on the current
> draft. When going through various implementation scenarios, however, one
> thought did strike me, although it may be a bit too late in the game to p=
ut
> this on the table at all. I apologize for making this late suggestion...*=
*
> **
>
>  ****
>
> In some scenarios, such as hosted cloud application environments, a
> service provider may wish to host the information about a given user with=
in
> a different domain. For instance, suppose Company Foo.com utilizes servic=
es
> from ISV Bar.com. The user accounts, however, are drawn from Foo.com, but
> Bar.com is the provider that actually hosts the profiles and account
> information. What I want is something that identifies the user account AN=
D
> the service provider. ****
>
>  ****
>
> Example: ****
>
>  ****
>
>   acct:john.doe@foo.com?provider=3Dbar.com****
>
>  ****
>
> In a WebFinger type of scenario, resolving this would involve something
> like...****
>
>  ****
>
>   GET /.well-known/webfinger?resource=3Djohn.doe@foo.com****
>
>   Host: bar.com****
>
>  ****
>
> Encoding the third party provider into the URL in this way provides a
> fairly flexible way of enabling the third party support without complicat=
ed
> redirects from foo.com to bar.com. It also gives domains a way of
> enabling bits of information to be shared from multiple sources...
> acct:john.doe@foo.com?provider=3Disv1.com vs.
> acct:john.doe@foo.com?provider=3Disv2.com****
>
>  ****
>
> To enable this kind of thing, it would be helpful if the basic acct URI
> syntax allowed for optional parameters like the mailto URI scheme does
> (RFC2368). The specific parameters themselves can be figured out later...=
*
> ***
>
>  ****
>
> - James****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
> On Mon, Jan 28, 2013 at 10:16 AM, Salvatore Loreto <
> salvatore.loreto@ericsson.com> wrote:****
>
> FYI****
>
> the 2 weeks WGLC on draft-ietf-appsawg-webfinger is started.
> Please see the mail below and note that the right venue for discussion is
> the *webfinger* mailing list
>
> best regards
> Salvatore
>
> -------- Original Message -------- ****
>
> *Subject: *****
>
> [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09**=
*
> *
>
> *Date: *****
>
> Mon, 28 Jan 2013 20:13:48 +0200****
>
> *From: *****
>
> Salvatore Loreto 
> ****
>
> *To: *****
>
>  ****
>
> *CC: *****
>
> Murray S. Kucherawy  ****
>
>
>
> Dear WG partecipants,
>
>
> I would like to initiate a 2 weeks WG Last Call on
> draft-ietf-appsawg-webfinger-09.txt ("WebFinger")
> http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt
>
>
> Please send your reviews, as well as expression of support regarding
> document readiness for IESG (or not) either to the **webfinger** mailing
> list (webfinger@ietf.org),
> or directly to the WG chairs (Murray Kucherawy and myself).
>
> Comments like "I've read the document and it is Ok to publish" or
> "I've read the document and it has the following issues"
> are useful and would be gratefully accepted by chairs.
>
>
> The WG LC will end on Friday, February 8th.
>
>
> Thank you,
> Salvatore as an APPSAWG co-chair.
>
>
>
> ****
>
>  ****
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
>  ****
>
> ** **
>

--bcaec50fe5f578bd8004d484ea1a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


First off, The ? synt=
ax is already well established practice for many URI structures, particular=
ly http and mailto, it makes a lot of sense to reuse that, particularly sin=
ce many existing URI parsers will give you support for for free.


Second, the most I am suggesting for acct uri is the a=
llowance of optional query parameters. I am not suggesting, right now, that=
 we ought to change the semantics of WebFinger's resolution... but I do=
 want to leave the door open for alternative resolution mechanisms later. I=
 used the ?provider=3Dbar.com as an example =
of the basic motivation for the parameters, but there very well could be ot=
her interesting parameters that are worth considering.




Hypothetically, for instance, in the future=
 we could have something like:




=C2=A0 <a h=
ref=3D"acct:joe@e=
xample.net?rel=3Dweblog" rel=3D"weblog">Find my blog!=
</a>




Allowing for optional query paramete=
rs gives us more flexibility long term without introducing significant new =
complexity now.




Additional responses to Salvatore&#=
39;s comments inline below...




On Wed, Jan 30, 2013 at 9:16 AM, Mike Jones =
<Michael.Jones@microsoft.com> wrote:













If we were to support this, a more consistent syntax =
would be to always have the provider be the part to the right of the last =
=E2=80=98@=E2=80=99 and have everything else
 be the account identifier at the provider.=C2=A0 Then, for instance, acct:=
mbj@microsoft.com@faceboo=
k.com would be a legal identifier for my Facebook account and acct:selfissued=
@twitter.com would be a legal identifier for my Twitter account.=C2=A0 =
In both cases, the
 provider is the part after the last =E2=80=98@=E2=80=99.


=C2=A0


I=E2=80=99m not certain this is needed, but would pre=
fer the =E2=80=98@=E2=80=99 syntax to the =E2=80=98?=E2=80=99 syntax, if we=
 do want to support account identifiers of the form user@domain with
 a provider being specified that=E2=80=99s different than the domain.=C2=A0=
 Whereas introducing the full =E2=80=98?=E2=80=99 syntax seems like overkil=
l, and I would be against that.


=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=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 -- Mike


=C2=A0






From: apps-discuss-bounces@ietf.org [mailto:<=
a href=3D"mailto:apps-discuss-bounces@ietf.org" target=3D"_blank">apps-disc=
uss-bounces@ietf.org]
On Behalf Of Salvatore Loreto

Sent: Wednesday, January 30, 2013 12:41 AM

To: 'James M Snell'

Cc: apps-=
discuss@ietf.org

Subject: Re: [apps-discuss] [webfinger] Working Group Last Call for =
draft-ietf-appsawg-webfinger-09






=C2=A0






in principle I am not against to allow the basic 'acct' URI syntax =
for optional parameter.



However I am not convinced of the need to specify one for the actual cloud =
provider

for several reasons:

- the actual cloud provider can change over the time

Yes, the provider can change but the base account id would=
 not...=C2=A0



=C2=A0




- one user can decide to host different services to different cloud provide=
rs

=
And a single account ID could be used=
 a multiple cloud providers... for instance, I use my gmail address as my l=
ogin ID at quite a few locations.=C2=A0



=C2=A0



 

- if a user has to provide the 'acct' URI with the 'provide'=
; parameter

I don't understand the advantage to disclosure 
acct:john.doe@foo.com?provider=3Disv1.com


vs disclosing directly=C2=A0 acct:john.doe@isv1.com


Suppose I am an ISV hosting serv=
ices for two separate companies, both of which have a user named "joe&=
quot;






acct:joe@bar.com?provider=3Disv.com

Looking at this, there are two ways of r=
esolving each..=C2=A0




1. To find out information about joe@foo.com..
=C2=A0 =C2=A0a. I can send a WF request to=
 foo.com, which redirects to isv.com, or=C2=A0



=C2=A0 =C2=A0b. I can send=
 a WF request to isv.com with resource=3Djoe@foo.com
2. To find out information about joe@bar.com..



=C2=A0 =C2=A0a. I can send a WF =
request to bar.com, which redirects to isv.com, or=C2=A0
=C2=A0 =C2=A0b. I can send a WF request to isv.com with resource=3Djoe@bar.com




Again, howe=
ver, this is just an example. The most I am suggesting right now is that we=
 allow for optional query string parameters, I am not suggesting that we de=
fine specific parameters at this time.




- James
=C2=A0



<=
div>




/Salvatore





On 1/30/13 5:31 AM, Paul E. Jones wrote:






James,


=C2=A0


Since this is really an acct URI question, I think it=
 should be redirected back to the apps-discuss list.



=C2=A0


One challenge I see with this kind of syntax is that =
the account information for a user is not necessarily always hosted at any =
certain provider.=C2=A0 Perhaps when
 acct: is used with WebFinger, the domain foo.com redirects the request to a different domain.=C2=A0 =
Perhaps for some other protocol that might utilize acct:, the means through=
 which the information is returned is entirely different.=C2=A0 And what if=
 the =E2=80=9Chosting provider=E2=80=9D
 changes next week?=C2=A0 I would not want a URI like 
acct:paulej@packetizer.com to become invalid simply because I decide to=
 host my account information at a different provider next week.




=C2=A0



Paul


=C2=A0








From:
webfinger-b=
ounces@ietf.org [mailto:webfinger-bounces@ietf.org]
On Behalf Of James M Snell

Sent: Tuesday, January 29, 2013 1:03 PM

To: Salvatore Loreto

Cc: webfinge=
r@ietf.org

Subject: Re: [webfinger] [apps-discuss] Working Group Last Call for =
draft-ietf-appsawg-webfinger-09






=C2=A0




I'=
;m really just now starting to turn my attention to the acct uri aspect of =
the WebFinger discussion.. generally speaking I'm +1 on the current dra=
ft. When going through various implementation
 scenarios, however, one thought did strike me, although it may be a bit to=
o late in the game to put this on the table at all. I apologize for making =
this late suggestion...




=C2=A0






In so=
me scenarios, such as hosted cloud application environments, a service prov=
ider may wish to host the information about a given user within a different=
 domain. For instance, suppose Company
 Foo.com utilizes services from ISV Bar.com. The user accounts, however, ar=
e drawn from Foo.com, but Bar.com is the provider that actually hosts the p=
rofiles and account information. What I want is something that identifies t=
he user account AND the service
 provider.=C2=A0






=C2=A0






Examp=
le:=C2=A0






=C2=A0







=C2=A0






In a =
WebFinger type of scenario, resolving this would involve something like...<=
/span>






=C2=A0






=C2=
=A0 GET /.well-known/webfinger?resource=3Djohn.doe@foo.com






=C2=
=A0 Host: 
bar.com






=C2=A0






Encod=
ing the third party provider into the URL in this way provides a fairly fle=
xible way of enabling the third party support without complicated redirects=
 from
foo.com to bar.com. It also gives domains a way of e=
nabling bits of information to be shared from multiple sources...
acct:john.doe@foo.com?provider=3Disv1.com vs.
acct:john.doe@foo.com?provider=3Disv2.com






=C2=A0






To en=
able this kind of thing, it would be helpful if the basic acct URI syntax a=
llowed for optional parameters like the mailto URI scheme does (RFC2368). T=
he specific parameters themselves
 can be figured out later...






=C2=A0






- Jam=
es






=C2=A0






=C2=A0






=C2=A0






=C2=A0








=C2=A0




On Mon, Jan 28, 2013 at 10:16 AM, Salvatore Loreto <salvatore.lore=
to@ericsson.com> wrote:




FYI




the 2 weeks WGLC on draft-ietf-appsawg-webfinger is started.<=
br>
Please see the mail below and note that the right venue for discussion is <=
br>
the *webfinger* mailing list



best regards

Salvatore



-------- Original Message -------- 








Subject: 




[webfinger] Working Group Last Call for draft-ietf-appsawg-we=
bfinger-09








Date: 




Mon, 28 Jan 2013 20:13:48 +0200








From: 




Salvatore Loreto 
<salvatore.loreto@ericsson.com>








To: =





<w=
ebfinger@ietf.org>








CC: =





Murray S. Kucherawy 
<superuser@gmail.com>
















Dear WG partecipants, 





I would like to initiate a 2 weeks WG Last Call on 

draft-ietf-appsawg-webfinger-09.txt ("WebFinger") 

http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt=






Please send your reviews, as well as expression of support regarding 

document readiness for IESG (or not) either to the *webfinger* maili=
ng list (webfinger@=
ietf.org),


or directly to the WG chairs (Murray Kucherawy and myself). 



Comments like "I've read the document and it is Ok to publish"=
; or 

"I've read the document and it has the following issues"

are useful and would be gratefully accepted by chairs. 





The WG LC will end on Friday, February 8th. 





Thank you, 

Salvatore as an APPSAWG co-chair. 
















=C2=A0






_______________________________________________

apps-discuss mailing list

apps-discuss@iet=
f.org

https://www.ietf.org/mailman/listinfo/apps-discuss<=
/p>



=C2=A0






=C2=A0










--bcaec50fe5f578bd8004d484ea1a--