From James.H.Manger@team.telstra.com Mon Oct 1 00:00:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9F721F85C4 for ; Mon, 1 Oct 2012 00:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.269 X-Spam-Level: X-Spam-Status: No, score=-0.269 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_42=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZlwZUMlCy-U for ; Mon, 1 Oct 2012 00:00:23 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id AEFFD21F84CD for ; Mon, 1 Oct 2012 00:00:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,515,1344175200"; d="scan'208";a="95519464" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 01 Oct 2012 17:00:20 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6851"; a="90962213" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcdvi.tcif.telstra.com.au with ESMTP; 01 Oct 2012 17:00:19 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Mon, 1 Oct 2012 17:00:19 +1000 From: "Manger, James H" To: Mark Nottingham , "apps-discuss@ietf.org" Date: Mon, 1 Oct 2012 17:00:18 +1000 Thread-Topic: json-patch: draft 05 comments Thread-Index: Ac2cYehurY7DjAyjT5O6gci4i377xgDKiE2AAALbTyA= Message-ID: <255B9BB34FB7D647A506DC292726F6E114FD642F4D@WSMSG3153V.srv.dir.telstra.com> References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [apps-discuss] json-patch: draft 05 comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 07:00:23 -0000 RmVlZGJhY2sgb24gZHJhZnQtaWV0Zi1hcHBzYXdnLWpzb24tcGF0Y2gtMDUNCg0KMy4gRG9jdW1l bnQgU3RydWN0dXJlOiB0aGUgZXhhbXBsZSBmYWlscyBhcyB0aGUgImNvcHkiIG9wZXJhdGlvbiBy ZWZlcnMgdG8gYSBwYXRoIHRoYXQgbm8gbG9uZ2VyIGV4aXN0cyBkdWUgdG8gdGhlIHByZXZpb3Vz ICJtb3ZlIg0KT0xEOiB7ICJvcCI6ICJtb3ZlIiwgInBhdGgiOiAiL2EvYi9jIiwgInRvIjogIi9h L2IvZCIgfSwNCiAgICAgeyAib3AiOiAiY29weSIsICJwYXRoIjogIi9hL2IvYyIsICJ0byI6ICIv YS9iL2UiIH0NCk5FVzogeyAib3AiOiAibW92ZSIsICJwYXRoIjogIi9hL2IvYyIsICJ0byI6ICIv YS9iL2QiIH0sDQogICAgIHsgIm9wIjogImNvcHkiLCAicGF0aCI6ICIvYS9iL2QiLCAidG8iOiAi L2EvYi9lIiB9DQoNCg0KMy4gRG9jdW1lbnQgU3RydWN0dXJlOiBhdm9pZCAib2JqZWN0IiB3aGVu IGl0IGRvZXNuJ3QgbWVhbiBhIEpTT04gb2JqZWN0DQpPTEQ6ICJhIEpTT04gZG9jdW1lbnQgd2hv c2Ugcm9vdCBvYmplY3QgaXMgYW4gYXJyYXkiDQpORVc6ICJhIEpTT04gZG9jdW1lbnQgdGhhdCBp cyBhbiBhcnJheSINCg0KDQo0LjEuIGFkZDogYSBtZW1iZXIgTVVTVCAqTk9UKiBhbHJlYWR5IGV4 aXN0DQpPTEQ6ICIgdGhlIHNwZWNpZmllZCBsb2NhdGlvbiBNVVNUIGFscmVhZHkgZXhpc3QgZm9y IHRoZSBvcGVyYXRpb24gdG8gYmUgc3VjY2Vzc2Z1bCINCk5FVzogIiB0aGUgc3BlY2lmaWVkIGxv Y2F0aW9uIE1VU1QgTk9UIGFscmVhZHkgZXhpc3QgZm9yIHRoZSBvcGVyYXRpb24gdG8gYmUgc3Vj Y2Vzc2Z1bCINClAuUy4gSSBkb24ndCBsaWtlIG5lZWRpbmcgdG8ga25vdyBhIG1lbWJlciBkb2Vz IG5vdCBleGlzdHMgYmVmb3JlIGFkZGluZyBpdCwgYnV0IHRoYXQgaXMgYSBzZXBhcmF0ZSBpc3N1 ZS4NCg0KDQo0LjEuIGFkZDogdGhlIG5vdGUgYWJvdXQgInBvaW50ZXLigJlzIGVycm9yIGhhbmRs aW5nIiBpcyBhd2t3YXJkLg0KDQoNCjQuMi4gcmVtb3ZlOiBpdCBuZWVkbid0IGJlIGFuIGVycm9y IHRvIHJlbW92ZSBhIHZhbHVlIHRoYXQgZG9lcyBub3QgZXhpc3QgKGVnIGhhcyBhbHJlYWR5IGJl ZW4gcmVtb3ZlZCkuDQpPTEQ6ICJUaGUgdmFsdWUgYXQgdGhlIHNwZWNpZmllZCBsb2NhdGlvbiBN VVNUIGV4aXN0IGZvciB0aGUgb3BlcmF0aW9uIHRvIGJlIHN1Y2Nlc3NmdWwuIg0KTkVXOiAiSWYg dGhlcmUgaXMgbm8gdmFsdWUgYXMgdGhlIHNwZWNpZmllZCBsb2NhdGlvbiB0aGUgb3BlcmF0aW9u IGhhcyBubyBhZmZlY3QuIg0KDQoNCjQuNC4gbW92ZSBhbmQgNC41LiBjb3B5OiBkZWZpbmluZyBh biBleGNlcHRpb24gZm9yIHRoZSBwb2ludGxlc3MgcGF0aD10byBjYXNlIGlzIHVubmVjZXNzYXJ5 LiAibW92ZSIgc2hvdWxkIGJlICJwYXRoIiBhcyB3ZWxsLg0KUkVNT1ZFOiAidW5sZXNzICJtb3Zl IihzaWMpIGFuZCAidG8iIHNwZWNpZnkgdGhlIHNhbWUgb2JqZWN0LCB3aGljaCBoYXMgbm8gZWZm ZWN0Ig0KDQoNCjQuNS4gY29weTogY2FuIHlvdSBjb3B5IGEgdmFsdWUgaW50byBhIGNvbXBvbmVu dCBvZiBpdHNlbGY/IFRoYXQgaXMsIGNhbiAicGF0aCIgYmUgYSBwcmVmaXggb2YgInRvIj8NCiAg eyJvcCI6ImNvcHkiLCAicGF0aCI6Ii9hIiwgInRvIjoiL2EvYi9jIn0NCg0KDQo0LjQuIG1vdmU6 IG1vdmluZyBhIHZhbHVlIHRvIGFuIG9iamVjdCBlbGVtZW50IHNob3VsZCByZXBsYWNlIGFueSBl eGlzdGluZyB2YWx1ZSBhdCB0aGF0IGVsZW1lbnQgaWYgdGhlcmUgaXMgb25lLCBpbnN0ZWFkIG9m IGJlaW5nIGFuIGVycm9yLiBTaW1pbGFybHkgd2l0aCBjb3B5Lg0KDQoNCjUuIEVycm9yIEhhbmRs aW5nLiAiYSBSRkMyMTE5IHJlcXVpcmVtZW50IiBpcyBhIHZlcnkgYXdrd2FyZCB3YXkgdG8gcmVm ZXIgdG8gIk1VU1QiIHN0YXRlbWVudHMgaW4gdGhpcyBkcmFmdC4NCk9MRDogIklmIGEgUkZDMjEx OSBbUkZDMjExOV0gcmVxdWlyZW1lbnQgaXMgdmlvbGF0ZWQgYnkgYSBKU09OIFBhdGNoIGRvY3Vt ZW50LCBvciBpZiBhbiBvcGVyYXRpb24gaXMgbm90IHN1Y2Nlc3NmdWwiDQpORVc6ICJJZiBhbnkg b3BlcmF0aW9uIGlzIG5vdCBzdWNjZXNzZnVsIg0KDQoNCkFwcGVuZGl4IEEuIEV4YW1wbGVzOiBh ZGQgZXhhbXBsZXMgd2l0aCB1bnJlY29nbml6ZWQgZWxlbWVudHMgYW5kIGludmFsaWQgb3BlcmF0 aW9ucw0KTkVXOiAgQS4xMS4gSWdub3JlIHVucmVjb2duaXplZCBlbGVtZW50cw0KICAgICAgICBB biBleGFtcGxlIHRhcmdldCBKU09OIGRvY3VtZW50Og0KICAgICAgICAgeyJmb28iOiJiYXIifQ0K ICAgICAgICBBIEpTT04gUGF0Y2ggZG9jdW1lbnQ6DQogICAgICAgICBbeyJvcCI6ImFkZCIsICJw YXRoIjoiL2JheiIsICJ2YWx1ZSI6InF1eCIsICJ4eXoiOjEyM31dDQogICAgICAgIFRoZSByZXN1 bHRpbmcgSlNPTiBkb2N1bWVudDoNCiAgICAgICAgIHsiZm9vIjoiYmFyIiwgImJheiI6InF1eCJ9 DQoNCk5FVzogIEEuMTIuIEludmFsaWQgSlNPTiBQYXRjaCBkb2N1bWVudA0KICAgICAgICBBIEpT T04gUGF0Y2ggZG9jdW1lbnQ6DQogICAgICAgICBbeyJvcCI6ImFkZCIsICJwYXRoIjoiL2JheiIs ICJ2YWx1ZSI6InF1eCIsICJvcCI6InJlbW92ZSJ9XQ0KICAgICAgICBUaGlzIEpTT04gUGF0Y2gg ZG9jdW1lbnQgTVVTVCBOT1QgYmUgdHJlYXRlZCBhcyBhbiAiYWRkIg0KICAgICAgICBvcGVyYXRp b24gc2luY2UgdGhlcmUgaXMgYSBsYXRlciAib3AiOiJyZW1vdmUiIGVsZW1lbnQuDQogICAgICAg IEl0IFNIT1VMRCBiZSBhbiBlcnJvci4gQSBKU09OIHBhcnNlciB0aGF0IGhpZGVzIHN1Y2ggZHVw bGljYXRlDQogICAgICAgIGVsZW1lbnQgbmFtZXMgTVVTVCBOT1QgYmUgdXNlZCB1bmxlc3MgaXQg YWx3YXlzIGV4cG9zZXMgb25seQ0KICAgICAgICB0aGUgbGFzdCBlbGVtZW50IHdpdGggYSBnaXZl biBuYW1lIChlZyAib3AiOiJyZW1vdmUiIGluIHRoaXMgZXhhbXBsZSkuDQoNCi0tDQpKYW1lcyBN YW5nZXINCg== From mnot@mnot.net Mon Oct 1 04:45:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D9A21F85F0 for ; Mon, 1 Oct 2012 04:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.554 X-Spam-Level: X-Spam-Status: No, score=-101.554 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, J_CHICKENPOX_42=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 eLOKuNc6-Dbz for ; Mon, 1 Oct 2012 04:45:19 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id D80F421F860B for ; Mon, 1 Oct 2012 04:45:18 -0700 (PDT) Received: from [192.168.1.57] (unknown [149.241.34.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0CD5A50A64; Mon, 1 Oct 2012 07:45:11 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Mark Nottingham In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FD642F4D@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 1 Oct 2012 12:45:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E114FD642F4D@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1498) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] json-patch: draft 05 comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 11:45:20 -0000 Hi James, Thanks for the feedback. Responses below. On 01/10/2012, at 8:00 AM, "Manger, James H" = wrote: > Feedback on draft-ietf-appsawg-json-patch-05 >=20 > 3. Document Structure: the example fails as the "copy" operation = refers to a path that no longer exists due to the previous "move" > OLD: { "op": "move", "path": "/a/b/c", "to": "/a/b/d" }, > { "op": "copy", "path": "/a/b/c", "to": "/a/b/e" } > NEW: { "op": "move", "path": "/a/b/c", "to": "/a/b/d" }, > { "op": "copy", "path": "/a/b/d", "to": "/a/b/e" } Fixed in SVN > 3. Document Structure: avoid "object" when it doesn't mean a JSON = object > OLD: "a JSON document whose root object is an array" > NEW: "a JSON document that is an array" Changed to "whose root is an array" > 4.1. add: a member MUST *NOT* already exist > OLD: " the specified location MUST already exist for the operation to = be successful" > NEW: " the specified location MUST NOT already exist for the operation = to be successful" > P.S. I don't like needing to know a member does not exists before = adding it, but that is a separate issue. Fixed in SVN > 4.1. add: the note about "pointer=92s error handling" is awkward. Agreed, but I didn't have a better way to phrase it. Suggestions? > 4.2. remove: it needn't be an error to remove a value that does not = exist (eg has already been removed). > OLD: "The value at the specified location MUST exist for the operation = to be successful." > NEW: "If there is no value as the specified location the operation has = no affect." Needs discussion. > 4.4. move and 4.5. copy: defining an exception for the pointless = path=3Dto case is unnecessary. "move" should be "path" as well. > REMOVE: "unless "move"(sic) and "to" specify the same object, which = has no effect" "move" changed to "path". Removing it needs discussion; this was an = explicit decision earlier, discussed as issue #9 = . > 4.5. copy: can you copy a value into a component of itself? That is, = can "path" be a prefix of "to"? > {"op":"copy", "path":"/a", "to":"/a/b/c"} Needs discussion, but good point; I suspect we need a constraint here. > 4.4. move: moving a value to an object element should replace any = existing value at that element if there is one, instead of being an = error. Similarly with copy. Needs discussion. > 5. Error Handling. "a RFC2119 requirement" is a very awkward way to = refer to "MUST" statements in this draft. > OLD: "If a RFC2119 [RFC2119] requirement is violated by a JSON Patch = document, or if an operation is not successful" > NEW: "If any operation is not successful" I agree that it's a bit awkward, but there are two things happening = here; one is a violation by the doc, another is the operation failing. = If you have a suggestion that's smoother yet captures both, I'd be glad = to incorporate it. > Appendix A. Examples: add examples with unrecognized elements and = invalid operations > NEW: A.11. Ignore unrecognized elements > An example target JSON document: > {"foo":"bar"} > A JSON Patch document: > [{"op":"add", "path":"/baz", "value":"qux", "xyz":123}] > The resulting JSON document: > {"foo":"bar", "baz":"qux"} >=20 > NEW: A.12. Invalid JSON Patch document > A JSON Patch document: > [{"op":"add", "path":"/baz", "value":"qux", "op":"remove"}] > This JSON Patch document MUST NOT be treated as an "add" > operation since there is a later "op":"remove" element. > It SHOULD be an error. A JSON parser that hides such duplicate > element names MUST NOT be used unless it always exposes only > the last element with a given name (eg "op":"remove" in this = example). Added in SVN, although I removed the RFC2119 language, as it's not good = to have in examples, or to repeat requirements. Cheers and thanks again, -- Mark Nottingham http://www.mnot.net/ From glenzorn@gmail.com Mon Oct 1 00:54:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D3021F85B6; Mon, 1 Oct 2012 00:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=-1.485, BAYES_50=0.001, J_CHICKENPOX_51=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 W6qyso7fQqXN; Mon, 1 Oct 2012 00:53:59 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id B6B3221F84BF; Mon, 1 Oct 2012 00:53:58 -0700 (PDT) Received: by padfb11 with SMTP id fb11so4045064pad.31 for ; Mon, 01 Oct 2012 00:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yF39Jf4qikHc9Lh8Kh0tIYwfGn02xF7sDf2uuLWhmsM=; b=xkjhU7LpuhhAxTPAzywrf4Bg4L2S7NUN3nbQk4nO81rXGekiyM2wo7T5VhOUCXNHRi Gpux81zuOMDGglQ35ZTznuC9/Ozlxa4Tg+chXrgqIbIjzcEFo4i28oaZTmx1ULvS2Aqx St7R/kD2+EQpNh6gkgsFf3ZhbXzp2akSxHUtmMBGdtOO9Z0OD+QTKqr5W9hnNwveGZTi RcxAXNk6FXJPwolAi8jPPNQgjgqXJ8afCZAf1a6no2isJxGD9Ol4sg86JLPzlN68+jHQ eSUP6SROn1g5TW358xp8Nk0qNU0acq56aisrRf0NdVGEmns24HIaw4C9YAF6ioA8PwFj ZO+Q== Received: by 10.68.197.104 with SMTP id it8mr39458789pbc.167.1349078038366; Mon, 01 Oct 2012 00:53:58 -0700 (PDT) Received: from [192.168.0.102] (ppp-124-120-13-13.revip2.asianet.co.th. [124.120.13.13]) by mx.google.com with ESMTPS id bn1sm10000680pab.8.2012.10.01.00.53.54 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 00:53:57 -0700 (PDT) Message-ID: <50694C10.4050508@gmail.com> Date: Mon, 01 Oct 2012 14:53:52 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120914 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dave Crocker References: <50161436.8080900@bbiw.net> In-Reply-To: <50161436.8080900@bbiw.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 01 Oct 2012 08:08:51 -0700 Cc: glenzorn@gmail.com, dime mailing list , draft-ietf-dime-rfc4005bis.all@tools.ietf.org, apps-discuss@ietf.org, iesg Subject: Re: [apps-discuss] Review of: draft-ietf-dime-rfc4005bis-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, 01 Oct 2012 07:54:01 -0000 On 07/30/2012 11:57 AM, Dave Crocker wrote: > G'day. > > > 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-dime-rfc4005bis-09 Title: Diameter > Network Access Server Application Reviewer: Dave Crocker Review > Date: 18 June 2012 > > > Summary: > > This draft continues problems from the original, at a minimum lacking > definitions of terms, citation or definition of notational > conventions, apparent normative redundancy with base documents. > > > Major Issues: > > Active vs. passive voice -- the documents use of passive voice > greatly expands the verbiage but also sometimes make it difficult to > discern which participating entity is the identified actor. > > Apparently redundant normative text -- this document appears to > contain restatements of normative text from the base Diameter > document. This is extremely poor practice, since it invites > divergence. > > Possibly inconsistent use of terminology -- Some of the terms used > appear to have equivalent meaning but are not defines; to the extent > that they are meant to have different meaning I could not tell what > that was. > > Most significantly, it appears that this document cannot readily be > read without very deep familiarity with other Diameter documentation, > making this nearly an appendix to those. At the least, the > dependencies should be made explicit and detailed. The > Introduction's opening paragraph might have been thought to take care > of this requirement, but it doesn't, at least not for me. For one > thing, it isn't phrase so as to accomplish this. For another, the > references are to entire documents, implying -- but not saying -- > don't read this until you are deeply familiar with all of these other > documents. > > The broader comments appear to apply to the original documents as > well as this (and related) current ones. It's likely that making > changes accordingly would be a major effort. Whether that's worth > the effort isn't something I can judge. I think the revisions would > make for tighter, clearer specifications that are probably easier to > maintain, but I can't offer an opinion about the benefit this would > have in terms of existing implementers or better market adoption, > since I'm not familiar with Diameter's degree of market penetration > nor the skills of those who have (or might) adopt it. > > > > Minor Issues: -- > > > Nits: -- > > > Detailed comments: > > >> Network Working Group G. >> Zorn, Ed. Internet-Draft Network Zen Obsoletes: 4005 (if approved) >> May 18, 2012 Intended status: Standards Track Expires: November >> 19, 2012 >> >> >> Diameter Network Access Server Application >> draft-ietf-dime-rfc4005bis-09 >> >> Abstract >> >> This document describes the Diameter protocol application used for > > When summarizing the nature or purpose of a document, it is best for > the abstract and Introduction to use different words than are in the > title. Simply repeating the language of the title does not explain > the title. The simple rule should be to assume that the new reader > does not automatically understand the meaning of the title. > > In this case, I also have no idea what "the Diameter protocol > application" means here. RFC 3588. > "protocol application" is not typical > phrasing. Does it really mean that details are being specified for > software implementation of Diameter at the server? No. > > Typically, the IETF does not specify details about software > implementation, nevermind put such a specification on the standards > track. (And, yes, I see that this is a -bis document; but that does > not change the underlying concern.) > > What is the motivation for this version of the document? What > problems or improvements are being provided? That is, why was it > worth the effort to revise the previous document? These are not > explained in the bis document. Section 1.1 > > >> Authentication, Authorization, and Accounting (AAA) services in >> the Network Access Server (NAS) environment; it obsoletes RFC 4005. >> When combined with the Diameter Base protocol, Transport Profile, >> and Extensible Authentication Protocol specifications, this >> application specification satisfies typical network access services >> requirements. > > ... >> 1. Introduction >> >> This document describes the Diameter protocol application used for >> AAA in the Network Access Server (NAS) environment. When combined >> with the Diameter Base protocol [I-D.ietf-dime-rfc3588bis], >> Transport Profile [RFC3539], and EAP [RFC4072] specifications, >> this specification satisfies the NAS-related requirements defined >> in Aboba, et al. [RFC2989] and Beadles & Mitton [RFC3169]. > > This assertion raises a dilemma: The cited documents are extensive > and the topic(s?) complex. There is no way to know what details are > being referred to, to evaluate the assertion. If there were only specific details that were relevant, only specific sections of the document would be cited. To evaluate the assertion read the cited documents. All of them. To understand this document, read and understand the normative references. All of them. > Worse, fixing this > deficiency is certain to be a large effort. > > >> First, this document describes the operation of a Diameter NAS >> application. > > What is "a Diameter NAS application"? It does not seem to be > explained in this document, nor is there a citation to its > definition. > > >> Then it defines the Diameter message Command-Codes. The following >> sections list the AVPs used in these messages, grouped > > AVPs? > > Define acronyms when they are introduced. Explain their meaning. If > the acronym is not destined for regular use within the document, > consider replacing the acronym with the full term. > > If this document is a case of "this document only makes sense when > you are intimately familiar with these other documents", then specify > those other documents. As the document stands now, it does not > formally citte foundational documents, although it does seem to rely > on some. My understanding, as expressed above, is that in order for a reader to expect to understand an RFC, they must first have read and understood the normative references. Is that incorrect? > > In general, this document's frequent use of "AVP" appears to be an > oddly syntactic focus. Typical specifications refer to attributes, > without such frequent, explicit reference to the form of their having > values. On its own, this point could seem like quibbling, but it's > part of the reaction I had when reading the document, that is seemed > less accessible than one would wish for a new reader. This document is not intended to function as a primer on Diameter, AAA, or network access systems. As I mentioned above, the "new" reader is fully expected to have read and thoroughly understand all of the normative references. That reader would have found that Section 1.1 of RFC 3588 (referencing that document since RFC3588bis is still something of a moving target) says: All data delivered by the protocol is in the form of an AVP. Some of these AVP values are used by the Diameter protocol itself, while others deliver data associated with particular applications that employ Diameter. The centrality of AVPs to the operation of the Diameter protocol might explain the focus of this draft upon them. > > >> by common usage. These are session identification, >> authentication, authorization, tunneling, and accounting. The >> authorization AVPs are further broken down by service type. > > This document appears to require deep knowledge of The Diameter Base > Protocol. In reality, I don't think this document can be > meaningfully read without that knowledge. So this document should > say that. (The language in the first paragraph of the Intro doesn't > actually say it.) One more time: read the normative references. Understand them. All of them. I realize that this is a rather tall order for a review, but the target audience for this draft is not people who are less than intimately familiar with the Diameter base protocol, as well as RADIUS ans network access systems in general. > > >> 1.1. Changes from RFC 4005 >> >> This document obsoletes RFC 4005 and is not backward compatible >> with that document. An overview of some the major changes are >> given below. > > "not backward compatible" automatically raises basic questions about > transition from old to new and support during an extended > transition. The word 'transition' does not appear in this document. > > >> o All of the material regarding RADIUS/Diameter protocol >> interactions has been removed. >> >> o The Command Code Format (CCF) [I-D.ietf-dime-rfc3588bis] for >> the > > presumably the references to I-Ds need to be changed for RFC > publication? Presumably the RFC Editor will take care of that; this draft is part of a rather large cluster that is waiting on the publication of RFC 3588 bis. > > >> Accounting-Request and Accounting-Answer messages has been changed >> to explicitly require the inclusion of the Acct-Application-Id AVP >> and exclude the Vendor-Specific-Application-Id AVP. Normally, this >> type of change would also require the allocation of a new command >> code and consequently, a new application-id (See Section 1.3.3 of >> [I-D.ietf-dime-rfc3588bis]). However, the presence of an instance >> of the Acct-Application-Id AVP was required in RFC 4005, as well: >> >> The ACR message [BASE] is sent by the NAS to report its session >> information to a target server downstream. >> >> Either of Acct-Application-Id or Vendor-Specific-Application-Id >> AVPs MUST be present. If the Vendor-Specific-Application-Id >> grouped AVP is present, it must have an Acct-Application-Id >> inside. >> >> Thus, though the syntax of the commands has changed, the semantics >> have not (with the caveat that the Acct-Application-Id AVP can no >> longer be contained in the Vendor-Specific-Application-Id AVP). > > Sounds oddly disruptive. /Why/ has the syntax been changed? What > problem is this solving? > >> >> >> >> >> Zorn Expires November 19, 2012 [Page 5] >> Internet-Draft Diameter NASREQ May 2012 >> >> >> o The lists of RADIUS attribute values have been deleted in favor >> of references to the appropriate IANA registries. >> >> o The accounting model to be used is now specified. >> >> There are many other many miscellaneous fixes that have been >> introduced in this document that may not be considered significant >> but they are useful nonetheless. Examples are fixes to example IP > > Useful, but not significant. Interesting concept. Perhaps what is > meant is not major or not substantive or not normative? > > >> addresses, addition of clarifying references, etc. All of the >> errata previously filed against RFC 4005 have been fixed. A >> comprehensive list of changes is not shown here for practical >> reasons. >> >> 1.2. Terminology >> >> Section 1.2 of the base Diameter specification >> [I-D.ietf-dime-rfc3588bis] defines most of the terminology used in >> this document. Additionally, the following terms and acronyms are >> used in this application: >> >> NAS (Network Access Server) A device that provides an access >> service for a user to a network. The service may be a network >> connection or a value-added service such as terminal emulation >> [RFC2881]. > > Do not define a term by re-using the words in the term. In this > case, even a word as obvious as 'access' could mean a variety of > things. > > Everything is "a network connection". Perhaps the distinction here > is between host-level attachment service, versus user-level > application service? I can't tell. > > > ... >> VPN (Virtual Private Network) In this document, this term is used >> to describe access services that use tunneling methods. > > Since VPN is a well-entrenched, standard term of art, it seems odd -- > and likely counterproductive -- to imply that use in this document > will be non-standard, especially since the definition provided seems > on a par with usual definitions, such as wikipedia's. Fine. > > > >> 1.4. Advertising Application Support >> >> Diameter nodes conforming to this specification MUST advertise >> support by including the value of one (1) in the >> Auth-Application-Id of the Capabilities-Exchange-Request (CER) >> message. > > "this specification' -> this version of specification [???] > > There is no other reference to the CER message in this document. As > such, it's not clear what context for the message is meant. Offhand, > it appears that advertising support of the spec is made during a > session that implements the spec? This seems at least odd. > > Since this version of the spec uses a different syntax, it's not > likely that any implementation will be speaking a different version > of the protocol. > > >> 1.5. Application Identification >> >> When used in this application, the Auth-Application-Id AVP MUST be >> set to the value one (1) in the following messages >> >> o AA-Request (Section 3.1) >> >> >> >> >> >> Zorn Expires November 19, 2012 [Page 7] >> Internet-Draft Diameter NASREQ May 2012 >> >> >> o Re-Auth-Request(Section 3.3) >> >> o Session-Termination-Request (Section 3.5) >> >> o Abort-Session-Request (Section 3.7) >> >> 1.6. Accounting Model >> >> It is RECOMMENDED that the coupled accounting model (Section 9.3 >> of [I-D.ietf-dime-rfc3588bis]) be used with this application; >> therefore, the value of the Acct-Application-Id AVP in the >> Accounting-Request (Section 3.10) and Accounting-Answer (Section >> 3.9) messages SHOULD be set to one (1). > > All of the values in those two sections (except the "271") are > symbolic. As such, setting a value to "1" has no obvious meaning. > > I assume that the issue would be fixed by using symbolic values > here? Or by reading RFC 3588. > > >> 2. NAS Calls, Ports, and Sessions >> >> The arrival of a new call or service connection at a port of a > > "a port"? is this a reference to a transport-level port? That's the > only use of the word in the base diameter document. > > What is a 'call' and what does it mean for it to "arrive", in this > context? How is it different from a service connection? > > The word 'call' in the base document does not have a usage that seems > relevant here. > > Is this document really trying to specify how a host dispatches a > server? If so, that means it's discussing implementation details > rather than protocol details. > > >> Network Access Server (NAS) starts a Diameter NAS message >> exchange. > > I would guess that the Diameter-level initiation of a NAS message > exchange is caused by a Diameter-level message, not the transport > connection it triggers. If so, what message would that be? > > >> Information about the call, the identity of the user, and the >> user's > > The base Diameter document does not specify the concept of a 'call'. > > >> authentication information are packaged into a Diameter AA-Request >> (AAR) message and sent to a server. >> >> The server processes the information and responds with a Diameter >> AA- > > "processes the information"? What does this mean, in protocol > interoperability terms? I'd expect some statement about the > semantics of the processes, relative to the overall exchange. > > >> Answer (AAA) message that contains authorization information for >> the NAS, or a failure code (Result-Code AVP). A value of >> DIAMETER_MULTI_ROUND_AUTH indicates an additional authentication >> exchange, and several AAR and AAA messages may be exchanged until >> the transaction completes. > > "may"? > > This paragraph appears to be largely redundant with the base Diameter > document. Redundancy like this invites divergence over time and > ambiguity about which text is controlling. > > >> Depending on the value of the Auth-Request-Type AVP, the Diameter > > The reader is supposed to guess what values produce what results or > actions? I don't see the choices/mappings/whatever documented. > > > >> 3.1. AA-Request (AAR) Command >> >> The AA-Request (AAR), which is indicated by setting the >> Command-Code field to 265 and the 'R' bit in the Command Flags >> field, is used to request authentication and/or authorization for a >> given NAS user. > > The text provides detail about the internals of the AAR, but doesn't > say who sends it. > > By the way, does the AA- mean Authentication/Authorization? That's > implied but not stated. Since the labels are symbolic, mnemonic > utility is improved by explaining the basis of the string. > > >> The type of request is identified through the Auth-Request-Type >> AVP [I-D.ietf-dime-rfc3588bis] The recommended value for most >> situations is AUTHORIZE_AUTHENTICATE. >> >> If Authentication is requested, the User-Name attribute SHOULD be >> present, as well as any additional authentication AVPs that would >> carry the password information. A request for authorization >> SHOULD only include the information from which the authorization >> will be performed, such as the User-Name, Called-Station-Id, or >> Calling- > > This implies that some other sorts of information SHOULD NOT be > included, but gives no indication what it is (or why). > > >> Station-Id AVPs. All requests SHOULD contain AVPs uniquely >> identifying the source of the call, such as Origin-Host and >> NAS-Port. > > This is a classic and frequent bit of guidance, but lacks any > technical substance. The "such as" gives a concrete example, but > otherwise the implementer has no idea what will satisfy the SHOULD. > > >> Certain networks MAY use different AVPs for authorization >> purposes. A request for authorization will include some AVPs >> defined in Section 4.4. > > Which ones? How is the implementer to know? > > >> It is possible for a single session to be authorized first and >> then for an authentication request to follow. > > What is the implementer to do with this statement? > > >> This AA-Request message MAY be the result of a multi-round >> authentication exchange, which occurs when the AA-Answer message >> is received with the Result-Code AVP set to >> DIAMETER_MULTI_ROUND_AUTH. A subsequent AAR message SHOULD be sent, >> with the User-Password AVP that includes the user's response to the >> prompt, and MUST include any State AVPs that were present in the >> AAA message. >> >> Message Format > > What meta-syntax is being used for specifying formats? It isn't ABNF > and it isn't cited. > > > >> 3.2. AA-Answer (AAA) Command >> >> The AA-Answer (AAA) message is indicated by setting the >> Command-Code field to 265 and clearing the 'R' bit in the Command >> Flags field. It > > Is it really helpful to have each of these say how to set the > command, given that it's already listed in a table? Having prose > that merely repeats details, rather than explaining them, expands the > size of the document but, I believe, actually makes the substance > less accessible. > > Worse, isn't that already done in the base Diameter document? > > And by the way, the base document defines a command as a > request/answer pair. As such neither one, on its own, is a command. > That is, this one appears to be the a "command answer", rather than > a command. (And yes, that's painfully redundant, given the symbolic > name.) > > I notice that the text often uses the word 'message' to refer to one > of these transaction components of a command. That looks like a > simple and reasonable choice. Hence, AA-Answer (AAA) Message? This > assumes that "command" means a request/response pair. > > >> is sent in response to the AA-Request (AAR) message. If >> authorization was requested, a successful response will include >> the authorization AVPs appropriate for the service being provided, >> as defined in Section 4.4. > > The "if" seems odd, since the preceding sentence declares the > necessary (and obvious) predicate. > > >> >> For authentication exchanges requiring more than a single round >> trip, the server MUST set the Result-Code AVP to >> DIAMETER_MULTI_ROUND_AUTH. An AAA message with this result code MAY >> include one Reply-Message or >> >> >> >> Zorn Expires November 19, 2012 [Page 12] >> Internet-Draft Diameter NASREQ May 2012 >> >> >> more and MAY include zero or one State AVPs. >> >> If the Reply-Message AVP was present, the network access server >> SHOULD send the text to the user's client to display to the user, > > "was present" suffers the problem of passive sentence form in a > protocol specification -- and using past tense adds to the challenge: > it isn't clear who does what. Offhand, I would think that it is, in > fact, the server that generates replies (and presumably, therefore, > chooses to include Reply-Message text.) However the above sentence > implies otherwise. > > Since Diameter is a protocol specification, what does it mean for a > server to send text to the user's client? What is the protocol > mechanism for doing this? > > >> instructing the client to prompt the user for a response. For >> example, this capability can be achieved in PPP via PAP. If the >> access client is unable to prompt the user for a new response, it >> MUST treat the AA-Answer (AAA) with the Reply-Message AVP as an >> error and deny access. > > The 'it' means the client? The client must deny access? > > >> 3.3. Re-Auth-Request (RAR) Command >> >> A Diameter server may initiate a re-authentication and/or re- > > may? > > >> authorization service for a particular session by issuing a >> Re-Auth- Request (RAR) message [I-D.ietf-dime-rfc3588bis]. > > Re-authorization "service"? I don't understand what the word means > here and didn't find any obvious guidance in the base Diameter > document. > > The additional uses of the word in the next paragraph added to my > confusion. > > >> For example, for pre-paid services, the Diameter server that >> originally authorized a session may need some confirmation that >> the user is still using the services. > > I have no idea what this is about, what it's basis is or what it > means. It seems to presume that the reader knows exactly what is > being referred to, as 'pre-paid services' and why it would need some > (additional) confirmation. > > >> If a NAS receives an RAR message with Session-Id equal to a >> currently active session and a Re-Auth-Type that includes >> authentication, it MUST initiate a re-authentication toward the >> user, if the service supports this particular feature. > > and if it doesn't, then what? > > > >> 3.4. Re-Auth-Answer (RAA) Command >> >> The Re-Auth-Answer (RAA) message [I-D.ietf-dime-rfc3588bis] is >> sent in response to the RAR. The Result-Code AVP MUST be present >> and indicates the disposition of the request. >> >> A successful RAA transaction MUST be followed by an AAR message. > > transaction -> command { ? } > > >> 3.5. Session-Termination-Request (STR) Command >> >> The Session-Termination-Request (STR) message >> [I-D.ietf-dime-rfc3588bis] is sent by the NAS to inform the >> Diameter Server that an authenticated and/or authorized session is >> being terminated. > > "is being". Again, this is passive voice for a 'command'. > Consequently it is not clear whether the requestor has done the > termination or is requesting that the server terminate. I assume the > latter, but the text leaves this open. > > >> 3.6. Session-Termination-Answer (STA) Command >> >> The Session-Termination-Answer (STA) message >> [I-D.ietf-dime-rfc3588bis] is sent by the Diameter Server to >> acknowledge the notification that the session has been terminated. >> The Result-Code AVP MUST be present and MAY contain an indication >> that an error occurred while the STR was being serviced. >> >> Upon sending or receiving the STA, the Diameter Server MUST >> release all resources for the session indicated by the Session-Id >> AVP. Any intermediate server in the Proxy-Chain MAY also release >> any resources, if necessary. > > The server can /receive/ an STA? That appears to be at odds with the > first paragraph. > > >> 3.7. Abort-Session-Request (ASR) Command >> >> The Abort-Session-Request (ASR) message [I-D.ietf-dime-rfc3588bis] >> may be sent by any server to the NAS providing session service, to >> request that the session identified by the Session-Id be stopped. > > "by any server" suggests a multi-server model, with a NAS talking to > more than one at a time (for a given session...?) As I understand > it, NAS/Server sessions are bilateral, not multi-lateral. In > addition, the "providing session service" implies that a NAS could be > relevant to this text when it is /not/ providing session service. > This seems unlikely. > > So the language here probably should be: > > MAY be sent by the server to the NAS to request that... > > > >> 3.8. Abort-Session-Answer (ASA) Command >> >> The ASA message [I-D.ietf-dime-rfc3588bis] is sent in response to >> the ASR. The Result-Code AVP MUST be present and indicates the >> disposition of the request. > > Who sends to whom? > > >> 3.9. Accounting-Request (ACR) Command >> >> The ACR message [I-D.ietf-dime-rfc3588bis] is sent by the NAS to >> report its session information to a target server downstream. > > 'downstream'? Is it relayed through intermediaries? What does > 'downstream' mean here, beyond simply having a client/server > dialogue? > > >> The Acct-Application-Id AVP MUST be present. >> >> The AVPs listed in the Base protocol specification >> [I-D.ietf-dime-rfc3588bis] MUST be assumed to be present, as > > What does "assumed to be present" mean? What is the point behind > "assuming" and does this just mean supported by client and server > software? Required to be used in the protocol exchanges? Something > else? > > > >> 3.10. Accounting-Answer (ACA) Command >> >> The ACA message [I-D.ietf-dime-rfc3588bis] is used to acknowledge >> an > > is used to acknowledge -> acknowledges > > >> Accounting-Request command. The Accounting-Answer command >> contains the same Session-Id as the Request. The same level of >> security MUST be applied to both the Accounting-Request and the >> corresponding > > Is this security requirement special to this command or is it > univeral? Why? > > >> Accounting-Answer message. For example, if the ACR was protected >> using end-to-end security techniques then the corresponding ACA >> message MUST be protected in the same way; note, however, that the >> definition of such techniques is outside the scope of this >> document. >> >> Only the target Diameter Server or home Diameter Server SHOULD >> respond with the Accounting-Answer command. > > target vs. home. What distinguishes which is to respond? How are > they to know? > > > >> 4. Diameter NAS Application AVPs >> >> The following sections define a new derived AVP data format, a set >> of > > "new" will not mean much 10 years from now. RFCs should be written > for long-term reading. > > "derived"? What does this mean? > > >> application-specific AVPs and describe the use of AVPs defined in >> other documents by the Diameter NAS Application. >> >> 4.1. Derived AVP Data Formats >> >> 4.1.1. QoSFilterRule > > What is the /purpose/ of this? Presumably it has something to do > with filtering, but there's no context for it established. > > >> The QosFilterRule format is derived from the OctetString AVP Base >> Format. It uses the ASCII charset. Packets may be marked or >> metered based on the following information: >> > > marked vs. metered ? > > >> >> >> Zorn Expires November 19, 2012 [Page 23] >> Internet-Draft Diameter NASREQ May 2012 >> >> >> o Direction (in or out) >> >> o Source and destination IP address (possibly masked) >> >> o Protocol >> >> o Source and destination port (lists or ranges) >> >> o DSCP values (no mask or range) > > DSCP? > > >> Rules for the appropriate direction are evaluated in order; the >> first > > "Rules for the appropriate direction"? What does this mean? > > >> matched rule terminates the evaluation. Each packet is evaluated >> once. If no rule matches, the packet is treated as best effort. >> An access device unable to interpret or apply a QoS rule SHOULD >> NOT terminate the session. > > This appears to be discussing a /set/ of rules, but there's been no > discussion of a set. This appears to presume a model that hasn't > been introduced. > > >> >> QoSFilterRule filters MUST follow the following format: > > There is more than one filter? Does this mean multiple sets or > multiple rules within a single set? > > >> action dir proto from src to dst [options] > > Where are the /semantics/ of these defined? > > >> where >> >> action tag Mark packet with a specific DSCP [RFC2474] meter >> Meter traffic >> >> dir The format is as described under IPFilterRule >> [I-D.ietf-dime-rfc3588bis] >> >> proto The format is as described under IPFilterRule >> [I-D.ietf-dime-rfc3588bis] >> >> src and dst The format is as described under IPFilterRule >> [I-D.ietf-dime-rfc3588bis] >> >> The options are described in Section 4.4.9. > > I didn't see them there. > >> >> The rule syntax is a modified subset of ipfw(8) from FreeBSD, and >> the ipfw.c code may provide a useful base for implementations. > > "may be provided"??? I thought this was a protocol specification > which defines its details or cites them formally. > > >> 4.2. NAS Session AVPs >> >> Diameter reserves the AVP Codes 0 - 255 for RADIUS Attributes that >> are implemented in Diameter. >> >> 4.2.1. Call and Session Information >> >> This section describes the AVPs specific to Diameter applications >> that are needed to identify the call and session context and >> status >> >> >> >> Zorn Expires November 19, 2012 [Page 24] >> Internet-Draft Diameter NASREQ May 2012 >> >> >> information. On a request, this information allows the server to >> qualify the session. > > "on a request"? > > >> These AVPs are used in addition to the following AVPs from the >> base protocol specification [I-D.ietf-dime-rfc3588bis]: >> >> Session-Id Auth-Application-Id Origin-Host Origin-Realm >> Auth-Request-Type Termination-Cause >> >> The following table gives the possible flag values for the session >> level AVPs. > > "session-level"? > > >> +----------+ | AVP Flag | | rules | |----+-----+ |MUST| MUST| >> Attribute Name Section Defined | | NOT| >> -----------------------------------------|----+-----| NAS-Port >> 4.2.2 | M | V | NAS-Port-Id 4.2.3 | M | >> V | NAS-Port-Type 4.2.4 | M | V | >> Called-Station-Id 4.2.5 | M | V | >> Calling-Station-Id 4.2.6 | M | V | Connect-Info >> 4.2.7 | M | V | Originating-Line-Info 4.2.8 | M >> | V | Reply-Message 4.2.9 | M | V | >> -----------------------------------------|----+-----| >> >> 4.2.2. NAS-Port AVP >> >> The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains >> the physical or virtual port number of the NAS which is >> authenticating the user. Note that "port" is meant in its sense as >> a service connection on the NAS, not as an IP protocol identifier. > > "service connection on the NAS"? > > "virtual" port number? This is the only time the term is used, and I > don't see it in the base Diameter document and I don't know what it > means. > > >> Either the NAS-Port AVP or the NAS-Port-Id AVP (Section 4.2.3) >> SHOULD be present in the AA-Request (AAR, Section 3.1) command if >> the NAS differentiates among its ports. >> >> 4.2.3. NAS-Port-Id AVP >> >> The NAS-Port-Id AVP (AVP Code 87) is of type UTF8String and >> consists of ASCII text identifying the port of the NAS >> authenticating the >> >> >> >> Zorn Expires November 19, 2012 [Page 25] >> Internet-Draft Diameter NASREQ May 2012 >> >> >> user. Note that "port" is meant in its sense as a service >> connection on the NAS, not as an IP protocol identifier. > > Although this doesn't distinguish physical from virtual, it does > explain the term port. I suspect such explanations should be broken > out into an earlier section that provides some framework and > terminology. This will avoid having definitions buried deeply and > possibly after first use. This can be especially helpful for > sections, like this one, that seem likely to be used for reference, > and therefore not read sequentially. > > >> >> Either the NAS-Port-Id AVP or the NAS-Port AVP (Section 4.2.2) >> SHOULD be present in the AA-Request (AAR, Section 3.1) command if >> the NAS differentiates among its ports. NAS-Port-Id is intended >> for use by NASes that cannot conveniently number their ports. >> >> 4.2.4. NAS-Port-Type AVP >> >> The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and > > "Enumerated"? Where are the types defined? > > >> 4.2.9. Reply-Message AVP >> >> The Reply-Message AVP (AVP Code 18) is of type UTF8String and >> contains text that MAY be displayed to the user. When used in an >> AA- > > Since I doubt that this specification is intended to cover user > interface design -- and hope that it is not -- I think that the > normative, semantic point in specification terms is that the strings > MUST be created with the intent of displaying them to humans. That > is, these are human-consumable strings, not (necessarily) > computer-consumable. > > > >> 4.4.1. Service-Type AVP >> >> The Service-Type AVP (AVP Code 6) is of type Enumerated and >> contains the type of service the user has requested or the type of >> service to be provided. One such AVP MAY be present in an >> authentication and/or authorization request or response. A NAS is >> not required to implement all of these service types. It MUST >> treat unknown or unsupported Service-Types received in a response >> as a failure and end the session with a DIAMETER_INVALID_AVP_VALUE >> Result-Code. >> >> When used in a request, the Service-Type AVP SHOULD be considered >> a hint to the server that the NAS believes the user would prefer >> the kind of service indicated. The server is not required to honor >> the > > A hint is a hint. It would be odd and probably wrong for an > implementer to be "required to honor the hint". If they are > required, it's not a hint. > > I believe the simpler and more useful phrasing would simply be: > > When used in a request, the Service-Type AVP is only a hint to the > server that the NAS believes... > > And then delete the sentence after. > >> hint. Furthermore, if the service specified by the server is >> supported, but not compatible with the current mode of access, the >> NAS MUST fail to start the session. The NAS MUST also generate the >> appropriate error message(s). > > Doesn't "MUST fail to start" equate to "MUST NOT start" and wouldn't > that be the simpler and more typical phrasing? > > "appropriate"? What are the criteria and how is the implementer to > know? > > > >> 4.4.10.5.4. Framed-Pool AVP >> >> The Framed-Pool AVP (AVP Code 88) is of type OctetString and >> contains the name of an assigned address pool that SHOULD be used >> to assign an address for the user. If a NAS does not support >> multiple address pools, the NAS SHOULD ignore this AVP. Address >> pools are usually used for IP addresses but can be used for other >> protocols if the NAS supports pools for those protocols. > > Hmmm. If the NAS does not support multiple address pools and doesn't > ignore this AVP, what happens and how will it be interoperable? > > This seems like something that requires an exact, shared model > between the two sides, or else it's merely a notational convenience > without interoperability substance. That is, either it's a MAY or a > MUST? Or there needs to be some explanation of how to deal with the > mismatch between the two sides. > > > > // > > d/ From jasnell@gmail.com Mon Oct 1 08:32:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059C71F0C7E for ; Mon, 1 Oct 2012 08:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 tagged_above=-999 required=5 tests=[AWL=-1.370, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_42=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 6BvvdSV+NQDQ for ; Mon, 1 Oct 2012 08:32:04 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20F501F0D1B for ; Mon, 1 Oct 2012 08:32:03 -0700 (PDT) Received: by weyu46 with SMTP id u46so3299997wey.31 for ; Mon, 01 Oct 2012 08:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2pY9xhMsRLx0IvsgCKDbnBQHyZJ1+/7WZhaOOtG47lA=; b=Suh9rsVULUnNKA8IMHFccmf2VL1v26i6liqATr6JX32bMC5VZkGa3Ee41KuREorHQQ y6/YmK41dDM1ywVbNSt3YSO5JiIWAcXLIaQ2U7NpS8HTqux01BYNl/YgdC0WSY/9YIYx Pjr3CRPBeebFC1Jx8+JynOmVM7dSZYWM9JnyyLcycES9jKu8HujAd8Cl/j33kaSnoRx9 L8a4EMhKn9Uw6F4PAqM/ryPy+QQLLzfHxeox5hOuLxgR8epdTrGrtgalF8r/f+zSCrGC waHiHVI8rXjW6qHATtJSfnu5/9HGHRi5zSO44nQP67fnPhGr1Y9WT9usHO8L2dwu/6h3 Hz4w== Received: by 10.180.102.164 with SMTP id fp4mr15462251wib.13.1349105523270; Mon, 01 Oct 2012 08:32:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Mon, 1 Oct 2012 08:31:43 -0700 (PDT) In-Reply-To: References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E114FD642F4D@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Mon, 1 Oct 2012 08:31:43 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=f46d04462e647aa2f704cb011bef Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] json-patch: draft 05 comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 15:32:08 -0000 --f46d04462e647aa2f704cb011bef Content-Type: text/plain; charset=UTF-8 On Mon, Oct 1, 2012 at 4:45 AM, Mark Nottingham wrote: > [snip] > > 4.2. remove: it needn't be an error to remove a value that does not > exist (eg has already been removed). > > OLD: "The value at the specified location MUST exist for the operation > to be successful." > > NEW: "If there is no value as the specified location the operation has > no affect." > > Needs discussion. > > In general this is probably ok, however, if patch is asking to remove a value that does not exist, then it's a possible indication that the resource has been modified in other ways since the patch document was generated, or possibly that some other previous operation or error condition has left the document in an inconsistent state. If we allow this one, what should we do if someone attempts to use "replace" with a value that doesn't exist? > > 4.4. move and 4.5. copy: defining an exception for the pointless > path=to case is unnecessary. "move" should be "path" as well. > > REMOVE: "unless "move"(sic) and "to" specify the same object, which has > no effect" > > "move" changed to "path". Removing it needs discussion; this was an > explicit decision earlier, discussed as issue #9 < > http://trac.tools.ietf.org/wg/appsawg/trac/ticket/9>. > > Not exactly sure what you mean by "move" changed to "path". > > 4.5. copy: can you copy a value into a component of itself? That is, > can "path" be a prefix of "to"? > > {"op":"copy", "path":"/a", "to":"/a/b/c"} > > Needs discussion, but good point; I suspect we need a constraint here. > > likewise with "move" really... {"a": {"b": {}}} It would be quite silly to do {"op":"move","path":"/a","to":"/a/b"} For copy, it's not as much of an obvious error tho (even if it is completely non-sensical). Perhaps use MUST NOT with "move" and SHOULD NOT with "copy" ? > > 4.4. move: moving a value to an object element should replace any > existing value at that element if there is one, instead of being an error. > Similarly with copy. > > Needs discussion. > > -1 ... with stuff like this it becomes too easy to make accidental changes. I would much rather require an explicit delete of the existing value prior to issuing the "move". > > 5. Error Handling. "a RFC2119 requirement" is a very awkward way to > refer to "MUST" statements in this draft. > > OLD: "If a RFC2119 [RFC2119] requirement is violated by a JSON Patch > document, or if an operation is not successful" > > NEW: "If any operation is not successful" > > I agree that it's a bit awkward, but there are two things happening here; > one is a violation by the doc, another is the operation failing. If you > have a suggestion that's smoother yet captures both, I'd be glad to > incorporate it. > "If a JSON Patch document violates any of the normative requirements of this specification, or if an operation is not successful, evaluation of the JSON Patch document SHOULD terminate and application of the entire patch document SHALL NOT be deemed successful." > > Appendix A. Examples: add examples with unrecognized elements and > invalid operations > > NEW: A.11. Ignore unrecognized elements > > An example target JSON document: > > {"foo":"bar"} > > A JSON Patch document: > > [{"op":"add", "path":"/baz", "value":"qux", "xyz":123}] > > The resulting JSON document: > > {"foo":"bar", "baz":"qux"} > > > > NEW: A.12. Invalid JSON Patch document > > A JSON Patch document: > > [{"op":"add", "path":"/baz", "value":"qux", "op":"remove"}] > > This JSON Patch document MUST NOT be treated as an "add" > > operation since there is a later "op":"remove" element. > > It SHOULD be an error. A JSON parser that hides such duplicate > > element names MUST NOT be used unless it always exposes only > > the last element with a given name (eg "op":"remove" in this > example). > > > Added in SVN, although I removed the RFC2119 language, as it's not good to > have in examples, or to repeat requirements. > > Cheers and thanks again, > > -- > Mark Nottingham > http://www.mnot.net/ > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d04462e647aa2f704cb011bef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 1, 2012 at 4:45 AM, Mark Nottingham <<= a href=3D"mailto:mnot@mnot.net" target=3D"_blank">mnot@mnot.net> wrote:
[snip]
> 4.2. remove: it needn't be an error to remove a value that does no= t exist (eg has already been removed).
> OLD: "The value at the specified location MUST exist for the oper= ation to be successful."
> NEW: "If there is no value as the specified location the operatio= n has no affect."

Needs discussion.


In general thi= s is probably ok, however, if patch is asking to remove a value that does n= ot exist, then it's a possible indication that the resource has been mo= dified in other ways since the patch document was generated, or possibly th= at some other previous operation or error condition has left the document i= n an inconsistent state.

If we allow this one, what should we do if someone atte= mpts to use "replace" with a value that doesn't exist?
<= div>=C2=A0
> 4.4. move and 4.5. copy: defining an exception for the pointless path= =3Dto case is unnecessary. "move" should be "path" as w= ell.
> REMOVE: "unless "move"(sic) and "to" specify = the same object, which has no effect"

"move" changed to "path". Removing it needs discu= ssion; this was an explicit decision earlier, discussed as issue #9 <http://trac.tools.ietf.org/wg/appsawg/trac/ticket/9>.


Not exactly su= re what you mean by "move" changed to "path".
=C2=A0
> 4.5. copy: can you copy a value into a component of itself? That is, c= an "path" be a prefix of "to"?
> =C2=A0{"op":"copy", "path":"/a"= ;, "to":"/a/b/c"}

Needs discussion, but good point; I suspect we need a constraint here= .


likewise with = "move" really...=C2=A0

{"a": {= "b": {}}}

It would be quite silly to do = {"op":"move","path":"/a","to&q= uot;:"/a/b"}

For copy, it's not as much of an obvious error tho = (even if it is completely non-sensical). Perhaps use MUST NOT with "mo= ve" and SHOULD NOT with "copy" ?
=C2=A0
> 4.4. move: moving a value to an object element should replace any exis= ting value at that element if there is one, instead of being an error. Simi= larly with copy.

Needs discussion.


-1 ... with st= uff like this it becomes too easy to make accidental changes. I would much = rather require an explicit delete of the existing value prior to issuing th= e "move".=C2=A0
=C2=A0
> 5. Error Handling. "a RFC2119 requirement" is a very awkward= way to refer to "MUST" statements in this draft.
> OLD: "If a RFC2119 [RFC2119] requirement is violated by a JSON Pa= tch document, or if an operation is not successful"
> NEW: "If any operation is not successful"

I agree that it's a bit awkward, but there are two things happeni= ng here; one is a violation by the doc, another is the operation failing. I= f you have a suggestion that's smoother yet captures both, I'd be g= lad to incorporate it.


"If a JSON Patch=C2=A0= document violates any of the normative requirements of this specification,= =C2=A0
or if an operation is not successful, evaluation of the=C2= =A0JSON Patch document SHOULD=C2=A0
terminate and application of the entire=C2=A0patch document SHALL NOT = be deemed successful."=C2=A0



> Appendix A. Examples: add examples with unrecognized elements and inva= lid operations
> NEW: =C2=A0A.11. Ignore unrecognized elements
> =C2=A0 =C2=A0 =C2=A0 =C2=A0An example target JSON document:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 {"foo":"bar"}
> =C2=A0 =C2=A0 =C2=A0 =C2=A0A JSON Patch document:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 [{"op":"add", "pa= th":"/baz", "value":"qux", "xyz&quo= t;:123}]
> =C2=A0 =C2=A0 =C2=A0 =C2=A0The resulting JSON document:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 {"foo":"bar", "ba= z":"qux"}
>
> NEW: =C2=A0A.12. Invalid JSON Patch document
> =C2=A0 =C2=A0 =C2=A0 =C2=A0A JSON Patch document:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 [{"op":"add", "pa= th":"/baz", "value":"qux", "op"= ;:"remove"}]
> =C2=A0 =C2=A0 =C2=A0 =C2=A0This JSON Patch document MUST NOT be treate= d as an "add"
> =C2=A0 =C2=A0 =C2=A0 =C2=A0operation since there is a later "op&q= uot;:"remove" element.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0It SHOULD be an error. A JSON parser that h= ides such duplicate
> =C2=A0 =C2=A0 =C2=A0 =C2=A0element names MUST NOT be used unless it al= ways exposes only
> =C2=A0 =C2=A0 =C2=A0 =C2=A0the last element with a given name (eg &quo= t;op":"remove" in this example).


Added in SVN, although I removed the RFC2119 language, as it's no= t good to have in examples, or to repeat requirements.

Cheers and thanks again,

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




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

--f46d04462e647aa2f704cb011bef-- From jasnell@gmail.com Mon Oct 1 08:39:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0554321F8831 for ; Mon, 1 Oct 2012 08:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=-1.186, BAYES_40=-0.185, 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 KIdXLESaKmvu for ; Mon, 1 Oct 2012 08:39:08 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5CC21F8818 for ; Mon, 1 Oct 2012 08:39:07 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so2245995wib.13 for ; Mon, 01 Oct 2012 08:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=U0gufAbe9aRbPZiHz1mW26P5xWmiv+hIvo/Zp/rWqXg=; b=mmooblcWZlNaR6WFJM7ifRGHnLxyqDNyPE7jYU40iaYkfV7ZLeG8aylXgys1INPxf0 bOuPlKUkbB9yOr7HPY3sVbN509nT+RuDZdS0F+EpxTHoxCQwoeKGCvxHsGWou27YM39Y JzhXo8KGSJI78YHMOABFQXpzPlDHvLSOFn5mP32DlMSoFzHJbhpktgnc0z2aSiRYF1Ye bdH1eO1hfD9/BBXQFRabjb2ac/gkoDIFyJxnW2s9BZMqh7p0C+yH8pJHQWi6KXkr/6+T LP0ogKeJnhHRu0XrV2eYXgGAggDttTrjVlVgoDRxeawbM5Q+KPg/v7frzL+fYx03Q0ee PQ5Q== Received: by 10.216.135.148 with SMTP id u20mr7709469wei.137.1349105945030; Mon, 01 Oct 2012 08:39:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Mon, 1 Oct 2012 08:38:44 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FD642E67@WSMSG3153V.srv.dir.telstra.com> References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E114FD642E67@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Mon, 1 Oct 2012 08:38:44 -0700 Message-ID: To: "Manger, James H" Content-Type: multipart/alternative; boundary=0016e6dd99209e2f4f04cb0134ec Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] json-patch: "op":"tree" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 15:39:09 -0000 --0016e6dd99209e2f4f04cb0134ec Content-Type: text/plain; charset=UTF-8 Definitely agree that this would be useful. In the JSON-TEST draft that I'm updating and will be publishing later today, I have a "base" predicate that essentially does the same thing. Having this in the base JSON-PATCH spec could be useful but it does introduce a potentially complex new structure (not necessarily a bad thing, but definitely something to keep in mind). Rather than calling it "tree", I'd prefer a name such as "base" ... as you're establishing a base path for the contained operations. [ {"op": "base", "path": "/a/b", ops: [ {"op": "add", "path":"/c", "value": "This is added to /a/b/c"}, {"op": "base", "path": "/d/e", ops: [ {"op": "add", "path":"/f", "value": "This is added to /a/b/d/e/f"} ] ]}, {"op": "add", "path":"/g", "value": "This is added to /g"} ] Definite +1 to this. - James On Sun, Sep 30, 2012 at 10:41 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > RE: draft-ietf-appsawg-json-patch-05 > > Suggestion: define a "tree" operation for grouping operations that apply > to part of the JSON doc being changed. It avoids repeating a path prefix in > lots of operations; it simplifies writing a patch that can be applied at > different points; its easier to separate the patch for changing a value > from where that value is in a larger JSO structure. New text: > > 4.7. tree > > The "tree" operation applies other operations to a subset of > the target. The operation object MUST include "path" and "ops" > members. "path" holds a JSON pointer that identifies the value > to which the other operations apply. "ops" holds an array of > operation objects. JSON pointers within "ops" are relative > to the value identified by "path". > > Example: > Old: {"a":{"b":{"c":{"d":{"e":{"name":"Alice"}}}}}} > Patch: [{"op":"tree", "path":"/a/b/c/d/e", "ops":[ > {"op":"add", "path":"/age", "value":20}, > {"op":"add", "path":"/email", "value":"a@eg.com"}]}] > New: {"a":{"b":{"c":{"d":{"e":{ > "name":"Alice", "age":20, "email":"a@eg.com"}}}}}} > > -- > James Manger > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --0016e6dd99209e2f4f04cb0134ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Definitely agree that this would be us= eful. In the JSON-TEST draft that I'm updating and will be publishing l= ater today, I have a "base" predicate that essentially does the s= ame thing. Having this in the base JSON-PATCH spec could be useful but it d= oes introduce a potentially complex new structure (not necessarily a bad th= ing, but definitely something to keep in mind). Rather than calling it &quo= t;tree", I'd prefer a name such as "base" ... as you'= ;re establishing a base path for the contained operations.

[
=C2=A0 {"op": "base", "path": "/a/b= ", ops: [
=C2=A0 =C2=A0 {"op": &= quot;add", "path":"/c", "value": "T= his is added to /a/b/c"},
=C2=A0 =C2=A0 {"op": "base", "path"= ;: "/d/e", ops: [
=C2=A0 =C2=A0 =C2=A0 {"op&q= uot;: "add", "path":"/f", "value": = "This is added to /a/b/d/e/f"}
=C2=A0 =C2=A0 ]
=C2=A0 ]},
=C2=A0 {"op": &q= uot;add", "path":"/g", "value": "Th= is is added to /g"}
]

Definite +1 to this.

- James


On Sun, Sep 30, 2012 at 10:41 PM, Manger, J= ames H <James.H.Manger@team.telstra.com> wrote= :
RE: draft-ietf-appsawg-json-patch-05

Suggestion: define a "tree" operation for grouping operations tha= t apply to part of the JSON doc being changed. It avoids repeating a path p= refix in lots of operations; it simplifies writing a patch that can be appl= ied at different points; its easier to separate the patch for changing a va= lue from where that value is in a larger JSO structure. New text:

=C2=A0 4.7. tree

=C2=A0 =C2=A0 The "tree" operation applies other operations to a = subset of
=C2=A0 =C2=A0 the target. The operation object MUST include "path"= ; and "ops"
=C2=A0 =C2=A0 members. "path" holds a JSON pointer that identifie= s the value
=C2=A0 =C2=A0 to which the other operations apply. "ops" holds an= array of
=C2=A0 =C2=A0 operation objects. JSON pointers within "ops" are r= elative
=C2=A0 =C2=A0 to the value identified by "path".

=C2=A0 =C2=A0 Example:
=C2=A0 =C2=A0 Old: =C2=A0 {"a":{"b":{"c":{&qu= ot;d":{"e":{"name":"Alice"}}}}}}
=C2=A0 =C2=A0 Patch: [{"op":"tree", "path":&q= uot;/a/b/c/d/e", "ops":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {"op":"add&= quot;, "path":"/age", "value":20},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {"op":"add&= quot;, "path":"/email", "value":"a@eg.com"}]}]
=C2=A0 =C2=A0 New: =C2=A0 {"a":{"b":{"c":{&qu= ot;d":{"e":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name":"Alice"= ;, "age":20, "email":"= a@eg.com"}}}}}}

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

--0016e6dd99209e2f4f04cb0134ec-- From mnot@mnot.net Mon Oct 1 08:46:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3280B11E8112 for ; Mon, 1 Oct 2012 08:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3KP8l4IMyNl for ; Mon, 1 Oct 2012 08:46:01 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 284A111E80D5 for ; Mon, 1 Oct 2012 08:46:00 -0700 (PDT) Received: from [192.168.16.71] (unknown [80.194.52.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9FA3422E259; Mon, 1 Oct 2012 11:45:53 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Mark Nottingham In-Reply-To: Date: Mon, 1 Oct 2012 16:45:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <04178555-0928-4E67-AE3C-4DE63C023D6F@mnot.net> References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E114FD642E67@WSMSG3153V.srv.dir.telstra.com> To: James M Snell X-Mailer: Apple Mail (2.1498) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] json-patch: "op":"tree" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 15:46:02 -0000 Personally -- I'm concerned about the complexity, but open to it (again, as long as we = don't trip on it). What about "with"? Cheers, On 01/10/2012, at 4:38 PM, James M Snell wrote: > Definitely agree that this would be useful. In the JSON-TEST draft = that I'm updating and will be publishing later today, I have a "base" = predicate that essentially does the same thing. Having this in the base = JSON-PATCH spec could be useful but it does introduce a potentially = complex new structure (not necessarily a bad thing, but definitely = something to keep in mind). Rather than calling it "tree", I'd prefer a = name such as "base" ... as you're establishing a base path for the = contained operations. >=20 > [ > {"op": "base", "path": "/a/b", ops: [ > {"op": "add", "path":"/c", "value": "This is added to /a/b/c"}, > {"op": "base", "path": "/d/e", ops: [ > {"op": "add", "path":"/f", "value": "This is added to = /a/b/d/e/f"} > ] > ]}, > {"op": "add", "path":"/g", "value": "This is added to /g"} > ] >=20 > Definite +1 to this. >=20 > - James >=20 >=20 > On Sun, Sep 30, 2012 at 10:41 PM, Manger, James H = wrote: > RE: draft-ietf-appsawg-json-patch-05 >=20 > Suggestion: define a "tree" operation for grouping operations that = apply to part of the JSON doc being changed. It avoids repeating a path = prefix in lots of operations; it simplifies writing a patch that can be = applied at different points; its easier to separate the patch for = changing a value from where that value is in a larger JSO structure. New = text: >=20 > 4.7. tree >=20 > The "tree" operation applies other operations to a subset of > the target. The operation object MUST include "path" and "ops" > members. "path" holds a JSON pointer that identifies the value > to which the other operations apply. "ops" holds an array of > operation objects. JSON pointers within "ops" are relative > to the value identified by "path". >=20 > Example: > Old: {"a":{"b":{"c":{"d":{"e":{"name":"Alice"}}}}}} > Patch: [{"op":"tree", "path":"/a/b/c/d/e", "ops":[ > {"op":"add", "path":"/age", "value":20}, > {"op":"add", "path":"/email", "value":"a@eg.com"}]}] > New: {"a":{"b":{"c":{"d":{"e":{ > "name":"Alice", "age":20, "email":"a@eg.com"}}}}}} >=20 > -- > James Manger > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 -- Mark Nottingham http://www.mnot.net/ From jasnell@gmail.com Mon Oct 1 08:55:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFFB1F0D31 for ; Mon, 1 Oct 2012 08:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 uJh87m-EMEuC for ; Mon, 1 Oct 2012 08:55:37 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id F26D41F0C7E for ; Mon, 1 Oct 2012 08:55:36 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so2267270wib.13 for ; Mon, 01 Oct 2012 08:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=O3tNAhLNTsAkvMOt7Z2iWm6gOYxPvL6yd+mO01JAFFo=; b=NOlskKYHHqCj96YU31UduG9hslb4HCSgGh2O0m72goLxsqtBUYbAHb98nv6+vCfA24 ioq2nlSrxA8uodI7ptSgVChgsmGGqPU0Zo4dLR1asebWhTt/ixi1POVC0YXi2NrB8SXs 4FdrjRu4xvdZgo3fe0fBgTioQDBbRyx6wT7MYT2LiTfOb2rTcifBWdPB5J86UEe86fwJ 3p7/Y+cPfNNNCuCDAuOUZWWeZjnlTY+y6qsTIGu+NSoMbuMo5TFQkz+JJMTxMmNtq/yE 4m80Nr/T9qEawtJfkJxORCWkH/08Pl/9XfoklsXes+5ExuZ5s+DNBh1NA351cON67fz0 MV9g== Received: by 10.216.243.74 with SMTP id j52mr7604322wer.108.1349106936059; Mon, 01 Oct 2012 08:55:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Mon, 1 Oct 2012 08:55:15 -0700 (PDT) In-Reply-To: <04178555-0928-4E67-AE3C-4DE63C023D6F@mnot.net> References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E114FD642E67@WSMSG3153V.srv.dir.telstra.com> <04178555-0928-4E67-AE3C-4DE63C023D6F@mnot.net> From: James M Snell Date: Mon, 1 Oct 2012 08:55:15 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=e0cb4e43cf1fb01a1b04cb016f1c Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] json-patch: "op":"tree" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 15:55:38 -0000 --e0cb4e43cf1fb01a1b04cb016f1c Content-Type: text/plain; charset=UTF-8 Yes, there is definitely a risk of increased complexity here but I think it's manageable in this case. Yes, a developer could get quite carried away with too many layers of nesting but that's more an implementation detail and we can have some simple language warning people away from that if necessary. The important thing is that having this does not significantly impact the basic processing of the patch document, and a patch that contains these can easily be translated into a flattened set of patch operations with explicit paths. I'm not overly concerned with what we call it so long as the name is descriptive of it's purpose. "tree" is a bit unclear. "with" is ok, I suppose. On Mon, Oct 1, 2012 at 8:45 AM, Mark Nottingham wrote: > Personally -- > > I'm concerned about the complexity, but open to it (again, as long as we > don't trip on it). > > What about "with"? > > Cheers, > > > On 01/10/2012, at 4:38 PM, James M Snell wrote: > > > Definitely agree that this would be useful. In the JSON-TEST draft that > I'm updating and will be publishing later today, I have a "base" predicate > that essentially does the same thing. Having this in the base JSON-PATCH > spec could be useful but it does introduce a potentially complex new > structure (not necessarily a bad thing, but definitely something to keep in > mind). Rather than calling it "tree", I'd prefer a name such as "base" ... > as you're establishing a base path for the contained operations. > > > > [ > > {"op": "base", "path": "/a/b", ops: [ > > {"op": "add", "path":"/c", "value": "This is added to /a/b/c"}, > > {"op": "base", "path": "/d/e", ops: [ > > {"op": "add", "path":"/f", "value": "This is added to /a/b/d/e/f"} > > ] > > ]}, > > {"op": "add", "path":"/g", "value": "This is added to /g"} > > ] > > > > Definite +1 to this. > > > > - James > > > > > > On Sun, Sep 30, 2012 at 10:41 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote: > > RE: draft-ietf-appsawg-json-patch-05 > > > > Suggestion: define a "tree" operation for grouping operations that apply > to part of the JSON doc being changed. It avoids repeating a path prefix in > lots of operations; it simplifies writing a patch that can be applied at > different points; its easier to separate the patch for changing a value > from where that value is in a larger JSO structure. New text: > > > > 4.7. tree > > > > The "tree" operation applies other operations to a subset of > > the target. The operation object MUST include "path" and "ops" > > members. "path" holds a JSON pointer that identifies the value > > to which the other operations apply. "ops" holds an array of > > operation objects. JSON pointers within "ops" are relative > > to the value identified by "path". > > > > Example: > > Old: {"a":{"b":{"c":{"d":{"e":{"name":"Alice"}}}}}} > > Patch: [{"op":"tree", "path":"/a/b/c/d/e", "ops":[ > > {"op":"add", "path":"/age", "value":20}, > > {"op":"add", "path":"/email", "value":"a@eg.com"}]}] > > New: {"a":{"b":{"c":{"d":{"e":{ > > "name":"Alice", "age":20, "email":"a@eg.com"}}}}}} > > > > -- > > James Manger > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > -- > Mark Nottingham > http://www.mnot.net/ > > > > > --e0cb4e43cf1fb01a1b04cb016f1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, there is definitely a risk of inc= reased complexity here but I think it's manageable in this case. Yes, a= developer could get quite carried away with too many layers of nesting but= that's more an implementation detail and we can have some simple langu= age warning people away from that if necessary. The important thing is that= having this does not significantly impact the basic processing of the patc= h document, and a patch that contains these can easily be translated into a= flattened set of patch operations with explicit paths.=C2=A0

I'm not overly con= cerned with what we call it so long as the name is descriptive of it's = purpose. "tree" is a bit unclear. "with" is ok, I suppo= se.

On Mon, Oct 1, 2012 at 8:45 AM, Mark No= ttingham <mnot@mnot.net> wrote:


On 01/10/2012, at 4:38 PM, James M Snell <jasnell@gmail.com> wrote:

> Definitely agree that this would be useful. In the JSON-TEST draft tha= t I'm updating and will be publishing later today, I have a "base&= quot; predicate that essentially does the same thing. Having this in the ba= se JSON-PATCH spec could be useful but it does introduce a potentially comp= lex new structure (not necessarily a bad thing, but definitely something to= keep in mind). Rather than calling it "tree", I'd prefer a n= ame such as "base" ... as you're establishing a base path for= the contained operations.
>
> [
> =C2=A0 {"op": "base", "path": "/a/b= ", ops: [
> =C2=A0 =C2=A0 {"op": "add", "path":"= ;/c", "value": "This is added to /a/b/c"},
> =C2=A0 =C2=A0 {"op": "base", "path": &qu= ot;/d/e", ops: [
> =C2=A0 =C2=A0 =C2=A0 {"op": "add", "path"= ;:"/f", "value": "This is added to /a/b/d/e/f"= ;}
> =C2=A0 =C2=A0 ]
> =C2=A0 ]},
> =C2=A0 {"op": "add", "path":"/g&quo= t;, "value": "This is added to /g"}
> ]
>
> Definite +1 to this.
>
> - James
>
>
> On Sun, Sep 30, 2012 at 10:41 PM, Manger, James H <James.H.Manger@team.telstra.com> = wrote:
> RE: draft-ietf-appsawg-json-patch-05
>
> Suggestion: define a "tree" operation for grouping operation= s that apply to part of the JSON doc being changed. It avoids repeating a p= ath prefix in lots of operations; it simplifies writing a patch that can be= applied at different points; its easier to separate the patch for changing= a value from where that value is in a larger JSO structure. New text:
>
> =C2=A0 4.7. tree
>
> =C2=A0 =C2=A0 The "tree" operation applies other operations = to a subset of
> =C2=A0 =C2=A0 the target. The operation object MUST include "path= " and "ops"
> =C2=A0 =C2=A0 members. "path" holds a JSON pointer that iden= tifies the value
> =C2=A0 =C2=A0 to which the other operations apply. "ops" hol= ds an array of
> =C2=A0 =C2=A0 operation objects. JSON pointers within "ops" = are relative
> =C2=A0 =C2=A0 to the value identified by "path".
>
> =C2=A0 =C2=A0 Example:
> =C2=A0 =C2=A0 Old: =C2=A0 {"a":{"b":{"c"= :{"d":{"e":{"name":"Alice"}}}}}} > =C2=A0 =C2=A0 Patch: [{"op":"tree", "path&quo= t;:"/a/b/c/d/e", "ops":[
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {"op":"= ;add", "path":"/age", "value":20},
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {"op":"= ;add", "path":"/email", "value":"a@eg.com"}]}]
> =C2=A0 =C2=A0 New: =C2=A0 {"a":{"b":{"c"= :{"d":{"e":{
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name":"Alice= ", "age":20, "email":"a@eg.com"}}}}}}
>
> --
> James Manger
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

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





--e0cb4e43cf1fb01a1b04cb016f1c-- From mnot@mnot.net Mon Oct 1 09:00:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6881211E8166 for ; Mon, 1 Oct 2012 09:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB5zyZ6T1ZFh for ; Mon, 1 Oct 2012 09:00:17 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFEB1F0C7E for ; Mon, 1 Oct 2012 09:00:17 -0700 (PDT) Received: from [192.168.16.71] (unknown [80.194.52.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C478B22E26A; Mon, 1 Oct 2012 12:00:09 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Mark Nottingham In-Reply-To: Date: Mon, 1 Oct 2012 17:00:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5DCE97AB-4A43-4578-913A-1B51D14A29BF@mnot.net> References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E114FD642E67@WSMSG3153V.srv.dir.telstra.com> <04178555-0928-4E67-AE3C-4DE63C023D6F@mnot.net> To: James M Snell X-Mailer: Apple Mail (2.1498) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] json-patch: "op":"tree" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 16:00:22 -0000 {"op": "with", "base": "/foo/bar/baz", do: [ =85 ]} On 01/10/2012, at 4:55 PM, James M Snell wrote: > Yes, there is definitely a risk of increased complexity here but I = think it's manageable in this case. Yes, a developer could get quite = carried away with too many layers of nesting but that's more an = implementation detail and we can have some simple language warning = people away from that if necessary. The important thing is that having = this does not significantly impact the basic processing of the patch = document, and a patch that contains these can easily be translated into = a flattened set of patch operations with explicit paths.=20 >=20 > I'm not overly concerned with what we call it so long as the name is = descriptive of it's purpose. "tree" is a bit unclear. "with" is ok, I = suppose. >=20 > On Mon, Oct 1, 2012 at 8:45 AM, Mark Nottingham wrote: > Personally -- >=20 > I'm concerned about the complexity, but open to it (again, as long as = we don't trip on it). >=20 > What about "with"? >=20 > Cheers, >=20 >=20 > On 01/10/2012, at 4:38 PM, James M Snell wrote: >=20 > > Definitely agree that this would be useful. In the JSON-TEST draft = that I'm updating and will be publishing later today, I have a "base" = predicate that essentially does the same thing. Having this in the base = JSON-PATCH spec could be useful but it does introduce a potentially = complex new structure (not necessarily a bad thing, but definitely = something to keep in mind). Rather than calling it "tree", I'd prefer a = name such as "base" ... as you're establishing a base path for the = contained operations. > > > > [ > > {"op": "base", "path": "/a/b", ops: [ > > {"op": "add", "path":"/c", "value": "This is added to /a/b/c"}, > > {"op": "base", "path": "/d/e", ops: [ > > {"op": "add", "path":"/f", "value": "This is added to = /a/b/d/e/f"} > > ] > > ]}, > > {"op": "add", "path":"/g", "value": "This is added to /g"} > > ] > > > > Definite +1 to this. > > > > - James > > > > > > On Sun, Sep 30, 2012 at 10:41 PM, Manger, James H = wrote: > > RE: draft-ietf-appsawg-json-patch-05 > > > > Suggestion: define a "tree" operation for grouping operations that = apply to part of the JSON doc being changed. It avoids repeating a path = prefix in lots of operations; it simplifies writing a patch that can be = applied at different points; its easier to separate the patch for = changing a value from where that value is in a larger JSO structure. New = text: > > > > 4.7. tree > > > > The "tree" operation applies other operations to a subset of > > the target. The operation object MUST include "path" and "ops" > > members. "path" holds a JSON pointer that identifies the value > > to which the other operations apply. "ops" holds an array of > > operation objects. JSON pointers within "ops" are relative > > to the value identified by "path". > > > > Example: > > Old: {"a":{"b":{"c":{"d":{"e":{"name":"Alice"}}}}}} > > Patch: [{"op":"tree", "path":"/a/b/c/d/e", "ops":[ > > {"op":"add", "path":"/age", "value":20}, > > {"op":"add", "path":"/email", "value":"a@eg.com"}]}] > > New: {"a":{"b":{"c":{"d":{"e":{ > > "name":"Alice", "age":20, "email":"a@eg.com"}}}}}} > > > > -- > > James Manger > > _______________________________________________ > > 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 >=20 -- Mark Nottingham http://www.mnot.net/ From wmills@yahoo-inc.com Mon Oct 1 09:12:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA0B1F0CCD for ; Mon, 1 Oct 2012 09:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.386 X-Spam-Level: X-Spam-Status: No, score=-16.386 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_40=-0.185, 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 FtXCiQSE5kOh for ; Mon, 1 Oct 2012 09:12:43 -0700 (PDT) Received: from nm28-vm0.bullet.mail.ac4.yahoo.com (nm28-vm0.bullet.mail.ac4.yahoo.com [98.139.52.246]) by ietfa.amsl.com (Postfix) with SMTP id 8FFD11F0C7E for ; Mon, 1 Oct 2012 09:12:41 -0700 (PDT) Received: from [98.139.52.197] by nm28.bullet.mail.ac4.yahoo.com with NNFMP; 01 Oct 2012 16:12:36 -0000 Received: from [98.139.52.141] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 01 Oct 2012 16:12:36 -0000 Received: from [127.0.0.1] by omp1024.mail.ac4.yahoo.com with NNFMP; 01 Oct 2012 16:12:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 152578.71631.bm@omp1024.mail.ac4.yahoo.com Received: (qmail 50369 invoked by uid 60001); 1 Oct 2012 16:12:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1349107955; bh=GxuUgkJQlk+Tezb1PsyRV1CHJP/fn6B40zcW+tUB0vM=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=oRXbhmS4fyD124l0EWIki83Q+SETxjTpgRG6ztsByQFHzR/1VQK1R2pRrwZdaqNgcb82EI+/oMIz8wxAu15zOevJRik6ZrVdl1shStvhhvyreijr7/qOvmY8uFbIX60CW/sEUNT6S5OdRqOAbuJsbSpfPa0yh9ksKN9hQGr+Vf8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=H0DTsoLLyERoBGWMgnfcT2rgqSFrI7z83uezLUpGIpakLEWBwR5H96GeHElxqqB2kAeidly4FSfkaUTK/his3AehA6umM/kgIYkV8Fh0xjebLMWOcRcyXF11hL5aFDI5cyTnEor0ub0wA4NNKwTEmghb9/ztqzX4OGSp7UIxU9w=; X-YMail-OSG: cYwgB5AVM1liW13DDmUuxYW77QcqHvxNX7mZUUYw3vziajj ovSSoxBske84PRq_Ol7mG_qi8hi.9n1IVyiVvNApQ7m7vNDGW0aN16ArM_Uw umSIvep8qgf._kXn89I6gJaGpnq52nxPDq4lENZT9XCua2rxWP9us5l21ZqC CfrolUxgGDHGInLb6Mkcsanw_QkEsI_13swlkrEuC0mYQSK_j5nhiqqgEIaF uuI.xV9i1mL.EHVQNb9cekg4vLAm7IfJ1tBOZ3R_zke9UBXbBfWHqVKsSm9y IpVnXbdTPlGQ20KMheS9v9SOOhPNznyus0PzvEtYdrQEM1u10cYJAyEHmWrq vvIFJgIq7GFA.o.2pabj8u_2OYrT4Ycn_O3_L2U4DvxJKPfxn3TykVE5Zyfm NlYel1CyCax9Wg7fOTMmAcgE42LDF26HOh3hYcCHPWaPkgz_FYqwND_kM_f5 NFbQIBbJDpAjjHPBKHsVTR3aMrqV75MmD7_TLiYxSw0bbSt9sXF3S7P1SpzR 2EEjVFHYkWxCjk_Lz8yc4lDBReyZmvyA- Received: from [99.31.212.42] by web31813.mail.mud.yahoo.com via HTTP; Mon, 01 Oct 2012 09:12:35 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.122.442 Message-ID: <1349107955.29811.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Mon, 1 Oct 2012 09:12:35 -0700 (PDT) From: William Mills To: Apps Discuss MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-332189132-1349107955=:29811" Subject: [apps-discuss] Link type registry for OAuth draft 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: Mon, 01 Oct 2012 16:12:46 -0000 --767760015-332189132-1349107955=:29811 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I think the link registry for OAuth 2 is pretty close to done, especially w= ith Goix Laurent Walter's recent review.=A0 If one or two more folks could = give it a read that would be great.=0A=0Ahttp://tools.ietf.org/id/draft-wmi= lls-oauth-lrdd-03.html=0A=0AThanks,=0A=0A-bill=0A --767760015-332189132-1349107955=:29811 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I th= ink the link registry for OAuth 2 is pretty close to done, especially with = Goix Laurent Walter's recent review.  If one or two more folks could g= ive it a read that would be great.

http://tools.ietf.org/id/draft-wmills-oauth-lrdd-03.html

Thanks,

-bill
--767760015-332189132-1349107955=:29811-- From dhc@dcrocker.net Mon Oct 1 09:32:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4291F0CD1; Mon, 1 Oct 2012 09:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_51=0.6, 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 gcUJcPwhGnB1; Mon, 1 Oct 2012 09:32:17 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7371F0CCD; Mon, 1 Oct 2012 09:32:17 -0700 (PDT) Received: from [192.168.1.6] (adsl-67-127-59-48.dsl.pltn13.pacbell.net [67.127.59.48]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q91GWEQD017248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Oct 2012 09:32:14 -0700 Message-ID: <5069C58D.1090200@dcrocker.net> Date: Mon, 01 Oct 2012 09:32:13 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Glen Zorn References: <50161436.8080900@bbiw.net> <50694C10.4050508@gmail.com> In-Reply-To: <50694C10.4050508@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 01 Oct 2012 09:32:15 -0700 (PDT) Cc: dime mailing list , apps-discuss@ietf.org, draft-ietf-dime-rfc4005bis.all@tools.ietf.org, iesg Subject: Re: [apps-discuss] Review of: draft-ietf-dime-rfc4005bis-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 16:32:20 -0000 Glen, et al, On 10/1/2012 12:53 AM, Glen Zorn wrote: > On 07/30/2012 11:57 AM, Dave Crocker wrote: > >> 1. Introduction > >> > >> This document describes the Diameter protocol application used for > >> AAA in the Network Access Server (NAS) environment. When combined > >> with the Diameter Base protocol [I-D.ietf-dime-rfc3588bis], > >> Transport Profile [RFC3539], and EAP [RFC4072] specifications, > >> this specification satisfies the NAS-related requirements defined > >> in Aboba, et al. [RFC2989] and Beadles & Mitton [RFC3169]. > > > > This assertion raises a dilemma: The cited documents are extensive > > and the topic(s?) complex. There is no way to know what details are > > being referred to, to evaluate the assertion. > > If there were only specific details that were relevant, only specific > sections of the document would be cited. To evaluate the assertion read > the cited documents. All of them. To understand this document, read > and understand the normative references. All of them. Then that is what should be said in the specification. When citing references, it is typical (and I believe essential) to have the citation text be specific about what it being used from the cited document. If what is being used is 'everything', then that's what is said. Explicitly. Language along the lines of "the current specification requires completely familiarity with: cite1, cite2, ... is typical. > My understanding, as expressed above, is that in order for a reader to > expect to understand an RFC, they must first have read and understood > the normative references. Is that incorrect? It depends upon what is being drawn from the references, and it is the job of the referring text to explain its use of the reference. It also is not typical to require the reader to check the references section to find out what is normative and what isn't. That's why we have normative vocabulary. By requiring the reader to flip back and forth to the references section, to find out what is normative and what isn't, the specification is made markedly more cumbersome to use. > > In general, this document's frequent use of "AVP" appears to be an > > oddly syntactic focus. Typical specifications refer to attributes, > > without such frequent, explicit reference to the form of their having > > values. On its own, this point could seem like quibbling, but it's > > part of the reaction I had when reading the document, that is seemed > > less accessible than one would wish for a new reader. > > This document is not intended to function as a primer on Diameter, AAA, > or network access systems. Except that the document does provide /some/ primer material: The Diameter base protocol provides the following facilities: ... all data delivered by the protocol is in the form of an AVP Documents need to define their normative context. There is benefit in making different documents minimize that context. Obviously documents that extend a service must rely on the foundation of that service, but the specification of an extension can be made more or less complicated by the way divide-and-conquor writing is done. > The centrality of AVPs to the operation of the Diameter protocol might > explain the focus of this draft upon them. My point was not that the use of attributes was unusual, but that the terminologic focus on what is essentially a syntactic aspect of the construct is unusual and, in my view, overly detailed. It's a bit like spelling out 'period' at the end of every sentence in a document. Distracting and unnecessary. And again, the term isn't defined in this document, in spite of there being a Terminology section. >> > > > >> by common usage. These are session identification, > >> authentication, authorization, tunneling, and accounting. The > >> authorization AVPs are further broken down by service type. > > > > This document appears to require deep knowledge of The Diameter Base > > Protocol. In reality, I don't think this document can be > > meaningfully read without that knowledge. So this document should > > say that. (The language in the first paragraph of the Intro doesn't > > actually say it.) > > One more time: read the normative references. Understand them. All of > them. Once again: say that. have the text cite them as musts for background and familiarity. > >> 1.6. Accounting Model > >> > >> It is RECOMMENDED that the coupled accounting model (Section 9.3 > >> of [I-D.ietf-dime-rfc3588bis]) be used with this application; > >> therefore, the value of the Acct-Application-Id AVP in the > >> Accounting-Request (Section 3.10) and Accounting-Answer (Section > >> 3.9) messages SHOULD be set to one (1). > > > > All of the values in those two sections (except the "271") are > > symbolic. As such, setting a value to "1" has no obvious meaning. > > > > I assume that the issue would be fixed by using symbolic values > > here? > > Or by reading RFC 3588. Which part? in my review I tried to make clear that I actually had looked in RFC 3588 to resolve questions about the text I was reviewing. Had that succeeded I would have made more specific suggestions for resolving specific issues. So, for the current case, the word 'symbolic' appears in RFC 3588 exactly one time, for icmptypes types, very deep in Section 4.3. I did not find it at all helpful for resolving the point I raised here in the review. Just to check, it appears the response to the review ended with this item. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jasnell@gmail.com Mon Oct 1 09:46:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295EA1F0CCD for ; Mon, 1 Oct 2012 09:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.313 X-Spam-Level: X-Spam-Status: No, score=-3.313 tagged_above=-999 required=5 tests=[AWL=0.285, 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 e5+yvfd+1IUG for ; Mon, 1 Oct 2012 09:46:51 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCF6C1F0D0A for ; Mon, 1 Oct 2012 09:46:49 -0700 (PDT) Received: by weyu46 with SMTP id u46so3349057wey.31 for ; Mon, 01 Oct 2012 09:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=v6sFVH/j8Lst/u+abejeU9vQSt7v9bWz9HQf+TekkQY=; b=yBRgnyu0Wbp58klfjNRevstUHBuj//zFLCOVDPdp2S2Qapm3VAf4/Wk0OUp1Zr3ole kYRP45Z3chhp5HCjg69uPFrMezqn1wLPnQWRd92FYAGqsFOJxggQF8Xb5PK3fY2Wlztw EXlc+DMIBI+PYR5k8FDvuS8/4f0P0p6AYbYP2B3YYAQWMxT66T6Qj09jHTJd2LvtC/6S zgMBqZIH4uyF3Zxm/7N1EybFkbCAZkEZaAOuLIIPkUbRM9IbUqgRZc61IGSRiHE5sXsA 3YX3qrJBdwV+wJIUf15bVl60tKNpm6KaVAg97z7xWmVtCK7wUGra4lnRQCDBoGH9+eFD bE7w== Received: by 10.216.135.148 with SMTP id u20mr7803688wei.137.1349110008336; Mon, 01 Oct 2012 09:46:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Mon, 1 Oct 2012 09:46:27 -0700 (PDT) In-Reply-To: <5DCE97AB-4A43-4578-913A-1B51D14A29BF@mnot.net> References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E114FD642E67@WSMSG3153V.srv.dir.telstra.com> <04178555-0928-4E67-AE3C-4DE63C023D6F@mnot.net> <5DCE97AB-4A43-4578-913A-1B51D14A29BF@mnot.net> From: James M Snell Date: Mon, 1 Oct 2012 09:46:27 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=0016e6dd9920cf530804cb022663 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] json-patch: "op":"tree" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 16:46:53 -0000 --0016e6dd9920cf530804cb022663 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hmm.. I'd rather keep the path named "path" for consistency with the other operations. {"op": "with", "path": "/a/b/c", "do": [...]} This allows me to simply introduce a new operation without special casing. - James On Mon, Oct 1, 2012 at 9:00 AM, Mark Nottingham wrote: > {"op": "with", "base": "/foo/bar/baz", do: [ > =E2=80=A6 > ]} > > On 01/10/2012, at 4:55 PM, James M Snell wrote: > > > Yes, there is definitely a risk of increased complexity here but I thin= k > it's manageable in this case. Yes, a developer could get quite carried aw= ay > with too many layers of nesting but that's more an implementation detail > and we can have some simple language warning people away from that if > necessary. The important thing is that having this does not significantly > impact the basic processing of the patch document, and a patch that > contains these can easily be translated into a flattened set of patch > operations with explicit paths. > > > > I'm not overly concerned with what we call it so long as the name is > descriptive of it's purpose. "tree" is a bit unclear. "with" is ok, I > suppose. > > > > On Mon, Oct 1, 2012 at 8:45 AM, Mark Nottingham wrote: > > Personally -- > > > > I'm concerned about the complexity, but open to it (again, as long as w= e > don't trip on it). > > > > What about "with"? > > > > Cheers, > > > > > > On 01/10/2012, at 4:38 PM, James M Snell wrote: > > > > > Definitely agree that this would be useful. In the JSON-TEST draft > that I'm updating and will be publishing later today, I have a "base" > predicate that essentially does the same thing. Having this in the base > JSON-PATCH spec could be useful but it does introduce a potentially compl= ex > new structure (not necessarily a bad thing, but definitely something to > keep in mind). Rather than calling it "tree", I'd prefer a name such as > "base" ... as you're establishing a base path for the contained operation= s. > > > > > > [ > > > {"op": "base", "path": "/a/b", ops: [ > > > {"op": "add", "path":"/c", "value": "This is added to /a/b/c"}, > > > {"op": "base", "path": "/d/e", ops: [ > > > {"op": "add", "path":"/f", "value": "This is added to > /a/b/d/e/f"} > > > ] > > > ]}, > > > {"op": "add", "path":"/g", "value": "This is added to /g"} > > > ] > > > > > > Definite +1 to this. > > > > > > - James > > > > > > > > > On Sun, Sep 30, 2012 at 10:41 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote: > > > RE: draft-ietf-appsawg-json-patch-05 > > > > > > Suggestion: define a "tree" operation for grouping operations that > apply to part of the JSON doc being changed. It avoids repeating a path > prefix in lots of operations; it simplifies writing a patch that can be > applied at different points; its easier to separate the patch for changin= g > a value from where that value is in a larger JSO structure. New text: > > > > > > 4.7. tree > > > > > > The "tree" operation applies other operations to a subset of > > > the target. The operation object MUST include "path" and "ops" > > > members. "path" holds a JSON pointer that identifies the value > > > to which the other operations apply. "ops" holds an array of > > > operation objects. JSON pointers within "ops" are relative > > > to the value identified by "path". > > > > > > Example: > > > Old: {"a":{"b":{"c":{"d":{"e":{"name":"Alice"}}}}}} > > > Patch: [{"op":"tree", "path":"/a/b/c/d/e", "ops":[ > > > {"op":"add", "path":"/age", "value":20}, > > > {"op":"add", "path":"/email", "value":"a@eg.com"}]}] > > > New: {"a":{"b":{"c":{"d":{"e":{ > > > "name":"Alice", "age":20, "email":"a@eg.com"}}}}}} > > > > > > -- > > > James Manger > > > _______________________________________________ > > > 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/ > > > > > --0016e6dd9920cf530804cb022663 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hmm.. I'd rather keep the path nam= ed "path" for consistency with the other operations.=C2=A0=

{"op": "with", "path&qu= ot;: "/a/b/c", "do": [...]}

This allows me to simply introduce a new operati= on without special casing.

- James
On Mon, Oct 1, 2012 at 9:00 AM, Mark Nottingha= m <= mnot@mnot.net> wrote:
{"op": "with", "bas= e": "/foo/bar/baz", do: [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A6
]}

On 01/10/2012, at 4:55 PM, James M Snell <jasnell@gmail.com> wrote:

> Yes, there is definitely a risk of increased complexity here but I thi= nk it's manageable in this case. Yes, a developer could get quite carri= ed away with too many layers of nesting but that's more an implementati= on detail and we can have some simple language warning people away from tha= t if necessary. The important thing is that having this does not significan= tly impact the basic processing of the patch document, and a patch that con= tains these can easily be translated into a flattened set of patch operatio= ns with explicit paths.
>
> I'm not overly concerned with what we call it so long as the name = is descriptive of it's purpose. "tree" is a bit unclear. &quo= t;with" is ok, I suppose.
>
> On Mon, Oct 1, 2012 at 8:45 AM, Mark Nottingham <mnot@mnot.net> wrote:
> Personally --
>
> I'm concerned about the complexity, but open to it (again, as long= as we don't trip on it).
>
> What about "with"?
>
> Cheers,
>
>
> On 01/10/2012, at 4:38 PM, James M Snell <jasnell@gmail.com> wrote:
>
> > Definitely agree that this would be useful. In the JSON-TEST draf= t that I'm updating and will be publishing later today, I have a "= base" predicate that essentially does the same thing. Having this in t= he base JSON-PATCH spec could be useful but it does introduce a potentially= complex new structure (not necessarily a bad thing, but definitely somethi= ng to keep in mind). Rather than calling it "tree", I'd prefe= r a name such as "base" ... as you're establishing a base pat= h for the contained operations.
> >
> > [
> > =C2=A0 {"op": "base", "path": "= ;/a/b", ops: [
> > =C2=A0 =C2=A0 {"op": "add", "path":= "/c", "value": "This is added to /a/b/c"}, > > =C2=A0 =C2=A0 {"op": "base", "path"= : "/d/e", ops: [
> > =C2=A0 =C2=A0 =C2=A0 {"op": "add", "path= ":"/f", "value": "This is added to /a/b/d/e/f= "}
> > =C2=A0 =C2=A0 ]
> > =C2=A0 ]},
> > =C2=A0 {"op": "add", "path":"/= g", "value": "This is added to /g"}
> > ]
> >
> > Definite +1 to this.
> >
> > - James
> >
> >
> > On Sun, Sep 30, 2012 at 10:41 PM, Manger, James H <James.H.Manger@team.telstra.com= > wrote:
> > RE: draft-ietf-appsawg-json-patch-05
> >
> > Suggestion: define a "tree" operation for grouping oper= ations that apply to part of the JSON doc being changed. It avoids repeatin= g a path prefix in lots of operations; it simplifies writing a patch that c= an be applied at different points; its easier to separate the patch for cha= nging a value from where that value is in a larger JSO structure. New text:=
> >
> > =C2=A0 4.7. tree
> >
> > =C2=A0 =C2=A0 The "tree" operation applies other operat= ions to a subset of
> > =C2=A0 =C2=A0 the target. The operation object MUST include "= ;path" and "ops"
> > =C2=A0 =C2=A0 members. "path" holds a JSON pointer that= identifies the value
> > =C2=A0 =C2=A0 to which the other operations apply. "ops"= ; holds an array of
> > =C2=A0 =C2=A0 operation objects. JSON pointers within "ops&q= uot; are relative
> > =C2=A0 =C2=A0 to the value identified by "path".
> >
> > =C2=A0 =C2=A0 Example:
> > =C2=A0 =C2=A0 Old: =C2=A0 {"a":{"b":{"c&= quot;:{"d":{"e":{"name":"Alice"}}}}= }}
> > =C2=A0 =C2=A0 Patch: [{"op":"tree", "pat= h":"/a/b/c/d/e", "ops":[
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {"op":= "add", "path":"/age", "value":20},<= br> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {"op":= "add", "path":"/email", "value":&qu= ot;a@eg.com"}]}]
> > =C2=A0 =C2=A0 New: =C2=A0 {"a":{"b":{"c&= quot;:{"d":{"e":{
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name":"= Alice", "age":20, "email":"a@eg.com"}}}}}}
> >
> > --
> > James Manger
> > _______________________________________________
> > 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/=





--0016e6dd9920cf530804cb022663-- From sm@resistor.net Mon Oct 1 12:20:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C06521F8816; Mon, 1 Oct 2012 12:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 FEjUL3uhAn4k; Mon, 1 Oct 2012 12:20:07 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E0521F8814; Mon, 1 Oct 2012 12:20:07 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q91JJrdU025738; Mon, 1 Oct 2012 12:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1349119199; bh=smM120F0XSIlgz9eRVNEGCWDHF4eyESYwzDDHF5QQ4A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Mb653YkMuHIqXcuO3W8riotUNUhscZ53ST6cnPd+0oh/ZXvH/tjOg1u5I4gPX69x1 kKN1sSiCt3hNMy67tm6QT2WYbsA4yNKvE1IIPdu5n92oEk/BbwqVjeOQ6u8owPI47r tPtYoNu1voeo5PlPDKOyqpRkomkJVZ9Wz86+JRe8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1349119199; i=@resistor.net; bh=smM120F0XSIlgz9eRVNEGCWDHF4eyESYwzDDHF5QQ4A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2BrNeAi9YoLBcFWrT1ltCnmj4s0+++q7AAlP5MiaAaY66wsZPDzld1Te0YAtCc+Hn g55/20v6Bs88ZhBuGBXPw6WDrWzydcY4hbwDsg1azMVf11JnxaWIitBprnTzd1Dt5I NcdTEVr4kCpZFUycel1RiL0TV1flarBzg/U446i4= Message-Id: <6.2.5.6.2.20121001114245.0a490458@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 01 Oct 2012 12:03:37 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: <50694C10.4050508@gmail.com> References: <50161436.8080900@bbiw.net> <50694C10.4050508@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Glen Zorn , dime mailing list , Dave Crocker , draft-ietf-dime-rfc4005bis.all@tools.ietf.org Subject: Re: [apps-discuss] Review of: draft-ietf-dime-rfc4005bis-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, 01 Oct 2012 19:20:08 -0000 Hello, [I removed iesg@ from the Cc] At 00:53 01-10-2012, Glen Zorn wrote: > >> 4.2.9. Reply-Message AVP > >> > >> The Reply-Message AVP (AVP Code 18) is of type UTF8String and > >> contains text that MAY be displayed to the user. When used in an > >> AA- > > > > Since I doubt that this specification is intended to cover user > > interface design -- and hope that it is not -- I think that the > > normative, semantic point in specification terms is that the strings > > MUST be created with the intent of displaying them to humans. That > > is, these are human-consumable strings, not (necessarily) > > computer-consumable. The Gen-ART review ( http://www.ietf.org/mail-archive/web/ietf/current/msg75004.html ) mentioned that "every use of UTF8String in this draft needs to be checked, and most of them are likely to need some attention". In case it is useful to anyone "UTF8String" is mentioned in draft-ietf-dime-rfc3588bis-33. Regards, -sm From jasnell@gmail.com Mon Oct 1 15:55:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51841F0CF9 for ; Mon, 1 Oct 2012 15:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.324 X-Spam-Level: X-Spam-Status: No, score=-3.324 tagged_above=-999 required=5 tests=[AWL=0.274, 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 faEEPuCxLy6j for ; Mon, 1 Oct 2012 15:55:03 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2191F0CC4 for ; Mon, 1 Oct 2012 15:55:02 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2991384wgb.13 for ; Mon, 01 Oct 2012 15:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=cc/RSMNw/Qr0b7nDBI/MBuPkCuAaZKR0D7DbpBnJRCc=; b=0kAP5znkXt+RPEMtj337lmNyIWn+/DHL0gy+eoVHUlJHcFt4sLp8P89HlQiAYZhrcm uTmI6bYZW3KuQEgrd3Sg8OJ07ywzxL07Z7vyQv6JocsIBOtJ/NXbxYBF4mhrJ3oVIf2y NcmbvD9c9soiYu2WbCUzj26deFZHkpJFxv+QWwa+IECAZaveIonEuQYvQYfTmQzJzO7D MuWdFHYhgjvCYnFVj88t3ysRVeyey+AjV60gpEYCsaETccc/2HZklBr+SBsnDv1/vgjZ lLMq97TggX/HtwVIJwZDW4RoH4ZS4kHcHweycvV3KIopThz87b+uK8C63CvujAiowrKv XNpQ== Received: by 10.180.95.130 with SMTP id dk2mr4676602wib.18.1349132101712; Mon, 01 Oct 2012 15:55:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Mon, 1 Oct 2012 15:54:40 -0700 (PDT) From: James M Snell Date: Mon, 1 Oct 2012 15:54:40 -0700 Message-ID: To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d0444ef93ad7b7104cb074b77 Subject: [apps-discuss] JSON Predicates Draft (for JSON 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: Mon, 01 Oct 2012 22:55:04 -0000 --f46d0444ef93ad7b7104cb074b77 Content-Type: text/plain; charset=UTF-8 Now that the updated JSON Patch draft has been published [2] ... here is the first draft of the JSON Predicates doc [1] [1] http://www.ietf.org/id/draft-snell-json-test-00.txt [2] http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-05 Example JSON-Patch with Predicates: # Adds a value only if path "/a/b/c" # is undefined or consists of three # numeric digits ... [ { "op": "or", "path": "/a/b", "apply": [ { "op": "undefined", "path": "/c" }, { "op": "matches", "path": "/c", "value": "^\\d{3}$" } ] }, { "op": "add", "path": "/a/b/d", "value": 123 } ] As always, comments are more than welcome. - James --f46d0444ef93ad7b7104cb074b77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Now that the updated JSON Patch draft = has been published [2] ... here is the first draft of the JSON Predicates d= oc [1]

[1]=C2=A0http://www.ietf.org/id/draft-snell-json-test-00.txt
[2]=C2=A0http://tools.ietf.org/html/d= raft-ietf-appsawg-json-patch-05

Example JSON-Patch with Predicates:

=C2=A0 # Adds a value only if path "/a/b/= c"=C2=A0
=C2=A0 # is undefined or consist= s of three
=C2=A0 # = numeric digits ...
<= br>
=C2=A0 [
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "op": "or&q= uot;,
=C2=A0 =C2=A0 = =C2=A0 "path": "/a/b",
=C2=A0 =C2=A0 =C2=A0 "apply= ": [
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "op": "undefined",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 "path": "/c"
=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": "matches",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "path": &= quot;/c",
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "value": "^\\d{3}$"
=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&qu= ot;: "add",
=C2=A0 =C2=A0 =C2=A0 "value&q= uot;: 123
=C2=A0 =C2=A0 }
=C2=A0 ]

=
As always, comments are more tha= n welcome.=C2=A0

- James
--f46d0444ef93ad7b7104cb074b77-- From jasnell@gmail.com Tue Oct 2 09:36:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F17B21F851C for ; Tue, 2 Oct 2012 09:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_05=-1.11, 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 tdaE23x7wvYh for ; Tue, 2 Oct 2012 09:36:38 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6FB721F851B for ; Tue, 2 Oct 2012 09:36:35 -0700 (PDT) Received: by weyu46 with SMTP id u46so4089145wey.31 for ; Tue, 02 Oct 2012 09:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=VcqtfvN4N5e1bK2lthEHgwczPtsoDcGasxr+TTgZwYo=; b=sCxqcPcwhQ5jRcqyEG20JarNkEol6iPfPC/mkwFVaySDVkdSJstR+x/ZBhr4FO1efd 8WKSZhXiehp5PPFQs2w7x2WPm+XdpNFVeCUz8Ws9bD+zdL7ZX00tMeS5lRmSAGkSoBqi SttZw4nbbeS2N+yQqXYuqeprgIYheGlNK3fCJWgRYPE8lUkvt8z8Vm7LOCWcwQJT+a8C IVxuCVuXgqCNIldK9p/0JMXvJRXQCQrPz46BmRE9F5M7pkb+thcrucfwfNkkwsCQK+dn /TMDU7eZHnnVKlL/pq3Ko2OaC4vX+tIOIeHLd3kZ+oJVGUf1JU7r2qdMcK/DeXrzklu/ kW2w== Received: by 10.216.243.74 with SMTP id j52mr9415722wer.108.1349195794973; Tue, 02 Oct 2012 09:36:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Tue, 2 Oct 2012 09:36:13 -0700 (PDT) From: James M Snell Date: Tue, 2 Oct 2012 09:36:13 -0700 Message-ID: To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=e0cb4e43cf1f17847804cb1620e8 Subject: [apps-discuss] JSON Patch feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2012 16:36:39 -0000 --e0cb4e43cf1f17847804cb1620e8 Content-Type: text/plain; charset=UTF-8 Going through the current json-patch draft, I notice that it's particularly light on examples and details for working with arrays. A few additional array-specific examples in the text would be helpful... as well as a reminder that array indexing with JSON Pointer is 0-based. (yes I know there are a couple examples in the appendix but they're not quite enough) In Section 4.1.. some of the language used is not quite clear... For example: If the target location references the root of the target document or a member of an existing object, the specified location MUST already exist for the operation to be successful. This would seem to imply that if I do... {"op": "add", "path": "/a/b/c", "value": 1} That the path "/a/b/c" MUST already exist for the add to work, which is contrary to the definition of "add". I suggest rewording section 4.1 to something like the following (yes this is more verbose, but it's a lot clearer and easier to understand than the existing text) [START] The "add" operation adds a new value to a target location. The operation object's "path" member identifies the position within an existing object or array to add the new value. The object MUST contain a "value" member that specifies the value to be added. For example, given the JSON document: { "a": { "b": {} } } A path of "/a/b/c" indicates that a new member "c" is being added to the object identified by "/a/b". {"op": "add", "path": "/a/b/c", "value": 1} Yields: { "a": { "b": { "c": 1 } } } The add operation MUST fail if the object to which the member is being added does not exist. Likewise, the add operation MUST fail if the target object already contains a member with the same name. Using the same example document given above: {"op": "add", "path": "/a/b", "value": "foo"} Would result in an error since "/a/b" refers to an existing member of object "/a". If the value is being added to an array, the path will indicate the specific position within the array to insert the item. For instance, given the JSON document: { "a": { "b": [1,2,3] } } A path of "/a/b/1" would indicate that the new value is to be inserted as the second item, causing any existing items at or above the specified position to be shifted one position to the right. {"op": "add", "path": "/a/b/1", "value": 0} Yields: { "a": { "b": [1,0,2,3] } } The add operation MUST fail if the array to which the member is being added does not exist. Note, however, that if the object referenced by the path "/a/b" points to an Object rather than an Array a new member named "1" will be added to that object. Specifying 0 (zero) as the index causes the value to be inserted at the beginning of the array. Specifying an index equal to the current size of the array causes the item to be appended as the last item in the array. The specified index MUST be a non-negative integer and MUST NOT be greater than the number of items in the array {"op": "add", "path": "/a/b/4", "value": 4} Yields: { "a": { "b": [1,0,2,3,4] } } While: {"op": "add", "path": "/a/b/10", "value": 'x'} {"op": "add", "path": "/a/b/-1", "value": 'y'} {"op": "add", "path": "/a/b/c", "value": 'z'} Would each result in an error. [END] Lastly, it would be helpful to provide a few more Array examples in the appendix... for instance: Arrays nested within arrays. Given... { "a": [ [1,2,3], ["A","B","C"] ] } If I wished to swap the second elements of the two arrays, I would do... [ {"op": "move", "path": "/a/0/1", "to": "/a/1/1"}, {"op": "move", "path": "/a/1/2", "to": "/a/1/1"} ] Which yields... { "a": [ [1,"B",3], ["A",2,"C"] ] } - James --e0cb4e43cf1f17847804cb1620e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Going through the current json-patch d= raft, I notice that it's particularly light on examples and details for= working with arrays. A few additional array-specific examples in the text = would be helpful... as well as a reminder that array indexing with JSON Poi= nter is 0-based. (yes I know there are a couple examples in the appendix bu= t they're not quite enough)

In Section 4.1.. some = of the language used is not quite clear... For example:

=C2=A0 =C2=A0If the target location references the root of the target docum= ent or
=C2=A0 =C2=A0a member of an existing object, the specified= location MUST already
=C2=A0 =C2=A0exist for the operation to be= successful.

This would seem to imply that if I do...

=C2=A0 {"op": "add", "path": "/a/b/c&q= uot;, "value": 1}

That the path "/a= /b/c" MUST already exist for the add to work, which is contrary to the= definition of "add". I suggest rewording section 4.1 to somethin= g like the following (yes this is more verbose, but it's a lot clearer = and easier to understand than the existing text)

[START]
=C2=A0 =C2=A0The "add"= operation adds a new value to a target location. =C2=A0The=C2=A0
=C2=A0 =C2=A0operation object's "path" member identifies the= position within an
=C2=A0 =C2=A0existing object or array to add the new value. The=C2=A0object= MUST contain=C2=A0
=C2=A0 =C2=A0a "value" member that = specifies the=C2=A0value to be added.

=C2=A0= =C2=A0For example, given the JSON document:

=C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 = =C2=A0"a": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"b&= quot;: {}
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 = =C2=A0}

=C2=A0 =C2=A0A path of "/a/b/c" = indicates=C2=A0that a new member "c" is being added to=C2=A0
=C2=A0 =C2=A0the object identified by "/a/b".

=
=C2=A0 =C2=A0 =C2=A0{"op": "add", "path= ": "/a/b/c", "value": 1}

= =C2=A0 =C2=A0Yields:

=C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0"a": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"b": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"c": 1
=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=A0The add operation MUST fail= if the object to which the member is being added
=C2=A0 =C2=A0doe= s not exist. Likewise, the add operation MUST fail if the target object
=C2=A0 =C2=A0a= lready contains a member with the same name. Using the same example documen= t
=C2=A0 =C2=A0giv= en above:
<= br>
=C2=A0 = =C2=A0 =C2=A0{"op": "add", "path": "/a/b= ", "value": "foo"}

=C2=A0 =C2=A0Would res= ult in an error since "/a/b" refers to an existing member of obje= ct "/a".

=C2=A0 =C2=A0If t= he value is being added to an array, the path will indicate the specific
=C2=A0 =C2=A0position within the array to insert the item. For inst= ance, given the JSON=C2=A0
=C2=A0 =C2=A0document:

=C2=A0 =C2=A0 =C2=A0{<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0"a": {
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0"b": [1,2,3]
=C2=A0 =C2=A0 =C2= =A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0}

=C2=A0= =C2=A0A path of "/a/b/1"=C2=A0would indicate that the new=C2=A0v= alue is to be inserted as the=C2=A0
=C2=A0 =C2=A0second item, causing=C2=A0a= ny existing items at or above=C2=A0the= specified position to be=C2=A0
=C2=A0 =C2=A0shifted one position to the right.=C2=A0

=C2=A0 =C2=A0 =C2=A0{"op": "add", "pat= h": "/a/b/1", "value": 0}

=C2=A0 =C2=A0Yields:=

=C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0"a": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"b&= quot;: [1,0,2,3]
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0The add operati= on MUST fail if the array to which the member is being added=C2=A0
=C2=A0 =C2=A0does not exist. Note, however, that if the object referenced= by the path=C2=A0
=C2=A0 =C2=A0"/a/b" points to an Obj= ect rather than an Array a new member named=C2=A0
=C2=A0 =C2=A0"1" will be added to that object.

=C2=A0 =C2=A0Specifying 0 (zero)=C2=A0as the index causes the value to be inserted at the beginning=C2=A0
=C2=A0 =C2=A0of the array. Specifying an= index equal to the current size of the array causes=C2=A0
=C2=A0 =C2=A0the item to be appended as the = last item in the array. The specified index MUST be a
=C2=A0 =C2=A0non-negative integer and MU= ST NOT=C2=A0be greater than the number= of items in the array

<= /span>
=C2=A0 =C2=A0 =C2=A0{"op": "ad= d", "path": "/a/b/4", "value": 4}=

=C2=A0 =C2=A0Yields:

=C2=A0 =C2=A0= =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0"a": {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"b": [1,0,2,3,4]
=C2= =A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0= =C2=A0 =C2=A0}=C2=A0=C2=A0
=C2=A0 =C2=A0While:

=C2=A0 =C2=A0 =C2=A0{"op": "add", &q= uot;path": "/a/b/10", "value": 'x'}=
=C2=A0 =C2=A0 =C2=A0{"o= p": "add", "path": "/a/b/-1", "valu= e": 'y'}
=C2=A0 =C2=A0 =C2=A0{"op": "add", "path= ": "/a/b/c", =C2=A0"value": 'z'}
=C2=A0 =C2=A0Would each result in an error.

[END]


Lastly, it would be = helpful to provide a few more Array examples in the appendix... for instanc= e:

Arrays nested within arrays. Given...
=C2= =A0 {
=C2=A0 =C2=A0 "a": [
=C2=A0 =C2=A0 =C2=A0 [= 1,2,3],
=C2= =A0 =C2=A0 =C2=A0 ["A","B","C"]
<= div style=3D"font-family:arial">=C2= =A0 =C2=A0 ]
=C2=A0 }

If I wi= shed to swap the second elements of the two arrays, I would do...

=
=C2=A0 [
=C2=A0 =C2=A0 {"op": "move"= , "path": "/a/0/1", "to": "/a/1/1"}= ,
=C2= =A0 =C2=A0 {"op": "move", "path": "/a/1/= 2", "to": "/a/1/1"}
=C2=A0 ]

Which yields...

=C2=A0 {
=C2=A0 =C2=A0 "a": [
=C2=A0 =C2=A0 =C2=A0 [1,"B",3],
=C2=A0 =C2=A0 =C2=A0 ["A&qu= ot;,2,"C"]
=C2=A0 =C2=A0 ]
=C2= =A0 }

- James
--e0cb4e43cf1f17847804cb1620e8-- From presnick@qti.qualcomm.com Tue Oct 2 09:50:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F3D21F853B for ; Tue, 2 Oct 2012 09:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Pp8hRBHgiKiz for ; Tue, 2 Oct 2012 09:50:56 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEDC21F8539 for ; Tue, 2 Oct 2012 09:50:56 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6853"; a="242420951" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 02 Oct 2012 09:50:55 -0700 X-IronPort-AV: E=Sophos;i="4.80,524,1344236400"; d="scan'208";a="312250075" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Oct 2012 09:50:55 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 2 Oct 2012 09:50:54 -0700 Message-ID: <506B1B6E.9010503@qti.qualcomm.com> Date: Tue, 2 Oct 2012 09:50:54 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Apps Discuss References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:50:57 -0000 Folks, I'm having trouble discerning consensus from this conversation, so I want to simplify a bit. Currently, IANA is requiring Expert Review for *all* registrations, including things published as RFCs. That's not what 3864 *says* to do: It is quite clear (whatever the intent) that RFCs (whatever stream) don't go for Expert Review: The registration template is submitted for incorporation in one of the IANA message header field repositories by *one of the following methods*: And the two methods specified are "RFC" and "Expert Review". So, here are the choices: (And I do *not* want anybody to simply choose one; see below.) a) IANA should continue requiring Expert Review for all registrations. b) IANA should require Expert Review for registrations that don't come as part of an RFC. c) IANA should require Expert Review for registrations that don't come as part of an IETF stream RFC. For each of the above, I'd like to hear from folks answers of the form: - Yeah, this is OK with me. - No, this would be actively bad and can not be what we tell IANA is the current policy. Of course, if you say "actively bad", I'd also like to hear the reason. Potential reasons are "that's not what 3864 says and not following the rules is bad" or "that will let bad things be registered" or "that will slow down important things from being registered in a timely fashion". The "actively bad" answers are the ones I am most interested in. And please keep in mind that we are telling IANA what the policy will be until we write a new document that is clearer about our intent. This is a stop-gap until then. Thanks. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From john-ietf@jck.com Tue Oct 2 10:28:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFA821F8532 for ; Tue, 2 Oct 2012 10:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 8GkoNQ0GlAwD for ; Tue, 2 Oct 2012 10:28:19 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id D253B21F8527 for ; Tue, 2 Oct 2012 10:28:19 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TJ6GY-0009jJ-NQ; Tue, 02 Oct 2012 13:28:18 -0400 Date: Tue, 02 Oct 2012 13:28:12 -0400 From: John C Klensin To: Pete Resnick Message-ID: <5539D2E291D44427BDF0A7E6@JcK-HP8200.jck.com> In-Reply-To: <506B1B6E.9010503@qti.qualcomm.com> References: <506B1B6E.9010503@qti.qualcomm.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 17:28:20 -0000 --On Tuesday, October 02, 2012 09:50 -0700 Pete Resnick wrote: > Folks, I'm having trouble discerning consensus from this > conversation, so I want to simplify a bit. Currently, IANA is > requiring Expert Review for *all* registrations, including > things published as RFCs. That's not what 3864 *says* to do: > It is quite clear (whatever the intent) that RFCs (whatever > stream) don't go for Expert Review: >... > So, here are the choices: (And I do *not* want anybody to > simply choose one; see below.) See comment at end, especially since you use language like "all registrations". > a) IANA should continue requiring Expert Review for all > registrations. - Yeah, this is OK with me and is, I believe, the most desirable solution, especially if the Expert is smart enough to consider whatever level of consensus an RFC might have to as part of the evaluation (and certainly part of a community review process and evidence that the proposal has been reviewed). I'd also expect Experts to pay exceptionally timely attention to things coming to them as RFC in last-stage consideration (again, see comment at end). > b) IANA should require Expert Review for registrations that > don't come as part of an RFC. - Actively bad unless agreements are made with other streams, especially the Independent one, about considering the Expert among the document reviewers. We really need to be sure someone with expertise in the subject matter looks at these things. > c) IANA should require Expert Review for registrations that > don't come as part of an IETF stream RFC. -- Less bad. As long as the IESG continues to insist on an IETF Last Call for all IETF Stream documents (RFC 2026 does not require it for Individual Submission Informational or Experimental documents), it is plausible to assume that someone will call the registration to the Expert's attention, causing this option to be not much different in practice than (a). On the other hand, I don't need to tell you how variable the quality of review and documents reaching the IESG actually is, so there is some risk. >... > And please keep in mind that we are telling IANA what the > policy will be until we write a new document that is clearer > about our intent. This is a stop-gap until then. Pete, most of this discussion has focused on "what 3864 says" and on when we are going to get a 3864bis and what is in it. I think that is incorrect. I think the real issue here is in RFC 5226 and its failure to either explicitly discuss the relationship between the "Expert Review" category and requests that satisfy one or more of the "RFC Required", "IETF Review", "Standards Action", and "IESG Approval" ones or to spell out how combinations can and should be specified. For example, if something is identified as "IESG Approval" and the document that modifies the registry is approved on the standards track, is IANA required to demand that the IESG pass a separate resolution approving the change? To me, that would be a new low in the "process over good sense" battle, but some of the comments on this thread would predict exactly that. So, IMO, we need to fix 5226 sooner or later. I'll happily leave it up to the IESG whether that fix must also explicitly update all relevant registration documents including 3864. john From hallam@gmail.com Tue Oct 2 10:40:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2631321F846A for ; Tue, 2 Oct 2012 10:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.141 X-Spam-Level: X-Spam-Status: No, score=-3.141 tagged_above=-999 required=5 tests=[AWL=-1.209, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0hEwozuINfU for ; Tue, 2 Oct 2012 10:40:35 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E64D321F8525 for ; Tue, 2 Oct 2012 10:40:34 -0700 (PDT) Received: by obqv19 with SMTP id v19so7702685obq.31 for ; Tue, 02 Oct 2012 10:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5Z1XAsAMZrSHLMNgxJl5jREhKYpmDMuS3rWBIkEI0zg=; b=I6AXGxP9JBTN0FJRfT3IRQOtFmfUdex/cxyt1x7Iu8rUSGl04MZ8ia/nVbjutgaGjh tCacB+Jo+w9wrQ1pzjbKVblEWVgwXptjD/uruu1VN2SjqYy9xcZf2xsWczfR9fzW5LjR Vs4etmmlw4Ye2VZfQ0jG/LzaKLmXzgbnBWZVuCU6xAzaFt+zoP/z8lXUJr9nKAZL17s0 RwfNGNVfK7mOwfRL2rOIPD/0QeqSZYnwgQ5V1soh41d0rMXATDw3Q3D5pNa9QpRYrpY8 ce5PLb8mF5pTmfnaJtd5edELNmfEdNpu8KoUnjsQcJ5FQptIjdEkfafi5h6qy4jSJPNV ShkQ== MIME-Version: 1.0 Received: by 10.182.207.6 with SMTP id ls6mr14992842obc.36.1349199634567; Tue, 02 Oct 2012 10:40:34 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Tue, 2 Oct 2012 10:40:34 -0700 (PDT) In-Reply-To: <506B1B6E.9010503@qti.qualcomm.com> References: <506B1B6E.9010503@qti.qualcomm.com> Date: Tue, 2 Oct 2012 13:40:34 -0400 Message-ID: From: Phillip Hallam-Baker To: Pete Resnick Content-Type: multipart/alternative; boundary=e89a8f646e2bf30fe104cb1704da Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 17:40:36 -0000 --e89a8f646e2bf30fe104cb1704da Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 2, 2012 at 12:50 PM, Pete Resnick wrote: > Folks, I'm having trouble discerning consensus from this conversation, so > I want to simplify a bit. Currently, IANA is requiring Expert Review for > *all* registrations, including things published as RFCs. That's not what > 3864 *says* to do: It is quite clear (whatever the intent) that RFCs > (whatever stream) don't go for Expert Review: > > > The registration template is submitted for incorporation in one of > the IANA message header field repositories by *one of the following > methods*: > > > And the two methods specified are "RFC" and "Expert Review". > > So, here are the choices: (And I do *not* want anybody to simply choose > one; see below.) > > a) IANA should continue requiring Expert Review for all registrations > OK with that > b) IANA should require Expert Review for registrations that don't come as > part of an RFC. > No, I think that would be bad. I see the role of expert review as being strictly limited to avoiding unnecessary duplication and avoiding unintentional collisions. For the expert to achieve those functions they really need to be tracking all the documents proposing headers regardless of source. So expert review for this case is no additional effort. I see expert review as beneficial in this case for the same reason that we have Gen Art review, SECDIR review etc. The fact that a proposal comes from inside the IETF does not mean that the authors understand the HTTP issues involved or describe them effectively. I care rather more about IETF documents and other RFCs being reviewed than non-RFCs. In particular I care about things like the consistency of the description of the headers. > c) IANA should require Expert Review for registrations that don't come as > part of an IETF stream RFC. > No, for same reason as above. > For each of the above, I'd like to hear from folks answers of the form: > > - Yeah, this is OK with me. > - No, this would be actively bad and can not be what we tell IANA is the > current policy. > > Of course, if you say "actively bad", I'd also like to hear the reason. > Potential reasons are "that's not what 3864 says and not following the > rules is bad" or "that will let bad things be registered" or "that will > slow down important things from being registered in a timely fashion". > > The "actively bad" answers are the ones I am most interested in. > > And please keep in mind that we are telling IANA what the policy will be > until we write a new document that is clearer about our intent. This is a > stop-gap until then. > > Thanks. > > pr > > -- > Pete Resnick > > > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > -- Website: http://hallambaker.com/ --e89a8f646e2bf30fe104cb1704da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 2, 2012 at 12:50 PM, Pete Re= snick <presnick@qti.qualcomm.com> wrote:
Folks, I'm having trouble discerning consensus from this conversation, = so I want to simplify a bit. Currently, IANA is requiring Expert Review for= *all* registrations, including things published as RFCs. That's not wh= at 3864 *says* to do: It is quite clear (whatever the intent) that RFCs (wh= atever stream) don't go for Expert Review:


=A0 =A0The registration template is submitted for incorporation in one of
=A0 =A0the IANA message header field repositories by *one of the following<= br> =A0 =A0methods*:


And the two methods specified are "RFC" and "Expert Review&q= uot;.

So, here are the choices: (And I do *not* want anybody to simply choose one= ; see below.)

a) IANA should continue requiring Expert Review for all registrations

OK with that

=A0
b) IANA should require Expert Review for registrations that don't come = as part of an RFC.

No, I think that wou= ld be bad. I see the role of expert review as being strictly limited to avo= iding unnecessary duplication and avoiding unintentional collisions. For th= e expert to achieve those functions they really need to be tracking all the= documents proposing headers regardless of source. So expert review for thi= s case is no additional effort.

I see expert review as beneficial in this case for the = same reason that we have Gen Art review, SECDIR review etc. The fact that a= proposal comes from inside the IETF does not mean that the authors underst= and the HTTP issues involved or describe them effectively. I care rather mo= re about IETF documents and other RFCs being reviewed than non-RFCs.

In particular I care about things like the consistency = of the description of the headers.
=A0
c) IANA should require Expert Review for registrations that don't come = as part of an IETF stream RFC.

No, for = same reason as above.

=A0
For each of the above, I'd like to hear from folks answers of the form:=

- Yeah, this is OK with me.
- No, this would be actively bad and can not be what we tell IANA is the cu= rrent policy.

Of course, if you say "actively bad", I'd also like to hear t= he reason. Potential reasons are "that's not what 3864 says and no= t following the rules is bad" or "that will let bad things be reg= istered" or "that will slow down important things from being regi= stered in a timely fashion".

The "actively bad" answers are the ones I am most interested in.<= br>
And please keep in mind that we are telling IANA what the policy will be un= til we write a new document that is clearer about our intent. This is a sto= p-gap until then.

Thanks.

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478


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



--
= Website: http://halla= mbaker.com/

--e89a8f646e2bf30fe104cb1704da-- From hallam@gmail.com Tue Oct 2 10:43:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0DE21F844D for ; Tue, 2 Oct 2012 10:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.127 X-Spam-Level: X-Spam-Status: No, score=-3.127 tagged_above=-999 required=5 tests=[AWL=-1.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9qsRszseRyU for ; Tue, 2 Oct 2012 10:43:36 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2B2821F843E for ; Tue, 2 Oct 2012 10:43:36 -0700 (PDT) Received: by obqv19 with SMTP id v19so7706024obq.31 for ; Tue, 02 Oct 2012 10:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BoiC48JdMqzl1q8boS703E84YqwWgJ6ISuleoY3mn9M=; b=qb85IUGi1Id+S6K54UAXki2lmQmZFu+7/EzgEC8d/O/rpntOZN8jwarFvnYN5tFeTA UGwurRfSKezo5QevCMwbZWoywH2murh0abaVpwiwXyycU2xKr5FpXgYZC/J9xnJq0/6s HXNvHo6T1ZBPqpOfQfVxPGFAC0bAogSZT7z1oEeSUYqz/BrSAvq85e0GjDR9rDUf0fPM /1V388LO5XZnLO8riKTRbiIh3uj4GeBuQ2XeOf1NIqF0VXtYLIsVZ08tCQYFVelh3PvQ FTEtALkMB2ONKqGBvJhV1zcM9OZOfWAE8QRrgpKPykEjVHwNF2zFcR/goejDUPY39u7j MQpg== MIME-Version: 1.0 Received: by 10.182.5.168 with SMTP id t8mr7108208obt.32.1349199816121; Tue, 02 Oct 2012 10:43:36 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Tue, 2 Oct 2012 10:43:36 -0700 (PDT) In-Reply-To: References: <506B1B6E.9010503@qti.qualcomm.com> Date: Tue, 2 Oct 2012 13:43:36 -0400 Message-ID: From: Phillip Hallam-Baker To: Pete Resnick Content-Type: multipart/alternative; boundary=f46d044795a5c55e0304cb170fcc Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 17:43:38 -0000 --f46d044795a5c55e0304cb170fcc Content-Type: text/plain; charset=ISO-8859-1 Looking at John's response it is clear he interpreted the options differently. I was interpreting b and c as 'only require'. On Tue, Oct 2, 2012 at 1:40 PM, Phillip Hallam-Baker wrote: > > > On Tue, Oct 2, 2012 at 12:50 PM, Pete Resnick wrote: > >> Folks, I'm having trouble discerning consensus from this conversation, so >> I want to simplify a bit. Currently, IANA is requiring Expert Review for >> *all* registrations, including things published as RFCs. That's not what >> 3864 *says* to do: It is quite clear (whatever the intent) that RFCs >> (whatever stream) don't go for Expert Review: >> >> >> The registration template is submitted for incorporation in one of >> the IANA message header field repositories by *one of the following >> methods*: >> >> >> And the two methods specified are "RFC" and "Expert Review". >> >> So, here are the choices: (And I do *not* want anybody to simply choose >> one; see below.) >> >> a) IANA should continue requiring Expert Review for all registrations >> > > OK with that > > > >> b) IANA should require Expert Review for registrations that don't come as >> part of an RFC. >> > > No, I think that would be bad. I see the role of expert review as being > strictly limited to avoiding unnecessary duplication and avoiding > unintentional collisions. For the expert to achieve those functions they > really need to be tracking all the documents proposing headers regardless > of source. So expert review for this case is no additional effort. > > I see expert review as beneficial in this case for the same reason that we > have Gen Art review, SECDIR review etc. The fact that a proposal comes from > inside the IETF does not mean that the authors understand the HTTP issues > involved or describe them effectively. I care rather more about IETF > documents and other RFCs being reviewed than non-RFCs. > > In particular I care about things like the consistency of the description > of the headers. > > >> c) IANA should require Expert Review for registrations that don't come as >> part of an IETF stream RFC. >> > > No, for same reason as above. > > > >> For each of the above, I'd like to hear from folks answers of the form: >> >> - Yeah, this is OK with me. >> - No, this would be actively bad and can not be what we tell IANA is the >> current policy. >> >> Of course, if you say "actively bad", I'd also like to hear the reason. >> Potential reasons are "that's not what 3864 says and not following the >> rules is bad" or "that will let bad things be registered" or "that will >> slow down important things from being registered in a timely fashion". >> >> The "actively bad" answers are the ones I am most interested in. >> >> And please keep in mind that we are telling IANA what the policy will be >> until we write a new document that is clearer about our intent. This is a >> stop-gap until then. >> >> Thanks. >> >> pr >> >> -- >> Pete Resnick >> > >> Qualcomm Technologies, Inc. - +1 (858)651-4478 >> >> >> ______________________________**_________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/**listinfo/apps-discuss >> > > > > -- > Website: http://hallambaker.com/ > > -- Website: http://hallambaker.com/ --f46d044795a5c55e0304cb170fcc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Looking at John's response it is clear he interpreted the options diffe= rently. I was interpreting b and c as 'only require'.

On Tue, Oct 2, 2012 at 1:40 PM, Phillip Hallam-Baker <= span dir=3D"ltr"><= hallam@gmail.com> wrote:


On Tue, Oct 2, 2012 at 12:50 PM, Pete Resnick &l= t;presnick@q= ti.qualcomm.com> wrote:
Folks, I'm having trouble discerning consensus from this conversation, = so I want to simplify a bit. Currently, IANA is requiring Expert Review for= *all* registrations, including things published as RFCs. That's not wh= at 3864 *says* to do: It is quite clear (whatever the intent) that RFCs (wh= atever stream) don't go for Expert Review:


=A0 =A0The registration template is submitted for incorporation in one of
=A0 =A0the IANA message header field repositories by *one of the following<= br> =A0 =A0methods*:


And the two methods specified are "RFC" and "Expert Review&q= uot;.

So, here are the choices: (And I do *not* want anybody to simply choose one= ; see below.)

a) IANA should continue requiring Expert Review for all registrations

OK with that

=A0
b) IANA should require Expert Review for registrations that don't come = as part of an RFC.

No, I think th= at would be bad. I see the role of expert review as being strictly limited = to avoiding unnecessary duplication and avoiding unintentional collisions. = For the expert to achieve those functions they really need to be tracking a= ll the documents proposing headers regardless of source. So expert review f= or this case is no additional effort.

I see expert review as beneficial in this case for the = same reason that we have Gen Art review, SECDIR review etc. The fact that a= proposal comes from inside the IETF does not mean that the authors underst= and the HTTP issues involved or describe them effectively. I care rather mo= re about IETF documents and other RFCs being reviewed than non-RFCs.

In particular I care about things like the consistency = of the description of the headers.
=A0
c) IANA should require Expert Review for registrations that don't come = as part of an IETF stream RFC.

No= , for same reason as above.

=A0<= /div>
For each of the above, I'd like to hear from folks answers of the form:=

- Yeah, this is OK with me.
- No, this would be actively bad and can not be what we tell IANA is the cu= rrent policy.

Of course, if you say "actively bad", I'd also like to hear t= he reason. Potential reasons are "that's not what 3864 says and no= t following the rules is bad" or "that will let bad things be reg= istered" or "that will slow down important things from being regi= stered in a timely fashion".

The "actively bad" answers are the ones I am most interested in.<= br>
And please keep in mind that we are telling IANA what the policy will be un= til we write a new document that is clearer about our intent. This is a sto= p-gap until then.

Thanks.

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478


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



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



-- Website: http://hallambaker.com/<= br>
--f46d044795a5c55e0304cb170fcc-- From ietfc@btconnect.com Tue Oct 2 10:54:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C5F21F84DD for ; Tue, 2 Oct 2012 10:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 HzOQTqB6neaL for ; Tue, 2 Oct 2012 10:54:10 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id D3A7521F8438 for ; Tue, 2 Oct 2012 10:54:10 -0700 (PDT) Received: from mail80-co1-R.bigfish.com (10.243.78.239) by CO1EHSOBE006.bigfish.com (10.243.66.69) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Oct 2012 17:54:09 +0000 Received: from mail80-co1 (localhost [127.0.0.1]) by mail80-co1-R.bigfish.com (Postfix) with ESMTP id B6F9D8000D0; Tue, 2 Oct 2012 17:54:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: PS-28(zz9371I542M1432I1519Mzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h304l1155h) Received: from mail80-co1 (localhost.localdomain [127.0.0.1]) by mail80-co1 (MessageSwitch) id 1349200448241540_21788; Tue, 2 Oct 2012 17:54:08 +0000 (UTC) Received: from CO1EHSMHS013.bigfish.com (unknown [10.243.78.242]) by mail80-co1.bigfish.com (Postfix) with ESMTP id 2F1DB1C0059; Tue, 2 Oct 2012 17:54:08 +0000 (UTC) Received: from AMSPRD0710HT005.eurprd07.prod.outlook.com (157.56.249.85) by CO1EHSMHS013.bigfish.com (10.243.66.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Oct 2012 17:54:07 +0000 Received: from DB3PRD0410HT002.eurprd04.prod.outlook.com (157.56.252.21) by pod51017.outlook.com (10.255.160.168) with Microsoft SMTP Server (TLS) id 14.16.190.9; Tue, 2 Oct 2012 17:54:00 +0000 Message-ID: <04fe01cda0c6$ecb3fd80$4001a8c0@gateway.2wire.net> From: t.petch To: Pete Resnick , Apps Discuss References: <506B1B6E.9010503@qti.qualcomm.com> Date: Tue, 2 Oct 2012 18:53:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.21] X-OriginatorOrg: btconnect.com Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 17:54:11 -0000 ---- Original Message ----- From: "Pete Resnick" To: "Apps Discuss" Sent: Tuesday, October 02, 2012 5:50 PM > Folks, I'm having trouble discerning consensus from this conversation, > so I want to simplify a bit. Currently, IANA is requiring Expert Review > for *all* registrations, including things published as RFCs. That's not > what 3864 *says* to do: It is quite clear (whatever the intent) that > RFCs (whatever stream) don't go for Expert Review: > > The registration template is submitted for incorporation in one of > the IANA message header field repositories by *one of the following > methods*: > > > And the two methods specified are "RFC" and "Expert Review". > > So, here are the choices: (And I do *not* want anybody to simply choose > one; see below.) > > a) IANA should continue requiring Expert Review for all registrations. Bad idea - puts an additional load on what may be a scarce resource. > > b) IANA should require Expert Review for registrations that don't come > as part of an RFC. Poor, second best - some tracks generate RFC with little or no review and I am not saying that this is so trivial that that would be ok. > > c) IANA should require Expert Review for registrations that don't come > as part of an IETF stream RFC. Yes, preferred outcome; ensures adequate review in all cases. Tom Petch > For each of the above, I'd like to hear from folks answers of the form: > > - Yeah, this is OK with me. > - No, this would be actively bad and can not be what we tell IANA is the > current policy. > > Of course, if you say "actively bad", I'd also like to hear the reason. > Potential reasons are "that's not what 3864 says and not following the > rules is bad" or "that will let bad things be registered" or "that will > slow down important things from being registered in a timely fashion". > > The "actively bad" answers are the ones I am most interested in. > > And please keep in mind that we are telling IANA what the policy will be > until we write a new document that is clearer about our intent. This is > a stop-gap until then. > > Thanks. > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From barryleiba.mailing.lists@gmail.com Tue Oct 2 14:21:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BF121F85F9 for ; Tue, 2 Oct 2012 14:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.979 X-Spam-Level: X-Spam-Status: No, score=-102.979 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 4+vwGn-EhAiv for ; Tue, 2 Oct 2012 14:21:27 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5E5D21F85EA for ; Tue, 2 Oct 2012 14:21:17 -0700 (PDT) Received: by lamb11 with SMTP id b11so2849834lam.31 for ; Tue, 02 Oct 2012 14:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=IU1IDEMjY9ZqpNvWjMe8nEYm9AtQKCy+tfy9Vj5nveE=; b=Xa98zsAW4fBu1WNTogarBx6Z6scPIhtR3jk6XLOuVlyiE9PQyCIkh4dYoSvLh25Wt7 /vM4UveJm9kDfrtzoWHM4c7JxhzCRWEQi/ZTyhwqkgFLNVDkJDRuQclacoS+bpBRvnMi Hee+Ir7OpinIDpuJhf0a3isWVcr4o40tNv2BvI6Gwszsv1H9vhklcgL82DF31TL6ey0o AVvCtsciGj+0k4tdhBuL7NcSVbAH3bgWwXCiKP/RT0bbFI3gZv5D92ioP9iNPqm0zCLZ FCc02a2tO37rpXpX/B1ZJ1PxEA4MTWFMmvRFhS+r6OQvivH2dBds0If5LPDqve0fjDLi 9fxw== MIME-Version: 1.0 Received: by 10.152.112.136 with SMTP id iq8mr41137lab.18.1349212876576; Tue, 02 Oct 2012 14:21:16 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Tue, 2 Oct 2012 14:21:16 -0700 (PDT) Date: Tue, 2 Oct 2012 17:21:16 -0400 X-Google-Sender-Auth: BC9icALmn1v0bH2SRwIKM76OoP0 Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: [apps-discuss] What BCP 26 says about well-known IANA registration policies X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2012 21:21:32 -0000 > Pete, most of this discussion has focused on "what 3864 says" > and on when we are going to get a 3864bis and what is in it. I > think that is incorrect. I think the real issue here is in RFC > 5226 and its failure to either explicitly discuss the > relationship between the "Expert Review" category and requests > that satisfy one or more of the "RFC Required", "IETF Review", > "Standards Action", and "IESG Approval" ones or to spell out how > combinations can and should be specified. Indeed. And I have added the following section to draft-leiba-cotton-iana-5226bis-01, along with appropriate references to it from elsewhere in the document: --------------------------------------------- 4.3. Using Multiple Policies in Combination It is often desirable to allow registrations through the normal IETF process, and to also provide a mechanism for registration outside the process. Thus, a particular registry might want to use a policy such as "RFC Required" or "IETF Review" sometimes, with a designated expert checking a "Specification Required" policy at other times. Such combinations are frequently appropriate, and are encouraged. The alternative to using a combination requires either that all requests come through RFCs or that requests in RFCs go through review by the designated expert, despite the review and consensus that RFCs represent. For example, if it is felt that IETF consensus will provide good review for a particular registry, but we expect frequent registrations from other SDOs and we do not want those other organizations always to be required to go through the IETF RFC process, we might put the following in the IANA Considerations section when we create the registry: IANA is asked to create the registry "Fruit Access Flags" as a sub-registry of "Fruit Parameters". New registrations will be permitted through either the IETF Review policy or the Specification Required policy [BCP26]. Such combinations will commonly use one of {Standards Action, IETF Review, RFC Required} in combination with one of {Specification Required, Expert Review}. --------------------------------------------- > For example, if > something is identified as "IESG Approval" and the document that > modifies the registry is approved on the standards track, is > IANA required to demand that the IESG pass a separate resolution > approving the change? To me, that would be a new low in the > "process over good sense" battle, but some of the comments on > this thread would predict exactly that. Because any IETF Stream RFC has IESG approval, your example reduces to IANA simply asking the question during last call, to ensure that the IESG notices the issue. Don't worry about those sorts of silliness. > So, IMO, we need to fix 5226 sooner or later. I'll happily > leave it up to the IESG whether that fix must also explicitly > update all relevant registration documents including 3864. We're working on doing it sooner, but I've had exactly NO responses to this message: http://www.ietf.org/mail-archive/web/ietf/current/msg74180.html ...which I posted two months ago now. I'll go ahead and post -01 now(-ish), just to re-awaken things; why not? [Please do NOT discuss draft-leiba-cotton-iana-5226bis itself here; take that to .] Barry From duerst@it.aoyama.ac.jp Tue Oct 2 17:49:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA1F21F8501 for ; Tue, 2 Oct 2012 17:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.185 X-Spam-Level: X-Spam-Status: No, score=-103.185 tagged_above=-999 required=5 tests=[AWL=0.605, 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 HqoS0cPYyktb for ; Tue, 2 Oct 2012 17:49:56 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id CFA8A21F84D8 for ; Tue, 2 Oct 2012 17:49:55 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q930nhAQ028844 for ; Wed, 3 Oct 2012 09:49:44 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 3d86_4c35_38bf7030_0cf4_11e2_bf0e_001d096c566a; Wed, 03 Oct 2012 09:49:43 +0900 Received: from [IPv6:::1] ([133.2.210.1]:35012) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 3 Oct 2012 09:49:43 +0900 Message-ID: <506B8B9B.5090201@it.aoyama.ac.jp> Date: Wed, 03 Oct 2012 09:49: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: John C Klensin References: <506B1B6E.9010503@qti.qualcomm.com> <5539D2E291D44427BDF0A7E6@JcK-HP8200.jck.com> In-Reply-To: <5539D2E291D44427BDF0A7E6@JcK-HP8200.jck.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Pete Resnick , Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 00:49:57 -0000 Pretty much exactly what John said. Regards, Martin. P.S.: Just for Pete, who doesn't like simple "+1"s, I have carefully read the mails in this thread and have expressed the same opinion before. I just wanted to save some useless typing. P.P.S.: If we end up going with a), which I hope we will, then the overall change from discussion is exactly nil. I'd strongly suggest that next time a similar question comes up, the powers that be first ask what the overall potential benefits and costs of opening a discussion are. As far as I'm aware, what's currently done has produced exactly zero wrong/problematic outputs, and hasn't been challenged by anybody affected. It may be a tiny bit more work for IANA, but they are highly optimized for this kind of work. On the other hand, this discussion has used time and space on this list which I'm sure could have been used for other, more productive discussions. [Sorry if this sounded like a rant, but I had to get that out.] Regards, Martin. On 2012/10/03 2:28, John C Klensin wrote: > > > --On Tuesday, October 02, 2012 09:50 -0700 Pete Resnick > wrote: > >> Folks, I'm having trouble discerning consensus from this >> conversation, so I want to simplify a bit. Currently, IANA is >> requiring Expert Review for *all* registrations, including >> things published as RFCs. That's not what 3864 *says* to do: >> It is quite clear (whatever the intent) that RFCs (whatever >> stream) don't go for Expert Review: >> ... >> So, here are the choices: (And I do *not* want anybody to >> simply choose one; see below.) > > See comment at end, especially since you use language like "all > registrations". > >> a) IANA should continue requiring Expert Review for all >> registrations. > > - Yeah, this is OK with me and is, I believe, the most desirable > solution, especially if the Expert is smart enough to consider > whatever level of consensus an RFC might have to as part of the > evaluation (and certainly part of a community review process and > evidence that the proposal has been reviewed). I'd also expect > Experts to pay exceptionally timely attention to things coming > to them as RFC in last-stage consideration (again, see comment > at end). > >> b) IANA should require Expert Review for registrations that >> don't come as part of an RFC. > > - Actively bad unless agreements are made with other streams, > especially the Independent one, about considering the Expert > among the document reviewers. We really need to be sure someone > with expertise in the subject matter looks at these things. > >> c) IANA should require Expert Review for registrations that >> don't come as part of an IETF stream RFC. > > -- Less bad. As long as the IESG continues to insist on an IETF > Last Call for all IETF Stream documents (RFC 2026 does not > require it for Individual Submission Informational or > Experimental documents), it is plausible to assume that someone > will call the registration to the Expert's attention, causing > this option to be not much different in practice than (a). On > the other hand, I don't need to tell you how variable the > quality of review and documents reaching the IESG actually is, > so there is some risk. > >> ... >> And please keep in mind that we are telling IANA what the >> policy will be until we write a new document that is clearer >> about our intent. This is a stop-gap until then. > > Pete, most of this discussion has focused on "what 3864 says" > and on when we are going to get a 3864bis and what is in it. I > think that is incorrect. I think the real issue here is in RFC > 5226 and its failure to either explicitly discuss the > relationship between the "Expert Review" category and requests > that satisfy one or more of the "RFC Required", "IETF Review", > "Standards Action", and "IESG Approval" ones or to spell out how > combinations can and should be specified. For example, if > something is identified as "IESG Approval" and the document that > modifies the registry is approved on the standards track, is > IANA required to demand that the IESG pass a separate resolution > approving the change? To me, that would be a new low in the > "process over good sense" battle, but some of the comments on > this thread would predict exactly that. > > So, IMO, we need to fix 5226 sooner or later. I'll happily > leave it up to the IESG whether that fix must also explicitly > update all relevant registration documents including 3864. > > john > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From barryleiba.mailing.lists@gmail.com Tue Oct 2 19:06:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF54321F8615 for ; Tue, 2 Oct 2012 19:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.829 X-Spam-Level: X-Spam-Status: No, score=-102.829 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 oPHGj4uomtfq for ; Tue, 2 Oct 2012 19:06:18 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC8FB21F860B for ; Tue, 2 Oct 2012 19:06:17 -0700 (PDT) Received: by lbok13 with SMTP id k13so6400257lbo.31 for ; Tue, 02 Oct 2012 19:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Pl2jTo9MVg6oDaRZ19PAEGj4c1+eBK+fjuvlfPD7vNk=; b=owbX1eY1i1u9YQLMAOdVNIO8+2WLgeTgg+rgKt9i0CJRQ0IHfA/SmxwYWtmTKIY7+M IygfvN6VV1ZdFjTpd9A/NcqYhHYlyxHxooOC+FQxiuHxrpfiiviEiQr6YHLtXIz5/kX3 hI7s1S2t05iEDTz3Owb0OXdCq5hmJa2KqZ4yqQhIOP2WThFc1OY7AYJnjLbxDuBlwOEx uWgV6SuElpgx2wqkPdwElYQfE/fami9BmRLwk3qKf4EsVZF1tZBTLehnoBVRudGu3fcj +mm13tKXOZJ918ZHPJBKDdDY74LoU8Vwbv55ToxAWEgabSAmw//N/O3d2rVR69Ezgnd8 66xQ== MIME-Version: 1.0 Received: by 10.112.37.105 with SMTP id x9mr1195557lbj.69.1349229976796; Tue, 02 Oct 2012 19:06:16 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Tue, 2 Oct 2012 19:06:16 -0700 (PDT) In-Reply-To: <506B8B9B.5090201@it.aoyama.ac.jp> References: <506B1B6E.9010503@qti.qualcomm.com> <5539D2E291D44427BDF0A7E6@JcK-HP8200.jck.com> <506B8B9B.5090201@it.aoyama.ac.jp> Date: Tue, 2 Oct 2012 22:06:16 -0400 X-Google-Sender-Auth: i42bdwGbGc3P9Da1GLRJZQAvGUY Message-ID: From: Barry Leiba To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=ISO-8859-1 Cc: Pete Resnick , Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 02:06:18 -0000 > I'd strongly suggest that next time a > similar question comes up, the powers that be first ask what the overall > potential benefits and costs of opening a discussion are. As far as I'm > aware, what's currently done has produced exactly zero wrong/problematic > outputs, and hasn't been challenged by anybody affected. It may be a tiny > bit more work for IANA, but they are highly optimized for this kind of work. > On the other hand, this discussion has used time and space on this list > which I'm sure could have been used for other, more productive discussions. > [Sorry if this sounded like a rant, but I had to get that out.] No, that's a fair cop. On the other hand, though, the IETF works on consensus. Pete and I certainly could have just made an executive decision. For me, rough consensus is better. Barry From James.H.Manger@team.telstra.com Tue Oct 2 19:49:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6050721F85F4 for ; Tue, 2 Oct 2012 19:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.571 X-Spam-Level: X-Spam-Status: No, score=-0.571 tagged_above=-999 required=5 tests=[AWL=0.330, 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 ThR72OZJNrvs for ; Tue, 2 Oct 2012 19:49:58 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6F83221F85C3 for ; Tue, 2 Oct 2012 19:49:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,526,1344175200"; d="scan'208";a="95541279" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 03 Oct 2012 12:49:56 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6853"; a="131419686" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcavi.tcif.telstra.com.au with ESMTP; 03 Oct 2012 12:49:56 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Wed, 3 Oct 2012 12:49:55 +1000 From: "Manger, James H" To: James M Snell , IETF Apps Discuss Date: Wed, 3 Oct 2012 12:49:55 +1000 Thread-Topic: [apps-discuss] JSON Patch feedback Thread-Index: Ac2gvB5CjI06Nyt/TWefg+MFf4qTNQAVTjPQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114FD7D5589@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] JSON Patch feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2012 02:49:59 -0000 PiBMYXN0bHksIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gcHJvdmlkZSBhIGZldyBtb3JlIEFycmF5 IGV4YW1wbGVzIGluIHRoZQ0KPiBhcHBlbmRpeC4uLiBmb3IgaW5zdGFuY2U6DQo+IA0KPiBBcnJh eXMgbmVzdGVkIHdpdGhpbiBhcnJheXMuIEdpdmVuLi4uDQo+IA0KPiDCoCB7DQo+IMKgIMKgICJh IjogWw0KPiDCoCDCoCDCoCBbMSwyLDNdLA0KPiDCoCDCoCDCoCBbIkEiLCJCIiwiQyJdDQo+IMKg IMKgIF0NCj4gwqAgfQ0KPiANCj4gSWYgSSB3aXNoZWQgdG8gc3dhcCB0aGUgc2Vjb25kIGVsZW1l bnRzIG9mIHRoZSB0d28gYXJyYXlzLCBJIHdvdWxkDQo+IGRvLi4uDQo+IA0KPiDCoCBbDQo+IMKg IMKgIHsib3AiOiAibW92ZSIsICJwYXRoIjogIi9hLzAvMSIsICJ0byI6ICIvYS8xLzEifSwNCj4g wqAgwqAgeyJvcCI6ICJtb3ZlIiwgInBhdGgiOiAiL2EvMS8yIiwgInRvIjogIi9hLzEvMSJ9DQo+ IMKgIF0NCg0KTm90IHF1aXRlLiBUaGUgMm5kIG9wZXJhdGlvbiBzaG91bGQgYmUgInRvIjoiL2Ev MC8xIi4NCg0KPiANCj4gV2hpY2ggeWllbGRzLi4uDQo+IA0KPiDCoCB7DQo+IMKgIMKgICJhIjog Ww0KPiDCoCDCoCDCoCBbMSwiQiIsM10sDQo+IMKgIMKgIMKgIFsiQSIsMiwiQyJdDQo+IMKgIMKg IF0NCj4gwqAgfQ0K From ned.freed@mrochek.com Tue Oct 2 20:09:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB9721F85C6 for ; Tue, 2 Oct 2012 20:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJo2Mq8kJ39t for ; Tue, 2 Oct 2012 20:09:42 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 46AE021F85B8 for ; Tue, 2 Oct 2012 20:09:41 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKYGECK3Y800AW4X@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 2 Oct 2012 20:04:38 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKWD2NXQC00006TF@mauve.mrochek.com>; Tue, 2 Oct 2012 20:04:36 -0700 (PDT) Message-id: <01OKYGEAYE9A0006TF@mauve.mrochek.com> Date: Tue, 02 Oct 2012 15:21:30 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 02 Oct 2012 09:50:54 -0700" <506B1B6E.9010503@qti.qualcomm.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <506B1B6E.9010503@qti.qualcomm.com> To: Pete Resnick Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 03:09:43 -0000 > Folks, I'm having trouble discerning consensus from this conversation, > so I want to simplify a bit. Currently, IANA is requiring Expert Review > for *all* registrations, including things published as RFCs. That's not > what 3864 *says* to do: It is quite clear (whatever the intent) that > RFCs (whatever stream) don't go for Expert Review: > The registration template is submitted for incorporation in one of > the IANA message header field repositories by *one of the following > methods*: > And the two methods specified are "RFC" and "Expert Review". > So, here are the choices: (And I do *not* want anybody to simply choose > one; see below.) At this point I think a few words about the purpose of this registry are in order. Not to belabor the obvious, but different registries exist for different reasons. A registry of standardized SMTP extensions exists in order to provide an authoritative list of same. It's a matter of convenience, not providing new information. The media types registry exists for several purposes, including to establish common naming conventions and to provide a little information about semantics and possible security issues. But one of the things it doesn't do in general is provide descriptions or even pointers to descriptions of the media type. So why do we have, or even want, a header registry? Again, I'm not especially interested in intent, but what I want to see from such a registry is rather more than a reiteration of what the IETF has chosen to specify in an RFC. What I would like, although I recognize that there's precious little chance of it happening at this point, is some information about some subset - even a small subset - of the myriad headers that are in use out there. As a small example among many, yesterday I received a message from the ietf-charsets list with the following block of headers on it: X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Originating-IP: [131.107.147.4] X-OrganizationHeadersPreserved: BY2PRD0310HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MROCHEK.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IT.AOYAMA.AC.JP$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IANA.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Mon, 01 Oct 2012 21:03:23 +0000 (UTC) (I'll spare you the entire thing, which was over 100 lines long,) This sort of thing is now par for the course. And while I have no doubt that a lot of this is badly designed, ill-conceived, and even irrelevant, there are times when knowing what it means is actually important. To this end, added review beyond making sure what is there is coherent is a bad idea. And with that in mind... > a) IANA should continue requiring Expert Review for all registrations. Actively bad. Waste of resources and too high a barrier. It doesn't help that it isn't what the rules say. > b) IANA should require Expert Review for registrations that don't come > as part of an RFC. OK with me. And as I said before, this needs to focus on the registration, not what it describes. That can be total crap. In fact the ones describing complete crap are sometimes the ones that are important, because I haven't found that customers demanding interoperability with something find "but it's crap" to be an acceptable excuse. > c) IANA should require Expert Review for registrations that don't come > as part of an IETF stream RFC. Actively bad. These documents have received sufficient review by the time they get this far, there is no need to require more. Ned From ned.freed@mrochek.com Tue Oct 2 22:13:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D94B21F8688 for ; Tue, 2 Oct 2012 22:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 g3js-XJZ+E6A for ; Tue, 2 Oct 2012 22:13:02 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0542621F859F for ; Tue, 2 Oct 2012 22:13:01 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKYKP9T0GW00C8YM@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 2 Oct 2012 22:07:59 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKWD2NXQC00006TF@mauve.mrochek.com>; Tue, 2 Oct 2012 22:07:56 -0700 (PDT) Message-id: <01OKYKP85PBY0006TF@mauve.mrochek.com> Date: Tue, 02 Oct 2012 22:06:27 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 02 Oct 2012 22:06:16 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <506B1B6E.9010503@qti.qualcomm.com> <5539D2E291D44427BDF0A7E6@JcK-HP8200.jck.com> <506B8B9B.5090201@it.aoyama.ac.jp> To: Barry Leiba Cc: Pete Resnick , Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 05:13:02 -0000 > > I'd strongly suggest that next time a > > similar question comes up, the powers that be first ask what the overall > > potential benefits and costs of opening a discussion are. As far as I'm > > aware, what's currently done has produced exactly zero wrong/problematic > > outputs, and hasn't been challenged by anybody affected. As always with registration processes, I'm more concerned with the outputs that were not produced than the ones that were. Ned From duerst@it.aoyama.ac.jp Tue Oct 2 22:55:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E5B21F8682 for ; Tue, 2 Oct 2012 22:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.214 X-Spam-Level: X-Spam-Status: No, score=-103.214 tagged_above=-999 required=5 tests=[AWL=0.576, 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 a-Vch62Ap97u for ; Tue, 2 Oct 2012 22:55:29 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id EBD7621F8619 for ; Tue, 2 Oct 2012 22:55:28 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q935tF8b013408 for ; Wed, 3 Oct 2012 14:55:16 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 3537_0b58_e78f824c_0d1e_11e2_a387_001d096c5782; Wed, 03 Oct 2012 14:55:15 +0900 Received: from [IPv6:::1] ([133.2.210.1]:47140) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 3 Oct 2012 14:55:14 +0900 Message-ID: <506BD336.4030508@it.aoyama.ac.jp> Date: Wed, 03 Oct 2012 14:55:02 +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: Ned Freed References: <506B1B6E.9010503@qti.qualcomm.com> <5539D2E291D44427BDF0A7E6@JcK-HP8200.jck.com> <506B8B9B.5090201@it.aoyama.ac.jp> <01OKYKP85PBY0006TF@mauve.mrochek.com> In-Reply-To: <01OKYKP85PBY0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Pete Resnick , Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 05:55:29 -0000 Hello Ned, On 2012/10/03 14:06, Ned Freed wrote: >>> I'd strongly suggest that next time a >>> similar question comes up, the powers that be first ask what the overall >>> potential benefits and costs of opening a discussion are. As far as I'm >>> aware, what's currently done has produced exactly zero wrong/problematic >>> outputs, and hasn't been challenged by anybody affected. > > As always with registration processes, I'm more concerned with the outputs that > were not produced than the ones that were. Good point. Actually, with "zero wrong/problematic outputs", I intended to include both "false positives" and "false negatives", but that was probably not clear enough. Anyway, I don't think that there is a single case that a registration contained in an RFC was rejected because it didn't manage to pass the expert review, so I think in the case of hand, this consideration is actually irrelevant in practice. Regards, Martin. From ned.freed@mrochek.com Tue Oct 2 23:29:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF87321F86B1 for ; Tue, 2 Oct 2012 23:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 yK6wSXWKsYl9 for ; Tue, 2 Oct 2012 23:29:26 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 72C7821F8615 for ; Tue, 2 Oct 2012 23:29:26 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKYNEMK19C00BFOQ@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 2 Oct 2012 23:25:42 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKWD2NXQC00006TF@mauve.mrochek.com>; Tue, 2 Oct 2012 23:25:38 -0700 (PDT) Message-id: <01OKYNEKC5U40006TF@mauve.mrochek.com> Date: Tue, 02 Oct 2012 23:19:02 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 03 Oct 2012 14:55:02 +0900" <506BD336.4030508@it.aoyama.ac.jp> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <506B1B6E.9010503@qti.qualcomm.com> <5539D2E291D44427BDF0A7E6@JcK-HP8200.jck.com> <506B8B9B.5090201@it.aoyama.ac.jp> <01OKYKP85PBY0006TF@mauve.mrochek.com> <506BD336.4030508@it.aoyama.ac.jp> To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Cc: Pete Resnick , Barry Leiba , Ned Freed , Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 06:29:27 -0000 > Hello Ned, > On 2012/10/03 14:06, Ned Freed wrote: > >>> I'd strongly suggest that next time a > >>> similar question comes up, the powers that be first ask what the overall > >>> potential benefits and costs of opening a discussion are. As far as I'm > >>> aware, what's currently done has produced exactly zero wrong/problematic > >>> outputs, and hasn't been challenged by anybody affected. > > > > As always with registration processes, I'm more concerned with the outputs that > > were not produced than the ones that were. > Good point. Actually, with "zero wrong/problematic outputs", I intended > to include both "false positives" and "false negatives", but that was > probably not clear enough. > Anyway, I don't think that there is a single case that a registration > contained in an RFC was rejected because it didn't manage to pass the > expert review, so I think in the case of hand, this consideration is > actually irrelevant in practice. In the case of RFCs from the IETF, probably true. It's harder to say for indepedent stream documents and non-RFC registrations, but it's still likely to have negligible effect, especially at this late date. So yes, John is correct in saying that this really is little benefit for the cost. Unless, perhaps we use it as a vehicle to examine our overall approach to registration policies. Ned From john-ietf@jck.com Wed Oct 3 06:04:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1444921F84DD for ; Wed, 3 Oct 2012 06:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGUOZB6ChVnO for ; Wed, 3 Oct 2012 06:04:45 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 52F0E21F845F for ; Wed, 3 Oct 2012 06:04:45 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TJOcz-000CD2-RW; Wed, 03 Oct 2012 09:04:41 -0400 Date: Wed, 03 Oct 2012 09:04:36 -0400 From: John C Klensin To: Ned Freed , Pete Resnick Message-ID: <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> In-Reply-To: <01OKYGEAYE9A0006TF@mauve.mrochek.com> References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 13:04:46 -0000 --On Tuesday, October 02, 2012 15:21 -0700 Ned Freed wrote: >> a) IANA should continue requiring Expert Review for all >> registrations. > > Actively bad. Waste of resources and too high a barrier. It > doesn't help > that it isn't what the rules say. > >> b) IANA should require Expert Review for registrations that >> don't come as part of an RFC. > > OK with me. And as I said before, this needs to focus on the > registration, not > what it describes. That can be total crap. In fact the ones > describing complete > crap are sometimes the ones that are important, because I > haven't found that > customers demanding interoperability with something find "but > it's crap" to be > an acceptable excuse. > >> c) IANA should require Expert Review for registrations that >> don't come as part of an IETF stream RFC. > > Actively bad. These documents have received sufficient review > by the time > they get this far, there is no need to require more. Ned, I'm not sure we disagree, but let me explain what I was trying to say in case it helps. (0) For the present/immediate situation, I believe that Graham should send in a signoff "for the avoidance of doubt", IANA should observe that it has _both_ an draft RFC and an Expert signoff in hand, they should smile happily, and we should move on. When good sense is working, I don't think we should be trying to invent hair-splitting rules to solve a non-problem, especially on an urgent basis. (1) At the risk of drifting out of the Header Registry-specific discussion, I think it would be wise to revise/update RFC 5226 to _require_ that any document that specifies "Expert Review" contain a statement about what that review is supposed to cover. Just as you suggest there are different types of registries with different purposes, I think there are differences among reviews for coherence, for accuracy, for conformity to a particular set or rules or guidelines, for taste, etc. It would probably also be useful for a 5226bis to divide Expert Review into two categories: "expert consultation required" and "expert approval required", where the former would cause IANA to ask the Expert "have you looked at this and delivered any comments" and not "is this ok". In the former case, the Expert Review is definitely non-blocking even though it might result in a short delay while the proposer decides whether or not to revise the application/request. I hope we can trust the IESG (reinforced by a few appeals if needed) to both enforce such a specification requirement and to select and retain only those experts who are willing to toe the line. (2) Graham has, as far as I can tell, been applying exactly the test for coherency that we are advocating. While we might want to give guidance to his potential successors, we are probably in an "if it ain't broke, don't fix it" situation right now. (3) The reason I'm advocating having the Expert take a look at _all_ potential new entries in this particular registry is that Graham (or you, or me, or most or all of the participants in this discussion) might have a better eye for what is or is not coherent than the potential registrant of, e.g., "X-FUSSP:" or an ISE, IAB, IRTF, or even IETF review process that is concentrating on other things. As long as the Expert is just an extra set of skilled eyes looking at the registration request and doesn't have to do much more than confirm that he or she has looked at it, and as long as the IESG is willing to deal with non-feasant Experts, I think such a review requirement falls into the "harmless at worst" category. best, john From alexey.melnikov@isode.com Wed Oct 3 06:56:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7291221F8616 for ; Wed, 3 Oct 2012 06:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.659 X-Spam-Level: X-Spam-Status: No, score=-102.659 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_102=0.6, J_CHICKENPOX_35=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 1wjiaq+Ym+XV for ; Wed, 3 Oct 2012 06:56:10 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 47FE221F8682 for ; Wed, 3 Oct 2012 06:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1349272568; d=isode.com; s=selector; i=@isode.com; bh=CGPOhupUm4rct2117mJvsFLWnSYtJ2885edfa46Ufew=; 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=abkeLiUv1qT+VDymooWu6y4nToyp2OxacwMuILA0tV7MdUXCRnWgvTEn7FpykMuF7un3sC q+hRg1iYihZmicw2YTbZTuDSirNzlyryCVe4Kxaeg2BSiSD86DicW+LZnGotrQ4+NRO2mh tOjEQTVLeMd5KfIsx/v+HJmwYJOy7bw=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 3 Oct 2012 14:56:08 +0100 Message-ID: <506C43FA.5040608@isode.com> Date: Wed, 03 Oct 2012 14:56:10 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: "apps-discuss@ietf.org" References: <506C43AA.9010206@isode.com> In-Reply-To: <506C43AA.9010206@isode.com> X-Forwarded-Message-Id: <506C43AA.9010206@isode.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060906080604040201090209" Subject: [apps-discuss] Fwd: SecDir and AppsDir review of draft-ietf-storm-iscsi-cons-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: Wed, 03 Oct 2012 13:56:12 -0000 This is a multi-part message in MIME format. --------------060906080604040201090209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As this is also an AppsDir review, I am sending it here. -------- Original Message -------- Subject: SecDir and AppsDir review of draft-ietf-storm-iscsi-cons-06 Date: Wed, 03 Oct 2012 14:54:50 +0100 From: Alexey Melnikov To: secdir@ietf.org, draft-ietf-storm-iscsi-cons.all@tools.ietf.org, iesg@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a transport protocol for SCSI that works on top of TCP. Summary Overall this is a very well written document. I also trust that all options were implemented by at least 1 implementation, so the document reflects implementation experience. The Security Considerations section is thorough. iSCSI security partially relies on security provided by IPSec. Unfortunately I do not have the IPSec expertise to determine if all relevant cases were covered, although the text looked plausible. Security considerations for CHAP and SRP authentication mechanisms are discussed in details and seem to be adequate. I've not seen any discussion of KRB5 (mentioned in 12.1) related issues though. I also have other more detailed comments (some of them are security related). They range between minor and nits, although some of them can be reclassified as a bit more important: In Section 2.2: >- SCSI Port Name: A name made up as UTF-8 characters and includes > the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag. The first mention of UTF-8 needs a reference. "UTF-8 characters" should be something like "UTF-8 [UTF-8] encoding of Unicode characters. (There is no such thing as "UTF-8 character") In Section 4.2, 2nd paragraph: > For the remainder of this document, the terms "initiator" and > "target" refer to "iSCSI initiator node" and "iSCSI target node", > respectively (see iSCS) unless otherwise qualified. I didn't find iSCS in the list of acronyms. In 4.2.2.3.3: Whenever the TaskReporting key (Section 13.23"Task Reporting") is negotiated to ResponseFence or FastAbort for an iSCSI session and the Response Fence behavior is required for a SCSI response message, The last part: how can this be known? the target iSCSI layer MUST perform the actions described in this Section for that session. In 4.2.2.3.4: Note: - Due to the absence of ACA-related fencing requirements in [RFC3720], initiator implementations SHOULD NOT use ACA on multi-connection iSCSI sessions with targets complying only with [RFC3720]. How can the initiator know whether the target only complies with RFC 3720 or not? 4.2.3.2. Notion of Affected Tasks LOGICAL UNIT RESET: All outstanding tasks from all initiators for the LU identified by the LUN field in the LOGICAL UNIT RESET Request PDU. Are there any access control facilities for this operation? 4.2.3.4. FastAbort Multi-task Abort Semantics Protocol behavior defined in this Section SHOULD be implemented by Why is this a SHOULD (and not a MUST)? What are possible alternatives? all iSCSI implementations complying with this document. Protocol behavior defined in this Section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (Section 13.23) key to "FastAbort" on that session. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party. In Section 4.2.7.1 iSCSI names are composed only of displayable characters. What does "displayable" means here? "ASCII printable"? "Unicode printable"? iSCSI names allow the use of international character sets but are not case sensitive. What does this mean exactly? Do you mean ASCII case sensitivity? Unicode case sensitivity? No whitespace characters are used in iSCSI names. What is "whitespace". U+0020? (ASCII space) Something else? 4.2.7.2. iSCSI Name Encoding The stringprep process is described in [RFC3454]; iSCSI's use of the stringprep process is described in [RFC3722]. Stringprep is a method designed by the Internationalized Domain Name (IDN) working group to translate human-typed strings into a format that can be compared as opaque strings. Strings MUST NOT include punctuation, spacing, diacritical marks, or other characters that could get in the way of readability. This MUST NOT is not well defined. You need to define specific Unicode codepoints or character classes. The stringprep process also converts strings into equivalent strings of lower-case characters. The stringprep process does not need to be implemented if the names are only generated using numeric and lower-case (any character set) alphabetic characters. Lower-case is not well defined, unless you say you mean ASCII or something else. Also, "any character set"? This really doesn't look correct. Once iSCSI names encoded in UTF-8 are "normalized" they may be safely compared byte-for-byte. Nit: I suggest adding "as described in this section" after "normalized" to distinguish this from various forms of Unicode Normalization, etc. In Section 4.2.7.4: To generate names of this type, the person or organization generating the name must own a registered domain name. This domain name does not have to be active, IMHO, the meaning of "active" is not clear here. and does not have to resolve to an address; it just needs to be reserved to prevent others from generating iSCSI names using the same domain name. Every time the document is referring to "hexadecimal" - is the case important or not? In 4.2.9: In situations where IP packets are delivered in order from the network, iSCSI message framing is not an issue and messages are processed one after the other. In the presence of IP packet reordering (i.e., frames being dropped), legacy TCP Nit: What is so "legacy" about these implementations? Please explain or drop "legacy" here. implementations store the "out of order" TCP segments in temporary buffers until the missing TCP segments arrive, upon which the data must be copied to the application buffers. In iSCSI, it is desirable to steer the SCSI data within these out of order TCP segments into the pre-allocated SCSI buffers rather than store them in temporary buffers. This decreases the need for dedicated reassembly buffers as well as the latency and bandwidth related to extra copies. 4.3. iSCSI Session Types The session type is defined during login with key=value parameter in the login command. Using which key? In 4.6.1.5: To enable a SCSI command to be processed while involving a minimum number of messages, the last SCSI Data-in PDU passed for a command may also contain the status if the status indicates termination with no exceptions (no sense or response involved). A forward reference to "sense" would be good here. In 6.1: base64-constant: base64 constant encoded as a string that starts with "0b" or "0B" followed by 1 or more digits or letters or plus or slash or equal. I think you need to include ASCII codes for the above, just to be clear. Also, this is not quite correct, as leading "=" is not valid in base64 encoding, etc. The encoding is done according to [RFC2045] Please reference "Section 4 of [RFC4648]" instead of RFC 2045. RFC 4648 is the most recent RFC for base64 definition. 6.2.1. List negotiations In list negotiation, the originator sends a list of values (which may include "None") in its order of preference. Is "None" a special value that designates an empty list? Or am I misintepreting what it is used for? If an acceptor does not understand any particular value in a list, it MUST ignore it. If an acceptor does not support, does not understand, or is not allowed to use any of the proposed options with a specific originator, it may use the constant "Reject" or terminate the negotiation. The selection of a value not proposed MUST be handled as a protocol error. I suggest inserting "by the initiator" before "as a protocol error". 6.2.2. Simple-value Negotiations Specifically, the two cases in which answers are OPTIONAL are: - The Boolean function is "AND" and the value "No" is received. The outcome of the negotiation is "No". - The Boolean function is "OR" and the value "Yes" is received. The outcome of the negotiation is "Yes". You lost me here, can you provide an example or two? In 6.3: The Login Phase MAY include a SecurityNegotiation stage and a LoginOperationalNegotiation stage and MUST include at least one of them, but the included stage MAY be empty except for the mandatory names. Again, an example (or pointer) here would be useful, as I am not entirely clear what this mean. Security MUST be completely negotiated within the Login Phase. The What is the meaning of the word "Security" in this case? use of underlying IPsec security is specified in Chapter 8 and in [RFC3723]. iSCSI support for security within the protocol only consists of authentication in the Login Phase. In some environments, a target or an initiator is not interested in authenticating its counterpart. It is possible to bypass How? authentication through the Login request and response. In 6.3.1: -Login Response with Login reject. This is an immediate rejection from the target that causes the connection to terminate and the session to terminate if this is the first (or only) connection of a new session. The T bit and the CSG and NSG fields are reserved. What does "reserved" mean in this case? In 6.3.2: It should be noted that the negotiation might also be directed by the target if the initiator does support security, but is not ready to direct the negotiation (propose options). How can this be done? In 6.3.5: Session timeout is an event defined to occur when the last connection state timeout expires and no tasks are waiting for reassignment. This takes the session to the FREE state (N6 transition in the session state diagram). Is the timeout implied or negotiated? In 7.1.4: In the detailed description of the recover classes the mandating terms (MUST, SHOULD, MAY, etc.) indicate normative actions to be executed if the recovery class is supported and used. How is such support shown/negotiated? 7.1.4.1. Recovery Within-command Header digest error, which manifests as a sequence reception timeout or a sequence error - dealt with as specified in Section 7.9, using the option of a recovery R2T. Did you mean 7.9 or 7.8? (Also check elsewhere in the document.) 7.1.4.2. Recovery Within-connection At the initiator, the following cases lend themselves to within- connection recovery: - Requests not acknowledged for a long time. Requests are acknowledged explicitly through ExpCmdSN or implicitly by receiving data and/or status. The initiator MAY retry non- acknowledged commands as specified in Retry an. Sorry, I didn't get what "Retry an" is. In 7.2.2: In reassigning connection allegiance for a command, the targets SHOULD continue the command from its current state. For example, when reassigning read commands, the target SHOULD take advantage of the ExpDataSN field provided by the Task Management function request (which must be set to zero if there was no data transfer) and bring the read command to completion by sending the remaining data and sending (or resending) the status. ExpDataSN acknowledges all data sent up to, but not including, the Data-In PDU and or R2T with DataSN (or R2TSN) equal to ExpDataSN. However, targets may choose to send/receive all unacknowledged data or all of the data on a reassignment of connection allegiance if unable to recover or maintain accurate an state. Nit: Should "an" be dropped? 7.14. Connection Failures iSCSI can keep a session in operation if it is able to keep/establish at least one TCP connection between the initiator and the target in a timely fashion. Targets and/or initiators may recognize a failing connection by either transport level means (TCP), a gap in the command sequence number, a response stream that is not filled for a long time, or by a failing iSCSI NOP (acting as a ping). The latter MAY be used periodically to increase the speed and likelihood of detecting connection failures. Initiators and targets MAY also use the keep-alive option on the TCP connection I think TCP keep-alive option needs a reference here. to enable early link failure detection on otherwise idle links. In 9.2.1: The first mentioning of RADIUS needs an Informative reference. In 9.3.1: - HMAC-SHA1 MUST be implemented [RFC2404]. RFC 2404 seems to define HMAC-SHA-1-96, not HMAC-SHA1. 9.3.2. Confidentiality The NULL encryption algorithm MUST also be implemented. I find it odd that the section talks about how weak DES is and then requires NULL encryption to be supported. What is the reason for this? 9.3.3. Policy, Security Associations, and Cryptographic Key Management - When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority. IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) before accepting a PKI certificate for use in IKE authentication procedures. What are the reasons for these requirements being SHOULD level (as opposed to MUST level)? - The following identification type requirements apply to IKEv1. ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6) and ID_FQDN Identification Types MUST be supported; ID_USER_FQDN SHOULD be supported. The IP Subnet, IP Address Range, ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types SHOULD NOT be used. The ID_KEY_ID Identification Type MUST NOT be used. It would be good to know the reason for the last SHOULD NOT and the last MUST NOT. 10.5. Synch and Steering Layer and Performance While a synch and steering layer is optional, Is this section defining "synch and steering layer"? I found the use of this term confusing. an initiator/target that does not have it working against a target/initiator that demands synch and steering may experience performance degradation caused by packet reordering and loss. Providing a synch and steering mechanism is recommended for all high-speed implementations. 10.6.1. Determining the Proper ErrorRecoveryLevel Probability of transport layer "checksum escape". Is this a well known term and if it is, what does it mean? 11.3.1. Flags and Task Attributes (byte 1) bit 3-4 Reserved. Here and everywhere else in the document: what does it mean "reserved"? Do you mean "MUST be set to zero when sent, MUST be ignored when received"? 11.4.4. SNACK Tag For a detailed discussion on R-Data SNACK see SNACK. Is the last "SNACK" supposed to be a proper section reference? 11.4.5.3. SCSI REPORT LUNS and Residual Overflow If the Expected Data Transfer Length (EDTL) in the iSCSI header of the SCSI Command PDU for a REPORT LUNS command is set to at least as large as that ALLOCATION LENGTH, the SCSI layer truncation prevents an iSCSI Residual Overflow from occurring. A SCSI initiator can detect that such truncation has occurred via other information at theS CSI layer. The rest of the Section elaborates s/theS CSI/the SCSI this required behavior. 11.9.2. AsyncVCode AsyncVCode is a vendor specific detail code that is only valid if the AsyncEvent field indicates a vendor specific event. Otherwise, it is reserved. Is there an IANA registry for these? 11.13.8. Login Parameters Keys in Section 12, only need to be supported when the function to which they refer is mandatory to implement. How is this decided? 12.1. AuthMethod Use: During Login - Security Negotiation Senders: Initiator and Target Scope: connection AuthMethod = The main item of security negotiation is the authentication method (AuthMethod). The authentication methods that can be used (appear in the list- of-values) are either those listed in the following table or are vendor-unique methods: Is there an IANA registry for this? 12.1.2. Secure Remote Password (SRP) For SRP [RFC2945], the initiator MUST use: SRP_U= TargetAuth=Yes /* or TargetAuth=No */ The target MUST answer with a Login reject with the "Authorization Failure" status or reply with: SRP_GROUP= SRP_s= How are elements delemited on the wire? 12.1.3. Challenge Handshake Authentication Protocol (CHAP) For CHAP [RFC1994], the initiator MUST use: CHAP_A= As above: How are elements delemited on the wire? To guarantee interoperability, initiators MUST always offer it as one of the proposed algorithms. "Offer" or "support"? Most Apps protocols describe support, not necessarily requiring that the mandatory-to-implement is enabled in a particular server. --------------060906080604040201090209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As this is also an AppsDir review, I am sending it here.

-------- Original Message --------
Subject: SecDir and AppsDir review of draft-ietf-storm-iscsi-cons-06
Date: Wed, 03 Oct 2012 14:54:50 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: secdir@ietf.org, draft-ietf-storm-iscsi-cons.all@tools.ietf.org, iesg@ietf.org 


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document describes a transport protocol for SCSI that works
on top of TCP.


Summary

Overall this is a very well written document. I also trust that all 
options were implemented by at least 1 implementation, so the document 
reflects implementation experience.

The Security Considerations section is thorough. iSCSI security 
partially relies on security provided by IPSec. Unfortunately I do not 
have the IPSec expertise to determine if all relevant cases were 
covered, although the text looked plausible.

Security considerations for CHAP and SRP authentication mechanisms are 
discussed in details and seem to be adequate. I've not seen any 
discussion of KRB5 (mentioned in 12.1) related issues though.

I also have other more detailed comments (some of them are security 
related). They range between minor and nits, although some of them can 
be reclassified as a bit more important:


In Section 2.2:

>- SCSI Port Name: A name made up as UTF-8 characters and includes
>  the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag.

The first mention of UTF-8 needs a reference.

"UTF-8 characters" should be something like "UTF-8 [UTF-8] encoding of 
Unicode characters.
(There is no such thing as "UTF-8 character")


In Section 4.2, 2nd paragraph:

>  For the remainder of this document, the terms "initiator" and
>  "target" refer to "iSCSI initiator node" and "iSCSI target node",
>  respectively (see iSCS) unless otherwise qualified.

I didn't find iSCS in the list of acronyms.

In 4.2.2.3.3:

  Whenever the TaskReporting key (Section 13.23"Task Reporting") is
  negotiated to ResponseFence or FastAbort for an iSCSI session and
  the Response Fence behavior is required for a SCSI response
  message,

The last part: how can this be known?

  the target iSCSI layer MUST perform the actions described
  in this Section for that session.

In 4.2.2.3.4:

 Note:
    - Due to the absence of ACA-related fencing requirements in
      [RFC3720], initiator implementations SHOULD NOT use ACA on
       multi-connection iSCSI sessions with targets complying only
       with [RFC3720].


How can the initiator know whether the target only complies with RFC 
3720 or not?

4.2.3.2. Notion of Affected Tasks

  LOGICAL UNIT RESET: All outstanding tasks from all initiators for
  the LU identified by the LUN field in the LOGICAL UNIT RESET
  Request PDU.

Are there any access control facilities for this operation?

4.2.3.4. FastAbort Multi-task Abort Semantics

  Protocol behavior defined in this Section SHOULD be implemented by

Why is this a SHOULD (and not a MUST)? What are possible alternatives?

  all iSCSI implementations complying with this document. Protocol
  behavior defined in this Section MUST be exhibited by iSCSI
  implementations on an iSCSI session when they negotiate the
  TaskReporting (Section 13.23) key to "FastAbort" on that session.
  The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT
  RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests
  consists of the following sequence of actions in the specified
  order on the specified party.

In Section 4.2.7.1

     iSCSI names are composed only of displayable characters.

What does "displayable" means here? "ASCII printable"? "Unicode printable"?

        iSCSI
        names allow the use of international character sets but are
        not case sensitive.

What does this mean exactly? Do you mean ASCII case sensitivity? Unicode 
case sensitivity?

        No whitespace characters are used in
        iSCSI names.

What is "whitespace". U+0020? (ASCII space) Something else?

4.2.7.2. iSCSI Name Encoding

  The stringprep process is described in [RFC3454]; iSCSI's use of
  the stringprep process is described in [RFC3722]. Stringprep is a
  method designed by the Internationalized Domain Name (IDN) working
  group to translate human-typed strings into a format that can be
  compared as opaque strings. Strings MUST NOT include punctuation,
  spacing, diacritical marks, or other characters that could get in
  the way of readability.

This MUST NOT is not well defined. You need to define specific Unicode 
codepoints or character classes.

  The stringprep process also converts
  strings into equivalent strings of lower-case characters.


  The stringprep process does not need to be implemented if the
  names are only generated using numeric and lower-case (any
  character set) alphabetic characters.

Lower-case is not well defined, unless you say you mean ASCII or 
something else.
Also, "any character set"? This really doesn't look correct.

  Once iSCSI names encoded in UTF-8 are "normalized" they may be
  safely compared byte-for-byte.

Nit: I suggest adding "as described in this section" after "normalized" 
to distinguish this from various forms of Unicode Normalization, etc.


In Section 4.2.7.4:

  To generate names of this type, the person or organization
  generating the name must own a registered domain name. This domain
  name does not have to be active,

IMHO, the meaning of "active" is not clear here.

  and does not have to resolve to
  an address; it just needs to be reserved to prevent others from
  generating iSCSI names using the same domain name.



Every time the document is referring to "hexadecimal" - is the case 
important or not?

In 4.2.9:

  In situations where IP packets are delivered in order from the
  network, iSCSI message framing is not an issue and messages are
  processed one after the other. In the presence of IP packet
  reordering (i.e., frames being dropped), legacy TCP

Nit: What is so "legacy" about these implementations? Please explain or 
drop "legacy" here.

  implementations store the "out of order" TCP segments in temporary
  buffers until the missing TCP segments arrive, upon which the data
  must be copied to the application buffers. In iSCSI, it is
  desirable to steer the SCSI data within these out of order TCP
  segments into the pre-allocated SCSI buffers rather than store
  them in temporary buffers. This decreases the need for dedicated
  reassembly buffers as well as the latency and bandwidth related to
  extra copies.

4.3. iSCSI Session Types

  The session type is defined during login with key=value parameter
  in the login command.

Using which key?

In 4.6.1.5:

  To enable a SCSI command to be processed while involving a minimum
  number of messages, the last SCSI Data-in PDU passed for a command
  may also contain the status if the status indicates termination
  with no exceptions (no sense or response involved).

A forward reference to "sense" would be good here.

In 6.1:

 base64-constant: base64 constant encoded as a string that
       starts with "0b" or "0B" followed by 1 or more digits or
       letters or plus or slash or equal.

I think you need to include ASCII codes for the above, just to be clear.

Also, this is not quite correct, as leading "=" is not valid in base64 
encoding, etc.

       The encoding is done
       according to [RFC2045]

Please reference "Section 4 of [RFC4648]" instead of RFC 2045. RFC 4648 
is the most recent
RFC for base64 definition.

6.2.1. List negotiations

  In list negotiation, the originator sends a list of values (which
  may include "None") in its order of preference.

Is "None" a special value that designates an empty list? Or am I 
misintepreting what it is used for?

  If an acceptor does not understand any particular value in a list,
  it MUST ignore it. If an acceptor does not support, does not
  understand, or is not allowed to use any of the proposed options
  with a specific originator, it may use the constant "Reject" or
  terminate the negotiation. The selection of a value not proposed
  MUST be handled as a protocol error.

I suggest inserting "by the initiator" before "as a protocol error".


6.2.2. Simple-value Negotiations

  Specifically, the two cases in which answers are OPTIONAL are:

     - The Boolean function is "AND" and the value "No" is
       received. The outcome of the negotiation is "No".

     - The Boolean function is "OR" and the value "Yes" is
       received. The outcome of the negotiation is "Yes".

You lost me here, can you provide an example or two?

In 6.3:

  The Login Phase MAY include a SecurityNegotiation stage and a
  LoginOperationalNegotiation stage and MUST include at least one of
  them, but the included stage MAY be empty except for the mandatory
  names.

Again, an example (or pointer) here would be useful, as I am not 
entirely clear what this mean.


  Security MUST be completely negotiated within the Login Phase. The

What is the meaning of the word "Security" in this case?

  use of underlying IPsec security is specified in Chapter 8 and in
  [RFC3723]. iSCSI support for security within the protocol only
  consists of authentication in the Login Phase.


  In some environments, a target or an initiator is not interested
  in authenticating its counterpart. It is possible to bypass

How?

  authentication through the Login request and response.

In 6.3.1:

      -Login Response with Login reject. This is an immediate
       rejection from the target that causes the connection to
       terminate and the session to terminate if this is the first
       (or only) connection of a new session. The T bit and the CSG
       and NSG fields are reserved.

What does "reserved" mean in this case?

In 6.3.2:

  It should be noted that the negotiation might also be directed by
  the target if the initiator does support security, but is not
  ready to direct the negotiation (propose options).

How can this be done?

In 6.3.5:

  Session timeout is an event defined to occur when the last
  connection state timeout expires and no tasks are waiting for
  reassignment. This takes the session to the FREE state (N6
  transition in the session state diagram).

Is the timeout implied or negotiated?

In 7.1.4:

  In the detailed description of the recover classes the
  mandating terms (MUST, SHOULD, MAY, etc.) indicate normative
  actions to be executed if the recovery class is supported and
  used.

How is such support shown/negotiated?


7.1.4.1. Recovery Within-command

     Header digest error, which manifests as a sequence reception
        timeout or a sequence error - dealt with as specified in
        Section 7.9, using the option of a recovery R2T.

Did you mean 7.9 or 7.8?
(Also check elsewhere in the document.)


7.1.4.2. Recovery Within-connection

  At the initiator, the following cases lend themselves to within-
  connection recovery:

     - Requests not acknowledged for a long time. Requests are
       acknowledged explicitly through ExpCmdSN or implicitly by
       receiving data and/or status. The initiator MAY retry non-
       acknowledged commands as specified in Retry an.

Sorry, I didn't get what "Retry an" is.

In 7.2.2:

  In reassigning connection allegiance for a command, the targets
  SHOULD continue the command from its current state. For example,
  when reassigning read commands, the target SHOULD take advantage
  of the ExpDataSN field provided by the Task Management function
  request (which must be set to zero if there was no data transfer)
  and bring the read command to completion by sending the remaining
  data and sending (or resending) the status. ExpDataSN
  acknowledges all data sent up to, but not including, the Data-In
  PDU and or R2T with DataSN (or R2TSN) equal to ExpDataSN. However,
  targets may choose to send/receive all unacknowledged data or all
  of the data on a reassignment of connection allegiance if unable
  to recover or maintain accurate an state.

Nit: Should "an" be dropped?

7.14. Connection Failures

  iSCSI can keep a session in operation if it is able to
  keep/establish at least one TCP connection between the initiator
  and the target in a timely fashion. Targets and/or initiators may
  recognize a failing connection by either transport level means
  (TCP), a gap in the command sequence number, a response stream
  that is not filled for a long time, or by a failing iSCSI NOP
  (acting as a ping). The latter MAY be used periodically to
  increase the speed and likelihood of detecting connection
  failures. Initiators and targets MAY also use the keep-alive
  option on the TCP connection

I think TCP keep-alive option needs a reference here.

  to enable early link failure
  detection on otherwise idle links.

In 9.2.1:

The first mentioning of RADIUS needs an Informative reference.


In 9.3.1:

- HMAC-SHA1 MUST be implemented [RFC2404].

RFC 2404 seems to define HMAC-SHA-1-96, not HMAC-SHA1.

9.3.2. Confidentiality

  The NULL encryption algorithm MUST also be implemented.

I find it odd that the section talks about how weak DES is and then 
requires NULL encryption to be supported. What is the reason for this?

9.3.3. Policy, Security Associations, and Cryptographic Key
        Management

     - When digital signatures are used to achieve authentication,
       an IKE negotiator SHOULD use IKE Certificate Request
       Payload(s) to specify the certificate authority. IKE
       negotiators SHOULD check the pertinent Certificate
       Revocation List (CRL) before accepting a PKI certificate for
       use in IKE authentication procedures.

What are the reasons for these requirements being SHOULD level (as 
opposed to MUST level)?

  - The following identification type requirements apply to IKEv1.
    ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports
    IPv6) and ID_FQDN Identification Types MUST be supported;
    ID_USER_FQDN SHOULD be supported. The IP Subnet, IP Address
    Range, ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types
    SHOULD NOT be used. The ID_KEY_ID Identification Type MUST NOT
    be used.

It would be good to know the reason for the last SHOULD NOT and the last 
MUST NOT.


10.5. Synch and Steering Layer and Performance

  While a synch and steering layer is optional,

Is this section defining "synch and steering layer"? I found the use of 
this term confusing.

  an initiator/target
  that does not have it working against a target/initiator that
  demands synch and steering may experience performance degradation
  caused by packet reordering and loss. Providing a synch and
  steering mechanism is recommended for all high-speed
  implementations.

10.6.1. Determining the Proper ErrorRecoveryLevel

     Probability of transport layer "checksum escape".

Is this a well known term and if it is, what does it mean?


11.3.1. Flags and Task Attributes (byte 1)

     bit 3-4 Reserved.

Here and everywhere else in the document: what does it mean "reserved"?
Do you mean "MUST be set to zero when sent, MUST be ignored when received"?

11.4.4. SNACK Tag

   For a detailed discussion on R-Data SNACK see SNACK.

Is the last "SNACK" supposed to be a proper section reference?

11.4.5.3. SCSI REPORT LUNS and Residual Overflow

  If the Expected Data Transfer Length (EDTL) in the iSCSI header of
  the SCSI Command PDU for a REPORT LUNS command is set to at least
  as large as that ALLOCATION LENGTH, the SCSI layer truncation
  prevents an iSCSI Residual Overflow from occurring. A SCSI
  initiator can detect that such truncation has occurred via other
  information at theS CSI layer. The rest of the Section elaborates

s/theS CSI/the SCSI

  this required behavior.

11.9.2. AsyncVCode

   AsyncVCode is a vendor specific detail code that is only valid if
   the AsyncEvent field indicates a vendor specific event. Otherwise,
   it is reserved.

Is there an IANA registry for these?


11.13.8. Login Parameters

  Keys in Section 12, only need to be
  supported when the function to which they refer is mandatory to
  implement.

How is this decided?


12.1. AuthMethod

   Use: During Login - Security Negotiation
   Senders: Initiator and Target
   Scope: connection

   AuthMethod = <list-of-values>

   The main item of security negotiation is the authentication method
   (AuthMethod).

  The authentication methods that can be used (appear in the list-
  of-values) are either those listed in the following table or are
  vendor-unique methods:

Is there an IANA registry for this?


12.1.2. Secure Remote Password (SRP)

  For SRP [RFC2945], the initiator MUST use:

      SRP_U=<U> TargetAuth=Yes     /* or TargetAuth=No */

  The target MUST answer with a Login reject with the "Authorization
  Failure" status or reply with:

  SRP_GROUP=<G1,G2...> SRP_s=<s>

How are elements delemited on the wire?

12.1.3. Challenge Handshake Authentication Protocol (CHAP)

  For CHAP [RFC1994], the initiator MUST use:

     CHAP_A=<A1,A2...>

As above: How are elements delemited on the wire?

  To guarantee interoperability, initiators MUST always offer it as
  one of the proposed algorithms.

"Offer" or "support"? Most Apps protocols describe support, not 
necessarily requiring that
the mandatory-to-implement is enabled in a particular server.



--------------060906080604040201090209-- From alexey.melnikov@isode.com Wed Oct 3 07:04:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBC021F8593 for ; Wed, 3 Oct 2012 07:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.279 X-Spam-Level: X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=0.320, 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 QFwcVVxJl5k6 for ; Wed, 3 Oct 2012 07:04:52 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 0616C21F868A for ; Wed, 3 Oct 2012 07:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1349273091; d=isode.com; s=selector; i=@isode.com; bh=EcQWJwiK8Ldm7pLf+42hsU5jhs+3g/+qyGi8UXsHP2g=; 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=vjtNFXIyUkSqxfaROPfzwlG8BZ0T4Wlt8MzAeCWqLNGesT6q2LPvWos+y45bCfhN7gfRwp W7DyjqpkFTS5/a/3W5HiXevW/ajfWgMg0yeUrjGEjB/lW89y1+O1FkoiM0JWOIShZ77HMj K4YKXfRF8wGbz8MUGQjyYX6ESXPsXgM=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 3 Oct 2012 15:04:51 +0100 Message-ID: <506C4605.4060001@isode.com> Date: Wed, 03 Oct 2012 15:04:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Pete Resnick References: <506B1B6E.9010503@qti.qualcomm.com> In-Reply-To: <506B1B6E.9010503@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 14:04:53 -0000 On 02/10/2012 17:50, Pete Resnick wrote: > Folks, I'm having trouble discerning consensus from this conversation, > so I want to simplify a bit. Currently, IANA is requiring Expert > Review for *all* registrations, including things published as RFCs. > That's not what 3864 *says* to do: It is quite clear (whatever the > intent) that RFCs (whatever stream) don't go for Expert Review: > > The registration template is submitted for incorporation in one of > the IANA message header field repositories by *one of the following > methods*: > > > And the two methods specified are "RFC" and "Expert Review". > > So, here are the choices: (And I do *not* want anybody to simply > choose one; see below.) > > a) IANA should continue requiring Expert Review for all registrations. I think doing a) is fine as a stop-gap, as the replacement RFC will be done very quickly, right ;-). I don't think there are that many registrations coming from RFCs anyway for this to make a big difference. And nobody seem to complain about Expert Review for these... > b) IANA should require Expert Review for registrations that don't come > as part of an RFC. > > c) IANA should require Expert Review for registrations that don't come > as part of an IETF stream RFC. I am actually not convinced that registrations from other streams always have adequate reviews of this aspect, so I think Expert review for them is fine. Again, there are very very very few documents from other streams trying to register new header fields, so I don't think this is likely to make a significant difference. This is my preferred option. > For each of the above, I'd like to hear from folks answers of the form: > > - Yeah, this is OK with me. > - No, this would be actively bad and can not be what we tell IANA is > the current policy. > > Of course, if you say "actively bad", I'd also like to hear the > reason. Potential reasons are "that's not what 3864 says and not > following the rules is bad" or "that will let bad things be > registered" or "that will slow down important things from being > registered in a timely fashion". > > The "actively bad" answers are the ones I am most interested in. > > And please keep in mind that we are telling IANA what the policy will > be until we write a new document that is clearer about our intent. > This is a stop-gap until then. From ned.freed@mrochek.com Wed Oct 3 09:41:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A9821F866B for ; Wed, 3 Oct 2012 09:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 69Cnj1Rz5eFX for ; Wed, 3 Oct 2012 09:41:16 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE2E21F865B for ; Wed, 3 Oct 2012 09:41:16 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKZ8QK8A0G004CSW@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 3 Oct 2012 09:36:13 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKWD2NXQC00006TF@mauve.mrochek.com>; Wed, 3 Oct 2012 09:36:10 -0700 (PDT) Message-id: <01OKZ8QICJL40006TF@mauve.mrochek.com> Date: Wed, 03 Oct 2012 08:01:39 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 03 Oct 2012 09:04:36 -0400" <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> To: John C Klensin Cc: Pete Resnick , Ned Freed , Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 16:41:17 -0000 > --On Tuesday, October 02, 2012 15:21 -0700 Ned Freed > wrote: > >> a) IANA should continue requiring Expert Review for all > >> registrations. > > > > Actively bad. Waste of resources and too high a barrier. It > > doesn't help > > that it isn't what the rules say. > > > >> b) IANA should require Expert Review for registrations that > >> don't come as part of an RFC. > > > > OK with me. And as I said before, this needs to focus on the > > registration, not > > what it describes. That can be total crap. In fact the ones > > describing complete > > crap are sometimes the ones that are important, because I > > haven't found that > > customers demanding interoperability with something find "but > > it's crap" to be > > an acceptable excuse. > > > >> c) IANA should require Expert Review for registrations that > >> don't come as part of an IETF stream RFC. > > > > Actively bad. These documents have received sufficient review > > by the time > > they get this far, there is no need to require more. > Ned, > I'm not sure we disagree, but let me explain what I was trying > to say in case it helps. I think there's some disagreement on some specific points, but I doubt these points are worth the time we're spending on them. > (0) For the present/immediate situation, I believe that Graham > should send in a signoff "for the avoidance of doubt", IANA > should observe that it has _both_ an draft RFC and an Expert > signoff in hand, they should smile happily, and we should move > on. When good sense is working, I don't think we should be > trying to invent hair-splitting rules to solve a non-problem, > especially on an urgent basis. I don't think that's really necessary and probably a waste, and it isn't what was called for, but the overarching point you made - that this just isn't that big a deal - overrides any interest I have in arguing about it further. > (1) At the risk of drifting out of the Header Registry-specific > discussion, I think it would be wise to revise/update RFC 5226 > to _require_ that any document that specifies "Expert Review" > contain a statement about what that review is supposed to cover. I have no problem with doing this, but on reflection, I doubt that it will solve the problem. I think this is mostly a matter of attitude, and attitudes are hard to adjust with text in documents. These are "our" registries, and as such we want them to be "good" registries. And it's easy to take "good" as meaning "not full of junky crap". But that's the problem: This is a case of a registry that *needs* to be full of junky crap. Because there is an absolutely staggering amount of junky crap out there. A lot of it is noise and can be ignored, but some of it isn't. And it would sure be nice if we could capture some of that subset - even if that exposes us to registering a bunch of useless stuff - somewhere. And this cuts both ways: In some sense it doesn't matter what Graham or whoever does the reviews does, because it's the perception of difficulty that determines whether or not people bother. We saw this in the early days of media types, where the reality was IANA would let pretty much anhything through, but since the rules looked difficult, people didn't try (and stated publicly that this was in fact what they were (not) doing). And again, just as the effort to fix the media type registry in some sense came too late, it's probably too late to really solve this problem for headers. (In fact the lateness of the creation of the registry probably made it impossible from the get-go.) So this is really something that we need to keep in mind for the next time, because there's bound to be one. > Just as you suggest there are different types of registries with > different purposes, I think there are differences among reviews > for coherence, for accuracy, for conformity to a particular set > or rules or guidelines, for taste, etc. It would probably also > be useful for a 5226bis to divide Expert Review into two > categories: "expert consultation required" and "expert approval > required", where the former would cause IANA to ask the Expert > "have you looked at this and delivered any comments" and not "is > this ok". In the former case, the Expert Review is definitely > non-blocking even though it might result in a short delay while > the proposer decides whether or not to revise the > application/request. I hope we can trust the IESG (reinforced > by a few appeals if needed) to both enforce such a specification > requirement and to select and retain only those experts who are > willing to toe the line. All good ideaas. > (2) Graham has, as far as I can tell, been applying exactly the > test for coherency that we are advocating. While we might want > to give guidance to his potential successors, we are probably in > an "if it ain't broke, don't fix it" situation right now. See above. I don't think Graham's actions were ever part of the problem. > (3) The reason I'm advocating having the Expert take a look at > _all_ potential new entries in this particular registry is that > Graham (or you, or me, or most or all of the participants in > this discussion) might have a better eye for what is or is not > coherent than the potential registrant of, e.g., "X-FUSSP:" or > an ISE, IAB, IRTF, or even IETF review process that is > concentrating on other things. As long as the Expert is just an > extra set of skilled eyes looking at the registration request > and doesn't have to do much more than confirm that he or she has > looked at it, and as long as the IESG is willing to deal with > non-feasant Experts, I think such a review requirement falls > into the "harmless at worst" category. That's a valid point, although to be fair, I'd say that the FUSSP risk is greater in the indepedent stream submission process than in the header registry. Ned From john@jlc.net Wed Oct 3 10:18:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A214421F8495 for ; Wed, 3 Oct 2012 10:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.289 X-Spam-Level: X-Spam-Status: No, score=-106.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 tOckUEKJ6wct for ; Wed, 3 Oct 2012 10:18:25 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0EC21F847A for ; Wed, 3 Oct 2012 10:18:25 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id E618D33C22; Wed, 3 Oct 2012 13:18:24 -0400 (EDT) Date: Wed, 3 Oct 2012 13:18:24 -0400 From: John Leslie To: Ned Freed Message-ID: <20121003171824.GB97796@verdi> References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01OKZ8QICJL40006TF@mauve.mrochek.com> User-Agent: Mutt/1.4.1i Cc: Pete Resnick , Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 17:18:28 -0000 Ned Freed wrote: >... > I think there's some disagreement on some specific points, but I doubt > these points are worth the time we're spending on them. +1 >... > These are "our" registries, and as such we want them to be "good" > registries. And it's easy to take "good" as meaning "not full of > junky crap". > > But that's the problem: This is a case of a registry that *needs* to be > full of junky crap. Because there is an absolutely staggering amount of > junky crap out there... +1 This doesn't deserve much more discussion; but I'd like to put in a plug for either 1) somebody volunteers to write the RFC to update 3864, or 2) we encourage IANA to make sure Expert Review is no more gating than 3864 calls for it to be. There is certainly no problem if IANA wants to ask the Expert to review _anything_ proposed for any registry and pass those comments to the RFC Editor. If somebody does volunteer to update 3864, I have no strong preference which path they take. IMHO, the horse left the barn so long ago that it's not worth the effort to try to fix this. -- John Leslie From barryleiba.mailing.lists@gmail.com Wed Oct 3 10:39:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3932721F864D for ; Wed, 3 Oct 2012 10:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.975 X-Spam-Level: X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=0.002, 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 W4ZkOsTvGSjS for ; Wed, 3 Oct 2012 10:39:00 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2A821F8647 for ; Wed, 3 Oct 2012 10:38:59 -0700 (PDT) Received: by lbok13 with SMTP id k13so7208238lbo.31 for ; Wed, 03 Oct 2012 10:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=+EPpXMXsHRO76uZyxwLYNzTLb3mK2r8Ms7USWGhOp6A=; b=Hc8oIrHt/IGI2fGxmhmnZvP/AYP3F2dOuGgJGhBInmjyxavzIWRuf42g1lp0ec5nta KfSnLCpv8AiEkvYHZzS0KcQ3vfUnB4LhM9mCSbcnJ8zSiqtodmYNI4TlRIBAh2y1U1+P MZ8utcYvP93N6pA4ckVuxZVFmmyOXzSjoIiXfwex+BPxon6hXi3BJQwL2RhcAtqTqoHN +oPtlGYmKV5NVZ6HMEcOFPGGyIhgFvB/FsgsDUpKym1bED8Q7FIuTHcFP17tVrilGslg dwjRSByAokFY9VwvU6VPO7nqn73mSyeREHWXADxvkfJYy9JTatyzsmWmHu2eE6JX0qMF DwxA== MIME-Version: 1.0 Received: by 10.152.112.136 with SMTP id iq8mr2283032lab.18.1349285938826; Wed, 03 Oct 2012 10:38:58 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Wed, 3 Oct 2012 10:38:58 -0700 (PDT) In-Reply-To: <01OKZ8QICJL40006TF@mauve.mrochek.com> References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> Date: Wed, 3 Oct 2012 13:38:58 -0400 X-Google-Sender-Auth: ch9Ua8Jc5Jz88gbUHeyCBPl3VGs Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 17:39:01 -0000 Ned says... > These are "our" registries, and as such we want them to be "good" registries. > And it's easy to take "good" as meaning "not full of junky crap". > > But that's the problem: This is a case of a registry that *needs* to be full of > junky crap. Because there is an absolutely staggering amount of junky crap out > there. A lot of it is noise and can be ignored, but some of it isn't. And it > would sure be nice if we could capture some of that subset - even if that > exposes us to registering a bunch of useless stuff - somewhere. Indeed, and this is why I've been pushing for less-strict registration policies in general, and even more consideration of First Come, First Served. There are registries -- perhaps many of the first ones created, back when, and also a number since -- where we're handing out limited resources. If you want one bit out of eight or sixteen or 32 to be assigned to you, we'd better make sure you have a good case. Ethertypes and port numbers have that aspect, and also have interoperability issues. But when we're talking about long character strings that implementations can ignore at will, there's no reason to be strict, and, as Ned says, if we wind up with a registry full of stuff no one cares about, at least we have a list of what's out there so people can avoid colliding with it, and can perhaps find the documentation for something obscure when they look for it (though for that latter, Google may have supplanted IANA as the place to go). Whatever we decide for this case, I encourage everyone to consider this in the general situation: When you're writing IANA Considerations sections, and you're creating a new registry, and the resource you're registering has an essentially unlimited namespace, consider a registration policy that encourages registrations above one that makes it harder and is discouraging. Barry From john-ietf@jck.com Wed Oct 3 10:44:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D0321F8568 for ; Wed, 3 Oct 2012 10:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 UZs5we5psCqc for ; Wed, 3 Oct 2012 10:44:03 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9276B21F855F for ; Wed, 3 Oct 2012 10:44:02 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TJSzA-000Cp4-C1; Wed, 03 Oct 2012 13:43:52 -0400 Date: Wed, 03 Oct 2012 13:43:46 -0400 From: John C Klensin To: John Leslie , Ned Freed Message-ID: <89F10240F9835A7E12E9BA25@JcK-HP8200.jck.com> In-Reply-To: <20121003171824.GB97796@verdi> References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> <20121003171824.GB97796@verdi> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Pete Resnick , Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 17:44:03 -0000 --On Wednesday, October 03, 2012 13:18 -0400 John Leslie wrote: > Ned Freed wrote: >> ... >> I think there's some disagreement on some specific points, >> but I doubt these points are worth the time we're spending on >> them. > > +1 Agree to that too, but Pete felt a need to ask the question. >> ... >> These are "our" registries, and as such we want them to be >> "good" registries. And it's easy to take "good" as meaning >> "not full of junky crap". >> >> But that's the problem: This is a case of a registry that >> *needs* to be full of junky crap. Because there is an >> absolutely staggering amount of junky crap out there... > > +1 yep >... > There is certainly no problem if IANA wants to ask the > Expert to review _anything_ proposed for any registry and pass > those comments to the RFC Editor. >... > IMHO, the horse left the barn so long ago that it's not > worth the effort to try to fix this. Yes. But part of what started this discussion (oversimplified for brevity) is that a standards-track document that specified some registrations went in. During Last Call, IANA essentially said "registry says 'Expert Review' and we haven't heard from the expert". That is ok; it is their job. However, that is precisely why I recommended that Graham simply do a pro-forma review and send IANA a note that says "yes, I've reviewed this and it is ok". Silly? Yes. Should it be unnecessary? IMO, also yes. But it gets the issue completely out of the critical path for that document and lets us have any discussion we need to have after there is actually a draft 3864bis and/or 5226bis (and, yes, we should be discussing parts of this in the context of draft-leiba-cotton-iana-5226bis) in front of us. john From john@jck.com Wed Oct 3 11:01:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036B321F8566 for ; Wed, 3 Oct 2012 11:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OakB6nmkhwnE for ; Wed, 3 Oct 2012 11:01:03 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7494421F855F for ; Wed, 3 Oct 2012 11:01:03 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TJTFm-000CsR-0r; Wed, 03 Oct 2012 14:01:02 -0400 Date: Wed, 03 Oct 2012 14:00:56 -0400 From: John C Klensin To: Barry Leiba , Apps Discuss Message-ID: In-Reply-To: References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 18:01:04 -0000 --On Wednesday, October 03, 2012 13:38 -0400 Barry Leiba wrote: >... > Whatever we decide for this case, I encourage everyone to > consider this in the general situation: When you're writing > IANA Considerations sections, and you're creating a new > registry, and the resource you're registering has an > essentially unlimited namespace, consider a registration > policy that encourages registrations above one that makes it > harder and is discouraging. Barry, Violent agreement. However, I think there is a role for two things with at least some registries, neither of which makes registration hard. (1) A list/ description of things that ought to ("SHOULD" ?) be included with the registration if possible, making sure that is a different list from whatever minimal stuff we absolutely insist on. (2) An Expert _Review_ process (not an Expert Approval one), focused more on clarity and coherency than on technical merit, that gives someone with some perspective and experience an opportunity to read the proposed registration and provide comments about how it might be improved or clarified. If those who request the registration ignore the list and pay no attention to the advice, we are still better off than without the registration. But, for people who feel cooperative as long as the process isn't too "hard", it will result in more coherent and complete registrations. But I think we need to be careful to avoid discarding the baby with the bathwater. john From presnick@qti.qualcomm.com Wed Oct 3 11:22:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4370411E8097 for ; Wed, 3 Oct 2012 11:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 9qS-bwYBIr-O for ; Wed, 3 Oct 2012 11:22:51 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8D30A11E8091 for ; Wed, 3 Oct 2012 11:22:51 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6854"; a="242992423" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 03 Oct 2012 11:22:51 -0700 X-IronPort-AV: E=Sophos;i="4.80,528,1344236400"; d="scan'208";a="162818184" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Oct 2012 10:39:53 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 3 Oct 2012 10:39:52 -0700 Message-ID: <506C7869.7080209@qti.qualcomm.com> Date: Wed, 3 Oct 2012 10:39:53 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Apps Discuss References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> In-Reply-To: <01OKYGEAYE9A0006TF@mauve.mrochek.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 18:22:52 -0000 On 10/2/12 10:28 AM, John C Klensin wrote: >> b) IANA should require Expert Review for registrations that >> > don't come as part of an RFC. >> > - Actively bad unless agreements are made with other streams, > especially the Independent one, about considering the Expert > among the document reviewers. We really need to be sure someone > with expertise in the subject matter looks at these things. On 10/2/12 3:21 PM, Ned Freed wrote: >> a) IANA should continue requiring Expert Review for all registrations. > > Actively bad. Waste of resources and too high a barrier. It doesn't help > that it isn't what the rules say. > > [...] >> c) IANA should require Expert Review for registrations that don't come >> as part of an IETF stream RFC. > > Actively bad. These documents have received sufficient review by the time > they get this far, there is no need to require more. Heh. OK. That worked out well. :-/ Let me make a suggestion to see if we can at least set aside this deadlock for the moment: The IESG gets a crack at all RFCs anyway: All IETF documents come through regular Last Call and IESG Evaluation, and IAB, IRTF, and Independent Submissions come through the IESG for Conflict Review. Since the 3864 appears to say "Either publish an RFC or get Expert Review", we could simply tell IANA, "If it's an RFC, you don't have to check." That gets IANA out of the confusion they are currently in. Then, while this group is figuring out what they want the actual policy to be, the Apps ADs will take the responsibility to either check the templates, or toss them over the wall to Graham to check. Does anyone object to going forward that way? Either way, we need the conversation about what the policy *should* be to complete in short order. Glad to take that discussion to another list if it needs to be. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From ned.freed@mrochek.com Wed Oct 3 11:29:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D6321F8555 for ; Wed, 3 Oct 2012 11:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 RyZG6qEuIvT2 for ; Wed, 3 Oct 2012 11:29:29 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3E71621F8562 for ; Wed, 3 Oct 2012 11:29:29 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKZCJAL1LS009I2D@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 3 Oct 2012 11:24:53 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKWD2NXQC00006TF@mauve.mrochek.com>; Wed, 3 Oct 2012 11:24:51 -0700 (PDT) Message-id: <01OKZCJ99MZU0006TF@mauve.mrochek.com> Date: Wed, 03 Oct 2012 11:23:58 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 03 Oct 2012 10:39:53 -0700" <506C7869.7080209@qti.qualcomm.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <506C7869.7080209@qti.qualcomm.com> To: Pete Resnick Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 18:29:29 -0000 > On 10/2/12 10:28 AM, John C Klensin wrote: > >> b) IANA should require Expert Review for registrations that > >> > don't come as part of an RFC. > >> > > - Actively bad unless agreements are made with other streams, > > especially the Independent one, about considering the Expert > > among the document reviewers. We really need to be sure someone > > with expertise in the subject matter looks at these things. > On 10/2/12 3:21 PM, Ned Freed wrote: > >> a) IANA should continue requiring Expert Review for all registrations. > > > > Actively bad. Waste of resources and too high a barrier. It doesn't help > > that it isn't what the rules say. > > > > [...] > >> c) IANA should require Expert Review for registrations that don't come > >> as part of an IETF stream RFC. > > > > Actively bad. These documents have received sufficient review by the time > > they get this far, there is no need to require more. > Heh. OK. That worked out well. :-/ > Let me make a suggestion to see if we can at least set aside this > deadlock for the moment: > The IESG gets a crack at all RFCs anyway: All IETF documents come > through regular Last Call and IESG Evaluation, and IAB, IRTF, and > Independent Submissions come through the IESG for Conflict Review. Since > the 3864 appears to say "Either publish an RFC or get Expert Review", we > could simply tell IANA, "If it's an RFC, you don't have to check." That > gets IANA out of the confusion they are currently in. Then, while this > group is figuring out what they want the actual policy to be, the Apps > ADs will take the responsibility to either check the templates, or toss > them over the wall to Graham to check. > Does anyone object to going forward that way? That's more or less how I expected it to work in practice. So yes, this is fine with me. Ned From john-ietf@jck.com Wed Oct 3 11:32:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE7D21F8562 for ; Wed, 3 Oct 2012 11:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 LCAkIbQexegQ for ; Wed, 3 Oct 2012 11:32:51 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5805721F858F for ; Wed, 3 Oct 2012 11:32:51 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TJTkX-000CwW-U5; Wed, 03 Oct 2012 14:32:49 -0400 Date: Wed, 03 Oct 2012 14:32:44 -0400 From: John C Klensin To: Pete Resnick , Apps Discuss Message-ID: <0FB38DF0FE9DED30FC0AE501@JcK-HP8200.jck.com> In-Reply-To: <506C7869.7080209@qti.qualcomm.com> References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <506C7869.7080209@qti.qualcomm.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 18:32:52 -0000 --On Wednesday, October 03, 2012 10:39 -0700 Pete Resnick wrote: >> Actively bad. These documents have received sufficient review >> by the time they get this far, there is no need to require >> more. > > Heh. OK. That worked out well. :-/ Doubly so because I believe that Ned and I are in agreement except on details that really are not important. > Let me make a suggestion to see if we can at least set aside > this deadlock for the moment: > > The IESG gets a crack at all RFCs anyway: All IETF documents > come through regular Last Call and IESG Evaluation, and IAB, > IRTF, and Independent Submissions come through the IESG for > Conflict Review. Since the 3864 appears to say "Either publish > an RFC or get Expert Review", we could simply tell IANA, "If > it's an RFC, you don't have to check." That gets IANA out of > the confusion they are currently in. Then, while this group is > figuring out what they want the actual policy to be, the Apps > ADs will take the responsibility to either check the > templates, or toss them over the wall to Graham to check. Wfm if IANA will accept it. Consistent with the "just throw everything to Graham and let him bless it and throw it back" suggestion I've made a couple of times now. >... john From ned.freed@mrochek.com Wed Oct 3 14:26:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4E51F0C3E for ; Wed, 3 Oct 2012 14:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 1uqEDeTBka9v for ; Wed, 3 Oct 2012 14:26:15 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4698F1F0421 for ; Wed, 3 Oct 2012 14:26:15 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKZIOH21Y800C4VX@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 3 Oct 2012 14:20:52 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKWD2NXQC00006TF@mauve.mrochek.com>; Wed, 3 Oct 2012 14:20:49 -0700 (PDT) Message-id: <01OKZIOEWAT20006TF@mauve.mrochek.com> Date: Wed, 03 Oct 2012 14:18:28 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 28 Sep 2012 10:47:21 +0100" <50657229.4070509@ninebynine.org> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <2747A13381D34945560A89E0@JcK-HP8200.jck.com> <01OKQ27GEZGC0006TF@mauve.mrochek.com> <50657229.4070509@ninebynine.org> To: Graham Klyne Cc: Mark Nottingham , Ned Freed , Apps Discuss Subject: Re: [apps-discuss] Registration review (was: Registration policy for the Permanent Message Header Field Names registry) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 21:26:15 -0000 > Ned, > re. "The *description* needs to be competent." > I think you make a very important observation here, and one that maybe has not > been sufficiently emphasized. I shall try to keep this more firmly in mind when > I undertake future reviews. Before this whole thing whizzes by, I want to note that John Klensin has the original insight into this, not me. And keeping this in mind when reviewing is an excellent idea. It's not exactly comparable, but I'm going to try and do the same with media types. Ned From john-ietf@jck.com Wed Oct 3 18:07:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751A721F860F for ; Wed, 3 Oct 2012 18:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 HcsOmBOhmofL for ; Wed, 3 Oct 2012 18:07:05 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id F22A121F8616 for ; Wed, 3 Oct 2012 18:07:04 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TJZtx-000DaQ-I5; Wed, 03 Oct 2012 21:06:57 -0400 Date: Wed, 03 Oct 2012 21:06:51 -0400 From: John C Klensin To: Ned Freed , Graham Klyne Message-ID: In-Reply-To: <01OKZIOEWAT20006TF@mauve.mrochek.com> References: <2747A13381D34945560A89E0@JcK-HP8200.jck.com> <01OKQ27GEZGC0006TF@mauve.mrochek.com> <50657229.4070509@ninebynine.org> <01OKZIOEWAT20006TF@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Mark Nottingham , Apps Discuss Subject: Re: [apps-discuss] Registration review (was: Registration policy for the Permanent Message Header Field Names registry) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 01:07:05 -0000 --On Wednesday, October 03, 2012 14:18 -0700 Ned Freed wrote: >... > Before this whole thing whizzes by, I want to note that John > Klensin > has the original insight into this, not me. Thanks Ned. I'm happy to accept credit for introducing it into this discussion, but the insight was really Jon Postel's, originally IIR, in the context of the Port Number registry. For a number of reasons, I think it is helpful to put what most of us seem to be saying now in the context of returning to well-establish and tested policies after an intermediate period when the community probably went too far down the road of "registration as quality control" (or worse), rather than inventing a new model. best, john From duerst@it.aoyama.ac.jp Wed Oct 3 19:00:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05491F0C8A for ; Wed, 3 Oct 2012 19:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.24 X-Spam-Level: X-Spam-Status: No, score=-101.24 tagged_above=-999 required=5 tests=[AWL=-1.450, 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 LBLaYwgANlWv for ; Wed, 3 Oct 2012 19:00:15 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id D3CE71F0C80 for ; Wed, 3 Oct 2012 19:00:14 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q942041N023362 for ; Thu, 4 Oct 2012 11:00:04 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 71ab_aca0_36d80efc_0dc7_11e2_b387_001d096c5782; Thu, 04 Oct 2012 11:00:04 +0900 Received: from [IPv6:::1] ([133.2.210.1]:57366) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 4 Oct 2012 11:00:03 +0900 Message-ID: <506CED96.5030802@it.aoyama.ac.jp> Date: Thu, 04 Oct 2012 10:59:50 +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: John C Klensin References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <506C7869.7080209@qti.qualcomm.com> <0FB38DF0FE9DED30FC0AE501@JcK-HP8200.jck.com> In-Reply-To: <0FB38DF0FE9DED30FC0AE501@JcK-HP8200.jck.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Pete Resnick , Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 02:00:15 -0000 On 2012/10/04 3:32, John C Klensin wrote: > --On Wednesday, October 03, 2012 10:39 -0700 Pete Resnick > wrote: >> Let me make a suggestion to see if we can at least set aside >> this deadlock for the moment: >> >> The IESG gets a crack at all RFCs anyway: All IETF documents >> come through regular Last Call and IESG Evaluation, and IAB, >> IRTF, and Independent Submissions come through the IESG for >> Conflict Review. Since the 3864 appears to say "Either publish >> an RFC or get Expert Review", we could simply tell IANA, "If >> it's an RFC, you don't have to check." That gets IANA out of >> the confusion they are currently in. Then, while this group is >> figuring out what they want the actual policy to be, the Apps >> ADs will take the responsibility to either check the >> templates, or toss them over the wall to Graham to check. > > Wfm if IANA will accept it. Consistent with the "just throw > everything to Graham and let him bless it and throw it back" > suggestion I've made a couple of times now. We all agree that we are discussing minor details. But the above proposal ignores the following facts: 1) In practice, it's the same as up to now (Graham has a look at everything) 2) IANA asked the ADs, so we should assume that it will do what the the ADs tell it. 3) IANA is much more efficient, and less error-prone at asking the reviewer than the ADs. If we can, we should have IANA do the work, not the ADs. Regards, Martin. From duerst@it.aoyama.ac.jp Wed Oct 3 21:38:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F2921F853B for ; Wed, 3 Oct 2012 21:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.877 X-Spam-Level: X-Spam-Status: No, score=-100.877 tagged_above=-999 required=5 tests=[AWL=-1.687, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6, 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 Io2zVNTKgX2s for ; Wed, 3 Oct 2012 21:38:00 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 34BF01F0C8F for ; Wed, 3 Oct 2012 21:37:59 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q944bkf9004317 for ; Thu, 4 Oct 2012 13:37:47 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 79d8_9d4f_3edc4666_0ddd_11e2_8964_001d096c566a; Thu, 04 Oct 2012 13:37:46 +0900 Received: from [IPv6:::1] ([133.2.210.1]:37937) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 4 Oct 2012 13:37:45 +0900 Message-ID: <506D128D.7030401@it.aoyama.ac.jp> Date: Thu, 04 Oct 2012 13:37:33 +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: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: [apps-discuss] One more idea to make registrations easier (was: Re: Registration policy for the Permanent Message Header Field Names registry) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 04:38:01 -0000 On 2012/10/04 2:38, Barry Leiba wrote: > Whatever we decide for this case, I encourage everyone to consider > this in the general situation: When you're writing IANA Considerations > sections, and you're creating a new registry, and the resource you're > registering has an essentially unlimited namespace, consider a > registration policy that encourages registrations above one that makes > it harder and is discouraging. During this discussion, and based on my experience with helping to register media types from the W3C, and as a reviewer for charsets, I want to point out some other ideas on how to hopefully improve the review/registration process. Many registries have a process that can be summarized as "send it to the mailing list, then later send it to IANA". On paper, this two-step process looks like it's quite easy. But submitters easily forget the second step, or don't know how to judge when they can move on. For many registries, it would be great if that could be changed to "submit to IANA, they'll forward to the mailing list (they have to make sure they keep the submitter in the loop by cc'ing, I'm not sure IANA's systems are currently able to handle this.). A second point that I think is worth looking at is to give the expert reviewers the possibility (not duty) to fix some things by themselves. In many cases, it's easier to do a quick fix than to wait for the submitter to possibly goof up again. In these cases, insisting on the submitter to submit again is quite contraproductive in terms of registration rates. Of course, how often this gets used depends very much on the business of the registry and the issues at hand. Just some ideas. Regards, Martin. From duerst@it.aoyama.ac.jp Wed Oct 3 21:48:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798D621F84EB for ; Wed, 3 Oct 2012 21:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.107 X-Spam-Level: X-Spam-Status: No, score=-101.107 tagged_above=-999 required=5 tests=[AWL=-1.317, 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 HbP9o40bRwJY for ; Wed, 3 Oct 2012 21:48:36 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 83C8121F8489 for ; Wed, 3 Oct 2012 21:48:35 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q944mMwZ011777 for ; Thu, 4 Oct 2012 13:48:26 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 71ae_f438_b9c379ac_0dde_11e2_bf42_001d096c5782; Thu, 04 Oct 2012 13:48:22 +0900 Received: from [IPv6:::1] ([133.2.210.1]:55352) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 4 Oct 2012 13:48:21 +0900 Message-ID: <506D1508.1080206@it.aoyama.ac.jp> Date: Thu, 04 Oct 2012 13:48:08 +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: <506B1B6E.9010503@qti.qualcomm.com> <5539D2E291D44427BDF0A7E6@JcK-HP8200.jck.com> <506B8B9B.5090201@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Pete Resnick , Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 04:48:37 -0000 On 2012/10/03 11:06, Barry Leiba wrote: >> I'd strongly suggest that next time a >> similar question comes up, the powers that be first ask what the overall >> potential benefits and costs of opening a discussion are. As far as I'm >> aware, what's currently done has produced exactly zero wrong/problematic >> outputs, and hasn't been challenged by anybody affected. It may be a tiny >> bit more work for IANA, but they are highly optimized for this kind of work. >> On the other hand, this discussion has used time and space on this list >> which I'm sure could have been used for other, more productive discussions. >> [Sorry if this sounded like a rant, but I had to get that out.] > > No, that's a fair cop. On the other hand, though, the IETF works on > consensus. Pete and I certainly could have just made an executive > decision. For me, rough consensus is better. Of course I don't disagree with that. But just to make an example, I wouldn't want the ADs, or anybody else for that matter, to ask whether they should use a paperclip or a staple to hold together the pages of a draft they just printed out. The discussion of this issue has led to quite some good general insight, but in terms of actual changes, the result seems to be truly insignificant. If it was really considered necessary to get the list involved, a mail of the form "We instructed IANA to continue using paperclips. In case you think that's thoroughly wrong and cannot wait to be addressed/fixed until the document is updated, please say so." Regards, Martin. From GK@ninebynine.org Thu Oct 4 05:00:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312C121F867B for ; Thu, 4 Oct 2012 05:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOA-+R4zS0Bb for ; Thu, 4 Oct 2012 05:00:21 -0700 (PDT) Received: from relay9.mail.ox.ac.uk (relay9.mail.ox.ac.uk [163.1.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3102D21F8685 for ; Thu, 4 Oct 2012 05:00:21 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay9.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1TJk6B-0004uB-Up; Thu, 04 Oct 2012 13:00:15 +0100 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TJk6B-0005Ol-4C; Thu, 04 Oct 2012 13:00:15 +0100 Message-ID: <506D7380.1080406@ninebynine.org> Date: Thu, 04 Oct 2012 12:31:12 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: John C Klensin References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> <20121003171824.GB97796@verdi> <89F10240F9835A7E12E9BA25@JcK-HP8200.jck.com> In-Reply-To: <89F10240F9835A7E12E9BA25@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: Pete Resnick , Ned Freed , Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 12:00:22 -0000 On 03/10/2012 18:43, John C Klensin wrote: > Yes. But part of what started this discussion (oversimplified > for brevity) is that a standards-track document that specified > some registrations went in. During Last Call, IANA essentially > said "registry says 'Expert Review' and we haven't heard from > the expert". That is ok; it is their job. Oops, did I drop the ball somewhere? I *try* to respond to or acknowledge IANA requests promptly. If there's a weakness in the system, it's that emails sometimes get lost or buried in the wider deluge. Maybe that's something to look into, but I think it's a minor procedural issue that can probably be dealt with between IANA or IESG and the reviewer. #g From GK@ninebynine.org Thu Oct 4 05:00:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D921221F8690 for ; Thu, 4 Oct 2012 05:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPHfYtPAMjvm for ; Thu, 4 Oct 2012 05:00:25 -0700 (PDT) Received: from relay8.mail.ox.ac.uk (relay8.mail.ox.ac.uk [129.67.1.171]) by ietfa.amsl.com (Postfix) with ESMTP id D803A21F868A for ; Thu, 4 Oct 2012 05:00:24 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay8.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1TJk6A-0000os-RQ; Thu, 04 Oct 2012 13:00:14 +0100 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TJk6A-0005Ob-3e; Thu, 04 Oct 2012 13:00:14 +0100 Message-ID: <506D7191.5020002@ninebynine.org> Date: Thu, 04 Oct 2012 12:22:57 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: John C Klensin References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> In-Reply-To: <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: Pete Resnick , Ned Freed , Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 12:00:26 -0000 I'm sorry I've been out of this discussion the past few days. Mainly, I wanted to confirm that John's perspective here matches mine. One further small point: there have been a couple of comments about the cost of requiring review of header fields in standard-track RFC submissions: in practice there have been very few of these, and they require very little effort to review. The potential cost I perceive is introducing yet another decision point about whether or not a submission needs to be reviewed. #g -- On 03/10/2012 14:04, John C Klensin wrote: > > > --On Tuesday, October 02, 2012 15:21 -0700 Ned Freed > wrote: > >>> a) IANA should continue requiring Expert Review for all >>> registrations. >> >> Actively bad. Waste of resources and too high a barrier. It >> doesn't help >> that it isn't what the rules say. >> >>> b) IANA should require Expert Review for registrations that >>> don't come as part of an RFC. >> >> OK with me. And as I said before, this needs to focus on the >> registration, not >> what it describes. That can be total crap. In fact the ones >> describing complete >> crap are sometimes the ones that are important, because I >> haven't found that >> customers demanding interoperability with something find "but >> it's crap" to be >> an acceptable excuse. >> >>> c) IANA should require Expert Review for registrations that >>> don't come as part of an IETF stream RFC. >> >> Actively bad. These documents have received sufficient review >> by the time >> they get this far, there is no need to require more. > > Ned, > > I'm not sure we disagree, but let me explain what I was trying > to say in case it helps. > > (0) For the present/immediate situation, I believe that Graham > should send in a signoff "for the avoidance of doubt", IANA > should observe that it has _both_ an draft RFC and an Expert > signoff in hand, they should smile happily, and we should move > on. When good sense is working, I don't think we should be > trying to invent hair-splitting rules to solve a non-problem, > especially on an urgent basis. > > (1) At the risk of drifting out of the Header Registry-specific > discussion, I think it would be wise to revise/update RFC 5226 > to _require_ that any document that specifies "Expert Review" > contain a statement about what that review is supposed to cover. > Just as you suggest there are different types of registries with > different purposes, I think there are differences among reviews > for coherence, for accuracy, for conformity to a particular set > or rules or guidelines, for taste, etc. It would probably also > be useful for a 5226bis to divide Expert Review into two > categories: "expert consultation required" and "expert approval > required", where the former would cause IANA to ask the Expert > "have you looked at this and delivered any comments" and not "is > this ok". In the former case, the Expert Review is definitely > non-blocking even though it might result in a short delay while > the proposer decides whether or not to revise the > application/request. I hope we can trust the IESG (reinforced > by a few appeals if needed) to both enforce such a specification > requirement and to select and retain only those experts who are > willing to toe the line. > > (2) Graham has, as far as I can tell, been applying exactly the > test for coherency that we are advocating. While we might want > to give guidance to his potential successors, we are probably in > an "if it ain't broke, don't fix it" situation right now. > > (3) The reason I'm advocating having the Expert take a look at > _all_ potential new entries in this particular registry is that > Graham (or you, or me, or most or all of the participants in > this discussion) might have a better eye for what is or is not > coherent than the potential registrant of, e.g., "X-FUSSP:" or > an ISE, IAB, IRTF, or even IETF review process that is > concentrating on other things. As long as the Expert is just an > extra set of skilled eyes looking at the registration request > and doesn't have to do much more than confirm that he or she has > looked at it, and as long as the IESG is willing to deal with > non-feasant Experts, I think such a review requirement falls > into the "harmless at worst" category. > > best, > john > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From john-ietf@jck.com Thu Oct 4 05:43:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A56B21F85ED for ; Thu, 4 Oct 2012 05:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.121 X-Spam-Level: X-Spam-Status: No, score=-102.121 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 UIN7CKyHJdTg for ; Thu, 4 Oct 2012 05:43:42 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7F27921F85C7 for ; Thu, 4 Oct 2012 05:43:42 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TJkm9-000Euf-9R; Thu, 04 Oct 2012 08:43:37 -0400 Date: Thu, 04 Oct 2012 08:43:30 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Barry Leiba Message-ID: <87C87EFF1F4C984D99567920@JcK-HP8200.jck.com> In-Reply-To: <506D128D.7030401@it.aoyama.ac.jp> References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> <506D128D.7030401@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Apps Discuss Subject: Re: [apps-discuss] One more idea to make registrations easier (was: Re: Registration policy for the Permanent Message Header Field Names registry) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 12:43:43 -0000 --On Thursday, October 04, 2012 13:37 +0900 "\"Martin J. D=C3=BCrst\"" wrote: >... > Many registries have a process that can be summarized as "send > it to the mailing list, then later send it to IANA". On paper, > this two-step process looks like it's quite easy. But > submitters easily forget the second step, or don't know how to > judge when they can move on. >=20 > For many registries, it would be great if that could be > changed to "submit to IANA, they'll forward to the mailing > list (they have to make sure they keep the submitter in the > loop by cc'ing, I'm not sure IANA's systems are currently able > to handle this.). I would favor this generally, partially for a reason that Martin didn't mention: it would allow IANA to establish and maintain a tracking regime for requests. Such a tracking regime would act as a safeguard against the many ways that a request can fall through the cracks despite the best of intentions (I note Graham's recent comment about the possibility of email just getting lost in the general noise). Secondarily, it might provide a public record of pending requests which might reduce or eliminate the need for provisional registries in some cases. > A second point that I think is worth looking at is to give the > expert reviewers the possibility (not duty) to fix some things > by themselves. In many cases, it's easier to do a quick fix > than to wait for the submitter to possibly goof up again. In > these cases, insisting on the submitter to submit again is > quite contraproductive in terms of registration rates. Of > course, how often this gets used depends very much on the > business of the registry and the issues at hand. I'm more hesitant about this. On the other hand, if the Expert reviewer wants to propose some specific text or changes to the submitter and ask if it would be ok to apply them, I can't see any problem with that even under present procedures. best, john From john-ietf@jck.com Thu Oct 4 05:51:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC4421F8691 for ; Thu, 4 Oct 2012 05:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=-0.115, 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 gVGvoRnfly-q for ; Thu, 4 Oct 2012 05:51:56 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id E23F421F8674 for ; Thu, 4 Oct 2012 05:51:55 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TJku9-000EvM-2C; Thu, 04 Oct 2012 08:51:53 -0400 Date: Thu, 04 Oct 2012 08:51:45 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= Message-ID: <229B85F7B37BA79FD217824D@JcK-HP8200.jck.com> In-Reply-To: <506CED96.5030802@it.aoyama.ac.jp> References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <506C7869.7080209@qti.qualcomm.com> <0FB38DF0FE9DED30FC0AE501@JcK-HP8200.jck.com> <506CED96.5030802@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Pete Resnick , Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 12:51:56 -0000 --On Thursday, October 04, 2012 10:59 +0900 "\"Martin J. D=C3=BCrst\"" wrote: >... > We all agree that we are discussing minor details. But the > above proposal ignores the following facts: >=20 > 1) In practice, it's the same as up to now (Graham has a look > at everything) > 2) IANA asked the ADs, so we should assume that it will do > what the the ADs tell it. > 3) IANA is much more efficient, and less error-prone at asking > the reviewer than the ADs. If we can, we should have IANA do > the work, not the ADs. Yes. I've said variations on this in a few off-list notes but, IMO, the real disconnect here was that IANA felt obligated to _ask_ the IESG rather than asking Graham, getting his signoff, and then telling the IESG that they requested expert review for consistency with the registry spec and that all was well. I don't fault IANA for this -- I think "ask the IESG during Last Call review" is part of their rule structure as (at least implicitly) negotiated with the IESG.=20 So. as a result of everyone trying to do their jobs and follow procedures carefully, we've had a long discussion that could have been avoided if those procedures were a little more friendly to good sense and creativity. While this particular problem is about minor details, I think procedures that discourage application of good sense and creativity when they would efficiently facilitate a reasonable solution are a much bigger and more general issue. john From hallam@gmail.com Thu Oct 4 06:44:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7211521F86D6 for ; Thu, 4 Oct 2012 06:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=-1.854, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRC72pxKACv7 for ; Thu, 4 Oct 2012 06:44:46 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2BA021F8602 for ; Thu, 4 Oct 2012 06:44:45 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so617842oag.31 for ; Thu, 04 Oct 2012 06:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n/qYx/XyJ7DJrj7vbAUKzjhpDRJAdeZGrf/RuB2L3vM=; b=gcmr0t+Sz8gSgRpQy1sQ3YwkH2rNrtUkXWgO01SrnJ9Q6HCaAw56z3Z6D2diIyTt/b xzcLVoHfphkWC/OVHyVSnBuqHkaKrCIJVb6WugaHfbeSHglUvVkdAfStnEsD+TXi1oBe 7K7jkIa42vM9V0uGoJpW4gDh4AWFtzXp4feiJOWffryH94LZe0F5AbDWsie+hX492yiY Ij/aiw3sLX3F8EztPn4UQqwpwHqh9tgRLl/RjwP4ZFplqMInuTfrscPwmolDkrGc7UzE E4u8M57pD+poMzT/SICzBp/so7vmH2B7b1VbdmsHbmwedNPaqbyj71scXWaM9mYgqpd+ c93Q== MIME-Version: 1.0 Received: by 10.60.22.198 with SMTP id g6mr4257734oef.18.1349358285382; Thu, 04 Oct 2012 06:44:45 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Thu, 4 Oct 2012 06:44:45 -0700 (PDT) In-Reply-To: <87C87EFF1F4C984D99567920@JcK-HP8200.jck.com> References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> <506D128D.7030401@it.aoyama.ac.jp> <87C87EFF1F4C984D99567920@JcK-HP8200.jck.com> Date: Thu, 4 Oct 2012 09:44:45 -0400 Message-ID: From: Phillip Hallam-Baker To: John C Klensin Content-Type: multipart/alternative; boundary=e89a8fb2016e4662ab04cb3bf564 Cc: Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] One more idea to make registrations easier (was: Re: Registration policy for the Permanent Message Header Field Names registry) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 13:44:47 -0000 --e89a8fb2016e4662ab04cb3bf564 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable How about a web form with fields for the data in the template that people fill in. This could be recorded separately from the registry itself which would contain the reviewed data or it could just be a status flag thing. I am writing a draft for a HTTP header right now. Pretty much the only thing I care about with respect to the name is that nobody else has attempted to use it. We can bike shed whether it should be content-integrity, integrity, MAC, security or whatever if the proposal gets to WG stage. At this stage the only important thing is to avoid a collision and provide a pointer to the best available documentation in case people want to look it up. Bad documentation of registrations does not worry me a tenth as much as no registration. Bad or even missing documentation has a habit of getting fixed if people actually use a feature. It is also a pretty effective discouragement to implementors. The worst outcome for me is what happened with the SRV non-registry. The IETF did not set up a registry that made sense or registration processes that made sense. So now other people run a whole mess of registries that are incomplete and difficult to find. What comes top in Google serach on a given day should not determine the authoritative SRV registry. On Thu, Oct 4, 2012 at 8:43 AM, John C Klensin wrote: > > > --On Thursday, October 04, 2012 13:37 +0900 "\"Martin J. > D=FCrst\"" wrote: > > >... > > Many registries have a process that can be summarized as "send > > it to the mailing list, then later send it to IANA". On paper, > > this two-step process looks like it's quite easy. But > > submitters easily forget the second step, or don't know how to > > judge when they can move on. > > > > For many registries, it would be great if that could be > > changed to "submit to IANA, they'll forward to the mailing > > list (they have to make sure they keep the submitter in the > > loop by cc'ing, I'm not sure IANA's systems are currently able > > to handle this.). > > I would favor this generally, partially for a reason that Martin > didn't mention: it would allow IANA to establish and maintain a > tracking regime for requests. Such a tracking regime would act > as a safeguard against the many ways that a request can fall > through the cracks despite the best of intentions (I note > Graham's recent comment about the possibility of email just > getting lost in the general noise). Secondarily, it might > provide a public record of pending requests which might reduce > or eliminate the need for provisional registries in some cases. > > > A second point that I think is worth looking at is to give the > > expert reviewers the possibility (not duty) to fix some things > > by themselves. In many cases, it's easier to do a quick fix > > than to wait for the submitter to possibly goof up again. In > > these cases, insisting on the submitter to submit again is > > quite contraproductive in terms of registration rates. Of > > course, how often this gets used depends very much on the > > business of the registry and the issues at hand. > > I'm more hesitant about this. On the other hand, if the Expert > reviewer wants to propose some specific text or changes to the > submitter and ask if it would be ok to apply them, I can't see > any problem with that even under present procedures. > > best, > john > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --=20 Website: http://hallambaker.com/ --e89a8fb2016e4662ab04cb3bf564 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable How about a web form with fields for the data in the template that people f= ill in. This could be recorded separately from the registry itself which wo= uld contain the reviewed data or it could just be a status flag thing.

I am writing a draft for a HTTP header right now. Pretty muc= h the only thing I care about with respect to the name is that nobody else = has attempted to use it. We can bike shed whether it should be content-inte= grity, integrity, MAC, security or whatever if the proposal gets to WG stag= e. At this stage the only important thing is to avoid a collision and provi= de a pointer to the best available documentation in case people want to loo= k it up.

Bad documentation of registrations does not worry me a = tenth as much as no registration. Bad or even missing documentation has a h= abit of getting fixed if people actually use a feature. It is also a pretty= effective discouragement to implementors.


The worst outcome for me is what happene= d with the SRV non-registry. The IETF did not set up a registry that made s= ense or registration processes that made sense. So now other people run a w= hole mess of registries that are incomplete and difficult to find. What com= es top in Google serach on a given day should not determine the authoritati= ve SRV registry.



On Thu, O= ct 4, 2012 at 8:43 AM, John C Klensin <john-ietf@jck.com> wr= ote:


--On Thursday, October 04, 2012 13:37 +0900 "\"Martin J.
D=FCrst\"" <duerst@i= t.aoyama.ac.jp> wrote:

>...
> Many registries have a process that can be summarize= d as "send
> it to the mailing list, then later send it to IANA". On paper, > this two-step process looks like it's quite easy. But
> submitters easily forget the second step, or don't know how to
> judge when they can move on.
>
> For many registries, it would be great if that could be
> changed to "submit to IANA, they'll forward to the mailing > list (they have to make sure they keep the submitter in the
> loop by cc'ing, I'm not sure IANA's systems are currently = able
> to handle this.).

I would favor this generally, partially for a reason that Martin
didn't mention: it would allow IANA to establish and maintain a
tracking regime for requests. =A0Such a tracking regime would act
as a safeguard against the many ways that a request can fall
through the cracks despite the best of intentions (I note
Graham's recent comment about the possibility of email just
getting lost in the general noise). =A0Secondarily, it might
provide a public record of pending requests which might reduce
or eliminate the need for provisional registries in some cases.

> A second point that I think is worth looking at is to give the
> expert reviewers the possibility (not duty) to fix some things
> by themselves. In many cases, it's easier to do a quick fix
> than to wait for the submitter to possibly goof up again. In
> these cases, insisting on the submitter to submit again is
> quite contraproductive in terms of registration rates. Of
> course, how often this gets used depends very much on the
> business of the registry and the issues at hand.

I'm more hesitant about this. =A0On the other hand, if the Expert=
reviewer wants to propose some specific text or changes to the
submitter and ask if it would be ok to apply them, I can't see
any problem with that even under present procedures.

best,
=A0 john

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



--
= Website: http://hallambaker.com/
--e89a8fb2016e4662ab04cb3bf564-- From jasnell@gmail.com Thu Oct 4 11:55:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793771F0C96 for ; Thu, 4 Oct 2012 11:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.071 X-Spam-Level: X-Spam-Status: No, score=-4.071 tagged_above=-999 required=5 tests=[AWL=-0.473, 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 V3khc6uvWe0M for ; Thu, 4 Oct 2012 11:55:13 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8BA1F0C8E for ; Thu, 4 Oct 2012 11:55:12 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so3777628wib.13 for ; Thu, 04 Oct 2012 11:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=0ofe/NpEL7pVNhs1VMzDVm1yCPIK70l+puRtRVIMRyU=; b=ertu6D7M4WbNKUL6pMaHZkTUra9baBXHKHusxCNmxAVn6xi93W6NzydF6BXILkvlqr Mge/haBFVSUSsb9XSdjMsG19WymgvQWXEmWBYExhyZTC/Xqiw2HQNde5CohdqzhSLlVx zXKYBsxrAeTLqzMo8FXDYbyQHUbrA8BOLw+fdsuE1juaueHVBDpWo/hZZYViOyHLbp9y e8jbFakTey2cXXL7Yi/pz698o4nJ1GJ6WLbyTfQCa8eVbVAuJLn8VvnAggY+rSQhrNp1 06sb031zJ0fWZuezI8AV2Q90mIWV7FON2NURb+V6uWhAMGFTM0zVjlOHhTTJA+HXkTPB kBjQ== Received: by 10.180.79.103 with SMTP id i7mr14885399wix.13.1349376911553; Thu, 04 Oct 2012 11:55:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.4 with HTTP; Thu, 4 Oct 2012 11:54:51 -0700 (PDT) From: James M Snell Date: Thu, 4 Oct 2012 11:54:51 -0700 Message-ID: To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d041825187b331a04cb404be0 Subject: [apps-discuss] Updated JSON 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, 04 Oct 2012 18:55:13 -0000 --f46d041825187b331a04cb404be0 Content-Type: text/plain; charset=UTF-8 I have refreshed the JSON Merge Patch draft... http://www.ietf.org/id/draft-snell-merge-patch-04.txt This is an alternative/complement to JSON-Patch derived from a number of different specific implementations in the wild. Example, given the original document: { "a": 1, "b": 2, "c": 3, "d": { "e": 4, "f": 5, "g": 6 } } Merge-patch allows us to perform a partial modification by example, rather than explicit list of change operations: PATCH /doc HTTP/1.1 Host: example.org Content-Type: application/json-merge-patch { "a": 0, "b": null, "d": { "i": 7 } } Which would yield: { "a": 0, "c": 3, "d": { "e": 4, "f": 5, "g": 6, "i": 7 } } As always, feedback is quite welcome. - James --f46d041825187b331a04cb404be0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have refreshed the JSON Merge Patch = draft...

<= div>=C2=A0=C2=A0http://www.ietf.org/id/draft-snell-merge-patch-04.txt

This is an alternative/complement to JSON-Patch= derived from a number of different specific implementations in the wild.

Example, given the original document:

=C2=A0 {
=C2=A0 =C2=A0 "a": 1,<= /font>
=C2=A0 =C2=A0 "= b": 2,
=C2=A0 = =C2=A0 "c": 3,
=C2=A0 =C2= =A0 "d": {
=C2=A0 =C2=A0 =C2=A0 "e": 4,
<= div>=C2=A0 =C2= =A0 =C2=A0 "f": 5,
=C2=A0 =C2= =A0 =C2=A0 "g": 6
=C2=A0 =C2=A0 }
=C2=A0 }

Merge-patch allows us to perform a partial modi= fication by example, rather than explicit list of change operations:=

=C2=A0 PATCH /doc HTTP/1.1
=C2=A0 Host: example.org
=C2=A0 Content-Type: application= /json-merge-patch
=C2=A0 {
=C2=A0 =C2=A0 "a":= 0,
=C2=A0 =C2=A0 "b": nul= l,
=C2=A0 =C2=A0 &qu= ot;d": {
=C2=A0= =C2=A0 =C2=A0 "i": 7
=C2=A0 =C2=A0 }
=C2=A0 }

Which would yield:

=C2=A0 {
=C2= =A0 =C2=A0 "a": 0,
=C2=A0 =C2=A0 "c": 3,
=C2=A0 =C2= =A0 "d": {
=C2=A0 =C2=A0 =C2=A0 "e": 4,
<= div>=C2=A0 =C2= =A0 =C2=A0 "f": 5,
=C2=A0 =C2= =A0 =C2=A0 "g": 6,
=C2=A0 =C2=A0 =C2=A0 "i": 7=
=C2= =A0 =C2=A0 }
=C2=A0 }

As always, feedback is quite welcome.
- James
--f46d041825187b331a04cb404be0-- From presnick@qti.qualcomm.com Thu Oct 4 12:24:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4F221F86D8 for ; Thu, 4 Oct 2012 12:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 bDw0xYGalnAy for ; Thu, 4 Oct 2012 12:24:34 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id C55B621F863B for ; Thu, 4 Oct 2012 12:24:34 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6855"; a="245828278" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 04 Oct 2012 12:24:26 -0700 X-IronPort-AV: E=Sophos;i="4.80,537,1344236400"; d="scan'208";a="339685911" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Oct 2012 12:24:26 -0700 Received: from kyles-iphone-010073086190.wlan.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 4 Oct 2012 12:24:26 -0700 Message-ID: <506DE26B.5060005@qti.qualcomm.com> Date: Thu, 4 Oct 2012 12:24:27 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <506C7869.7080209@qti.qualcomm.com> <0FB38DF0FE9DED30FC0AE501@JcK-HP8200.jck.com> <506CED96.5030802@it.aoyama.ac.jp> In-Reply-To: <506CED96.5030802@it.aoyama.ac.jp> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.48.1] Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 19:24:35 -0000 A couple of small points: On 10/3/12 6:59 PM, "Martin J. Dürst" wrote: >> --On Wednesday, October 03, 2012 10:39 -0700 Pete Resnick >> wrote: >> >>> Let me make a suggestion to see if we can at least set aside >>> this deadlock for the moment: >>> >>> The IESG gets a crack at all RFCs anyway: All IETF documents >>> come through regular Last Call and IESG Evaluation, and IAB, >>> IRTF, and Independent Submissions come through the IESG for >>> Conflict Review. Since the 3864 appears to say "Either publish >>> an RFC or get Expert Review", we could simply tell IANA, "If >>> it's an RFC, you don't have to check." That gets IANA out of >>> the confusion they are currently in. Then, while this group is >>> figuring out what they want the actual policy to be, the Apps >>> ADs will take the responsibility to either check the >>> templates, or toss them over the wall to Graham to check. > > We all agree that we are discussing minor details. But the above > proposal ignores the following facts: > > 1) In practice, it's the same as up to now (Graham has a look at > everything) That was not my expectation. For IETF standards track documents that have gotten appropriate review, I do not expect to be asking Graham to look at it. For other RFCs, we'll send them to Graham if it does not appear that review was done. > 2) IANA asked the ADs, so we should assume that it will do what the > the ADs tell it. > 3) IANA is much more efficient, and less error-prone at asking the > reviewer than the ADs. If we can, we should have IANA do the work, not > the ADs. Understand that the current procedure is not as you describe. When a draft goes to Last Call, IANA asks the IESG whether there has been Expert Review. We could also change that procedure and tell IANA to simply check with Graham each time, but my feeling was that if the Apps ADs have looked at the thing (we look at all drafts when they come through the IESG) and we believe the registration template is fine, no need to bother anybody else. If there are objections to this being the practice and you instead want Graham to look at everything, we can tell IANA to make the process "Check with Graham for everything". That is not my personal preference (and it's not what 3864 says), but if that's the consensus, we'll talk to IANA to make sure that happens. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From hallam@gmail.com Thu Oct 4 14:08:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D18F21F860D for ; Thu, 4 Oct 2012 14:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.09 X-Spam-Level: X-Spam-Status: No, score=-3.09 tagged_above=-999 required=5 tests=[AWL=-1.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svAR79cu0U7G for ; Thu, 4 Oct 2012 14:08:34 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 016DC21F85F4 for ; Thu, 4 Oct 2012 14:08:33 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so1234666oag.31 for ; Thu, 04 Oct 2012 14:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1UkwgdUCXy1MgYs1LYGF1GxHzy4R20P1jG8UOGVrNAg=; b=VjwCPheePt+ojBZ6PZYQT2FQApx2xeKNOXMH+djzn4dybEcIApFuNAvJPMezwnDDGD d57BneJAyFoYi7BleJWfArb0lkpW5hg+Q0SXGN38ZJz4rYu3FoM+83yLZ48/KcJrB5EV 6mIdO9jF3NogjjR8fiyrhxTT3vw/vq5zVWZ8FOi0e/dKwC4BawPdsBB2AT33Qv41OoUE vnYlVtBJ0hnPFxsVHFieeaArCGQgk4agJQY7BTCn3s00fu2cXpJbuWbqCSqBhpH+AmuT rF5BaVEGw7tmZiKKUR9Fa/BpF6LoydwUOgL0Frn1bgT62LBkOKKDtHD124YSrWkrM4MA GAWQ== MIME-Version: 1.0 Received: by 10.182.152.97 with SMTP id ux1mr5535049obb.13.1349384913578; Thu, 04 Oct 2012 14:08:33 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Thu, 4 Oct 2012 14:08:33 -0700 (PDT) In-Reply-To: <506DE26B.5060005@qti.qualcomm.com> References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <506C7869.7080209@qti.qualcomm.com> <0FB38DF0FE9DED30FC0AE501@JcK-HP8200.jck.com> <506CED96.5030802@it.aoyama.ac.jp> <506DE26B.5060005@qti.qualcomm.com> Date: Thu, 4 Oct 2012 17:08:33 -0400 Message-ID: From: Phillip Hallam-Baker To: Pete Resnick Content-Type: multipart/alternative; boundary=f46d04462c0a706c9b04cb422876 Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 21:08:35 -0000 --f46d04462c0a706c9b04cb422876 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Why wouldn't the expert be interested in a standards RFC submission? That is the sort of issue I would expect them to want to be involved in. Those are the documents I want to see have the highest possible level of review. I don't see how a document has been given adequate review if the domain expert has not at least been made aware of it. I don't see that being standards track is a guarantee of quality as many requests for HTTP headers come from people who have no connection to HTTP. They may not even be from the apps area at all. Since anyone can add in any HTTP headers they like, the role of the expert is not to grant permission but to help avoid people adding unnecessary confusion. I really disagree with the notion that IETF should ever tell people not to add new functionality to a protocol. Explaining that the functionality already exists is another matter as is endorsing that protocol as a good idea. On Thu, Oct 4, 2012 at 3:24 PM, Pete Resnick wro= te: > A couple of small points: > > > On 10/3/12 6:59 PM, "Martin J. D=FCrst" wrote: > > --On Wednesday, October 03, 2012 10:39 -0700 Pete Resnick >>> wrote: >>> >>> Let me make a suggestion to see if we can at least set aside >>>> this deadlock for the moment: >>>> >>>> The IESG gets a crack at all RFCs anyway: All IETF documents >>>> come through regular Last Call and IESG Evaluation, and IAB, >>>> IRTF, and Independent Submissions come through the IESG for >>>> Conflict Review. Since the 3864 appears to say "Either publish >>>> an RFC or get Expert Review", we could simply tell IANA, "If >>>> it's an RFC, you don't have to check." That gets IANA out of >>>> the confusion they are currently in. Then, while this group is >>>> figuring out what they want the actual policy to be, the Apps >>>> ADs will take the responsibility to either check the >>>> templates, or toss them over the wall to Graham to check. >>>> >>> >> We all agree that we are discussing minor details. But the above proposa= l >> ignores the following facts: >> >> 1) In practice, it's the same as up to now (Graham has a look at >> everything) >> > > That was not my expectation. For IETF standards track documents that have > gotten appropriate review, I do not expect to be asking Graham to look at > it. For other RFCs, we'll send them to Graham if it does not appear that > review was done. > > > 2) IANA asked the ADs, so we should assume that it will do what the the >> ADs tell it. >> 3) IANA is much more efficient, and less error-prone at asking the >> reviewer than the ADs. If we can, we should have IANA do the work, not t= he >> ADs. >> > > Understand that the current procedure is not as you describe. When a draf= t > goes to Last Call, IANA asks the IESG whether there has been Expert Revie= w. > We could also change that procedure and tell IANA to simply check with > Graham each time, but my feeling was that if the Apps ADs have looked at > the thing (we look at all drafts when they come through the IESG) and we > believe the registration template is fine, no need to bother anybody else= . > > If there are objections to this being the practice and you instead want > Graham to look at everything, we can tell IANA to make the process "Check > with Graham for everything". That is not my personal preference (and it's > not what 3864 says), but if that's the consensus, we'll talk to IANA to > make sure that happens. > > > pr > > -- > Pete Resnick > > > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --=20 Website: http://hallambaker.com/ --f46d04462c0a706c9b04cb422876 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Why wouldn't the expert be interested in a standards RFC submission?
That is the sort of issue I would expect them to want to b= e involved in. Those are the documents I want to see have the highest possi= ble level of review. I don't see how a document has been given adequate= review if the domain expert has not at least been made aware of it.

I don't see that being standards track is a guarant= ee of quality as many requests for HTTP headers come from people who have n= o connection to HTTP. They may not even be from the apps area at all.

Since anyone can add in any HTTP headers they like, the= role of the expert is not to grant permission but to help avoid people add= ing unnecessary confusion. I really disagree with the notion that IETF shou= ld ever tell people not to add new functionality to a protocol. Explaining = that the functionality already exists is another matter as is endorsing tha= t protocol as a good idea.



On Thu, O= ct 4, 2012 at 3:24 PM, Pete Resnick <presnick@qti.qualcomm.com= > wrote:
A couple of small points:
<= br>
On 10/3/12 6:59 PM, "Martin J. D=FCrst" wrote:

--On Wednesday, October 03, 2012 10:39 -0700 Pete Resnick
<presnick= @qti.qualcomm.com> =A0wrote:

Let me make a suggestion to see if we can at least set aside
this deadlock for the moment:

The IESG gets a crack at all RFCs anyway: All IETF documents
come through regular Last Call and IESG Evaluation, and IAB,
IRTF, and Independent Submissions come through the IESG for
Conflict Review. Since the 3864 appears to say "Either publish
an RFC or get Expert Review", we could simply tell IANA, "If
it's an RFC, you don't have to check." That gets IANA out of the confusion they are currently in. Then, while this group is
figuring out what they want the actual policy to be, the Apps
ADs will take the responsibility to either check the
templates, or toss them over the wall to Graham to check.

We all agree that we are discussing minor details. But the above proposal i= gnores the following facts:

1) In practice, it's the same as up to now (Graham has a look at everyt= hing)

That was not my expectation. For IETF standards track documents that have g= otten appropriate review, I do not expect to be asking Graham to look at it= . For other RFCs, we'll send them to Graham if it does not appear that = review was done.


2) IANA asked the ADs, so we should assume that it will do what the the ADs= tell it.
3) IANA is much more efficient, and less error-prone at asking the reviewer= than the ADs. If we can, we should have IANA do the work, not the ADs.

Understand that the current procedure is not as you describe. When a draft = goes to Last Call, IANA asks the IESG whether there has been Expert Review.= We could also change that procedure and tell IANA to simply check with Gra= ham each time, but my feeling was that if the Apps ADs have looked at the t= hing (we look at all drafts when they come through the IESG) and we believe= the registration template is fine, no need to bother anybody else.

If there are objections to this being the practice and you instead want Gra= ham to look at everything, we can tell IANA to make the process "Check= with Graham for everything". That is not my personal preference (and = it's not what 3864 says), but if that's the consensus, we'll ta= lk to IANA to make sure that happens.


pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

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



--
= Website: http://hallambaker.com/
--f46d04462c0a706c9b04cb422876-- From john-ietf@jck.com Thu Oct 4 14:10:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3926E21F860F for ; Thu, 4 Oct 2012 14:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.112 X-Spam-Level: X-Spam-Status: No, score=-102.112 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, 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 eC6xadEDqS5l for ; Thu, 4 Oct 2012 14:10:34 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB5621F85C7 for ; Thu, 4 Oct 2012 14:10:34 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TJsgg-000G2C-2Z; Thu, 04 Oct 2012 17:10:30 -0400 Date: Thu, 04 Oct 2012 17:10:22 -0400 From: John C Klensin To: Pete Resnick , =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= Message-ID: In-Reply-To: <506DE26B.5060005@qti.qualcomm.com> References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <506C7869.7080209@qti.qualcomm.com> <0FB38DF0FE9DED30FC0AE501@JcK-HP8200.jck.com> <506CED96.5030802@it.aoyama.ac.jp> <506DE26B.5060005@qti.qualcomm.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Apps Discuss Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 21:10:39 -0000 --On Thursday, October 04, 2012 12:24 -0700 Pete Resnick wrote: >> 2) IANA asked the ADs, so we should assume that it will do >> what the the ADs tell it. >> 3) IANA is much more efficient, and less error-prone at >> asking the reviewer than the ADs. If we can, we should have >> IANA do the work, not the ADs. > > Understand that the current procedure is not as you describe. > When a draft goes to Last Call, IANA asks the IESG whether > there has been Expert Review. We could also change that > procedure and tell IANA to simply check with Graham each time, > but my feeling was that if the Apps ADs have looked at the > thing (we look at all drafts when they come through the IESG) > and we believe the registration template is fine, no need to > bother anybody else. > > If there are objections to this being the practice and you > instead want Graham to look at everything, we can tell IANA to > make the process "Check with Graham for everything". That is > not my personal preference (and it's not what 3864 says), but > if that's the consensus, we'll talk to IANA to make sure that > happens. Pete, Focusing exclusively on this particular registry for a change... This (the Apps-discuss list and the sources of email expertise in the IETF more generally)is a sufficiently skilled and nit-picky crowd that the odds are extremely low that there is any difference between the two procedures in practice. If a registration request has serious competency problems and goes into Last Call in the IETF Stream, the odds are extremely high that someone will make loud noises, making the notion of a final check-up review by you, Barry, or Graham large irrelevant. I think several of us have said that in different ways; I won't say it again. However, if you are looking to fine-tune procedures, I think the key question is whether there is any reasonable scenario in which the Expert Reviewer might add value, i.e., identify a problem that wasn't caught or identify a key question that wasn't asked otherwise. If the answer is "yes there are such scenarios", then the Expert ought to be in the loop. The scenario would go like this. First, one has to assume that the problem --whatever it is-- isn't noticed during IETF Last Call. It shouldn't happen. If it never happened, it would make no difference whether the ADs reviewed the registration request or not (except as part of the normal process of ensuring that LC comments are resolved). But things do sometimes slip through the LC cracks (indeed, the fact that we are having this discussion is evidence of that). Then it needs to be far enough in the future that, instead of having two ADs with a few decades of experience in email issues (ignoring your current AD roles, Graham is not inherently more qualified to do the reviews than you or Barry) we had two ADs who were expert in, e.g., Web services who had little in-depth experience with email protocols and header issues. Would it then be desirable to be sure that someone with the relevant expertise did a final check? I think so. And the finger points to an existing appointed Expert for obvious reasons. But, again, I'm not going to lose any sleep over whatever choice you make because I think the odds of its actually making a difference are very low. RFCs that don't go through IETF LC are a different matter and involve somewhat higher odds of a problem slipping through if there isn't specific Expert review. john From internet-drafts@ietf.org Fri Oct 5 06:51:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1030321F86F1; Fri, 5 Oct 2012 06:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 ytKu5v6A1uTn; Fri, 5 Oct 2012 06:51:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C10F21F8714; Fri, 5 Oct 2012 06:51:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121005135147.16356.10774.idtracker@ietfa.amsl.com> Date: Fri, 05 Oct 2012 06:51:47 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-06.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, 05 Oct 2012 13:51: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 : Additional Media Type Structured Syntax Suffixes Author(s) : Tony Hansen Alexey Melnikov Filename : draft-ietf-appsawg-media-type-suffix-regs-06.txt Pages : 15 Date : 2012-10-05 Abstract: A content media type name sometimes includes partitioned meta- information distinguish by a Structured Syntax, to permit noting an attribute of the media as a suffix to the name. This document defines several Structured Syntax Suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax Suffixes, and updates the "+xml" Message Type Structured Syntax Suffix registration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-suffix-regs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-media-type-suffix-reg= s-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From GK@ninebynine.org Fri Oct 5 07:11:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6151C21F877F for ; Fri, 5 Oct 2012 07:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 Smw5FvO1BEck for ; Fri, 5 Oct 2012 07:11:33 -0700 (PDT) Received: from relay1.mail.ox.ac.uk (relay1.mail.ox.ac.uk [129.67.1.165]) by ietfa.amsl.com (Postfix) with ESMTP id AB98D21F876F for ; Fri, 5 Oct 2012 07:11:28 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay1.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1TK8cf-0003Fk-6G; Fri, 05 Oct 2012 15:11:25 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TK8cf-0005uF-8F; Fri, 05 Oct 2012 15:11:25 +0100 Message-ID: <506EC609.8040503@ninebynine.org> Date: Fri, 05 Oct 2012 12:35:37 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> <506D128D.7030401@it.aoyama.ac.jp> <87C87EFF1F4C984D99567920@JcK-HP8200.jck.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Cc: Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] One more idea to make registrations easier X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Oct 2012 14:11:34 -0000 On 04/10/2012 14:44, Phillip Hallam-Baker wrote: > How about a web form with fields for the data in the template that people > fill in. This could be recorded separately from the registry itself which > would contain the reviewed data or it could just be a status flag thing. > > I am writing a draft for a HTTP header right now. Pretty much the only > thing I care about with respect to the name is that nobody else has > attempted to use it. We can bike shed whether it should be > content-integrity, integrity, MAC, security or whatever if the proposal > gets to WG stage. At this stage the only important thing is to avoid a > collision and provide a pointer to the best available documentation in case > people want to look it up. This is a big part of what "provisional" registration, for which the bar is quite low, was meant to achieve. It doesn't guarantee uniqueness (permanent registration does that), but it does give notice to other developers that, given good faith and a little due diligence, should help to avoid clashes. #g -- > Bad documentation of registrations does not worry me a tenth as much as no > registration. Bad or even missing documentation has a habit of getting > fixed if people actually use a feature. It is also a pretty effective > discouragement to implementors. > > > The worst outcome for me is what happened with the SRV non-registry. The > IETF did not set up a registry that made sense or registration processes > that made sense. So now other people run a whole mess of registries that > are incomplete and difficult to find. What comes top in Google serach on a > given day should not determine the authoritative SRV registry. > > > > On Thu, Oct 4, 2012 at 8:43 AM, John C Klensin wrote: > >> >> >> --On Thursday, October 04, 2012 13:37 +0900 "\"Martin J. >> Dürst\"" wrote: >> >>> ... >>> Many registries have a process that can be summarized as "send >>> it to the mailing list, then later send it to IANA". On paper, >>> this two-step process looks like it's quite easy. But >>> submitters easily forget the second step, or don't know how to >>> judge when they can move on. >>> >>> For many registries, it would be great if that could be >>> changed to "submit to IANA, they'll forward to the mailing >>> list (they have to make sure they keep the submitter in the >>> loop by cc'ing, I'm not sure IANA's systems are currently able >>> to handle this.). >> >> I would favor this generally, partially for a reason that Martin >> didn't mention: it would allow IANA to establish and maintain a >> tracking regime for requests. Such a tracking regime would act >> as a safeguard against the many ways that a request can fall >> through the cracks despite the best of intentions (I note >> Graham's recent comment about the possibility of email just >> getting lost in the general noise). Secondarily, it might >> provide a public record of pending requests which might reduce >> or eliminate the need for provisional registries in some cases. >> >>> A second point that I think is worth looking at is to give the >>> expert reviewers the possibility (not duty) to fix some things >>> by themselves. In many cases, it's easier to do a quick fix >>> than to wait for the submitter to possibly goof up again. In >>> these cases, insisting on the submitter to submit again is >>> quite contraproductive in terms of registration rates. Of >>> course, how often this gets used depends very much on the >>> business of the registry and the issues at hand. >> >> I'm more hesitant about this. On the other hand, if the Expert >> reviewer wants to propose some specific text or changes to the >> submitter and ask if it would be ok to apply them, I can't see >> any problem with that even under present procedures. >> >> best, >> john >> >> _______________________________________________ >> 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 iesg-secretary@ietf.org Fri Oct 5 07:14:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4933A21F86FA; Fri, 5 Oct 2012 07:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 ZdXhQ9R5UAiF; Fri, 5 Oct 2012 07:14:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC1721F85DA; Fri, 5 Oct 2012 07:14:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121005141421.25035.8756.idtracker@ietfa.amsl.com> Date: Fri, 05 Oct 2012 07:14:21 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (Additional Media Type Structured Syntax Suffixes) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 14:14:22 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Additional Media Type Structured Syntax Suffixes' 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-10-19. 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 A content media type name sometimes includes partitioned meta- information distinguish by a Structured Syntax, to permit noting an attribute of the media as a suffix to the name. This document defines several Structured Syntax Suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax Suffixes, and updates the "+xml" Message Type Structured Syntax Suffix registration. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-suffix-regs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-suffix-regs/ballot/ No IPR declarations have been submitted directly on this I-D. From hallam@gmail.com Fri Oct 5 08:33:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC57021F84A2 for ; Fri, 5 Oct 2012 08:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=-1.445, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C83mb7ivMC5a for ; Fri, 5 Oct 2012 08:33:46 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5E921F8456 for ; Fri, 5 Oct 2012 08:33:39 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2234943obq.31 for ; Fri, 05 Oct 2012 08:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Lwj33VjYro57qCCs7zNbBYDUqksu4bbGQlkwn9rrCNU=; b=Sn7uJPjb9UdxED8gQ2K0d9LFNz1X6QGixj/Doot3rjyzyRS/UGSZi1TeMSVhe8CQs0 h3LSjiRHps+MCSnrcAZI3V6BN/ebPkk7SAg9IFy7hD+GKIV2ROQUUegde89jIH1UKU6C AOMfSLZGpE8oz5/ACaCvE9C42hq7tjAwTvn10WdOfhGpfEdSLYM1+Ud2zpi5x+5Isjjm uFfXAi3Qa3l+AKmEYN8Yx9fEyaOYm3v360EErCKje+Y183YbzInRBEvD9J2wO2dhmUsf ac45GDZRZigPkG/JmaepmOQIt2favFm2UB2oCDAQNnr5pqmBsRO4dzQiunXAeEc4AlHh GMqQ== MIME-Version: 1.0 Received: by 10.182.174.100 with SMTP id br4mr3441485obc.62.1349451219396; Fri, 05 Oct 2012 08:33:39 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Fri, 5 Oct 2012 08:33:39 -0700 (PDT) In-Reply-To: <506EC609.8040503@ninebynine.org> References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> <506D128D.7030401@it.aoyama.ac.jp> <87C87EFF1F4C984D99567920@JcK-HP8200.jck.com> <506EC609.8040503@ninebynine.org> Date: Fri, 5 Oct 2012 11:33:39 -0400 Message-ID: From: Phillip Hallam-Baker To: Graham Klyne Content-Type: multipart/alternative; boundary=e89a8f647b1d92e93904cb5198bb Cc: Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] One more idea to make registrations easier X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Oct 2012 15:33:48 -0000 --e89a8f647b1d92e93904cb5198bb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 The problem is that we seem to have a commitment issue and end up using provisional for things that should be permanent and then start upping the barrier to provisional registrations. On Fri, Oct 5, 2012 at 7:35 AM, Graham Klyne wrote: > On 04/10/2012 14:44, Phillip Hallam-Baker wrote: > >> How about a web form with fields for the data in the template that peopl= e >> fill in. This could be recorded separately from the registry itself whic= h >> would contain the reviewed data or it could just be a status flag thing. >> >> I am writing a draft for a HTTP header right now. Pretty much the only >> thing I care about with respect to the name is that nobody else has >> attempted to use it. We can bike shed whether it should be >> content-integrity, integrity, MAC, security or whatever if the proposal >> gets to WG stage. At this stage the only important thing is to avoid a >> collision and provide a pointer to the best available documentation in >> case >> people want to look it up. >> > > This is a big part of what "provisional" registration, for which the bar > is quite low, was meant to achieve. It doesn't guarantee uniqueness > (permanent registration does that), but it does give notice to other > developers that, given good faith and a little due diligence, should help > to avoid clashes. > > #g > -- > > Bad documentation of registrations does not worry me a tenth as much as = no >> registration. Bad or even missing documentation has a habit of getting >> fixed if people actually use a feature. It is also a pretty effective >> discouragement to implementors. >> >> >> The worst outcome for me is what happened with the SRV non-registry. The >> IETF did not set up a registry that made sense or registration processes >> that made sense. So now other people run a whole mess of registries that >> are incomplete and difficult to find. What comes top in Google serach on= a >> given day should not determine the authoritative SRV registry. >> >> >> >> On Thu, Oct 4, 2012 at 8:43 AM, John C Klensin wrote= : >> >> >>> >>> --On Thursday, October 04, 2012 13:37 +0900 "\"Martin J. >>> D=FCrst\"" wrote: >>> >>> ... >>>> Many registries have a process that can be summarized as "send >>>> it to the mailing list, then later send it to IANA". On paper, >>>> this two-step process looks like it's quite easy. But >>>> submitters easily forget the second step, or don't know how to >>>> judge when they can move on. >>>> >>>> For many registries, it would be great if that could be >>>> changed to "submit to IANA, they'll forward to the mailing >>>> list (they have to make sure they keep the submitter in the >>>> loop by cc'ing, I'm not sure IANA's systems are currently able >>>> to handle this.). >>>> >>> >>> I would favor this generally, partially for a reason that Martin >>> didn't mention: it would allow IANA to establish and maintain a >>> tracking regime for requests. Such a tracking regime would act >>> as a safeguard against the many ways that a request can fall >>> through the cracks despite the best of intentions (I note >>> Graham's recent comment about the possibility of email just >>> getting lost in the general noise). Secondarily, it might >>> provide a public record of pending requests which might reduce >>> or eliminate the need for provisional registries in some cases. >>> >>> A second point that I think is worth looking at is to give the >>>> expert reviewers the possibility (not duty) to fix some things >>>> by themselves. In many cases, it's easier to do a quick fix >>>> than to wait for the submitter to possibly goof up again. In >>>> these cases, insisting on the submitter to submit again is >>>> quite contraproductive in terms of registration rates. Of >>>> course, how often this gets used depends very much on the >>>> business of the registry and the issues at hand. >>>> >>> >>> I'm more hesitant about this. On the other hand, if the Expert >>> reviewer wants to propose some specific text or changes to the >>> submitter and ask if it would be ok to apply them, I can't see >>> any problem with that even under present procedures. >>> >>> best, >>> john >>> >>> ______________________________**_________________ >>> 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 >> >> --=20 Website: http://hallambaker.com/ --e89a8f647b1d92e93904cb5198bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

The problem is that we seem to have a commitment issu= e and end up using provisional for things that should be permanent and then= start upping the barrier to provisional registrations.

On Fri, Oct 5, 2012 at 7:35 AM, Graham Klyne <GK@ninebynine.org> wrote:
On 04/10/2012 14:44, Phillip Hallam-Baker wrote:
How about a web form with fields for the data in the template that people fill in. This could be recorded separately from the registry itself which would contain the reviewed data or it could just be a status flag thing.
I am writing a draft for a HTTP header right now. Pretty much the only
thing I care about with respect to the name is that nobody else has
attempted to use it. We can bike shed whether it should be
content-integrity, integrity, MAC, security or whatever if the proposal
gets to WG stage. At this stage the only important thing is to avoid a
collision and provide a pointer to the best available documentation in case=
people want to look it up.

This is a big part of what "provisional" registration, for which = the bar is quite low, was meant to achieve. =A0It doesn't guarantee uni= queness (permanent registration does that), but it does give notice to othe= r developers that, given good faith and a little due diligence, should help= to avoid clashes.

#g
--

Bad documentation of registrations does not worry me a tenth as much as no<= br> registration. Bad or even missing documentation has a habit of getting
fixed if people actually use a feature. It is also a pretty effective
discouragement to implementors.


The worst outcome for me is what happened with the SRV non-registry. The IETF did not set up a registry that made sense or registration processes that made sense. So now other people run a whole mess of registries that are incomplete and difficult to find. What comes top in Google serach on a<= br> given day should not determine the authoritative SRV registry.



On Thu, Oct 4, 2012 at 8:43 AM, John C Klensin <john-ietf@jck.com> wrote:



--On Thursday, October 04, 2012 13:37 +0900 "\"Martin J.
D=FCrst\"" <duerst@it.aoyama.ac.jp> wrote:

...
Many registries have a process that can be summarized as "send
it to the mailing list, then later send it to IANA". On paper,
this two-step process looks like it's quite easy. But
submitters easily forget the second step, or don't know how to
judge when they can move on.

For many registries, it would be great if that could be
changed to "submit to IANA, they'll forward to the mailing
list (they have to make sure they keep the submitter in the
loop by cc'ing, I'm not sure IANA's systems are currently able<= br> to handle this.).

I would favor this generally, partially for a reason that Martin
didn't mention: it would allow IANA to establish and maintain a
tracking regime for requests. =A0Such a tracking regime would act
as a safeguard against the many ways that a request can fall
through the cracks despite the best of intentions (I note
Graham's recent comment about the possibility of email just
getting lost in the general noise). =A0Secondarily, it might
provide a public record of pending requests which might reduce
or eliminate the need for provisional registries in some cases.

A second point that I think is worth looking at is to give the
expert reviewers the possibility (not duty) to fix some things
by themselves. In many cases, it's easier to do a quick fix
than to wait for the submitter to possibly goof up again. In
these cases, insisting on the submitter to submit again is
quite contraproductive in terms of registration rates. Of
course, how often this gets used depends very much on the
business of the registry and the issues at hand.

I'm more hesitant about this. =A0On the other hand, if the Expert
reviewer wants to propose some specific text or changes to the
submitter and ask if it would be ok to apply them, I can't see
any problem with that even under present procedures.

best,
=A0 =A0john

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






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




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

--e89a8f647b1d92e93904cb5198bb-- From iesg-secretary@ietf.org Fri Oct 5 08:50:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1373021F8764; Fri, 5 Oct 2012 08:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMrEA3tId+Qn; Fri, 5 Oct 2012 08:50:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8773A21F8718; Fri, 5 Oct 2012 08:50:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121005155008.21453.67110.idtracker@ietfa.amsl.com> Date: Fri, 05 Oct 2012 08:50:08 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] UPDATED Last Call: (Additional Media Type Structured Syntax Suffixes) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 15:50:09 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Additional Media Type Structured Syntax Suffixes' 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-10-19. 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 A content media type name sometimes includes partitioned meta- information distinguish by a Structured Syntax, to permit noting an attribute of the media as a suffix to the name. This document defines several Structured Syntax Suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax Suffixes, and updates the "+xml" Message Type Structured Syntax Suffix registration. Note that this document contains completed registration templates for the Structured Syntax Suffixes it registers. Those registrations include normative references to a number of external (non-IETF) documents that describe the formats being registered. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-suffix-regs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-suffix-regs/ballot/ No IPR declarations have been submitted directly on this I-D. From alexey.melnikov@isode.com Fri Oct 5 10:40:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B7C21F87A5 for ; Fri, 5 Oct 2012 10:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.302 X-Spam-Level: X-Spam-Status: No, score=-102.302 tagged_above=-999 required=5 tests=[AWL=0.297, 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 uHjE-S3arfjJ for ; Fri, 5 Oct 2012 10:40:42 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id E733021F86B3 for ; Fri, 5 Oct 2012 10:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1349458840; d=isode.com; s=selector; i=@isode.com; bh=BsQyjXH0fwcteQngFWGhXa1yyPZSsQaWoK9iRxYs7ms=; 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=wiO4Z/SQU3yqYBYixWL8nCeMNFCLcaaLRxIHweD8b14+1fVeomXob5MUkaYiQRKbL/f4VB aUyevd0Voe62sYHaqR6v93iyR6ly0vSBXwwE7Tk688xU9hrXE093jsGn4pNKcKM9UjvzuE Sq46C7cBZ8DRr4q0a3nN+qca/wAcVuA=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 5 Oct 2012 18:40:40 +0100 Message-ID: <506F1B81.5020102@isode.com> Date: Fri, 05 Oct 2012 18:40:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: apps-discuss@ietf.org References: <20121005135147.16356.10774.idtracker@ietfa.amsl.com> In-Reply-To: <20121005135147.16356.10774.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-06.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, 05 Oct 2012 17:40:43 -0000 On 05/10/2012 14:51, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : Additional Media Type Structured Syntax Suffixes > Author(s) : Tony Hansen > Alexey Melnikov > Filename : draft-ietf-appsawg-media-type-suffix-regs-06.txt > Pages : 15 > Date : 2012-10-05 > > Abstract: > A content media type name sometimes includes partitioned meta- > information distinguish by a Structured Syntax, to permit noting an > attribute of the media as a suffix to the name. This document > defines several Structured Syntax Suffixes for use with media type > registrations. In particular, it defines and registers the "+json", > "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax > Suffixes, and updates the "+xml" Message Type Structured Syntax > Suffix registration. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-suffix-regs > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-media-type-suffix-regs-06 This version clarifies relationship to RFC 3023 (as per Barry's AD review) + fixes a typo. From ned.freed@mrochek.com Fri Oct 5 12:19:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95DC21F86C2 for ; Fri, 5 Oct 2012 12:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 YkuYt-URKbvj for ; Fri, 5 Oct 2012 12:19:37 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 305CF21F842C for ; Fri, 5 Oct 2012 12:19:37 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OL26UL2RZ400BTJV@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 5 Oct 2012 12:14:35 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OL246NG2NK0006TF@mauve.mrochek.com>; Fri, 5 Oct 2012 12:14:32 -0700 (PDT) Message-id: <01OL26UJLLEG0006TF@mauve.mrochek.com> Date: Fri, 05 Oct 2012 12:10:30 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 05 Oct 2012 11:33:39 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1 References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> <506D128D.7030401@it.aoyama.ac.jp> <87C87EFF1F4C984D99567920@JcK-HP8200.jck.com> <506EC609.8040503@ninebynine.org> To: Phillip Hallam-Baker Cc: Barry Leiba , Graham Klyne , Apps Discuss Subject: Re: [apps-discuss] One more idea to make registrations easier X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Oct 2012 19:19:37 -0000 > The problem is that we seem to have a commitment issue and end up using > provisional for things that should be permanent and then start upping the > barrier to provisional registrations. As I noted in the discussion of provisional media type registrations, part of the problem with the provisional header registry is calling it "provisional". The word doesn't really match up well with the intended purpose of the registry. At a minimum this needs to be clarified in any future revision of the specification. Ned From ned.freed@mrochek.com Fri Oct 5 15:22:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0FB21F867B for ; Fri, 5 Oct 2012 15:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 NVyYuyZEeWqF for ; Fri, 5 Oct 2012 15:22:08 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id DE96421F8527 for ; Fri, 5 Oct 2012 15:22:07 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OL2D7VAAC000CB8C@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 5 Oct 2012 15:17:05 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OL246NG2NK0006TF@mauve.mrochek.com>; Fri, 5 Oct 2012 15:17:03 -0700 (PDT) Message-id: <01OL2D7TXXTK0006TF@mauve.mrochek.com> Date: Fri, 05 Oct 2012 15:12:17 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 04 Oct 2012 13:37:33 +0900" <506D128D.7030401@it.aoyama.ac.jp> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> <506D128D.7030401@it.aoyama.ac.jp> To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Cc: Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] One more idea to make registrations easier (was: Re: Registration policy for the Permanent Message Header Field Names registry) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 22:22:09 -0000 > On 2012/10/04 2:38, Barry Leiba wrote: > > Whatever we decide for this case, I encourage everyone to consider > > this in the general situation: When you're writing IANA Considerations > > sections, and you're creating a new registry, and the resource you're > > registering has an essentially unlimited namespace, consider a > > registration policy that encourages registrations above one that makes > > it harder and is discouraging. > During this discussion, and based on my experience with helping to > register media types from the W3C, and as a reviewer for charsets, I > want to point out some other ideas on how to hopefully improve the > review/registration process. > Many registries have a process that can be summarized as "send it to the > mailing list, then later send it to IANA". On paper, this two-step > process looks like it's quite easy. But submitters easily forget the > second step, or don't know how to judge when they can move on. > For many registries, it would be great if that could be changed to > "submit to IANA, they'll forward to the mailing list (they have to make > sure they keep the submitter in the loop by cc'ing, I'm not sure IANA's > systems are currently able to handle this.). Seems like a good idea in the abstract but the devil is going to be in the details. In particular, I'm not sure how IANA is supposed to process or interpret the results of the list posting or who determines when that process is "complete". > A second point that I think is worth looking at is to give the expert > reviewers the possibility (not duty) to fix some things by themselves. > In many cases, it's easier to do a quick fix than to wait for the > submitter to possibly goof up again. In these cases, insisting on the > submitter to submit again is quite contraproductive in terms of > registration rates. Of course, how often this gets used depends very > much on the business of the registry and the issues at hand. One way I usually handle this is to suggest text. I often do it in the first review, but I pretty much always do it if the second attempt still has problems. When it comes to really small stuff like typos, I approve the registration subject to them being corrected. That gets me out of the loop. Ned From john-ietf@jck.com Fri Oct 5 21:33:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E18121F8634 for ; Fri, 5 Oct 2012 21:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.095 X-Spam-Level: X-Spam-Status: No, score=-102.095 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 BP51O64QuOl2 for ; Fri, 5 Oct 2012 21:33:04 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id EE3C421F862A for ; Fri, 5 Oct 2012 21:33:03 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TKM4I-000Jeb-M4; Sat, 06 Oct 2012 00:32:50 -0400 Date: Sat, 06 Oct 2012 00:32:40 -0400 From: John C Klensin To: Ned Freed , =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= Message-ID: In-Reply-To: <01OL2D7TXXTK0006TF@mauve.mrochek.com> References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> <506D128D.7030401@it.aoyama.ac.jp> <01OL2D7TXXTK0006TF@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] One more idea to make registrations easier (was: Re: Registration policy for the Permanent Message Header Field Names registry) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 04:33:04 -0000 --On Friday, October 05, 2012 15:12 -0700 Ned Freed wrote: >> Many registries have a process that can be summarized as >> "send it to the mailing list, then later send it to IANA". On >> paper, this two-step process looks like it's quite easy. But >> submitters easily forget the second step, or don't know how >> to judge when they can move on. > >> For many registries, it would be great if that could be >> changed to "submit to IANA, they'll forward to the mailing >> list (they have to make sure they keep the submitter in the >> loop by cc'ing, I'm not sure IANA's systems are currently >> able to handle this.). > > Seems like a good idea in the abstract but the devil is going > to be in the > details. In particular, I'm not sure how IANA is supposed to > process or > interpret the results of the list posting or who determines > when that > process is "complete". Ned, I think there are two cases in practice: (1) The one where there is a Designated Expert involved, in which case my (somewhat extended) interpretation of Martin's suggestion is that (i) IANA gets the request and logs it, (ii) IANA sends notes to the list and to the Expert, (iii) the Expert decides. (2) The one where there is no Expert and the procedure really is as Martin described: submitter sends to list, waits some period of time for suggestions, and then forwards to IANA for registration. For that case, it seems that the suggestions leaves us exactly where we are today as far as approval is concerned. While the submitter sends to IANA rather than the mailing list directly, IANA just logs and forwards to the list. The submitter still decides when to tell IANA to register, subject to whatever constraints about time, handling of comments, etc., apply to that particular registry. I assume that case would apply only to FCFS situations; for all others, I think we've specified some sort of review and signoff process by other than the submitter. john From ned.freed@mrochek.com Fri Oct 5 21:43:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2181021F845D for ; Fri, 5 Oct 2012 21:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqoslY5+rmkM for ; Fri, 5 Oct 2012 21:43:48 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 839AF21F845B for ; Fri, 5 Oct 2012 21:43:48 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OL2QK1J08G00C0GM@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 5 Oct 2012 21:38:44 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OL2H0K5EG00006TF@mauve.mrochek.com>; Fri, 5 Oct 2012 21:38:41 -0700 (PDT) Message-id: <01OL2QJZ9SS00006TF@mauve.mrochek.com> Date: Fri, 05 Oct 2012 21:37:43 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 06 Oct 2012 00:32:40 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> <506D128D.7030401@it.aoyama.ac.jp> <01OL2D7TXXTK0006TF@mauve.mrochek.com> To: John C Klensin Cc: Barry Leiba , Ned Freed , Apps Discuss Subject: Re: [apps-discuss] One more idea to make registrations easier (was: Re: Registration policy for the Permanent Message Header Field Names registry) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 04:43:49 -0000 > --On Friday, October 05, 2012 15:12 -0700 Ned Freed > wrote: > >> Many registries have a process that can be summarized as > >> "send it to the mailing list, then later send it to IANA". On > >> paper, this two-step process looks like it's quite easy. But > >> submitters easily forget the second step, or don't know how > >> to judge when they can move on. > > > >> For many registries, it would be great if that could be > >> changed to "submit to IANA, they'll forward to the mailing > >> list (they have to make sure they keep the submitter in the > >> loop by cc'ing, I'm not sure IANA's systems are currently > >> able to handle this.). > > > > Seems like a good idea in the abstract but the devil is going > > to be in the > > details. In particular, I'm not sure how IANA is supposed to > > process or > > interpret the results of the list posting or who determines > > when that > > process is "complete". > Ned, > I think there are two cases in practice: > (1) The one where there is a Designated Expert involved, in > which case my (somewhat extended) interpretation of Martin's > suggestion is that (i) IANA gets the request and logs it, (ii) > IANA sends notes to the list and to the Expert, (iii) the Expert > decides. Not hard to implement, but only applicable in limited circumstances. > (2) The one where there is no Expert and the procedure really is > as Martin described: submitter sends to list, waits some period > of time for suggestions, and then forwards to IANA for > registration. For that case, it seems that the suggestions > leaves us exactly where we are today as far as approval is > concerned. While the submitter sends to IANA rather than the > mailing list directly, IANA just logs and forwards to the list. > The submitter still decides when to tell IANA to register, > subject to whatever constraints about time, handling of > comments, etc., apply to that particular registry. I assume > that case would apply only to FCFS situations; for all others, I > think we've specified some sort of review and signoff process by > other than the submitter. Yep, it doesn't really help, does it? Ned From john-ietf@jck.com Fri Oct 5 22:23:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82CA21F85A7 for ; Fri, 5 Oct 2012 22:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.332 X-Spam-Level: X-Spam-Status: No, score=-101.332 tagged_above=-999 required=5 tests=[AWL=-1.147, BAYES_40=-0.185, 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 J17DTNlU7nCD for ; Fri, 5 Oct 2012 22:23:49 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7681E21F855F for ; Fri, 5 Oct 2012 22:23:49 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TKMrT-000JjS-HO; Sat, 06 Oct 2012 01:23:39 -0400 Date: Sat, 06 Oct 2012 01:23:29 -0400 From: John C Klensin To: Ned Freed Message-ID: In-Reply-To: <01OL2QJZ9SS00006TF@mauve.mrochek.com> References: <01OL2QJZ9SS00006TF@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] One more idea to make registrations easier (was: Re: Registration policy for the Permanent Message Header Field Names registry) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 05:23:50 -0000 --On Friday, October 05, 2012 21:37 -0700 Ned Freed wrote: >> I think there are two cases in practice: > >> (1) The one where there is a Designated Expert involved, in >> which case my (somewhat extended) interpretation of Martin's >> suggestion is that (i) IANA gets the request and logs it, (ii) >> IANA sends notes to the list and to the Expert, (iii) the >> Expert decides. > > Not hard to implement, but only applicable in limited > circumstances. I think it makes it a tad easier for the submitter (assuming the submitter is clear about what registry is involved) and provides better tracking. Otherwise, yes, limited circumstances and a small gain. >> (2) The one where there is no Expert and the procedure really >> is as Martin described: submitter sends to list, waits some >> period of time for suggestions, and then forwards to IANA for >> registration. For that case, it seems that the suggestions >> leaves us exactly where we are today as far as approval is >> concerned. While the submitter sends to IANA rather than the >> mailing list directly, IANA just logs and forwards to the >> list. The submitter still decides when to tell IANA to >> register, subject to whatever constraints about time, >> handling of comments, etc., apply to that particular >> registry. I assume that case would apply only to FCFS >> situations; for all others, I think we've specified some sort >> of review and signoff process by other than the submitter. > > Yep, it doesn't really help, does it? Again, provides better tracking and might be easier for submitters to keep track of what to do. Not a huge change. So I thought of this as a small incremental improvement -- mostly because of the tracking aspect-- but with some emphasis on "small". john From GK@ninebynine.org Sat Oct 6 01:07:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B681D21F8673 for ; Sat, 6 Oct 2012 01:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.308 X-Spam-Level: X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 rdDSTTKtP76l for ; Sat, 6 Oct 2012 01:07:14 -0700 (PDT) Received: from relay0.mail.ox.ac.uk (relay0.mail.ox.ac.uk [129.67.1.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9D87821F8672 for ; Sat, 6 Oct 2012 01:07:13 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay0.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1TKPPg-0001aE-3B; Sat, 06 Oct 2012 09:07:09 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TKPPg-00010b-7W; Sat, 06 Oct 2012 09:07:08 +0100 Message-ID: <506FD080.3020902@ninebynine.org> Date: Sat, 06 Oct 2012 07:32:32 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> <506D128D.7030401@it.aoyama.ac.jp> <87C87EFF1F4C984D99567920@JcK-HP8200.jck.com> <506EC609.8040503@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Cc: Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] One more idea to make registrations easier X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Oct 2012 08:07:14 -0000 On 05/10/2012 16:33, Phillip Hallam-Baker wrote: > +1 > > The problem is that we seem to have a commitment issue and end up using > provisional for things that should be permanent and then start upping the > barrier to provisional registrations. That's not something I've noticed or been aware of, at least as far as the message header or URI registries are concerned. But I cannot dispute there is a widespread perception of a problem here, which is just as bad. #g -- > > On Fri, Oct 5, 2012 at 7:35 AM, Graham Klyne wrote: > >> On 04/10/2012 14:44, Phillip Hallam-Baker wrote: >> >>> How about a web form with fields for the data in the template that people >>> fill in. This could be recorded separately from the registry itself which >>> would contain the reviewed data or it could just be a status flag thing. >>> >>> I am writing a draft for a HTTP header right now. Pretty much the only >>> thing I care about with respect to the name is that nobody else has >>> attempted to use it. We can bike shed whether it should be >>> content-integrity, integrity, MAC, security or whatever if the proposal >>> gets to WG stage. At this stage the only important thing is to avoid a >>> collision and provide a pointer to the best available documentation in >>> case >>> people want to look it up. >>> >> >> This is a big part of what "provisional" registration, for which the bar >> is quite low, was meant to achieve. It doesn't guarantee uniqueness >> (permanent registration does that), but it does give notice to other >> developers that, given good faith and a little due diligence, should help >> to avoid clashes. >> >> #g >> -- >> >> Bad documentation of registrations does not worry me a tenth as much as no >>> registration. Bad or even missing documentation has a habit of getting >>> fixed if people actually use a feature. It is also a pretty effective >>> discouragement to implementors. >>> >>> >>> The worst outcome for me is what happened with the SRV non-registry. The >>> IETF did not set up a registry that made sense or registration processes >>> that made sense. So now other people run a whole mess of registries that >>> are incomplete and difficult to find. What comes top in Google serach on a >>> given day should not determine the authoritative SRV registry. >>> >>> >>> >>> On Thu, Oct 4, 2012 at 8:43 AM, John C Klensin wrote: >>> >>> >>>> >>>> --On Thursday, October 04, 2012 13:37 +0900 "\"Martin J. >>>> Dürst\"" wrote: >>>> >>>> ... >>>>> Many registries have a process that can be summarized as "send >>>>> it to the mailing list, then later send it to IANA". On paper, >>>>> this two-step process looks like it's quite easy. But >>>>> submitters easily forget the second step, or don't know how to >>>>> judge when they can move on. >>>>> >>>>> For many registries, it would be great if that could be >>>>> changed to "submit to IANA, they'll forward to the mailing >>>>> list (they have to make sure they keep the submitter in the >>>>> loop by cc'ing, I'm not sure IANA's systems are currently able >>>>> to handle this.). >>>>> >>>> >>>> I would favor this generally, partially for a reason that Martin >>>> didn't mention: it would allow IANA to establish and maintain a >>>> tracking regime for requests. Such a tracking regime would act >>>> as a safeguard against the many ways that a request can fall >>>> through the cracks despite the best of intentions (I note >>>> Graham's recent comment about the possibility of email just >>>> getting lost in the general noise). Secondarily, it might >>>> provide a public record of pending requests which might reduce >>>> or eliminate the need for provisional registries in some cases. >>>> >>>> A second point that I think is worth looking at is to give the >>>>> expert reviewers the possibility (not duty) to fix some things >>>>> by themselves. In many cases, it's easier to do a quick fix >>>>> than to wait for the submitter to possibly goof up again. In >>>>> these cases, insisting on the submitter to submit again is >>>>> quite contraproductive in terms of registration rates. Of >>>>> course, how often this gets used depends very much on the >>>>> business of the registry and the issues at hand. >>>>> >>>> >>>> I'm more hesitant about this. On the other hand, if the Expert >>>> reviewer wants to propose some specific text or changes to the >>>> submitter and ask if it would be ok to apply them, I can't see >>>> any problem with that even under present procedures. >>>> >>>> best, >>>> john >>>> >>>> ______________________________**_________________ >>>> 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 > From barryleiba.mailing.lists@gmail.com Sat Oct 6 06:38:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D894321F8634 for ; Sat, 6 Oct 2012 06:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.11 X-Spam-Level: X-Spam-Status: No, score=-103.11 tagged_above=-999 required=5 tests=[AWL=-0.133, 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 rty2VVfrAUm0 for ; Sat, 6 Oct 2012 06:38:10 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F30E321F8630 for ; Sat, 6 Oct 2012 06:38:09 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so2221046lbo.31 for ; Sat, 06 Oct 2012 06:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8YuFqCd0IBkr5eGlmLWkDFv5ZmbnAHbB12NWgO1eE48=; b=cMEmw9bOlS2BAoQg48sjfDotK9wcg9z2pGIz0aMVIXu0QWQtu9jV18SV6ID+3JohCM 403N9x3WtkW+OXbBYOOHUQ+kaNq6bHJ5ZoI4+bL02+aQQ6sDjngijtQBYlInDTUAHOQs LEYpf/ve7hLtKZJY/JEcX4idBl6pPPmEnCaMsHW0PEIKKy0xmYRw02KigM0VfaOVwVvy gsQRFPrB6Ya5/vBrYHQ52wky8P3iRmvm6sb8O0s3rWlFuHeVS+UjVVWI7YfQZGEADib5 m04LWy7zmA4dfOZrqrl0faX+mzmRaavB9cwKcffMvpeYMEgSBzgE4qs4IUKa8ROqMAZe /83A== MIME-Version: 1.0 Received: by 10.152.105.236 with SMTP id gp12mr9072262lab.35.1349530688777; Sat, 06 Oct 2012 06:38:08 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.150.194 with HTTP; Sat, 6 Oct 2012 06:38:08 -0700 (PDT) In-Reply-To: <01OL2QJZ9SS00006TF@mauve.mrochek.com> References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> <506D128D.7030401@it.aoyama.ac.jp> <01OL2D7TXXTK0006TF@mauve.mrochek.com> <01OL2QJZ9SS00006TF@mauve.mrochek.com> Date: Sat, 6 Oct 2012 09:38:08 -0400 X-Google-Sender-Auth: x1vI22GjqOQRgINeOOP9tqUfXLo Message-ID: From: Barry Leiba To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: Re: [apps-discuss] One more idea to make registrations easier (was: Re: Registration policy for the Permanent Message Header Field Names registry) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 13:38:11 -0000 >> (1) The one where there is a Designated Expert involved, in >> which case my (somewhat extended) interpretation of Martin's >> suggestion is that (i) IANA gets the request and logs it, (ii) >> IANA sends notes to the list and to the Expert, (iii) the Expert >> decides. > > Not hard to implement, but only applicable in limited circumstances. Actually, it probably would be more applicable than you think, and perhaps more helpful than you think. Most chairs/shepherds/authors aren't fully aware of how the expert review process works, and think that someone else (the IESG or IANA) will take care of the expert review. The shepherd writeups almost always fail to mention anything about expert review, IANA always asks in their last-call message ("IANA Question -> has the document been reviewed by the Permanent Message Header Field Names registry expert?", from the IANA comments on draft-snell-http-prefer), and the shepherd/authors usually don't respond. It then remains for someone (usually the responsible AD or another AD who ballots a comment or DISCUSS on it) to deal with this, and it's quite late in the process (by now it's the last few days before the IESG telechat where the document is meant to get final approval, and we don't have the expert review yet). If, in IANA's last-call review, instead of asking whether it's been through expert review IANA just sent it to the designated expert, they would get their answer (from the DE directly), and we would be sure to get expert review during IETF last call. Barry From john-ietf@jck.com Sat Oct 6 06:57:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2AC21F856F for ; Sat, 6 Oct 2012 06:57:32 -0700 (PDT) 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 OCXXZrmF77B2 for ; Sat, 6 Oct 2012 06:57:31 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA7121F8569 for ; Sat, 6 Oct 2012 06:57:31 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TKUsc-000Kaw-HZ; Sat, 06 Oct 2012 09:57:22 -0400 Date: Sat, 06 Oct 2012 09:57:11 -0400 From: John C Klensin To: Barry Leiba , Ned Freed Message-ID: In-Reply-To: References: <506B1B6E.9010503@qti.qualcomm.com> <01OKYGEAYE9A0006TF@mauve.mrochek.com> <520CED87E8AB168E8E5454ED@JcK-HP8200.jck.com> <01OKZ8QICJL40006TF@mauve.mrochek.com> <506D128D.7030401@it.aoyama.ac.jp> <01OL2D7TXXTK0006TF@mauve.mrochek.com> <01OL2QJZ9SS00006TF@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Apps Discuss Subject: Re: [apps-discuss] One more idea to make registrations easier (was: Re: Registration policy for the Permanent Message Header Field Names registry) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 13:57:32 -0000 --On Saturday, October 06, 2012 09:38 -0400 Barry Leiba wrote: >>> (1) The one where there is a Designated Expert involved, in >>> which case my (somewhat extended) interpretation of Martin's >>> suggestion is that (i) IANA gets the request and logs it, >>> (ii) IANA sends notes to the list and to the Expert, (iii) >>> the Expert decides. >> >> Not hard to implement, but only applicable in limited >> circumstances. > > Actually, it probably would be more applicable than you think, > and perhaps more helpful than you think. Most > chairs/shepherds/authors aren't fully aware of how the expert > review process works, and think that someone else (the IESG or > IANA) will take care of the expert review. The shepherd > writeups almost always fail to mention anything about expert > review, IANA always asks in their last-call message ("IANA > Question -> has the document been reviewed by the Permanent > Message Header Field Names registry expert?", from the IANA > comments on draft-snell-http-prefer), and the shepherd/authors > usually don't respond. It then remains for someone (usually > the responsible AD or another AD who ballots a comment or > DISCUSS on it) to deal with this, and it's quite late in the > process (by now it's the last few days before the IESG > telechat where the document is meant to get final approval, > and we don't have the expert review yet). >... Barry, I agree (and have made the same observations), but I think part of this is a Shepherd (and instructions/advice to Shepherds) matter. Using your report and checklist format (which many readers of this list won't have seen, but they can probably get the gist), wouldn't it help if one of those checklist questions were something like "if Expert Review is called for, are the instructions to the Expert clear enough that he or she would know what to do and what criteria are appropriate to be applied, even if the Expert was not a participant in the WG or discussion leading to the document?" An honest "yes" answer would presumably solve much of the problem you describe. I still favor doing this because I think that having a single submission path (to IANA, rather than to different mailing lists or experts) is a good idea and that a unified tracking mechanism is an even better one. But, in terms of problems it would prevent or stop, I'd much rather see it (at least long-term) as preventing the occasional odd case from falling through the cracks than as a patch around failures in our specifications of review mechanisms. I say "long-term" because if, as a side-effect, it helps with some of those failures, that is obviously a benefit. john From dhc@dcrocker.net Sun Oct 7 07:32:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210DF21F86D8; Sun, 7 Oct 2012 07:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 fK5lj0OVRsOR; Sun, 7 Oct 2012 07:32:48 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B62A121F86D6; Sun, 7 Oct 2012 07:32:48 -0700 (PDT) Received: from [192.168.1.6] (adsl-67-127-59-48.dsl.pltn13.pacbell.net [67.127.59.48]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q97EWgwL032054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 7 Oct 2012 07:32:42 -0700 Message-ID: <5071928A.9010408@dcrocker.net> Date: Sun, 07 Oct 2012 07:32:42 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Glen Zorn References: <50161436.8080900@bbiw.net> <50694C10.4050508@gmail.com> <5069C58D.1090200@dcrocker.net> <507125D5.4050304@gmail.com> In-Reply-To: <507125D5.4050304@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 07 Oct 2012 07:32:45 -0700 (PDT) Cc: apps-discuss@ietf.org, dime mailing list , dcrocker@bbiw.net, draft-ietf-dime-rfc4005bis.all@tools.ietf.org, iesg Subject: Re: [apps-discuss] Review of: draft-ietf-dime-rfc4005bis-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 14:32:50 -0000 On 10/6/2012 11:48 PM, Glen Zorn wrote: > On 10/01/2012 11:32 PM, Dave Crocker wrote: > > When citing references, it is typical (and I believe essential) to > > have the citation text be specific about what it being used from the > > cited document. > > > > If what is being used is 'everything', then that's what is said. > > Explicitly. Language along the lines of "the current specification > > requires completely familiarity with: cite1, cite2, ... is typical. > > I've read a fair number of RFCs (though not all of them, by any means) > but I do not recall ever having encountered that language. I don't either. Specs usually describe the prior normative knowledge that is required. It's not typical to require as much as this one, such as taking knowledge of specialized terminology as a given, to the point of not declaring it explicitly. > > It also is not typical to require the reader to check the references > > section to find out what is normative and what isn't. That's why we > > have normative vocabulary. > > > > By requiring the reader to flip back and forth to the references > > section, to find out what is normative and what isn't, the > > specification is made markedly more cumbersome to use. > > Having ascertained what the normative references are, having read and > understood them, why would one need to flip back and forth? The flaw in the question is the "having ascertained". The usual form of citations is to the specific text that is used at a particular point. When an attorney cites a law, they don't simply say "Federal Code" or "California Code". They cite the specific sub-section. We try to do that for technical specifications, too. > > Documents need to define their normative context. There is benefit > > in making different documents minimize that context. Obviously > > documents that extend a service must rely on the foundation of that > > service, but the specification of an extension can be made more or > > less complicated by the way divide-and-conquor writing is done. > > Sorry, you've lost me. I was suggesting benefit in modularization with clean, limited, explicitly-defined interfaces, for specifications as well as software. > >> The centrality of AVPs to the operation of the Diameter protocol > >> might explain the focus of this draft upon them. > > > > My point was not that the use of attributes was unusual, but that the > > terminologic focus on what is essentially a syntactic aspect of the > > construct is unusual and, in my view, overly detailed. It's a bit > > like spelling out 'period' at the end of every sentence in a > > document. Distracting and unnecessary. > > > > And again, the term isn't defined in this document, in spite of there > > being a Terminology section. > > Again, the term is defined in RFC 3588. Again, the reader of the document doesn't have an explicit way to know that, since this is a specialized term and its importation from 3588 isn't declared. Specifications that have a default source for definitions usually state that explicitly. > >> One more time: read the normative references. Understand them. > >> All of them. > > > > Once again: say that. have the text cite them as musts for > > background and familiarity. > > OK, let's try a thought experiment: suppose that I had included a > (redundant) sentence like "The reader is assumed to have read and > understood all of the documents listed as normative references." in the > Abstract (& maybe, just to double-down on redundancy, in the > Introduction, too). Would you have actually done that as part of your > review? I did. Note, for example, that I made a point of citing some omissions in the current document that are not satisfied by knowledge of the underlying documents. > >>>> 1.6. Accounting Model > >>>> > >>>> It is RECOMMENDED that the coupled accounting model (Section > >>>> 9.3 of [I-D.ietf-dime-rfc3588bis]) be used with this > >>>> application; therefore, the value of the Acct-Application-Id > >>>> AVP in the Accounting-Request (Section 3.10) and > >>>> Accounting-Answer (Section 3.9) messages SHOULD be set to one > >>>> (1). > >>> > >>> All of the values in those two sections (except the "271") are > >>> symbolic. As such, setting a value to "1" has no obvious > >>> meaning. > >>> > >>> I assume that the issue would be fixed by using symbolic values > >>> here? > >> > >> Or by reading RFC 3588. > > > > Which part? > > The part that is, in this case, specifically referenced: Section 9.3, > reproduced below. > > 9.3. Accounting Application Extension and Requirements ... > Since the recommendation is to use the coupled accounting model, the > value of the Acct-Application-Id AVP should be set to the NASREQ > Application Id (1). I assume this is the specific text that you are referring to. In other words, the current draft is redundantly specifying normative detail, after already 'recommending' a controlling normative source. This is a good way to encourage divergent normative detail, over time. That is, the text after te semi-colon should be dropped. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From glenzorn@gmail.com Sat Oct 6 23:48:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480A721F8472; Sat, 6 Oct 2012 23:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, J_CHICKENPOX_51=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 9NEgDXuHfMMt; Sat, 6 Oct 2012 23:48:58 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFF121F844F; Sat, 6 Oct 2012 23:48:58 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so3190266pbb.31 for ; Sat, 06 Oct 2012 23:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C9SNFUuwPj5ePLgyvbx0YQpxcdo+mXJPaBv8vXcdLY4=; b=nvdt4E/YfTrBUkYxmgCLszGiTtpGAa+kesEFALNW/zf2eKjW7ff4ud/VDlJaiicPVT EamNvk4a0Iup/DSLCHfzYbA9frK0+T0w4j9N1ReLVx7/44r7GJm+XqyU1AJsNhSaGU51 F62WqiuIW0nxmgAhV2EHH6zoD2uWXQbTORV+VHsz1Zlz5tMDOkt+jV5aEyt1mQ3+EiMn dUe3nUeGL/AXqZGEqc75a60fThwgYY8Bo4zhqz0ow7gYPXyJCl+Oy/fg0sR+CIBTTW38 vrJGbN3HlDw2Lb1B6LzA9GWMNtb+YzD0S5RyG8yeb7oChZQX9cnm9kKaoLjzNr4KM4aX e7ew== Received: by 10.68.242.9 with SMTP id wm9mr43292570pbc.62.1349592537886; Sat, 06 Oct 2012 23:48:57 -0700 (PDT) Received: from [192.168.0.102] (ppp-115-87-90-243.revip4.asianet.co.th. [115.87.90.243]) by mx.google.com with ESMTPS id nd6sm5168011pbc.68.2012.10.06.23.48.54 (version=SSLv3 cipher=OTHER); Sat, 06 Oct 2012 23:48:57 -0700 (PDT) Message-ID: <507125D5.4050304@gmail.com> Date: Sun, 07 Oct 2012 13:48:53 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120914 Thunderbird/15.0.1 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <50161436.8080900@bbiw.net> <50694C10.4050508@gmail.com> <5069C58D.1090200@dcrocker.net> In-Reply-To: <5069C58D.1090200@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 07 Oct 2012 08:03:42 -0700 Cc: draft-ietf-dime-rfc4005bis.all@tools.ietf.org, apps-discuss@ietf.org, dime mailing list , iesg , Glen Zorn Subject: Re: [apps-discuss] Review of: draft-ietf-dime-rfc4005bis-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: Sun, 07 Oct 2012 06:48:59 -0000 On 10/01/2012 11:32 PM, Dave Crocker wrote: > Glen, et al, > > > On 10/1/2012 12:53 AM, Glen Zorn wrote: >> On 07/30/2012 11:57 AM, Dave Crocker wrote: >>>> 1. Introduction >>>> >>>> This document describes the Diameter protocol application used >>>> for AAA in the Network Access Server (NAS) environment. When >>>> combined with the Diameter Base protocol >>>> [I-D.ietf-dime-rfc3588bis], Transport Profile [RFC3539], and >>>> EAP [RFC4072] specifications, this specification satisfies the >>>> NAS-related requirements defined in Aboba, et al. [RFC2989] and >>>> Beadles & Mitton [RFC3169]. >>> >>> This assertion raises a dilemma: The cited documents are >>> extensive and the topic(s?) complex. There is no way to know what >>> details are being referred to, to evaluate the assertion. >> >> If there were only specific details that were relevant, only >> specific sections of the document would be cited. To evaluate the >> assertion read the cited documents. All of them. To understand >> this document, read and understand the normative references. All >> of them. > > Then that is what should be said in the specification. > > When citing references, it is typical (and I believe essential) to > have the citation text be specific about what it being used from the > cited document. > > If what is being used is 'everything', then that's what is said. > Explicitly. Language along the lines of "the current specification > requires completely familiarity with: cite1, cite2, ... is typical. I've read a fair number of RFCs (though not all of them, by any means) but I do not recall ever having encountered that language. > > >> My understanding, as expressed above, is that in order for a reader >> to expect to understand an RFC, they must first have read and >> understood the normative references. Is that incorrect? > > It depends upon what is being drawn from the references, and it is > the job of the referring text to explain its use of the reference. > > It also is not typical to require the reader to check the references > section to find out what is normative and what isn't. That's why we > have normative vocabulary. > > By requiring the reader to flip back and forth to the references > section, to find out what is normative and what isn't, the > specification is made markedly more cumbersome to use. Having ascertained what the normative references are, having read and understood them, why would one need to flip back and forth? > > >>> In general, this document's frequent use of "AVP" appears to be >>> an oddly syntactic focus. Typical specifications refer to >>> attributes, without such frequent, explicit reference to the form >>> of their having values. On its own, this point could seem like >>> quibbling, but it's part of the reaction I had when reading the >>> document, that is seemed less accessible than one would wish for >>> a new reader. >> >> This document is not intended to function as a primer on Diameter, >> AAA, or network access systems. > > Except that the document does provide /some/ primer material: > > The Diameter base protocol provides the following facilities: ... all > data delivered by the protocol is in the form of an AVP > > > Documents need to define their normative context. There is benefit > in making different documents minimize that context. Obviously > documents that extend a service must rely on the foundation of that > service, but the specification of an extension can be made more or > less complicated by the way divide-and-conquor writing is done. Sorry, you've lost me. > > >> The centrality of AVPs to the operation of the Diameter protocol >> might explain the focus of this draft upon them. > > My point was not that the use of attributes was unusual, but that the > terminologic focus on what is essentially a syntactic aspect of the > construct is unusual and, in my view, overly detailed. It's a bit > like spelling out 'period' at the end of every sentence in a > document. Distracting and unnecessary. > > And again, the term isn't defined in this document, in spite of there > being a Terminology section. Again, the term is defined in RFC 3588. > > >>> >>> >>>> by common usage. These are session identification, >>>> authentication, authorization, tunneling, and accounting. The >>>> authorization AVPs are further broken down by service type. >>> >>> This document appears to require deep knowledge of The Diameter >>> Base Protocol. In reality, I don't think this document can be >>> meaningfully read without that knowledge. So this document >>> should say that. (The language in the first paragraph of the >>> Intro doesn't actually say it.) >> >> One more time: read the normative references. Understand them. >> All of them. > > Once again: say that. have the text cite them as musts for > background and familiarity. OK, let's try a thought experiment: suppose that I had included a (redundant) sentence like "The reader is assumed to have read and understood all of the documents listed as normative references." in the Abstract (& maybe, just to double-down on redundancy, in the Introduction, too). Would you have actually done that as part of your review? > > >>>> 1.6. Accounting Model >>>> >>>> It is RECOMMENDED that the coupled accounting model (Section >>>> 9.3 of [I-D.ietf-dime-rfc3588bis]) be used with this >>>> application; therefore, the value of the Acct-Application-Id >>>> AVP in the Accounting-Request (Section 3.10) and >>>> Accounting-Answer (Section 3.9) messages SHOULD be set to one >>>> (1). >>> >>> All of the values in those two sections (except the "271") are >>> symbolic. As such, setting a value to "1" has no obvious >>> meaning. >>> >>> I assume that the issue would be fixed by using symbolic values >>> here? >> >> Or by reading RFC 3588. > > Which part? The part that is, in this case, specifically referenced: Section 9.3, reproduced below. 9.3. Accounting Application Extension and Requirements Each Diameter application (e.g., NASREQ, Mobile IP) SHOULD define its service-specific AVPs that MUST be present in the Accounting-Request message in a section titled "Accounting AVPs". The application MUST assume that the AVPs described in this document will be present in all Accounting messages, so only their respective service-specific AVPs need to be defined in that section. Applications have the option of using one or both of the following accounting application extension models: Split Accounting Service The accounting message will carry the Application Id of the Diameter base accounting application (see Section 2.4). Accounting messages may be routed to Diameter nodes other than the corresponding Diameter application. These nodes might be centralized accounting servers that provide accounting service for multiple different Diameter applications. These nodes MUST advertise the Diameter base accounting Application Id during capabilities exchange. Coupled Accounting Service The accounting message will carry the Application Id of the application that is using it. The application itself will process the received accounting records or forward them to an accounting server. There is no accounting application advertisement required during capabilities exchange, and the accounting messages will be routed the same way as any of the other application messages. In cases where an application does not define its own accounting service, it is preferred that the split accounting model be used. Since the recommendation is to use the coupled accounting model, the value of the Acct-Application-Id AVP should be set to the NASREQ Application Id (1). > in my review I tried to make clear that I actually had > looked in RFC 3588 to resolve questions about the text I was > reviewing. Had that succeeded I would have made more specific > suggestions for resolving specific issues. > > So, for the current case, the word 'symbolic' appears in RFC 3588 > exactly one time, for icmptypes types, very deep in Section 4.3. I > did not find it at all helpful for resolving the point I raised here > in the review. > > > Just to check, it appears the response to the review ended with this > item. Yes, it was frankly very difficult to find anything that wasn't covered by either RTFRFC or a stylistic quibble. I gave up. > > d/ From wmills@yahoo-inc.com Sun Oct 7 08:43:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E987621F86FC for ; Sun, 7 Oct 2012 08:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.507 X-Spam-Level: X-Spam-Status: No, score=-17.507 tagged_above=-999 required=5 tests=[AWL=0.091, 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 KFtj9ZRLQ-S0 for ; Sun, 7 Oct 2012 08:43:55 -0700 (PDT) Received: from nm21-vm0.bullet.mail.sp2.yahoo.com (nm21-vm0.bullet.mail.sp2.yahoo.com [98.139.91.220]) by ietfa.amsl.com (Postfix) with SMTP id 48E1D21F86F7 for ; Sun, 7 Oct 2012 08:43:55 -0700 (PDT) Received: from [98.139.91.63] by nm21.bullet.mail.sp2.yahoo.com with NNFMP; 07 Oct 2012 15:43:48 -0000 Received: from [72.30.22.76] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 07 Oct 2012 15:43:48 -0000 Received: from [127.0.0.1] by omp1070.mail.sp2.yahoo.com with NNFMP; 07 Oct 2012 15:43:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 637185.66576.bm@omp1070.mail.sp2.yahoo.com Received: (qmail 65873 invoked by uid 60001); 7 Oct 2012 15:43:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1349624628; bh=/Hbsp+VaIOqVIkChmd4vjhWjMnYLhoXaHKkIEFSwtSE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=j6/hOp08mCnxvn6qN9wJrnL+mSMsZc3D77VPQwudQYXTJPjLYzVHVLaeLSxMj5vizKCl233k4orXMdTdKcdl+bkdRfYoY1a+xh6o5j29BkGvIbVgtIwYmNO/S3Kvmy5/6VEGY3vd5Yv0MJ2WMvrW0MZkRI1sOiRgWMp/QJsX9DY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Q6qHm9xVZ5GQ32P/jwf1Zg3pj4V1OAXE78xDyVMCGn+rg5URgtO0WhF37OeRWdJqsV3moy6G1tDBibLvUlFkp3aMPizcwy3UzPp2BLBXv06Ozpe0BOIFGkLTDk57tB+D49Fn+0Po13N5XffpMsVuIxGVuWeWp2voP2wYsOXCztc=; X-YMail-OSG: jeb7B9wVM1lL3ODm25w_6ePEdQowpnhYhFPMEZDL3EiEPOV 7a3krpE2VYFjm9HFYim_85QHbmjW5gAtzjqloOxSk.UoQ9nJOhg.eUKX5hwN XvUL8c9djFj0KuBG1R8duS6kZFPwrkuCjx3gn.y6_NlpEbxkiJEJsQ4adGkx 1hc1FLDr7FZdXInILhg1q9V9HkUFmNVjAljMDu.cAYVwiIZ52lmGrWK4xVuQ VJleqC1.yWOoqzQ7hA1iaV3coeSu55AXqJ7SrSmM8SMFR05Whxm0klxoPrCj 14TBIyeC1RN5_9N9eiI3HCuXrL0Fu9gqMWkRDiVcqaydvbkh3vMRVAIxEbuW 3ZksDuXl5leNfsrNFvT3GqROzmqVYUN6cTk4_nDPxYuWNcaFMz.ADP_ZCABP q5Ua2xBVhCSTCb7NNZoZvej4Ixxk1pgT_CP6ln7KvJa8by97fXsj0YNwehqN _YVb0mSMo_r4- Received: from [99.31.212.42] by web31807.mail.mud.yahoo.com via HTTP; Sun, 07 Oct 2012 08:43:47 PDT X-Rocket-MIMEInfo: 001.001, VGhlcmUgaGFzIGJlZW4gb25lIGZ1cnRoZXIgcmV2aWV3IG9mIHRoaXMgKHRoYW5rcyBNYXJrKSBhbmQgdGhlIHRpdGxlIGhhcyBiZWVuIGNvcnJlY3RlZCAoYXMgaGFzIHRoZSBzdWJqZWN0IGxpbmUgb2YgdGhpcyBtZXNzYWdlKS7CoCBBcyBhbiBpbmRpdmlkdWFsIHN1Ym1pc3Npb24gZG9lcyB0aGlzIGdldCBhIFdHTEMgdGhyb3VnaCB0aGlzIFdHP8KgIAoKVGhhbmtzLAoKLWJpbGwKCgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBXaWxsaWFtIE1pbGxzIDx3bWlsbHNAeWEBMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.123.450 References: <1349107955.29811.YahooMailNeo@web31813.mail.mud.yahoo.com> Message-ID: <1349624627.64105.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Sun, 7 Oct 2012 08:43:47 -0700 (PDT) From: William Mills To: Apps Discuss In-Reply-To: <1349107955.29811.YahooMailNeo@web31813.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-903211268-1349624627=:64105" Subject: Re: [apps-discuss] Link type registration for OAuth draft 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: Sun, 07 Oct 2012 15:43:56 -0000 ---125733401-903211268-1349624627=:64105 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable There has been one further review of this (thanks Mark) and the title has b= een corrected (as has the subject line of this message).=A0 As an individua= l submission does this get a WGLC through this WG?=A0 =0A=0AThanks,=0A=0A-b= ill=0A=0A=0A=0A=0A=0A>________________________________=0A> From: William Mi= lls =0A>To: Apps Discuss =0A>= Sent: Monday, October 1, 2012 9:12 AM=0A>Subject: Link type registry for OA= uth draft=0A> =0A>=0A>I think the link registry for OAuth 2 is pretty close= to done, especially with Goix Laurent Walter's recent review.=A0 If one or= two more folks could give it a read that would be great.=0A>=0A>=0A>http:/= /tools.ietf.org/id/draft-wmills-oauth-lrdd-03.html=0A>=0A>=0A>Thanks,=0A>= =0A>=0A>-bill=0A>=0A>=0A> ---125733401-903211268-1349624627=:64105 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
There has= been one further review of this (thanks Mark) and the title has been corre= cted (as has the subject line of this message).  As an individual subm= ission does this get a WGLC through this WG? 

Thanks,

-= bill


From: William Mills <wmills@yahoo-inc.com>
To: Apps Discuss <apps-discuss@ietf.org>
S= ent: Monday, October 1, 2012 9:12 AM
Subject: Link type registry for OAuth draft
<= /font>

I think the link registry for OAuth 2 is pr= etty close to done, especially with Goix Laurent Walter's recent review.&nb= sp; If one or two more folks could give it a read that would be great.

http://tools.ietf.org/id/draft-wmills-oaut= h-lrdd-03.html

Thanks,
<= div style=3D"color:rgb(0, 0, 0);font-size:18.6667px;font-family:Courier New= , courier, monaco, monospace, sans-serif;background-color:transparent;font-= style:normal;">
-bill
<= br>
---125733401-903211268-1349624627=:64105-- From sm@resistor.net Sun Oct 7 09:04:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6CC21F870A for ; Sun, 7 Oct 2012 09:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 g8nZInr4h9bE for ; Sun, 7 Oct 2012 09:04:55 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 344AE21F8707 for ; Sun, 7 Oct 2012 09:04:55 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q97G4mkf021818; Sun, 7 Oct 2012 09:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1349625893; bh=LowSrpbTiTPFPNc27c3K7OyansnF0WLdOHacdH9yhlk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Q5o76eZXHbkBhAU7rjsR4zRBKtQ2PK86SiAM9ajlZ37o/5X+7Xl2CZWulYa1OMob1 E4LsLZo39WdRnoaIeiBB7mp4y7g3u/UnYa36ymQfcEkJXG/7/Pcl6BsDOZMweQkRu2 hJFeaawdUfFiXpBHXs/dbjRZvPnOz/WSDGaoKdKo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1349625893; i=@resistor.net; bh=LowSrpbTiTPFPNc27c3K7OyansnF0WLdOHacdH9yhlk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=4W/DcOdxJdAWJJCWIGkdJTWVac7GNoVxlA7HNTqVN5WTK9aWnp3TBb4+BgcNk+76Z dF7wtq59iiUfYEiTYUAD8WYN0f7tMpJMQVwRLw5aVWmMJpzcGPyOcftHvRUVaEaDsy 6cf8wpyyOAiuGaPe8Gfgo4ftnRMGHWeBnlRCLXhI= Message-Id: <6.2.5.6.2.20121007084843.0a2b12f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 07 Oct 2012 09:04:48 -0700 To: William Mills From: SM In-Reply-To: <1349624627.64105.YahooMailNeo@web31807.mail.mud.yahoo.com> References: <1349107955.29811.YahooMailNeo@web31813.mail.mud.yahoo.com> <1349624627.64105.YahooMailNeo@web31807.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Apps Discuss Subject: Re: [apps-discuss] Link type registration for OAuth draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2012 16:04:56 -0000 Hi Bill, At 08:43 07-10-2012, William Mills wrote: >There has been one further review of this (thanks Mark) and the >title has been corrected (as has the subject line of this >message). As an individual submission does this get a WGLC through this WG? No. A working group would have to adopt the draft for it to go through a WGLC. I'll send some quick nits. The text in the Abstract Section needs to be reworded. The title mentions "OAuth 2" while there is text about "OAuth 1a" in the draft. In Section 2: "In examplesl ine breaks have been inserted for readability." This is a typo. I don't see why RFC 2119 key words are used in the IANA Considerations section. The draft has examples in Section 5. I don't see what that has to do with registries. Section 3 mentions that: "This document is informational, defining values in existing registries, and as such has no security properties to discuss." Regards, -sm From salvatore.loreto@ericsson.com Sun Oct 7 09:39:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AC021F86EA for ; Sun, 7 Oct 2012 09:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.974 X-Spam-Level: X-Spam-Status: No, score=-106.974 tagged_above=-999 required=5 tests=[AWL=-0.726, 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 yztD-1fWoWHt for ; Sun, 7 Oct 2012 09:39:13 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 44A2321F86E8 for ; Sun, 7 Oct 2012 09:39:13 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-79-5071b02052f7 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 74.38.25676.020B1705; Sun, 7 Oct 2012 18:38:56 +0200 (CEST) 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; Sun, 7 Oct 2012 18:38:55 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CF9722AD7 for ; Sun, 7 Oct 2012 19:38:55 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3E2C2537C1 for ; Sun, 7 Oct 2012 19:38:55 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D91F453464 for ; Sun, 7 Oct 2012 19:38:54 +0300 (EEST) Message-ID: <5071B01E.7050500@ericsson.com> Date: Sun, 7 Oct 2012 19:38:54 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net> <503CDF26.8050000@aol.com> <02a301cd8551$be7ab390$3b701ab0$@packetizer.com> <3BE24613-9CA0-4B2C-AB33-274026D534FB@ve7jtb.com> <032d01cd8597$aac7f740$0057e5c0$@packetizer.com> <04f001cd8627$092727e0$1b7577a0$@packetizer.com> <90420743-8FE8-4EDB-98EF-D717D5346397@frobbit.se> <1346306587.53748.YahooMailNeo@web31804.mail.mud.yahoo.com> <251A4741-1E52-41D3-B4C8-43BEDE5C79B7@ve7jtb.com> <50614259.2040504@packetizer.com> In-Reply-To: <50614259.2040504@packetizer.com> Content-Type: multipart/alternative; boundary="------------080706030107050906080007" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+Jvra7ChsIAgwdfrCxWv1zB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujH+/jzIXzJGsWHPtH1sDY6tIFyMnh4SAicTx9Z/YIWwxiQv3 1rN1MXJxCAmcYpTY97iZEcJZzygx4/5PVgjnOqPEncU9rHBlc44uZ4dwLjNKbP79lQ1kGK+A tsTEZyvBbBYBFYkP874wgdhsAmYSzx9uYQaxRQWSJXrn72SEqBeUODnzCQuILSIgKbFv1mSw GmEBA4ntf44yQyw4zS7xbfYtVpAEp4CexMkF98EuZxYIk1j3bD0rxBdqElfPbQJrFhLQkug9 28k0gVF4FpIds5C0QNi2EhfmXIeKy0tsfzuHGcLWlbjwfwqK+AJGtlWMwrmJmTnp5UZ6qUWZ ycXF+Xl6xambGIGRcXDLb9UdjHfOiRxilOZgURLntd66x19IID2xJDU7NbUgtSi+qDQntfgQ IxMHp1QDo/4tDZONmvPee+uZvD49yXj5/i7xHA23szPM831X5BYe1j2ZOTEg4+2+bhOxXI4/ DItqVFtXcBgZyG898Pr79p+b+K/Pm/VlUuiHkpKHRipfTGJvp69+LbBf7q+PwaGuSZeaTn+s er1hwR2+jT5aD54tOZC2/Vqh70X2bcFfDm04r5vs63bob5ESS3FGoqEWc1FxIgDWRuuEWgIA AA== Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 16:39:15 -0000 --------------080706030107050906080007 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 9/25/12 8:34 AM, Paul E. Jones wrote: > On 9/11/2012 11:49 AM, John Bradley wrote: >> Nat, >> >> TuCows supports SRV records at least for openSRS. Some of there resellers may be using other things to manage DNS recodes and just using them for registration, so it would be hard to make a blanket statement. >> >> I think using a SRV record introduces other security issues that would have to be looked at without DNSsec. >> >> John B. > I think this is true regardless. DNSSEC should be a top priority for > anyone, really. Otherwise, there exists the risk of having the domain > requests hijacked. And if one can do that, they can probably get > certificates for the hijacked domains. > > Paul > I share the same concerns about the possibility to introduce security issues that would have to be looked if we go for SRV record without DNSsec. Having said that, what I would like to understand at this point is how important is to solve the issue of domains "not able to use 3xx redirect requests" /Salvatore -- Salvatore Loreto, PhD www.sloreto.com --------------080706030107050906080007 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 9/25/12 8:34 AM, Paul E. Jones wrote:
On 9/11/2012 11:49 AM, John Bradley wrote:

Nat,

TuCows supports SRV records at least for openSRS.   Some of there resellers may be using other things to manage DNS recodes and just using them for registration, so it would be hard to make a blanket statement.

I think using a SRV record introduces other security issues that would have to be looked at without DNSsec.

John B.

I think this is true regardless. DNSSEC should be a top priority for 
anyone, really.  Otherwise, there exists the risk of having the domain 
requests hijacked.  And if one can do that, they can probably get 
certificates for the hijacked domains.

Paul
I share the same concerns about the possibility to introduce security issues that would have to be looked
if we go for SRV record without DNSsec.

Having said that, what I would like to understand at this point is how important is to solve
the issue of domains "not able to use 3xx redirect requests"

/Salvatore

 
-- 
Salvatore Loreto, PhD
www.sloreto.com
--------------080706030107050906080007-- From salvatore.loreto@ericsson.com Sun Oct 7 10:59:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A88021F86D8 for ; Sun, 7 Oct 2012 10:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.792 X-Spam-Level: X-Spam-Status: No, score=-106.792 tagged_above=-999 required=5 tests=[AWL=-0.544, 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 s7-TIYumVNH1 for ; Sun, 7 Oct 2012 10:59:31 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 232A321F86D6 for ; Sun, 7 Oct 2012 10:59:30 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-9b-5071c3019fb4 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 41.18.17130.103C1705; Sun, 7 Oct 2012 19:59:30 +0200 (CEST) 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; Sun, 7 Oct 2012 19:59:29 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7A9A82AD7 for ; Sun, 7 Oct 2012 20:59:29 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A75B4537C1 for ; Sun, 7 Oct 2012 20:59:28 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6093053464 for ; Sun, 7 Oct 2012 20:59:28 +0300 (EEST) Message-ID: <5071C300.4000404@ericsson.com> Date: Sun, 7 Oct 2012 20:59:28 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4E1F6AAD24975D4BA5B1680429673943667C07CC@TK5EX14MBXC284.redmond.corp.microsoft.com> <50614409.4040608@packetizer.com> In-Reply-To: <50614409.4040608@packetizer.com> Content-Type: multipart/alternative; boundary="------------030300040408090703000404" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+JvrS7T4cIAgzUT2CxWv1zB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAtrtjMWvDKo+HuzjbWB8a1qFyMnh4SAicSNprNMELaYxIV7 69m6GLk4hAROMUpcXnGVCcJZzyjRdP0cI0iVkMB1Romnl6TgqiZ+6WGBcC4zSny9do4NpIpX QFti+opHLCA2i4CKxP7L/9hBbDYBM4nnD7cwg9iiAskSvfN3MkLUC0qcnPkErF5EQFJi36zJ YDXCAlYSyw6+ZoXY3MQocfpdbRcjBwengJ7EhA/mIGFmgTCJP9NXMkK8oCZx9dwmZohyLYne s51MExiFZyHZMAtJyyygScwC9hIPtpZBhOUlmrfOZoaw9SWu37nPiiy+gJFtFaNwbmJmTnq5 uV5qUWZycXF+nl5x6iZGYEQc3PLbYAfjpvtihxilOViUxHn1VPf7CwmkJ5akZqemFqQWxReV 5qQWH2Jk4uCUamBUKU77scrkp7NUV6u2Xvar7+wxKV7vQ2ueCColq0fXPt/g3jblmZDUF3XW r2vOPJ00v63t0ASFlAIekQ1HXJrnqp47eSpuA19I3d3blWv/ls2cJt42zyXZTveh+xu1lR/9 Ztp03uyb3jGb78E0LpdlDy/5bPF1+jBvUZBxelXBxx9cVosYkh4rsRRnJBpqMRcVJwIAz55j Q1YCAAA= Subject: Re: [apps-discuss] WebFinger should be HTTPS only X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 17:59:33 -0000 --------------030300040408090703000404 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit On 9/25/12 8:41 AM, Paul E. Jones wrote: > On 9/11/2012 1:43 PM, Mike Jones wrote: >> >> Having looked at the WebFinger specification a bit more, I recently >> realized that it currently does not require TLS to be used. Section >> 5.1 - Performing a WebFinger Query – currently begins “The first step >> a client must perform in executing a WebFinger query is to query for >> the host metadata using HTTPS or HTTP”. This concerns me, since this >> may enable classes of phishing attacks in some situations. >> >> I would therefore request that the specification be updated to >> prohibit non-TLS connections. >> >> Thank you, >> >> -- Mike >> > > Mike, > > The spec currently recommends the use of HTTPS, as did RFC 6415 > (referenced right after the text you highlight). I do not believe we > can mandate HTTPS. There may be private networks that use WebFinger > that do not need HTTPS. There will definitely be those who do not > want to pay for the certificate to protect WebFinger. We can strongly > recommend use of HTTPS, but I don't think we can mandate it. > > Paul > Hi there, I tend to agree with with Paul and Evan, in the case TLS is required we have the text in RFC6415 Here's the language from RFC 6415: Applications utilizing the host-meta document where the authenticity of the information is necessary MUST require the use of the HTTPS protocol and MUST NOT produce a host-meta document using other means. perhaps it would be a good idea to insert a similar text in WebFinger draft to stress the point. /Salvatore -- Salvatore Loreto, PhD www.sloreto.com --------------030300040408090703000404 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit
On 9/25/12 8:41 AM, Paul E. Jones wrote:
On 9/11/2012 1:43 PM, Mike Jones wrote:

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

 

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

 

                                                            Thank you,

                                                            -- Mike


Mike,

The spec currently recommends the use of HTTPS, as did RFC 6415 (referenced right after the text you highlight).  I do not believe we can mandate HTTPS.  There may be private networks that use WebFinger that do not need HTTPS.  There will definitely be those who do not want to pay for the certificate to protect WebFinger.  We can strongly recommend use of HTTPS, but I don't think we can mandate it.

Paul

Hi there,

I tend to agree with with Paul and Evan, in the case TLS is required we have the text in RFC6415
Here's the language from RFC 6415:
   Applications utilizing the host-meta document where the authenticity
   of the information is necessary MUST require the use of the HTTPS
   protocol and MUST NOT produce a host-meta document using other means.

perhaps it would be a good idea to insert a similar text in WebFinger draft
to stress the point.

/Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com
--------------030300040408090703000404-- From wmills@yahoo-inc.com Sun Oct 7 11:47:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFD521F86E8 for ; Sun, 7 Oct 2012 11:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.513 X-Spam-Level: X-Spam-Status: No, score=-17.513 tagged_above=-999 required=5 tests=[AWL=0.085, 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 KHBH41eClP0p for ; Sun, 7 Oct 2012 11:47:09 -0700 (PDT) Received: from nm4-vm0.bullet.mail.ac4.yahoo.com (nm4-vm0.bullet.mail.ac4.yahoo.com [98.139.53.206]) by ietfa.amsl.com (Postfix) with SMTP id 0C99B21F86D8 for ; Sun, 7 Oct 2012 11:47:08 -0700 (PDT) Received: from [98.139.52.195] by nm4.bullet.mail.ac4.yahoo.com with NNFMP; 07 Oct 2012 18:47:05 -0000 Received: from [98.139.52.142] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 07 Oct 2012 18:47:05 -0000 Received: from [127.0.0.1] by omp1025.mail.ac4.yahoo.com with NNFMP; 07 Oct 2012 18:47:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 365036.68221.bm@omp1025.mail.ac4.yahoo.com Received: (qmail 24764 invoked by uid 60001); 7 Oct 2012 18:47:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1349635624; bh=MnGJ7cNaZZvp9ZOkRR9I11SIe76TbEV175rUy2Wv9Bo=; 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=tbWfCW+oHfVsqPcWc7pcyzuBF6I10CwqTTg5eEt9lugfs/j7hj9uQZTEgJjmtR2BTEPPN5oB6rRiaAU2qRn2oxnWFXh1sdR0H3gCorFiUWpUesshC8MrRxbxP3OM1w66zyOQ2CDZDtKHF014g26AbEokimCibu/5vrYqkL412fs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.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=f+rbFfm126dtS92fwASpA0bhpbx0R2o27CIA28L7lNa293j7cqR8Y+EJd8LOn+w1zBApcg4PjO0UoXec4PqtfAHNyuhuD9Qp4ObVePx28JxlB++fZP+bMwTExmtqzsAkS+mOwiMoRY8y8q2vc6P57PW+WxTO4VA+ms7K8Ao3Nf0=; X-YMail-OSG: 6MzmZ3QVM1m_3u1LwLCb9tNAp6ap81te2i8mfRjJT_rL9O7 IzX.lrEzF5XqRVp1T.UpYG9cG6ZL5Nd7vOoOgWOpY2XqkfWZgWJbvkXH_suY KBgEDOvsYy_GkjJoLsQezScXmDERgQ6kogcjd7t_VJsmMl.gY7IYDY4BqwQe o29uiplh_m4.HKIOvLxiUHPG6jGvh2H9QRIkSVp_w9kXO0j4p4tCEOKUEq7b 17.z9ApeBRs3re6jDXb9NOKZ1aP_9aSoyCJz.e.3PimmTeZwt5HVUeiW.tsT _1imw3CsPrIEj2W7X0Dso99Wup3jAmDpz2hozPFPbZVJ0LhMxLiatTsY2dV8 X876fdneoD5DkrMAcmszs4U.1TUZUOB4hoAWVmuiTYJQW6dZP5WjdlgmqEsy rpv2bwyNEYBp1fypBOpnfpshxMOCp0E4hsuIKIjMMLbi5fT3_OtkhwS3MqsS 1I_ZUd_cqBZY- Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Sun, 07 Oct 2012 11:47:04 PDT X-Rocket-MIMEInfo: 001.001, U28gZXhhbXBsZXMgYXJlIG5vdCBuZWVkZWQgaGVyZT8KCgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBTTSA8c21AcmVzaXN0b3IubmV0Pgo.VG86IFdpbGxpYW0gTWlsbHMgPHdtaWxsc0B5YWhvby1pbmMuY29tPiAKPkNjOiBBcHBzIERpc2N1c3MgPGFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4gCj5TZW50OiBTdW5kYXksIE9jdG9iZXIgNywgMjAxMiA5OjA0IEFNCj5TdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gTGluayB0eXBlIHJlZ2lzdHJhdGlvbiBmb3IgT0F1dGggZHIBMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.123.450 References: <1349107955.29811.YahooMailNeo@web31813.mail.mud.yahoo.com> <1349624627.64105.YahooMailNeo@web31807.mail.mud.yahoo.com> <6.2.5.6.2.20121007084843.0a2b12f0@resistor.net> Message-ID: <1349635624.2048.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Sun, 7 Oct 2012 11:47:04 -0700 (PDT) From: William Mills To: SM In-Reply-To: <6.2.5.6.2.20121007084843.0a2b12f0@resistor.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-344368827-1349635624=:2048" Cc: Apps Discuss Subject: Re: [apps-discuss] Link type registration for OAuth draft 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: Sun, 07 Oct 2012 18:47:10 -0000 --764183289-344368827-1349635624=:2048 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable So examples are not needed here?=0A=0A=0A=0A=0A=0A>________________________= ________=0A> From: SM =0A>To: William Mills =0A>Cc: Apps Discuss =0A>Sent: Sunday, Oct= ober 7, 2012 9:04 AM=0A>Subject: Re: [apps-discuss] Link type registration = for OAuth draft=0A> =0A>Hi Bill,=0A>At 08:43 07-10-2012, William Mills wrot= e:=0A>> There has been one further review of this (thanks Mark) and the tit= le has been corrected (as has the subject line of this message).=A0 As an i= ndividual submission does this get a WGLC through this WG?=0A>=0A>No.=A0 A = working group would have to adopt the draft for it to go through a WGLC.=A0= I'll send some quick nits.=0A>=0A>The text in the Abstract Section needs t= o be reworded.=A0 The title mentions "OAuth 2" while there is text about "O= Auth 1a" in the draft.=0A>=0A>In Section 2:=0A>=0A>=A0 "In examplesl ine br= eaks have been inserted for readability."=0A>=0A>This is a typo.=0A>=0A>I d= on't see why RFC 2119 key words are used in the IANA Considerations section= .=A0 The draft has examples in Section 5.=A0 I don't see what that has to d= o with registries.=A0 Section 3 mentions that:=0A>=0A>=A0 "This document is= informational, defining values in existing=0A>=A0 registries, and as such= has no security properties to discuss."=0A>=0A>Regards,=0A>-sm =0A>=0A>=0A= > --764183289-344368827-1349635624=:2048 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
So exampl= es are not needed here?

From: SM <sm@resistor.net>
<= span style=3D"font-weight: bold;">To: William Mills <wmills@y= ahoo-inc.com>
Cc: A= pps Discuss <apps-discuss@ietf.org>
Sent: Sunday, October 7, 2012 9:04 AM
Subject: Re: [apps-discuss] Link type registration for O= Auth draft

Hi Bill,
At 08:43 07-10-2012, William = Mills wrote:
> There has been one further review of this (thanks Mark= ) and the title has been corrected (as has the subject line of this message= ).  As an individual submission does this get a WGLC through this WG?<= br>
No.  A working group would have to adopt the draft for it to go= through a WGLC.  I'll send some quick nits.

The text in the Ab= stract Section needs to be reworded.  The title mentions "OAuth 2" whi= le there is text about "OAuth 1a" in the draft.

In Section 2:
  "In examplesl ine breaks have been inserted for readability."
This is a typo.

I don't see why RFC 2119 key words are used in the= IANA Considerations section.  The draft has examples in Section 5.&nb= sp; I don't see what that has to do with registries.  Section 3 mentions that:

  "This document is informational, defining val= ues in existing
  registries, and as such has no security properti= es to discuss."

Regards,
-sm


--764183289-344368827-1349635624=:2048-- From wmills@yahoo-inc.com Sun Oct 7 11:52:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BBE21F86F5 for ; Sun, 7 Oct 2012 11:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.518 X-Spam-Level: X-Spam-Status: No, score=-17.518 tagged_above=-999 required=5 tests=[AWL=0.079, 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 EHBIpw0ZWrjR for ; Sun, 7 Oct 2012 11:52:38 -0700 (PDT) Received: from nm25-vm4.bullet.mail.ne1.yahoo.com (nm25-vm4.bullet.mail.ne1.yahoo.com [98.138.91.185]) by ietfa.amsl.com (Postfix) with SMTP id B0DD421F86F4 for ; Sun, 7 Oct 2012 11:52:38 -0700 (PDT) Received: from [98.138.226.177] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 07 Oct 2012 18:52:25 -0000 Received: from [98.138.88.239] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 07 Oct 2012 18:52:25 -0000 Received: from [127.0.0.1] by omp1039.mail.ne1.yahoo.com with NNFMP; 07 Oct 2012 18:52:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 686575.88226.bm@omp1039.mail.ne1.yahoo.com Received: (qmail 69496 invoked by uid 60001); 7 Oct 2012 18:52:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1349635945; bh=QLbw6urEkSx7qhwAi56ZwhiwaKhwcNGUagmQcQ1UMYg=; 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=XOpPATLfaFqd8537EgCkHwDcwfMVD44WdTaGpA9L/+w2uhPGso+W052YKRWAzLAYcUutkrxyiHOsthdo/Nsurfcohvx438oC13G9VF9N/3n8n2KKm7pKMnir0o1UeEULDcwVGGLCzRIslPcuraQzBc/gFspzbeb4MtD7sLeM6Gg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.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=YQXyEPVrOoq8qlYP4IUBT5MhClnWG8MZs2usZL62VoY9GS3l0Ms7Cw6pMlsm1mWeTp6T4eL/2jNDtWdXZneG0OsuKxEpFnfRiu0qCNRBwTPOIDF4+IRGR/rOu4sL2jmgM6/PJMpoGHfiBkjBZbzBLxIyCK9T82OqOIN8rI6l8oQ=; X-YMail-OSG: pvB1S5IVM1mkooeAu8XJezE4_m5QOpVVlpYCOEFSiscjDkR ifSLiU7frRZC9irqflzJjtsjkqdjOVUvGVh6Ew0ihkUEKnRlLWanQ3LPq5A8 M7l4YIn1bm5QkMXmistRQboN1siQbjNHrB7_rl8f2o2oQhYGgf.owvp.jHkf 03MTMsvYNlzaJKe6iOLNjbh9Q.NpYtEjrx1jI_qJUWKRvfaLKjVLAYr7i6YW FwsoCEOr6w0Vhqb5JU29GTKLB.SiSCa7oTKh2R08tcNuP5O__0YzSpX7hYvL y.314ddkRiAuv_DLk9XqvyAIb.vHKnTW_.ujLBP4CO_1V.gEJ1ek27r_Ty.q x3LHe9lij6hAhTU.LjMc3nlBuNyVtsVvUlWXIJKNE6GawNdr6kwm_nhdADnN Oh4poeyNMtdHfML98S6ZGvilyaHuBFGGAiEXmbXkgP.KMv_namMqxa4loblb iJ8cH.W_h3dE- Received: from [99.31.212.42] by web31816.mail.mud.yahoo.com via HTTP; Sun, 07 Oct 2012 11:52:24 PDT X-Rocket-MIMEInfo: 001.001, Rml4ZWQgdGhlIDIgb2J2aW91cyBjb3JyZWN0aW9ucywgdGhhbmsgeW91LgoKQ2FuIGFuIGluZGl2aWR1YWwgc3VibWlzc2lvbiBwcm9jZWVkIHdpdGhvdXQgYSBXRz_CoCBJZiBzbyBob3cgZG8gSSBkbyB0aGF0P8KgIE9yIGlzIEFwcHMgd2lsbGluZyB0byB0YWtlIHRoaXMgdXA_CgoKCgoKPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRnJvbTogU00gPHNtQHJlc2lzdG9yLm5ldD4KPlRvOiBXaWxsaWFtIE1pbGxzIDx3bWlsbHNAeWFob28taW5jLmNvbT4gCj5DYzogQXBwcyBEaXNjdXNzIDwBMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.123.450 References: <1349107955.29811.YahooMailNeo@web31813.mail.mud.yahoo.com> <1349624627.64105.YahooMailNeo@web31807.mail.mud.yahoo.com> <6.2.5.6.2.20121007084843.0a2b12f0@resistor.net> Message-ID: <1349635944.69442.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Sun, 7 Oct 2012 11:52:24 -0700 (PDT) From: William Mills To: SM In-Reply-To: <6.2.5.6.2.20121007084843.0a2b12f0@resistor.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-1189699046-1349635944=:69442" Cc: Apps Discuss Subject: Re: [apps-discuss] Link type registration for OAuth draft 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: Sun, 07 Oct 2012 18:52:39 -0000 ---1238014912-1189699046-1349635944=:69442 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Fixed the 2 obvious corrections, thank you.=0A=0ACan an individual submissi= on proceed without a WG?=A0 If so how do I do that?=A0 Or is Apps willing t= o take this up?=0A=0A=0A=0A=0A=0A>________________________________=0A> From= : SM =0A>To: William Mills =0A>Cc: = Apps Discuss =0A>Sent: Sunday, October 7, 2012 9:04= AM=0A>Subject: Re: [apps-discuss] Link type registration for OAuth draft= =0A> =0A>Hi Bill,=0A>At 08:43 07-10-2012, William Mills wrote:=0A>> There h= as been one further review of this (thanks Mark) and the title has been cor= rected (as has the subject line of this message).=A0 As an individual submi= ssion does this get a WGLC through this WG?=0A>=0A>No.=A0 A working group w= ould have to adopt the draft for it to go through a WGLC.=A0 I'll send some= quick nits.=0A>=0A>The text in the Abstract Section needs to be reworded.= =A0 The title mentions "OAuth 2" while there is text about "OAuth 1a" in th= e draft.=0A>=0A>In Section 2:=0A>=0A>=A0 "In examplesl ine breaks have been= inserted for readability."=0A>=0A>This is a typo.=0A>=0A>I don't see why R= FC 2119 key words are used in the IANA Considerations section.=A0 The draft= has examples in Section 5.=A0 I don't see what that has to do with registr= ies.=A0 Section 3 mentions that:=0A>=0A>=A0 "This document is informational= , defining values in existing=0A>=A0 registries, and as such has no securi= ty properties to discuss."=0A>=0A>Regards,=0A>-sm =0A>=0A>=0A> ---1238014912-1189699046-1349635944=:69442 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Fixed the= 2 obvious corrections, thank you.

Can an individual submission proc= eed without a WG?  If so how do I do that?  Or is Apps willing to= take this up?


From: SM <sm@resistor.net>
To: William Mills <wmills@yahoo-inc= .com>
Cc: Apps Disc= uss <apps-discuss@ietf.org>
S= ent: Sunday, October 7, 2012 9:04 AM
Subject: Re: [apps-discuss] Link type registratio= n for OAuth draft

Hi Bill,
At 08:43 07-10-2012, W= illiam Mills wrote:
> There has been one further review of this (than= ks Mark) and the title has been corrected (as has the subject line of this = message).  As an individual submission does this get a WGLC through th= is WG?

No.  A working group would have to adopt the draft for i= t to go through a WGLC.  I'll send some quick nits.

The text in= the Abstract Section needs to be reworded.  The title mentions "OAuth= 2" while there is text about "OAuth 1a" in the draft.

In Section 2:=

  "In examplesl ine breaks have been inserted for readability.= "

This is a typo.

I don't see why RFC 2119 key words are used in the IANA Considerations section.  The draft has examples in S= ection 5.  I don't see what that has to do with registries.  Sect= ion 3 mentions that:

  "This document is informational, definin= g values in existing
  registries, and as such has no security pro= perties to discuss."

Regards,
-sm


---1238014912-1189699046-1349635944=:69442-- From sm@resistor.net Sun Oct 7 12:11:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4EF21F870A for ; Sun, 7 Oct 2012 12:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 iHxRL9mWwdDM for ; Sun, 7 Oct 2012 12:11:21 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D869221F870B for ; Sun, 7 Oct 2012 12:11:20 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q97JBDJM022098; Sun, 7 Oct 2012 12:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1349637078; bh=iI7FmrQjifjLK9UWKqIIggZ7de/nPIzyKr+rmKb99lA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Le6daOWNHKmxJA972EFj66l9DJqsgcP6YuDFrODVggO7Sr4EBI7ls8T7CvNeNmHoO DjDIOtcTYekGG3nftelLRJ2PuNNWGlhnyOHGFQ2BY52y/8XngBhq9SdB4ST4+QBUwC IIMy0vShsAhj7uPrO31Pie9ke+LyON8+KDBDzFKk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1349637078; i=@resistor.net; bh=iI7FmrQjifjLK9UWKqIIggZ7de/nPIzyKr+rmKb99lA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=amd6iHWuL40yM9MvlJnokRCd6yRXVi25AC7vFUHj7LOeX0B8dOwnNM3NBgFZPGivf tH9Ixhli//6qQiMo8DeumkknsnRVj1RrFUhC0u0fqBVrKdGm9HPmZWhkKsbZ/FKqXm pcrHluiaPfDRUfmya2KRhUNadjcnGadTItqk4+fk= Message-Id: <6.2.5.6.2.20121007115721.09c80fd8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 07 Oct 2012 12:04:15 -0700 To: William Mills From: SM In-Reply-To: <1349635624.2048.YahooMailNeo@web31811.mail.mud.yahoo.com> References: <1349107955.29811.YahooMailNeo@web31813.mail.mud.yahoo.com> <1349624627.64105.YahooMailNeo@web31807.mail.mud.yahoo.com> <6.2.5.6.2.20121007084843.0a2b12f0@resistor.net> <1349635624.2048.YahooMailNeo@web31811.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Apps Discuss Subject: Re: [apps-discuss] Link type registration for OAuth draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2012 19:11:22 -0000 Hi Bill, At 11:47 07-10-2012, William Mills wrote: >So examples are not needed here? I don't think that the examples are needed in this draft as the purpose of the draft is to do the registrations. The examples would be a better fit in the technical specification. Regards, -sm From sm@resistor.net Sun Oct 7 12:11:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFC821F8720 for ; Sun, 7 Oct 2012 12:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 7qgtjcUurPIQ for ; Sun, 7 Oct 2012 12:11:23 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 352FE21F870B for ; Sun, 7 Oct 2012 12:11:23 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q97JBDJO022098; Sun, 7 Oct 2012 12:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1349637082; bh=gI3NeOojqjyWSfxMF1wPLDIB4Li60Ql41iYWjpSPkCs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=RiRcy57sL5bPOqeqzyRod5+MlUXGNMG9yENHKSXc6hefRbD9KcL7olGMyd+rX4X5P sPJQxAXMn3TeF2fLFH5QNqHo+6BQv6hBzVLxu9TRTiv/T7ze8TCIp4Brt4RIFYwtsV qkNpx6BB43WRqYp6Y5yb+daBoiEdYyXpILpEVPHQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1349637082; i=@resistor.net; bh=gI3NeOojqjyWSfxMF1wPLDIB4Li60Ql41iYWjpSPkCs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TjydP760crjC63Sv1j4xvD/0Dl+DHcyIVepI8vvfBo1IrYDHzlvpXeURykof+CzXe I6WRXiu07dtYJweXs9DDTNJZ/NuNtVrjHf2C4XuiS0AkGW5MkXe8vFmX7pa6LhABTY ocGgk+qENjJvpalemQ5qUCx5upy0a+GygO2nFG9k= Message-Id: <6.2.5.6.2.20121007120418.09c80d48@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 07 Oct 2012 12:10:07 -0700 To: William Mills From: SM In-Reply-To: <1349635944.69442.YahooMailNeo@web31816.mail.mud.yahoo.com> References: <1349107955.29811.YahooMailNeo@web31813.mail.mud.yahoo.com> <1349624627.64105.YahooMailNeo@web31807.mail.mud.yahoo.com> <6.2.5.6.2.20121007084843.0a2b12f0@resistor.net> <1349635944.69442.YahooMailNeo@web31816.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Apps Discuss Subject: Re: [apps-discuss] Link type registration for OAuth draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2012 19:11:23 -0000 Hi Bill, At 11:52 07-10-2012, William Mills wrote: >Can an individual submission proceed without a WG? If so how do I >do that? Or is Apps willing to take this up? Yes. You could contact the Apps ADs (app-ads@tools.ietf.org) to sponsor the draft if it is an Individual Submission. The draft only goes through a Last Call once it is ready for publication. Regards, -sm From wmills@yahoo-inc.com Sun Oct 7 19:51:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC73821F874F for ; Sun, 7 Oct 2012 19:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.523 X-Spam-Level: X-Spam-Status: No, score=-17.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 KKBv68OrXk9Q for ; Sun, 7 Oct 2012 19:51:50 -0700 (PDT) Received: from nm11-vm0.bullet.mail.sp2.yahoo.com (nm11-vm0.bullet.mail.sp2.yahoo.com [98.139.91.240]) by ietfa.amsl.com (Postfix) with SMTP id 2F0A421F8746 for ; Sun, 7 Oct 2012 19:51:50 -0700 (PDT) Received: from [72.30.22.78] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 08 Oct 2012 02:51:47 -0000 Received: from [72.30.22.187] by tm12.bullet.mail.sp2.yahoo.com with NNFMP; 08 Oct 2012 02:51:47 -0000 Received: from [127.0.0.1] by omp1063.mail.sp2.yahoo.com with NNFMP; 08 Oct 2012 02:51:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 387701.75242.bm@omp1063.mail.sp2.yahoo.com Received: (qmail 28025 invoked by uid 60001); 8 Oct 2012 02:51:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1349664706; bh=TbZ1ifOeYBba+3U33sMYIx2dfXBQXEeOiKJMIpz63U4=; 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=dbPh6riZc0JuEUKDJ4lbfQXLoHBxnUseHJOHKIB8Ajk24cJuWVoieRD5L5il/e0yjrSCMf3qgByaLMT133iXTVRlj1GhYAwS9poGUl1RRLot+/hiSQAwrG7ORjo3czLDYtw56SEk8zi0YR2RP9UkWoQnWnrDXtl3oUuYKF/BiMU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.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=W7nj+vrllo90ofTdkbkmGBA6yz4QjyhO4geJAR9apN8+pWPzWbBB62YHON6QWXWCBB9J0geKHztN/CwuL5M1V/7iHh9G0KUW+NCe0lwUM1dYZyvyBQFEBAAax4v0aoBpJ4ZfRUu33jNYVHS19a3goWspLDylcG2IbG6lFISRPAw=; X-YMail-OSG: lzNVSBcVM1nI_rKXFbqfLteqVXXaTv0cpamNIVzZCHiqve9 TSpvfhV8QW9loQIBEii.BLWwOW1Iisg9qP.Voy8O2vViJuDYJpjqn6aBjwnb A9ahegVQKMFuw.vqdJQUv2981KrbqiXVyrDAJQbyI.ioHy9satvHIPayk3Nz nZtbl16Wa8VZl.AM.Yalg8JuhuVHIt5rFVHsOaEDy3dL5OEcl.VINphmtUHf ZnnmZEBdtPeF6ACwktyTfaZbEawKSimu3_qRi3Gty6FDomMNLjciiDYlEFDV Uf7_bUVVa6S74Fv9k_HFhZpE2EbzbK.I.E29Wefjcd9l3wuMeluC6xa8HKUo uqF4NA6CYdvLECGe8zhkyxIRpEIXU1TLTeIO3EtuYvXBxbXYkXyMM6v4m7pu 4zlWG.EuGpPLDfTx2AN11P_.H5wbbl7SoRUG9ABs.hEbOujTs3eA03r.Z4P9 oeDtAH_lNIl8- Received: from [99.31.212.42] by web31807.mail.mud.yahoo.com via HTTP; Sun, 07 Oct 2012 19:51:46 PDT X-Rocket-MIMEInfo: 001.001, RmFpciBlbm91Z2guwqAgSSBjYW4gcHVsbCB0aGUgZXhhbXBsZXMuCgoKCgoKPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRnJvbTogU00gPHNtQHJlc2lzdG9yLm5ldD4KPlRvOiBXaWxsaWFtIE1pbGxzIDx3bWlsbHNAeWFob28taW5jLmNvbT4gCj5DYzogQXBwcyBEaXNjdXNzIDxhcHBzLWRpc2N1c3NAaWV0Zi5vcmc.IAo.U2VudDogU3VuZGF5LCBPY3RvYmVyIDcsIDIwMTIgMTI6MDQgUE0KPlN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBMaW5rIHR5cGUgcmVnaXN0cmF0aW9uIGZvciABMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.123.450 References: <1349107955.29811.YahooMailNeo@web31813.mail.mud.yahoo.com> <1349624627.64105.YahooMailNeo@web31807.mail.mud.yahoo.com> <6.2.5.6.2.20121007084843.0a2b12f0@resistor.net> <1349635624.2048.YahooMailNeo@web31811.mail.mud.yahoo.com> <6.2.5.6.2.20121007115721.09c80fd8@resistor.net> Message-ID: <1349664706.25785.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Sun, 7 Oct 2012 19:51:46 -0700 (PDT) From: William Mills To: SM In-Reply-To: <6.2.5.6.2.20121007115721.09c80fd8@resistor.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-60261745-1349664706=:25785" Cc: Apps Discuss Subject: Re: [apps-discuss] Link type registration for OAuth draft 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: Mon, 08 Oct 2012 02:51:50 -0000 ---125733401-60261745-1349664706=:25785 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Fair enough.=A0 I can pull the examples.=0A=0A=0A=0A=0A=0A>________________= ________________=0A> From: SM =0A>To: William Mills =0A>Cc: Apps Discuss =0A>Sent: Sun= day, October 7, 2012 12:04 PM=0A>Subject: Re: [apps-discuss] Link type regi= stration for OAuth draft=0A> =0A>Hi Bill,=0A>At 11:47 07-10-2012, William M= ills wrote:=0A>> So examples are not needed here?=0A>=0A>I don't think that= the examples are needed in this draft as the purpose of the draft is to do= the registrations. The examples would be a better fit in the technical spe= cification.=0A>=0A>Regards,=0A>-sm =0A>=0A>=0A> ---125733401-60261745-1349664706=:25785 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Fair enou= gh.  I can pull the examples.


=
From: SM <sm@resistor.net&= gt;
To: William Mills = <wmills@yahoo-inc.com>
Cc:<= /span> Apps Discuss <apps-discuss@ietf.org>
Sent: Sunday, October 7, 2012 12:04 PM Subject: Re: [apps-discuss] Link t= ype registration for OAuth draft

Hi Bill,
At 11:4= 7 07-10-2012, William Mills wrote:
> So examples are not needed here?=

I don't think that the examples are needed in this draft as the pur= pose of the draft is to do the registrations. The examples would be a bette= r fit in the technical specification.

Regards,
-sm


<= /div>
---125733401-60261745-1349664706=:25785-- From James.H.Manger@team.telstra.com Mon Oct 8 00:36:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21C121F8777 for ; Mon, 8 Oct 2012 00:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.129 X-Spam-Level: X-Spam-Status: No, score=0.129 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_05=-1.11, 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 RCI-0ACl+qA3 for ; Mon, 8 Oct 2012 00:36:24 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id EA2D221F8724 for ; Mon, 8 Oct 2012 00:36:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,551,1344175200"; d="scan'208";a="97711164" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 08 Oct 2012 18:36:21 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6858"; a="91945526" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcdvi.tcif.telstra.com.au with ESMTP; 08 Oct 2012 18:36:19 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Mon, 8 Oct 2012 18:36:21 +1100 From: "Manger, James H" To: James M Snell , IETF Apps Discuss Date: Mon, 8 Oct 2012 18:36:19 +1100 Thread-Topic: merge-patch semantics for json-patch Thread-Index: Ac2iYdSEgPDbdirvRUCZ0rg0Qn5owQCwNEIg Message-ID: <255B9BB34FB7D647A506DC292726F6E114FD9A059D@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [apps-discuss] merge-patch semantics for json-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: Mon, 08 Oct 2012 07:36:24 -0000 Q29tcGFyaW5nIGRyYWZ0LXNuZWxsLW1lcmdlLXBhdGNoIGFuZCBkcmFmdC1pZXRmLWFwcHNhd2ct anNvbi1wYXRjaDoNCg0KSSBsaWtlIHRoaXMgbWVyZ2UtcGF0Y2ggc3ludGF4LiBJdCBlZmZlY3Rp dmVseSBzdXBwb3J0cyAyIG9wZXJhdGlvbnM6DQoxLiBSZW1vdmluZyBhIEpTT04gb2JqZWN0IGVs ZW1lbnQNCjIuIEFkZGluZyBhIEpTT04gb2JqZWN0IGVsZW1lbnQNCg0KQm90aCBvcGVyYXRpb25z IHdvcmsgcmVnYXJkbGVzcyBvZiB0aGUgY3VycmVudCBzdGF0ZSBvZiB0aGUgSlNPTiBkb2MuIFJl bW92aW5nIGFuIGl0ZW0gdGhhdCBkb2Vzbid0IGV4aXN0IGlzIG5vdCBhbiBlcnJvciwgaXQncyBq dXN0IGRvZXMgbm90aGluZy4gR3JlYXQhIEFkZGluZyBhbiBpdGVtIHJlcGxhY2VzIGFuIGV4aXN0 aW5nIGl0ZW0sIG9yIGNyZWF0ZXMgYSBuZXcgaXRlbSwgb3IgZXZlbiBjcmVhdGVzIG5ldyBwYXJl bnQgb2JqZWN0cyBmb3IgdGhlIGl0ZW0gYXMgcmVxdWlyZWQgLS0gaXQgaXMgbmV2ZXIgYW4gZXJy b3IuIEdyZWF0IQ0KDQpUaGUgb3BlcmF0aW9ucyBpbiBpZXRmLWFwcHNhd2ctanNvbi1wYXRjaCBz aG91bGQgaGF2ZSBzaW1pbGFyIHNlbWFudGljcy4NCnsib3AiOiJyZW1vdmUiLCAicGF0aCI6Ii9h L2IvYyJ9IHNob3VsZG4ndCBjYXVzZSBhbiBlcnJvciBpZiAvYS9iL2MgZG9lc24ndCBleGlzdC4N CkEgInB1dCIgb3BlcmF0aW9uIHNob3VsZCBlbnN1cmUgdGhhdCBhZnRlciB0aGUgb3AgaXMgYXBw bGllZCB0aGUgZ2l2ZW4gdmFsdWUgZXhpc3RzIGF0IHRoZSBnaXZlbiBwb3NpdGlvbiAtLSByZWdh cmRsZXNzIG9mIHdoZXRoZXIgaXQgaGFzIHRvIHJlcGxhY2UgYW4gZXhpc3RpbmcgdmFsdWUsIGNy ZWF0ZSBhIG5ldyB2YWx1ZSwgb3IgZXZlbiBjcmVhdGUgaW50ZXJtZWRpYXRlIG9iamVjdHMuDQoN CkFwcGx5IHsib3AiOiJwdXQiLCAicGF0aCI6Ii9hL2IvYyIsICJ2YWx1ZSI6Mn0NCg0KVG8geyJh Ijp7ImIiOnsiYyI6MX19fSBzaG91bGQgZ2l2ZSB7ImEiOnsiYiI6eyJjIjoyfX19DQoNClRvIHsi YSI6eyJiIjp7ImZvbyI6ImJhciJ9fX0gc2hvdWxkIGdpdmUgeyJhIjp7ImIiOnsiZm9vIjoiYmFy IiwgImMiOjJ9fX0NCg0KVG8geyJhIjp7IngiOiJ5In19IHNob3VsZCBnaXZlIHsiYSI6eyJ4Ijoi eSIsICJiIjp7ImMiOjJ9fX0NCg0KDQpbVGhlIG9uZSBleHRyYSBydWxlIHdlIG5lZWQgaXMgdGhh dCBvbmx5IGludGVybWVkaWF0ZSBvYmplY3RzIGFyZSBjcmVhdGVkLCBuZXZlciBpbnRlcm1lZGlh dGUgYXJyYXlzLCBldmVuIGlmIGEgc2VnbWVudCBvZiB0aGUgInBhdGgiIGlzICIvMCIuXQ0KDQoN Ci0tDQpKYW1lcyBNYW5nZXINCg0K From James.H.Manger@team.telstra.com Mon Oct 8 18:15:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA741F042B for ; Mon, 8 Oct 2012 18:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[AWL=0.314, 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 X1WDRSLMOlfX for ; Mon, 8 Oct 2012 18:15:51 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4E21F0417 for ; Mon, 8 Oct 2012 18:15:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,557,1344175200"; d="scan'208,217";a="94715146" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 09 Oct 2012 12:15:46 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6859"; a="93168392" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipccni.tcif.telstra.com.au with ESMTP; 09 Oct 2012 12:15:46 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Tue, 9 Oct 2012 12:15:46 +1100 From: "Manger, James H" To: James M Snell , IETF Apps Discuss Date: Tue, 9 Oct 2012 12:15:44 +1100 Thread-Topic: [apps-discuss] Updated JSON Merge Patch... Thread-Index: Ac2lZg9dhL6rePURSDm06Od3fg1tOAAQ2t+w Message-ID: <255B9BB34FB7D647A506DC292726F6E114FDA21CC4@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114FD9A05AE@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114FDA21CC4WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [apps-discuss] Updated JSON 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: Tue, 09 Oct 2012 01:15:52 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114FDA21CC4WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tbWVudHMgb24gZHJhZnQtc25lbGwtbWVyZ2UtcGF0Y2gtMDQ6DQoNClRoZSBpbnRyb2R1Y3Rp b24gdHJpZXMgdG8gZGlzdGluZ3Vpc2ggYW4g4oCcZXhwbGljaXQgZGVzY3JpcHRpb24gb2YgdGhl IGNoYW5nZXPigJ0gYW5kIOKAnGEgbW9kaWZpZWQgc3Vic2V04oCdIG9mIHRoZSByZXNvdXJjZS4g SSBkb27igJl0IGxpa2UgdGhpcyBjaGFyYWN0ZXJpemF0aW9uIGFzIGEgbWVyZ2UtcGF0Y2ggZG9j IGlzIGNsZWFyIGFib3V0IGl0cyBjaGFuZ2VzLiBUaGUga2V5IGZlYXR1cmVzIG9mIG1lcmdlLXBh dGNoIGFyZSBpdHMgbGltaXRlZCBvcGVyYXRpb25zLCBhbmQgc3BlY2lhbC1jYXNpbmcgb2YgbnVs bCwgdGhhdCBhbGxvdyBhIG1lcmdlLXBhdGNoIHZhbHVlIHRvIGxvb2sgYSBiaXQgbGlrZSBhIHN1 YnNldCBvZiB0aGUgZG9jIGl0IGlzIHBhdGNoaW5nLg0KDQpNeSBhdHRlbXB0IGF0IGFuIGludHJv Og0K4oCcVGhlIG1lcmdlLXBhdGNoIGZvcm1hdCBzdXBwb3J0cyB0d28gdHlwZXMgb2YgY2hhbmdl czogcmVtb3ZpbmcgYW5kIHNldHRpbmcgSlNPTiBvYmplY3QgZWxlbWVudHMuIEpTT04gYXJyYXlz IGFyZSB0cmVhdGVkIHRoZSBzYW1lIHdheSBhcyBKU09OIHByaW1pdGl2ZXM6IHRoZSB3aG9sZSB2 YWx1ZSBjYW4gYmUgcmVwbGFjZWQsIGJ1dCBub3QgcGFydGlhbGx5IG1vZGlmaWVkLiBUaGUgSlNP TiBudWxsIHZhbHVlIGlzIGdpdmVuIGEgc3BlY2lhbCBtZWFuaW5nLiBUaGVzZSBjb25zdHJhaW50 cyBhbGxvdyBtZXJnZS1wYXRjaCB0byB1c2UgYSBmb3JtYXQgdGhhdCBjbG9zZWx5IG1pbWljcyB0 aGUgZG9jdW1lbnQgYmVpbmcgcGF0Y2hlZC4gVGhlIGNvbnN0cmFpbnRzIG1lYW4gbWVyZ2UtcGF0 Y2ggaXMgc3VpdGFibGUgZm9yIHBhdGNoaW5nIEpTT04gZG9jdW1lbnRzIHRoYXQgcHJpbWFyaWx5 IHVzZSBvYmplY3RzIGZvciB0aGVpciBzdHJ1Y3R1cmUsIGFuZCBkb27igJl0IHVzZSBudWxsIHZh bHVlcy4gVGhlIG1lcmdlLXBhdGNoIGZvcm1hdCBpcyBub3QgYXBwcm9wcmlhdGUgZm9yIGFsbCBK U09OIHN5bnRheGVzLuKAnQ0KDQpNdWNoIG9mIHRoZSBjdXJyZW50IGludHJvIGFwcGVhcnMgdG8g YmUgYSBjb252b2x1dGVkIG1vdGl2YXRpb24gZm9yIHdoeSBtZXJnZS1wYXRjaCBuZWVkcyBpdHMg b3duIG1lZGlhIHR5cGUuIEkgd291bGQgZHJvcCBhbGwgdGhhdCBhbmQganVzdCBzdGF0ZSB0aGF0 IOKAnGFwcGxpY2F0aW9uL2pzb24tbWVyZ2UtcGF0Y2jigJ0gaXMgdGhlIG1lZGlhIHR5cGUgZm9y IHRoaXMgZm9ybWF0LiBJIGRvbuKAmXQgdGhpbmsgYW55IGZ1cnRoZXIgbW90aXZhdGlvbiBpcyBu ZWVkZWQuIFRoZSDigJxwYXRjaGluZy1hLXBhdGNoLWZvcm1hdOKAnSBhcmd1bWVudCBpcyBjdXRl LCBidXQgbW92ZSBpdCB0byBhbiBhcHBlbmRpeCBpZiB5b3UgcmVhbGx5IHdhbnQgdG8ga2VlcCBp dC4NCg0KVGhlIGV4YW1wbGUgaXMgYXBwYWxsaW5nIChub3QgbWVyZWx5IOKAnHNvbWV3aGF0IGV4 dHJlbWXigJ0gYXMgdGhlIGludHJvIHNheXMpLiBUaGUgZXhhbXBsZSBpcyBwYXRjaGluZyBhIGpz b24tcGF0Y2ggZG9jLiBBIGpzb24tcGF0Y2ggaXMgYWx3YXlzIGFuIGFycmF5LiBNZXJnZS1wYXRj aCBjYW5ub3Qg4oCccGF0Y2jigJ0gYW4gYXJyYXksIGl0IGNhbiBvbmx5IGNvbXBsZXRlbHkgcmVw bGFjZSBpdC4gSW4gdGhpcyBzaXR1YXRpb24sIGFueSBQQVRDSCB3aXRoIGEgbWVyZ2UtcGF0Y2gg dmFsdWUgc2hvdWxkIGJlIGRvbmUgbW9yZSBzaW1wbHkgd2l0aCBhIFBVVCBvZiBhIG5ldyBqc29u LXBhdGNoIHZhbHVlLiBUaGUgZXhhbXBsZSB3YXMgb25seSBpbnRlbmRlZCB0byBpbGx1c3RyYXRl IGEgbWVkaWEgdHlwZSBjb3JuZXItY2FzZSwgYnV0IGJlaW5nIGluIHRoZSBpbnRyb2R1Y3Rpb24g aXQgd2lsbCBiZSBzZWVuIGFzIGFuIGV4YW1wbGUgb2YgbWVyZ2UtcGF0Y2guDQpbUC5TLiBTZW5k aW5nIHRoZSBtZXJnZS1wYXRjaCB3aXRoIHRoZSBqc29uLXBhdGNoIG1lZGlhIHR5cGUgd291bGRu 4oCZdCByZXN1bHQgaW4g4oCcYW4gdW5pbnRlbmRlZCBtb2RpZmljYXRpb27igJ0gaW4gdGhpcyBj YXNlLiBJdCB3b3VsZCB0cmlnZ2VyIGFuIGVycm9yLl0NCltQLlMuIFNvbWUganNvbi1wYXRjaCDi gJxwYXRo4oCdIHZhbHVlcyBzaG91bGQgYmUg4oCcL3RpdGxl4oCdLCBub3Qg4oCcdGl0bGXigJ0u XQ0KDQoNCkRvZXMgYXBwbGljYXRpb24vanNvbi1tZXJnZS1wYXRjaCByZWFsbHkgbmVlZCBhIGNo YXJzZXQgcGFyYW1ldGVyPyBJIG11Y2ggcHJlZmVyIHRoZSBKU09OIGFwcHJvYWNoOiBNVVNUIGJl IFVuaWNvZGUgW2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ2Mjcjc2VjdGlvbi0zXS4N Cg0KDQpUaGUgY2hhbmdlIHJ1bGVzIGFyZSBub3QgcXVpdGUgcmlnaHQuIENvbnNpZGVyIHRoZXNl IGNhc2VzOg0KTWVyZ2UtcGF0Y2ggICAgICAgT2xkICAgICAgIE5ldyAgICAgICBDb21tZW50DQp7 ImEiOjJ9ICAgICAgICAgICBbMCwxXSAgICAgeyJhIjoyfSAgIG5vdCByZWFsbHkgY292ZXJlZA0K eyJhIjp7ImIiOm51bGx9fSAge30gICAgICAgIHsiYSI6e319ICB0ZXh0IGFsbW9zdCBzYXlzIE5l dyBpcyB7ImEiOnsiYiI6bnVsbH19DQoNCg0KLS0NCkphbWVzIE1hbmdlcg0KDQpGcm9tOiBKYW1l cyBNIFNuZWxsIFttYWlsdG86amFzbmVsbEBnbWFpbC5jb21dDQpTZW50OiBUdWVzZGF5LCA5IE9j dG9iZXIgMjAxMiAyOjAzIEFNDQpUbzogTWFuZ2VyLCBKYW1lcyBIDQpTdWJqZWN0OiBSZTogW2Fw cHMtZGlzY3Vzc10gVXBkYXRlZCBKU09OIE1lcmdlIFBhdGNoLi4uDQoNClRydWUuLi4gSSd2ZSBh Y3R1YWxseSBiZWVuIGNvbnNpZGVyaW5nIHRpZ2h0ZW5pbmcgdGhhdCBsYW5ndWFnZSB1cCBhIGJp dCBtb3JlIHRvIGdldCByaWQgb2YgdGhlIGZ1enouDQpPbiBNb24sIE9jdCA4LCAyMDEyIGF0IDEy OjUxIEFNLCBNYW5nZXIsIEphbWVzIEggPEphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208 bWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20+PiB3cm90ZToNCkNvbW1lbnRz IG9uIGRyYWZ0LXNuZWxsLW1lcmdlLXBhdGNoLTA0Og0KDQpUaGUgc3ludGF4IChhbnkgSlNPTikg YW5kIHNlbWFudGljcyBvZiBhbiBhcHBsaWNhdGlvbi9qc29uLW1lcmdlLXBhdGNoIGRvYyBsb29r IHdlbGwtZGVmaW5lZCBhbmQgdW5hbWJpZ3VvdXMuIEFuIGltcGxlbWVudGF0aW9uIGNvdWxkIGFw cGx5IGFueSBwYXRjaCB0byBhbnkgSlNPTiBkb2MuIFRoZSBzcGVjIHRleHQsIGhvd2V2ZXIsIHNl ZW1zIHRvIGltcGx5IHRoYXQgdGhlIGNoYW5nZXMgYXJlIHNvbWVob3cgZnV6enksIGRlcGVuZGlu ZyBvbiB0aGUgc2VydmVycyAidW5kZXJzdGFuZGluZyBvZiB0aGUgdGFyZ2V0IHJlc291cmNlIG1l ZGlhIHR5cGUgYW5kIHRoZSB1bmRlcmx5aW5nIGRhdGEgbW9kZWwiLg0KDQpJIGNhbiB1bmRlcnN0 YW5kIHRoYXQgYSBzZXJ2ZXIgbWF5IHdhbnQgdG8gYWNjZXB0IG9yIHJlamVjdCBhIHNwZWNpZmlj IHNldCBvZiBjaGFuZ2VzIGJhc2VkIG9uIHJlc291cmNlLXNwZWNpZmljIGtub3dsZWRnZS4gQnV0 IHRoYXQgaXMgdHJ1ZSBvZiBhbnkgSFRUUCByZXF1ZXN0LCBhbmQgaXMgc3VwcG9ydGVkIGJ5IHN0 YXR1cyBjb2RlcyAoZWcgMjAxIENyZWF0ZWQgdnMgNDAwIEJhZCBSZXF1ZXN0KS4NCg0KDQotLQ0K SmFtZXMgTWFuZ2VyDQoNCg== --_000_255B9BB34FB7D647A506DC292726F6E114FDA21CC4WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVh ZD48Ym9keSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3Jk U2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Q29tbWVu dHMgb24gZHJhZnQtc25lbGwtbWVyZ2UtcGF0Y2gtMDQ6PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUg aW50cm9kdWN0aW9uIHRyaWVzIHRvIGRpc3Rpbmd1aXNoIGFuIOKAnGV4cGxpY2l0IGRlc2NyaXB0 aW9uIG9mIHRoZSBjaGFuZ2Vz4oCdIGFuZCDigJxhIG1vZGlmaWVkIHN1YnNldOKAnSBvZiB0aGUg cmVzb3VyY2UuIEkgZG9u4oCZdCBsaWtlIHRoaXMgY2hhcmFjdGVyaXphdGlvbiBhcyBhIG1lcmdl LXBhdGNoIGRvYyBpcyBjbGVhciBhYm91dCBpdHMgY2hhbmdlcy4gVGhlIGtleSBmZWF0dXJlcyBv ZiBtZXJnZS1wYXRjaCBhcmUgaXRzIGxpbWl0ZWQgb3BlcmF0aW9ucywgYW5kIHNwZWNpYWwtY2Fz aW5nIG9mIG51bGwsIHRoYXQgYWxsb3cgYSBtZXJnZS1wYXRjaCB2YWx1ZSB0byBsb29rIGEgYml0 IGxpa2UgYSBzdWJzZXQgb2YgdGhlIGRvYyBpdCBpcyBwYXRjaGluZy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPk15IGF0dGVtcHQgYXQgYW4gaW50cm86PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPuKAnFRoZSBtZXJnZS1wYXRjaCBmb3Jt YXQgc3VwcG9ydHMgdHdvIHR5cGVzIG9mIGNoYW5nZXM6IHJlbW92aW5nIGFuZCBzZXR0aW5nIEpT T04gb2JqZWN0IGVsZW1lbnRzLiBKU09OIGFycmF5cyBhcmUgdHJlYXRlZCB0aGUgc2FtZSB3YXkg YXMgSlNPTiBwcmltaXRpdmVzOiB0aGUgd2hvbGUgdmFsdWUgY2FuIGJlIHJlcGxhY2VkLCBidXQg bm90IHBhcnRpYWxseSBtb2RpZmllZC4gVGhlIEpTT04gbnVsbCB2YWx1ZSBpcyBnaXZlbiBhIHNw ZWNpYWwgbWVhbmluZy4gVGhlc2UgY29uc3RyYWludHMgYWxsb3cgbWVyZ2UtcGF0Y2ggdG8gdXNl IGEgZm9ybWF0IHRoYXQgY2xvc2VseSBtaW1pY3MgdGhlIGRvY3VtZW50IGJlaW5nIHBhdGNoZWQu IFRoZSBjb25zdHJhaW50cyBtZWFuIG1lcmdlLXBhdGNoIGlzIHN1aXRhYmxlIGZvciBwYXRjaGlu ZyBKU09OIGRvY3VtZW50cyB0aGF0IHByaW1hcmlseSB1c2Ugb2JqZWN0cyBmb3IgdGhlaXIgc3Ry dWN0dXJlLCBhbmQgZG9u4oCZdCB1c2UgbnVsbCB2YWx1ZXMuIFRoZSBtZXJnZS1wYXRjaCBmb3Jt YXQgaXMgbm90IGFwcHJvcHJpYXRlIGZvciBhbGwgSlNPTiBzeW50YXhlcy7igJ08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPk11Y2ggb2YgdGhlIGN1cnJlbnQgaW50cm8gYXBwZWFycyB0byBiZSBhIGNvbnZv bHV0ZWQgbW90aXZhdGlvbiBmb3Igd2h5IG1lcmdlLXBhdGNoIG5lZWRzIGl0cyBvd24gbWVkaWEg dHlwZS4gSSB3b3VsZCBkcm9wIGFsbCB0aGF0IGFuZCBqdXN0IHN0YXRlIHRoYXQg4oCcYXBwbGlj YXRpb24vanNvbi1tZXJnZS1wYXRjaOKAnSBpcyB0aGUgbWVkaWEgdHlwZSBmb3IgdGhpcyBmb3Jt YXQuIEkgZG9u4oCZdCB0aGluayBhbnkgZnVydGhlciBtb3RpdmF0aW9uIGlzIG5lZWRlZC4gVGhl IOKAnHBhdGNoaW5nLWEtcGF0Y2gtZm9ybWF04oCdIGFyZ3VtZW50IGlzIGN1dGUsIGJ1dCBtb3Zl IGl0IHRvIGFuIGFwcGVuZGl4IGlmIHlvdSByZWFsbHkgd2FudCB0byBrZWVwIGl0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+VGhlIGV4YW1wbGUgaXMgYXBwYWxsaW5nIChub3QgbWVyZWx5IOKAnHNvbWV3 aGF0IGV4dHJlbWXigJ0gYXMgdGhlIGludHJvIHNheXMpLiBUaGUgZXhhbXBsZSBpcyBwYXRjaGlu ZyBhIGpzb24tcGF0Y2ggZG9jLiBBIGpzb24tcGF0Y2ggaXMgYWx3YXlzIGFuIGFycmF5LiBNZXJn ZS1wYXRjaCBjYW5ub3Qg4oCccGF0Y2jigJ0gYW4gYXJyYXksIGl0IGNhbiBvbmx5IGNvbXBsZXRl bHkgcmVwbGFjZSBpdC4gSW4gdGhpcyBzaXR1YXRpb24sIGFueSBQQVRDSCB3aXRoIGEgbWVyZ2Ut cGF0Y2ggdmFsdWUgc2hvdWxkIGJlIGRvbmUgbW9yZSBzaW1wbHkgd2l0aCBhIFBVVCBvZiBhIG5l dyBqc29uLXBhdGNoIHZhbHVlLiBUaGUgZXhhbXBsZSB3YXMgb25seSBpbnRlbmRlZCB0byBpbGx1 c3RyYXRlIGEgbWVkaWEgdHlwZSBjb3JuZXItY2FzZSwgYnV0IGJlaW5nIGluIHRoZSBpbnRyb2R1 Y3Rpb24gaXQgd2lsbCBiZSBzZWVuIGFzIGFuIGV4YW1wbGUgb2YgbWVyZ2UtcGF0Y2guPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PltQLlMuIFNlbmRpbmcgdGhlIG1lcmdlLXBhdGNoIHdpdGggdGhlIGpzb24tcGF0Y2ggbWVkaWEg dHlwZSB3b3VsZG7igJl0IHJlc3VsdCBpbiDigJxhbiB1bmludGVuZGVkIG1vZGlmaWNhdGlvbuKA nSBpbiB0aGlzIGNhc2UuIEl0IHdvdWxkIHRyaWdnZXIgYW4gZXJyb3IuXTxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5bUC5TLiBT b21lIGpzb24tcGF0Y2gg4oCccGF0aOKAnSB2YWx1ZXMgc2hvdWxkIGJlIOKAnC90aXRsZeKAnSwg bm90IOKAnHRpdGxl4oCdLl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Eb2VzIGFw cGxpY2F0aW9uL2pzb24tbWVyZ2UtcGF0Y2ggcmVhbGx5IG5lZWQgYSBjaGFyc2V0IHBhcmFtZXRl cj8gSSBtdWNoIHByZWZlciB0aGUgSlNPTiBhcHByb2FjaDogTVVTVCBiZSBVbmljb2RlIFs8L3Nw YW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDYyNyNzZWN0aW9uLTMi Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ2Mjcjc2VjdGlvbi0zPC9hPl0uPHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgY2hh bmdlIHJ1bGVzIGFyZSBub3QgcXVpdGUgcmlnaHQuIENvbnNpZGVyIHRoZXNlIGNhc2VzOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+TWVyZ2UtcGF0Y2jC oMKgwqAgwqDCoMKgT2xkwqDCoMKgwqDCoMKgIE5ld8KgwqDCoMKgwqAgwqBDb21tZW50PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz57JnF1b3Q7YSZxdW90 OzoyfcKgwqDCoMKgIMKgwqAgwqDCoMKgWzAsMV3CoMKgwqDCoCB7JnF1b3Q7YSZxdW90OzoyfcKg IMKgbm90IHJlYWxseSBjb3ZlcmVkPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjojMUY0OTdEJz57JnF1b3Q7YSZxdW90Ozp7JnF1b3Q7YiZxdW90OzpudWxsfX3CoCB7fcKg wqDCoMKgwqDCoMKgIHsmcXVvdDthJnF1b3Q7Ont9fcKgIHRleHQgYWxtb3N0IHNheXMgTmV3IGlz IHsmcXVvdDthJnF1b3Q7OnsmcXVvdDtiJnF1b3Q7Om51bGx9fTxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IEphbWVzIE0gU25lbGwgW21haWx0bzpqYXNuZWxs QGdtYWlsLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCA5IE9jdG9iZXIgMjAxMiAyOjAz IEFNPGJyPjxiPlRvOjwvYj4gTWFuZ2VyLCBKYW1lcyBIPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTog W2FwcHMtZGlzY3Vzc10gVXBkYXRlZCBKU09OIE1lcmdlIFBhdGNoLi4uPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+VHJ1ZS4uLiBJJ3ZlIGFjdHVhbGx5IGJl ZW4gY29uc2lkZXJpbmcgdGlnaHRlbmluZyB0aGF0IGxhbmd1YWdlIHVwIGEgYml0IG1vcmUgdG8g Z2V0IHJpZCBvZiB0aGUgZnV6ei4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+T24gTW9uLCBPY3QgOCwgMjAxMiBhdCAxMjo1MSBBTSwgTWFuZ2VyLCBK YW1lcyBIICZsdDs8YSBocmVmPSJtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Q29tbWVudHMgb24gZHJh ZnQtc25lbGwtbWVyZ2UtcGF0Y2gtMDQ6PGJyPjxicj5UaGUgc3ludGF4IChhbnkgSlNPTikgYW5k IHNlbWFudGljcyBvZiBhbiBhcHBsaWNhdGlvbi9qc29uLW1lcmdlLXBhdGNoIGRvYyBsb29rIHdl bGwtZGVmaW5lZCBhbmQgdW5hbWJpZ3VvdXMuIEFuIGltcGxlbWVudGF0aW9uIGNvdWxkIGFwcGx5 IGFueSBwYXRjaCB0byBhbnkgSlNPTiBkb2MuIFRoZSBzcGVjIHRleHQsIGhvd2V2ZXIsIHNlZW1z IHRvIGltcGx5IHRoYXQgdGhlIGNoYW5nZXMgYXJlIHNvbWVob3cgZnV6enksIGRlcGVuZGluZyBv biB0aGUgc2VydmVycyAmcXVvdDt1bmRlcnN0YW5kaW5nIG9mIHRoZSB0YXJnZXQgcmVzb3VyY2Ug bWVkaWEgdHlwZSBhbmQgdGhlIHVuZGVybHlpbmcgZGF0YSBtb2RlbCZxdW90Oy48YnI+PGJyPkkg Y2FuIHVuZGVyc3RhbmQgdGhhdCBhIHNlcnZlciBtYXkgd2FudCB0byBhY2NlcHQgb3IgcmVqZWN0 IGEgc3BlY2lmaWMgc2V0IG9mIGNoYW5nZXMgYmFzZWQgb24gcmVzb3VyY2Utc3BlY2lmaWMga25v d2xlZGdlLiBCdXQgdGhhdCBpcyB0cnVlIG9mIGFueSBIVFRQIHJlcXVlc3QsIGFuZCBpcyBzdXBw b3J0ZWQgYnkgc3RhdHVzIGNvZGVzIChlZyAyMDEgQ3JlYXRlZCB2cyA0MDAgQmFkIFJlcXVlc3Qp Ljxicj48YnI+PGJyPi0tPGJyPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9o dG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E114FDA21CC4WSMSG3153Vsrv_-- From internet-drafts@ietf.org Tue Oct 9 01:41:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70A021F884A; Tue, 9 Oct 2012 01:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 7IkmK+ASU-nh; Tue, 9 Oct 2012 01:41:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C2221F8518; Tue, 9 Oct 2012 01:41:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121009084102.28998.24706.idtracker@ietfa.amsl.com> Date: Tue, 09 Oct 2012 01:41:02 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-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: Tue, 09 Oct 2012 08:41:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Forwarded HTTP Extension Author(s) : Andreas Petersson Martin Nilsson Filename : draft-ietf-appsawg-http-forwarded-09.txt Pages : 19 Date : 2012-10-09 Abstract: This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-http-forwarded-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Oct 9 03:00:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2BB21F8876; Tue, 9 Oct 2012 03:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 IX5tT9Db4FXc; Tue, 9 Oct 2012 03:00:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E59321F886C; Tue, 9 Oct 2012 03:00:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121009100023.14125.58363.idtracker@ietfa.amsl.com> Date: Tue, 09 Oct 2012 03:00:23 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-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: Tue, 09 Oct 2012 10:00:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Forwarded HTTP Extension Author(s) : Andreas Petersson Martin Nilsson Filename : draft-ietf-appsawg-http-forwarded-10.txt Pages : 20 Date : 2012-10-09 Abstract: This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-http-forwarded-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paulej@packetizer.com Tue Oct 9 09:16:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA1E21F861A for ; Tue, 9 Oct 2012 09:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HS_INDEX_PARAM=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 fXv+3WCM1ASg for ; Tue, 9 Oct 2012 09:16:39 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B69FE21F8611 for ; Tue, 9 Oct 2012 09:16:39 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q99GGcBI019964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Oct 2012 12:16:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1349799399; bh=XxCe/jbAXOLDt6ELsgIu30A+jkIS+c2+C9QWLFhXyk8=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=cxVhaCJn1sv+kvKnf7YPEKW9P7iO4P4x/KnvUOV3UT3UoaEod1odX7T5TM05zXZ3g T2qAXpHCL5uc7rltP/NKxmnRpT+zun9rm1VXxynE8q6d7g4gGQUbO7V89j2N8wGYa+ yJR9hg1uKeiJHOTrszKwedskJt0UnqCpF9tSu/qM= From: "Paul E. Jones" To: "'Evan Prodromou'" , References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> In-Reply-To: <50633767.2010003@status.net> Date: Tue, 9 Oct 2012 12:16:48 -0400 Message-ID: <027501cda639$7c684f90$7538eeb0$@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: AQLwMXxq4ac8iFiI1eWGxp691CAGewKEG4UeAU/+zskBqFGbVAHtpkgkASzybwmVJ1a7IA== Content-Language: en-us Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 16:16:41 -0000 Evan, Perhaps this is not stated and should be, but my assumption would be that if one requested the XRD version of host-meta, then the LRDD link would refer to the XML version. Likewise, if one requested the JRD version, then it would point to the JRD version. Note that I do precisely that with my own implementation: curl http://packetizer.com/.well-known/host-meta curl http://packetizer.com/.well-known/host-meta I explicitly include the "type" attribute so that it is made explicit as to the format that will be returned. For example: and { "rel" : "lrdd", "type" : "application/json", "template" : "https://packetizer.com/lrdd/?format=json&resource={uri}" } Are you suggesting that if the "type" attribute is missing, it defaults to XRD? Even if the requestor requested host-meta.json or included the "Accept" header with "application/json"? Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Evan Prodromou > Sent: Wednesday, September 26, 2012 1:12 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] XML in Webfinger > > Paul, > > I'm happy with making XRD "SHOULD" and JRD "MUST". > > I suggest that the default content type, if unspecified, stay XRD. So, > if a client sees: > > template="http://webfinger.example/lrdd?uri={uri}" /> > > ...they can be somewhat confident that the results will be XRD, > regardless of the specification the remote host supports. > > -Evan > > -- > Evan Prodromou, CEO and Founder, StatusNet Inc. > 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 > E: evan@status.net P: +1-514-554-3826 > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From paulej@packetizer.com Tue Oct 9 09:28:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FDD21F8549 for ; Tue, 9 Oct 2012 09:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 u2t08Hb7qqgL for ; Tue, 9 Oct 2012 09:28:30 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 790A221F852E for ; Tue, 9 Oct 2012 09:28:28 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q99GSREO020452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Oct 2012 12:28:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1349800108; bh=cHaqlY+8n8Uo2DNX+jjRar1nvBWl0mWHL+6PX0O9Z/I=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ml8fN5IBe/Q3zDypiBVDkKRLrzhDG0wQ8nivQrXB3Q+KFTekbmrfodDOyvpjLK1JT D6VnC6CggvmAb2yP1/2bOUpOwX3WtyKmFUQAbTYEcXEwPWNPoVzylAV9Qbjb/jjxLI 9I3i4oVOpKpzFRsvXCwhVoGOpnXeGpW4g86jHCzo= From: "Paul E. Jones" To: "'Evan Prodromou'" , References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> <4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> <50635061.2050703@status.net> In-Reply-To: <50635061.2050703@status.net> Date: Tue, 9 Oct 2012 12:28:37 -0400 Message-ID: <027701cda63b$22ef1eb0$68cd5c10$@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: AQLwMXxq4ac8iFiI1eWGxp691CAGewKEG4UeAU/+zskBqFGbVAHtpkgkASzybwkB79pUvgIllDGklQaslOA= Content-Language: en-us Subject: Re: [apps-discuss] Making Webfinger replace RFC 6415 (was Re: XML in Webfinger) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 16:28:31 -0000 Evan, > One thing I'm grappling with with the Webfinger draft is that it depends > on RFC 6415, then requires some incompatible changes to that spec, or > drops requirements from it. Making XML optional will break backward compatibility. I hate doing that, but "it's the will of the people" :-) However, I think if we make it clear that the types used will follow what the user requests, that should be sufficient. Requesting /.well-known/host-meta without explicitly stating a type should default to XRD. However, one might get JRD if XML is not supported, and XML will be optional in the next draft. (I would personally implement both on the server since it's trivial, but people do not want to be required to do so.) > This means that implementers that support the (still active!) RFC 6415 > but don't yet know about or support the Webfinger draft will get > unexpected results. This is entirely true. And there are implementations out there. That said, if shifting the requirement to JRD as the only MTI format helps make WebFinger much more widely implemented, I think that would be "a good thing". For virtually every application we've looked at for WebFinger, JSON is the preference for developers. I've been clinging to XML only because I hate (and I mean ... really hate ...) breaking backward compatibility. But, I'd say the vast majority want JRD only. Just do both if you want, though. I plan to do that on my server. It is trivial. > Is there a reason that we don't simply replace RFC 6415 with a new RFC? > That would make it clear that there's a preferred new way to do things. We could say that this new RFC "updates" RFC 6415, but there's a lot of good content in RFC 6415 that I do not think we need to replace. The procedures are the same. The guidance in there is the same. We're adding a few additional things and changing the MTI format. I do not think that warrants replacing RFC 6415. > Otherwise, we should make it a priority that a compliant Webfinger > implementation is also compliant with the closely-related RFC 6415. I would personally make that a priority. There might be some applications like OpenID that specify only JRD. The new RFC will align with that desire. However, there might be other applications that mandate XRD. I think that would be reasonable. HTTP was designed with content negotiation capabilities. So, one could use that functionality. Perhaps in two hears, some new format prevails. I doubt it, but I think that if you want to guarantee universal acceptance, the format must be JSON. If you have servers you control or will use it with only specific applications, you could use (and mandate) XML. Paul From superuser@gmail.com Tue Oct 9 12:45:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D177111E8108 for ; Tue, 9 Oct 2012 12:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 oL19U4dkgcJl for ; Tue, 9 Oct 2012 12:45:56 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 15C6611E80ED for ; Tue, 9 Oct 2012 12:45:55 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so3673135lam.31 for ; Tue, 09 Oct 2012 12:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=fXn4KbykHCIg6aRSFWxoqGf++DV+xacFLAV8ORdyW2k=; b=QlHVJ58ysRftaEDq/vuxW5kec9KyZ+HspdCNzLlBesGFNePsZPCTKijo9PtVXxJr2u WVO3M3mAoONWluPP3p+ZJerEE15i1D1SxQcrem9rw1Pu5ZCXChnYEecZk8M6hVf4y80D x9MCFky8b9GIeNIDMGjdR4jQYyBkTkS2f4Bac1DWn6dKi4gEt872qsYQ6jTTDsPdFRe3 UwbPRqEirQjdCokQmrKGv+BznbBQPiumEWYqHYrmS7/GUT1in4heNlHJaZofK9dyQ2jY GpHXKraBOXIVuy9vfYHCzz7Q/Jz6FdSwUK969kB7TPNO4ENG1Ov02srfvZAhGloaxNyc /vQA== MIME-Version: 1.0 Received: by 10.112.43.137 with SMTP id w9mr8379128lbl.134.1349811954999; Tue, 09 Oct 2012 12:45:54 -0700 (PDT) Received: by 10.112.111.170 with HTTP; Tue, 9 Oct 2012 12:45:54 -0700 (PDT) Date: Tue, 9 Oct 2012 12:45:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Draft submission deadline reminder X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2012 19:45:56 -0000 Hi all, a quick reminder that because of the upcoming November meeting, draft submissions will be closed until the start of the meeting, as follows: - -00 versions cannot be submitted after October 15, 00:00 UTC - non-00 versions cannot be submitted after October 22, 00:00 UTC If you have initial or updated versions to submit prior to the meeting, please submit them by those times. -MSK, APPSAWG co-chair From superuser@gmail.com Tue Oct 9 12:50:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463871F040A for ; Tue, 9 Oct 2012 12:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 7-RmXuj7IiPm for ; Tue, 9 Oct 2012 12:50:58 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 812F121F87D6 for ; Tue, 9 Oct 2012 12:50:53 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so4439703lbo.31 for ; Tue, 09 Oct 2012 12:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+YCaW0OhLhD0qGO1j67gxPKALvNoec6KevWeJjR/ivk=; b=UcwRM53iy4nLSFNtgJz95pdDzm69b6cnxLWILUBCOKP8ZG02nCqNNrtQwR5P2tGpN2 zAz+eWS218dQdsfdbmANvNw0I6H4JnNaC8Y/Dg9qDmZpKJfwxghjLSYVnagG5DJ7pGxz OL4/al38dz8pB34mJGyq2LKW2sKj/bOGq7sQw5/e2B+T/mEXoOfzgu1PDCOwUBtUjnnc XVIWaclri29jVK3LA4Ls56jcHBl3h1n9cQtU06hBWAS6nlzzB4TLf6gCk2XNTEERML2o ByUmCAhlDJFpqapKY7JFlmLlsgvUZDLdV0UW9Ic15SIAMfojFyhsbC4yH/ardbsungib KYgA== MIME-Version: 1.0 Received: by 10.152.108.197 with SMTP id hm5mr8724258lab.45.1349812252446; Tue, 09 Oct 2012 12:50:52 -0700 (PDT) Received: by 10.112.111.170 with HTTP; Tue, 9 Oct 2012 12:50:52 -0700 (PDT) Date: Tue, 9 Oct 2012 12:50:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Solicitation for 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: Tue, 09 Oct 2012 19:50:59 -0000 Please submit any requests or suggestions for our agenda slot in Atlanta. We have the usual 2 1/2 hour slot first thing Monday morning. The usual things will of course appear on the agenda, including: - administrivia - completed APPSAWG work - overview of current APPSAWG documents - any proposed new APPSAWG work - BoFs of interest - new WGs of interest If there are any specific requests for agenda topics, please reply to this thread so we can plan accordingly. -MSK, WEIRDS co-chair From evan@status.net Tue Oct 9 12:55:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8484A21F8567 for ; Tue, 9 Oct 2012 12:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, 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 krRvJMGLbK+d for ; Tue, 9 Oct 2012 12:55:54 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 96FBC1F0C5F for ; Tue, 9 Oct 2012 12:55:54 -0700 (PDT) Received: from [192.168.0.115] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 2C80B8D57FD; Tue, 9 Oct 2012 20:06:41 +0000 (UTC) Message-ID: <50748149.1030604@status.net> Date: Tue, 09 Oct 2012 15:55:53 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <5049F3F5.4050404@status.net> <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> <027501cda639$7c684f90$7538eeb0$@packetizer.com> In-Reply-To: <027501cda639$7c684f90$7538eeb0$@packetizer.com> Content-Type: multipart/alternative; boundary="------------090206090003040308040203" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] XML in Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 19:55:55 -0000 This is a multi-part message in MIME format. --------------090206090003040308040203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Paul, Per RFC 6415 sec 6.3 : LRDD resources MUST have an "application/xrd+xml" representation, and MAY have others. I think that the de facto default when a type is not defined is XRD, but it's not actually specified in the RFC. -Evan On 12-10-09 12:16 PM, Paul E. Jones wrote: > Evan, > > Perhaps this is not stated and should be, but my assumption would be that if > one requested the XRD version of host-meta, then the LRDD link would refer > to the XML version. Likewise, if one requested the JRD version, then it > would point to the JRD version. > > Note that I do precisely that with my own implementation: > curl http://packetizer.com/.well-known/host-meta > curl http://packetizer.com/.well-known/host-meta > > I explicitly include the "type" attribute so that it is made explicit as to > the format that will be returned. For example: > > type="application/xrd+xml" > template="https://packetizer.com/lrdd/?resource={uri}"/> > > and > > { > "rel" : "lrdd", > "type" : "application/json", > "template" : "https://packetizer.com/lrdd/?format=json&resource={uri}" > } > > Are you suggesting that if the "type" attribute is missing, it defaults to > XRD? Even if the requestor requested host-meta.json or included the > "Accept" header with "application/json"? > > Paul > >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of Evan Prodromou >> Sent: Wednesday, September 26, 2012 1:12 PM >> To: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] XML in Webfinger >> >> Paul, >> >> I'm happy with making XRD "SHOULD" and JRD "MUST". >> >> I suggest that the default content type, if unspecified, stay XRD. So, >> if a client sees: >> >> > template="http://webfinger.example/lrdd?uri={uri}" /> >> >> ...they can be somewhat confident that the results will be XRD, >> regardless of the specification the remote host supports. >> >> -Evan >> >> -- >> Evan Prodromou, CEO and Founder, StatusNet Inc. >> 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 >> E: evan@status.net P: +1-514-554-3826 >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss --------------090206090003040308040203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Paul,

Per RFC 6415 sec 6.3:
LRDD resources MUST have an "application/xrd+xml" representation, and MAY have others.
I think that the de facto default when a type is not defined is XRD, but it's not actually specified in the RFC.

-Evan

On 12-10-09 12:16 PM, Paul E. Jones wrote:
Evan,

Perhaps this is not stated and should be, but my assumption would be that if
one requested the XRD version of host-meta, then the LRDD link would refer
to the XML version.  Likewise, if one requested the JRD version, then it
would point to the JRD version.

Note that I do precisely that with my own implementation:
curl http://packetizer.com/.well-known/host-meta
curl http://packetizer.com/.well-known/host-meta

I explicitly include the "type" attribute so that it is made explicit as to
the format that will be returned.  For example:

  <Link rel="lrdd"
        type="application/xrd+xml"
        template="https://packetizer.com/lrdd/?resource={uri}"/>

and

    {
      "rel" : "lrdd",
      "type" : "application/json",
      "template" : "https://packetizer.com/lrdd/?format=json&resource={uri}"
    }

Are you suggesting that if the "type" attribute is missing, it defaults to
XRD?  Even if the requestor requested host-meta.json or included the
"Accept" header with "application/json"?

Paul


-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
bounces@ietf.org] On Behalf Of Evan Prodromou
Sent: Wednesday, September 26, 2012 1:12 PM
To: apps-discuss@ietf.org
Subject: Re: [apps-discuss] XML in Webfinger

Paul,

I'm happy with making XRD "SHOULD" and JRD "MUST".

I suggest that the default content type, if unspecified, stay XRD. So,
if a client sees:

      <Link rel="lrdd"
                template="http://webfinger.example/lrdd?uri={uri}" />

...they can be somewhat confident that the results will be XRD,
regardless of the specification the remote host supports.

-Evan

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

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


    

    

  


--------------090206090003040308040203--

From internet-drafts@ietf.org  Tue Oct  9 13:04:14 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0EF21F86C2; Tue,  9 Oct 2012 13:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.503
X-Spam-Level: 
X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 MDsIVzVYDJHW; Tue,  9 Oct 2012 13:04:13 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF39121F84DF; Tue,  9 Oct 2012 13:04:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121009200413.10682.93991.idtracker@ietfa.amsl.com>
Date: Tue, 09 Oct 2012 13:04:13 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-03.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Oct 2012 20:04:14 -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           : Advice for Safe Handling of Malformed Messages
	Author(s)       : Murray S. Kucherawy
                          Gregory N. Shapiro
	Filename        : draft-ietf-appsawg-malformed-mail-03.txt
	Pages           : 17
	Date            : 2012-10-09

Abstract:
   The email ecosystem has long had a very permissive set of common
   processing rules in place, despite increasingly rigid standards
   governing its components, ostensibly to improve the user experience.
   The handling of these come at some cost, and various components are
   faced with decisions about whether or not to permit non-conforming
   messages to continue toward their destinations unaltered, adjust them
   to conform (possibly at the cost of losing some of the original
   message), or outright rejecting them.

   This document includes a collection of the best advice available
   regarding a variety of common malformed mail situations, to be used
   as implementation guidance.  It must be emphasized, however, that the
   intent of this document is not to standardize malformations or
   otherwise encourage their proliferation.  The messages are manifestly
   malformed, and the code and culture that generates them needs to be
   fixed.  Therefore, these messages should be rejected outright if at
   all possible.  Nevertheless, many malformed messages from otherwise
   legitimate senders are in circulation and will be for some time, and,
   unfortunately, commercial reality shows that we cannot always simply
   reject or discard them.  Accordingly, this document presents
   alternatives for dealing with them in ways that seem to do the least
   additional harm until the infrastructure is tightened up to match the
   standards.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-malformed-mail-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-malformed-mail-03


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


From dret@berkeley.edu  Tue Oct  9 13:20:23 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000FA1F0422; Tue,  9 Oct 2012 13:20:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.11
X-Spam-Level: 
X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 2fbBr-7PNcsU; Tue,  9 Oct 2012 13:20:22 -0700 (PDT)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 625911F041C; Tue,  9 Oct 2012 13:20:22 -0700 (PDT)
Received: from rrcs-24-43-215-50.west.biz.rr.com ([24.43.215.50] helo=dretair.local) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1TLgHo-0004qz-40; Tue, 09 Oct 2012 13:20:21 -0700
Message-ID: <507486FE.2050601@berkeley.edu>
Date: Tue, 09 Oct 2012 10:20:14 -1000
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: link-relations@ietf.org
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: hypermedia-web@googlegroups.com, LDP WG , REST-Discuss , "apps-discuss@ietf.org application-layer protocols" 
Subject: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-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: Tue, 09 Oct 2012 20:20:23 -0000

dear link-relations experts,

this is a request to register 'describes' in the IANA link relations 
registry established by RFC 5988. the latest draft of the registration 
document is available at 
http://tools.ietf.org/html/draft-wilde-describes-link-01, and the last 
version announced on a variety of mailing lists has not generated any 
feedback asking for changes.

should the registration request be accepted, my understanding is that 
the draft registration document will be forwarded to IANA for 
registration by a designated expert.

thanks a lot and kind regards,

erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

From paulej@packetizer.com  Tue Oct  9 13:23:38 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED0221F86E1 for ; Tue,  9 Oct 2012 13:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.734
X-Spam-Level: 
X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YKznKV1tOdI for ; Tue,  9 Oct 2012 13:23:37 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 03F8C21F86A7 for ; Tue,  9 Oct 2012 13:23:36 -0700 (PDT)
Received: from dyn-157.arid.us (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 q99KNZG5029708 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 9 Oct 2012 16:23:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1349814216; bh=cC8O7C55gm6KHu5vul3mM0v9dVUgJcGvnbvnV/eY+Bk=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=etKzuLoQiO1m49eooTmKoXo7f98kE8W4iPZCXM+hUhg5Q7ikYaK2qUaUmipKhUx7g mX+qUMTHiPn9cQY9RIQxt38ZOmO1jXNsjzoSk2jlttzSa3IpTiN2UZteAekP5TCei9 GFe+t/l0d5QUoMOW3K1BYplR4nDkqsNi6pZqbJhY=
User-Agent: K-9 Mail for Android
In-Reply-To: <50748149.1030604@status.net>
References: <5049F3F5.4050404@status.net>  <504E1116.6060808@status.net> <504E9555.4070605@status.net> <50613AF0.2050706@packetizer.com> <50633767.2010003@status.net> <027501cda639$7c684f90$7538eeb0$@packetizer.com> <50748149.1030604@status.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----TD8IIBWWK49A9MMPNY6IZE9MW1OEOL"
From: "Paul E. Jones" 
Date: Tue, 09 Oct 2012 16:23:32 -0400
To: Evan Prodromou 
Message-ID: <2eab97c0-ed22-403d-b509-fff391b0d528@email.android.com>
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] XML in Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Oct 2012 20:23:38 -0000

------TD8IIBWWK49A9MMPNY6IZE9MW1OEOL
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit

The default for host-meta would be XRD, but it would be JRD if JSON was requested. That needs to be clarified.

Paul


-------- Original Message --------
From: Evan Prodromou 
Sent: Tue Oct 09 15:55:53 EDT 2012
To: "Paul E. Jones" 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] XML in Webfinger

Paul,

Per RFC 6415 sec 6.3 :

    LRDD resources MUST have an "application/xrd+xml" representation, and MAY have others.

I think that the de facto default when a type is not defined is XRD, but 
it's not actually specified in the RFC.

-Evan

On 12-10-09 12:16 PM, Paul E. Jones wrote:
> Evan,
>
> Perhaps this is not stated and should be, but my assumption would be that if
> one requested the XRD version of host-meta, then the LRDD link would refer
> to the XML version.  Likewise, if one requested the JRD version, then it
> would point to the JRD version.
>
> Note that I do precisely that with my own implementation:
> curl http://packetizer.com/.well-known/host-meta
> curl http://packetizer.com/.well-known/host-meta
>
> I explicitly include the "type" attribute so that it is made explicit as to
> the format that will be returned.  For example:
>
>              type="application/xrd+xml"
>          template="https://packetizer.com/lrdd/?resource={uri}"/>
>
> and
>
>      {
>        "rel" : "lrdd",
>        "type" : "application/json",
>        "template" : "https://packetizer.com/lrdd/?format=json&resource={uri}"
>      }
>
> Are you suggesting that if the "type" attribute is missing, it defaults to
> XRD?  Even if the requestor requested host-meta.json or included the
> "Accept" header with "application/json"?
>
> Paul
>
>> -----Original Message-----
>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>> bounces@ietf.org] On Behalf Of Evan Prodromou
>> Sent: Wednesday, September 26, 2012 1:12 PM
>> To: apps-discuss@ietf.org
>> Subject: Re: [apps-discuss] XML in Webfinger
>>
>> Paul,
>>
>> I'm happy with making XRD "SHOULD" and JRD "MUST".
>>
>> I suggest that the default content type, if unspecified, stay XRD. So,
>> if a client sees:
>>
>>        >                  template="http://webfinger.example/lrdd?uri={uri}" />
>>
>> ...they can be somewhat confident that the results will be XRD,
>> regardless of the specification the remote host supports.
>>
>> -Evan
>>
>> --
>> Evan Prodromou, CEO and Founder, StatusNet Inc.
>> 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
>> E: evan@status.net P: +1-514-554-3826
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss


------TD8IIBWWK49A9MMPNY6IZE9MW1OEOL
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

The default for host-meta would be XRD, but it would be JRD if JSON was requested. That needs to be clarified.



Paul




From: Evan Prodromou <evan@status.net>

Sent: Tue Oct 09 15:55:53 EDT 2012

To: "Paul E. Jones" <paulej@packetizer.com>

Cc: apps-discuss@ietf.org

Subject: Re: [apps-discuss] XML in Webfinger






  
    
  
  
    
Paul,

      

      Per RFC
        6415 sec 6.3:

      

        
LRDD resources MUST have an "application/xrd+xml" representation, and MAY have others.


      

      I think that the de facto default when a type is not defined is
      XRD, but it's not actually specified in the RFC.

      

      -Evan

      

      On 12-10-09 12:16 PM, Paul E. Jones wrote:

    

    

      
Evan,

Perhaps this is not stated and should be, but my assumption would be that if
one requested the XRD version of host-meta, then the LRDD link would refer
to the XML version.  Likewise, if one requested the JRD version, then it
would point to the JRD version.

Note that I do precisely that with my own implementation:
curl http://packetizer.com/.well-known/host-meta
curl http://packetizer.com/.well-known/host-meta

I explicitly include the "type" attribute so that it is made explicit as to
the format that will be returned.  For example:

  <Link rel="lrdd"
        type="application/xrd+xml"
        template="https://packetizer.com/lrdd/?resource={uri}"/>

and

    {
      "rel" : "lrdd",
      "type" : "application/json",
      "template" : "https://packetizer.com/lrdd/?format=json&resource={uri}"
    }

Are you suggesting that if the "type" attribute is missing, it defaults to
XRD?  Even if the requestor requested host-meta.json or included the
"Accept" header with "application/json"?

Paul



      

        
-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
bounces@ietf.org] On Behalf Of Evan Prodromou
Sent: Wednesday, September 26, 2012 1:12 PM
To: apps-discuss@ietf.org
Subject: Re: [apps-discuss] XML in Webfinger

Paul,

I'm happy with making XRD "SHOULD" and JRD "MUST".

I suggest that the default content type, if unspecified, stay XRD. So,
if a client sees:

      <Link rel="lrdd"
                template="http://webfinger.example/lrdd?uri={uri}" />

...they can be somewhat confident that the results will be XRD,
regardless of the specification the remote host supports.

-Evan

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

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


      

      

    

    

  


------TD8IIBWWK49A9MMPNY6IZE9MW1OEOL--


From evan@status.net  Tue Oct  9 13:24:39 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4168E21F86E1 for ; Tue,  9 Oct 2012 13:24:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vub5lw-+DWZT for ; Tue,  9 Oct 2012 13:24:38 -0700 (PDT)
Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 362DE21F86F9 for ; Tue,  9 Oct 2012 13:24:38 -0700 (PDT)
Received: from [192.168.0.115] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 0A5138D489E; Tue,  9 Oct 2012 20:35:24 +0000 (UTC)
Message-ID: <50748805.8070602@status.net>
Date: Tue, 09 Oct 2012 16:24:37 -0400
From: Evan Prodromou 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Paul E. Jones" 
References: <5049F3F5.4050404@status.net>		<504E1116.6060808@status.net> <504E9555.4070605@status.net>	<50613AF0.2050706@packetizer.com> <50633767.2010003@status.net>	<4E1F6AAD24975D4BA5B1680429673943667F099C@TK5EX14MBXC284.redmond.corp.microsoft.com> <50635061.2050703@status.net> <027701cda63b$22ef1eb0$68cd5c10$@packetizer.com>
In-Reply-To: <027701cda63b$22ef1eb0$68cd5c10$@packetizer.com>
Content-Type: multipart/alternative; boundary="------------070507030108060406020403"
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Making Webfinger replace RFC 6415 (was Re: XML in Webfinger)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Oct 2012 20:24:39 -0000

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

On 12-10-09 12:28 PM, Paul E. Jones wrote:
>> One thing I'm grappling with with the Webfinger draft is that it depends
>> on RFC 6415, then requires some incompatible changes to that spec, or
>> drops requirements from it.
> Making XML optional will break backward compatibility.  I hate doing that,
> but "it's the will of the people" :-)  However, I think if we make it clear
> that the types used will follow what the user requests, that should be
> sufficient.  Requesting /.well-known/host-meta without explicitly stating a
> type should default to XRD.  However, one might get JRD if XML is not
> supported, and XML will be optional in the next draft.  (I would personally
> implement both on the server since it's trivial, but people do not want to
> be required to do so.)
So, what about using "/.well-known/host-meta.json" instead?

This endpoint has always meant "I want JRD", so there's nothing to worry 
about with content negotiation or XRD defaults. XRD could be dropped 
entirely from the Webfinger draft entirely. It'd make things a lot simpler.

Since host-meta.json wasn't even around before RFC 6415, I don't think 
older implementations will even try to hit that endpoint.
> We could say that this new RFC "updates" RFC 6415, but there's a lot of good
> content in RFC 6415 that I do not think we need to replace.  The procedures
> are the same.  The guidance in there is the same.  We're adding a few
> additional things and changing the MTI format.  I do not think that warrants
> replacing RFC 6415.
I agree with that idea. What I want is to be able to implement RFC 6415 
/and/ the new Webfinger protocol.

I don't think it's that hard as long as we don't mess with older 
processors' expectations.

-Evan


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


  
    
  
  
    
On 12-10-09 12:28 PM, Paul E. Jones
      wrote:
    

    

      

        
One thing I'm grappling with with the Webfinger draft is that it depends
on RFC 6415, then requires some incompatible changes to that spec, or
drops requirements from it.


      

      
Making XML optional will break backward compatibility.  I hate doing that,
but "it's the will of the people" :-)  However, I think if we make it clear
that the types used will follow what the user requests, that should be
sufficient.  Requesting /.well-known/host-meta without explicitly stating a
type should default to XRD.  However, one might get JRD if XML is not
supported, and XML will be optional in the next draft.  (I would personally
implement both on the server since it's trivial, but people do not want to
be required to do so.)

    

    So, what about using "/.well-known/host-meta.json" instead?

    

    This endpoint has always meant "I want JRD", so there's nothing to
    worry about with content negotiation or XRD defaults. XRD could be
    dropped entirely from the Webfinger draft entirely. It'd make things
    a lot simpler.

    

    Since host-meta.json wasn't even around before RFC 6415, I don't
    think older implementations will even try to hit that endpoint.
    

      
We could say that this new RFC "updates" RFC 6415, but there's a lot of good
content in RFC 6415 that I do not think we need to replace.  The procedures
are the same.  The guidance in there is the same.  We're adding a few
additional things and changing the MTI format.  I do not think that warrants
replacing RFC 6415.

    

    I agree with that idea. What I want is to be able to implement RFC
    6415 and the new Webfinger protocol.

    

    I don't think it's that hard as long as we don't mess with older
    processors' expectations.

    

    -Evan

    

  


--------------070507030108060406020403--

From evan@status.net  Tue Oct  9 14:50:54 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77CB21F84F3 for ; Tue,  9 Oct 2012 14:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 75vEUa1qmaZz for ; Tue,  9 Oct 2012 14:50:54 -0700 (PDT)
Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 322541F041C for ; Tue,  9 Oct 2012 14:50:54 -0700 (PDT)
Received: from [192.168.0.115] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 1C4168D5D81; Tue,  9 Oct 2012 22:01:40 +0000 (UTC)
Message-ID: <50749C3C.1020206@status.net>
Date: Tue, 09 Oct 2012 17:50:52 -0400
From: Evan Prodromou 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Mike Jones 
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] (no subject)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Oct 2012 21:50:55 -0000

DON'T COME.

From evan@status.net  Tue Oct  9 14:52:00 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2951F041C for ; Tue,  9 Oct 2012 14:52:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vMkfBa+pwnj for ; Tue,  9 Oct 2012 14:51:59 -0700 (PDT)
Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 5E04C11E80A6 for ; Tue,  9 Oct 2012 14:51:59 -0700 (PDT)
Received: from [192.168.0.115] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 5BD698D5DBE; Tue,  9 Oct 2012 22:02:46 +0000 (UTC)
Message-ID: <50749C7E.3070501@status.net>
Date: Tue, 09 Oct 2012 17:51:58 -0400
From: Evan Prodromou 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Mike Jones 
References: <> <50749C3C.1020206@status.net>
In-Reply-To: <50749C3C.1020206@status.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] (no subject)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Oct 2012 21:52:00 -0000

On 12-10-09 05:50 PM, Evan Prodromou wrote:
> DON'T COME.
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
Sorry about that; I was responding to a different email. No idea how it 
got here.

-Evan


From barryleiba.mailing.lists@gmail.com  Tue Oct  9 16:40:09 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA1711E80ED; Tue,  9 Oct 2012 16:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.089
X-Spam-Level: 
X-Spam-Status: No, score=-103.089 tagged_above=-999 required=5 tests=[AWL=-0.112, 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 eFnF2QtKwSCr; Tue,  9 Oct 2012 16:40:07 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 63E0411E80E8; Tue,  9 Oct 2012 16:40:06 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so3812835lam.31 for ; Tue, 09 Oct 2012 16:40:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EF1XM0TRpEluUNn53Sh4nApCMLOPuLgNUxdAzClnRRo=; b=ZxlIJ9RhI5AFr60+0yzH/7JjyfoRVoWcIvFcHUb1F1GCsGYKbLtAbZGvsbljC3LWBe JoZEfxpGH/ssIfIw8gbDQUDJ6xQu87OPCiywlK6qWkklsc01oAIDHYxDndpIJGWRo1jW W7rzsk8E5ttXk8csi7AhAIiH9gLMRtuToN/uXt1bDQaJEQsuHK5KxIEwWs/cEhscSet5 l517hQDJVyIuXl0WZ6BO2E2cJQc1GgJcMWW9PyGhz46AkMykY9khnrAxTS7LoRIQAZDZ EtfuF1jZpHfzlZ5Nwrav4dMon2+IoGkjS2lQLYzW9Eqp6g/vPJ5654sveF3eVmcXWtmW jCSA==
MIME-Version: 1.0
Received: by 10.112.103.7 with SMTP id fs7mr3469251lbb.25.1349826005265; Tue, 09 Oct 2012 16:40:05 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.112.150.194 with HTTP; Tue, 9 Oct 2012 16:40:05 -0700 (PDT)
In-Reply-To: <507486FE.2050601@berkeley.edu>
References: <507486FE.2050601@berkeley.edu>
Date: Tue, 9 Oct 2012 19:40:05 -0400
X-Google-Sender-Auth: gkZKcscjYRmdeA7xIP0K29h7NRY
Message-ID: 
From: Barry Leiba 
To: Erik Wilde 
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss@ietf.org, link-relations@ietf.org
Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-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: Tue, 09 Oct 2012 23:40:10 -0000

[I'm removing the non-IETF groups from the distribution list.]

> this is a request to register 'describes' in the IANA link relations
> registry established by RFC 5988. the latest draft of the registration
> document is available at
> http://tools.ietf.org/html/draft-wilde-describes-link-01, and the last
> version announced on a variety of mailing lists has not generated any
> feedback asking for changes.

I'll let the folks on the link-relations list respond to the
suitability of the specification for documenting a useful link
relation.  I have just a couple of process points:

1. In order for the registration to be done, this document will have
to be published somewhere that will satisfy the Designated Expert as
being a stable reference.  That probably means that you'll want this
to be an RFC, so you need to be sorting out how that will happen.
Happily, I'm willing to sponsor this as an AD-sponsored individual
submission, if the link-relations folks agree that we should register
this.

2. I don't think this should be Standards Track, though (and it
doesn't need to be in order to register the link relation and to be
the reference documentation for it).  I would prefer that you make it
Informational, change the "SHOULD" to "should" in the Security
Considerations, and remove Section 2 and the normative reference to
RFC 2119.  (This can wait until after the feedback from the
link-relations mailing list.)

Barry, Applications AD

From jasnell@gmail.com  Tue Oct  9 17:10:04 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C86C11E80EE; Tue,  9 Oct 2012 17:10:04 -0700 (PDT)
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 N8AnSBHPlfDh; Tue,  9 Oct 2012 17:10:03 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C8B6D21F855D; Tue,  9 Oct 2012 17:10:02 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr13so3459607wgb.13 for ; Tue, 09 Oct 2012 17:10:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Q4iZghSU7G2jse4oMNUEPN/KnS/j3Sdg3lACmtI6tY8=; b=DVbMClyFzAMzqGUQSHuUAjTLpalqx7QD+YcDZd7ySEjV1aDf/rQsZrm4dCbHGhFqer 0NO8Q4IlUF7CqMALI7X6lxp0UdRS9W3K//kfEc1NZ8GxWMEqBPGA8UhaYH8hOJ9QFza0 NZ+A0K/+o5uqH/ySWTwndWFdLKpo9WMIzu6KLpZqhMCrsHCwvcQAmozK+vXml3ULK7EO 9/GU0ZxdnQz6Aa8IUYcDQN0zoG5BIlQXVp7oPGTyGkP2L3j6CrBNPvqi/39BM5Hea1XW WRFXVBpW6dmhQHq7iN6aUY4zBVBIXITdlkuVJPKWYQhhrNfF9ewrKI8LttsOiPhWFKBc +kLA==
Received: by 10.180.80.104 with SMTP id q8mr8406906wix.6.1349827801901; Tue, 09 Oct 2012 17:10:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.182.4 with HTTP; Tue, 9 Oct 2012 17:09:41 -0700 (PDT)
In-Reply-To: 
References: <507486FE.2050601@berkeley.edu> 
From: James M Snell 
Date: Tue, 9 Oct 2012 17:09:41 -0700
Message-ID: 
To: Barry Leiba 
Content-Type: multipart/alternative; boundary=f46d04428eaca3e9b804cba94633
Cc: apps-discuss@ietf.org, link-relations@ietf.org
Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-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, 10 Oct 2012 00:10:04 -0000

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

Sticking my hand up and hoping to get some similar treatment for:

  http://www.ietf.org/id/draft-snell-additional-link-relations-05.txt

This one has been there for a while. I followed the same advice you just
gave dret and changed it to informational and cleaned up the normative
references. Pretty basic draft.

- James

On Tue, Oct 9, 2012 at 4:40 PM, Barry Leiba  wrote:

> [I'm removing the non-IETF groups from the distribution list.]
>
> > this is a request to register 'describes' in the IANA link relations
> > registry established by RFC 5988. the latest draft of the registration
> > document is available at
> > http://tools.ietf.org/html/draft-wilde-describes-link-01, and the last
> > version announced on a variety of mailing lists has not generated any
> > feedback asking for changes.
>
> I'll let the folks on the link-relations list respond to the
> suitability of the specification for documenting a useful link
> relation.  I have just a couple of process points:
>
> 1. In order for the registration to be done, this document will have
> to be published somewhere that will satisfy the Designated Expert as
> being a stable reference.  That probably means that you'll want this
> to be an RFC, so you need to be sorting out how that will happen.
> Happily, I'm willing to sponsor this as an AD-sponsored individual
> submission, if the link-relations folks agree that we should register
> this.
>
> 2. I don't think this should be Standards Track, though (and it
> doesn't need to be in order to register the link relation and to be
> the reference documentation for it).  I would prefer that you make it
> Informational, change the "SHOULD" to "should" in the Security
> Considerations, and remove Section 2 and the normative reference to
> RFC 2119.  (This can wait until after the feedback from the
> link-relations mailing list.)
>
> Barry, Applications AD
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

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

Sticking my hand up and hoping to get =
some similar treatment for:=C2=A0





This one has been there for a while. I followed =
the same advice you just gave dret and changed it to informational and clea=
ned up the normative references. Pretty basic draft.




- James

On Tue, Oct 9, 2012 at 4:40 PM, Barry Leiba <barryleiba@computer.o=
rg> wrote:



[I'm removing the non-IETF groups from t=
he distribution list.]




> this is a request to register 'describes' in the IANA link rel=
ations

> registry established by RFC 5988. the latest draft of the registration=


> document is available at

> http://tools.ietf.org/html/draft-wilde-describes-link-01, and the last

> version announced on a variety of mailing lists has not generated any<=
br>
> feedback asking for changes.




I'll let the folks on the link-relations list respond to the

suitability of the specification for documenting a useful link

relation. =C2=A0I have just a couple of process points:



1. In order for the registration to be done, this document will have

to be published somewhere that will satisfy the Designated Expert as

being a stable reference. =C2=A0That probably means that you'll want th=
is

to be an RFC, so you need to be sorting out how that will happen.

Happily, I'm willing to sponsor this as an AD-sponsored individual

submission, if the link-relations folks agree that we should register

this.



2. I don't think this should be Standards Track, though (and it

doesn't need to be in order to register the link relation and to be

the reference documentation for it). =C2=A0I would prefer that you make it<=
br>
Informational, change the "SHOULD" to "should" in the S=
ecurity

Considerations, and remove Section 2 and the normative reference to

RFC 2119. =C2=A0(This can wait until after the feedback from the

link-relations mailing list.)



Barry, Applications AD


___________________________________=
____________

apps-discuss mailing list

apps-discuss@ietf.org

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





--f46d04428eaca3e9b804cba94633--

From barryleiba.mailing.lists@gmail.com  Tue Oct  9 17:19:14 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017EB11E80EE; Tue,  9 Oct 2012 17:19:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.08
X-Spam-Level: 
X-Spam-Status: No, score=-103.08 tagged_above=-999 required=5 tests=[AWL=-0.103, 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 YDp0Q+zf6+pn; Tue,  9 Oct 2012 17:19:13 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA84121F857E; Tue,  9 Oct 2012 17:19:11 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id k13so24980lbo.31 for ; Tue, 09 Oct 2012 17:19:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9SG1P5qSIB32Xj1/RXV1ObFwK2a3ae2LQk7ZfcdpYyo=; b=hGCYfKBhNr3nBIwYVBFsiLuEfdawdmU/OT0QveIJiqaq5ciR06YXeKesTO+K6goMiB m4js8w4aO28oyW5rweoUz0ui2baxacDXyPV1cylSuxZRDfSqPlJ7suyzp1SN8asWKXBQ ML/nunJbP55FLkwkqQY1kW8QX39nP+71otrBoOfaUTQbMfawZRDL0t3pcK0nWwcl1f6P qtogG9KhpSxvSzrwdZf3hcnQ3oKH85uNEnYkL0DlQ1yZa1v2DmYeupYdgJAGXxLQ1srN S8DVgGngXUn7EJKCoohYrFZ+HBnDaqWnsZaosvyjb8eiBGkBQNqdyrksvrAKyH2mT1f1 We/A==
MIME-Version: 1.0
Received: by 10.112.47.133 with SMTP id d5mr8916569lbn.47.1349828350898; Tue, 09 Oct 2012 17:19:10 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.112.150.194 with HTTP; Tue, 9 Oct 2012 17:19:10 -0700 (PDT)
In-Reply-To: 
References: <507486FE.2050601@berkeley.edu>  
Date: Tue, 9 Oct 2012 20:19:10 -0400
X-Google-Sender-Auth: rxI7hS_XWcm72eNOuR-Ps15Xljw
Message-ID: 
From: Barry Leiba 
To: James M Snell 
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss@ietf.org, link-relations@ietf.org
Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-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, 10 Oct 2012 00:19:14 -0000

> Sticking my hand up and hoping to get some similar treatment for:
>
>   http://www.ietf.org/id/draft-snell-additional-link-relations-05.txt
>
> This one has been there for a while. I followed the same advice you just
> gave dret and changed it to informational and cleaned up the normative
> references. Pretty basic draft.

Indeed.  I suggest that you change the references in each template to
include the section number -- not that the document is long enough to
really matter, but I very much like the cleanliness of it.  For
example:

   o  Relation Name: about
   o  Description: Refers to a resource that is the subject of the
      link's context.
   o  Reference: This specification, Section 2.

Link-relations folk, consider this a formal request for review of the
five relations in the above draft.  After comments here, I'll send the
document out for IETF last call.

Barry

From dret@berkeley.edu  Tue Oct  9 17:19:49 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7560F1F0C5C; Tue,  9 Oct 2012 17:19:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.227
X-Spam-Level: 
X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372,  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 wSNZhin6iHMv; Tue,  9 Oct 2012 17:19:48 -0700 (PDT)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id BC05B1F0C4C; Tue,  9 Oct 2012 17:19:48 -0700 (PDT)
Received: from rrcs-24-43-239-58.west.biz.rr.com ([24.43.239.58] 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 1TLk1a-00053B-Ca; Tue, 09 Oct 2012 17:19:48 -0700
Message-ID: <5074BF1F.7030608@berkeley.edu>
Date: Tue, 09 Oct 2012 14:19:43 -1000
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Barry Leiba 
References: <507486FE.2050601@berkeley.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org application-layer protocols" , link-relations@ietf.org
Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-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, 10 Oct 2012 00:19:49 -0000

hello barry.

On 2012-10-09 13:40 , Barry Leiba wrote:
> [I'm removing the non-IETF groups from the distribution list.]

i tried sending this to barry only, but barryleiba@computer.org does not 
seem to be a valid email address, so i'll respond to the list and hope 
barry will get in trough the list somehow.

> I'll let the folks on the link-relations list respond to the
> suitability of the specification for documenting a useful link
> relation.  I have just a couple of process points:

thanks for the feedback. i guess i am still a bit confused about the 
process. my understanding was that the link-relations experts would 
provide feedback, and then it would be sponsored as an RFC. apparently, 
that's not how things are working. also, please be advised that another 
similar request was sent to the link-relations and apps-discuss experts 
very recently 
(http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07356.html), 
and i guess your comments apply to this other request as well.

> 1. In order for the registration to be done, this document will have
> to be published somewhere that will satisfy the Designated Expert as
> being a stable reference.  That probably means that you'll want this
> to be an RFC, so you need to be sorting out how that will happen.
> Happily, I'm willing to sponsor this as an AD-sponsored individual
> submission, if the link-relations folks agree that we should register
> this.

thanks. would you be willing to sponsor the other draft 
(http://tools.ietf.org/html/draft-wilde-profile-link-03) as well?

> 2. I don't think this should be Standards Track, though (and it
> doesn't need to be in order to register the link relation and to be
> the reference documentation for it).  I would prefer that you make it
> Informational, change the "SHOULD" to "should" in the Security
> Considerations, and remove Section 2 and the normative reference to
> RFC 2119.  (This can wait until after the feedback from the
> link-relations mailing list.)

i assume these changes would apply to the other draft as well. for now i 
will wait for the feedback from the link-relations experts, and if they 
seem to be in favor, i will prepare new versions for both drafts, 
changing the track, and making the other changes you have mentioned.

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 jasnell@gmail.com  Tue Oct  9 17:26:19 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1648B1F0C4C; Tue,  9 Oct 2012 17:26:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.579
X-Spam-Level: 
X-Spam-Status: No, score=-4.579 tagged_above=-999 required=5 tests=[AWL=-0.981, 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 E99rXjmHThLF; Tue,  9 Oct 2012 17:26:18 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id E6D081F0C5C; Tue,  9 Oct 2012 17:26:17 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hr7so4677384wib.13 for ; Tue, 09 Oct 2012 17:26:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aosZmi0ChYieWanbQEsMnIRKZPKachXoF7/SRVmppco=; b=iEwnJWPbULphMgWsE4os2TMV+sn8hnri5qFmO2i4nxfFkvy76MRa8liF6rKmdLqPvp Skl+wLZ7bf8qHEV8xenHxCD4ygU2HzXbzQCBuvusEZpKdQuv4C82srgjP1uRki5e/UPk medPA82kzC55XoqRZLE7SASxYicpCCLt9Gm6Sr0rWYViFI8tGcaKdqbEKjAF2CMNlNyZ QmiNwr1geQXmzG+cGZU+MrFsnoj2oY301Xy0GuVCBRa+14Hu/pr0LT7vJF1oBRF/rBDV 9GHtvvHdnB1sncn2X2DlsxoZ51ocDxZFDME7fMPvYE4XtItGkkEHSvGzehfXBAa1i/vB oxeg==
Received: by 10.216.204.139 with SMTP id h11mr13104213weo.128.1349828776896; Tue, 09 Oct 2012 17:26:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.182.4 with HTTP; Tue, 9 Oct 2012 17:25:56 -0700 (PDT)
In-Reply-To: 
References: <507486FE.2050601@berkeley.edu>   
From: James M Snell 
Date: Tue, 9 Oct 2012 17:25:56 -0700
Message-ID: 
To: Barry Leiba 
Content-Type: multipart/alternative; boundary=0016e6d589e1c12a7004cba9800b
Cc: apps-discuss@ietf.org, link-relations@ietf.org
Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-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, 10 Oct 2012 00:26:19 -0000

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

Ok... given that I just rev'd the draft and that's a pretty editorial
change, let's hold off on that one until the final edit. I'd say this one
is pretty much done and ready for a last call. Assuming everything goes
through with that, I can make that section number change in the
templates...

- James

On Tue, Oct 9, 2012 at 5:19 PM, Barry Leiba  wrote:

> > Sticking my hand up and hoping to get some similar treatment for:
> >
> >   http://www.ietf.org/id/draft-snell-additional-link-relations-05.txt
> >
> > This one has been there for a while. I followed the same advice you just
> > gave dret and changed it to informational and cleaned up the normative
> > references. Pretty basic draft.
>
> Indeed.  I suggest that you change the references in each template to
> include the section number -- not that the document is long enough to
> really matter, but I very much like the cleanliness of it.  For
> example:
>
>    o  Relation Name: about
>    o  Description: Refers to a resource that is the subject of the
>       link's context.
>    o  Reference: This specification, Section 2.
>
> Link-relations folk, consider this a formal request for review of the
> five relations in the above draft.  After comments here, I'll send the
> document out for IETF last call.
>
> Barry
>

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

Ok... given that I just rev'd the =
draft and that's a pretty editorial change, let's hold off on that =
one until the final edit. I'd say this one is pretty much done and read=
y for a last call. Assuming everything goes through with that, I can make t=
hat section number change in the templates...=C2=A0



- James

On Tu=
e, Oct 9, 2012 at 5:19 PM, Barry Leiba <barryleiba@computer.org&=
gt; wrote:



> Sticking my hand up a=
nd hoping to get some similar treatment for:

>

> =C2=A0 http://www.ietf.org/id/draft-snell-addit=
ional-link-relations-05.txt

>

> This one has been there for a while. I followed the same advice you ju=
st

> gave dret and changed it to informational and cleaned up the normative=


> references. Pretty basic draft.




Indeed. =C2=A0I suggest that you change the references in each templa=
te to

include the section number -- not that the document is long enough to

really matter, but I very much like the cleanliness of it. =C2=A0For

example:



=C2=A0 =C2=A0o =C2=A0Relation Name: about

=C2=A0 =C2=A0o =C2=A0Description: Refers to a resource that is the subject =
of the

=C2=A0 =C2=A0 =C2=A0 link's context.

=C2=A0 =C2=A0o =C2=A0Reference: This specification, Section 2.



Link-relations folk, consider this a formal request for review of the

five relations in the above draft. =C2=A0After comments here, I'll send=
 the

document out for IETF last call.



Barry





--0016e6d589e1c12a7004cba9800b--

From barryleiba.mailing.lists@gmail.com  Tue Oct  9 17:35:27 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2471F0C71; Tue,  9 Oct 2012 17:35:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.079
X-Spam-Level: 
X-Spam-Status: No, score=-103.079 tagged_above=-999 required=5 tests=[AWL=-0.102, 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 MOjb6x-0KhXk; Tue,  9 Oct 2012 17:35:26 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A18211F0C4C; Tue,  9 Oct 2012 17:35:25 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so3837343lam.31 for ; Tue, 09 Oct 2012 17:35:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/4xkzJtSjIOJwIJStM5THHQQ7LnCHCHtBiMutLiGVNQ=; b=Zl8Sjd4Exmn8La0yH1pmLOqzS32al7y3VuhBwIq8fYRgvvpIdze8I9Qn8fQAKk9uxo dv2/HO/RtyxXqwmtRG2IfQbJQ6iPiITy164wuNRD/5ciJRWRzYOdkGgrM/VALOeIXp68 /KHByXrkhjGQzyh9E6QdaDtd5S3pUWtFdG3rpZiLDaEuVDVA9/UVY/3xZX1eKZ6BMhps ZCaZa4q7yeqLxI9mtxC1NFSwq+5t/omLLBcw2OjuLFuNGdPf+azaKjxDayraRaJgRYbC +SHT0k4g2kBJHcn6dGcsB/D9aWomPESmA5CROWfzHoMhI8oqIcDeOLkyD4/cCa5xFMwh /stA==
MIME-Version: 1.0
Received: by 10.152.108.197 with SMTP id hm5mr9303982lab.45.1349829324577; Tue, 09 Oct 2012 17:35:24 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.112.150.194 with HTTP; Tue, 9 Oct 2012 17:35:24 -0700 (PDT)
In-Reply-To: <5074BF1F.7030608@berkeley.edu>
References: <507486FE.2050601@berkeley.edu>  <5074BF1F.7030608@berkeley.edu>
Date: Tue, 9 Oct 2012 20:35:24 -0400
X-Google-Sender-Auth: me5Zbp9kSsXnqgcLvVVWHUIlm-4
Message-ID: 
From: Barry Leiba 
To: Erik Wilde 
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss@ietf.org, link-relations@ietf.org
Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-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, 10 Oct 2012 00:35:27 -0000

> i tried sending this to barry only, but barryleiba@computer.org does not
> seem to be a valid email address, so i'll respond to the list and hope barry
> will get in trough the list somehow.

Grumble...
IEEE (computer.org is a forwarding service of the IEEE Computer
Society) has recently started using Postini for filtering, and that's
caused sporadic problems, wherein the Postini filtering servers appear
sometimes to fail to contact the IEEE address validation servers...
and Postini takes the failure to be able to validate the address as
meaning that the address is invalid, and bounces the message.  It only
happens sometimes, and they're not answering my messages asking when
it will be fixed (well, or maybe they are, and...).

In any case, I got this message both through the list and directly.

> thanks for the feedback. i guess i am still a bit confused about the
> process. my understanding was that the link-relations experts would provide
> feedback, and then it would be sponsored as an RFC. apparently, that's not
> how things are working.

I'm not entirely sure.  Theoretically, at least, they will approve
requests for which they are satisfied that the documentation will be
published as a stable, public specification.  Internet Drafts won't
necessarily be that.  Those that come through a working group are
pretty safe, but individual submissions might or might not go
anywhere.

In practice, I don't know whether Mark and Julian are looking for an
AD sponsor before approving, or simply making their approval
contingent on the publication of the document (I'll have to ask them).
 Anyway, if you have an AD sponsor first (which you now do), we have
that covered.

> also, please be advised that another similar request
> was sent to the link-relations and apps-discuss experts very recently
> (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07356.html)
...
> (http://tools.ietf.org/html/draft-wilde-profile-link-03)

Yes, I'm happy to sponsor that one as well, and, yes, please also make
that Informational after we get feedback from the link-relations list
and the DEs.

I'll change the state of both document to Publication Requested, and
we can start the process.

Barry

From yoshiro.yoneya@jprs.co.jp  Tue Oct  9 23:02:12 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA80421F870F for ; Tue,  9 Oct 2012 23:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8UwttQlcQpH for ; Tue,  9 Oct 2012 23:02:12 -0700 (PDT)
Received: from off-send02.tyo.jprs.co.jp (off-send02.tyo.jprs.co.jp [IPv6:2001:df0:8:17::20]) by ietfa.amsl.com (Postfix) with ESMTP id 0693C21F870E for ; Tue,  9 Oct 2012 23:02:10 -0700 (PDT)
Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send02.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q9A61qX7010493; Wed, 10 Oct 2012 15:01:52 +0900
X-AuditID: ac120820-b7fd46d0000058b8-3b-50750f50c2f1
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 AD.03.22712.05F05705; Wed, 10 Oct 2012 15:01:52 +0900 (JST)
Date: Wed, 10 Oct 2012 15:01:52 +0900
From: Yoshiro YONEYA 
To: apps-discuss@ietf.org, idna-update@alvestrand.no
Message-Id: <20121010150152.e392601a08057f68a4fbef6b@jprs.co.jp>
X-Mailer: Sylpheed 3.2.0 (GTK+ 2.10.14; i686-pc-mingw32)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsWyRoiFTzeAvzTA4OssSYvVL1ewWcw//o/V gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYclys4BtHxdObl1gbGGewdzFyckgImEh8 P3OHGcIWk7hwbz1bFyMXh5DAcUaJu9PmsYIkWARUJb4en88CYrMJGEj8WvabqYuRg0MEqHnW 5gCQsLCAjMT22+vBynkFHCTWti1hgZhpIfH37newcl4BQYm/O4RBwswCWhIPf91igbDlJba/ ncM8gZFnFkLVLCRVs5BULWBkXsUok5+WplucmpdSnJtuYKhXUpmvl1VQVKyXDKI3MYKDh0Nh B+OMUwaHGAU4GJV4eDVySwKEWBPLiitzDzFKcjApifL+4y4NEOJLyk+pzEgszogvKs1JLT7E KMHBrCTCK7MSqJw3JbGyKrUoHyYlzcGiJM57/OwOPyGB9MSS1OzU1ILUIpisDAeHkgSvCh/Q UMGi1PTUirTMnBKENBMHJ8hwHqDh9iA1vMUFibnFmekQ+VOMklLivM95gRICIImM0jy43leM 4kAvCPMag7TxABMBXNcroIFMINdOArm2uCQRISXVwDixQHtz7IakJo1ftpbyEhlmqWafrhgn alQ/CTR4kc1w5qrAle7mhcWCr47aW32KiPrBXZl7Za6QvO4HgQtCDGHaljUvNFvkL/KKHFK7 sFirVpjDx0BEomuOXLLSM7YHXQq3rYzvrWro0C0ROqWqed+YsYf5kv8Jzua9cfzr1Jm2ysW2 3ORQYinOSDTUYi4qTgQAr4L97cECAAA=
Subject: [apps-discuss] idnkit-2.2 released
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2012 06:02:12 -0000

Dear all,

I'm very pleased to announce that JPRS has released idnkit-2.2 which is
an implementation of IDNA2008, and it provides features IDN encoding 
conversion tool and APIs for application software.

The idnkit-2.2 and its additional packages are available from following URL:


Major changes since idnkit-2.1 release are:

- Licence update
  + Added license version (version 1.1)
  + Modified article 6 and article 7 of the license to be more advantageous 
    to the end users
  + Updated year of the copyright notice
- Correspond to RFC publication
  + IDNA Table version was updated according to RFC 6452 publication
  + Reference revision of UTS#46 was updated (3->5) according to Unicode 
    6.0.0 correspondence

I hope that the idnkit-2.2 is useful for IDN zone administrators, IDN site 
administrators, IDN-aware application developers, and I18N related protocol 
designers.

Please feel free to give your comments about the idnkit-2.2 to following 
e-mail address:


Regards,

-- 
Yoshiro YONEYA 


From dret@berkeley.edu  Tue Oct  9 23:11:45 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230E121F8587; Tue,  9 Oct 2012 23:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.351
X-Spam-Level: 
X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248,  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 agvmrXL++KeZ; Tue,  9 Oct 2012 23:11:44 -0700 (PDT)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8E421F8582; Tue,  9 Oct 2012 23:11:44 -0700 (PDT)
Received: from rrcs-24-43-215-50.west.biz.rr.com ([24.43.215.50] 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 1TLpWA-0000nU-8m; Tue, 09 Oct 2012 23:11:43 -0700
Message-ID: <5075119A.1020104@berkeley.edu>
Date: Tue, 09 Oct 2012 20:11:38 -1000
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: nathan@webr3.org
References: <507486FE.2050601@berkeley.edu> <5074B197.9050101@webr3.org>
In-Reply-To: <5074B197.9050101@webr3.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: hypermedia-web@googlegroups.com, LDP WG , REST-Discuss , "apps-discuss@ietf.org application-layer protocols" , link-relations@ietf.org
Subject: Re: [apps-discuss] [rest-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-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, 10 Oct 2012 06:11:45 -0000

hello nathan.

On 2012-10-09 13:21 , Nathan wrote:
> Looks good and most useful, is it worth mentioning anywhere that this
> inverse relations(describes being the inverse of describedby) is now
> needed due to @rev falling out of fashion? It may help explain why
> describes wasn't defined by powder in the first instance.

honestly, i think such a comment would probably confuse more people than 
it would help. @rev never was a popular idea to begin with and only part 
of relatively few vocabularies.

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 Oct 10 00:02:20 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB4121F8742; Wed, 10 Oct 2012 00:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.413
X-Spam-Level: 
X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186,  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 3CdPRAlSq2jO; Wed, 10 Oct 2012 00:02:19 -0700 (PDT)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id B10F521F8735; Wed, 10 Oct 2012 00:02:19 -0700 (PDT)
Received: from rrcs-24-43-239-58.west.biz.rr.com ([24.43.239.58] 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 1TLqJ8-0007vN-7S; Wed, 10 Oct 2012 00:02:19 -0700
Message-ID: <50751D76.9000908@berkeley.edu>
Date: Tue, 09 Oct 2012 21:02:14 -1000
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Barry Leiba 
References: <507486FE.2050601@berkeley.edu>  <5074BF1F.7030608@berkeley.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org, link-relations@ietf.org
Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-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, 10 Oct 2012 07:02:20 -0000

hello barry.

On 2012-10-09 14:35 , Barry Leiba wrote:
> In practice, I don't know whether Mark and Julian are looking for an
> AD sponsor before approving, or simply making their approval
> contingent on the publication of the document (I'll have to ask them).
>   Anyway, if you have an AD sponsor first (which you now do), we have
> that covered.

great, thanks again and for now, that means we have to wait for the 
link-relations experts to respond and hear what their feedback is.

>> also, please be advised that another similar request
>> was sent to the link-relations and apps-discuss experts very recently
>> (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07356.html)
> ...
>> (http://tools.ietf.org/html/draft-wilde-profile-link-03)
> Yes, I'm happy to sponsor that one as well, and, yes, please also make
> that Informational after we get feedback from the link-relations list
> and the DEs.
> I'll change the state of both document to Publication Requested, and
> we can start the process.

just to make sure everything goes as it should: for now, i'll adjust my 
local copies of the next versions of both drafts. as soon as we hear 
from the link-relations experts, i can publish new versions 
incorporating the changes making the drafts informational, and any 
changes requested by the experts.

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 jan.algermissen@nordsc.com  Wed Oct 10 04:03:43 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCDD21F8543 for ; Wed, 10 Oct 2012 04:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlguA-+SyOqH for ; Wed, 10 Oct 2012 04:03:43 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 15E1E21F8530 for ; Wed, 10 Oct 2012 04:03:43 -0700 (PDT)
Received: from [10.90.131.173] ([87.253.171.222]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0Ls5Ln-1TWBX83fgt-013TQF; Wed, 10 Oct 2012 13:03:42 +0200
From: Jan Algermissen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 10 Oct 2012 13:03:44 +0200
Message-Id: 
To: "apps-discuss@ietf.org application-layer protocols" 
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:C56FFxWw++p6lU5geGPtCYi1D2Oa4wcAIFxy//bsyHC ZDS+meoZCsuOEF3i//QuqkDgPyPDPi2F4cYCxb/riJurCJMXIw rHkwA0nfDG5Tb+1UvY9ZvHW7meJzp2CpT4ov8HazJNmv/OJAsk poXho+8sfQKrmnGZQ3qn74SUpnd8SV/uAUfB35DpQ9I4BYpjKT lFgc3Yj9FOsUAHFPIgKWLoEyNsfggY807V+hRUbdfVWgG1NG8u JaRo+qIo5B4SvYSUyTv0GBvrehUPIhRuQZUxtqtOgaDO3ttoSs sGtqiSHywImgek/Yr70fTZNW/w96C16E8R53mXzQTV4A9d8g8G qsleGksNlFWkQsHBccnJjEhq71K7lH2+NBctfoF/szV6pchrzU HFLYUGRavdvng==
Subject: [apps-discuss] Media Type for HTML 'snippets'?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2012 11:03:43 -0000

Hi,

I am looking for an appropriate media type to use when serving HTML =
snippets that have a 
 as their root element.

I feel that serving HTML document fragments has become such a common =
scenario, I think there must be some solution already. However - I =
cannot find anything appropriate.

The closest thing is likely Atom's type attribute: =
http://tools.ietf.org/html/rfc4287#section-3.1.1.3

Can anyone provide a pointer or ideas?

Or is it time probably time for application/xhtml-div+xml

Jan=

From jonm@jjmoore.net  Wed Oct 10 04:33:23 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D50321F876C for ; Wed, 10 Oct 2012 04:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level: 
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 6KhFK+lQB9R1 for ; Wed, 10 Oct 2012 04:33:22 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A4D0621F8764 for ; Wed, 10 Oct 2012 04:33:22 -0700 (PDT)
Received: by mail-qa0-f44.google.com with SMTP id 25so4387348qao.10 for ; Wed, 10 Oct 2012 04:33:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=JdLKXXOCLi+xuALCYtDwTuLlCiWC0tK9fRZf3KQtkC0=; b=L4/B6P6JXPb6skCx8v+05gfwMjfQ4tYwkY48ZWc0IiFcvJrmjhVNfCjM6FH+08cgww nMW+FlNDHG72ZtaTctcIVin/KY9vbkVb73w8Daj+V7v87Z8/xNwOAejwboR0K/EN4hU8 J/xCIouqp6y58k7sj7YE3mALSwLOjGGkT39YJyj8aDX9/RMuL3xl0pxZmqNJXXa0QIaE wByfnHFvGaXpf0K1mTyCOSkIOWpaZUUhZnBdJ66CtrwujLjkOttFKJsYfqfcoGNrHmIg pXcTYbrUZPA9HF0WJzwvRsGxrOsZF4kiwZ+XD08y40KFgZ06Nwf/63C3rA/v8eUg1rwz BaNQ==
Received: by 10.229.178.138 with SMTP id bm10mr4406367qcb.31.1349868802157; Wed, 10 Oct 2012 04:33:22 -0700 (PDT)
Received: from [192.168.154.100] (c-68-32-29-233.hsd1.pa.comcast.net. [68.32.29.233]) by mx.google.com with ESMTPS id gd19sm948803qeb.0.2012.10.10.04.33.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2012 04:33:21 -0700 (PDT)
References: 
In-Reply-To: 
Mime-Version: 1.0 (1.0)
Content-Type: text/plain; charset=us-ascii
Message-Id: <802E941C-0B2A-4430-99DD-A468C255DC9E@jjmoore.net>
Content-Transfer-Encoding: quoted-printable
X-Mailer: iPhone Mail (9B206)
From: Jon Moore 
Date: Wed, 10 Oct 2012 07:33:17 -0400
To: Jan Algermissen 
X-Gm-Message-State: ALoCoQnNWIQwVYk9/Ymc0hn2yGPgDNMgV/Z8ze+bHswD/VxzhJ+6eDcUOrh311Zss8DUnQM8Jt8q
Cc: "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] Media Type for HTML 'snippets'?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2012 11:33:23 -0000

On Oct 10, 2012, at 7:03 AM, Jan Algermissen  wr=
ote:
> Can anyone provide a pointer or ideas?
>=20
> Or is it time probably time for application/xhtml-div+xml

Is this sufficient? Not all valid HTML snippets are valid XML. Does this nee=
d to be application/html-div+sgml? (Which begs the question: has someone doc=
umented application/sgml?)

Jon

From jan.algermissen@nordsc.com  Wed Oct 10 04:38:33 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B87B21F8574 for ; Wed, 10 Oct 2012 04:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tEfHBqLSRCN for ; Wed, 10 Oct 2012 04:38:32 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 616A521F850B for ; Wed, 10 Oct 2012 04:38:32 -0700 (PDT)
Received: from [10.90.131.173] ([87.253.171.222]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0M8tDM-1TEEZe17PA-00C9Qp; Wed, 10 Oct 2012 13:38:30 +0200
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Jan Algermissen 
In-Reply-To: <802E941C-0B2A-4430-99DD-A468C255DC9E@jjmoore.net>
Date: Wed, 10 Oct 2012 13:38:29 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <107D2AF0-65A6-42C6-9B42-68CBF8D75EA8@nordsc.com>
References:  <802E941C-0B2A-4430-99DD-A468C255DC9E@jjmoore.net>
To: Jon Moore 
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:42P2z+vng6e8s5KpKXDj4PflfQZsJ7WHtVnaprMABGq Mz7ee6xz31uZZYEpfSMsQ4Gd60yyAJxMseWWZmSMOLLQVqZJGQ oK7i6M5D//rpqwHOM9srfXac+OWt9C7jVatr87cQiRwmSvH15q zujXEmko3U8LDhRrerjUb6phZxoMFGZ67Dw+VZ/6xifn10rnKI NSHoGlnTpUmVm2cA1DOpbOeUwaiGIh5OxBDVINN+gHlmAQu7Bv iGEahlFL6wIWatoF3sGR5vUky+eQIphfApTDNztLmRpGLqt3eA QCaH06yD4VXF5iY9pKF6OTIe9nkDwQrC2F+VvDO8qLsThzV0/V Ns94bnxo8tiTsMDFF4UYpwVTthB2Ikf4NkzpLcFeqtMDnPx2lR dXfKVYCPJ0wUQ==
Cc: "apps-discuss@ietf.org application-layer protocols" 
Subject: Re: [apps-discuss] Media Type for HTML 'snippets'?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2012 11:38:33 -0000

On Oct 10, 2012, at 1:33 PM, Jon Moore wrote:

>=20
> On Oct 10, 2012, at 7:03 AM, Jan Algermissen =
 wrote:
>> Can anyone provide a pointer or ideas?
>>=20
>> Or is it time probably time for application/xhtml-div+xml
>=20
> Is this sufficient? Not all valid HTML snippets are valid XML.

I would be inclined to require just that. SGML days should be considered =
over, IMHO.=20

(At least on the Web. I guess Boeing, DOD et al. are SGML-bound for some =
time to come, eh? :-)

Jan

> Does this need to be application/html-div+sgml? (Which begs the =
question: has someone documented application/sgml?)
>=20
> Jon


From Peter.Rushforth@NRCan-RNCan.gc.ca  Wed Oct 10 06:53:05 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B646C21F8748; Wed, 10 Oct 2012 06:53:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANBCBe5rbiNz; Wed, 10 Oct 2012 06:53:05 -0700 (PDT)
Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id A08C121F8607; Wed, 10 Oct 2012 06:53:04 -0700 (PDT)
Received: from S-BSC-CAS1.nrn.nrcan.gc.ca (132.156.238.11) by S-BSC-EDGE1.nrcan.gc.ca (132.156.238.13) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 10 Oct 2012 09:53:03 -0400
Received: from S-BSC-MBX4.nrn.nrcan.gc.ca ([169.254.4.52]) by S-BSC-CAS1.nrn.nrcan.gc.ca ([fe80::c0ec:b772:2bfe:c34d%18]) with mapi id 14.02.0318.001; Wed, 10 Oct 2012 09:53:03 -0400
From: "Rushforth, Peter" 
To: James M Snell 
Thread-Topic: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01)
Thread-Index: AQHNpluEKJYw4tNLl0Go3M06NpAqmpex5SiAgAAIRYCAAKKkgA==
Date: Wed, 10 Oct 2012 13:53:02 +0000
Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF1AE768BB@S-BSC-MBX4.nrn.nrcan.gc.ca>
References: <507486FE.2050601@berkeley.edu>  
In-Reply-To: 
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: multipart/alternative; boundary="_000_1CD55F04538DEA4F85F3ADF7745464AF1AE768BBSBSCMBX4nrnnrca_"
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" , "link-relations@ietf.org" 
Subject: Re: [apps-discuss] request to register 'describes' link relation	(http://tools.ietf.org/html/draft-wilde-describes-link-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, 10 Oct 2012 13:53:05 -0000

--_000_1CD55F04538DEA4F85F3ADF7745464AF1AE768BBSBSCMBX4nrnnrca_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

6.  "type"

   The "type" Link relation can be used to indicate that the context
   resource is an instance of the resource identified by the target IRI.

     HTTP/1.1 200 OK
     Content-Type: text/plain
     Link: ; type=3D"type"

     Sally


Surely you mean "rel=3D"type" .

Peter Rushforth

________________________________
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of James M Snell
Sent: October 9, 2012 20:10
To: Barry Leiba
Cc: apps-discuss@ietf.org; link-relations@ietf.org
Subject: Re: [apps-discuss] request to register 'describes' link relation (=
http://tools.ietf.org/html/draft-wilde-describes-link-01)

Sticking my hand up and hoping to get some similar treatment for:

  http://www.ietf.org/id/draft-snell-additional-link-relations-05.txt

This one has been there for a while. I followed the same advice you just ga=
ve dret and changed it to informational and cleaned up the normative refere=
nces. Pretty basic draft.

- James

On Tue, Oct 9, 2012 at 4:40 PM, Barry Leiba > wrote:
[I'm removing the non-IETF groups from the distribution list.]

> this is a request to register 'describes' in the IANA link relations
> registry established by RFC 5988. the latest draft of the registration
> document is available at
> http://tools.ietf.org/html/draft-wilde-describes-link-01, and the last
> version announced on a variety of mailing lists has not generated any
> feedback asking for changes.

I'll let the folks on the link-relations list respond to the
suitability of the specification for documenting a useful link
relation.  I have just a couple of process points:

1. In order for the registration to be done, this document will have
to be published somewhere that will satisfy the Designated Expert as
being a stable reference.  That probably means that you'll want this
to be an RFC, so you need to be sorting out how that will happen.
Happily, I'm willing to sponsor this as an AD-sponsored individual
submission, if the link-relations folks agree that we should register
this.

2. I don't think this should be Standards Track, though (and it
doesn't need to be in order to register the link relation and to be
the reference documentation for it).  I would prefer that you make it
Informational, change the "SHOULD" to "should" in the Security
Considerations, and remove Section 2 and the normative reference to
RFC 2119.  (This can wait until after the feedback from the
link-relations mailing list.)

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


--_000_1CD55F04538DEA4F85F3ADF7745464AF1AE768BBSBSCMBX4nrnnrca_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











6.  "type"

   The "type" Link relation can be used to indicate that the cont=
ext
   resource is an instance of the resource identified by the target IRI.

     HTTP/1.1 200 OK
     Content-Type: text/plain
     Link: <http://example.org/Person/givenName>; type=3D"type"

     Sally




 


Surely=
 you mean "rel=3D"type" .


 


Peter Rushforth











From: apps-discuss-bounces@ietf.org=
 [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of James M Snell

Sent: October 9, 2012 20:10

To: Barry Leiba

Cc: apps-discuss@ietf.org; link-relations@ietf.org

Subject: Re: [apps-discuss] request to register 'describes' link rel=
ation (http://tools.ietf.org/html/draft-wilde-describes-link-01)







Sticking my hand up and hoping to get =
some similar treatment for: 












This one has been there for a whi=
le. I followed the same advice you just gave dret and changed it to informa=
tional and cleaned up the normative references. Pretty basic draft.<=
/div>






- James




On Tue, Oct 9, 2012 at 4:40 PM, Barry Leiba 
<barryleiba=
@computer.org> wrote:



[I'm removing the non-IETF groups from the distribution list.]




> this is a request to register 'describes' in the IANA link relations
> registry established by RFC 5988. the latest draft of the registration=


> document is available at

> 
http://tools.ietf.org/html/draft-wilde-describes-link-01, and the last<=
br>
> version announced on a variety of mailing lists has not generated any<=
br>
> feedback asking for changes.





I'll let the folks on the link-relations list respond to the

suitability of the specification for documenting a useful link

relation.  I have just a couple of process points:



1. In order for the registration to be done, this document will have

to be published somewhere that will satisfy the Designated Expert as

being a stable reference.  That probably means that you'll want this
to be an RFC, so you need to be sorting out how that will happen.

Happily, I'm willing to sponsor this as an AD-sponsored individual

submission, if the link-relations folks agree that we should register

this.



2. I don't think this should be Standards Track, though (and it

doesn't need to be in order to register the link relation and to be

the reference documentation for it).  I would prefer that you make it<=
br>
Informational, change the "SHOULD" to "should" in the S=
ecurity

Considerations, and remove Section 2 and the normative reference to

RFC 2119.  (This can wait until after the feedback from the

link-relations mailing list.)



Barry, Applications AD




_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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


















--_000_1CD55F04538DEA4F85F3ADF7745464AF1AE768BBSBSCMBX4nrnnrca_--

From barryleiba@gmail.com  Wed Oct 10 07:37:53 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A2F21F87BA; Wed, 10 Oct 2012 07:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.07
X-Spam-Level: 
X-Spam-Status: No, score=-103.07 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 WjGvTKfIIIX1; Wed, 10 Oct 2012 07:37:53 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 138FF21F87B2; Wed, 10 Oct 2012 07:37:52 -0700 (PDT)
Received: by mail-vb0-f44.google.com with SMTP id fc26so563443vbb.31 for ; Wed, 10 Oct 2012 07:37:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=iDGweSH8upfEeCra7v9Q7Q8/GlcW+Sqxo+XoLIxx7bQ=; b=j/e6XdEnjMg56jTPtyEUvytqWU3Hr+jVJEHmSTUYOXOdKb8ImTqDIExhFGvuSvs5Li Rre+4XmYjqOQChgWbZYQB4flRk7RTatFbvEf/SGVTygyFkqiJDxn8RBAin5wDIJAy1MJ AIFAmEnc24t0tPjZcqAu2P0o1eBqlBKVMUEBPnf3t3SvtqFMnbhhCqGl2NLFSr67ycU7 bUt0wjoSv0AvrX2V9CDtK/lTJ7aNNcBGEHW5Fvn35DMLABcrPP5Ie8LcKhMxGVVntybj bv0ZeFmqvUnr9HB/iBE3rw5ARIv+v5dgJRyW8/y0iRmV/0bme0MjHvMrkcXS5k8pHv7i CysQ==
MIME-Version: 1.0
Received: by 10.52.65.51 with SMTP id u19mr11316814vds.3.1349879872447; Wed, 10 Oct 2012 07:37:52 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.59.5.72 with HTTP; Wed, 10 Oct 2012 07:37:52 -0700 (PDT)
In-Reply-To: 
References: <507486FE.2050601@berkeley.edu>   
Date: Wed, 10 Oct 2012 10:37:52 -0400
X-Google-Sender-Auth: jn1Zou6XtlBrUB7MvB-qVXBpTvM
Message-ID: 
From: Barry Leiba 
To: Herbert van de Sompel 
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss@ietf.org, link-relations@ietf.org
Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-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, 10 Oct 2012 14:37:53 -0000

> Since we are at this, I would also like to point out the request to
> register Memento link relation types, which I submitted August 29
> 2012:
>
> http://www.ietf.org/mail-archive/web/link-relations/current/msg00372.html
>
> It was my understanding, from a brief email exchange with Mark
> Nottingham, that it was possible to reserve a spot in the registry for
> rel types for which there was not yet an RFC but for which a spec was
> in the works. In the case of Memento, that is the I-D
> https://datatracker.ietf.org/doc/draft-vandesompel-memento/. I think
> this ability is rather essential: Memento rel types are already in use
> in many applications and it would be rather counter-productive if
> someone else could register them for some other purpose prior to the
> Memento I-D reaching RFC status.

I think you needn't worry here.  Your document is submitted to the
Independent Stream and is under review by the ISE.  The designated
experts are aware of your registration request, and won't be approving
someone else's registration of the same name.  The actual registration
will be made by IANA when the ISE publishes the document.

I'm currently discussing with the designated experts what the tracking
process is for these.  Perhaps we might make it more visible, so
people can know the status of their requests.

Barry

From nathan@webr3.org  Tue Oct  9 16:22:38 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E7A11E80EE for ; Tue,  9 Oct 2012 16:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0A+v+1498lL for ; Tue,  9 Oct 2012 16:22:37 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4DE11E80EC for ; Tue,  9 Oct 2012 16:22:37 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr13so3443070wgb.13 for ; Tue, 09 Oct 2012 16:22:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=8EaKceGA+hbp6EZO1qExVNfLI8b1yMfUcmeYayug1bw=; b=WOcyhmsVZWCB0q+MIeulQ5O09ELMOX5AehESIW8ycZ8Wbrc0EN8WZv5i+Cz11+U9Gr UkGo+Qg7WCddmxpQJcm45SevuZMIXgGcoDZauL/naflJfUxjXuaBwmyeZD3hjflp9Uvy hTDbcwuQ3S8Cf/ol6xuHorpXEDReGa0Z/d/E/VaGmTsM8qo7ZHmDNq3zl3Aj7RSyvsnb zL9nR/6auAFQUCIYe6tzEWK/aHkVJ+BdUGUi9AdGxyC5ZiBuoL6y7FKq1X3b1Exsp+/J Yfux6pedLwBMJZM2wdJ9ML5tcV4zKqioR9JSHgvA0cPEz8JvvY/FUH0NGIhfx3R2TU+e 9xNA==
Received: by 10.180.96.129 with SMTP id ds1mr8088000wib.17.1349824956540; Tue, 09 Oct 2012 16:22:36 -0700 (PDT)
Received: from [172.19.233.133] (host86-141-250-6.range86-141.btcentralplus.com. [86.141.250.6]) by mx.google.com with ESMTPS id q7sm30808841wiy.11.2012.10.09.16.22.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 16:22:35 -0700 (PDT)
Message-ID: <5074B197.9050101@webr3.org>
Date: Wed, 10 Oct 2012 00:21:59 +0100
From: Nathan 
Organization: webr3
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Erik Wilde 
References: <507486FE.2050601@berkeley.edu>
In-Reply-To: <507486FE.2050601@berkeley.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQl1ha6HXlv+iodpFAQh0PY6dVbTWZzps0wOMBhHx0CsFQWAmQY657lDO/49SluS24aRdhR8
X-Mailman-Approved-At: Wed, 10 Oct 2012 07:57:01 -0700
Cc: hypermedia-web@googlegroups.com, LDP WG , REST-Discuss , "apps-discuss@ietf.org application-layer protocols" , link-relations@ietf.org
Subject: Re: [apps-discuss] [rest-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-01)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: nathan@webr3.org
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Oct 2012 23:22:38 -0000

Erik Wilde wrote:
> dear link-relations experts,
> 
> this is a request to register 'describes' in the IANA link relations 
> registry established by RFC 5988. the latest draft of the registration 
> document is available at 
> http://tools.ietf.org/html/draft-wilde-describes-link-01, and the last 
> version announced on a variety of mailing lists has not generated any 
> feedback asking for changes.
> 
> should the registration request be accepted, my understanding is that 
> the draft registration document will be forwarded to IANA for 
> registration by a designated expert.
> 
> thanks a lot and kind regards,

Looks good and most useful, is it worth mentioning anywhere that this 
inverse relations(describes being the inverse of describedby) is now 
needed due to @rev falling out of fashion? It may help explain why 
describes wasn't defined by powder in the first instance.

Best and KUTGW,

Nathan

From algermissen1971@mac.com  Wed Oct 10 04:03:16 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5604221F8610 for ; Wed, 10 Oct 2012 04:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.199
X-Spam-Level: 
X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=-1.600, 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 q2DnxSi82kkL for ; Wed, 10 Oct 2012 04:03:15 -0700 (PDT)
Received: from nk11p03mm-asmtp004.mac.com (nk11p03mm-asmtpout004.mac.com [17.158.232.39]) by ietfa.amsl.com (Postfix) with ESMTP id C14D321F8615 for ; Wed, 10 Oct 2012 04:03:15 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from [10.90.131.173] ([87.253.171.222]) by nk11p03mm-asmtp004.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0MBO005Q3C11V370@nk11p03mm-asmtp004.mac.com> for apps-discuss@ietf.org; Wed, 10 Oct 2012 11:03:15 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.431,0.0.0000 definitions=2012-10-10_03:2012-10-10, 2012-10-10, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1210100069
From: Jan Algermissen 
Date: Wed, 10 Oct 2012 13:03:03 +0200
Message-id: <8573713A-4AEC-4C63-8379-F2FDE9274BB6@mac.com>
To: "apps-discuss@ietf.org application-layer protocols" 
X-Mailer: Apple Mail (2.1283)
X-Mailman-Approved-At: Wed, 10 Oct 2012 07:57:01 -0700
Subject: [apps-discuss] Media Type for HTML 'snippets'?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2012 11:03:16 -0000

Hi,

I am looking for an appropriate media type to use when serving HTML snippets that have a 
 as their root element.

I feel that serving HTML document fragments has become such a common scenario, I think there must be some solution already. However - I cannot find anything appropriate.

The closest thing is likely Atom's type attribute: http://tools.ietf.org/html/rfc4287#section-3.1.1.3

Can anyone provide a pointer or ideas?

Or is it time probably time for application/xhtml-div+xml

Jan

From hvdsomp@gmail.com  Wed Oct 10 07:19:32 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F6221F8686; Wed, 10 Oct 2012 07:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPh4TYzSrsmz; Wed, 10 Oct 2012 07:19:31 -0700 (PDT)
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id D4A4621F8625; Wed, 10 Oct 2012 07:19:31 -0700 (PDT)
Received: by mail-pa0-f44.google.com with SMTP id fb11so667897pad.31 for ; Wed, 10 Oct 2012 07:19:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TTMCIp9Y8av1y5HU2WmqpFXSqlPHQoZJmHy331KGSUs=; b=xSRazc/mKkZ471RwrHM5UOHGjYdVBCh2At86RR+9Ie7ckUVgY0MqKJLFnNXR0zfrW8 yF9T2bR+472UYUGEMPhxwsta+PFqG/p8+wliOAZxdAKQiEnhSW6TXXwJz/1oilz4zx1n 1tK15UW5Zpc7epBOI5muiWRM61tmHfRN/EOaUElK/orJVICT8fYnXFs9sLxsiLWdviUN Z1kWiaXNpp1uZMbcqh+lzr/HjL6KV0NivS6Owd6iD8QFzUhsMA9FcdqGc3t4EgCQxXmu vhKRzDAr+D3GL6l76pD17AxFccSQ9tlubWd/BdsieiDFL4inHOxPtBUX44O6uCCdY2XJ NjOg==
MIME-Version: 1.0
Received: by 10.68.216.74 with SMTP id oo10mr17556834pbc.92.1349878771374; Wed, 10 Oct 2012 07:19:31 -0700 (PDT)
Received: by 10.68.202.168 with HTTP; Wed, 10 Oct 2012 07:19:31 -0700 (PDT)
In-Reply-To: 
References: <507486FE.2050601@berkeley.edu>  
Date: Wed, 10 Oct 2012 08:19:31 -0600
Message-ID: 
From: Herbert van de Sompel 
To: link-relations@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Mailman-Approved-At: Wed, 10 Oct 2012 07:57:01 -0700
Cc: Barry Leiba , apps-discuss@ietf.org
Subject: Re: [apps-discuss] request to register 'describes' link relation (http://tools.ietf.org/html/draft-wilde-describes-link-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, 10 Oct 2012 14:19:32 -0000

hi all,

Since we are at this, I would also like to point out the request to
register Memento link relation types, which I submitted August 29
2012:

http://www.ietf.org/mail-archive/web/link-relations/current/msg00372.html

It was my understanding, from a brief email exchange with Mark
Nottingham, that it was possible to reserve a spot in the registry for
rel types for which there was not yet an RFC but for which a spec was
in the works. In the case of Memento, that is the I-D
https://datatracker.ietf.org/doc/draft-vandesompel-memento/. I think
this ability is rather essential: Memento rel types are already in use
in many applications and it would be rather counter-productive if
someone else could register them for some other purpose prior to the
Memento I-D reaching RFC status.

Cheers

Herbert

On Tue, Oct 9, 2012 at 6:09 PM, James M Snell  wrote:
> Sticking my hand up and hoping to get some similar treatment for:
>
>   http://www.ietf.org/id/draft-snell-additional-link-relations-05.txt
>
> This one has been there for a while. I followed the same advice you just
> gave dret and changed it to informational and cleaned up the normative
> references. Pretty basic draft.
>
> - James
>
> On Tue, Oct 9, 2012 at 4:40 PM, Barry Leiba  wrote:
>>
>> [I'm removing the non-IETF groups from the distribution list.]
>>
>> > this is a request to register 'describes' in the IANA link relations
>> > registry established by RFC 5988. the latest draft of the registration
>> > document is available at
>> > http://tools.ietf.org/html/draft-wilde-describes-link-01, and the last
>> > version announced on a variety of mailing lists has not generated any
>> > feedback asking for changes.
>>
>> I'll let the folks on the link-relations list respond to the
>> suitability of the specification for documenting a useful link
>> relation.  I have just a couple of process points:
>>
>> 1. In order for the registration to be done, this document will have
>> to be published somewhere that will satisfy the Designated Expert as
>> being a stable reference.  That probably means that you'll want this
>> to be an RFC, so you need to be sorting out how that will happen.
>> Happily, I'm willing to sponsor this as an AD-sponsored individual
>> submission, if the link-relations folks agree that we should register
>> this.
>>
>> 2. I don't think this should be Standards Track, though (and it
>> doesn't need to be in order to register the link relation and to be
>> the reference documentation for it).  I would prefer that you make it
>> Informational, change the "SHOULD" to "should" in the Security
>> Considerations, and remove Section 2 and the normative reference to
>> RFC 2119.  (This can wait until after the feedback from the
>> link-relations mailing list.)
>>
>> Barry, Applications AD
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
> _______________________________________________
> link-relations mailing list
> link-relations@ietf.org
> https://www.ietf.org/mailman/listinfo/link-relations
>



-- 
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/

==

From dret@berkeley.edu  Thu Oct 11 01:16:36 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B104621F86CB for ; Thu, 11 Oct 2012 01:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.45
X-Spam-Level: 
X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149,  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 C2YWMdVSUIYi for ; Thu, 11 Oct 2012 01:16:35 -0700 (PDT)
Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 89B0B21F8698 for ; Thu, 11 Oct 2012 01:16:34 -0700 (PDT)
Received: from rrcs-24-43-239-58.west.biz.rr.com ([24.43.239.58] 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 1TMDwS-0003az-In; Thu, 11 Oct 2012 01:16:33 -0700
Message-ID: <50768058.9040108@berkeley.edu>
Date: Wed, 10 Oct 2012 22:16:24 -1000
From: Erik Wilde 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "apps-discuss@ietf.org application-layer protocols" 
References:  <2CC809E7-4468-43F8-9259-682782BEF117@emc.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: johnarwe@us.ibm.com
Subject: [apps-discuss] how to use non-URI registered identifiers when URIs are needed (for RDF)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2012 08:16:37 -0000

hello.

i had an interesting discussion about how it is allowed to refer to 
registered link relation types, and since this may be of interest for 
other non-URI identifiers as well, i thought i raise this as a general 
question. the starting point was john arwe asking whether it would be ok 
to use URIs as link relation type identifiers, which is allowed by RFC 
4287, but then neither allowed nor specifically disallowed by RFC 5988, 
which updates RFC 4287. john did a great job at digging through the 
history of this, and here is what he found:

On 2012-10-09 10:34 , John Arwe wrote:
> It may be that 5988 was attempting to incorporate some aspects of 4287
> when 5988 took over and expanded the registry.
> [1] lays out the equivalence and requires it.  Odd to expect people to
> read Atom in a "superseding" RFC (quotes b/c I realize it's only the
> registry that 5988 takes over and expands upon).
> POWDER relies on it too, as recently as 2010 [2]
> If I infer from the URI that [3] was an antecedent to 5988, it was
> explicit in the past.  [4] also mentions it, but I infer from [5] that
> it was dropped as a result of AnneVK's comment.  The TAG was also
> batting this around in 2008 [6] and apparently affirming it (via POWDER
> again) in  2012 [7].  RDFa also mentions/uses it.
> [1] http://tools.ietf.org/html/rfc4287#section-4.2.7.2
> [2] http://www.w3.org/2007/powder/powder-errata
> [3] http://tools.ietf.org/id/draft-nottingham-http-link-header-02.xml
> [4] http://tools.ietf.org/id/draft-nottingham-http-link-header-06.xml
> [5] http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0547.html
> [6] http://www.w3.org/2008/10/02-tagmem-minutes
> [7] http://lists.w3.org/Archives/Public/www-tag/2012Mar/0090.html

the starting point is the question how RDF scenarios, requiring URIs as 
identifiers, could reuse concepts such as link relation types. in this 
specific example the concrete question is whether RFC 5988, since it 
does not mention URIs as being equivalent to simple string values, 
effectively disallows what RFC 4287 allowed. my guess is that this is 
the case, but maybe it would help to make this more explicit (maybe as 
an erratum to RFC 5988?).

the bigger question then is: how is RDF supposed to refer to these 
registered values? is that just RDF's problem, being URI-centric when it 
comes to identifiers, or would it make sense to have some kind of best 
practice or method how registered values for the Internet or the Web, 
which very often are not URIs, and the requirement of RDF to have URIs 
as identifiers, can be sorted out.

i am asking both for guidance about the specific question about RFC 
4287, as well as for ideas (and maybe even existing experience or 
examples) how to bridge the gap between non-URI identifiers we might 
want to use in application layer protocols, and RDF's requirement to 
have URIs as identifiers.

thanks and kind regards,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

From jasnell@gmail.com  Thu Oct 11 07:41:45 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AD721F86C6 for ; Thu, 11 Oct 2012 07:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.105
X-Spam-Level: 
X-Spam-Status: No, score=-3.105 tagged_above=-999 required=5 tests=[AWL=-1.173, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAuk0ZewiCcC for ; Thu, 11 Oct 2012 07:41:44 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32F2F21F8680 for ; Thu, 11 Oct 2012 07:41:44 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id u46so1204137wey.31 for ; Thu, 11 Oct 2012 07:41:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kCKBIgv7cbhCQ0qAIJMI/9hfn10s6yDU+rTkh/wtep0=; b=IfXRcV/4uA2+49GygUNfGFgrvxS4pfH48T15Oi7y47xD3hSHbTKDBJ9o57D2hERASk lPr4a1XrroMCZ9OlIpXv+S1YRKYBN3mJdKw1LzpafdxKbETn+LLKRK2xTLgvwM3pS26x N1OCjZjJh4FD2/H/f3IK6s4106yIZJjsi7OvvZVMSsgNpjx931tBcuBHip3boEaq62Dl 9/0BnPd27ugcq6x5Ue63j+FG1DEyPglPmNWsHGROtND5FE6bhYzMI1zv+q3CP0ygKMs0 KfM71w9zcYxdjWE+mF0E8vR1zCzIvwi+A2QZtVfM6RHyXYapHCYzovLzM/IbUuSnKaDq bOIw==
MIME-Version: 1.0
Received: by 10.216.220.29 with SMTP id n29mr659768wep.137.1349966501506; Thu, 11 Oct 2012 07:41:41 -0700 (PDT)
Received: by 10.223.201.68 with HTTP; Thu, 11 Oct 2012 07:41:41 -0700 (PDT)
Received: by 10.223.201.68 with HTTP; Thu, 11 Oct 2012 07:41:41 -0700 (PDT)
In-Reply-To: <50768058.9040108@berkeley.edu>
References:  <2CC809E7-4468-43F8-9259-682782BEF117@emc.com>  <50768058.9040108@berkeley.edu>
Date: Thu, 11 Oct 2012 07:41:41 -0700
Message-ID: 
From: James M Snell 
To: Erik Wilde 
Content-Type: multipart/alternative; boundary=0016e6db2d78c7f04e04cbc99131
Cc: John Arwe , IETF Apps Discuss 
Subject: Re: [apps-discuss] how to use non-URI registered identifiers when URIs are needed (for RDF)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2012 14:41:45 -0000

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

Rfc5988 does allow for uri identifiers as extension relation types but does
drop the equivalence requirement. For atom, those equivalences still hold
as defined by rfc4287 but cannot be assumed to hold for any other context.
You can still use the full uri form, but it would be interpreted as an
extension rel type and left up to the application to determine any
reasonable equivalence. One possible off the cuff approach to bridging the
two worlds is to use the curie concept to view registered link rel types as
compact versions of a full uri...
On Oct 11, 2012 1:17 AM, "Erik Wilde"  wrote:

> hello.
>
> i had an interesting discussion about how it is allowed to refer to
> registered link relation types, and since this may be of interest for other
> non-URI identifiers as well, i thought i raise this as a general question.
> the starting point was john arwe asking whether it would be ok to use URIs
> as link relation type identifiers, which is allowed by RFC 4287, but then
> neither allowed nor specifically disallowed by RFC 5988, which updates RFC
> 4287. john did a great job at digging through the history of this, and here
> is what he found:
>
> On 2012-10-09 10:34 , John Arwe wrote:
>
>> It may be that 5988 was attempting to incorporate some aspects of 4287
>> when 5988 took over and expanded the registry.
>> [1] lays out the equivalence and requires it.  Odd to expect people to
>> read Atom in a "superseding" RFC (quotes b/c I realize it's only the
>> registry that 5988 takes over and expands upon).
>> POWDER relies on it too, as recently as 2010 [2]
>> If I infer from the URI that [3] was an antecedent to 5988, it was
>> explicit in the past.  [4] also mentions it, but I infer from [5] that
>> it was dropped as a result of AnneVK's comment.  The TAG was also
>> batting this around in 2008 [6] and apparently affirming it (via POWDER
>> again) in  2012 [7].  RDFa also mentions/uses it.
>> [1] http://tools.ietf.org/html/**rfc4287#section-4.2.7.2
>> [2] http://www.w3.org/2007/powder/**powder-errata
>> [3] http://tools.ietf.org/id/**draft-nottingham-http-link-**header-02.xml
>> [4] http://tools.ietf.org/id/**draft-nottingham-http-link-**header-06.xml
>> [5] http://lists.w3.org/Archives/**Public/ietf-http-wg/**
>> 2009JulSep/0547.html
>> [6] http://www.w3.org/2008/10/02-**tagmem-minutes
>> [7] http://lists.w3.org/Archives/**Public/www-tag/2012Mar/0090.**html
>>
>
> the starting point is the question how RDF scenarios, requiring URIs as
> identifiers, could reuse concepts such as link relation types. in this
> specific example the concrete question is whether RFC 5988, since it does
> not mention URIs as being equivalent to simple string values, effectively
> disallows what RFC 4287 allowed. my guess is that this is the case, but
> maybe it would help to make this more explicit (maybe as an erratum to RFC
> 5988?).
>
> the bigger question then is: how is RDF supposed to refer to these
> registered values? is that just RDF's problem, being URI-centric when it
> comes to identifiers, or would it make sense to have some kind of best
> practice or method how registered values for the Internet or the Web, which
> very often are not URIs, and the requirement of RDF to have URIs as
> identifiers, can be sorted out.
>
> i am asking both for guidance about the specific question about RFC 4287,
> as well as for ideas (and maybe even existing experience or examples) how
> to bridge the gap between non-URI identifiers we might want to use in
> application layer protocols, and RDF's requirement to have URIs as
> identifiers.
>
> thanks and kind regards,
>
> dret.
>
> --
> erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
>            | UC Berkeley  -  School of Information (ISchool) |
>            | http://dret.net/netdret http://twitter.com/dret |
> ______________________________**_________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/**listinfo/apps-discuss
>

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


Rfc5988 does allow for uri identifiers as extension relation=
 types but does drop the equivalence requirement. For atom, those equivalen=
ces still hold as defined by rfc4287 but cannot be assumed to hold for any =
other context. You can still use the full uri form, but it would be interpr=
eted as an extension rel type and left up to the application to determine a=
ny reasonable equivalence. One possible off the cuff approach to bridging t=
he two worlds is to use the curie concept to view registered link rel types=
 as compact versions of a full uri... 



On Oct 11, 2012 1:17 AM, "Erik Wilde" =
<dret@berkeley.edu> wrote:

hello.



i had an interesting discussion about how it is allowed to refer to registe=
red link relation types, and since this may be of interest for other non-UR=
I identifiers as well, i thought i raise this as a general question. the st=
arting point was john arwe asking whether it would be ok to use URIs as lin=
k relation type identifiers, which is allowed by RFC 4287, but then neither=
 allowed nor specifically disallowed by RFC 5988, which updates RFC 4287. j=
ohn did a great job at digging through the history of this, and here is wha=
t he found:




On 2012-10-09 10:34 , John Arwe wrote:



It may be that 5988 was attempting to incorporate some aspects of 4287

when 5988 took over and expanded the registry.

[1] lays out the equivalence and requires it. =C2=A0Odd to expect people to=


read Atom in a "superseding" RFC (quotes b/c I realize it's o=
nly the

registry that 5988 takes over and expands upon).

POWDER relies on it too, as recently as 2010 [2]

If I infer from the URI that [3] was an antecedent to 5988, it was

explicit in the past. =C2=A0[4] also mentions it, but I infer from [5] that=


it was dropped as a result of AnneVK's comment. =C2=A0The TAG was also<=
br>
batting this around in 2008 [6] and apparently affirming it (via POWDER

again) in =C2=A02012 [7]. =C2=A0RDFa also mentions/uses it.

[1] http://tools.ietf.org/html/rfc4287#section-4.2.7.2
[2] http://www.w3.org/2007/powder/powder-errata

[3] http://tools.ietf.org/id/draft-nottingham-h=
ttp-link-header-02.xml

[4] http://tools.ietf.org/id/draft-nottingham-h=
ttp-link-header-06.xml

[5] http://lists.w3.org/Archives/Public/iet=
f-http-wg/2009JulSep/0547.html

[6] http://www.w3.org/2008/10/02-tagmem-minutes

[7] http://lists.w3.org/Archives/Public/www-tag/201=
2Mar/0090.html





the starting point is the question how RDF scenarios, requiring URIs as ide=
ntifiers, could reuse concepts such as link relation types. in this specifi=
c example the concrete question is whether RFC 5988, since it does not ment=
ion URIs as being equivalent to simple string values, effectively disallows=
 what RFC 4287 allowed. my guess is that this is the case, but maybe it wou=
ld help to make this more explicit (maybe as an erratum to RFC 5988?).




the bigger question then is: how is RDF supposed to refer to these register=
ed values? is that just RDF's problem, being URI-centric when it comes =
to identifiers, or would it make sense to have some kind of best practice o=
r method how registered values for the Internet or the Web, which very ofte=
n are not URIs, and the requirement of RDF to have URIs as identifiers, can=
 be sorted out.




i am asking both for guidance about the specific question about RFC 4287, a=
s well as for ideas (and maybe even existing experience or examples) how to=
 bridge the gap between non-URI identifiers we might want to use in applica=
tion layer protocols, and RDF's requirement to have URIs as identifiers=
.




thanks and kind regards,



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 |

_______________________________________________

apps-discuss mailing list

apps-discuss@iet=
f.org

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




--0016e6db2d78c7f04e04cbc99131--

From rex@cisco.com  Thu Oct 11 10:21:43 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6CB21F86EF for ; Thu, 11 Oct 2012 10:21:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIQglYHjZEsY for ; Thu, 11 Oct 2012 10:21:42 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A161721F86EA for ; Thu, 11 Oct 2012 10:21:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=377; q=dns/txt; s=iport; t=1349976102; x=1351185702; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=EkIr2XS/TXoeQHFuAtKmrwdyycZdnmcsFeQ3+XgA9dE=; b=M2bEqkudnfVRXHSZMprf/DCsnGIXFUfFq/2IwEj7rk7QdlxUrycJB50j n0yeY5dNTf64UEXEvTOl5Ltt7iSMksQrpmnvbTM/hlWPqfmmX8TGd2QSo xxqAjz0X73py7DhnpUe/85gNOZP3HFNaOxZO4RZ+C2YtF9UQqKjtRhCsj I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsgKADz/dlCtJXG8/2dsb2JhbABEg32BTroMgQiCIgEEEgEnPxIBKhRCJgEEDg0BGYdiC5lPoCaRB2ADpDKBa4Jtghc
X-IronPort-AV: E=Sophos;i="4.80,573,1344211200"; d="scan'208";a="130668823"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 11 Oct 2012 17:21:42 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9BHLgeX029711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Oct 2012 17:21:42 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 12:21:41 -0500
From: "Rex Fernando (rex)" 
To: "apps-discuss@ietf.org" 
Thread-Topic: Standardizing protocol buffers
Thread-Index: Ac2n1OCMBjHH+i5NSJyfjOpDzvPMLw==
Date: Thu, 11 Oct 2012 17:21:40 +0000
Message-ID: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.155.70.255]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19262.000
x-tm-as-result: No--29.380800-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sstuart@google.com" 
Subject: [apps-discuss] Standardizing protocol buffers
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2012 17:21:43 -0000

Hi,

We have posted a new draft to standardize the protocol buffers data seriali=
zation format and to request a MIME type for it. The draft is located here:
http://www.ietf.org/id/draft-rfernando-protocol-buffers-00.txt

Given the charter of this group, it seems like a good place to process this=
 draft.=20

Please read and provide comments.

Regards,
- Rex=

From martin.thomson@gmail.com  Thu Oct 11 10:38:03 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8380B21F86F0 for ; Thu, 11 Oct 2012 10:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[AWL=-0.252, 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 w+HA+idDTyUc for ; Thu, 11 Oct 2012 10:38:02 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDEE21F86DE for ; Thu, 11 Oct 2012 10:38:02 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hr7so2119758wib.13 for ; Thu, 11 Oct 2012 10:38:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=goH37hRQhCT0WkK7Exy1YyXJ0ZopR012ZEE2M2MROP8=; b=RUNyCiNVIGUJv6zGQeEVhrFA+YQjz4+K4AKFIYxrpGwWHXqxEWj02W19AZoPlaQ3+7 RsWzBLXrgHBZCi8vASLGzm8FE3lN1oy+fvWrutjJC1536bxz8JA12E3YLdVtLebaltur 4hkpxBiZP2X3w3v0plvdMtZUDzQF2RDsR2YkrlIjP8fTC8Z+d6ZFuh/X3s+W+nKVBPLj uOmlCpht/q2khWqoPrNgXGILCxIYzphR1nu2/veS4Rny3TRFassVOm3Co93px1taox0I jFIzLeeeMKNRZUWvvGWLnronzPBE2P3p49xYjBHQYId/CdHg+spe3gidsFHhY3hrAjgi HTPA==
MIME-Version: 1.0
Received: by 10.216.209.40 with SMTP id r40mr983932weo.144.1349977081338; Thu, 11 Oct 2012 10:38:01 -0700 (PDT)
Received: by 10.180.96.9 with HTTP; Thu, 11 Oct 2012 10:38:01 -0700 (PDT)
In-Reply-To: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com>
References: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com>
Date: Thu, 11 Oct 2012 10:38:01 -0700
Message-ID: 
From: Martin Thomson 
To: "Rex Fernando (rex)" 
Content-Type: text/plain; charset=UTF-8
Cc: "sstuart@google.com" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Standardizing protocol buffers
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2012 17:38:03 -0000

On 11 October 2012 10:21, Rex Fernando (rex)  wrote:
> We have posted a new draft to standardize the protocol buffers data serialization format and to request a MIME type for it. The draft is located here:
> http://www.ietf.org/id/draft-rfernando-protocol-buffers-00.txt

Can you explain why this is superior to ASN.1 and PER?

This is not explained in the draft, or on the website
(https://developers.google.com/protocol-buffers/docs/overview).  Which
is where I ended up when I was trying to understand how this encoding
actually worked.

s/Proposed Standard/Informational/

From stpeter@stpeter.im  Thu Oct 11 10:40:35 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BA221F86F8 for ; Thu, 11 Oct 2012 10:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level: 
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlN-jviCpWx1 for ; Thu, 11 Oct 2012 10:40:32 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C662421F86F7 for ; Thu, 11 Oct 2012 10:40:32 -0700 (PDT)
Received: from [64.101.72.58] (unknown [64.101.72.58]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2A9BC40062; Thu, 11 Oct 2012 11:42:50 -0600 (MDT)
Message-ID: <507704AD.1030109@stpeter.im>
Date: Thu, 11 Oct 2012 11:41:01 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Martin Thomson 
References: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com> 
In-Reply-To: 
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "sstuart@google.com" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Standardizing protocol buffers
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2012 17:40:35 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/11/12 11:38 AM, Martin Thomson wrote:
> On 11 October 2012 10:21, Rex Fernando (rex) 
> wrote:
>> We have posted a new draft to standardize the protocol buffers
>> data serialization format and to request a MIME type for it. The
>> draft is located here: 
>> http://www.ietf.org/id/draft-rfernando-protocol-buffers-00.txt
> 
> Can you explain why this is superior to ASN.1 and PER?

Does it need to be superior in order to be registered?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlB3BK0ACgkQNL8k5A2w/vztrQCgr3TdMgvubJGWqe/1OU3Hvvvo
4bUAniGAjlmPl+sjxodXJdX+PJwo/zbH
=fFQv
-----END PGP SIGNATURE-----

From jasnell@gmail.com  Thu Oct 11 10:49:29 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AA921F86D1 for ; Thu, 11 Oct 2012 10:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.544
X-Spam-Level: 
X-Spam-Status: No, score=-4.544 tagged_above=-999 required=5 tests=[AWL=-0.946, 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 8unGjpoahbsp for ; Thu, 11 Oct 2012 10:49:28 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3810A21F8685 for ; Thu, 11 Oct 2012 10:49:28 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id hq12so7294825wib.13 for ; Thu, 11 Oct 2012 10:49:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lyDZP9bksFjdlL41QuufWDvoB2Kt6xZmTVh4EWIEoKE=; b=VDjK6AfSPfZsS+PWjWVThuf9Im56XQZOrF1/n87LlTuEh1eyv81KNrgbh9c7BpCBkm qav9AI27eWwsBNqmIhw8XO6xzTicJ4UtOajcP4HaATGIYE2XwppEeb8tiywqJXAcqKmb sKw7mUAVMkrXWhlp55bbTXxSGfWd0p4xvay6Er+5VuMIjaBmnNHMca/XcFsuK0xawi+O paPPRfg+/WpQdSXJhBjaFYico2+3b+D8plHivjQp/wUh3psIoL65/cqdBPx8F5s7isGN 3qecg0gJbQ04uESyZxkxbg3sZoLUCd7ci7kiypwHLWryRIBN79YyHWW9iK3E11iW+7iP w1MA==
Received: by 10.180.87.230 with SMTP id bb6mr22401923wib.6.1349977767259; Thu, 11 Oct 2012 10:49:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.201.68 with HTTP; Thu, 11 Oct 2012 10:49:07 -0700 (PDT)
In-Reply-To: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com>
References: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com>
From: James M Snell 
Date: Thu, 11 Oct 2012 10:49:07 -0700
Message-ID: 
To: "Rex Fernando (rex)" 
Content-Type: multipart/alternative; boundary=f46d0444e97b45af6a04cbcc315f
Cc: "sstuart@google.com" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Standardizing protocol buffers
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2012 17:49:29 -0000

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

I'll second Martin's suggestion that this should be Information rather than
Proposed Standard.

Also, I noticed that there is absolutely zero mention of IPR/Licensing
either in the draft or on the referenced Google-hosted website. There is
zero indication as to the license under which Protocol buffers can be used.
As an individual implementor I would have no idea if this can be safely
implemented and used.

- James


On Thu, Oct 11, 2012 at 10:21 AM, Rex Fernando (rex)  wrote:

>
> Hi,
>
> We have posted a new draft to standardize the protocol buffers data
> serialization format and to request a MIME type for it. The draft is
> located here:
> http://www.ietf.org/id/draft-rfernando-protocol-buffers-00.txt
>
> Given the charter of this group, it seems like a good place to process
> this draft.
>
> Please read and provide comments.
>
> Regards,
> - Rex
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

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

I'll second Martin's suggestio=
n that this should be Information rather than Proposed Standard.
Also, I noticed that there is absolutely zero mention=
 of IPR/Licensing either in the draft or on the referenced Google-hosted we=
bsite. There is zero indication as to the license under which Protocol buff=
ers can be used. As an individual implementor I would have no idea if this =
can be safely implemented and used.




- James


On Thu, Oct 11, 201=
2 at 10:21 AM, Rex Fernando (rex) <rex@cisco.com> wrote:





Hi,



We have posted a new draft to standardize the protocol buffers data seriali=
zation format and to request a MIME type for it. The draft is located here:=


http://www.ietf.org/id/draft-rfernando-protocol-buffers-0=
0.txt



Given the charter of this group, it seems like a good place to process this=
 draft.



Please read and provide comments.



Regards,

- Rex

_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--f46d0444e97b45af6a04cbcc315f--

From barryleiba.mailing.lists@gmail.com  Thu Oct 11 11:17:56 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D3521F86DC for ; Thu, 11 Oct 2012 11:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.051
X-Spam-Level: 
X-Spam-Status: No, score=-103.051 tagged_above=-999 required=5 tests=[AWL=-0.074, 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 RIcKsx+vL1cV for ; Thu, 11 Oct 2012 11:17:56 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 04E7021F86C2 for ; Thu, 11 Oct 2012 11:17:55 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so1623776lam.31 for ; Thu, 11 Oct 2012 11:17:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VvUMj0Dd02oirENOf0lIEdr/OY8AJ3F+DIyR/fImOBc=; b=fJWqXMvirFIbXhrUqPmgrH43KTT3bukxiBOp78eGreTlBU9qi7aGH4cPGScVc5s1rv 3Dg4q7iBGNfHMNCQk7u2qbN7jwJlX01Fd0x3d5uucu8qGcXkiwQvAyyALhW6WGonqTAL hTQ0SSr62QPpENsKNCTD02qRFjnewbMx36aYdeXNQoW0o7QS/u2qqTtJG3IsCg8nokGE Oi5fwOSnBOnwkoKiSiQk4krkVfixCqtzvRjSiFfE8YN6u7ozB5XU191zmQAa0JrbLt96 Q/SJszIbDgCrLk1x2egP5o2eiHxlZxoNKScLFGe40OLGLATJ8G0/4Xmy23upYJJaBkL4 mn0A==
MIME-Version: 1.0
Received: by 10.152.131.68 with SMTP id ok4mr1470999lab.47.1349979474984; Thu, 11 Oct 2012 11:17:54 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.112.150.194 with HTTP; Thu, 11 Oct 2012 11:17:54 -0700 (PDT)
In-Reply-To: 
References: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com> 
Date: Thu, 11 Oct 2012 14:17:54 -0400
X-Google-Sender-Auth: p_fWSruSNahhiMyXMzBEoauir7Q
Message-ID: 
From: Barry Leiba 
To: James M Snell 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "sstuart@google.com" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Standardizing protocol buffers
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2012 18:17:56 -0000

> Also, I noticed that there is absolutely zero mention of IPR/Licensing
> either in the draft or on the referenced Google-hosted website. There is
> zero indication as to the license under which Protocol buffers can be used.

Well, I'll note that the draft says this:

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

That means that the authors are asserting that any IPR they are aware
of has been disclosed, according to the requirements of BCP 79.

The authors can (should), of course, confirm this....

Barry

From jasnell@gmail.com  Thu Oct 11 11:22:57 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD10711E80B8 for ; Thu, 11 Oct 2012 11:22:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.947
X-Spam-Level: 
X-Spam-Status: No, score=-3.947 tagged_above=-999 required=5 tests=[AWL=-0.349, 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 2QaKvJZdfhvF for ; Thu, 11 Oct 2012 11:22:57 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE5FC1F0381 for ; Thu, 11 Oct 2012 11:22:56 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr13so1113368wgb.13 for ; Thu, 11 Oct 2012 11:22:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=day5hbWrXPFIS3cAsWp9iGPds8f7o8hsp4ZSEPEXZsg=; b=gjaJuKiAGBYm6SafH5nElDtTFehUS/dV8r3CAa7duD2n97Bv7E2m+UI10FkFu3grI6 HkJUdSRtF7aCusWPMzxq7jo8g6VkU3Y9v5Ef6IfUYttoBTBY2vvzxh5tlt87pyjNc6as zDY/nY3yUnHFLWSV6EG1wU0n1e/VKr2B1+MHlmagb9sS7wME7Oihpe2Hg8nWmP9pfU0n XugKO6K6NTqpejFzkt0UXrSV72zkMBLjmVbb+cOODp5TV5BbsmMGqLsJtaoGfPjiLkT2 YGeqZmmC4glb6970vAFsKWsPVzzEg5gnk/iLoV9YpERLrEl4sVHVDRJdsIzAZW+9BhBU rmKA==
Received: by 10.180.8.134 with SMTP id r6mr22514479wia.18.1349979776147; Thu, 11 Oct 2012 11:22:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.201.68 with HTTP; Thu, 11 Oct 2012 11:22:35 -0700 (PDT)
In-Reply-To: 
References: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com>  
From: James M Snell 
Date: Thu, 11 Oct 2012 11:22:35 -0700
Message-ID: 
To: Barry Leiba 
Content-Type: multipart/alternative; boundary=f46d041827f802e27d04cbcca9d4
Cc: "sstuart@google.com" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Standardizing protocol buffers
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2012 18:22:57 -0000

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

On Thu, Oct 11, 2012 at 11:17 AM, Barry Leiba wrote:

> > Also, I noticed that there is absolutely zero mention of IPR/Licensing
> > either in the draft or on the referenced Google-hosted website. There is
> > zero indication as to the license under which Protocol buffers can be
> used.
>
> Well, I'll note that the draft says this:
>
>    This Internet-Draft is submitted to IETF in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
> That means that the authors are asserting that any IPR they are aware
> of has been disclosed, according to the requirements of BCP 79.
>
> The authors can (should), of course, confirm this....
>
>
+1... I don't anticipate that there is any issue here, I just get nervous
when seeing something from a specific vendor that has no specific license
mentioned on the original spec. :-)

- James


> Barry
>

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



On Thu, Oct 11, 2012 at 11:17 AM, Barry Leiba <barryleiba@comput=
er.org> wrote:



> Also, I noticed that =
there is absolutely zero mention of IPR/Licensing

> either in the draft or on the referenced Google-hosted website. There =
is

> zero indication as to the license under which Protocol buffers can be =
used.




Well, I'll note that the draft says this:



=C2=A0 =C2=A0This Internet-Draft is submitted to IETF in full conformance w=
ith the

=C2=A0 =C2=A0provisions of BCP 78 and BCP 79.



That means that the authors are asserting that any IPR they are aware

of has been disclosed, according to the requirements of BCP 79.



The authors can (should), of course, confirm this....



+1... I don't anticipate that there is any issue=
 here, I just get nervous when seeing something from a specific vendor that=
 has no specific license mentioned on the original spec. :-)




- James
=C2=A0

Barry





--f46d041827f802e27d04cbcca9d4--

From martin.thomson@gmail.com  Thu Oct 11 11:27:30 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B511F0429 for ; Thu, 11 Oct 2012 11:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.513
X-Spam-Level: 
X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086,  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 RUP+VMyKaujz for ; Thu, 11 Oct 2012 11:27:30 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E17A1F0423 for ; Thu, 11 Oct 2012 11:27:29 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id u46so1349665wey.31 for ; Thu, 11 Oct 2012 11:27:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uoCjzD97WDO4hHD6B8fzOq4Ycda7LBYoe+GfLE0JdvI=; b=ePXnwM85Iw9fRgew5A0zMQ3CfvuRT2uLTVAL/NcefZqEmG0p4l5t6FmR0x0rK0qlGT IH6kjSPZc4khr12QipYgK01p7qLfRX1XGzKzUk37x0cKd2zHhHUqWvmkTYNKnzvX24TG fWTDFvF2P39rXAEWonA1/AuAlM5CxwUVumj0QF3O4W8gzMCp+jUwMntMFQFjAmjZuhaj PaWWh85jDokyLDdIR+aiZtfJ/fa51kuV2yUP9SKVlhaZz87nezAXca+diAc4Ew8REZQg pch+uRDlsJwHWyyo4QgQNm0Nae855NF49EldVMjA+1sV7eDoaMB+PB4e1LvrlfUzaM3c eHaQ==
MIME-Version: 1.0
Received: by 10.216.209.40 with SMTP id r40mr1053356weo.144.1349980049273; Thu, 11 Oct 2012 11:27:29 -0700 (PDT)
Received: by 10.180.96.9 with HTTP; Thu, 11 Oct 2012 11:27:29 -0700 (PDT)
In-Reply-To: <507704AD.1030109@stpeter.im>
References: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com>  <507704AD.1030109@stpeter.im>
Date: Thu, 11 Oct 2012 11:27:29 -0700
Message-ID: 
From: Martin Thomson 
To: Peter Saint-Andre 
Content-Type: text/plain; charset=UTF-8
Cc: "sstuart@google.com" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Standardizing protocol buffers
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2012 18:27:30 -0000

On 11 October 2012 10:41, Peter Saint-Andre  wrote:
> On 10/11/12 11:38 AM, Martin Thomson wrote:
>> Can you explain why this is superior to ASN.1 and PER?
>
> Does it need to be superior in order to be registered?

Oh no, I was just interested, that's all.  The website explains why
this is better than XML for a certain class of application.

If I were naive, I'd assume that something that requires this much
effort to design and implement would have to have some sort of reason
as justification.

From jasnell@gmail.com  Thu Oct 11 11:40:26 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B1121F866C for ; Thu, 11 Oct 2012 11:40:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.938
X-Spam-Level: 
X-Spam-Status: No, score=-3.938 tagged_above=-999 required=5 tests=[AWL=-0.340, 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 c8GWHsO9izI0 for ; Thu, 11 Oct 2012 11:40:25 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66CB721F8697 for ; Thu, 11 Oct 2012 11:40:25 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr13so1122669wgb.13 for ; Thu, 11 Oct 2012 11:40:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NUAd+QAoEXXBeQA7A/dHoSnhsBS6TrOHz2YPeYvLB2Q=; b=mQiGJC6xORteVaNt15AMoMwjE4a16yHuF9ACbHDBzuPYMDf2pdthJJZUgGwwTeN0nL N4e6ZdeBRAHgB+9bE98Fq6hBbbO5xlQLvNvBFIDBbhMIkYcHrgRtBME7Y3+6o9STp5Fx x72gH9fuNaT1ZO2fk3nDGx/ka114XJmf2CcvFap3LIbFh045+Y0s/YLCNcF+ONUQwHal yRW02+3xBoX50W74XqNj1weDzad5avJRBjxHmUHWHZrd6LaUalpfcxH9ac8u1j0SBt6D ED50wgr51eXMCos/SfcC+xeEpaipm9ItKKggWw2rjW0z/tAwJdQOo6rIkkQ1AVrWnbB+ npeA==
Received: by 10.216.204.139 with SMTP id h11mr1048418weo.128.1349980824496; Thu, 11 Oct 2012 11:40:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.201.68 with HTTP; Thu, 11 Oct 2012 11:40:04 -0700 (PDT)
In-Reply-To: 
References: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com>  
From: James M Snell 
Date: Thu, 11 Oct 2012 11:40:04 -0700
Message-ID: 
To: Stephen Stuart 
Content-Type: multipart/alternative; boundary=0016e6d589e17f6c5904cbcce72c
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Standardizing protocol buffers
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2012 18:40:26 -0000

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

Yep! That definitely helps. Basically, it just needs to be clear that any
one is free to implement the protobufs without any doubts... a statement
buried in the FAQ works, but you could make the statement a bit more
directly on the landing page.. just a suggestion. :-)

- James

On Thu, Oct 11, 2012 at 11:33 AM, Stephen Stuart  wrote:

> The FAQ notes that we haven't filed any patents on protocol buffers:
>
>     https://developers.google.com/protocol-buffers/docs/faq
>
> We published an implementation here,
> http://code.google.com/p/protobuf/, under the "Nw BSD license"
> (http://opensource.org/licenses/BSD-3-Clause).
>
> Does that help?
>
> Stephen
>
> On Thu, Oct 11, 2012 at 10:49 AM, James M Snell  wrote:
> > I'll second Martin's suggestion that this should be Information rather
> than
> > Proposed Standard.
> >
> > Also, I noticed that there is absolutely zero mention of IPR/Licensing
> > either in the draft or on the referenced Google-hosted website. There is
> > zero indication as to the license under which Protocol buffers can be
> used.
> > As an individual implementor I would have no idea if this can be safely
> > implemented and used.
> >
> > - James
> >
> >
> > On Thu, Oct 11, 2012 at 10:21 AM, Rex Fernando (rex) 
> wrote:
> >>
> >>
> >> Hi,
> >>
> >> We have posted a new draft to standardize the protocol buffers data
> >> serialization format and to request a MIME type for it. The draft is
> located
> >> here:
> >> http://www.ietf.org/id/draft-rfernando-protocol-buffers-00.txt
> >>
> >> Given the charter of this group, it seems like a good place to process
> >> this draft.
> >>
> >> Please read and provide comments.
> >>
> >> Regards,
> >> - Rex
> >> _______________________________________________
> >> apps-discuss mailing list
> >> apps-discuss@ietf.org
> >> https://www.ietf.org/mailman/listinfo/apps-discuss
> >
> >
>

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

Yep! That definitely helps. Basically,=
 it just needs to be clear that any one is free to implement the protobufs =
without any doubts... a statement buried in the FAQ works, but you could ma=
ke the statement a bit more directly on the landing page.. just a suggestio=
n. :-)



- James

On Th=
u, Oct 11, 2012 at 11:33 AM, Stephen Stuart <sstuart@google.com>=
 wrote:



The FAQ notes that we haven't filed any =
patents on protocol buffers:



=C2=A0 =C2=A0 https://developers.google.com/protocol-buffers/doc=
s/faq



We published an implementation here,

http://cod=
e.google.com/p/protobuf/, under the "Nw BSD license"

(=
http://opensource.org/licenses/BSD-3-Clause).



Does that help?



Stephen




On Thu, Oct 11, 2012 at 10:49 AM, James M Snell <jasnell@gmail.com> wrote:

> I'll second Martin's suggestion that this should be Informatio=
n rather than

> Proposed Standard.

>

> Also, I noticed that there is absolutely zero mention of IPR/Licensing=


> either in the draft or on the referenced Google-hosted website. There =
is

> zero indication as to the license under which Protocol buffers can be =
used.

> As an individual implementor I would have no idea if this can be safel=
y

> implemented and used.

>

> - James

>

>

> On Thu, Oct 11, 2012 at 10:21 AM, Rex Fernando (rex) <rex@cisco.com> wrote:

>>

>>

>> Hi,

>>

>> We have posted a new draft to standardize the protocol buffers dat=
a

>> serialization format and to request a MIME type for it. The draft =
is located

>> here:

>> http://www.ietf.org/id/draft-rfernando-protocol-=
buffers-00.txt

>>

>> Given the charter of this group, it seems like a good place to pro=
cess

>> this draft.

>>

>> Please read and provide comments.

>>

>> Regards,

>> - Rex

>> _______________________________________________

>> apps-discuss mailing list

>> apps-discuss@ietf.org=


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

>

>





--0016e6d589e17f6c5904cbcce72c--

From cabo@tzi.org  Thu Oct 11 13:26:51 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF2D21F85B8 for ; Thu, 11 Oct 2012 13:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.219
X-Spam-Level: 
X-Spam-Status: No, score=-106.219 tagged_above=-999 required=5 tests=[AWL=0.030, 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 KUxOdWgTjHSx for ; Thu, 11 Oct 2012 13:26:51 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AE57321F858E for ; Thu, 11 Oct 2012 13:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q9BKQYXu002260; Thu, 11 Oct 2012 22:26:34 +0200 (CEST)
Received: from [192.168.217.117] (p54894040.dip.t-dialin.net [84.137.64.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 70D80337; Thu, 11 Oct 2012 22:26:34 +0200 (CEST)
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: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com>
Date: Thu, 11 Oct 2012 22:26:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0484F1B0-2C8B-48B3-8523-CC01C0A23D48@tzi.org>
References: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com>
To: "Rex Fernando (rex)" 
X-Mailer: Apple Mail (2.1499)
Cc: "sstuart@google.com" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Standardizing protocol buffers
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2012 20:26:51 -0000

On Oct 11, 2012, at 19:21, "Rex Fernando (rex)"  wrote:

> http://www.ietf.org/id/draft-rfernando-protocol-buffers-00.txt

Hey, I can do that, too.

http://www.ietf.org/id/draft-bormann-apparea-bpack-00.txt

How many of these do we need?

(I'm actually quite serious with binarypack, as there is a lot of stuff =
out there that uses msgpack, and it probably would be a good idea to do =
a version with IETF change control.  Area of application for me is =
mostly constrained node/network REST, but of course it is a quite =
universal hammer.  Not the impact wrench that protocol buffers is :-)

Gr=FC=DFe, Carsten


From James.H.Manger@team.telstra.com  Thu Oct 11 18:49:31 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C053621F8540 for ; Thu, 11 Oct 2012 18:49:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.862
X-Spam-Level: 
X-Spam-Status: No, score=-0.862 tagged_above=-999 required=5 tests=[AWL=0.039,  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 BSpB5aMwIbym for ; Thu, 11 Oct 2012 18:49:29 -0700 (PDT)
Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6CE21F853F for ; Thu, 11 Oct 2012 18:49:27 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,575,1344175200"; d="scan'208";a="95342778"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 12 Oct 2012 12:49:25 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6862"; a="93714971"
Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcbni.tcif.telstra.com.au with ESMTP; 12 Oct 2012 12:49:25 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Fri, 12 Oct 2012 12:49:25 +1100
From: "Manger, James H" 
To: Carsten Bormann , "apps-discuss@ietf.org" 
Date: Fri, 12 Oct 2012 12:49:24 +1100
Thread-Topic: binarypack: streaming, very large values, indefinite lengths
Thread-Index: Ac2n7sLLFkHb+EXJStmIlo4F6eugbgAIhhFg
Message-ID: <255B9BB34FB7D647A506DC292726F6E114FDB91D11@WSMSG3153V.srv.dir.telstra.com>
References: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com> <0484F1B0-2C8B-48B3-8523-CC01C0A23D48@tzi.org>
In-Reply-To: <0484F1B0-2C8B-48B3-8523-CC01C0A23D48@tzi.org>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [apps-discuss] binarypack: streaming, very large values, indefinite lengths
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Oct 2012 01:49:31 -0000

Q2Fyc3RlbiwNCg0KQmluYXJ5cGFjayBbZHJhZnQtYm9ybWFubi1hcHBhcmVhLWJwYWNrXSBsb29r
cyBmYWlybHkgc2ltcGxlIGFuZCBlZmZpY2llbnQuDQoNCk9uZSBsaW1pdGF0aW9uIGlzIHRoYXQg
eW91IGhhdmUgdG8ga25vdyB0aGUgbGVuZ3RoIG9mIGEgc3RyaW5nLCB0aGUgbnVtYmVyIG9mIGl0
ZW1zIGluIGFuIGFycmF5LCBhbmQgdGhlIG51bWJlciBvZiBrZXkvdmFsdWUgcGFpcnMgaW4gYSB0
YWJsZSAoYWthIG9iamVjdCBvciBtYXApIGJlZm9yZSB5b3Ugc3RhcnQgZW5jb2RpbmcgdGhlbS4N
Cg0KSlNPTiBkb2VzIG5vdCBoYXZlIHRoaXMgbGltaXRhdGlvbi4NCg0KVGhpcyBpcyBsaWtlbHkg
dG8gbWFrZSBiaW5hcnlwYWNrIHVuc3VpdGFibGUgZm9yIHJlYWxseSBsYXJnZSB2YWx1ZXMsIGZv
ciB2YWx1ZXMgY3JlYXRlZCBpbiBhIHN0cmVhbWluZyBtb2RlLCBvciBmb3IgdG9vbHMgdGhhdCB3
YW50IHRvIGZpbHRlciBhIHN0cmVhbSBhcyBpdCBwYXNzZXMuDQoNCk9uZSBzb2x1dGlvbiB3b3Vs
ZCBiZSB0byBhbGxvdyB2YWx1ZXMgb2YgdGhlc2UgdHlwZXMgdG8gYmUgc2VudCBpbiBwaWVjZXMu
IEEgbmV3ICJwYXJ0aWFsIiByZXByZXNlbnRhdGlvbiBmb3IgdGhlc2UgdHlwZXMgd291bGQgYmUg
ZGVmaW5lZCAodXNpbmcgdGhlIHNhbWUgc3ludGF4IGFzIHRoZSByZXByZXNlbnRhdGlvbiB0aGF0
IHVzZXMgYSA0LWJ5dGUgbGVuZ3RoIGZpZWxkKS4gQW55IG51bWJlciBvZiB0aG9zZSBjYW4gYmUg
Y29uY2F0ZW5hdGVkIHRvIGNvbnZleSBhIGZ1bGwgdmFsdWUgKHRlcm1pbmF0ZWQgd2l0aCBhIG5v
bi1wYXJ0aWFsIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBzYW1lIHR5cGUsIG9yIGRlZmluaW5nIGEg
c3BlY2lhbCB0ZXJtaW5hdG9yKS4NCg0KU28gIkhlbGxvLCBXb3JsZCEiIGNvdWxkIGJlIGVuY29k
ZWQgYXM6DQogIEQ5IDAwMDAwMDBEIDQ4IDY1IDZDIDZDIDZGIDJDIDIwIDU3IDZGIDcyIDZDIDY0
IDIxDQpPciAocGlja2luZyBENyB0byBpbmRpY2F0ZSBhICJwYXJ0aWFsIiBzdHJpbmcpDQogIEQ3
IDAwMDAwMDA1IDQ4IDY1IDZDIDZDIDZGDQogIEQ3IDAwMDAwMDA4IDJDIDIwIDU3ICA2RiA3MiA2
QyA2NCAyMQ0KICBCMA0KDQpQLlMuIEkgYmVsaWV2ZSBwcm90b2NvbCBidWZmZXJzIGhhdmUgdGhl
IHNhbWUgc2NhbGFiaWxpdHkgbGltaXRhdGlvbi4NCg0KUC5TLiBBU04uMSBCRVIgc3VwcG9ydHMg
aW5kZWZpbml0ZS1sZW5ndGggZW5jb2RpbmdzIHRvIG92ZXJjb21lIHRoaXMgbGltaXRhdGlvbi4N
Cg0KUC5TLiBCZWluZyBhYmxlIHRvIGVuY29kZSBwYXJ0cyBvZiBhIGxhcmdlciBmaWVsZCBpcyBh
bHNvIHVzZWZ1bCBmb3Igb2NjYXNpb25hbCBtYW51YWwgZGVidWdnaW5nIGFzIHlvdSBjYW4gbW9k
aWZ5IGEgdmFsdWUgKGFkZC9yZW1vdmUgYnl0ZXMsIGNoYXJhY3RlcnMsIGFycmF5IGl0ZW1zLCBv
ciBrZXkvdmFsdWUgcGFpcnMpIHdpdGhvdXQgaGF2aW5nIHRvIHJlY2FsY3VsYXRlIG5lc3RlZCBs
ZW5ndGggZmllbGRzIGFsbCB0aGUgd2F5IHVwIHRvIHRoZSByb290IG9mIHRoZSBtZXNzYWdlLg0K
DQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg==

From susielu25@gmail.com  Fri Oct 12 02:16:49 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAABC21F84A6 for ; Fri, 12 Oct 2012 02:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level: 
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 kEeSDswZQluP for ; Fri, 12 Oct 2012 02:16:49 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D23321F8491 for ; Fri, 12 Oct 2012 02:16:49 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 9so5186234iec.31 for ; Fri, 12 Oct 2012 02:16:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YGA2FZ19n60AvUEMHCTXRuDCGCdri9RgWRD7pbBJNeY=; b=kPdFvLjNfrr4b0KIKMtRBFvaijTOks5zPVSSPydgxz/qayN4VtoJtvxNZpvVDUScQz qvyBcB1ailhO0A/KjtFV2qCygxIBbRP/WetLoaspDbEttG6tPaTL9KObk9Tsz1T74aQV fq72aDV8sCx/XKHm29TACaKZr3g0djyEHdiE7KqBycy1ktGRHbCCM21TODJAUxw9wNPM pAvVbuwwgJTfjYaxFJJh3YRLO2sC9SWKYtVJbLlxyFg6SXJtufaM+WbtDvdwizLcULjm EmRlMeJ/FJnYWOe2jHjs1gWqWPMHw+cxqn2PrVYcCneJylF/HMW7vyirCEEcLyClmwA9 2eeQ==
MIME-Version: 1.0
Received: by 10.50.153.162 with SMTP id vh2mr1508027igb.67.1350033408891; Fri, 12 Oct 2012 02:16:48 -0700 (PDT)
Received: by 10.64.38.6 with HTTP; Fri, 12 Oct 2012 02:16:48 -0700 (PDT)
Date: Fri, 12 Oct 2012 17:16:48 +0800
Message-ID: 
From: Susie Lu 
To: apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=e89a8f3badc3c59a2704cbd925cc
Subject: [apps-discuss] hello all
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Oct 2012 09:18:46 -0000

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

hello all

--e89a8f3badc3c59a2704cbd925cc
Content-Type: text/html; charset=ISO-8859-1

hello all

--e89a8f3badc3c59a2704cbd925cc--

From sstuart@google.com  Thu Oct 11 11:34:00 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4270311E8097 for ; Thu, 11 Oct 2012 11:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DClDIkqR9Qm7 for ; Thu, 11 Oct 2012 11:33:59 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 504BB21F8643 for ; Thu, 11 Oct 2012 11:33:59 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id s14so1864691qcg.31 for ; Thu, 11 Oct 2012 11:33:58 -0700 (PDT)
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-system-of-record; bh=J++OjML/WRDWw7JS+ON5qZhXi/xNqng9Lm1XlZCDnso=; b=QVBhNAY7TCX0B9NwtChHI5KR5WFWFyDyDsnlr8O+/pMr5rf4sBlJjXmkk3m6yeHH2q jwTLZzjvawRD4hfw7as+Chxeoo1TyMe6HwEXvfpLKGvVSr2ZIk2OWn8EBfvYhZM+1lCB 1dGYa6uonof+KpJOJ147iTHIaekkkoTeWJ4Njs/O3RCl/pLBdKjNaUjRUhHc+p2knnrD 0eOQ5cKFK2A2hD32jhO7y9+gaOPYp1aYNHdwmXqfef6koxPG8pX871ST35kMOy5S6tEj vXJcOl0fHHGRJkahpRAhjkMMooaF9XwO04OtxTEeIC1iMLRH2FL0WbZZfQhtnl1MXaMg nmGg==
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-system-of-record:x-gm-message-state; bh=J++OjML/WRDWw7JS+ON5qZhXi/xNqng9Lm1XlZCDnso=; b=TEjrSSrDZUYpUqR//X/7rb+DO8jkmDsGq1ysgGvkZmhWfbzL0NRZiZMO3gJVFzHDbp dZucM5nDJ8mib6TBwWNw+WhlShi1KCcY1W28Amy2JWY7JQmtiqNc7iHkjSucF4uCjeX0 +qjJ07G6wiRtxR3SxrIJDfQoQfs+t5eryENBlqQO6AOqz/0Hj+6kTyf3Lb4gcOFD2B1t jbj/pjUGhlkm6VIxooefwtNaQReJYtOfg1bsTz2wtDL0trmSo4VA9+DW9F60LDJK/QrL w7FxhDMCNcfe9uUrZKQ3x5FAKsZcLRVPw1DgoMkFqH4xJCcPSLipZ/z+9k2SblHuDfkv /Lug==
MIME-Version: 1.0
Received: by 10.49.87.36 with SMTP id u4mr3833016qez.57.1349980438539; Thu, 11 Oct 2012 11:33:58 -0700 (PDT)
Received: by 10.229.78.8 with HTTP; Thu, 11 Oct 2012 11:33:58 -0700 (PDT)
In-Reply-To: 
References: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com> 
Date: Thu, 11 Oct 2012 11:33:58 -0700
Message-ID: 
From: Stephen Stuart 
To: James M Snell 
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmecTaFYpjWHfNQuilRX/vJId/YMo7JvgVH3aVe+qMgfoxlUQXiVl3B5eGEtit5JfrFAee9/SXH/vfKtng8SoRdtZy5js4XjlI6U3D/GSeXMGrJ585tXbZPZ9FZzxZCCjQgVcR5LQ0ZfcguiegdAwxEBp6W6JEgOKkGPZEQp2suheaHpbGdj0XAzUTP5CmqfSauNHeh
X-Mailman-Approved-At: Fri, 12 Oct 2012 08:08:06 -0700
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Standardizing protocol buffers
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2012 18:34:00 -0000

The FAQ notes that we haven't filed any patents on protocol buffers:

    https://developers.google.com/protocol-buffers/docs/faq

We published an implementation here,
http://code.google.com/p/protobuf/, under the "Nw BSD license"
(http://opensource.org/licenses/BSD-3-Clause).

Does that help?

Stephen

On Thu, Oct 11, 2012 at 10:49 AM, James M Snell  wrote:
> I'll second Martin's suggestion that this should be Information rather than
> Proposed Standard.
>
> Also, I noticed that there is absolutely zero mention of IPR/Licensing
> either in the draft or on the referenced Google-hosted website. There is
> zero indication as to the license under which Protocol buffers can be used.
> As an individual implementor I would have no idea if this can be safely
> implemented and used.
>
> - James
>
>
> On Thu, Oct 11, 2012 at 10:21 AM, Rex Fernando (rex)  wrote:
>>
>>
>> Hi,
>>
>> We have posted a new draft to standardize the protocol buffers data
>> serialization format and to request a MIME type for it. The draft is located
>> here:
>> http://www.ietf.org/id/draft-rfernando-protocol-buffers-00.txt
>>
>> Given the charter of this group, it seems like a good place to process
>> this draft.
>>
>> Please read and provide comments.
>>
>> Regards,
>> - Rex
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

From hallam@gmail.com  Fri Oct 12 12:13:08 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D0621F87E9 for ; Fri, 12 Oct 2012 12:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.883
X-Spam-Level: 
X-Spam-Status: No, score=-3.883 tagged_above=-999 required=5 tests=[AWL=-0.285, 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 nkYmoGkK8uxj for ; Fri, 12 Oct 2012 12:13:06 -0700 (PDT)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB1A121F87E8 for ; Fri, 12 Oct 2012 12:13:06 -0700 (PDT)
Received: by mail-oa0-f44.google.com with SMTP id n5so3903815oag.31 for ; Fri, 12 Oct 2012 12:13:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EG9zJxFvySMMyUg1a9ib4I+RujhyYSFH+vcsqpiKZ2s=; b=0k3FRwckqoGP1DjyTBvl5zbaZYj36XbObMm0ugegbbOq/PGC07/64I7BJDtXTqPN37 dUmOMA++aGXHsp/ywk15c/byzVMEfKuB2kZS9JwDhDAxXwU6yKKHH7Q2Z11gmK2qMfrN gm579gfLQF1QvnePIQ5N99bNw2juiLov172ErMEqUYt+k+0JhtkfIxkqWejski7yicq+ Z9GNvpef26edVF+zfshLXE/1C0VmtTglRmUVL5/GxcPTYUnyRDW1KxBTWLLmCdWFQVDa 4EP3xZkVbYpdkwjss7fbr++YvyGxKUwQOjZnN7uI24HEV5Yiiw+r90oN/GeRjo2OXWop F1ow==
MIME-Version: 1.0
Received: by 10.60.170.229 with SMTP id ap5mr4160914oec.101.1350069186298; Fri, 12 Oct 2012 12:13:06 -0700 (PDT)
Received: by 10.76.27.103 with HTTP; Fri, 12 Oct 2012 12:13:06 -0700 (PDT)
In-Reply-To: <0484F1B0-2C8B-48B3-8523-CC01C0A23D48@tzi.org>
References: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com> <0484F1B0-2C8B-48B3-8523-CC01C0A23D48@tzi.org>
Date: Fri, 12 Oct 2012 15:13:06 -0400
Message-ID: 
From: Phillip Hallam-Baker 
To: Carsten Bormann 
Content-Type: multipart/alternative; boundary=bcaec54b4ac045831104cbe17af5
Cc: "sstuart@google.com" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Standardizing protocol buffers
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Oct 2012 19:13:08 -0000

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

+1 and how does all this relate to JSON?

Also we should note that we have another very similar scheme inside TLS.

There are good reasons to prefer binary encoding over JSON and vice versa.
But it would be rather nice if we had a way to abstract the encoding choice
from the protocol.

For example, JSON does not support binary types which makes it rather
inefficient as a wrapper for video streams or the like. Another problem
with JSON is that it uses an escaped encoding for strings and those raise
security issues and performance issues. [And no, telling people not to make
mistakes is not a security solution]

There are also advantages to JSON of course but which one is best is going
to depend on the target application. So I think that is a choice that
should be made in deployment rather than by the protocol designer.


I think we should try to minimize the number of packing options. Most
decisions do not matter at all, some matter a lot but there is a very clear
choice (don't repeat DER) and some depend on circumstances.


As far as the details go, there are only a few useful design choices in a
packing scheme. I am certain this proposal has some of them wrong.


1) Integer encoding

The encoding of negative integers needs to be much better thought out. As
should the fact that an integer might well be larger than 64 bits.

The Varint scheme uses the top bit of each integer to encode the run
length. This means that if we AND each octet of an integer with 0x80 we
will get one of the following

0x00
0x80 0x00
0x80 0x80 0x00
...

The problem with this scheme is that it requires each integer to be packed
into 7 bit form which is kind of inefficient. Lots of rotates and so on. A
more time efficient scheme is to follow the ASN1 approach and pack the run
length into the first byte in some fashion. So if the top byte is:

0xxx xxxx length =3D 1
10xx xxxx length =3D 2
110x xxxx length =3D 3
1110 xxxx length =3D 4
1111 nnnn length =3D 4 + nnnn

One of the big advantages of this approach is that it avoids the need for
the 7 bit shifting which is not only inefficient, it requires special case
fixup for negative integers. A twos compliment number can be fitted in very
easily.


2) Tagged or untagged data

JSON and XML data is tagged which means that it is very flexible. Adding an
extra data field does not cause chaos. It was not immediately apparent to
me which approach this proposal takes.

ASN.1 data gives a choice on a per field basis. This does not seem to be a
helpful approach (to say the least).


3) Typed or untyped

This is not the same as tagged or untagged. A data structure {"a" : 1} has
different semantics from {
"b" : 1}. The tags may imply a type but they are not themselves a type
declaration.

JSON data is implicitly typed by the syntax. ASN.1 is not.

Any conversion from a binary format to JSON needs to have the type
information. That may come from either a schema or be explicit in the data
stream as in BER encoding.


4) Can it be implemented as a linear traversal?

The really insane part of ASN.1 is actually two lines buried in the X.500
documentation defining DER. According to the DER encoding rules, an object
is represented using the definite length encoding. So each object is
prefixed by the total length of the data fields.

This is a problem because the included data fields may also be objects and
the length field is encoded using variable length encoding. So emitting DER
encoding requires a totally pointless double recursion down the tree and
back again, keeping track of multiple values. It is just stupid, stupid,
stupid.

Oh and there is absolutely no security reason for DER encoding, none, zip,
nada.

Again, the draft seems pretty vague on this point as well.






On Thu, Oct 11, 2012 at 4:26 PM, Carsten Bormann  wrote:

> On Oct 11, 2012, at 19:21, "Rex Fernando (rex)"  wrote:
>
> > http://www.ietf.org/id/draft-rfernando-protocol-buffers-00.txt
>
> Hey, I can do that, too.
>
> http://www.ietf.org/id/draft-bormann-apparea-bpack-00.txt
>
> How many of these do we need?
>
> (I'm actually quite serious with binarypack, as there is a lot of stuff
> out there that uses msgpack, and it probably would be a good idea to do a
> version with IETF change control.  Area of application for me is mostly
> constrained node/network REST, but of course it is a quite universal
> hammer.  Not the impact wrench that protocol buffers is :-)
>
> Gr=FC=DFe, Carsten
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>



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

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

+1 and how does all this relate to JSON?

Also we should =
note that we have another very similar scheme inside TLS.

There are good reasons to prefer binary encoding over JSON and vice=
 versa. But it would be rather nice if we had a way to abstract the encodin=
g choice from the protocol.



For example, JSON does not support binary types which m=
akes it rather inefficient as a wrapper for video streams or the like. Anot=
her problem with JSON is that it uses an escaped encoding for strings and t=
hose raise security issues and performance issues. [And no, telling people =
not to make mistakes is not a security solution]



There are also advantages to JSON of course but which o=
ne is best is going to depend on the target application. So I think that is=
 a choice that should be made in deployment rather than by the protocol des=
igner.




I think we should try to minimize t=
he number of packing options. Most decisions do not matter at all, some mat=
ter a lot but there is a very clear choice (don't repeat DER) and some =
depend on circumstances.




As far as the details go, there ar=
e only a few useful design choices in a packing scheme. I am certain this p=
roposal has some of them wrong.



1) Integer encoding

The encoding of negative integ=
ers needs to be much better thought out. As should the fact that an integer=
 might well be larger than 64 bits.

The Varint sch=
eme uses the top bit of each integer to encode the run length. This means t=
hat if we AND each octet of an integer with 0x80 we will get one of the fol=
lowing



0x00
0x80 0x00
0x80 0x80 0x00
=

...

The problem with this scheme is that it r=
equires each integer to be packed into 7 bit form which is kind of ineffici=
ent. Lots of rotates and so on. A more time efficient scheme is to follow t=
he ASN1 approach and pack the run length into the first byte in some fashio=
n. So if the top byte is:



0xxx xxxx length =3D 1
10xx xxxx length =3D 2=

110x xxxx length =3D 3
1110 xxxx length =3D 4
1111 nnnn length =3D 4 + nnnn

One of the big adv=
antages of this approach is that it avoids the need for the 7 bit shifting =
which is not only inefficient, it requires special case fixup for negative =
integers. A twos compliment number can be fitted in very easily.




2) Tagged or untagged data
JSON and XML data is tagged which means that it is very flexibl=
e. Adding an extra data field does not cause chaos. It was not immediately =
apparent to me which approach this proposal takes.=A0



ASN.1 data gives a choice on a per field basis. This do=
es not seem to be a helpful approach (to say the least).


3) Typed or untyped

This is =
not the same as tagged or untagged. A data structure {"a" : 1} ha=
s different semantics from {

"b" : 1}. The tags may imply a type but they are not themselves a=
 type declaration.

JSON data is implicitly typed b=
y the syntax. ASN.1 is not.=A0

Any conversion from=
 a binary format to JSON needs to have the type information. That may come =
from either a schema or be explicit in the data stream as in BER encoding.<=
/div>



4) Can it be implemented as a linear tra=
versal?

The really insane part of ASN.1 is actuall=
y two lines buried in the X.500 documentation defining DER. According to th=
e DER encoding rules, an object is represented using the definite length en=
coding. So each object is prefixed by the total length of the data fields.<=
/div>


This is a problem because the included data fields may =
also be objects and the length field is encoded using variable length encod=
ing. So emitting DER encoding requires a totally pointless double recursion=
 down the tree and back again, keeping track of multiple values. It is just=
 stupid, stupid, stupid.



Oh and there is absolutely no security reason for DER e=
ncoding, none, zip, nada.=A0

Again, the draft seem=
s pretty vague on this point as well.








On Th=
u, Oct 11, 2012 at 4:26 PM, Carsten Bormann <cabo@tzi.org> wrot=
e:


On Oct 11, 2012, at 19:21, "Rex Fernand=
o (rex)" <rex@cisco.com> wr=
ote:




> http://www.ietf.org/id/draft-rfernando-protocol-buff=
ers-00.txt



Hey, I can do that, too.



http://www.ietf.org/id/draft-bormann-apparea-bpack-00.txt<=
br>


How many of these do we need?



(I'm actually quite serious with binarypack, as there is a lot of stuff=
 out there that uses msgpack, and it probably would be a good idea to do a =
version with IETF change control. =A0Area of application for me is mostly c=
onstrained node/network REST, but of course it is a quite universal hammer.=
 =A0Not the impact wrench that protocol buffers is :-)




Gr=FC=DFe, Carsten




_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





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




--bcaec54b4ac045831104cbe17af5--

From martin.thomson@gmail.com  Fri Oct 12 13:07:48 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E57B21F87DC for ; Fri, 12 Oct 2012 13:07:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.912
X-Spam-Level: 
X-Spam-Status: No, score=-3.912 tagged_above=-999 required=5 tests=[AWL=-0.313, 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 7ySQXPv3Za7E for ; Fri, 12 Oct 2012 13:07:47 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAE721F8732 for ; Fri, 12 Oct 2012 13:07:47 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id hq12so159834wib.13 for ; Fri, 12 Oct 2012 13:07:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cn5RxuUYfa701JYYe6z1gT2/9OVCiqob3lQXxQv4yJQ=; b=Kmy0oJCn9EV/WMRLp+068do3gooToleeidxYrja84ypUc9NezqX29OXj6Es/DzX+SP PyOCf4eGUced7vTE7xFkwEscACLzMFX1Xlda9jqN8UmYXVOf7724FL/DNT1warqsKwck RyBFF0K6xKbWr20Fc7rAie5hhlmIhRCh9cqb/x1SXMdLmKoNEIB2hDeLAMAJ1ZdtxksK nE2F0khXr3pqFvjKcdwgI24JOn2iz3MN/6VuEkbl/m0JXOe69u85zISFHn3yI7/sJJco +8Z3Kr/qxStlYjEI5PUY3iqrZoLHSszQgJXyZ9an6sz/JowLgNF11U8GXHilkCqS4O9G mzQQ==
MIME-Version: 1.0
Received: by 10.216.198.16 with SMTP id u16mr3423156wen.115.1350072466607; Fri, 12 Oct 2012 13:07:46 -0700 (PDT)
Received: by 10.180.96.9 with HTTP; Fri, 12 Oct 2012 13:07:46 -0700 (PDT)
In-Reply-To: 
References: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com> <0484F1B0-2C8B-48B3-8523-CC01C0A23D48@tzi.org> 
Date: Fri, 12 Oct 2012 13:07:46 -0700
Message-ID: 
From: Martin Thomson 
To: Phillip Hallam-Baker 
Content-Type: text/plain; charset=UTF-8
Cc: "sstuart@google.com" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Standardizing protocol buffers
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Oct 2012 20:07:48 -0000

On 12 October 2012 12:13, Phillip Hallam-Baker  wrote:
> +1 and how does all this relate to JSON?

Maybe the authors of the draft under discussion can comment on what
their intent is.  Are they intending to bring work for the IETF to
work in (as would be hinted at by the Proposed Standard status), or is
this an attempt to provide a stable informational reference for
something that is widely deployed.

I assumed it was the latter.  In that sense, a more relevant question
to debate is whether this information, if published as an RFC, would
improve the Internet in any meaningful way.

If this were the former, then I'd be more inclined to engage in some
sort of debate about the merits of ASN.1 and the various encoding
rules as they relate to the protocol buffers design.  Carsten's draft
is clearly in this camp.

--Martin

From cabo@tzi.org  Fri Oct 12 13:11:19 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DA521F87A2 for ; Fri, 12 Oct 2012 13:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.22
X-Spam-Level: 
X-Spam-Status: No, score=-106.22 tagged_above=-999 required=5 tests=[AWL=0.029, 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 VrRKtgR5e80N for ; Fri, 12 Oct 2012 13:11:19 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C81FA21F8722 for ; Fri, 12 Oct 2012 13:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q9CKB9TM025865; Fri, 12 Oct 2012 22:11:09 +0200 (CEST)
Received: from [192.168.217.117] (p54891BEA.dip.t-dialin.net [84.137.27.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BC6E082A; Fri, 12 Oct 2012 22:11:08 +0200 (CEST)
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: <255B9BB34FB7D647A506DC292726F6E114FDB91D11@WSMSG3153V.srv.dir.telstra.com>
Date: Fri, 12 Oct 2012 22:11:07 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B1815F1-B6CD-4B73-83D5-6835797225F9@tzi.org>
References: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com> <0484F1B0-2C8B-48B3-8523-CC01C0A23D48@tzi.org> <255B9BB34FB7D647A506DC292726F6E114FDB91D11@WSMSG3153V.srv.dir.telstra.com>
To: "Manger, James H" 
X-Mailer: Apple Mail (2.1499)
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] binarypack: streaming, very large values, indefinite lengths
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Oct 2012 20:11:19 -0000

On Oct 12, 2012, at 03:49, "Manger, James H" =
 wrote:

> indefinite-length

I have too many scars from BER to be too happy about indefinite-length =
encoding.
I do see the advantages that you mention, for certain applications.
They don't really apply to my constrained node use case.
But they are needed to enable completely different ones ("streaming").

My main concern really is that many representation formats have too many =
ways to say the same thing, which leads to a number of issues (interop =
testing becomes harder, this is a covert channel, etc.).  msgpack of =
course already has three ways to express the same data for things with =
0..15 elements, so maybe this already is a lost cause.

One interesting alternative that I was looking at before deciding to go =
for msgpack was bencode, which has exactly one encoding for a given data =
object (i.e., it is a DER, actually more like CER).
For its structured types (and integers!), this entirely relies on =
push-pop style delimiters (but then it doesn't have chunking for =
strings, which would destroy the DERness).
In the end, I was quite happy with the definiteness of msgpack -- works =
well with constrained nodes.
It seems a lot of msgpack users are happy with this, too (their main =
application so far appears to be RPC marshaling, which also works well =
with definite length).
Adding a "chunking" code for "concatenate the next few data elements =
until you get a zero length one" is a very small extension in the number =
of words of the spec, but a big one in the number of lines of code.
(One could also add a code for "concatenate this to the previous data =
element", but this would lose the self-delimiting property of msgpack.)

Another way of handling this requirement is making the chunking code =
optional.
I.e., essentially splitting the format into two variants (as there is no =
other way to handle this optionality).
If it is possible to carve up the use cases cleanly into two groups, =
this might even make sense.

In summary: good point, but no obvious resolution springs to mind.

(The other big user requirement neither JSON nor msgpack address is =
internal referencing, i.e. deviations from the pure tree model.
I believe JSON was right in not addressing this, and I don't really want =
to go there.)

Gr=FC=DFe, Carsten


From cabo@tzi.org  Fri Oct 12 13:29:14 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B14821F8713 for ; Fri, 12 Oct 2012 13:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.221
X-Spam-Level: 
X-Spam-Status: No, score=-106.221 tagged_above=-999 required=5 tests=[AWL=0.028, 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 b9ER5KCXy1pM for ; Fri, 12 Oct 2012 13:29:13 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7D49E21F8712 for ; Fri, 12 Oct 2012 13:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q9CKT4A1001653; Fri, 12 Oct 2012 22:29:04 +0200 (CEST)
Received: from [192.168.217.117] (p54891BEA.dip.t-dialin.net [84.137.27.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C76D4833; Fri, 12 Oct 2012 22:29:03 +0200 (CEST)
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: Fri, 12 Oct 2012 22:29:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <53330214-C3A8-45E6-8275-0FEAD8EEAE48@tzi.org>
References: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com> <0484F1B0-2C8B-48B3-8523-CC01C0A23D48@tzi.org>  
To: Martin Thomson 
X-Mailer: Apple Mail (2.1499)
Cc: "sstuart@google.com" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Standardizing protocol buffers
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Oct 2012 20:29:14 -0000

On Oct 12, 2012, at 22:07, Martin Thomson  =
wrote:

> Carsten's draft
> is clearly in this camp.

I'm not quite sure in which camp I am.

msgpack is widely deployed.
binarypack is an interesting small tweak on this (that I didn't even =
invent, but that happens to solve my specific problem with msgpack).

I think is it highly appropriate for the IETF to take widely deployed, =
relevant protocols, and add some value to them:

1) creating an unambiguous reference

2) picking up and solving specific requirements that the IETF is =
interested in, while maintaining the value of the base spec.

(For a [much larger and much more valuable] example, compare this to SSL =
and TLS, if you want.)

Of course, I'm happy going the JSON way here (JSON is an informational =
RFC that is widely used as a normative reference) :-)

As regards the protocol buffers spec:=20
This is really a Google thing, so I'd expect this to become another =
informational document titled "Google's ...".
Maybe my view is too narrow.
(In case this isn't clear: I believe protocol buffers is definitely =
worth documenting.  Certainly more than, say, RFC 3072.)

Gr=FC=DFe, Carsten


From mnot@mnot.net  Fri Oct 12 13:59:59 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BB121F87B6; Fri, 12 Oct 2012 13:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.109
X-Spam-Level: 
X-Spam-Status: No, score=-104.109 tagged_above=-999 required=5 tests=[AWL=-1.510, 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 gcb33LrjfblD; Fri, 12 Oct 2012 13:59:58 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9917E21F8779; Fri, 12 Oct 2012 13:59:58 -0700 (PDT)
Received: from [192.168.1.72] (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1D7A922E255; Fri, 12 Oct 2012 16:59:51 -0400 (EDT)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sat, 13 Oct 2012 07:59:47 +1100
Message-Id: <908A5670-8A38-4702-B801-B31BB756EA97@mnot.net>
To: "iesg@ietf.org IESG" 
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Cc: "apps-discuss@ietf.org Discuss" 
Subject: [apps-discuss] Forwarded draft: registration policy
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Oct 2012 20:59:59 -0000

Draft -09 changed the registration policy for forwarded parameters:

> The "Forwarded" header field contains parameters for which IANA is to
>    create and maintain a new registry entitled "HTTP Forwarded
>    parameters".  Initial registrations are given below; for future
>    assignments, the registration procedure to be used is IETF review =
[RFC5226].



I *think* this change was based upon Stephen's comment:

> Section 9 says only that the expert should ensure that the
> specification "address the security and privacy implications of the
> requested parameter." So if I defined a parameter that passed on the
> precise location of the end-user or the most recent healthcare
> related URL they've accessed then would that be ok? I think
> additional instructions are needed as to the acceptable purposes to
> which such parameters can be put or else perhaps IETF review would
> in fact be better. Given the field of applicability I would not be
> surprised if very privacy-invasive parameters were defined in
> future.


=


For the record, I question whether IETF Review is necessary for this =
registry, because it sets it up as a gatekeeper, rather than a registry =
of deployed parameters.=20

I strongly suspect vendors will give in to the temptation to deploy =
unregistered parameters here, meaning we'll be publishing yet another =
registry that's both disconnected from reality and failing to serve the =
purported purpose (protecting security and privacy).

Regards,

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




From Michael.Jones@microsoft.com  Fri Oct 12 16:39:26 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA93A21F86A5 for ; Fri, 12 Oct 2012 16:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.550, 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 jWfR+pGN0GXX for ; Fri, 12 Oct 2012 16:39:26 -0700 (PDT)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2EACD21F855A for ; Fri, 12 Oct 2012 16:39:26 -0700 (PDT)
Received: from BY2FFO11FD015.protection.gbl (10.1.15.200) by BY2FFO11HUB034.protection.gbl (10.1.14.118) with Microsoft SMTP Server (TLS) id 15.0.516.0; Fri, 12 Oct 2012 23:40:27 +0000
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD015.mail.protection.outlook.com (10.1.14.131) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Fri, 12 Oct 2012 23:40:27 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.33]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Fri, 12 Oct 2012 23:39:14 +0000
From: Mike Jones 
To: "apps-discuss@ietf.org" 
Thread-Topic: OAuth 2.0 RFCs Completed
Thread-Index: Ac2o0g5UnfkkfGxrQSWten+ni7nRywAAKXVg
Date: Fri, 12 Oct 2012 23:39:14 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436684824A@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B1680429673943668481BD@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668481BD@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.34]
Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B16804296739436684824ATK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(54164002)(377454001)(69234002)(44976002)(74662001)(46102001)(74502001)(15202345001)(47446002)(8716001)(31966008)(16696001)(16826001)(20776001)(42186003)(33656001)(15395725001)(16406001)(47736001)(4396001)(3846001)(4196001)(5343655001)(5343665001)(5343635001)(512954001)(50986001)(49866001)(1076001)(51856001)(47976001)(316001)(3556001)(3746001)(6606295001); DIR:OUT; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0632519F33
Subject: [apps-discuss] FW: OAuth 2.0 RFCs Completed
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Oct 2012 23:39:27 -0000

--_004_4E1F6AAD24975D4BA5B16804296739436684824ATK5EX14MBXC284r_
Content-Type: multipart/alternative;
	boundary="_000_4E1F6AAD24975D4BA5B16804296739436684824ATK5EX14MBXC284r_"

--_000_4E1F6AAD24975D4BA5B16804296739436684824ATK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

FYI

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M=
ike Jones
Sent: Friday, October 12, 2012 4:34 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth 2.0 RFCs Completed

The OAuth 2.0 Core and Bearer specifications are now RFC 6749 and RFC 6750.  Thanks to all of you who brought us to this important mileston=
e!

I wrote about this at http://self-issued.info/?p=3D870 and Dick wrote about=
 it at http://dickhardt.org/2012/10/oauth-2-0/.

Now, on to approving the next set of related standards!

                                                            Thanks all!
                                                            -- Mike


--_000_4E1F6AAD24975D4BA5B16804296739436684824ATK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











FYI


 







From: oauth-bounces@ietf.org [mailto:=
oauth-bounces@ietf.org]
On Behalf Of Mike Jones

Sent: Friday, October 12, 2012 4:34 PM

To: oauth@ietf.org

Subject: [OAUTH-WG] OAuth 2.0 RFCs Completed






 


Th=
e OAuth 2.0 Core and Bearer specifications are now
RFC 6749 and 
RFC 6750.  Thanks to all of you who brought us to this important m=
ilestone!


 


I =
wrote about this at
http://self-issued.info/?p=3D8=
70 and Dick wrote about it at
http://dickhardt.org/20=
12/10/oauth-2-0/.


 


No=
w, on to approving the next set of related standards!


 


&n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;         Thanks all!=



&n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;         -- Mike


 






--_000_4E1F6AAD24975D4BA5B16804296739436684824ATK5EX14MBXC284r_--

--_004_4E1F6AAD24975D4BA5B16804296739436684824ATK5EX14MBXC284r_
Content-Type: text/plain; name="ATT00001.txt"
Content-Description: ATT00001.txt
Content-Disposition: attachment; filename="ATT00001.txt"; size=130;
	creation-date="Fri, 12 Oct 2012 23:34:31 GMT";
	modification-date="Fri, 12 Oct 2012 23:34:31 GMT"
Content-ID: <91CCC65625E6E6479430CFFF82F7FB28@microsoft.com>
Content-Transfer-Encoding: base64

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h
aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgNCg==

--_004_4E1F6AAD24975D4BA5B16804296739436684824ATK5EX14MBXC284r_--

From rex@cisco.com  Fri Oct 12 16:50:21 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8930321F86A2 for ; Fri, 12 Oct 2012 16:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEkV42vdGbE8 for ; Fri, 12 Oct 2012 16:50:20 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C449121F8646 for ; Fri, 12 Oct 2012 16:50:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2116; q=dns/txt; s=iport; t=1350085821; x=1351295421; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=X2e6iYwDnmwINnuDvq0L9qLJ4uWMLm7T71udivN8jtg=; b=QOiFby2fuMWmxESfQf4LSebCqY5SRbuoXyrTtjDLKiBS4dR7WfWoAthc j8rghQLhble0U0KYMwL6Z7diXbGoROFOpOc7YOoU178Bu+2l/FFdhye++ PtyhPhzMc/v/06/MFYYV9fcyDV/f/gUPPVPzmfsQzbbRtjloVWS39G9oQ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EACWseFCtJV2d/2dsb2JhbABFv26BCIIgAQEBBAEBAQ8BWwsMBAIBCA4DBAEBCx0HIQYLFAkIAQEEAQ0FCBqHUAMPC5sxlhUNiVAEimxmhV1gA4gji3WMeIMigWuCbYIX
X-IronPort-AV: E=Sophos;i="4.80,578,1344211200"; d="scan'208";a="131180427"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 12 Oct 2012 23:50:20 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9CNoKWu003470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Oct 2012 23:50:20 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 18:50:20 -0500
From: "Rex Fernando (rex)" 
To: Carsten Bormann , Martin Thomson 
Thread-Topic: [apps-discuss] Standardizing protocol buffers
Thread-Index: Ac2n1OCMBjHH+i5NSJyfjOpDzvPMLwAQ7xuAAC+56QAAAejCAAAAviQAAAO9+4A=
Date: Fri, 12 Oct 2012 23:50:19 +0000
Message-ID: <868851912C182241B686E0BD4D73BC1713E64C@xmb-aln-x08.cisco.com>
References: <868851912C182241B686E0BD4D73BC1713B73C@xmb-aln-x08.cisco.com> <0484F1B0-2C8B-48B3-8523-CC01C0A23D48@tzi.org>   <53330214-C3A8-45E6-8275-0FEAD8EEAE48@tzi.org>
In-Reply-To: <53330214-C3A8-45E6-8275-0FEAD8EEAE48@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.23.18.250]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19266.000
x-tm-as-result: No--46.576600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sstuart@google.com" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Standardizing protocol buffers
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Oct 2012 23:50:21 -0000

Martin, Carsten,

| -----Original Message-----
| From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
| bounces@ietf.org] On Behalf Of Carsten Bormann
| Sent: Friday, October 12, 2012 1:29 PM
| To: Martin Thomson
| Cc: sstuart@google.com; apps-discuss@ietf.org
| Subject: Re: [apps-discuss] Standardizing protocol buffers
|=20
| On Oct 12, 2012, at 22:07, Martin Thomson 
| wrote:
|=20
| > Carsten's draft
| > is clearly in this camp.
|=20
| I'm not quite sure in which camp I am.
|=20
| msgpack is widely deployed.
| binarypack is an interesting small tweak on this (that I didn't even inve=
nt, but
| that happens to solve my specific problem with msgpack).
|=20
| I think is it highly appropriate for the IETF to take widely deployed, re=
levant
| protocols, and add some value to them:
|=20
| 1) creating an unambiguous reference
|=20
| 2) picking up and solving specific requirements that the IETF is interest=
ed in,
| while maintaining the value of the base spec.
|=20
| (For a [much larger and much more valuable] example, compare this to SSL
| and TLS, if you want.)
|=20
| Of course, I'm happy going the JSON way here (JSON is an informational RF=
C
| that is widely used as a normative reference) :-)
|=20
| As regards the protocol buffers spec:
| This is really a Google thing, so I'd expect this to become another
| informational document titled "Google's ...".
| Maybe my view is too narrow.
| (In case this isn't clear: I believe protocol buffers is definitely worth
| documenting.  Certainly more than, say, RFC 3072.)

Agree with the points being made.

Our intention is to create an unambiguous and stable reference for implemen=
ters of protocol buffers.  The intention is not to supplant existing encodi=
ng formats.

We'll fix the 'Intended Status' to be  'Informational' if that helps clear =
things a bit.

- Rex
=20
| Gr=FC=DFe, Carsten
|=20
| _______________________________________________
| apps-discuss mailing list
| apps-discuss@ietf.org
| https://www.ietf.org/mailman/listinfo/apps-discuss

From barryleiba.mailing.lists@gmail.com  Sat Oct 13 07:37:54 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A9F21F8540; Sat, 13 Oct 2012 07:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.042
X-Spam-Level: 
X-Spam-Status: No, score=-103.042 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 Gz1cecknYENL; Sat, 13 Oct 2012 07:37:53 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 887D221F8513; Sat, 13 Oct 2012 07:37:52 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so2868094lam.31 for ; Sat, 13 Oct 2012 07:37:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8+rwPrbxLOqwHuXF93c8xVLV/Gx66l90KedqsAPLcUQ=; b=Bojd4r8+FfZO1NXUs3SLTNCBbJ6Id/pJJ3AQpv1OWqU0Mi84cgsQt5g7jH8QSH38z3 LkVQpwdXBvT5nSZEHOYOM/Rod2gnZ5SQDZMYcKcZfpDVDxVIkoEZeFhiErdg6Uwh5fAf xYLKhJ3MGxJ+gk/1MDivx00vQ/S5tncHyQ2sDNMb/eM/3cqqYK1MbJUHLvTGc90m9R+J 3712Uj78jjLeMaqJH6GzrpAxiGotz7cREFaWwJQpsKzvzptba3lG9YUt3w4vBSiN7Y87 16gExEFMNp6g+EugQe7/JbWflvql4eGbpV6ShhdLDHcXYXUPvC8sEoY1vA5OWj2u7yha oscA==
MIME-Version: 1.0
Received: by 10.152.105.68 with SMTP id gk4mr6099964lab.48.1350139071457; Sat, 13 Oct 2012 07:37:51 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.112.150.194 with HTTP; Sat, 13 Oct 2012 07:37:51 -0700 (PDT)
In-Reply-To: <908A5670-8A38-4702-B801-B31BB756EA97@mnot.net>
References: <908A5670-8A38-4702-B801-B31BB756EA97@mnot.net>
Date: Sat, 13 Oct 2012 10:37:51 -0400
X-Google-Sender-Auth: Ctc4qfqQESU6alJf0KC7zND3Bmk
Message-ID: 
From: Barry Leiba 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=f46d040714afc0691804cbf1bfaf
Cc: "iesg@ietf.org IESG" , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] Forwarded draft: registration policy
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Oct 2012 14:37:54 -0000

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

>
> Draft -09 changed the registration policy for forwarded parameters:
>
> > The "Forwarded" header field contains parameters for which IANA is to
> >    create and maintain a new registry entitled "HTTP Forwarded
> >    parameters".  Initial registrations are given below; for future
> >    assignments, the registration procedure to be used is IETF review
> [RFC5226].
>
> 
>
> I *think* this change was based upon Stephen's comment:


I believe you're correct.  Andreas can confirm that.  (And I'm explicitly
adding Stephen to the CC list here, to be sure he sees and comments.)


> > Section 9 says only that the expert should ensure that the
> > specification "address the security and privacy implications of the
> > requested parameter." So if I defined a parameter that passed on the
> > precise location of the end-user or the most recent healthcare
> > related URL they've accessed then would that be ok? I think
> > additional instructions are needed as to the acceptable purposes to
> > which such parameters can be put or else perhaps IETF review would
> > in fact be better. Given the field of applicability I would not be
> > surprised if very privacy-invasive parameters were defined in
> > future.
>
> <
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/
> >
>
> For the record, I question whether IETF Review is necessary for this
> registry, because it sets it up as a gatekeeper, rather than a registry of
> deployed parameters.


For the record, I agree with you.  But there's more history.  Untiil -05,
the policy was RFC Required.  I convinced the authors to change it to
Specification Required in -06, and later to add instructions to the
designated expert for leniency, erring toward registration rather than
gatekeeping.  And that is the version that got final working group approval
and went through IETF last call.

I'm actually quite disappointed that it's changed back (and is actually
even stricter than the original, and I agree with you in this:


> I strongly suspect vendors will give in to the temptation to deploy
> unregistered parameters here, meaning we'll be publishing yet another
> registry that's both disconnected from reality and failing to serve the
> purported purpose (protecting security and privacy).
>

I think we overdid this in an effort to make Stephen happier with the
document (and we did make him happier, if not "happy").  I suggest that
both the Apps community and the IESG have more discussion on this and sort
it out for AUTH48.  I suggest that we go back to the IANA Considerations
from the -08 draft.

Barry

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


Draft -09 changed the registration policy fo=
r forwarded parameters:



> The "Forwarded" header field contains parameters for which I=
ANA is to

> =A0 =A0create and maintain a new registry entitled "HTTP Forwarde=
d

> =A0 =A0parameters". =A0Initial registrations are given below; for=
 future

> =A0 =A0assignments, the registration procedure to be used is IETF revi=
ew [RFC5226].



<http://www.ietf.org/rfcdiff?url2=3Ddraft-iet=
f-appsawg-http-forwarded-09>



I *think* this change was based upon Stephen's comment:

I believe you're correct. =A0Andreas can confirm that.=
 =A0(And I'm explicitly adding Stephen to the CC list here, to be sure =
he sees and comments.)


=A0

> Section 9 says only that the expert should ensure that the

> specification "address the security and privacy implications of t=
he

> requested parameter." So if I defined a parameter that passed on =
the

> precise location of the end-user or the most recent healthcare

> related URL they've accessed then would that be ok? I think

> additional instructions are needed as to the acceptable purposes to
> which such parameters can be put or else perhaps IETF review would

> in fact be better. Given the field of applicability I would not be

> surprised if very privacy-invasive parameters were defined in

> future.




<https://datatracker.ietf.org/doc/draft-ie=
tf-appsawg-http-forwarded/ballot/>



For the record, I question whether IETF Review is necessary for this regist=
ry, because it sets it up as a gatekeeper, rather than a registry of deploy=
ed parameters.

For the record, I agree with=
 you. =A0But there's more history. =A0Untiil -05, the policy was RFC Re=
quired. =A0I convinced the authors to change it to Specification Required i=
n -06, and later to add instructions to the designated expert for leniency,=
 erring toward registration rather than gatekeeping. =A0And that is the ver=
sion that got final working group approval and went through IETF last call.=




I'm actually quite disappointed that it's chang=
ed back (and is actually even stricter than the original, and I agree with =
you in this:
=A0


I strongly suspect vendors will give in to the temptation to deploy unregis=
tered parameters here, meaning we'll be publishing yet another registry=
 that's both disconnected from reality and failing to serve the purport=
ed purpose (protecting security and privacy).




I think we overdid this in an effort to ma=
ke Stephen happier with the document (and we did make him happier, if not &=
quot;happy"). =A0I suggest that both the Apps community and the IESG h=
ave more discussion on this and sort it out for AUTH48. =A0I suggest that w=
e go back to the IANA Considerations from the -08 draft.



Barry


--f46d040714afc0691804cbf1bfaf--

From barryleiba@gmail.com  Sat Oct 13 07:42:54 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B2521F8549 for ; Sat, 13 Oct 2012 07:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.042
X-Spam-Level: 
X-Spam-Status: No, score=-103.042 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 Ob2eSDKlcLEF for ; Sat, 13 Oct 2012 07:42:54 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABB321F8543 for ; Sat, 13 Oct 2012 07:42:54 -0700 (PDT)
Received: by mail-vb0-f44.google.com with SMTP id fc26so4411530vbb.31 for ; Sat, 13 Oct 2012 07:42:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=v7aFTxStLbnDCx6Z2s4pasO7NYxgdXl3Mb1yDOKsO3I=; b=rWxMN/GSNlhaZVDZFZX3zoCGqQPZlVRGorB4yUQasrVE7aGgh5DKYimjpvJMMFpKcS dRR6b0kS91KLVOnG3VFGbg9TAuuaLlZ9+n9VV5vrc3F133BYjqa8x4S9pNEMoccunnm8 d8h1D6FqNNaYptKEQSLqGIE/X0dq9CgACxSUvieER0UHmz/k8G6hi9ZRPFrI5C1dsx9B 3ASQRL9nMH1TGi6UtQMnjdRYS34ALfA8jwmXNf861GGX1qRd5vNk6P6AVV2R/+VUwdZa RTFNDVfoVF0i614006i2HNVS3tmZ9iFPdW0UT1F5dTbGELo/0sOrhiy9NR00lr8L+QMm Qlqg==
MIME-Version: 1.0
Received: by 10.52.24.142 with SMTP id u14mr3321509vdf.110.1350139373682; Sat, 13 Oct 2012 07:42:53 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.59.5.72 with HTTP; Sat, 13 Oct 2012 07:42:53 -0700 (PDT)
Date: Sat, 13 Oct 2012 10:42:53 -0400
X-Google-Sender-Auth: t3Ig7P8Td7_kmcW_DK86OE6J-38
Message-ID: 
From: Barry Leiba 
To: Apps Discuss , HTTP Working Group 
Content-Type: multipart/alternative; boundary=bcaec5015e97c3ff1804cbf1d140
Subject: [apps-discuss] Re-review of draft-snell-http-prefer-15
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Oct 2012 14:42:55 -0000

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

After some discussion on the httpbis mailing list, James made a significant
change to draft-snell-http-prefer-15, adding (back) the Preference-Applied
response header field.  See:
http://tools.ietf.org/rfcdiff?url2=draft-snell-http-prefer-15.txt

Because this happened after last call, I would like the copied communities
to re-review this in parallel with IESG Evaluation, and make further
comments on that particular change.

The document is on the 25 Oct telechat, so please post any comments by then.

Barry, sponsoring AD

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

After some discussion on the httpbis mailing list, James made a significant=
 change to=A0draft-snell-http-prefer-15, adding (back) the Preference-Ap=
plied response header field. =A0See:

Because this happened after last c=
all, I would like the copied communities to re-review this in parallel with=
 IESG Evaluation, and make further comments on that particular change.



The document is on the 25 Oct telechat, so please post=
 any comments by then.



Barry, sponsoring AD





--bcaec5015e97c3ff1804cbf1d140--

From mnot@mnot.net  Sat Oct 13 11:43:01 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D18D21F8491 for ; Sat, 13 Oct 2012 11:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.138
X-Spam-Level: 
X-Spam-Status: No, score=-104.138 tagged_above=-999 required=5 tests=[AWL=-1.539, 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 jZmhwPOfoDdJ for ; Sat, 13 Oct 2012 11:43:00 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6527C21F8489 for ; Sat, 13 Oct 2012 11:43:00 -0700 (PDT)
Received: from mnot-mini.mnot.net (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6282122E1EB; Sat, 13 Oct 2012 14:42:52 -0400 (EDT)
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: 
Date: Sun, 14 Oct 2012 05:42:48 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9C722517-7948-4B0E-A78D-8992FD96F59B@mnot.net>
References: 
To: Barry Leiba 
X-Mailer: Apple Mail (2.1499)
Cc: HTTP Working Group , Apps Discuss 
Subject: Re: [apps-discuss] Re-review of draft-snell-http-prefer-15
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Oct 2012 18:43:01 -0000

My .02:

* Technically, the requirement for including a Vary should include the =
option for using Vary: *; requiring Prefer in the Vary header is too =
constraining.

* Vary needs to be on *every* response from a resource that evidences =
negotiation, not those that just happen to be influenced by the Prefer =
header.=20

* The examples section needs to show complete request and response =
messages, not just examples of the header field in isolation. This spec =
is not just defining a header, it's defining a protocol.

* "return-async" now seems like a less functional expression of "wait". =
Also, saying you'd *prefer* something to return async doesn't make much =
sense; if the request semantics can be honoured immediately and =
reflected in the response representation, why not allow so?=20

I can imagine some protocols that want to tunnel over HTTP wanting to do =
so, but can't think of any sane use of HTTP that would. return-async can =
be dropped.

* I still don't see the use cases for Preference-Applied (see message =
just now on the thread that brought it back). I'm not going to fight it, =
but am -0.5 on it (as I think it introduces opportunities for people to =
abuse the mechanism).

Cheers,



On 14/10/2012, at 1:42 AM, Barry Leiba  wrote:

> After some discussion on the httpbis mailing list, James made a =
significant change to draft-snell-http-prefer-15, adding (back) the =
Preference-Applied response header field.  See:
> http://tools.ietf.org/rfcdiff?url2=3Ddraft-snell-http-prefer-15.txt
>=20
> Because this happened after last call, I would like the copied =
communities to re-review this in parallel with IESG Evaluation, and make =
further comments on that particular change.
>=20
> The document is on the 25 Oct telechat, so please post any comments by =
then.
>=20
> Barry, sponsoring AD
>=20

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




From jasnell@gmail.com  Sat Oct 13 12:01:20 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A364521F84D5 for ; Sat, 13 Oct 2012 12:01:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.674
X-Spam-Level: 
X-Spam-Status: No, score=-4.674 tagged_above=-999 required=5 tests=[AWL=-1.076, 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 y6RMXEJ9Eifp for ; Sat, 13 Oct 2012 12:01:19 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5405221F84D9 for ; Sat, 13 Oct 2012 12:01:19 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hr7so525625wib.13 for ; Sat, 13 Oct 2012 12:01:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=e0zAluSPxFa4Ky5Ym9LbSbOF5QtclSbn4asazGt0pCQ=; b=WO+K2AHJibsYn6dm1PG9DSb8/B574XY8k5ewlQhAup56IhpwUn4Gh9ZoLyaWkG8TS9 nsFg1r77TOrcx+s801EWq0pOu/RchP3YjlRpct1kwHFOfMKkJviSrZIc19ma7B9gNKBb yzjRaGKzQnYBlwtSFEbVUI3d1D/FGR5ltvCfyB/M3LHape5498Y6lsTUvB/Kmmo+mnW8 e/4Pdz1UBFsTGXhFL3620Z9ZdR2febCXW5EJIGfCgSLJKMft6YzppI0j3tR7Os4q2e5g 9nDQhjO5Di8nxwzHYAvwT8lUWRWd1rD9e2KM1MPcBAi/PDZTAAsSMKs/OHGfqYGB2tFQ GxUA==
Received: by 10.180.80.104 with SMTP id q8mr13570212wix.6.1350154869522; Sat, 13 Oct 2012 12:01:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.201.68 with HTTP; Sat, 13 Oct 2012 12:00:48 -0700 (PDT)
In-Reply-To: <9C722517-7948-4B0E-A78D-8992FD96F59B@mnot.net>
References:  <9C722517-7948-4B0E-A78D-8992FD96F59B@mnot.net>
From: James M Snell 
Date: Sat, 13 Oct 2012 12:00:48 -0700
Message-ID: 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=f46d04428eac63bf9404cbf56d56
Cc: Barry Leiba , HTTP Working Group , Apps Discuss 
Subject: Re: [apps-discuss] Re-review of draft-snell-http-prefer-15
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Oct 2012 19:01:20 -0000

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

On Sat, Oct 13, 2012 at 11:42 AM, Mark Nottingham  wrote:

> My .02:
>
> * Technically, the requirement for including a Vary should include the
> option for using Vary: *; requiring Prefer in the Vary header is too
> constraining.
>
> * Vary needs to be on *every* response from a resource that evidences
> negotiation, not those that just happen to be influenced by the Prefer
> header.
>

A comment can be added in that "Vary: *" would also cover the requirement
here.


>
> * The examples section needs to show complete request and response
> messages, not just examples of the header field in isolation. This spec is
> not just defining a header, it's defining a protocol.
>
>
Noted but not sure it's critical since there are plenty of other examples
given throughout the document that show complete requests. It's a minor
addition, tho, that can be added into a final version.


> * "return-async" now seems like a less functional expression of "wait".
> Also, saying you'd *prefer* something to return async doesn't make much
> sense; if the request semantics can be honoured immediately and reflected
> in the response representation, why not allow so?
>
> I can imagine some protocols that want to tunnel over HTTP wanting to do
> so, but can't think of any sane use of HTTP that would. return-async can be
> dropped.
>
>
-1 ... in my use of this I have used return-asynch and wait together (e.g.
Prefer: return-asynch; wait=10)... if the server is able to process the
request in less than 10 seconds, it does so and responds synchronously. If
it cannot, it responds asynchronously. The mechanism works rather
effectively when dealing with long running processes. I respect that you
might not consider such use to be "sane" but it has proved useful
nevertheless.

- James

* I still don't see the use cases for Preference-Applied (see message just
> now on the thread that brought it back). I'm not going to fight it, but am
> -0.5 on it (as I think it introduces opportunities for people to abuse the
> mechanism).
>


> Cheers,
>
>
>
> On 14/10/2012, at 1:42 AM, Barry Leiba  wrote:
>
> > After some discussion on the httpbis mailing list, James made a
> significant change to draft-snell-http-prefer-15, adding (back) the
> Preference-Applied response header field.  See:
> > http://tools.ietf.org/rfcdiff?url2=draft-snell-http-prefer-15.txt
> >
> > Because this happened after last call, I would like the copied
> communities to re-review this in parallel with IESG Evaluation, and make
> further comments on that particular change.
> >
> > The document is on the 25 Oct telechat, so please post any comments by
> then.
> >
> > Barry, sponsoring AD
> >
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

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



On Sat, Oct 13, 2012 at 11:42 AM, Mark Nottingham <=
;mnot@mnot.net> wrote:



My .02:



* Technically, the requirement for including a Vary should include the opti=
on for using Vary: *; requiring Prefer in the Vary header is too constraini=
ng.



* Vary needs to be on *every* response from a resource that evidences negot=
iation, not those that just happen to be influenced by the Prefer header.

A comment can be added in that "Var=
y: *" would also cover the requirement here.=C2=A0



=C2=A0



* The examples section needs to show complete request and response messages=
, not just examples of the header field in isolation. This spec is not just=
 defining a header, it's defining a protocol.



Noted but not sure it's critical s=
ince there are plenty of other examples given throughout the document that =
show complete requests. It's a minor addition, tho, that can be added i=
nto a final version.



=C2=A0

* "return-async" now seems like a less functional expression of &=
quot;wait". Also, saying you'd *prefer* something to return async =
doesn't make much sense; if the request semantics can be honoured immed=
iately and reflected in the response representation, why not allow so?





I can imagine some protocols that want to tunnel over HTTP wanting to do so=
, but can't think of any sane use of HTTP that would. return-async can =
be dropped.



-1 ... in my use of this I have used r=
eturn-asynch and wait together (e.g. Prefer: return-asynch; wait=3D10)... i=
f the server is able to process the request in less than 10 seconds, it doe=
s so and responds synchronously. If it cannot, it responds asynchronously. =
The mechanism works rather effectively when dealing with long running proce=
sses. I respect that you might not consider such use to be "sane"=
 but it has proved useful nevertheless.



=C2=A0
- James


* I still don't see the use cases for Preference-Applied (see message j=
ust now on the thread that brought it back). I'm not going to fight it,=
 but am -0.5 on it (as I think it introduces opportunities for people to ab=
use the mechanism).



=C2=A0

Cheers,








On 14/10/2012, at 1:42 AM, Barry Leiba <barryleiba@computer.org> wrote:



> After some discussion on the httpbis mailing list, James made a signif=
icant change to draft-snell-http-prefer-15, adding (back) the Preference-Ap=
plied response header field. =C2=A0See:

> http://tools.ietf.org/rfcdiff?url2=3Ddraft-snel=
l-http-prefer-15.txt

>

> Because this happened after last call, I would like the copied communi=
ties to re-review this in parallel with IESG Evaluation, and make further c=
omments on that particular change.

>

> The document is on the 25 Oct telechat, so please post any comments by=
 then.

>

> Barry, sponsoring AD

>




--

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







_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--f46d04428eac63bf9404cbf56d56--

From mnot@mnot.net  Sat Oct 13 12:05:58 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F0D21F84D9 for ; Sat, 13 Oct 2012 12:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.232
X-Spam-Level: 
X-Spam-Status: No, score=-104.232 tagged_above=-999 required=5 tests=[AWL=-1.633, 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 FXt4liFPCwMK for ; Sat, 13 Oct 2012 12:05:57 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 42AC121F84D5 for ; Sat, 13 Oct 2012 12:05:57 -0700 (PDT)
Received: from mnot-mini.mnot.net (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2045F22DD6D; Sat, 13 Oct 2012 15:05:48 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: 
Date: Sun, 14 Oct 2012 06:05:43 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <603A775B-5CCA-44F7-A7FF-BB22168CBE2B@mnot.net>
References:  <9C722517-7948-4B0E-A78D-8992FD96F59B@mnot.net> 
To: James M Snell 
X-Mailer: Apple Mail (2.1499)
Cc: Barry Leiba , HTTP Working Group , Apps Discuss 
Subject: Re: [apps-discuss] Re-review of draft-snell-http-prefer-15
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Oct 2012 19:05:58 -0000

On 14/10/2012, at 6:00 AM, James M Snell  wrote:

> -1 ... in my use of this I have used return-asynch and wait together =
(e.g. Prefer: return-asynch; wait=3D10)... if the server is able to =
process the request in less than 10 seconds, it does so and responds =
synchronously. If it cannot, it responds asynchronously. The mechanism =
works rather effectively when dealing with long running processes. I =
respect that you might not consider such use to be "sane" but it has =
proved useful nevertheless.

Right, but what's the difference between:

  Prefer: wait=3D10
and
  Prefer: return-asynch, wait=3D10

? "return asynch" really says "give me a 202" which is nonsense; the =
client doesn't control the status code, the server does.=20

Cheers,

P.S. I hate that "h" on "return-asynch"... :)

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




From jasnell@gmail.com  Sat Oct 13 12:11:50 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFB421F846B for ; Sat, 13 Oct 2012 12:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.714
X-Spam-Level: 
X-Spam-Status: No, score=-4.714 tagged_above=-999 required=5 tests=[AWL=-1.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGCpNFJnphVE for ; Sat, 13 Oct 2012 12:11:50 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id ACE1421F8469 for ; Sat, 13 Oct 2012 12:11:49 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hr7so530042wib.13 for ; Sat, 13 Oct 2012 12:11:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1E1dinnCjsOYx1zpJICCJYJgY3ZoJDsH47U3hxQ96Xo=; b=ntSsApWpBc/QSuT87RnS24j0Zjx4tgkEFhwQexC6cZ4ged8ciN5s0/SmPNdtAtJpkj 2H+34oLEizB3fejzVfNS2NMM1KwkN+L8ZhFH7r/AWjEeCMathRvNfcH/nF377twfwZ3Z ezsW9THUX0kj5rFUvd173v152thqVper87al48i70F5VzVE5X1ovy7aVW6tdqFs8kF2F BiKhJ/tw4hww/kHPDk9JNdg/Wt67sXekmjK/Dy8j5aR2eCQxOm+B8yK54W82QzOunRMv LBONPDYzqtHiECq/YTuAy30yi3RRopiYyX5wqEFRuXMvIU2q89ND9fzKcSmgj1G6fhMQ irrg==
Received: by 10.180.87.230 with SMTP id bb6mr13600069wib.6.1350155508754; Sat, 13 Oct 2012 12:11:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.201.68 with HTTP; Sat, 13 Oct 2012 12:11:28 -0700 (PDT)
In-Reply-To: <603A775B-5CCA-44F7-A7FF-BB22168CBE2B@mnot.net>
References:  <9C722517-7948-4B0E-A78D-8992FD96F59B@mnot.net>  <603A775B-5CCA-44F7-A7FF-BB22168CBE2B@mnot.net>
From: James M Snell 
Date: Sat, 13 Oct 2012 12:11:28 -0700
Message-ID: 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=f46d0444e97b7dab2104cbf5933d
Cc: Barry Leiba , HTTP Working Group , Apps Discuss 
Subject: Re: [apps-discuss] Re-review of draft-snell-http-prefer-15
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Oct 2012 19:11:50 -0000

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

On Sat, Oct 13, 2012 at 12:05 PM, Mark Nottingham  wrote:

>
> On 14/10/2012, at 6:00 AM, James M Snell  wrote:
>
> > -1 ... in my use of this I have used return-asynch and wait together
> (e.g. Prefer: return-asynch; wait=10)... if the server is able to process
> the request in less than 10 seconds, it does so and responds synchronously.
> If it cannot, it responds asynchronously. The mechanism works rather
> effectively when dealing with long running processes. I respect that you
> might not consider such use to be "sane" but it has proved useful
> nevertheless.
>
> Right, but what's the difference between:
>
>   Prefer: wait=10
> and
>   Prefer: return-asynch, wait=10
>
> ? "return asynch" really says "give me a 202" which is nonsense; the
> client doesn't control the status code, the server does.
>
>
That's why it's a Prefer header and not Expect. The server retains control.
"Prefer: wait=10" could just as easily result in the server simply throwing
up it's hands and saying, "sorry, can't do it"


> Cheers,
>
> P.S. I hate that "h" on "return-asynch"... :)
>

Yeah yeah... me too. Only reason not to drop it would be some existing code
but known impls are limited enough right now that it shouldn't be a problem
really.

- James


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

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



On Sat, Oct 13, 2012 at 12:05 PM, Mark Nottingham <=
;mnot@mnot.net> wrote:





On 14/10/2012, at 6:00 AM, James M Snell <jasnell@gmail.com> wrote:



> -1 ... in my use of this I have used return-asynch and wait together (=
e.g. Prefer: return-asynch; wait=3D10)... if the server is able to process =
the request in less than 10 seconds, it does so and responds synchronously.=
 If it cannot, it responds asynchronously. The mechanism works rather effec=
tively when dealing with long running processes. I respect that you might n=
ot consider such use to be "sane" but it has proved useful nevert=
heless.






Right, but what's the difference between:



=C2=A0 Prefer: wait=3D10

and

=C2=A0 Prefer: return-asynch, wait=3D10



? "return asynch" really says "give me a 202" which is =
nonsense; the client doesn't control the status code, the server does.<=
br>


That's why it's a Prefer heade=
r and not Expect. The server retains control. "Prefer: wait=3D10"=
 could just as easily result in the server simply throwing up it's hand=
s and saying, "sorry, can't do it"



=C2=A0

Cheers,



P.S. I hate that "h" on "return-asynch"... :)

Yeah yeah... me too. Only reason not to drop it =
would be some existing code but known impls are limited enough right now th=
at it shouldn't be a problem really.




- James
=C2=A0




--

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











--f46d0444e97b7dab2104cbf5933d--

From mnot@mnot.net  Sat Oct 13 12:55:14 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73D821F846B for ; Sat, 13 Oct 2012 12:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.194
X-Spam-Level: 
X-Spam-Status: No, score=-104.194 tagged_above=-999 required=5 tests=[AWL=-1.595, 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 avcaroLkpjW5 for ; Sat, 13 Oct 2012 12:55:13 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id BAB3521F8467 for ; Sat, 13 Oct 2012 12:55:13 -0700 (PDT)
Received: from mnot-mini.mnot.net (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F2FBD22E257; Sat, 13 Oct 2012 15:55:05 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>
Date: Sun, 14 Oct 2012 06:55:00 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>
To: "Manger, James H" 
X-Mailer: Apple Mail (2.1499)
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Oct 2012 19:55:15 -0000

There hasn't been a lot of discussion of this on-list, but based on a =
few private exchanges and discussion elsewhere (e.g., =
), I =
think there is at least one problem worth solving here -- being able to =
add items to arrays without knowing their current length.

The suggestion is to add an 'index' attribute. I think that adds a lot =
of complexity and corner cases, and wonder whether we couldn't achieve =
the same thing by allowing negative indices on JSON Pointer; e.g.,

/foo/-1

to indicate the last member of the array (delta a discussion about =
whether we base on -0 or -1).

If folks are uncomfortable with that amount of complexity, I think we =
could even meet the use case by doing something like

/foo/-

to indicate the last member of the array.

Thoughts?

Beyond that, there's a notion that we should relax certain requirements =
so as to avoid making the client know the exact state of the resource in =
every instance.

I *think* we have agreement that this should be done for "add"  (by =
removing the "MUST exist" requirement), but not elsewhere.=20

Specifically:

>    If the target location references the root of the target document =
or
>    a member of an existing object, the specified location MUST already
>    exist for the operation to be successful.

... and I note that our examples already seem to violate this =
requirement, depending on how you read it, so *something* needs to =
change.

At the same time, it might be good to change the name; I'd suggest =
"set".

Make sense?

Cheers,



On 01/10/2012, at 3:22 PM, "Manger, James H" =
 wrote:

> RE: draft-ietf-appsawg-json-patch-05
>=20
> Suggestion: replace the "add" and "replace" operations with "insert" =
and "put" operations that work without needing to know (ie be in sync =
with) the old state of the JSON doc being changed. New text:
>=20
>  4.1. insert
>=20
>    The "insert" operation adds a new value to an array. The operation
>    object MUST include "path" and "value" members, and MAY include an
>    "i" member. "path" holds a JSON pointer that identifies an array.
>    "value" holds the value to add, which can be any JSON value.
>    "i" holds a number that is rounded to the nearest integer to give
>    the array index of the new value when inserted. If "i" is absent =
the
>    value is appended to the array. Any items in the array at an index
>    equal to or greater than "i" are moved to the next higher index to
>    make room for the new value.
>=20
>    It is an error if "i" (rounded to the nearest integer) is less than
>    0 or greater than the length of the array.
>=20
>    Example:
>    Old:   {"n":[1,2,3]}
>    Patch: [{"op":"insert", "path":"/n", "value":4},
>            {"op":"insert", "path":"/n", "value":5, "i":5},
>            {"op":"insert", "path":"/n", "value":1.5, "i":1}]
>    New:   {"n":[1,1.5,2,3,4,5]}
>=20
>=20
>  4.2. put
>=20
>    The "put" operation puts a new value at the target location,
>    replacing any existing value if there is one. The operation object
>    MUST include "path" and "value" members. "path" holds a JSON =
pointer
>    that identifies the target location, which can be an object member
>    (that is or isn't present), an array index (that must exist), or
>    the whole target. "value" holds the value to add, which can be any
>    JSON value.
>=20
>    Example:
>    Old:   {"n":[1,2,3]}
>    Patch: [{"op":"put", "path":"", "value":[true, {"a":1}]},
>            {"op":"put", "path":"/0", "value":false},
>            {"op":"put", "path":"/1/b", "value":2},
>            {"op":"put", "path":"/1/a", "value":3}]
>    New:   [false, {"a":3, "b":2}]
>=20
> --
> James Manger
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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




From mnot@mnot.net  Sat Oct 13 13:39:56 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD97C21F846C for ; Sat, 13 Oct 2012 13:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.155
X-Spam-Level: 
X-Spam-Status: No, score=-104.155 tagged_above=-999 required=5 tests=[AWL=-1.556, 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 nZdcLWBIUUWP for ; Sat, 13 Oct 2012 13:39:56 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 485C021F8464 for ; Sat, 13 Oct 2012 13:39:56 -0700 (PDT)
Received: from mnot-mini.mnot.net (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E364F22E255; Sat, 13 Oct 2012 16:39:47 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: 
Date: Sun, 14 Oct 2012 07:39:42 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <9C722517-7948-4B0E-A78D-8992FD96F59B@mnot.net>  <603A775B-5CCA-44F7-A7FF-BB22168CBE2B@mnot.net> 
To: James M Snell 
X-Mailer: Apple Mail (2.1499)
Cc: Barry Leiba , HTTP Working Group , Apps Discuss 
Subject: Re: [apps-discuss] Re-review of draft-snell-http-prefer-15
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Oct 2012 20:39:57 -0000

On 14/10/2012, at 6:11 AM, James M Snell  wrote:

>> Right, but what's the difference between:
>>=20
>>   Prefer: wait=3D10
>> and
>>   Prefer: return-asynch, wait=3D10
>>=20
>> ? "return asynch" really says "give me a 202" which is nonsense; the =
client doesn't control the status code, the server does.
>>=20
>=20
> That's why it's a Prefer header and not Expect. The server retains =
control. "Prefer: wait=3D10" could just as easily result in the server =
simply throwing up it's hands and saying, "sorry, can't do it"

And what does return-async(h) bring to the party?

The server can still throw up its hands with a 4xx or 5xx, and the =
client has to deal with that.=20



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




From jan.algermissen@nordsc.com  Sat Oct 13 14:08:15 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089EB21F8498 for ; Sat, 13 Oct 2012 14:08:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-AQPa9TgiZt for ; Sat, 13 Oct 2012 14:08:14 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 54AA521F8493 for ; Sat, 13 Oct 2012 14:08:14 -0700 (PDT)
Received: from [192.168.2.103] (p548FA742.dip.t-dialin.net [84.143.167.66]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MGi7V-1T9gfC0FSj-00DZSF; Sat, 13 Oct 2012 23:08:11 +0200
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Jan Algermissen 
In-Reply-To: 
Date: Sat, 13 Oct 2012 23:08:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E11857B-970B-44D6-8EB9-AF7BEFF28F50@nordsc.com>
References:  <9C722517-7948-4B0E-A78D-8992FD96F59B@mnot.net>  <603A775B-5CCA-44F7-A7FF-BB22168CBE2B@mnot.net>  
To: Mark Nottingham 
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:3CC62Udx31OeJ7wnD3Bt8JSxmSoK/vzsuWPFFlRsWco 2DI689FKaeNKrXrjIsBUrRn4LWGIC6JWl0mzlvfKZmtR7EL+95 tehYNyuBt7ZIHP1F8h5NBz/wJIAJIP+XmgDyxuubUypRMd8nNj Dod8nzeKNue5AE4wy9Tp7h+qAI7CZuQ6VPUI74i95ES4N4IBd0 Ud1b9T2RDNo/ByZTdOwAvdEwEn8zHcUj/wukByE+mn+R1kFYP5 cLEsatMgmpbfmc6CdF02yyQbcWFNpKpcDAm3FT/Vq9ZbDOkdK2 1QQAi+2DeZJusJH4oF4uaKSPWqdGSC8NyYzz1GxVfgLN0LKheX zBgjSuwPNWg2ST/RQRY4ORbK3zqGxaPLS4WZZoq6PX8Wb4du/T FayQlTKnagBmg==
Cc: Apps Discuss , HTTP Working Group , Barry Leiba 
Subject: Re: [apps-discuss] Re-review of draft-snell-http-prefer-15
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Oct 2012 21:08:15 -0000

On Oct 13, 2012, at 10:39 PM, Mark Nottingham wrote:

>=20
> On 14/10/2012, at 6:11 AM, James M Snell  wrote:
>=20
>>> Right, but what's the difference between:
>>>=20
>>>  Prefer: wait=3D10
>>> and
>>>  Prefer: return-asynch, wait=3D10
>>>=20
>>> ? "return asynch" really says "give me a 202" which is nonsense; the =
client doesn't control the status code, the server does.
>>>=20
>>=20
>> That's why it's a Prefer header and not Expect. The server retains =
control. "Prefer: wait=3D10" could just as easily result in the server =
simply throwing up it's hands and saying, "sorry, can't do it"
>=20
> And what does return-async(h) bring to the party?

I cannot see that either. In fact, I cannot even imagine a server paying =
attention to the '10', given the juggling between estimating the task =
duration and comparing to the wait time.

Maybe

  Prefer: wait

just does the job?

Jan


>=20
> The server can still throw up its hands with a 4xx or 5xx, and the =
client has to deal with that.=20
>=20
>=20
>=20
> --
> Mark Nottingham   http://www.mnot.net/
>=20
>=20
>=20
>=20


From stephen.farrell@cs.tcd.ie  Sat Oct 13 14:22:08 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CE921F845E; Sat, 13 Oct 2012 14:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Level: 
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vm0WPboWrmhn; Sat, 13 Oct 2012 14:22:07 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 89B6921F844F; Sat, 13 Oct 2012 14:22:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1791517147A; Sat, 13 Oct 2012 22:22:04 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1350163322; bh=IyUZHiM9b9XThi DGhTsctPG8wqjlVu7/7gcoBrNEJkM=; b=dd+mKm0u6sfvFms3nh3oCbRBDpaIQs qmn5LBoUIvtqqXjvbxL8oUsAQUUZlX7YLltHTAPQxFMkkgThvjpDhYFzw8hhDv2D ZVBh2if01rG0xwZwxkAljakNy/qUOOyTzknm2odqWoRhlFitDsn8a2xGn7CefYAu YB6RBDOxPGWcE9YRbGck5iplF8zPK/Sy2WRotZhB2debi/JIChkIvk3Jf74i3vot 2NYsAOJvDKw30zlBfWlyyA6W14qR2g/HD+pHgQVlyoLcp4cgPYa1upL0InZZ5r7M P0+MqB0uVMIfVnnnSdzY8qenDanZ2LQQlMStwF1zal/N/76B6jtUgXlQ==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id UM4-JXC26BA4; Sat, 13 Oct 2012 22:22:02 +0100 (IST)
Received: from [10.87.48.11] (unknown [86.42.181.155]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3CD6F171481; Sat, 13 Oct 2012 22:21:58 +0100 (IST)
Message-ID: <5079DB76.6080207@cs.tcd.ie>
Date: Sat, 13 Oct 2012 22:21:58 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Barry Leiba 
References: <908A5670-8A38-4702-B801-B31BB756EA97@mnot.net> 
In-Reply-To: 
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Mark Nottingham , "iesg@ietf.org IESG" , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] Forwarded draft: registration policy
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Oct 2012 21:22:08 -0000

Hiya,

On 10/13/2012 03:37 PM, Barry Leiba wrote:
>>
>> Draft -09 changed the registration policy for forwarded parameters:
>>
>>> The "Forwarded" header field contains parameters for which IANA is to
>>>    create and maintain a new registry entitled "HTTP Forwarded
>>>    parameters".  Initial registrations are given below; for future
>>>    assignments, the registration procedure to be used is IETF review
>> [RFC5226].
>>
>> 
>>
>> I *think* this change was based upon Stephen's comment:
> 
> 
> I believe you're correct.  Andreas can confirm that.  (And I'm explicitly
> adding Stephen to the CC list here, to be sure he sees and comments.)

As far as I know mine was the only comment on that part but
I don't recall discussing it specifically. though I've not
checked.

>>> Section 9 says only that the expert should ensure that the
>>> specification "address the security and privacy implications of the
>>> requested parameter." So if I defined a parameter that passed on the
>>> precise location of the end-user or the most recent healthcare
>>> related URL they've accessed then would that be ok? I think
>>> additional instructions are needed as to the acceptable purposes to
>>> which such parameters can be put or else perhaps IETF review would
>>> in fact be better. Given the field of applicability I would not be
>>> surprised if very privacy-invasive parameters were defined in
>>> future.
>>
>> <
>> https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/
>>>
>>
>> For the record, I question whether IETF Review is necessary for this
>> registry, because it sets it up as a gatekeeper, rather than a registry of
>> deployed parameters.

I believe this entire spec has bent way too much in the
direction of just documenting existing bad practice and
that the IETF haven't done a good job on quality control
this time. This is not a "purist" position but e.g. I
reckon that moving from XFF to this would be as hard as
moving from XFF to a more privacy friendly design, for
the stated goals. But there was no apparent willingness
to explore that route, or perhaps not all goals were
fully stated.

So I don't agree that making this privacy damaging spec
extensible at lowest cost is actually a good plan. I do
see that IETF review might be a pain, but I suspect there
would also be pain in actually writing down and agreeing
some sensible guidance for an expert, and I'm not sure
that doing that kind of change at AUTH-48 would be
reasonable. I personally don't think FCFS would be good
here either.

> For the record, I agree with you.  But there's more history.  Untiil -05,
> the policy was RFC Required.  I convinced the authors to change it to
> Specification Required in -06, and later to add instructions to the
> designated expert for leniency, erring toward registration rather than
> gatekeeping.  And that is the version that got final working group approval
> and went through IETF last call.
> 
> I'm actually quite disappointed that it's changed back (and is actually
> even stricter than the original, and I agree with you in this:
> 
> 
>> I strongly suspect vendors will give in to the temptation to deploy
>> unregistered parameters here, meaning we'll be publishing yet another
>> registry that's both disconnected from reality and failing to serve the
>> purported purpose (protecting security and privacy).

I do not believe anything related to this specification is aimed
at protecting security or privacy. Rather the opposite in the
case of privacy.

> I think we overdid this in an effort to make Stephen happier with the
> document (and we did make him happier, if not "happy").  

Even "happier" is too much. A little less unhappy perhaps.

> I suggest that
> both the Apps community and the IESG have more discussion on this and sort
> it out for AUTH48.  I suggest that we go back to the IANA Considerations
> from the -08 draft.

Personally, I don't agree that specification required is
enough, unless there's some real guidance for an expert.

S

PS: I've not checked, but I think my comment that this also says
nothing about DNT wasn't addressed, but that's what I get for
abstaining I guess;-)



> 
> Barry
> 

From barryleiba@gmail.com  Sat Oct 13 14:26:39 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF261F041F; Sat, 13 Oct 2012 14:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.27
X-Spam-Level: 
X-Spam-Status: No, score=-103.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgbT8HnB3qg2; Sat, 13 Oct 2012 14:26:39 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA171F0381; Sat, 13 Oct 2012 14:26:39 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 9so7323186iec.31 for ; Sat, 13 Oct 2012 14:26:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:x-rim-org-msg-ref-id:message-id:reply-to:x-priority :sensitivity:importance:subject:to:cc:from:date:content-type :mime-version; bh=+4AnmM7QTPKlg2cz6MpZI7We+MR3/c1DagHdFX2wqpg=; b=sTdidxvt14JQOvY5Kn7xaEUoULmBcRpf3ynpWOX0+5YMZLwleBhmndSJ6kVxlTERer xHczBbu0kJUidt3D1VxApV91WNO+z0zC6dPXei5xHxvde4qn/1A0u5pdzAziRCWtDUhC LNVNSUzwJaG+sJP8rEX5AToNPCl2aKYWjA7weQ7qSmovnbPQfplZiCq1PDaMpHK8S6T7 LI2+h/LQrWcazkFFgnVkrUJsYA+uQNqwhca3Z9JsrmeYS5xkdu4QhZsoRg0dhL7c6PDO gjwDNdOfuPtSe+YgbXeKMmNjAxps8Xo76qVr/NBynW4986kDWqPZcL738TZsqTZb+zFf DL0g==
Received: by 10.50.0.168 with SMTP id 8mr5420844igf.24.1350163598857; Sat, 13 Oct 2012 14:26:38 -0700 (PDT)
Received: from 172.29.197.211 (bda-74-82-80-230.bis6.us.blackberry.com. [74.82.80.230]) by mx.google.com with ESMTPS id bg2sm2143171igb.1.2012.10.13.14.26.37 (version=SSLv3 cipher=OTHER); Sat, 13 Oct 2012 14:26:38 -0700 (PDT)
Sender: Barry Leiba 
X-rim-org-msg-ref-id: 1419478078
Message-ID: <1419478078-1350163596-cardhu_decombobulator_blackberry.rim.net-1611778561-@b15.c4.bise6.blackberry>
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
To: "Stephen Farrell" 
From: "Barry Leiba" 
Date: Sat, 13 Oct 2012 21:26:47 +0000
Content-Type: text/plain
MIME-Version: 1.0
Cc: "iesg@ietf.org IESG" , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] Forwarded draft: registration policy
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: barryleiba@computer.org
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Oct 2012 21:26:39 -0000

> PS: I've not checked, but I think my comment that this also says
> nothing about DNT wasn't addressed, but that's what I get for
> abstaining I guess;-)

Check the RFC Editor note.  That's what we ended up with after discussion with the authors.  We felt that a direct reference to DNT would be non-usefully controversial.

b


From mnot@mnot.net  Sat Oct 13 14:51:44 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050EC11E8091; Sat, 13 Oct 2012 14:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.176
X-Spam-Level: 
X-Spam-Status: No, score=-104.176 tagged_above=-999 required=5 tests=[AWL=-1.577, 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 T8ckJZwmaoh7; Sat, 13 Oct 2012 14:51:43 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id C1D7511E808D; Sat, 13 Oct 2012 14:51:39 -0700 (PDT)
Received: from mnot-mini.mnot.net (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BFFB122E255; Sat, 13 Oct 2012 17:51:32 -0400 (EDT)
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: <5079DB76.6080207@cs.tcd.ie>
Date: Sun, 14 Oct 2012 08:51:25 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <96CE8862-4B2C-43E7-8670-005CAD47749E@mnot.net>
References: <908A5670-8A38-4702-B801-B31BB756EA97@mnot.net>  <5079DB76.6080207@cs.tcd.ie>
To: Stephen Farrell 
X-Mailer: Apple Mail (2.1499)
Cc: Barry Leiba , "iesg@ietf.org IESG" , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] Forwarded draft: registration policy
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Oct 2012 21:51:45 -0000

On 14/10/2012, at 8:21 AM, Stephen Farrell  =
wrote:

> I believe this entire spec has bent way too much in the
> direction of just documenting existing bad practice and
> that the IETF haven't done a good job on quality control
> this time. This is not a "purist" position but e.g. I
> reckon that moving from XFF to this would be as hard as
> moving from XFF to a more privacy friendly design, for
> the stated goals. But there was no apparent willingness
> to explore that route, or perhaps not all goals were
> fully stated.

Didn't that horse already bolt when the cookie spec was approved? =
Revealing the IP that would have been very apparent to the server had an =
intermediary been imposed pales in comparison to the issues there, =
surely?

I'd also point out that making this IETF Review raises the bar for a =
parameter in a header field higher than the bar for minting an entirely =
new header field (Specification Required, as per RFC3864). So I'm not =
sure what's really being accomplished.


> So I don't agree that making this privacy damaging spec
> extensible at lowest cost is actually a good plan. I do
> see that IETF review might be a pain, but I suspect there
> would also be pain in actually writing down and agreeing
> some sensible guidance for an expert, and I'm not sure
> that doing that kind of change at AUTH-48 would be
> reasonable. I personally don't think FCFS would be good
> here either.

Given that the document has normative references to HTTPbis p1 and p4, =
which realistically aren't going to be RFCs for a few months (i.e., just =
about to WGLC p1), I wonder if it makes sense to pull the doc back and =
have another go.

Regards,


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




From stephen.farrell@cs.tcd.ie  Sat Oct 13 14:57:59 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006BE21F846C; Sat, 13 Oct 2012 14:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.508
X-Spam-Level: 
X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 mzzNzAlw4FVJ; Sat, 13 Oct 2012 14:57:58 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 35AD921F846B; Sat, 13 Oct 2012 14:57:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4CE8B17147A; Sat, 13 Oct 2012 22:57:57 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1350165476; bh=FmaDUPmLrkF0Vy e5OZNsroJCgu0ZV4qZU/P3HeI90VU=; b=X/Z1KK/rUbcRBa7tqUFGqSDQIxWgF8 3ryie1klCGkzoYNKkcanVa/ReFQ90eZkydA4RbnGITBnTiNlmuCupduzRQ3rM9l0 z0d9yXDgpLNJKjH0UIauKUddeqIvPU0oaYh32x2kpFVZd+hmymgSNLuNB80lx4xA +nl3G/E5vOhsRpUh4aN+0j3mU7Fs3SWHb1bvFlQTVTwuREAD1jJBsPwxU2fIUa+9 dly5HX/mQAZbI518acTHH/lTlaeOL5T1U66ZlcBHbIQ+za1yg+phvBjnJjxUWJww PQW5tW0QkF7GdAdshTZna/ZJz/vcTvMMZPjUBb2Cp+eFfv6vV+aTuocg==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id PbRRxzRICXtJ; Sat, 13 Oct 2012 22:57:56 +0100 (IST)
Received: from [10.87.48.11] (unknown [86.42.181.155]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 78947171474; Sat, 13 Oct 2012 22:57:54 +0100 (IST)
Message-ID: <5079E3E0.5010104@cs.tcd.ie>
Date: Sat, 13 Oct 2012 22:57:52 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Mark Nottingham 
References: <908A5670-8A38-4702-B801-B31BB756EA97@mnot.net>  <5079DB76.6080207@cs.tcd.ie> <96CE8862-4B2C-43E7-8670-005CAD47749E@mnot.net>
In-Reply-To: <96CE8862-4B2C-43E7-8670-005CAD47749E@mnot.net>
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Barry Leiba , "iesg@ietf.org IESG" , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] Forwarded draft: registration policy
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Oct 2012 21:57:59 -0000

On 10/13/2012 10:51 PM, Mark Nottingham wrote:
> 
> On 14/10/2012, at 8:21 AM, Stephen Farrell  wrote:
> 
>> I believe this entire spec has bent way too much in the
>> direction of just documenting existing bad practice and
>> that the IETF haven't done a good job on quality control
>> this time. This is not a "purist" position but e.g. I
>> reckon that moving from XFF to this would be as hard as
>> moving from XFF to a more privacy friendly design, for
>> the stated goals. But there was no apparent willingness
>> to explore that route, or perhaps not all goals were
>> fully stated.
> 
> Didn't that horse already bolt when the cookie spec was approved? Revealing the IP that would have been very apparent to the server had an intermediary been imposed pales in comparison to the issues there, surely?

Partly. OTOH, there is at least UA control over cookies.

> I'd also point out that making this IETF Review raises the bar for a parameter in a header field higher than the bar for minting an entirely new header field (Specification Required, as per RFC3864). So I'm not sure what's really being accomplished.

That's a fair point.

S.

>> So I don't agree that making this privacy damaging spec
>> extensible at lowest cost is actually a good plan. I do
>> see that IETF review might be a pain, but I suspect there
>> would also be pain in actually writing down and agreeing
>> some sensible guidance for an expert, and I'm not sure
>> that doing that kind of change at AUTH-48 would be
>> reasonable. I personally don't think FCFS would be good
>> here either.
> 
> Given that the document has normative references to HTTPbis p1 and p4, which realistically aren't going to be RFCs for a few months (i.e., just about to WGLC p1), I wonder if it makes sense to pull the doc back and have another go.
> 
> Regards,
> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 

From James.H.Manger@team.telstra.com  Sun Oct 14 17:37:27 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F9C21F8528 for ; Sun, 14 Oct 2012 17:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.864
X-Spam-Level: 
X-Spam-Status: No, score=-0.864 tagged_above=-999 required=5 tests=[AWL=0.037,  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 OzYso3LQ1os2 for ; Sun, 14 Oct 2012 17:37:26 -0700 (PDT)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9A97E21F8510 for ; Sun, 14 Oct 2012 17:37:24 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,586,1344175200"; d="scan'208";a="102939793"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 15 Oct 2012 11:37:22 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6865"; a="94002280"
Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcbni.tcif.telstra.com.au with ESMTP; 15 Oct 2012 11:37:22 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Mon, 15 Oct 2012 11:37:22 +1100
From: "Manger, James H" 
To: Mark Nottingham 
Date: Mon, 15 Oct 2012 11:37:21 +1100
Thread-Topic: [apps-discuss] json-patch: "op":"insert" and "op":"put"
Thread-Index: Ac2pfKs1Eg5KYdWaTQ+uBQLv0dephwA37GGw
Message-ID: <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com>
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com> 
In-Reply-To: 
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2012 00:37:27 -0000

SmF2YSB1c2VzOg0KKiAiYWRkIiB0byBpbnNlcnQgYSBuZXcgaXRlbSBpbnRvIGEgbGlzdCAoYXJy
YXkpLA0KKiAic2V0IiB0byByZXBsYWNlIGEgY3VycmVudCBpdGVtIGluIGEgbGlzdCAoYXJyYXkp
LCBhbmQNCiogInB1dCIgdG8gcHV0IGEga2V5L3ZhbHVlIHBhaXIgaW4gYSBtYXAgKG9iamVjdCks
IHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgdGhlIGtleSBhbHJlYWR5IGV4aXN0cy4NCg0K
Q29uc2VxdWVudGx5LCBJIGRvbid0IHRoaW5rICJzZXQiIGlzIGEgZ29vZCBuYW1lIGZvciBhIGpz
b24tcGF0Y2ggb3BlcmF0aW9uIGlmIGl0IHByb3ZpZGVzIHRoZSBmdW5jdGlvbmFsaXR5IG9mIEph
dmHigJlzICJhZGQiLCBidXQgbm90IEphdmHigJlzICJzZXQiLg0KDQpJdCB3b3VsZCBzaW1wbGlm
eSBzcGVjICYgY29kZSB0byBkZWZpbmUgMyBvcGVyYXRpb25zIGZvciBqc29uLXBhdGNoLCBpbnN0
ZWFkIG9mIHRyeWluZyB0byBzcXVlZXplIHRoZSBmdW5jdGlvbmFsaXR5IGludG8gdHdvIG9mIHRo
ZXNlLg0KDQoNCj4gL2Zvby8tMQ0KDQpJIGxpa2UgdGhlIGFiaWxpdHkgdG8gaW5kaWNhdGUgcG9z
aXRpb24gaW4gYW4gYXJyYXkgKG9yIGJldHdlZW4gYXJyYXkgZWxlbWVudHMpIGZyb20gdGhlbiBl
bmQuIEnigJltIG5vdCBzdXJlIHRoYXQgZXh0ZW5kaW5nIEpTT04gcG9pbnRlciBpcyB0aGUgcmln
aHQgYXBwcm9hY2guIEN1cnJlbnRseSB0aGVyZSBpcyBhIHVuaXF1ZSBwb2ludGVyIGZvciBldmVy
eSB2YWx1ZS4gSXQgd291bGQgYmUgYSBzaGFtZSB0byBsb3NlIHRoYXQgcHJvcGVydHkuDQoNCi0t
DQpKYW1lcyBNYW5nZXINCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206
IE1hcmsgTm90dGluZ2hhbSBbbWFpbHRvOm1ub3RAbW5vdC5uZXRdDQo+IFNlbnQ6IFN1bmRheSwg
MTQgT2N0b2JlciAyMDEyIDY6NTUgQU0NCj4gVG86IE1hbmdlciwgSmFtZXMgSA0KPiBDYzogYXBw
cy1kaXNjdXNzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBqc29uLXBh
dGNoOiAib3AiOiJpbnNlcnQiIGFuZCAib3AiOiJwdXQiDQo+IA0KPiBUaGVyZSBoYXNuJ3QgYmVl
biBhIGxvdCBvZiBkaXNjdXNzaW9uIG9mIHRoaXMgb24tbGlzdCwgYnV0IGJhc2VkIG9uIGENCj4g
ZmV3IHByaXZhdGUgZXhjaGFuZ2VzIGFuZCBkaXNjdXNzaW9uIGVsc2V3aGVyZSAoZS5nLiwNCj4g
PGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zY2ltL2N1cnJlbnQvbXNnMDA3
NDQuaHRtbD4pLCBJDQo+IHRoaW5rIHRoZXJlIGlzIGF0IGxlYXN0IG9uZSBwcm9ibGVtIHdvcnRo
IHNvbHZpbmcgaGVyZSAtLSBiZWluZyBhYmxlIHRvDQo+IGFkZCBpdGVtcyB0byBhcnJheXMgd2l0
aG91dCBrbm93aW5nIHRoZWlyIGN1cnJlbnQgbGVuZ3RoLg0KPiANCj4gVGhlIHN1Z2dlc3Rpb24g
aXMgdG8gYWRkIGFuICdpbmRleCcgYXR0cmlidXRlLiBJIHRoaW5rIHRoYXQgYWRkcyBhIGxvdA0K
PiBvZiBjb21wbGV4aXR5IGFuZCBjb3JuZXIgY2FzZXMsIGFuZCB3b25kZXIgd2hldGhlciB3ZSBj
b3VsZG4ndCBhY2hpZXZlDQo+IHRoZSBzYW1lIHRoaW5nIGJ5IGFsbG93aW5nIG5lZ2F0aXZlIGlu
ZGljZXMgb24gSlNPTiBQb2ludGVyOyBlLmcuLA0KPiANCj4gL2Zvby8tMQ0KPiANCj4gdG8gaW5k
aWNhdGUgdGhlIGxhc3QgbWVtYmVyIG9mIHRoZSBhcnJheSAoZGVsdGEgYSBkaXNjdXNzaW9uIGFi
b3V0DQo+IHdoZXRoZXIgd2UgYmFzZSBvbiAtMCBvciAtMSkuDQo+IA0KPiBJZiBmb2xrcyBhcmUg
dW5jb21mb3J0YWJsZSB3aXRoIHRoYXQgYW1vdW50IG9mIGNvbXBsZXhpdHksIEkgdGhpbmsgd2UN
Cj4gY291bGQgZXZlbiBtZWV0IHRoZSB1c2UgY2FzZSBieSBkb2luZyBzb21ldGhpbmcgbGlrZQ0K
PiANCj4gL2Zvby8tDQo+IA0KPiB0byBpbmRpY2F0ZSB0aGUgbGFzdCBtZW1iZXIgb2YgdGhlIGFy
cmF5Lg0KPiANCj4gVGhvdWdodHM/DQo+IA0KPiBCZXlvbmQgdGhhdCwgdGhlcmUncyBhIG5vdGlv
biB0aGF0IHdlIHNob3VsZCByZWxheCBjZXJ0YWluIHJlcXVpcmVtZW50cw0KPiBzbyBhcyB0byBh
dm9pZCBtYWtpbmcgdGhlIGNsaWVudCBrbm93IHRoZSBleGFjdCBzdGF0ZSBvZiB0aGUgcmVzb3Vy
Y2UNCj4gaW4gZXZlcnkgaW5zdGFuY2UuDQo+IA0KPiBJICp0aGluayogd2UgaGF2ZSBhZ3JlZW1l
bnQgdGhhdCB0aGlzIHNob3VsZCBiZSBkb25lIGZvciAiYWRkIiAgKGJ5DQo+IHJlbW92aW5nIHRo
ZSAiTVVTVCBleGlzdCIgcmVxdWlyZW1lbnQpLCBidXQgbm90IGVsc2V3aGVyZS4NCj4gDQo+IFNw
ZWNpZmljYWxseToNCj4gDQo+ID4gICAgSWYgdGhlIHRhcmdldCBsb2NhdGlvbiByZWZlcmVuY2Vz
IHRoZSByb290IG9mIHRoZSB0YXJnZXQgZG9jdW1lbnQNCj4gb3INCj4gPiAgICBhIG1lbWJlciBv
ZiBhbiBleGlzdGluZyBvYmplY3QsIHRoZSBzcGVjaWZpZWQgbG9jYXRpb24gTVVTVA0KPiBhbHJl
YWR5DQo+ID4gICAgZXhpc3QgZm9yIHRoZSBvcGVyYXRpb24gdG8gYmUgc3VjY2Vzc2Z1bC4NCj4g
DQo+IC4uLiBhbmQgSSBub3RlIHRoYXQgb3VyIGV4YW1wbGVzIGFscmVhZHkgc2VlbSB0byB2aW9s
YXRlIHRoaXMNCj4gcmVxdWlyZW1lbnQsIGRlcGVuZGluZyBvbiBob3cgeW91IHJlYWQgaXQsIHNv
ICpzb21ldGhpbmcqIG5lZWRzIHRvDQo+IGNoYW5nZS4NCj4gDQo+IEF0IHRoZSBzYW1lIHRpbWUs
IGl0IG1pZ2h0IGJlIGdvb2QgdG8gY2hhbmdlIHRoZSBuYW1lOyBJJ2Qgc3VnZ2VzdA0KPiAic2V0
Ii4NCj4gDQo+IE1ha2Ugc2Vuc2U/DQo+IA0KPiBDaGVlcnMsDQo+IA0KPiANCj4gDQo+IE9uIDAx
LzEwLzIwMTIsIGF0IDM6MjIgUE0sICJNYW5nZXIsIEphbWVzIEgiDQo+IDxKYW1lcy5ILk1hbmdl
ckB0ZWFtLnRlbHN0cmEuY29tPiB3cm90ZToNCj4gDQo+ID4gUkU6IGRyYWZ0LWlldGYtYXBwc2F3
Zy1qc29uLXBhdGNoLTA1DQo+ID4NCj4gPiBTdWdnZXN0aW9uOiByZXBsYWNlIHRoZSAiYWRkIiBh
bmQgInJlcGxhY2UiIG9wZXJhdGlvbnMgd2l0aCAiaW5zZXJ0Ig0KPiBhbmQgInB1dCIgb3BlcmF0
aW9ucyB0aGF0IHdvcmsgd2l0aG91dCBuZWVkaW5nIHRvIGtub3cgKGllIGJlIGluIHN5bmMNCj4g
d2l0aCkgdGhlIG9sZCBzdGF0ZSBvZiB0aGUgSlNPTiBkb2MgYmVpbmcgY2hhbmdlZC4gTmV3IHRl
eHQ6DQo+ID4NCj4gPiAgNC4xLiBpbnNlcnQNCj4gPg0KPiA+ICAgIFRoZSAiaW5zZXJ0IiBvcGVy
YXRpb24gYWRkcyBhIG5ldyB2YWx1ZSB0byBhbiBhcnJheS4gVGhlIG9wZXJhdGlvbg0KPiA+ICAg
IG9iamVjdCBNVVNUIGluY2x1ZGUgInBhdGgiIGFuZCAidmFsdWUiIG1lbWJlcnMsIGFuZCBNQVkg
aW5jbHVkZSBhbg0KPiA+ICAgICJpIiBtZW1iZXIuICJwYXRoIiBob2xkcyBhIEpTT04gcG9pbnRl
ciB0aGF0IGlkZW50aWZpZXMgYW4gYXJyYXkuDQo+ID4gICAgInZhbHVlIiBob2xkcyB0aGUgdmFs
dWUgdG8gYWRkLCB3aGljaCBjYW4gYmUgYW55IEpTT04gdmFsdWUuDQo+ID4gICAgImkiIGhvbGRz
IGEgbnVtYmVyIHRoYXQgaXMgcm91bmRlZCB0byB0aGUgbmVhcmVzdCBpbnRlZ2VyIHRvIGdpdmUN
Cj4gPiAgICB0aGUgYXJyYXkgaW5kZXggb2YgdGhlIG5ldyB2YWx1ZSB3aGVuIGluc2VydGVkLiBJ
ZiAiaSIgaXMgYWJzZW50DQo+IHRoZQ0KPiA+ICAgIHZhbHVlIGlzIGFwcGVuZGVkIHRvIHRoZSBh
cnJheS4gQW55IGl0ZW1zIGluIHRoZSBhcnJheSBhdCBhbiBpbmRleA0KPiA+ICAgIGVxdWFsIHRv
IG9yIGdyZWF0ZXIgdGhhbiAiaSIgYXJlIG1vdmVkIHRvIHRoZSBuZXh0IGhpZ2hlciBpbmRleCB0
bw0KPiA+ICAgIG1ha2Ugcm9vbSBmb3IgdGhlIG5ldyB2YWx1ZS4NCj4gPg0KPiA+ICAgIEl0IGlz
IGFuIGVycm9yIGlmICJpIiAocm91bmRlZCB0byB0aGUgbmVhcmVzdCBpbnRlZ2VyKSBpcyBsZXNz
DQo+IHRoYW4NCj4gPiAgICAwIG9yIGdyZWF0ZXIgdGhhbiB0aGUgbGVuZ3RoIG9mIHRoZSBhcnJh
eS4NCj4gPg0KPiA+ICAgIEV4YW1wbGU6DQo+ID4gICAgT2xkOiAgIHsibiI6WzEsMiwzXX0NCj4g
PiAgICBQYXRjaDogW3sib3AiOiJpbnNlcnQiLCAicGF0aCI6Ii9uIiwgInZhbHVlIjo0fSwNCj4g
PiAgICAgICAgICAgIHsib3AiOiJpbnNlcnQiLCAicGF0aCI6Ii9uIiwgInZhbHVlIjo1LCAiaSI6
NX0sDQo+ID4gICAgICAgICAgICB7Im9wIjoiaW5zZXJ0IiwgInBhdGgiOiIvbiIsICJ2YWx1ZSI6
MS41LCAiaSI6MX1dDQo+ID4gICAgTmV3OiAgIHsibiI6WzEsMS41LDIsMyw0LDVdfQ0KPiA+DQo+
ID4NCj4gPiAgNC4yLiBwdXQNCj4gPg0KPiA+ICAgIFRoZSAicHV0IiBvcGVyYXRpb24gcHV0cyBh
IG5ldyB2YWx1ZSBhdCB0aGUgdGFyZ2V0IGxvY2F0aW9uLA0KPiA+ICAgIHJlcGxhY2luZyBhbnkg
ZXhpc3RpbmcgdmFsdWUgaWYgdGhlcmUgaXMgb25lLiBUaGUgb3BlcmF0aW9uIG9iamVjdA0KPiA+
ICAgIE1VU1QgaW5jbHVkZSAicGF0aCIgYW5kICJ2YWx1ZSIgbWVtYmVycy4gInBhdGgiIGhvbGRz
IGEgSlNPTg0KPiBwb2ludGVyDQo+ID4gICAgdGhhdCBpZGVudGlmaWVzIHRoZSB0YXJnZXQgbG9j
YXRpb24sIHdoaWNoIGNhbiBiZSBhbiBvYmplY3QgbWVtYmVyDQo+ID4gICAgKHRoYXQgaXMgb3Ig
aXNuJ3QgcHJlc2VudCksIGFuIGFycmF5IGluZGV4ICh0aGF0IG11c3QgZXhpc3QpLCBvcg0KPiA+
ICAgIHRoZSB3aG9sZSB0YXJnZXQuICJ2YWx1ZSIgaG9sZHMgdGhlIHZhbHVlIHRvIGFkZCwgd2hp
Y2ggY2FuIGJlIGFueQ0KPiA+ICAgIEpTT04gdmFsdWUuDQo+ID4NCj4gPiAgICBFeGFtcGxlOg0K
PiA+ICAgIE9sZDogICB7Im4iOlsxLDIsM119DQo+ID4gICAgUGF0Y2g6IFt7Im9wIjoicHV0Iiwg
InBhdGgiOiIiLCAidmFsdWUiOlt0cnVlLCB7ImEiOjF9XX0sDQo+ID4gICAgICAgICAgICB7Im9w
IjoicHV0IiwgInBhdGgiOiIvMCIsICJ2YWx1ZSI6ZmFsc2V9LA0KPiA+ICAgICAgICAgICAgeyJv
cCI6InB1dCIsICJwYXRoIjoiLzEvYiIsICJ2YWx1ZSI6Mn0sDQo+ID4gICAgICAgICAgICB7Im9w
IjoicHV0IiwgInBhdGgiOiIvMS9hIiwgInZhbHVlIjozfV0NCj4gPiAgICBOZXc6ICAgW2ZhbHNl
LCB7ImEiOjMsICJiIjoyfV0NCj4gPg0KPiA+IC0tDQo+ID4gSmFtZXMgTWFuZ2VyDQo+ID4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBhcHBzLWRp
c2N1c3MgbWFpbGluZyBsaXN0DQo+ID4gYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+ID4gaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCj4gDQo+IC0tDQo+
IE1hcmsgTm90dGluZ2hhbSAgIGh0dHA6Ly93d3cubW5vdC5uZXQvDQo+IA0KPiANCg0K

From mnot@mnot.net  Sun Oct 14 17:39:57 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBE821F84EA for ; Sun, 14 Oct 2012 17:39:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.195
X-Spam-Level: 
X-Spam-Status: No, score=-104.195 tagged_above=-999 required=5 tests=[AWL=-1.596, 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 ZAC0nyBk1Q+x for ; Sun, 14 Oct 2012 17:39:56 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id A143B21F8498 for ; Sun, 14 Oct 2012 17:39:56 -0700 (PDT)
Received: from mnot-mini.mnot.net (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B68F222E255; Sun, 14 Oct 2012 20:39:48 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com>
Date: Mon, 15 Oct 2012 11:39:43 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net>
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com>
To: "Manger, James H" 
X-Mailer: Apple Mail (2.1499)
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2012 00:39:57 -0000

On 15/10/2012, at 11:37 AM, "Manger, James H" =
 wrote:

> Java uses:
> * "add" to insert a new item into a list (array),
> * "set" to replace a current item in a list (array), and
> * "put" to put a key/value pair in a map (object), regardless of =
whether or not the key already exists.
>=20
> Consequently, I don't think "set" is a good name for a json-patch =
operation if it provides the functionality of Java=92s "add", but not =
Java=92s "set".
>=20
> It would simplify spec & code to define 3 operations for json-patch, =
instead of trying to squeeze the functionality into two of these.

I'm *not* patterning anything I write after Java, thanks. Besides which, =
we're not talking about arrays here (although I did flirt with the idea =
of type-specific operators for a little while).


> /foo/-1
>=20
> I like the ability to indicate position in an array (or between array =
elements) from then end. I=92m not sure that extending JSON pointer is =
the right approach. Currently there is a unique pointer for every value. =
It would be a shame to lose that property.

What does keeping it give us?=20


>=20
> --
> James Manger
>=20
>=20
>> -----Original Message-----
>> From: Mark Nottingham [mailto:mnot@mnot.net]
>> Sent: Sunday, 14 October 2012 6:55 AM
>> To: Manger, James H
>> Cc: apps-discuss@ietf.org
>> Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
>>=20
>> There hasn't been a lot of discussion of this on-list, but based on a
>> few private exchanges and discussion elsewhere (e.g.,
>> ), I
>> think there is at least one problem worth solving here -- being able =
to
>> add items to arrays without knowing their current length.
>>=20
>> The suggestion is to add an 'index' attribute. I think that adds a =
lot
>> of complexity and corner cases, and wonder whether we couldn't =
achieve
>> the same thing by allowing negative indices on JSON Pointer; e.g.,
>>=20
>> /foo/-1
>>=20
>> to indicate the last member of the array (delta a discussion about
>> whether we base on -0 or -1).
>>=20
>> If folks are uncomfortable with that amount of complexity, I think we
>> could even meet the use case by doing something like
>>=20
>> /foo/-
>>=20
>> to indicate the last member of the array.
>>=20
>> Thoughts?
>>=20
>> Beyond that, there's a notion that we should relax certain =
requirements
>> so as to avoid making the client know the exact state of the resource
>> in every instance.
>>=20
>> I *think* we have agreement that this should be done for "add"  (by
>> removing the "MUST exist" requirement), but not elsewhere.
>>=20
>> Specifically:
>>=20
>>>   If the target location references the root of the target document
>> or
>>>   a member of an existing object, the specified location MUST
>> already
>>>   exist for the operation to be successful.
>>=20
>> ... and I note that our examples already seem to violate this
>> requirement, depending on how you read it, so *something* needs to
>> change.
>>=20
>> At the same time, it might be good to change the name; I'd suggest
>> "set".
>>=20
>> Make sense?
>>=20
>> Cheers,
>>=20
>>=20
>>=20
>> On 01/10/2012, at 3:22 PM, "Manger, James H"
>>  wrote:
>>=20
>>> RE: draft-ietf-appsawg-json-patch-05
>>>=20
>>> Suggestion: replace the "add" and "replace" operations with "insert"
>> and "put" operations that work without needing to know (ie be in sync
>> with) the old state of the JSON doc being changed. New text:
>>>=20
>>> 4.1. insert
>>>=20
>>>   The "insert" operation adds a new value to an array. The operation
>>>   object MUST include "path" and "value" members, and MAY include an
>>>   "i" member. "path" holds a JSON pointer that identifies an array.
>>>   "value" holds the value to add, which can be any JSON value.
>>>   "i" holds a number that is rounded to the nearest integer to give
>>>   the array index of the new value when inserted. If "i" is absent
>> the
>>>   value is appended to the array. Any items in the array at an index
>>>   equal to or greater than "i" are moved to the next higher index to
>>>   make room for the new value.
>>>=20
>>>   It is an error if "i" (rounded to the nearest integer) is less
>> than
>>>   0 or greater than the length of the array.
>>>=20
>>>   Example:
>>>   Old:   {"n":[1,2,3]}
>>>   Patch: [{"op":"insert", "path":"/n", "value":4},
>>>           {"op":"insert", "path":"/n", "value":5, "i":5},
>>>           {"op":"insert", "path":"/n", "value":1.5, "i":1}]
>>>   New:   {"n":[1,1.5,2,3,4,5]}
>>>=20
>>>=20
>>> 4.2. put
>>>=20
>>>   The "put" operation puts a new value at the target location,
>>>   replacing any existing value if there is one. The operation object
>>>   MUST include "path" and "value" members. "path" holds a JSON
>> pointer
>>>   that identifies the target location, which can be an object member
>>>   (that is or isn't present), an array index (that must exist), or
>>>   the whole target. "value" holds the value to add, which can be any
>>>   JSON value.
>>>=20
>>>   Example:
>>>   Old:   {"n":[1,2,3]}
>>>   Patch: [{"op":"put", "path":"", "value":[true, {"a":1}]},
>>>           {"op":"put", "path":"/0", "value":false},
>>>           {"op":"put", "path":"/1/b", "value":2},
>>>           {"op":"put", "path":"/1/a", "value":3}]
>>>   New:   [false, {"a":3, "b":2}]
>>>=20
>>> --
>>> James Manger
>>> _______________________________________________
>>> 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 James.H.Manger@team.telstra.com  Sun Oct 14 18:30:14 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAC021F8546 for ; Sun, 14 Oct 2012 18:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.865
X-Spam-Level: 
X-Spam-Status: No, score=-0.865 tagged_above=-999 required=5 tests=[AWL=0.036,  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 Gq4mBQIJgOa6 for ; Sun, 14 Oct 2012 18:30:14 -0700 (PDT)
Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id DE51721F8545 for ; Sun, 14 Oct 2012 18:30:13 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,586,1344175200"; d="scan'208";a="98852220"
Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 15 Oct 2012 12:30:12 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6865"; a="93747632"
Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipccvi.tcif.telstra.com.au with ESMTP; 15 Oct 2012 12:30:11 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Mon, 15 Oct 2012 12:30:11 +1100
From: "Manger, James H" 
To: Mark Nottingham 
Date: Mon, 15 Oct 2012 12:30:10 +1100
Thread-Topic: [apps-discuss] json-patch: "op":"insert" and "op":"put"
Thread-Index: Ac2qbae1qt71BOx1RNC7Z/J6IJkjRgAAMmVw
Message-ID: <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com>
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net>
In-Reply-To: <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2012 01:30:14 -0000

PiA+IEphdmEgdXNlczoNCj4gPiAqICJhZGQiIHRvIGluc2VydCBhIG5ldyBpdGVtIGludG8gYSBs
aXN0IChhcnJheSksDQo+ID4gKiAic2V0IiB0byByZXBsYWNlIGEgY3VycmVudCBpdGVtIGluIGEg
bGlzdCAoYXJyYXkpLCBhbmQNCj4gPiAqICJwdXQiIHRvIHB1dCBhIGtleS92YWx1ZSBwYWlyIGlu
IGEgbWFwIChvYmplY3QpLCByZWdhcmRsZXNzIG9mDQo+IHdoZXRoZXIgb3Igbm90IHRoZSBrZXkg
YWxyZWFkeSBleGlzdHMuDQo+ID4NCj4gPiBDb25zZXF1ZW50bHksIEkgZG9uJ3QgdGhpbmsgInNl
dCIgaXMgYSBnb29kIG5hbWUgZm9yIGEganNvbi1wYXRjaA0KPiBvcGVyYXRpb24gaWYgaXQgcHJv
dmlkZXMgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgSmF2YeKAmXMgImFkZCIsIGJ1dCBub3QNCj4gSmF2
YeKAmXMgInNldCIuDQo+ID4NCj4gPiBJdCB3b3VsZCBzaW1wbGlmeSBzcGVjICYgY29kZSB0byBk
ZWZpbmUgMyBvcGVyYXRpb25zIGZvciBqc29uLXBhdGNoLA0KPiBpbnN0ZWFkIG9mIHRyeWluZyB0
byBzcXVlZXplIHRoZSBmdW5jdGlvbmFsaXR5IGludG8gdHdvIG9mIHRoZXNlLg0KDQo+IEknbSAq
bm90KiBwYXR0ZXJuaW5nIGFueXRoaW5nIEkgd3JpdGUgYWZ0ZXIgSmF2YSwgdGhhbmtzLiBCZXNp
ZGVzDQo+IHdoaWNoLCB3ZSdyZSBub3QgdGFsa2luZyBhYm91dCBhcnJheXMgaGVyZSAoYWx0aG91
Z2ggSSBkaWQgZmxpcnQgd2l0aA0KPiB0aGUgaWRlYSBvZiB0eXBlLXNwZWNpZmljIG9wZXJhdG9y
cyBmb3IgYSBsaXR0bGUgd2hpbGUpLg0KDQpBcmVu4oCZdCB3ZSB0YWxraW5nIGFib3V0IGFycmF5
cz8NCg0KVGhlIG9iamVjdCBjYXNlIHNlZW1zIGNsZWFyOiBzZXQgYSBrZXkvdmFsdWUgcGFpciwg
cmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSBrZXkgd2FzIGFscmVhZHkgcHJlc2VudC4NCg0KVGhl
IGNob2ljZSBJIHNlZSBmb3Igb2JqZWN0cyBpcyB3aGV0aGVyIGFuIG9wZXJhdGlvbjoNCiogU2V0
cyAxIGtleS92YWx1ZSBwYWlyICgicGF0aCIgaWRzIHRoZSBrZXksICJ2YWx1ZSIgaXMgc2VwYXJh
dGUpOyBvcg0KKiBTZXRzIGFueSBudW1iZXIgb2YgcGFpcnMgKCJwYXRoIiBpZHMgdGhlIG9iamVj
dCwgInZhbHVlIiBpcyBhbiBvYmplY3Qgb2YgcGFpcnMgdG8gc2V0KS4NCltUaGUgMm5kIGNob2lj
ZSBsb29rcyBiZXR0ZXJdDQoNClRoZSBhcnJheSBjYXNlIGlzIHdoZXJlIGl0IGlzIGEgYml0IG1v
cmUgY29tcGxleC4gQWRkaW5nIGFuZCByZXBsYWNpbmcgYXJlIHF1aXRlIHNlcGFyYXRlLiBBZGRp
bmcgbmVlZHMgYSBnYXAsIGZyb20gdGhlIHN0YXJ0IG9yIGVuZDsgcmVwbGFjaW5nIG5lZWRzIGFu
IGluZGV4LCBmcm9tIHRoZSBzdGFydCBvciBlbmQuIEdhcHMgYW5kIGluZGljZXMgY2FuIG92ZXJm
bG93LiBSYW5nZXMgYWRkIG1vcmUgY29tcGxleGl0eS4NCg0KDQoNCj4gPiAvZm9vLy0xDQo+ID4N
Cj4gPiBJIGxpa2UgdGhlIGFiaWxpdHkgdG8gaW5kaWNhdGUgcG9zaXRpb24gaW4gYW4gYXJyYXkg
KG9yIGJldHdlZW4gYXJyYXkNCj4gZWxlbWVudHMpIGZyb20gdGhlbiBlbmQuIEnigJltIG5vdCBz
dXJlIHRoYXQgZXh0ZW5kaW5nIEpTT04gcG9pbnRlciBpcw0KPiB0aGUgcmlnaHQgYXBwcm9hY2gu
IEN1cnJlbnRseSB0aGVyZSBpcyBhIHVuaXF1ZSBwb2ludGVyIGZvciBldmVyeQ0KPiB2YWx1ZS4g
SXQgd291bGQgYmUgYSBzaGFtZSB0byBsb3NlIHRoYXQgcHJvcGVydHkuDQoNCj4gV2hhdCBkb2Vz
IGtlZXBpbmcgaXQgZ2l2ZSB1cz8NCg0KWW91IGNhbiBjb21wYXJlIDIgcG9pbnRlcnMgdG8gc2Vl
IGlmIHRoZXkgcG9pbnQgdG8gdGhlIHNhbWUgdGhpbmcgKHdpdGhvdXQgaGF2aW5nIHRvIHJlc29s
dmUgdGhlbSBmaXJzdCBhZ2FpbnN0IHRoZSBKU09OIGRvYyB0aGV5IHBvaW50IGF0KS4NCg0KLS0N
CkphbWVzIE1hbmdlcg0K

From andreas@sbin.se  Mon Oct 15 03:06:28 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD13D21F8623; Mon, 15 Oct 2012 03:06:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMPIjNpk4GI4; Mon, 15 Oct 2012 03:06:28 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 05D6C21F86DC; Mon, 15 Oct 2012 03:06:27 -0700 (PDT)
Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q9FA66Fi000312; Mon, 15 Oct 2012 10:06:07 GMT
Date: Mon, 15 Oct 2012 12:06:00 +0200
From: Andreas Petersson 
To: Barry Leiba 
Message-ID: <20121015120600.638f428e@hetzer>
In-Reply-To: 
References: <908A5670-8A38-4702-B801-B31BB756EA97@mnot.net> 
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/sotmSG1_OXdKdx.P1VLjF38"; protocol="application/pgp-signature"
Cc: Mark Nottingham , "iesg@ietf.org IESG" , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] Forwarded draft: registration policy
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 15 Oct 2012 10:06:29 -0000

--Sig_/sotmSG1_OXdKdx.P1VLjF38
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Sat, 13 Oct 2012 10:37:51 -0400
Barry Leiba  wrote:

> >
> > Draft -09 changed the registration policy for forwarded parameters:
> >
> > > The "Forwarded" header field contains parameters for which IANA is to
> > >    create and maintain a new registry entitled "HTTP Forwarded
> > >    parameters".  Initial registrations are given below; for future
> > >    assignments, the registration procedure to be used is IETF review
> > [RFC5226].
> >
> > 
> >
> > I *think* this change was based upon Stephen's comment:
>=20
>=20
> I believe you're correct.  Andreas can confirm that.  (And I'm explicitly
> adding Stephen to the CC list here, to be sure he sees and comments.)

After this draft was first discussed in the IESG, there was some
uncertainty whether this would go through at all.
Barry sent this e-mail to the apps-discuss list:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06907.html

It lead to some quite extensive discussion. To get to some result Barry
then sent this e-mail:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07056.html

The only concrete response (as far as I can remember) to this came from
Alissa.

One of her points was that she agrees with Stephen that "IETF review
seems more appropriate here".

My response to that was:


AP> I think this too much overhead. It will not stop people from doing
AP> stupid things, it will only stop implementors from specifying
AP> stuff, and the only effect will be less interoperability.
AP>
AP> As I understand it IETF review essentially requires a standards
AP> track RFC. [ note: I know now this assumption was wrong ]
AP>
AP> Can we make it "experts review" with one technical expert and one from
AP> say IESG security area that is explicitly instructed to look after the
AP> privacy issues?
AP> And require both persons to approve the specification.

Alissa asks Barry for an opinion, and the following response from Barry
was what made me change the procedure:

B> I think IETF Review is probably best here, because of the
B> controversy.
B> I actually like Andreas's two-level review idea, but IANA won't like
B> it.  And it's probably best not to have external SDOs and Independent
B> Stream docs doing registrations for this.  Let's go back to IETF
B> Review.

My personal opinion is that "specification required" would be enough,
especially considered Mark's point about it then would require more to
register a parameter for "Forwarded" than an entirely new header field.
However... at some point we have to settle for something.

Best regards,
 Andreas

--Sig_/sotmSG1_OXdKdx.P1VLjF38
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJQe+AIAAoJEEaYRbQUWNleAxEQANJ2VcDrdJ8oLZoddDC4DBY5
3qwk/YzJj3rFxKhryq1AhiQ352bLMlBz/zeYlbUHkzdx+4+85LnaZKRDAwp7/tqs
F4nLC6lzDhH8qobv///oPZIA7/rBtc1lEM9hnO/vCbWoj4G1IsyV/emxwLSj0CAR
L4r3O9LpgiYu/Y1eIQVf/QGZPZe5ihXoXkvXJ0sfxXWrEFlIxwh1HMh4SWgcrXb2
F7stVbG+4i3fU1EddFvaDx/w8i+gVj5tH7ICz0eXXwKXXGCY9WmI5t3Qsjqxop0c
XxIb2VALDamwOmm8t7o7P2NcipVFZdDMqda8On/Sa1WnF8GAKjCcOFimi+4bOjmS
W6EGY5EWhAC8xqF1cKOe7jecK29w1C06emPqLu0h9dwpXLXEPDzZ8bVNFibaS+gQ
sAKOlK7RmkVfmhkuNJbfx4/P5OAtiDP+Ot3e6WAmH93zjwNuPwjgmSzT5zS39NF1
I+FOnqExtXp2b6iWPltGA14wD5liH2JIBqDMDz1lVD2qvuziXq3gL9o7PzhV93es
WHEfqN9lsuJUG3fTs5ZKIn/b1VgwKfNz/cK5i24ougdHSF3u5LqwdSIJQB/KF+L1
sElRGL59iU6I2J1IzgPwxk/vrttyJWBuPdnE0+n54l0s9aysDGD+IRPUaWPfp9qZ
XAzCQbo9yj3gfULdEYAX
=I4hU
-----END PGP SIGNATURE-----

--Sig_/sotmSG1_OXdKdx.P1VLjF38--

From pbryan@anode.ca  Mon Oct 15 09:32:04 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE5121F8736 for ; Mon, 15 Oct 2012 09:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igdzwsvxvVl3 for ; Mon, 15 Oct 2012 09:32:00 -0700 (PDT)
Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 0155021F8733 for ; Mon, 15 Oct 2012 09:31:59 -0700 (PDT)
Received: from [10.126.22.51] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id C77E16746; Mon, 15 Oct 2012 16:31:58 +0000 (UTC)
From: "Paul C. Bryan" 
To: Mark Nottingham 
In-Reply-To: 
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com> 
Content-Type: multipart/alternative; boundary="=-q/BGrsrHrw2uudDh4+4r"
Date: Mon, 15 Oct 2012 09:31:54 -0700
Message-ID: <1350318714.19167.7.camel@pbryan-wsl.internal.salesforce.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2012 16:32:04 -0000

--=-q/BGrsrHrw2uudDh4+4r
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On Sun, 2012-10-14 at 06:55 +1100, Mark Nottingham wrote:

> There hasn't been a lot of discussion of this on-list, but based on a
> few private exchanges and discussion elsewhere (e.g.,
> ), I
> think there is at least one problem worth solving here -- being able
> to add items to arrays without knowing their current length.
> 
> The suggestion is to add an 'index' attribute. I think that adds a lot
> of complexity and corner cases, and wonder whether we couldn't achieve
> the same thing by allowing negative indices on JSON Pointer; e.g.,
> 
> /foo/-1
> 
> to indicate the last member of the array (delta a discussion about
> whether we base on -0 or -1).
> 
> If folks are uncomfortable with that amount of complexity, I think we
> could even meet the use case by doing something like
> 
> /foo/-
> 
> to indicate the last member of the array.
> 
> Thoughts?


I'm fine with this. I would prefer /foo/-1 over /foo/-.


> Beyond that, there's a notion that we should relax certain
> requirements so as to avoid making the client know the exact state of
> the resource in every instance.
> 
> I *think* we have agreement that this should be done for "add"  (by
> removing the "MUST exist" requirement), but not elsewhere.


+1

> 
> Specifically:
> 
> >    If the target location references the root of the target document
> or
> >    a member of an existing object, the specified location MUST
> already
> >    exist for the operation to be successful.
> 
> ... and I note that our examples already seem to violate this
> requirement, depending on how you read it, so *something* needs to
> change.
> 
> At the same time, it might be good to change the name; I'd suggest
> "set".


+1

Paul

--=-q/BGrsrHrw2uudDh4+4r
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


On Sun, 2012-10-14 at 06:55 +1100, Mark Nottingham wrote:



    There hasn't been a lot of discussion of this on-list, but based on a few private exchanges and discussion elsewhere (e.g., <http://www.ietf.org/mail-archive/web/scim/current/msg00744.html>), I think there is at least one problem worth solving here -- being able to add items to arrays without knowing their current length.

    

    The suggestion is to add an 'index' attribute. I think that adds a lot of complexity and corner cases, and wonder whether we couldn't achieve the same thing by allowing negative indices on JSON Pointer; e.g.,

    

    /foo/-1

    

    to indicate the last member of the array (delta a discussion about whether we base on -0 or -1).

    

    If folks are uncomfortable with that amount of complexity, I think we could even meet the use case by doing something like

    

    /foo/-

    

    to indicate the last member of the array.

    

    Thoughts?





I'm fine with this. I would prefer /foo/-1 over /foo/-.





    Beyond that, there's a notion that we should relax certain requirements so as to avoid making the client know the exact state of the resource in every instance.

    

    I *think* we have agreement that this should be done for "add"  (by removing the "MUST exist" requirement), but not elsewhere.





+1



    

    Specifically:

    

    >    If the target location references the root of the target document or

    >    a member of an existing object, the specified location MUST already

    >    exist for the operation to be successful.

    

    ... and I note that our examples already seem to violate this requirement, depending on how you read it, so *something* needs to change.

    

    At the same time, it might be good to change the name; I'd suggest "set".





+1



Paul



--=-q/BGrsrHrw2uudDh4+4r--


From pbryan@anode.ca  Mon Oct 15 09:37:13 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B9021F8759 for ; Mon, 15 Oct 2012 09:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWyZb2l6M-nO for ; Mon, 15 Oct 2012 09:37:11 -0700 (PDT)
Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id AC0CC21F86F9 for ; Mon, 15 Oct 2012 09:37:11 -0700 (PDT)
Received: from [10.126.22.51] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id E6D346746; Mon, 15 Oct 2012 16:37:10 +0000 (UTC)
From: "Paul C. Bryan" 
To: "Manger, James H" 
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com>
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com>
Content-Type: multipart/alternative; boundary="=-Wuu1tezwnDIEG/thVovh"
Date: Mon, 15 Oct 2012 09:37:10 -0700
Message-ID: <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: Mark Nottingham , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2012 16:37:13 -0000

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

On Mon, 2012-10-15 at 12:30 +1100, Manger, James H wrote:

> > > Java uses:
> > > * "add" to insert a new item into a list (array),
> > > * "set" to replace a current item in a list (array), and
> > > * "put" to put a key/value pair in a map (object), regardless of
> > whether or not the key already exists.
> > >
> > > Consequently, I don't think "set" is a good name for a json-patch
> > operation if it provides the functionality of Java’s "add", but not
> > Java’s "set".
> > >
> > > It would simplify spec & code to define 3 operations for
> json-patch,
> > instead of trying to squeeze the functionality into two of these.
> 
> > I'm *not* patterning anything I write after Java, thanks. Besides
> > which, we're not talking about arrays here (although I did flirt
> with
> > the idea of type-specific operators for a little while).
> 
> Aren’t we talking about arrays?


No, at this point, we're talking about values, which can exist within
arrays or objects.


> The object case seems clear: set a key/value pair, regardless of
> whether the key was already present.
> 
> The choice I see for objects is whether an operation:
> * Sets 1 key/value pair ("path" ids the key, "value" is separate); or
> * Sets any number of pairs ("path" ids the object, "value" is an
> object of pairs to set).
> [The 2nd choice looks better]
> 
> The array case is where it is a bit more complex. Adding and replacing
> are quite separate. Adding needs a gap, from the start or end;
> replacing needs an index, from the start or end. Gaps and indices can
> overflow. Ranges add more complexity.


This does raise the issue of attempting to set an array element outside
the current range of values (i.e. sparse allocation).


> > > /foo/-1
> > >
> > > I like the ability to indicate position in an array (or between
> array
> > elements) from then end. I’m not sure that extending JSON pointer is
> > the right approach. Currently there is a unique pointer for every
> > value. It would be a shame to lose that property.
> 
> > What does keeping it give us?
> 
> You can compare 2 pointers to see if they point to the same thing
> (without having to resolve them first against the JSON doc they point
> at).


And what does that give us?

Paul


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




  
  


On Mon, 2012-10-15 at 12:30 +1100, Manger, James H wrote:



    > > Java uses:

    > > * "add" to insert a new item into a list (array),

    > > * "set" to replace a current item in a list (array), and

    > > * "put" to put a key/value pair in a map (object), regardless of

    > whether or not the key already exists.

    > >

    > > Consequently, I don't think "set" is a good name for a json-patch

    > operation if it provides the functionality of Java’s "add", but not

    > Java’s "set".

    > >

    > > It would simplify spec & code to define 3 operations for json-patch,

    > instead of trying to squeeze the functionality into two of these.

    

    > I'm *not* patterning anything I write after Java, thanks. Besides

    > which, we're not talking about arrays here (although I did flirt with

    > the idea of type-specific operators for a little while).

    

    Aren’t we talking about arrays?





No, at this point, we're talking about values, which can exist within arrays or objects.





    The object case seems clear: set a key/value pair, regardless of whether the key was already present.

    

    The choice I see for objects is whether an operation:

    * Sets 1 key/value pair ("path" ids the key, "value" is separate); or

    * Sets any number of pairs ("path" ids the object, "value" is an object of pairs to set).

    [The 2nd choice looks better]

    

    The array case is where it is a bit more complex. Adding and replacing are quite separate. Adding needs a gap, from the start or end; replacing needs an index, from the start or end. Gaps and indices can overflow. Ranges add more complexity.





This does raise the issue of attempting to set an array element outside the current range of values (i.e. sparse allocation).





    > > /foo/-1

    > >

    > > I like the ability to indicate position in an array (or between array

    > elements) from then end. I’m not sure that extending JSON pointer is

    > the right approach. Currently there is a unique pointer for every

    > value. It would be a shame to lose that property.

    

    > What does keeping it give us?

    

    You can compare 2 pointers to see if they point to the same thing (without having to resolve them first against the JSON doc they point at).





And what does that give us?



Paul






--=-Wuu1tezwnDIEG/thVovh--


From mccabe@archive.org  Mon Oct 15 13:09:52 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDAC21F8991 for ; Mon, 15 Oct 2012 13:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJG582ErCqPu for ; Mon, 15 Oct 2012 13:09:51 -0700 (PDT)
Received: from mail.archive.org (mail.us.archive.org [207.241.224.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7DADD21F8990 for ; Mon, 15 Oct 2012 13:09:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.archive.org (Postfix) with ESMTP id EF08A6840170; Mon, 15 Oct 2012 13:09:50 -0700 (PDT)
Received: from mail.archive.org ([127.0.0.1]) by localhost (mail.archive.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WjkYvsfUaBhe; Mon, 15 Oct 2012 13:09:49 -0700 (PDT)
Received: from mikemac-2.local (router300.sf.archive.org [208.70.27.190]) by mail.archive.org (Postfix) with ESMTPSA id B0DEC6840147; Mon, 15 Oct 2012 13:09:49 -0700 (PDT)
Message-ID: <507C6D8D.8070109@archive.org>
Date: Mon, 15 Oct 2012 13:09:49 -0700
From: Mike McCabe 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com> <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com>
In-Reply-To: <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2012 20:09:52 -0000

All -

I'm glad to see this subject discussed.

In discussions about json-patch at my organization, both of these 
requests - unconditional set, and list append -  have come up.

Some users would like to be able to make changes to data without prior 
knowledge of it's exact state ahead of time.

(It's worth mentioning that another use of json-patch in our 
organization is to replace a system with strictly versioned updates, in 
which race conditions and inconsistent data aren't tolerated.  Both 
needs exist, and I think both can be served by json-patch.)

In practice, the lack of safe unconditional sets and appends has led me 
to recommend that internal users generate their patches by getting the 
old document, making changes to a copy, and using an automated diff() 
function to compare old and new, rather than free-coding checks.  This 
will probably always be the most robust way to specify arbitrary 
changes, but there are many uses where an unconditional set or append 
would be simpler.


On to opinions...

* I think there's room for a new op alongside the current 'add' op 
semantics.  I propose 'set' - exactly like 'add', but not throwing an 
error if the value already exists.  For lists, it could work like 
'replace', but could still append.  The existing 'add' semantics remain 
useful for 'transactional' uses of json-patch.

* I also like negative index notation.  It's use is well established in 
javascript (as an array slice() argument), in python and in other 
languages.  There it means 'add the length of the list to the negative 
index to get the offset' - thus -1 indicates the last element, not the 
slot after.  For this reason, if we add negative indices, I think we 
should use -0 to append.  (In fact, a co-worker came up with exactly 
this notation some weeks ago.)

* I'm skeptical of proposals that call for 'opening up' value arguments, 
to merge them into the target value or otherwise.  What if it's an 
array?  What if it's something else?  I think this would lose the 
current generality of allowing arbitrary json in the value field, and 
would make json-patch harder to reason about - and harder to specify!


I'm otherwise very happy with json-patch - I was casting around for a 
json language to describe data deltas when I found it, and it exactly
fits the bill.  We're still in internal testing of json-patch, but it 
will soon be part of the preferred public API for modifying Internet 
Archive item metadata.


Best regards,
Mike McCabe



On 10/15/12 9:37 AM, Paul C. Bryan wrote:
> On Mon, 2012-10-15 at 12:30 +1100, Manger, James H wrote:
>> > > Java uses:
>> > > * "add" to insert a new item into a list (array),
>> > > * "set" to replace a current item in a list (array), and
>> > > * "put" to put a key/value pair in a map (object), regardless of
>> > whether or not the key already exists.
>> > >
>> > > Consequently, I don't think "set" is a good name for a json-patch
>> > operation if it provides the functionality of Java’s "add", but not
>> > Java’s "set".
>> > >
>> > > It would simplify spec & code to define 3 operations for json-patch,
>> > instead of trying to squeeze the functionality into two of these.
>>
>> > I'm *not* patterning anything I write after Java, thanks. Besides
>> > which, we're not talking about arrays here (although I did flirt with
>> > the idea of type-specific operators for a little while).
>>
>> Aren’t we talking about arrays?
>
> No, at this point, we're talking about values, which can exist within
> arrays or objects.
>
>> The object case seems clear: set a key/value pair, regardless of
>> whether the key was already present.
>>
>> The choice I see for objects is whether an operation:
>> * Sets 1 key/value pair ("path" ids the key, "value" is separate); or
>> * Sets any number of pairs ("path" ids the object, "value" is an
>> object of pairs to set).
>> [The 2nd choice looks better]
>>
>> The array case is where it is a bit more complex. Adding and replacing
>> are quite separate. Adding needs a gap, from the start or end;
>> replacing needs an index, from the start or end. Gaps and indices can
>> overflow. Ranges add more complexity.
>
> This does raise the issue of attempting to set an array element outside
> the current range of values (i.e. sparse allocation).
>
>> > > /foo/-1
>> > >
>> > > I like the ability to indicate position in an array (or between array
>> > elements) from then end. I’m not sure that extending JSON pointer is
>> > the right approach. Currently there is a unique pointer for every
>> > value. It would be a shame to lose that property.
>>
>> > What does keeping it give us?
>>
>> You can compare 2 pointers to see if they point to the same thing
>> (without having to resolve them first against the JSON doc they point at).
>
> And what does that give us?
>
> Paul
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From James.H.Manger@team.telstra.com  Mon Oct 15 20:48:38 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5731F0CA0 for ; Mon, 15 Oct 2012 20:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.867
X-Spam-Level: 
X-Spam-Status: No, score=-0.867 tagged_above=-999 required=5 tests=[AWL=0.034,  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 rIFS6uYtQFV8 for ; Mon, 15 Oct 2012 20:48:38 -0700 (PDT)
Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 6E02E1F0C9C for ; Mon, 15 Oct 2012 20:48:37 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,593,1344175200"; d="scan'208";a="96818556"
Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 16 Oct 2012 14:48:36 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6866"; a="42932293"
Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcani.tcif.telstra.com.au with ESMTP; 16 Oct 2012 14:48:36 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Tue, 16 Oct 2012 14:48:36 +1100
From: "Manger, James H" 
To: "apps-discuss@ietf.org" 
Date: Tue, 16 Oct 2012 14:48:34 +1100
Thread-Topic: [apps-discuss] json-patch: "op":"insert" and "op":"put"
Thread-Index: Ac2rEmCEwPPkGg1pTyqm2nvu5TiPJAAJmX+Q
Message-ID: <255B9BB34FB7D647A506DC292726F6E114FDCF0C2D@WSMSG3153V.srv.dir.telstra.com>
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com> <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com>
In-Reply-To: <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Mark Nottingham 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2012 03:48:38 -0000

PiAqIEkgdGhpbmsgdGhlcmUncyByb29tIGZvciBhIG5ldyBvcCBhbG9uZ3NpZGUgdGhlIGN1cnJl
bnQgJ2FkZCcgb3ANCj4gc2VtYW50aWNzLiAgSSBwcm9wb3NlICdzZXQnIC0gZXhhY3RseSBsaWtl
ICdhZGQnLCBidXQgbm90IHRocm93aW5nIGFuDQo+IGVycm9yIGlmIHRoZSB2YWx1ZSBhbHJlYWR5
IGV4aXN0cy4gIEZvciBsaXN0cywgaXQgY291bGQgd29yayBsaWtlDQo+ICdyZXBsYWNlJywgYnV0
IGNvdWxkIHN0aWxsIGFwcGVuZC4gIFRoZSBleGlzdGluZyAnYWRkJyBzZW1hbnRpY3MgcmVtYWlu
DQo+IHVzZWZ1bCBmb3IgJ3RyYW5zYWN0aW9uYWwnIHVzZXMgb2YganNvbi1wYXRjaC4NCg0KVXNp
bmcgdGhlIGRlZGljYXRlZCAidGVzdCIgb3BlcmF0aW9uIGlzIGJldHRlciB0aGFuIGR1cGxpY2F0
aW5nIGFuIG9wLg0KDQoNCj4gKiBJIGFsc28gbGlrZSBuZWdhdGl2ZSBpbmRleCBub3RhdGlvbi4g
IEl0J3MgdXNlIGlzIHdlbGwgZXN0YWJsaXNoZWQgaW4NCj4gamF2YXNjcmlwdCAoYXMgYW4gYXJy
YXkgc2xpY2UoKSBhcmd1bWVudCksIGluIHB5dGhvbiBhbmQgaW4gb3RoZXINCj4gbGFuZ3VhZ2Vz
LiAgVGhlcmUgaXQgbWVhbnMgJ2FkZCB0aGUgbGVuZ3RoIG9mIHRoZSBsaXN0IHRvIHRoZSBuZWdh
dGl2ZQ0KPiBpbmRleCB0byBnZXQgdGhlIG9mZnNldCcgLSB0aHVzIC0xIGluZGljYXRlcyB0aGUg
bGFzdCBlbGVtZW50LCBub3QgdGhlDQo+IHNsb3QgYWZ0ZXIuICBGb3IgdGhpcyByZWFzb24sIGlm
IHdlIGFkZCBuZWdhdGl2ZSBpbmRpY2VzLCBJIHRoaW5rIHdlDQo+IHNob3VsZCB1c2UgLTAgdG8g
YXBwZW5kLiAgKEluIGZhY3QsIGEgY28td29ya2VyIGNhbWUgdXAgd2l0aCBleGFjdGx5DQo+IHRo
aXMgbm90YXRpb24gc29tZSB3ZWVrcyBhZ28uKQ0KDQoiLTAiIGp1c3QgZmVlbHMgYSBiaXQgc3Ry
YW5nZSBmb3IgYSBjb21tb24gY2FzZSDigJQgYXBwZW5kaW5nIHRvIHRoZSBlbmQg4oCUDQpidXQg
dGhhdCBpcyBhIG1pbm9yIGNvbXBsYWludC4NCg0KDQo+ICogSSdtIHNrZXB0aWNhbCBvZiBwcm9w
b3NhbHMgdGhhdCBjYWxsIGZvciAnb3BlbmluZyB1cCcgdmFsdWUNCj4gYXJndW1lbnRzLCB0byBt
ZXJnZSB0aGVtIGludG8gdGhlIHRhcmdldCB2YWx1ZSBvciBvdGhlcndpc2UuICBXaGF0IGlmDQo+
IGl0J3MgYW4gYXJyYXk/ICBXaGF0IGlmIGl0J3Mgc29tZXRoaW5nIGVsc2U/ICBJIHRoaW5rIHRo
aXMgd291bGQgbG9zZQ0KPiB0aGUgY3VycmVudCBnZW5lcmFsaXR5IG9mIGFsbG93aW5nIGFyYml0
cmFyeSBqc29uIGluIHRoZSB2YWx1ZSBmaWVsZCwNCj4gYW5kIHdvdWxkIG1ha2UganNvbi1wYXRj
aCBoYXJkZXIgdG8gcmVhc29uIGFib3V0IC0gYW5kIGhhcmRlciB0bw0KPiBzcGVjaWZ5IQ0KDQpX
aGljaCBpcyBlYXNpZXIgdG8gcmVhc29uIGFib3V0Og0KIHsib3AiOiJhZGQiLCAicGF0aCI6Ii9h
L2IvYy9kL2UvbmFtZSIsICJ2YWx1ZSI6ImZyZWQifSwNCiB7Im9wIjoiYWRkIiwgInBhdGgiOiIv
YS9iL2MvZC9lL2FnZSIsICJ2YWx1ZSI6NDJ9LA0KIHsib3AiOiJhZGQiLCAicGF0aCI6Ii9hL2Iv
Yy9kL2UvZm9vIiwgInZhbHVlIjp7IngiOjEsICJ5IjotMn19LA0KT3INCiB7Im9wIjoicHV0Iiwg
InBhdGgiOiIvYS9iL2MvZC9lIiwgInZhbHVlIjp7DQogICAgIm5hbWUiOiJmcmVkIiwNCiAgICAi
YWdlIjo0MiwNCiAgICAiZm9vIjp7IngiOjEsICJ5IjotMn0NCiB9fSwNCkkgdGhpbmsgdGhlIGxh
dHRlciBpcyBlYXNpZXIgdG8gcmVhZCwgd3JpdGUsIGFuZCB1bmRlcnN0YW5kLg0KW2NoYW5nZSAi
dmFsdWUiIHRvICJvYmoiIGFuZC9vciAicHV0IiB0byAibWVyZ2UiIGlmIGl0IGhlbHBzDQogY2xh
cmlmeSB0aGlzIG9iamVjdC1zcGVjaWZpYyBvcGVyYXRpb25dDQpJdCBhbHNvIG1pdGlnYXRlcyB0
aGUgYW5ub3lhbmNlIG9mIGhhdmluZyB0byByZXBlYXQgYSBwb3RlbnRpYWxseSBsb25nDQpwb2lu
dGVyIGluIHRoZSBjb21tb24gY2FzZSBvZiBhZGRpbmcgYSBidW5jaCBvZiBlbGVtZW50cyB0byBh
biBvYmplY3QuDQoNCkl0IG1pZ2h0IGFsc28gcmVkdWNlIGEgbGlrZWx5IGNvbW1vbiB0eXBvIG9m
IGZvcmdldHRpbmcgdGhlIGxlYWRpbmcgIi8iLg0KU2F5aW5nICAgICAgIHsib3AiOiJhZGQiLCAi
cGF0aCI6Im5hbWUiLCAidmFsdWUiOiJmcmVkIn0NCkluc3RlYWQgb2YgICB7Im9wIjoiYWRkIiwg
InBhdGgiOiIvbmFtZSIsICJ2YWx1ZSI6ImZyZWQifQ0KDQoNCj4+Pj4gSSBsaWtlIHRoZSBhYmls
aXR5IHRvIGluZGljYXRlIHBvc2l0aW9uIGluIGFuIGFycmF5IChvciBiZXR3ZWVuIGFycmF5DQo+
Pj4+IGVsZW1lbnRzKSBmcm9tIHRoZW4gZW5kLiBJ4oCZbSBub3Qgc3VyZSB0aGF0IGV4dGVuZGlu
ZyBKU09OIHBvaW50ZXIgaXMNCj4+Pj4gdGhlIHJpZ2h0IGFwcHJvYWNoLiBDdXJyZW50bHkgdGhl
cmUgaXMgYSB1bmlxdWUgcG9pbnRlciBmb3IgZXZlcnkNCj4+Pj4gdmFsdWUuIEl0IHdvdWxkIGJl
IGEgc2hhbWUgdG8gbG9zZSB0aGF0IHByb3BlcnR5Lg0KDQo+Pj4gV2hhdCBkb2VzIGtlZXBpbmcg
aXQgZ2l2ZSB1cz8NCg0KPj4gWW91IGNhbiBjb21wYXJlIDIgcG9pbnRlcnMgdG8gc2VlIGlmIHRo
ZXkgcG9pbnQgdG8gdGhlIHNhbWUgdGhpbmcgKHdpdGhvdXQgaGF2aW5nIHRvIHJlc29sdmUgdGhl
bSBmaXJzdCBhZ2FpbnN0IHRoZSBKU09OIGRvYyB0aGV5IHBvaW50IGF0KS4NCg0KPiBBbmQgd2hh
dCBkb2VzIHRoYXQgZ2l2ZSB1cz8NCg0KUGVyaGFwcyBub3QgbXVjaCBpbiBhIHBhdGNoIGZvcm1h
dCwgYnV0IEpTT04gcG9pbnRlciB3aWxsIGJlIHVzZWQNCm1vcmUgd2lkZWx5LiBGb3IgZXhhbXBs
ZSBhIHVuaXF1ZSBwb2ludGVyIG1heSBiZSBzdWl0YWJsZSBmb3IgYW4gYWNjZXNzDQpjb250cm9s
IGxpc3QgaW5kaWNhdGluZyB3aGljaCBwYXJ0cyBvZiBhIEpTT04gZG9jIGFyZSBwcml2YXRlLg0K
DQotLQ0KSmFtZXMgTWFuZ2VyDQo=

From pbryan@anode.ca  Tue Oct 16 09:00:22 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6140421F89FD for ; Tue, 16 Oct 2012 09:00:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDDsmtQ+11ts for ; Tue, 16 Oct 2012 09:00:15 -0700 (PDT)
Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 38E1721F89F2 for ; Tue, 16 Oct 2012 09:00:13 -0700 (PDT)
Received: from [10.126.22.51] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 30D3A6452; Tue, 16 Oct 2012 16:00:12 +0000 (UTC)
From: "Paul C. Bryan" 
To: "Manger, James H" 
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FDCF0C2D@WSMSG3153V.srv.dir.telstra.com>
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com> <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114FDCF0C2D@WSMSG3153V.srv.dir.telstra.com>
Content-Type: multipart/alternative; boundary="=-V4KQgGiwvf/TAHB4YLQH"
Date: Tue, 16 Oct 2012 09:00:07 -0700
Message-ID: <1350403207.2540.1.camel@pbryan-wsl.internal.salesforce.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: Mark Nottingham , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2012 16:00:22 -0000

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

On Tue, 2012-10-16 at 14:48 +1100, Manger, James H wrote:

> > * I think there's room for a new op alongside the current 'add' op
> > semantics.  I propose 'set' - exactly like 'add', but not throwing an
> > error if the value already exists.  For lists, it could work like
> > 'replace', but could still append.  The existing 'add' semantics remain
> > useful for 'transactional' uses of json-patch.
> 
> Using the dedicated "test" operation is better than duplicating an op.


+1. If you want to guarantee the state of (some part of) the document,
test should be the way to do it.

> 
> > * I also like negative index notation.  It's use is well established in
> > javascript (as an array slice() argument), in python and in other
> > languages.  There it means 'add the length of the list to the negative
> > index to get the offset' - thus -1 indicates the last element, not the
> > slot after.  For this reason, if we add negative indices, I think we
> > should use -0 to append.  (In fact, a co-worker came up with exactly
> > this notation some weeks ago.)
> 
> "-0" just feels a bit strange for a common case — appending to the end —
> but that is a minor complaint.
> 
> 
> > * I'm skeptical of proposals that call for 'opening up' value
> > arguments, to merge them into the target value or otherwise.  What if
> > it's an array?  What if it's something else?  I think this would lose
> > the current generality of allowing arbitrary json in the value field,
> > and would make json-patch harder to reason about - and harder to
> > specify!	
> 
> Which is easier to reason about:
>  {"op":"add", "path":"/a/b/c/d/e/name", "value":"fred"},
>  {"op":"add", "path":"/a/b/c/d/e/age", "value":42},
>  {"op":"add", "path":"/a/b/c/d/e/foo", "value":{"x":1, "y":-2}},
> Or
>  {"op":"put", "path":"/a/b/c/d/e", "value":{
>     "name":"fred",
>     "age":42,
>     "foo":{"x":1, "y":-2}
>  }},
> I think the latter is easier to read, write, and understand.
> [change "value" to "obj" and/or "put" to "merge" if it helps
>  clarify this object-specific operation]
> It also mitigates the annoyance of having to repeat a potentially long
> pointer in the common case of adding a bunch of elements to an object.
> 
> It might also reduce a likely common typo of forgetting the leading "/".
> Saying       {"op":"add", "path":"name", "value":"fred"}
> Instead of   {"op":"add", "path":"/name", "value":"fred"}
> 
> 
> >>>> I like the ability to indicate position in an array (or between array
> >>>> elements) from then end. I’m not sure that extending JSON pointer is
> >>>> the right approach. Currently there is a unique pointer for every
> >>>> value. It would be a shame to lose that property.
> 
> >>> What does keeping it give us?
> 
> >> You can compare 2 pointers to see if they point to the same thing (without having to resolve them first against the JSON doc they point at).
> 
> > And what does that give us?
> 
> Perhaps not much in a patch format, but JSON pointer will be used
> more widely. For example a unique pointer may be suitable for an access
> control list indicating which parts of a JSON doc are private.


I wouldn't want to bake -1 into json-pointer. I think it should remain
in json-patch.

Paul

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




  
  


On Tue, 2012-10-16 at 14:48 +1100, Manger, James H wrote:



> * I think there's room for a new op alongside the current 'add' op
> semantics.  I propose 'set' - exactly like 'add', but not throwing an
> error if the value already exists.  For lists, it could work like
> 'replace', but could still append.  The existing 'add' semantics remain
> useful for 'transactional' uses of json-patch.

Using the dedicated "test" operation is better than duplicating an op.






+1. If you want to guarantee the state of (some part of) the document, test should be the way to do it.




> * I also like negative index notation.  It's use is well established in
> javascript (as an array slice() argument), in python and in other
> languages.  There it means 'add the length of the list to the negative
> index to get the offset' - thus -1 indicates the last element, not the
> slot after.  For this reason, if we add negative indices, I think we
> should use -0 to append.  (In fact, a co-worker came up with exactly
> this notation some weeks ago.)

"-0" just feels a bit strange for a common case — appending to the end —
but that is a minor complaint.


> * I'm skeptical of proposals that call for 'opening up' value
> arguments, to merge them into the target value or otherwise.  What if
> it's an array?  What if it's something else?  I think this would lose
> the current generality of allowing arbitrary json in the value field,
> and would make json-patch harder to reason about - and harder to
> specify!	

Which is easier to reason about:
 {"op":"add", "path":"/a/b/c/d/e/name", "value":"fred"},
 {"op":"add", "path":"/a/b/c/d/e/age", "value":42},
 {"op":"add", "path":"/a/b/c/d/e/foo", "value":{"x":1, "y":-2}},
Or
 {"op":"put", "path":"/a/b/c/d/e", "value":{
    "name":"fred",
    "age":42,
    "foo":{"x":1, "y":-2}
 }},
I think the latter is easier to read, write, and understand.
[change "value" to "obj" and/or "put" to "merge" if it helps
 clarify this object-specific operation]
It also mitigates the annoyance of having to repeat a potentially long
pointer in the common case of adding a bunch of elements to an object.

It might also reduce a likely common typo of forgetting the leading "/".
Saying       {"op":"add", "path":"name", "value":"fred"}
Instead of   {"op":"add", "path":"/name", "value":"fred"}


>>>> I like the ability to indicate position in an array (or between array
>>>> elements) from then end. I’m not sure that extending JSON pointer is
>>>> the right approach. Currently there is a unique pointer for every
>>>> value. It would be a shame to lose that property.

>>> What does keeping it give us?

>> You can compare 2 pointers to see if they point to the same thing (without having to resolve them first against the JSON doc they point at).

> And what does that give us?

Perhaps not much in a patch format, but JSON pointer will be used
more widely. For example a unique pointer may be suitable for an access
control list indicating which parts of a JSON doc are private.






I wouldn't want to bake -1 into json-pointer. I think it should remain in json-patch.



Paul



--=-V4KQgGiwvf/TAHB4YLQH--


From jasnell@gmail.com  Tue Oct 16 09:57:57 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF5A21F8A68 for ; Tue, 16 Oct 2012 09:57:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.751
X-Spam-Level: 
X-Spam-Status: No, score=-4.751 tagged_above=-999 required=5 tests=[AWL=-1.153, 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 d3y08cCtXSnE for ; Tue, 16 Oct 2012 09:57:56 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C35AB21F8A65 for ; Tue, 16 Oct 2012 09:57:56 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id s14so5912526qcg.31 for ; Tue, 16 Oct 2012 09:57:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eWV8lNVCt4PrMSWD1emErWTOmdB6ZYyVC8ARvJM/Kgc=; b=qBGw/EpovyWrkWXuTDSf1uh/MFnH92aJ7nUKufcGk/zVbUgGozinnzn3lG9H+jieg/ ZwP6HxsVPRSZSN2SIYSQTbDXvMxDZyU6u6jjLt5K2OpBG61tAkMr6T9Gmqiw9YV3ORXm NWna9+hMeXO2pk8tCbEBZtp1STHYAxWiOT0j8v9nnrqS8rGhhuov8PCmfjHdR6Hji9AR /3ui4uUQLWD78vyOqsvPGv0arjIWsAa/FoW5MMUoVm8ZGMOdzQbd9B64xJnSuGCFhxC3 a8FT9e53/d0TxLEpmxfbaq8JYFv105s8FF5ssdMgJzsfuklhofAAMLiwQQbCEG5BbIv9 yS3Q==
Received: by 10.49.63.104 with SMTP id f8mr37189086qes.29.1350406676300; Tue, 16 Oct 2012 09:57:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.81.230 with HTTP; Tue, 16 Oct 2012 09:57:36 -0700 (PDT)
In-Reply-To: <1350403207.2540.1.camel@pbryan-wsl.internal.salesforce.com>
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com> <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114FDCF0C2D@WSMSG3153V.srv.dir.telstra.com> <1350403207.2540.1.camel@pbryan-wsl.internal.salesforce.com>
From: James M Snell 
Date: Tue, 16 Oct 2012 09:57:36 -0700
Message-ID: 
To: "Paul C. Bryan" 
Content-Type: multipart/alternative; boundary=047d7bdc1a3a3e438604cc300ed1
Cc: Mark Nottingham , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2012 16:57:57 -0000

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

Hmm... that would mean having to special case json-pointer expressions
specifically for json-patch, which isn't great either. Why not simply bake
it into json-pointer and be done with it? I'm sure json-patch is not the
only place where it could be useful.

On Tue, Oct 16, 2012 at 9:00 AM, Paul C. Bryan  wrote:

> **
>
>
> [snip]
>
>
> I wouldn't want to bake -1 into json-pointer. I think it should remain in
> json-patch.
>
> Paul
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

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

Hmm... that would mean having to speci=
al case json-pointer expressions specifically for json-patch, which isn'=
;t great either. Why not simply bake it into json-pointer and be done with =
it? I'm sure json-patch is not the only place where it could be useful.=




On Tue, Oct 16, 2012 at 9:00 AM, Paul=
 C. Bryan <pbryan@anode.ca> wrote:





 =20
 =20



[snip]





I wouldn't want to bake -1 into json-pointer. I think it should remain =
in json-patch.



Paul




_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--047d7bdc1a3a3e438604cc300ed1--

From pbryan@anode.ca  Tue Oct 16 10:00:40 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A4521F853E for ; Tue, 16 Oct 2012 10:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 KCg23ZEar8uS for ; Tue, 16 Oct 2012 10:00:39 -0700 (PDT)
Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id EC9F621F8A73 for ; Tue, 16 Oct 2012 10:00:34 -0700 (PDT)
Received: from [10.126.22.51] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 027456746; Tue, 16 Oct 2012 17:00:33 +0000 (UTC)
From: "Paul C. Bryan" 
To: James M Snell 
In-Reply-To: 
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com> <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114FDCF0C2D@WSMSG3153V.srv.dir.telstra.com> <1350403207.2540.1.camel@pbryan-wsl.internal.salesforce.com> 
Content-Type: multipart/alternative; boundary="=-OZRRzJEkPQYPej8sZcNm"
Date: Tue, 16 Oct 2012 10:00:32 -0700
Message-ID: <1350406832.2540.3.camel@pbryan-wsl.internal.salesforce.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: Mark Nottingham , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2012 17:00:41 -0000

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

We already have special semantics in json-patch for how to handle the
case where the value doesn't exist (when it's being added). This seems
like another case of handling a non-existing referenced value.

Paul

On Tue, 2012-10-16 at 09:57 -0700, James M Snell wrote:

> Hmm... that would mean having to special case json-pointer expressions
> specifically for json-patch, which isn't great either. Why not simply
> bake it into json-pointer and be done with it? I'm sure json-patch is
> not the only place where it could be useful.
> 
> 
> On Tue, Oct 16, 2012 at 9:00 AM, Paul C. Bryan 
> wrote:
> 
>         > 
>         > [snip]
>         
>         
>         
>         
>         I wouldn't want to bake -1 into json-pointer. I think it
>         should remain in json-patch.
>         
>         Paul
>         
>         
>         _______________________________________________
>         apps-discuss mailing list
>         apps-discuss@ietf.org
>         https://www.ietf.org/mailman/listinfo/apps-discuss
>         
> 
> 



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




  
  


We already have special semantics in json-patch for how to handle the case where the value doesn't exist (when it's being added). This seems like another case of handling a non-existing referenced value.



Paul



On Tue, 2012-10-16 at 09:57 -0700, James M Snell wrote:



    Hmm... that would mean having to special case json-pointer expressions specifically for json-patch, which isn't great either. Why not simply bake it into json-pointer and be done with it? I'm sure json-patch is not the only place where it could be useful.

    





    On Tue, Oct 16, 2012 at 9:00 AM, Paul C. Bryan <pbryan@anode.ca> wrote:




    

        



[snip]


        

        

        

    





    

        I wouldn't want to bake -1 into json-pointer. I think it should remain in json-patch.

        

        Paul
    





    

        

        _______________________________________________

        apps-discuss mailing list

        apps-discuss@ietf.org

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

        

    





    








--=-OZRRzJEkPQYPej8sZcNm--


From jasnell@gmail.com  Tue Oct 16 10:02:47 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0530D21F8700 for ; Tue, 16 Oct 2012 10:02:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.886
X-Spam-Level: 
X-Spam-Status: No, score=-3.886 tagged_above=-999 required=5 tests=[AWL=-1.954, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSs5ttJiSKsW for ; Tue, 16 Oct 2012 10:02:46 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB9CC21F86D1 for ; Tue, 16 Oct 2012 10:02:45 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id s14so5918234qcg.31 for ; Tue, 16 Oct 2012 10:02:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2DU7RBapG9j/0bNeuNKR38YZ0xKFj9wVuyeFnmK7Y04=; b=kWZcdELVEoMJr/sAuU15LK3gyk0L7sZx/pZkD03gneIbbAlBWNsQb3t3V/lhAryl19 xxD+C0f2AHEtZdq29/50IIKN9ylrO6mei/kWaj4cPQTu92A7B557/FJw/oA3US2AKuR1 tBht73HRal5Av/BdimXDj26xnxKCzgs7/HfkdMMfNGmzGyS4dPsMrVHV1i4RNciLxlAH DpvrnXGUtFHRzowdYtfGopGm6dRmDDN11ugRMW52MVI5iXrMVWYjVyvErFbG/mWwq5GU RJEknqcdh4uc3lYSxGM/9c1E/npYHhd6e9bTND8gMOlKc4YVbiYc7tn5cCRxACuaAP/1 gvMA==
Received: by 10.229.209.145 with SMTP id gg17mr7232050qcb.56.1350406965175; Tue, 16 Oct 2012 10:02:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.81.230 with HTTP; Tue, 16 Oct 2012 10:02:25 -0700 (PDT)
In-Reply-To: <507C6D8D.8070109@archive.org>
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com> <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com> <507C6D8D.8070109@archive.org>
From: James M Snell 
Date: Tue, 16 Oct 2012 10:02:25 -0700
Message-ID: 
To: Mike McCabe 
Content-Type: multipart/alternative; boundary=00504501548476265404cc301f79
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2012 17:02:47 -0000

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

On Mon, Oct 15, 2012 at 1:09 PM, Mike McCabe  wrote:

> All -
>
> I'm glad to see this subject discussed.
>
> In discussions about json-patch at my organization, both of these request=
s
> - unconditional set, and list append -  have come up.
>
> Some users would like to be able to make changes to data without prior
> knowledge of it's exact state ahead of time.
>
> (It's worth mentioning that another use of json-patch in our organization
> is to replace a system with strictly versioned updates, in which race
> conditions and inconsistent data aren't tolerated.  Both needs exist, and=
 I
> think both can be served by json-patch.)
>
> In practice, the lack of safe unconditional sets and appends has led me t=
o
> recommend that internal users generate their patches by getting the old
> document, making changes to a copy, and using an automated diff() functio=
n
> to compare old and new, rather than free-coding checks.  This will probab=
ly
> always be the most robust way to specify arbitrary changes, but there are
> many uses where an unconditional set or append would be simpler.
>
>
> On to opinions...
>
> * I think there's room for a new op alongside the current 'add' op
> semantics.  I propose 'set' - exactly like 'add', but not throwing an err=
or
> if the value already exists.  For lists, it could work like 'replace', bu=
t
> could still append.  The existing 'add' semantics remain useful for
> 'transactional' uses of json-patch.
>
>
I imagine that introducing a "set" when we already have "replace" is going
to cause confusion. Perhaps "replace" can be modified such that it acts
like "add" if the path does not currently exist. Or perhaps we rename
"replace" to "set" and keep "add" as it is currently defined.

- James


> * I also like negative index notation.  It's use is well established in
> javascript (as an array slice() argument), in python and in other
> languages.  There it means 'add the length of the list to the negative
> index to get the offset' - thus -1 indicates the last element, not the sl=
ot
> after.  For this reason, if we add negative indices, I think we should us=
e
> -0 to append.  (In fact, a co-worker came up with exactly this notation
> some weeks ago.)
>
> * I'm skeptical of proposals that call for 'opening up' value arguments,
> to merge them into the target value or otherwise.  What if it's an array?
>  What if it's something else?  I think this would lose the current
> generality of allowing arbitrary json in the value field, and would make
> json-patch harder to reason about - and harder to specify!
>
>
> I'm otherwise very happy with json-patch - I was casting around for a jso=
n
> language to describe data deltas when I found it, and it exactly
> fits the bill.  We're still in internal testing of json-patch, but it wil=
l
> soon be part of the preferred public API for modifying Internet Archive
> item metadata.
>
>
> Best regards,
> Mike McCabe
>
>
>
>
> On 10/15/12 9:37 AM, Paul C. Bryan wrote:
>
>> On Mon, 2012-10-15 at 12:30 +1100, Manger, James H wrote:
>>
>>> > > Java uses:
>>> > > * "add" to insert a new item into a list (array),
>>> > > * "set" to replace a current item in a list (array), and
>>> > > * "put" to put a key/value pair in a map (object), regardless of
>>> > whether or not the key already exists.
>>> > >
>>> > > Consequently, I don't think "set" is a good name for a json-patch
>>> > operation if it provides the functionality of Java=E2=80=99s "add", b=
ut not
>>> > Java=E2=80=99s "set".
>>> > >
>>> > > It would simplify spec & code to define 3 operations for json-patch=
,
>>> > instead of trying to squeeze the functionality into two of these.
>>>
>>> > I'm *not* patterning anything I write after Java, thanks. Besides
>>> > which, we're not talking about arrays here (although I did flirt with
>>> > the idea of type-specific operators for a little while).
>>>
>>> Aren=E2=80=99t we talking about arrays?
>>>
>>
>> No, at this point, we're talking about values, which can exist within
>> arrays or objects.
>>
>>  The object case seems clear: set a key/value pair, regardless of
>>> whether the key was already present.
>>>
>>> The choice I see for objects is whether an operation:
>>> * Sets 1 key/value pair ("path" ids the key, "value" is separate); or
>>> * Sets any number of pairs ("path" ids the object, "value" is an
>>> object of pairs to set).
>>> [The 2nd choice looks better]
>>>
>>> The array case is where it is a bit more complex. Adding and replacing
>>> are quite separate. Adding needs a gap, from the start or end;
>>> replacing needs an index, from the start or end. Gaps and indices can
>>> overflow. Ranges add more complexity.
>>>
>>
>> This does raise the issue of attempting to set an array element outside
>> the current range of values (i.e. sparse allocation).
>>
>>  > > /foo/-1
>>> > >
>>> > > I like the ability to indicate position in an array (or between arr=
ay
>>> > elements) from then end. I=E2=80=99m not sure that extending JSON poi=
nter is
>>> > the right approach. Currently there is a unique pointer for every
>>> > value. It would be a shame to lose that property.
>>>
>>> > What does keeping it give us?
>>>
>>> You can compare 2 pointers to see if they point to the same thing
>>> (without having to resolve them first against the JSON doc they point
>>> at).
>>>
>>
>> And what does that give us?
>>
>> 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
>

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



On Mon, Oct 15, 2012 at 1:09 PM, Mike McCabe <mccabe@archive.org&=
gt; wrote:



All -



I'm glad to see this subject discussed.



In discussions about json-patch at my organization, both of these requests =
- unconditional set, and list append - =C2=A0have come up.



Some users would like to be able to make changes to data without prior know=
ledge of it's exact state ahead of time.



(It's worth mentioning that another use of json-patch in our organizati=
on is to replace a system with strictly versioned updates, in which race co=
nditions and inconsistent data aren't tolerated. =C2=A0Both needs exist=
, and I think both can be served by json-patch.)





In practice, the lack of safe unconditional sets and appends has led me to =
recommend that internal users generate their patches by getting the old doc=
ument, making changes to a copy, and using an automated diff() function to =
compare old and new, rather than free-coding checks. =C2=A0This will probab=
ly always be the most robust way to specify arbitrary changes, but there ar=
e many uses where an unconditional set or append would be simpler.







On to opinions...



* I think there's room for a new op alongside the current 'add'=
 op semantics. =C2=A0I propose 'set' - exactly like 'add', =
but not throwing an error if the value already exists. =C2=A0For lists, it =
could work like 'replace', but could still append. =C2=A0The existi=
ng 'add' semantics remain useful for 'transactional' uses o=
f json-patch.





I imagine that introducing a "set=
" when we already have "replace" is going to cause confusion=
. Perhaps "replace" can be modified such that it acts like "=
add" if the path does not currently exist. Or perhaps we rename "=
replace" to "set" and keep "add" as it is currentl=
y defined.




- James
=C2=A0

* I also like negative index notation. =C2=A0It's use is well establish=
ed in javascript (as an array slice() argument), in python and in other lan=
guages. =C2=A0There it means 'add the length of the list to the negativ=
e index to get the offset' - thus -1 indicates the last element, not th=
e slot after. =C2=A0For this reason, if we add negative indices, I think we=
 should use -0 to append. =C2=A0(In fact, a co-worker came up with exactly =
this notation some weeks ago.)





* I'm skeptical of proposals that call for 'opening up' value a=
rguments, to merge them into the target value or otherwise. =C2=A0What if i=
t's an array? =C2=A0What if it's something else? =C2=A0I think this=
 would lose the current generality of allowing arbitrary json in the value =
field, and would make json-patch harder to reason about - and harder to spe=
cify!







I'm otherwise very happy with json-patch - I was casting around for a j=
son language to describe data deltas when I found it, and it exactly

fits the bill. =C2=A0We're still in internal testing of json-patch, but=
 it will soon be part of the preferred public API for modifying Internet Ar=
chive item metadata.





Best regards,

Mike McCabe








On 10/15/12 9:37 AM, Paul C. Bryan wrote:



On Mon, 2012-10-15 at 12:30 +1100, Manger, James H wrote:



> > Java uses:

> > * "add" to insert a new item into a list (array),

> > * "set" to replace a current item in a list (array), an=
d

> > * "put" to put a key/value pair in a map (object), rega=
rdless of

> whether or not the key already exists.

> >

> > Consequently, I don't think "set" is a good name fo=
r a json-patch

> operation if it provides the functionality of Java=E2=80=99s "add=
", but not

> Java=E2=80=99s "set".

> >

> > It would simplify spec & code to define 3 operations for json=
-patch,

> instead of trying to squeeze the functionality into two of these.



> I'm *not* patterning anything I write after Java, thanks. Besides<=
br>
> which, we're not talking about arrays here (although I did flirt w=
ith

> the idea of type-specific operators for a little while).



Aren=E2=80=99t we talking about arrays?





No, at this point, we're talking about values, which can exist within
arrays or objects.





The object case seems clear: set a key/value pair, regardless of

whether the key was already present.



The choice I see for objects is whether an operation:

* Sets 1 key/value pair ("path" ids the key, "value" is=
 separate); or

* Sets any number of pairs ("path" ids the object, "value&qu=
ot; is an

object of pairs to set).

[The 2nd choice looks better]



The array case is where it is a bit more complex. Adding and replacing

are quite separate. Adding needs a gap, from the start or end;

replacing needs an index, from the start or end. Gaps and indices can

overflow. Ranges add more complexity.





This does raise the issue of attempting to set an array element outside

the current range of values (i.e. sparse allocation).





> > /foo/-1

> >

> > I like the ability to indicate position in an array (or between a=
rray

> elements) from then end. I=E2=80=99m not sure that extending JSON poin=
ter is

> the right approach. Currently there is a unique pointer for every

> value. It would be a shame to lose that property.



> What does keeping it give us?



You can compare 2 pointers to see if they point to the same thing

(without having to resolve them first against the JSON doc they point at).<=
br>




And what does that give us?



Paul







_______________________________________________

apps-discuss mailing list

apps-discuss@iet=
f.org

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





_______________________________________________

apps-discuss mailing list

apps-discuss@iet=
f.org

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





--00504501548476265404cc301f79--

From pbryan@anode.ca  Tue Oct 16 10:08:03 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D028121F8995 for ; Tue, 16 Oct 2012 10:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwKp7FvYvtcC for ; Tue, 16 Oct 2012 10:08:03 -0700 (PDT)
Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6184C21F8987 for ; Tue, 16 Oct 2012 10:08:03 -0700 (PDT)
Received: from [10.126.22.51] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 5F3936746; Tue, 16 Oct 2012 17:08:02 +0000 (UTC)
From: "Paul C. Bryan" 
To: James M Snell 
In-Reply-To: 
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com> <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com> <507C6D8D.8070109@archive.org> 
Content-Type: multipart/alternative; boundary="=-bJfqZRPKIV+U0hNtG1hm"
Date: Tue, 16 Oct 2012 10:08:01 -0700
Message-ID: <1350407281.2540.5.camel@pbryan-wsl.internal.salesforce.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2012 17:08:03 -0000

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

On Tue, 2012-10-16 at 10:02 -0700, James M Snell wrote:

> I imagine that introducing a "set" when we already have "replace" is
> going to cause confusion. Perhaps "replace" can be modified such that
> it acts like "add" if the path does not currently exist. Or perhaps we
> rename "replace" to "set" and keep "add" as it is currently defined.


I think the plan would be to drop "add" and "replace" in favour of
"insert" and "set".

Paul


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




  
  


On Tue, 2012-10-16 at 10:02 -0700, James M Snell wrote:




    I imagine that introducing a "set" when we already have "replace" is going to cause confusion. Perhaps "replace" can be modified such that it acts like "add" if the path does not currently exist. Or perhaps we rename "replace" to "set" and keep "add" as it is currently defined.





I think the plan would be to drop "add" and "replace" in favour of "insert" and "set".



Paul





--=-bJfqZRPKIV+U0hNtG1hm--


From jasnell@gmail.com  Tue Oct 16 12:34:01 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AE121F853A for ; Tue, 16 Oct 2012 12:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.666
X-Spam-Level: 
X-Spam-Status: No, score=-4.666 tagged_above=-999 required=5 tests=[AWL=-1.068, 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 Cue7XldXnQNr for ; Tue, 16 Oct 2012 12:33:55 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A59F321F8501 for ; Tue, 16 Oct 2012 12:33:55 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id s14so6078325qcg.31 for ; Tue, 16 Oct 2012 12:33:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=na6SIP3LMA7MuR95E8+KObHXNPmpCPXEmPI7mb/SinM=; b=liitWPcsG3HzV+t6Opu4aO+oVk282UsHa8VuLGoER1UiNq5SAQNLgJ8J7SM1527FH5 DXbe8vlBH8SUIGEgzFpPLBQu2IalD944M6yiqwp5r4/hsDHPT5uQ9yVhvDkRzvVHI48z nvbT/Ya1+e3b7V/UnpLN8r7FngsIocmdgapKJhH4lYPmYNvYkJRIx64hzdzykHNfHyzH uZDpVjb13Pek/8enTEy99cIg43t227PkyBMk7I6Pl8pdY/oWOUsan0QdD+By8QIKgSoM 0woxuBHWfmu83K/aJehVQ6xkuiO0OByjoQxZoVpcKW6nKJ3Ot9FJMz765qls6uDq3tt4 9jwA==
Received: by 10.49.131.199 with SMTP id oo7mr36598605qeb.14.1350416035074; Tue, 16 Oct 2012 12:33:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.81.230 with HTTP; Tue, 16 Oct 2012 12:33:34 -0700 (PDT)
In-Reply-To: <2E11857B-970B-44D6-8EB9-AF7BEFF28F50@nordsc.com>
References:  <9C722517-7948-4B0E-A78D-8992FD96F59B@mnot.net>  <603A775B-5CCA-44F7-A7FF-BB22168CBE2B@mnot.net>   <2E11857B-970B-44D6-8EB9-AF7BEFF28F50@nordsc.com>
From: James M Snell 
Date: Tue, 16 Oct 2012 12:33:34 -0700
Message-ID: 
To: Jan Algermissen 
Content-Type: multipart/alternative; boundary=047d7bdc7c2411d6a304cc323c05
Cc: Mark Nottingham , Barry Leiba , HTTP Working Group , Apps Discuss 
Subject: Re: [apps-discuss] Re-review of draft-snell-http-prefer-15
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Oct 2012 19:34:01 -0000

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

On Sat, Oct 13, 2012 at 2:08 PM, Jan Algermissen  wrote:

>
> On Oct 13, 2012, at 10:39 PM, Mark Nottingham wrote:
>
> >
> > On 14/10/2012, at 6:11 AM, James M Snell  wrote:
> >
> >>> Right, but what's the difference between:
> >>>
> >>>  Prefer: wait=10
> >>> and
> >>>  Prefer: return-asynch, wait=10
> >>>
> >>> ? "return asynch" really says "give me a 202" which is nonsense; the
> client doesn't control the status code, the server does.
> >>>
> >>
> >> That's why it's a Prefer header and not Expect. The server retains
> control. "Prefer: wait=10" could just as easily result in the server simply
> throwing up it's hands and saying, "sorry, can't do it"
> >
> > And what does return-async(h) bring to the party?
>
> I cannot see that either. In fact, I cannot even imagine a server paying
> attention to the '10', given the juggling between estimating the task
> duration and comparing to the wait time.
>
> Maybe
>
>   Prefer: wait
>
> just does the job?
>

No, wait simply tells the server how long the client expects processing of
the request to take and does not communicate any information about the
preferred response. I could, for instance, have a theoretical "Prefer:
wait=120, respond-giveup" that could be interpreted as "I prefer you give
up if you can't process this request in less than 2 minutes".

- James


>
> Jan
>
>
> >
> > The server can still throw up its hands with a 4xx or 5xx, and the
> client has to deal with that.
> >
> >
> >
> > --
> > Mark Nottingham   http://www.mnot.net/
> >
> >
> >
> >
>
>

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



On Sat, Oct 13, 2012 at 2:08 PM, Jan Algermissen <=
jan.algermi=
ssen@nordsc.com> wrote:






On Oct 13, 2012, at 10:39 PM, Mark Nottingham wrote:



>

> On 14/10/2012, at 6:11 AM, James M Snell <jasnell@gmail.com> wrote:

>

>>> Right, but what's the difference between:

>>>

>>> =C2=A0Prefer: wait=3D10

>>> and

>>> =C2=A0Prefer: return-asynch, wait=3D10

>>>

>>> ? "return asynch" really says "give me a 202&qu=
ot; which is nonsense; the client doesn't control the status code, the =
server does.

>>>

>>

>> That's why it's a Prefer header and not Expect. The server=
 retains control. "Prefer: wait=3D10" could just as easily result=
 in the server simply throwing up it's hands and saying, "sorry, c=
an't do it"




>

> And what does return-async(h) bring to the party?




I cannot see that either. In fact, I cannot even imagine a server pay=
ing attention to the '10', given the juggling between estimating th=
e task duration and comparing to the wait time.



Maybe



=C2=A0 Prefer: wait



just does the job?

No, wait simply tell=
s the server how long the client expects processing of the request to take =
and does not communicate any information about the preferred response. I co=
uld, for instance, have a theoretical "Prefer: wait=3D120, respond-giv=
eup" that could be interpreted as "I prefer you give up if you ca=
n't process this request in less than 2 minutes".=C2=A0





- James
=C2=A0



Jan






>

> The server can still throw up its hands with a 4xx or 5xx, and the cli=
ent has to deal with that.

>

>

>

> --

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

>

>

>

>







--047d7bdc7c2411d6a304cc323c05--

From jasnell@gmail.com  Tue Oct 16 17:04:38 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A241F0CB9 for ; Tue, 16 Oct 2012 17:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.673
X-Spam-Level: 
X-Spam-Status: No, score=-4.673 tagged_above=-999 required=5 tests=[AWL=-1.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDgEmOrxZ9eI for ; Tue, 16 Oct 2012 17:04:37 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58B451F0CB4 for ; Tue, 16 Oct 2012 17:04:36 -0700 (PDT)
Received: by mail-qa0-f44.google.com with SMTP id 25so5287qao.10 for ; Tue, 16 Oct 2012 17:04:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oKf7oMniU5qm+AcejRxR3Jni6s28ujlD5kI9nAJKy20=; b=VI9rpG2gifb9LZINtGsSOAueKs/LRUzx7l+PqJ32XSD+7qjsQYKFjZ8uNEoJOcciuq qlbCvCBIedRzaoCwm2/lNT6x2bR5MtmT2q8x9FYX7LmNZ7mLA8GMXUBInlA2MPg57PG2 bJON6agvAoJ00jC18771goeKsEsHdYH1oUbjXuiI7RActq2HTUFxndbAcxSOhgdPFW2h 5gvBdoU6YeKVlJc4ph45CjTEJxuNcmOlsMWsDGNnWHpkRZtwIfjwspoSzjcjEhkySpmo qIR3eisxIrwFMijUuUWxKUPiDuh66bAsINln/CdthVoUsEMCNjdn2SsewoOhmB+tFhWo 1s9A==
Received: by 10.224.193.69 with SMTP id dt5mr29288107qab.2.1350432275729; Tue, 16 Oct 2012 17:04:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.81.230 with HTTP; Tue, 16 Oct 2012 17:04:14 -0700 (PDT)
In-Reply-To: <1350406832.2540.3.camel@pbryan-wsl.internal.salesforce.com>
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com> <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114FDCF0C2D@WSMSG3153V.srv.dir.telstra.com> <1350403207.2540.1.camel@pbryan-wsl.internal.salesforce.com>  <1350406832.2540.3.camel@pbryan-wsl.internal.salesforce.com>
From: James M Snell 
Date: Tue, 16 Oct 2012 17:04:14 -0700
Message-ID: 
To: "Paul C. Bryan" 
Content-Type: multipart/alternative; boundary=20cf30051506168c9a04cc3604e9
Cc: Mark Nottingham , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2012 00:04:38 -0000

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

Special handling when the path refers to a non-existent object is different
than allowing for a json-patch specific variation in the pointer syntax
itself. If we allow for the use of negative indices then that change should
be baked in to json pointer itself. I see little harm in doing so.

- James

On Tue, Oct 16, 2012 at 10:00 AM, Paul C. Bryan  wrote:

> **
> We already have special semantics in json-patch for how to handle the case
> where the value doesn't exist (when it's being added). This seems like
> another case of handling a non-existing referenced value.
>
> Paul
>
>
> On Tue, 2012-10-16 at 09:57 -0700, James M Snell wrote:
>
> Hmm... that would mean having to special case json-pointer expressions
> specifically for json-patch, which isn't great either. Why not simply bake
> it into json-pointer and be done with it? I'm sure json-patch is not the
> only place where it could be useful.
>
>  On Tue, Oct 16, 2012 at 9:00 AM, Paul C. Bryan  wrote:
>
>   [snip]
>
>
>
>   I wouldn't want to bake -1 into json-pointer. I think it should remain
> in json-patch.
>
> Paul
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
>

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

Special handling when the path refers =
to a non-existent object is different than allowing for a json-patch specif=
ic variation in the pointer syntax itself. If we allow for the use of negat=
ive indices then that change should be baked in to json pointer itself. I s=
ee little harm in doing so.



- James

On Tu=
e, Oct 16, 2012 at 10:00 AM, Paul C. Bryan <pbryan@anode.ca> w=
rote:






 =20
 =20



We already have special semantics in json-patch for how to handle the case =
where the value doesn't exist (when it's being added). This seems l=
ike another case of handling a non-existing referenced value.





Paul




On Tue, 2012-10-16 at 09:57 -0700, James M Snell wrote:



    Hmm... that would mean having to special case json-pointer expressions =
specifically for json-patch, which isn't great either. Why not simply b=
ake it into json-pointer and be done with it? I'm sure json-patch is no=
t the only place where it could be useful.



    





    On Tue, Oct 16, 2012 at 9:00 AM, Paul C. Bryan <pbryan@anode.ca> wrote:




    

        


[snip]


        

        

        

    





    

        I wouldn't want to bake -1 into json-pointer. I think it should=
 remain in json-patch.

        

        Paul
    





    

        

        _______________________________________________

        apps-discuss mailing list

        apps-dis=
cuss@ietf.org

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

        

    





    












--20cf30051506168c9a04cc3604e9--

From mnot@mnot.net  Tue Oct 16 17:07:24 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA0F1F0CB9 for ; Tue, 16 Oct 2012 17:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.212
X-Spam-Level: 
X-Spam-Status: No, score=-104.212 tagged_above=-999 required=5 tests=[AWL=-1.613, 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 jfPXXLRnK7U5 for ; Tue, 16 Oct 2012 17:07:23 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id B31631F0423 for ; Tue, 16 Oct 2012 17:07:23 -0700 (PDT)
Received: from [192.168.1.72] (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 907B522DD6D; Tue, 16 Oct 2012 20:07:14 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: 
Date: Wed, 17 Oct 2012 11:07:08 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com> <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114FDCF0C2D@WSMSG3153V.srv.dir.telstra.com> <1350403207.2540.1.camel@pbryan-wsl.internal.salesforce.com>  <1350406832.2540.3.camel@pbryan-wsl.internal.salesforce.com> 
To: James M Snell 
X-Mailer: Apple Mail (2.1499)
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2012 00:07:24 -0000

I tend to agree that if we're going to do it, it should be in pointer.

If it were left to me, I think I'd just have *one* special value whose =
semantics is "the end of the array." Simpler.

Cheers,


On 17/10/2012, at 11:04 AM, James M Snell  wrote:

> Special handling when the path refers to a non-existent object is =
different than allowing for a json-patch specific variation in the =
pointer syntax itself. If we allow for the use of negative indices then =
that change should be baked in to json pointer itself. I see little harm =
in doing so.
>=20
> - James
>=20
> On Tue, Oct 16, 2012 at 10:00 AM, Paul C. Bryan  =
wrote:
> We already have special semantics in json-patch for how to handle the =
case where the value doesn't exist (when it's being added). This seems =
like another case of handling a non-existing referenced value.
>=20
> Paul
>=20
>=20
> On Tue, 2012-10-16 at 09:57 -0700, James M Snell wrote:
>> Hmm... that would mean having to special case json-pointer =
expressions specifically for json-patch, which isn't great either. Why =
not simply bake it into json-pointer and be done with it? I'm sure =
json-patch is not the only place where it could be useful.
>>=20
>> On Tue, Oct 16, 2012 at 9:00 AM, Paul C. Bryan  =
wrote:
>>> [snip]
>>>=20
>>=20
>>=20
>> I wouldn't want to bake -1 into json-pointer. I think it should =
remain in json-patch.
>>=20
>> Paul
>>=20
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>=20
>>=20
>=20
>=20

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




From pbryan@anode.ca  Tue Oct 16 17:12:38 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65A721F8647 for ; Tue, 16 Oct 2012 17:12:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yawj9MWrrDim for ; Tue, 16 Oct 2012 17:12:38 -0700 (PDT)
Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id E801121F8645 for ; Tue, 16 Oct 2012 17:12:37 -0700 (PDT)
Received: from [10.126.22.51] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id DEA406746; Wed, 17 Oct 2012 00:12:35 +0000 (UTC)
From: "Paul C. Bryan" 
To: Mark Nottingham 
In-Reply-To: 
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com> <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114FDCF0C2D@WSMSG3153V.srv.dir.telstra.com> <1350403207.2540.1.camel@pbryan-wsl.internal.salesforce.com>  <1350406832.2540.3.camel@pbryan-wsl.internal.salesforce.com>  
Content-Type: multipart/alternative; boundary="=-tigRqv/TcyaXo77m0Nrn"
Date: Tue, 16 Oct 2012 17:12:33 -0700
Message-ID: <1350432753.2540.27.camel@pbryan-wsl.internal.salesforce.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2012 00:12:39 -0000

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

Okay, if we're opening-up json-pointer to change, I think the other
thing I'm seeing in other threads is a desire to identify an object that
contains a specific member-value. Would you be open to discussing this?
I know this pushes final call out even further, but we're discussing
enhancements so I thought I'd put it out there.

Paul

On Wed, 2012-10-17 at 11:07 +1100, Mark Nottingham wrote:

> I tend to agree that if we're going to do it, it should be in pointer.
> 
> If it were left to me, I think I'd just have *one* special value whose semantics is "the end of the array." Simpler.
> 
> Cheers,
> 
> 
> On 17/10/2012, at 11:04 AM, James M Snell  wrote:
> 
> > Special handling when the path refers to a non-existent object is different than allowing for a json-patch specific variation in the pointer syntax itself. If we allow for the use of negative indices then that change should be baked in to json pointer itself. I see little harm in doing so.
> > 
> > - James
> > 
> > On Tue, Oct 16, 2012 at 10:00 AM, Paul C. Bryan  wrote:
> > We already have special semantics in json-patch for how to handle the case where the value doesn't exist (when it's being added). This seems like another case of handling a non-existing referenced value.
> > 
> > Paul
> > 
> > 
> > On Tue, 2012-10-16 at 09:57 -0700, James M Snell wrote:
> >> Hmm... that would mean having to special case json-pointer expressions specifically for json-patch, which isn't great either. Why not simply bake it into json-pointer and be done with it? I'm sure json-patch is not the only place where it could be useful.
> >> 
> >> On Tue, Oct 16, 2012 at 9:00 AM, Paul C. Bryan  wrote:
> >>> [snip]
> >>> 
> >> 
> >> 
> >> I wouldn't want to bake -1 into json-pointer. I think it should remain in json-patch.
> >> 
> >> Paul
> >> 
> >> _______________________________________________
> >> apps-discuss mailing list
> >> apps-discuss@ietf.org
> >> https://www.ietf.org/mailman/listinfo/apps-discuss
> >> 
> >> 
> > 
> > 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 



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




  
  


Okay, if we're opening-up json-pointer to change, I think the other thing I'm seeing in other threads is a desire to identify an object that contains a specific member-value. Would you be open to discussing this? I know this pushes final call out even further, but we're discussing enhancements so I thought I'd put it out there.



Paul



On Wed, 2012-10-17 at 11:07 +1100, Mark Nottingham wrote:



I tend to agree that if we're going to do it, it should be in pointer.

If it were left to me, I think I'd just have *one* special value whose semantics is "the end of the array." Simpler.

Cheers,


On 17/10/2012, at 11:04 AM, James M Snell <jasnell@gmail.com> wrote:

> Special handling when the path refers to a non-existent object is different than allowing for a json-patch specific variation in the pointer syntax itself. If we allow for the use of negative indices then that change should be baked in to json pointer itself. I see little harm in doing so.
> 
> - James
> 
> On Tue, Oct 16, 2012 at 10:00 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
> We already have special semantics in json-patch for how to handle the case where the value doesn't exist (when it's being added). This seems like another case of handling a non-existing referenced value.
> 
> Paul
> 
> 
> On Tue, 2012-10-16 at 09:57 -0700, James M Snell wrote:
>> Hmm... that would mean having to special case json-pointer expressions specifically for json-patch, which isn't great either. Why not simply bake it into json-pointer and be done with it? I'm sure json-patch is not the only place where it could be useful.
>> 
>> On Tue, Oct 16, 2012 at 9:00 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
>>> [snip]
>>> 
>> 
>> 
>> I wouldn't want to bake -1 into json-pointer. I think it should remain in json-patch.
>> 
>> Paul
>> 
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>> 
>> 
> 
> 

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












--=-tigRqv/TcyaXo77m0Nrn--


From jasnell@gmail.com  Tue Oct 16 17:27:27 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BD821F86B3 for ; Tue, 16 Oct 2012 17:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.705
X-Spam-Level: 
X-Spam-Status: No, score=-4.705 tagged_above=-999 required=5 tests=[AWL=-1.107, 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 ruXtsg01xgbZ for ; Tue, 16 Oct 2012 17:27:26 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 590FB21F86B1 for ; Tue, 16 Oct 2012 17:27:26 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id s14so6349015qcg.31 for ; Tue, 16 Oct 2012 17:27:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=u8nzmtL97jJhHfVmRE1etxxrHzVfyRoOG6j/8sD7+2M=; b=wtdnnJRSmRWrALTLVuZU7FB9W09T5YS/I0grxJHWcRy7r6eKdz5ypfYFSuk03nFZKn 7jr0xkgrcDZtr4vfR4y0tZRof0Co0kziKbdofIxLJDhKZcXHjvlYauvqIaZHvAtZIFZY hqO+MUAqr+N/5DNHoCGHDQmhI3k2Lp0J39olmAQfSZWel/m9/PxftD+k2bCPp/baQ27D mVwaAGh3mJqqF5H2dQMIgewvI2hvTXgXyqb4F/6weNm18xjscayIxa449g8fdYYIVZ2d jBsQkUf2FlKPitEOOIlkiYjKQ0BIYLYFU/7OQZvmRgOewQJ26tmDeOIJ/GUUJRqzjA4l MWbA==
Received: by 10.229.209.145 with SMTP id gg17mr7755949qcb.56.1350433645661; Tue, 16 Oct 2012 17:27:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.81.230 with HTTP; Tue, 16 Oct 2012 17:27:04 -0700 (PDT)
In-Reply-To: <1350432753.2540.27.camel@pbryan-wsl.internal.salesforce.com>
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com> <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114FDCF0C2D@WSMSG3153V.srv.dir.telstra.com> <1350403207.2540.1.camel@pbryan-wsl.internal.salesforce.com>  <1350406832.2540.3.camel@pbryan-wsl.internal.salesforce.com>   <1350432753.2540.27.camel@pbryan-wsl.internal.salesforce.com>
From: James M Snell 
Date: Tue, 16 Oct 2012 17:27:04 -0700
Message-ID: 
To: "Paul C. Bryan" 
Content-Type: multipart/alternative; boundary=005045015484be0d8a04cc365595
Cc: Mark Nottingham , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2012 00:27:27 -0000

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

Hmm... that's a slippery slope, indeed. I think mechanisms such as the
"test" operation and my proposals in the JSON Predicates draft give us
plenty of options for testing values once they have been selected with a
JSON Pointer. I don't think we need to go down the path of building
predicate operations into the pointer itself.

As for Mark's comment, I'm good with either negative indices in general or
a single special case like "-" to indicate the end of the array. I agree
the latter would be simpler (and therefore likely marginally better)

Btw... If we do go with negative indices, the reference for the last
element in the array really should be "-0" since we're using zero based
arrays...

  {"foo": ["a","b","c"]}

  /foo/0  =3D> "a"
  /foo/1  =3D> "b"
  /foo/2  =3D> "c"

  /foo/-0 =3D> "c"
  /foo/-1 =3D> "b"
  /foo/-2 =3D> "a"

  /foo/-  =3D> (the end of the array past c)

  [{"op": "set", "path": "/foo/-", "value": "d"},
  {"op": "set", "path": "/foo/-0", "value": "e"},
  {"op": "insert", "path": "/foo/1", "value": "f"}]

  Would result in:

  {"foo": ["a","f","b","e","d"]}


- James


On Tue, Oct 16, 2012 at 5:12 PM, Paul C. Bryan  wrote:

> **
> Okay, if we're opening-up json-pointer to change, I think the other thing
> I'm seeing in other threads is a desire to identify an object that contai=
ns
> a specific member-value. Would you be open to discussing this? I know thi=
s
> pushes final call out even further, but we're discussing enhancements so =
I
> thought I'd put it out there.
>
> Paul
>
>
> On Wed, 2012-10-17 at 11:07 +1100, Mark Nottingham wrote:
>
> I tend to agree that if we're going to do it, it should be in pointer.
>
> If it were left to me, I think I'd just have *one* special value whose se=
mantics is "the end of the array." Simpler.
>
> Cheers,
>
>
> On 17/10/2012, at 11:04 AM, James M Snell  wrote:
>
> > Special handling when the path refers to a non-existent object is diffe=
rent than allowing for a json-patch specific variation in the pointer synta=
x itself. If we allow for the use of negative indices then that change shou=
ld be baked in to json pointer itself. I see little harm in doing so.
> >
> > - James
> >
> > On Tue, Oct 16, 2012 at 10:00 AM, Paul C. Bryan  wrote=
:
> > We already have special semantics in json-patch for how to handle the c=
ase where the value doesn't exist (when it's being added). This seems like =
another case of handling a non-existing referenced value.
> >
> > Paul
> >
> >
> > On Tue, 2012-10-16 at 09:57 -0700, James M Snell wrote:
> >> Hmm... that would mean having to special case json-pointer expressions=
 specifically for json-patch, which isn't great either. Why not simply bake=
 it into json-pointer and be done with it? I'm sure json-patch is not the o=
nly place where it could be useful.
> >>
> >> On Tue, Oct 16, 2012 at 9:00 AM, Paul C. Bryan  wrote=
:
> >>> [snip]
> >>>
> >>
> >>
> >> I wouldn't want to bake -1 into json-pointer. I think it should remain=
 in json-patch.
> >>
> >> Paul
> >>
> >> _______________________________________________
> >> apps-discuss mailing list
> >> apps-discuss@ietf.org
> >> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>
> >>
> >
> >
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>

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

Hmm... that's a slippery slope, in=
deed. I think mechanisms such as the "test" operation and my prop=
osals in the JSON Predicates draft give us plenty of options for testing va=
lues once they have been selected with a JSON Pointer. I don't think we=
 need to go down the path of building predicate operations into the pointer=
 itself.=C2=A0



As for Mark's comm=
ent, I'm good with either negative indices in general or a single speci=
al case like "-" to indicate the end of the array. I agree the la=
tter would be simpler (and therefore likely marginally better)




Btw... If we do go with negative indices, the r=
eference for the last element in the array really should be "-0" =
since we're using zero based arrays...




=C2=A0 {"foo": ["a","b=
","c"]}




=C2=A0 /foo/0 =C2=
=A0=3D> "a"
=C2=A0 /foo/1 =C2=A0=3D> "b"
=C2=A0 /foo/2 =C2=A0=3D> "c"




=C2=A0 /foo/-0 =3D> "c"
=C2=A0 /foo/-1 =3D> "b=
"



=C2=A0 /foo/-2 =3D> "a&q=
uot;

=C2=A0 /foo/- =C2=A0=3D> (t=
he end of the array past c)




=C2=A0 [{"op": "set", "=
;path": "/foo/-", "value": "d"},<=
/div>


=C2=A0 {"op": "se=
t", "path": "/foo/-0", "value": "e&=
quot;},
=C2=A0 {&quo=
t;op": "insert", "path": "/foo/1", "=
;value": "f"}]




=C2=A0 Would result in:

=C2=A0 {"foo": ["a","f",&quo=
t;b","e","d"]}





=

- James=C2=A0
<=
font face=3D"courier new, monospace">=C2=A0



On Tue, Oct 16, 2012 at 5:12 PM, Paul C. Bryan <pbryan@anode.ca> wrote:





 =20
 =20



Okay, if we're opening-up json-pointer to change, I think the other thi=
ng I'm seeing in other threads is a desire to identify an object that c=
ontains a specific member-value. Would you be open to discussing this? I kn=
ow this pushes final call out even further, but we're discussing enhanc=
ements so I thought I'd put it out there.





Paul




On Wed, 2012-10-17 at 11:07 +1100, Mark Nottingham wrote:



I tend to agree that if we're going to do it, it should be in poin=
ter.

If it were left to me, I think I'd just have *one* special value whose =
semantics is "the end of the array." Simpler.

Cheers,


On 17/10/2012, at 11:04 AM, James M Snell <jasnell@gmail.com> wrote:

> Special handling when the path refers to a non-existent object is diff=
erent than allowing for a json-patch specific variation in the pointer synt=
ax itself. If we allow for the use of negative indices then that change sho=
uld be baked in to json pointer itself. I see little harm in doing so.
>=20
> - James
>=20
> On Tue, Oct 16, 2012 at 10:00 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
> We already have special semantics in json-patch for how to handle the =
case where the value doesn't exist (when it's being added). This se=
ems like another case of handling a non-existing referenced value.
>=20
> Paul
>=20
>=20
> On Tue, 2012-10-16 at 09:57 -0700, James M Snell wrote:
>> Hmm... that would mean having to special case json-pointer express=
ions specifically for json-patch, which isn't great either. Why not sim=
ply bake it into json-pointer and be done with it? I'm sure json-patch =
is not the only place where it could be useful.
>>=20
>> On Tue, Oct 16, 2012 at 9:00 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
>>> [snip]
>>>=20
>>=20
>>=20
>> I wouldn't want to bake -1 into json-pointer. I think it shoul=
d remain in json-patch.
>>=20
>> Paul
>>=20
>> _______________________________________________
>> apps-discuss mailing list
>> apps-di=
scuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>=20
>>=20
>=20
>=20

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
















--005045015484be0d8a04cc365595--

From mnot@mnot.net  Tue Oct 16 17:30:09 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEECA1F0C49 for ; Tue, 16 Oct 2012 17:30:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.178
X-Spam-Level: 
X-Spam-Status: No, score=-104.178 tagged_above=-999 required=5 tests=[AWL=-1.579, 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 UcuH-6kiZF6Y for ; Tue, 16 Oct 2012 17:30:09 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id BEAAA1F0C42 for ; Tue, 16 Oct 2012 17:30:08 -0700 (PDT)
Received: from [192.168.1.72] (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B252222E257; Tue, 16 Oct 2012 20:30:00 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: 
Date: Wed, 17 Oct 2012 11:29:53 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com> <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114FDCF0C2D@WSMSG3153V.srv.dir.telstra.com> <1350403207.2540.1.camel@pbryan-wsl.internal.salesforce.com>  <1350406832.2540.3.camel@pbryan-wsl.internal.salesforce.com>   <1350432753.2540.27.camel@pbryan-wsl.internal.salesforce.com> 
To: James M Snell 
X-Mailer: Apple Mail (2.1499)
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2012 00:30:10 -0000

OK, unless anyone yells (or speaks in a not-so-soft voice), I'll add a =
single "-" as "end of array" in pointer.

Cheers,


On 17/10/2012, at 11:27 AM, James M Snell  wrote:

> Hmm... that's a slippery slope, indeed. I think mechanisms such as the =
"test" operation and my proposals in the JSON Predicates draft give us =
plenty of options for testing values once they have been selected with a =
JSON Pointer. I don't think we need to go down the path of building =
predicate operations into the pointer itself.=20
>=20
> As for Mark's comment, I'm good with either negative indices in =
general or a single special case like "-" to indicate the end of the =
array. I agree the latter would be simpler (and therefore likely =
marginally better)
>=20
> Btw... If we do go with negative indices, the reference for the last =
element in the array really should be "-0" since we're using zero based =
arrays...
>=20
>   {"foo": ["a","b","c"]}
>=20
>   /foo/0  =3D> "a"
>   /foo/1  =3D> "b"
>   /foo/2  =3D> "c"
>=20
>   /foo/-0 =3D> "c"
>   /foo/-1 =3D> "b"
>   /foo/-2 =3D> "a"
>=20
>   /foo/-  =3D> (the end of the array past c)
>=20
>   [{"op": "set", "path": "/foo/-", "value": "d"},
>   {"op": "set", "path": "/foo/-0", "value": "e"},
>   {"op": "insert", "path": "/foo/1", "value": "f"}]
>=20
>   Would result in:
>=20
>   {"foo": ["a","f","b","e","d"]}
>=20
>=20
> - James=20
> =20
>=20
> On Tue, Oct 16, 2012 at 5:12 PM, Paul C. Bryan  =
wrote:
> Okay, if we're opening-up json-pointer to change, I think the other =
thing I'm seeing in other threads is a desire to identify an object that =
contains a specific member-value. Would you be open to discussing this? =
I know this pushes final call out even further, but we're discussing =
enhancements so I thought I'd put it out there.
>=20
> Paul
>=20
>=20
> On Wed, 2012-10-17 at 11:07 +1100, Mark Nottingham wrote:
>> I tend to agree that if we're going to do it, it should be in =
pointer.
>>=20
>> If it were left to me, I think I'd just have *one* special value =
whose semantics is "the end of the array." Simpler.
>>=20
>> Cheers,
>>=20
>>=20
>> On 17/10/2012, at 11:04 AM, James M Snell <
>> jasnell@gmail.com
>> > wrote:
>>=20
>> > Special handling when the path refers to a non-existent object is =
different than allowing for a json-patch specific variation in the =
pointer syntax itself. If we allow for the use of negative indices then =
that change should be baked in to json pointer itself. I see little harm =
in doing so.
>> >=20
>> > - James
>> >=20
>> > On Tue, Oct 16, 2012 at 10:00 AM, Paul C. Bryan <
>> pbryan@anode.ca
>> > wrote:
>> > We already have special semantics in json-patch for how to handle =
the case where the value doesn't exist (when it's being added). This =
seems like another case of handling a non-existing referenced value.
>> >=20
>> > Paul
>> >=20
>> >=20
>> > On Tue, 2012-10-16 at 09:57 -0700, James M Snell wrote:
>> >> Hmm... that would mean having to special case json-pointer =
expressions specifically for json-patch, which isn't great either. Why =
not simply bake it into json-pointer and be done with it? I'm sure =
json-patch is not the only place where it could be useful.
>> >>=20
>> >> On Tue, Oct 16, 2012 at 9:00 AM, Paul C. Bryan <
>> pbryan@anode.ca
>> > wrote:
>> >>> [snip]
>> >>>=20
>> >>=20
>> >>=20
>> >> I wouldn't want to bake -1 into json-pointer. I think it should =
remain in json-patch.
>> >>=20
>> >> Paul
>> >>=20
>> >> _______________________________________________
>> >> apps-discuss mailing list
>> >>=20
>> apps-discuss@ietf.org
>>=20
>> >>=20
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>=20
>> >>=20
>> >>=20
>> >=20
>> >=20
>>=20
>> --
>> Mark Nottingham  =20
>> http://www.mnot.net/
>>=20
>>=20
>>=20
>>=20
>>=20
>=20
>=20

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




From James.H.Manger@team.telstra.com  Tue Oct 16 17:33:53 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BE621F856C for ; Tue, 16 Oct 2012 17:33:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Level: 
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[AWL=0.031,  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 z8AzGn7rCl6v for ; Tue, 16 Oct 2012 17:33:52 -0700 (PDT)
Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3E45A21F8550 for ; Tue, 16 Oct 2012 17:33:51 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,597,1344175200"; d="scan'208";a="96743475"
Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 17 Oct 2012 11:33:50 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6867"; a="43074572"
Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcani.tcif.telstra.com.au with ESMTP; 17 Oct 2012 11:33:49 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Wed, 17 Oct 2012 11:33:49 +1100
From: "Manger, James H" 
To: Mark Nottingham , James M Snell 
Date: Wed, 17 Oct 2012 11:33:48 +1100
Thread-Topic: [apps-discuss] json-patch: "op":"insert" and "op":"put"
Thread-Index: Ac2r+2S1QD3T7akPSc6aOt2bFdp2QAAAOYwA
Message-ID: <255B9BB34FB7D647A506DC292726F6E114FDD51871@WSMSG3153V.srv.dir.telstra.com>
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com> <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114FDCF0C2D@WSMSG3153V.srv.dir.telstra.com> <1350403207.2540.1.camel@pbryan-wsl.internal.salesforce.com>  <1350406832.2540.3.camel@pbryan-wsl.internal.salesforce.com>  
In-Reply-To: 
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2012 00:33:53 -0000

Kk9uZSogc3BlY2lhbCB2YWx1ZSBtaWdodCB3b3JrIHdlbGwuDQpEZWZpbmUgaXQgYXMgYSBwb2lu
dGVyIHRvIHRoZSBpbmRleCBqdXN0ICpiZXlvbmQqIHRoZSBlbmQgb2YgYW4gYXJyYXkgKG5vdCB0
byB0aGUgbGFzdCBpdGVtIGluIHRoZSBhcnJheSkuDQpUaGF0IHdheSBpdCBuZXZlciBpZGVudGlm
aWVzIGEgdmFsdWUgaW4gYSBKU09OIGRvYy4gQW55IHZhbHVlIHN0aWxsIGhhcyBhIHVuaXF1ZSBw
b2ludGVyLg0KSXQgaXMgb25seSB1c2VmdWwgZm9yIGlkZW50aWZ5aW5nIGEgcG9pbnQgYmVmb3Jl
IHdoaWNoIHRvIGluc2VydCBhIHZhbHVlLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg0KPiAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJrIE5vdHRpbmdoYW0gW21haWx0bzpt
bm90QG1ub3QubmV0XQ0KPiBTZW50OiBXZWRuZXNkYXksIDE3IE9jdG9iZXIgMjAxMiAxMTowNyBB
TQ0KPiBUbzogSmFtZXMgTSBTbmVsbA0KPiBDYzogUGF1bCBDLiBCcnlhbjsgTWFuZ2VyLCBKYW1l
cyBIOyBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3Nd
IGpzb24tcGF0Y2g6ICJvcCI6Imluc2VydCIgYW5kICJvcCI6InB1dCINCj4gDQo+IEkgdGVuZCB0
byBhZ3JlZSB0aGF0IGlmIHdlJ3JlIGdvaW5nIHRvIGRvIGl0LCBpdCBzaG91bGQgYmUgaW4gcG9p
bnRlci4NCj4gDQo+IElmIGl0IHdlcmUgbGVmdCB0byBtZSwgSSB0aGluayBJJ2QganVzdCBoYXZl
ICpvbmUqIHNwZWNpYWwgdmFsdWUgd2hvc2UNCj4gc2VtYW50aWNzIGlzICJ0aGUgZW5kIG9mIHRo
ZSBhcnJheS4iIFNpbXBsZXIuDQo+IA0KPiBDaGVlcnMsDQo+IA0KPiANCj4gT24gMTcvMTAvMjAx
MiwgYXQgMTE6MDQgQU0sIEphbWVzIE0gU25lbGwgPGphc25lbGxAZ21haWwuY29tPiB3cm90ZToN
Cj4gDQo+ID4gU3BlY2lhbCBoYW5kbGluZyB3aGVuIHRoZSBwYXRoIHJlZmVycyB0byBhIG5vbi1l
eGlzdGVudCBvYmplY3QgaXMNCj4gZGlmZmVyZW50IHRoYW4gYWxsb3dpbmcgZm9yIGEganNvbi1w
YXRjaCBzcGVjaWZpYyB2YXJpYXRpb24gaW4gdGhlDQo+IHBvaW50ZXIgc3ludGF4IGl0c2VsZi4g
SWYgd2UgYWxsb3cgZm9yIHRoZSB1c2Ugb2YgbmVnYXRpdmUgaW5kaWNlcyB0aGVuDQo+IHRoYXQg
Y2hhbmdlIHNob3VsZCBiZSBiYWtlZCBpbiB0byBqc29uIHBvaW50ZXIgaXRzZWxmLiBJIHNlZSBs
aXR0bGUNCj4gaGFybSBpbiBkb2luZyBzby4NCj4gPg0KPiA+IC0gSmFtZXMNCj4gPg0KPiA+IE9u
IFR1ZSwgT2N0IDE2LCAyMDEyIGF0IDEwOjAwIEFNLCBQYXVsIEMuIEJyeWFuIDxwYnJ5YW5AYW5v
ZGUuY2E+DQo+IHdyb3RlOg0KPiA+IFdlIGFscmVhZHkgaGF2ZSBzcGVjaWFsIHNlbWFudGljcyBp
biBqc29uLXBhdGNoIGZvciBob3cgdG8gaGFuZGxlIHRoZQ0KPiBjYXNlIHdoZXJlIHRoZSB2YWx1
ZSBkb2Vzbid0IGV4aXN0ICh3aGVuIGl0J3MgYmVpbmcgYWRkZWQpLiBUaGlzIHNlZW1zDQo+IGxp
a2UgYW5vdGhlciBjYXNlIG9mIGhhbmRsaW5nIGEgbm9uLWV4aXN0aW5nIHJlZmVyZW5jZWQgdmFs
dWUuDQo+ID4NCj4gPiBQYXVsDQo+ID4NCj4gPg0KPiA+IE9uIFR1ZSwgMjAxMi0xMC0xNiBhdCAw
OTo1NyAtMDcwMCwgSmFtZXMgTSBTbmVsbCB3cm90ZToNCj4gPj4gSG1tLi4uIHRoYXQgd291bGQg
bWVhbiBoYXZpbmcgdG8gc3BlY2lhbCBjYXNlIGpzb24tcG9pbnRlcg0KPiBleHByZXNzaW9ucyBz
cGVjaWZpY2FsbHkgZm9yIGpzb24tcGF0Y2gsIHdoaWNoIGlzbid0IGdyZWF0IGVpdGhlci4gV2h5
DQo+IG5vdCBzaW1wbHkgYmFrZSBpdCBpbnRvIGpzb24tcG9pbnRlciBhbmQgYmUgZG9uZSB3aXRo
IGl0PyBJJ20gc3VyZQ0KPiBqc29uLXBhdGNoIGlzIG5vdCB0aGUgb25seSBwbGFjZSB3aGVyZSBp
dCBjb3VsZCBiZSB1c2VmdWwuDQo+ID4+DQo+ID4+IE9uIFR1ZSwgT2N0IDE2LCAyMDEyIGF0IDk6
MDAgQU0sIFBhdWwgQy4gQnJ5YW4gPHBicnlhbkBhbm9kZS5jYT4NCj4gd3JvdGU6DQo+ID4+PiBb
c25pcF0NCj4gPj4+DQo+ID4+DQo+ID4+DQo+ID4+IEkgd291bGRuJ3Qgd2FudCB0byBiYWtlIC0x
IGludG8ganNvbi1wb2ludGVyLiBJIHRoaW5rIGl0IHNob3VsZA0KPiByZW1haW4gaW4ganNvbi1w
YXRjaC4NCj4gPj4NCj4gPj4gUGF1bA0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBhcHBzLWRpc2N1c3MgbWFpbGluZyBsaXN0
DQo+ID4+IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw0KPiA+Pg0KPiA+Pg0KPiA+DQo+ID4NCj4gDQo+
IC0tDQo+IE1hcmsgTm90dGluZ2hhbSAgIGh0dHA6Ly93d3cubW5vdC5uZXQvDQo+IA0KPiANCg0K

From mnot@mnot.net  Tue Oct 16 17:35:23 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B988C21F86EE for ; Tue, 16 Oct 2012 17:35:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.146
X-Spam-Level: 
X-Spam-Status: No, score=-104.146 tagged_above=-999 required=5 tests=[AWL=-1.547, 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 1OZpUpzPZVgd for ; Tue, 16 Oct 2012 17:35:23 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0B83321F85C4 for ; Tue, 16 Oct 2012 17:35:23 -0700 (PDT)
Received: from [192.168.1.72] (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7046022E256; Tue, 16 Oct 2012 20:35:13 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FDD51871@WSMSG3153V.srv.dir.telstra.com>
Date: Wed, 17 Oct 2012 11:35:07 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8F1E08F1-1648-46A8-818E-3F0D3F4B027A@mnot.net>
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com> <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114FDCF0C2D@WSMSG3153V.srv.dir.telstra.com> <1350403207.2540.1.camel@pbryan-wsl.internal.salesforce.com>  <1350406832.2540.3.camel@pbryan-wsl.internal.salesforce.com>   <255B9BB34FB7D647A506DC292726F6E114FDD51871@WSMSG3153V.srv.dir.telstra.com>
To: "Manger, James H" 
X-Mailer: Apple Mail (2.1499)
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2012 00:35:23 -0000

That might make the language tricker (since we talk about moving members =
when there's a reference to a non-existant member), but I'll give it a =
go.

Cheers,


On 17/10/2012, at 11:33 AM, "Manger, James H" =
 wrote:

> *One* special value might work well.
> Define it as a pointer to the index just *beyond* the end of an array =
(not to the last item in the array).
> That way it never identifies a value in a JSON doc. Any value still =
has a unique pointer.
> It is only useful for identifying a point before which to insert a =
value.
>=20
> --
> James Manger
>=20
>=20
>> -----Original Message-----
>> From: Mark Nottingham [mailto:mnot@mnot.net]
>> Sent: Wednesday, 17 October 2012 11:07 AM
>> To: James M Snell
>> Cc: Paul C. Bryan; Manger, James H; apps-discuss@ietf.org
>> Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
>>=20
>> I tend to agree that if we're going to do it, it should be in =
pointer.
>>=20
>> If it were left to me, I think I'd just have *one* special value =
whose
>> semantics is "the end of the array." Simpler.
>>=20
>> Cheers,
>>=20
>>=20
>> On 17/10/2012, at 11:04 AM, James M Snell  wrote:
>>=20
>>> Special handling when the path refers to a non-existent object is
>> different than allowing for a json-patch specific variation in the
>> pointer syntax itself. If we allow for the use of negative indices =
then
>> that change should be baked in to json pointer itself. I see little
>> harm in doing so.
>>>=20
>>> - James
>>>=20
>>> On Tue, Oct 16, 2012 at 10:00 AM, Paul C. Bryan 
>> wrote:
>>> We already have special semantics in json-patch for how to handle =
the
>> case where the value doesn't exist (when it's being added). This =
seems
>> like another case of handling a non-existing referenced value.
>>>=20
>>> Paul
>>>=20
>>>=20
>>> On Tue, 2012-10-16 at 09:57 -0700, James M Snell wrote:
>>>> Hmm... that would mean having to special case json-pointer
>> expressions specifically for json-patch, which isn't great either. =
Why
>> not simply bake it into json-pointer and be done with it? I'm sure
>> json-patch is not the only place where it could be useful.
>>>>=20
>>>> On Tue, Oct 16, 2012 at 9:00 AM, Paul C. Bryan 
>> wrote:
>>>>> [snip]
>>>>>=20
>>>>=20
>>>>=20
>>>> I wouldn't want to bake -1 into json-pointer. I think it should
>> remain in json-patch.
>>>>=20
>>>> Paul
>>>>=20
>>>> _______________________________________________
>>>> apps-discuss mailing list
>>>> apps-discuss@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>=20
>>>>=20
>>>=20
>>>=20
>>=20
>> --
>> Mark Nottingham   http://www.mnot.net/
>>=20
>>=20
>=20

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




From pbryan@anode.ca  Tue Oct 16 20:39:21 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B119821F867C for ; Tue, 16 Oct 2012 20:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.389
X-Spam-Level: 
X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.209,  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 muy4Ox19Bxyg for ; Tue, 16 Oct 2012 20:39:20 -0700 (PDT)
Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id A6D5421F8624 for ; Tue, 16 Oct 2012 20:39:20 -0700 (PDT)
Received: from [192.168.1.10] (S0106a021b762dbb3.vf.shawcable.net [174.1.50.247]) by maple.anode.ca (Postfix) with ESMTPSA id AD3AE6452; Wed, 17 Oct 2012 03:39:19 +0000 (UTC)
Message-ID: <1350445158.10848.1.camel@smazz>
From: "Paul C. Bryan" 
To: Mark Nottingham 
Date: Tue, 16 Oct 2012 20:39:18 -0700
In-Reply-To: 
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E2B@WSMSG3153V.srv.dir.telstra.com>  <255B9BB34FB7D647A506DC292726F6E114FDC64230@WSMSG3153V.srv.dir.telstra.com> <5ACC3110-377B-48FD-BDCD-EBE67638E532@mnot.net> <255B9BB34FB7D647A506DC292726F6E114FDC64412@WSMSG3153V.srv.dir.telstra.com> <1350319030.19167.12.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114FDCF0C2D@WSMSG3153V.srv.dir.telstra.com> <1350403207.2540.1.camel@pbryan-wsl.internal.salesforce.com>  <1350406832.2540.3.camel@pbryan-wsl.internal.salesforce.com>   <1350432753.2540.27.camel@pbryan-wsl.internal.salesforce.com>  
Content-Type: multipart/alternative; boundary="=-Xnzl+Y5+SsoQbDNUuCrm"
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"insert" and "op":"put"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2012 03:39:21 -0000

--=-Xnzl+Y5+SsoQbDNUuCrm
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Grumble mumble...

On Wed, 2012-10-17 at 11:29 +1100, Mark Nottingham wrote:

> OK, unless anyone yells (or speaks in a not-so-soft voice), I'll add a single "-" as "end of array" in pointer.
> 
> Cheers,
> 
> 
> On 17/10/2012, at 11:27 AM, James M Snell  wrote:
> 
> > Hmm... that's a slippery slope, indeed. I think mechanisms such as the "test" operation and my proposals in the JSON Predicates draft give us plenty of options for testing values once they have been selected with a JSON Pointer. I don't think we need to go down the path of building predicate operations into the pointer itself. 
> > 
> > As for Mark's comment, I'm good with either negative indices in general or a single special case like "-" to indicate the end of the array. I agree the latter would be simpler (and therefore likely marginally better)
> > 
> > Btw... If we do go with negative indices, the reference for the last element in the array really should be "-0" since we're using zero based arrays...
> > 
> >   {"foo": ["a","b","c"]}
> > 
> >   /foo/0  => "a"
> >   /foo/1  => "b"
> >   /foo/2  => "c"
> > 
> >   /foo/-0 => "c"
> >   /foo/-1 => "b"
> >   /foo/-2 => "a"
> > 
> >   /foo/-  => (the end of the array past c)
> > 
> >   [{"op": "set", "path": "/foo/-", "value": "d"},
> >   {"op": "set", "path": "/foo/-0", "value": "e"},
> >   {"op": "insert", "path": "/foo/1", "value": "f"}]
> > 
> >   Would result in:
> > 
> >   {"foo": ["a","f","b","e","d"]}
> > 
> > 
> > - James 
> >  
> > 
> > On Tue, Oct 16, 2012 at 5:12 PM, Paul C. Bryan  wrote:
> > Okay, if we're opening-up json-pointer to change, I think the other thing I'm seeing in other threads is a desire to identify an object that contains a specific member-value. Would you be open to discussing this? I know this pushes final call out even further, but we're discussing enhancements so I thought I'd put it out there.
> > 
> > Paul
> > 
> > 
> > On Wed, 2012-10-17 at 11:07 +1100, Mark Nottingham wrote:
> >> I tend to agree that if we're going to do it, it should be in pointer.
> >> 
> >> If it were left to me, I think I'd just have *one* special value whose semantics is "the end of the array." Simpler.
> >> 
> >> Cheers,
> >> 
> >> 
> >> On 17/10/2012, at 11:04 AM, James M Snell <
> >> jasnell@gmail.com
> >> > wrote:
> >> 
> >> > Special handling when the path refers to a non-existent object is different than allowing for a json-patch specific variation in the pointer syntax itself. If we allow for the use of negative indices then that change should be baked in to json pointer itself. I see little harm in doing so.
> >> > 
> >> > - James
> >> > 
> >> > On Tue, Oct 16, 2012 at 10:00 AM, Paul C. Bryan <
> >> pbryan@anode.ca
> >> > wrote:
> >> > We already have special semantics in json-patch for how to handle the case where the value doesn't exist (when it's being added). This seems like another case of handling a non-existing referenced value.
> >> > 
> >> > Paul
> >> > 
> >> > 
> >> > On Tue, 2012-10-16 at 09:57 -0700, James M Snell wrote:
> >> >> Hmm... that would mean having to special case json-pointer expressions specifically for json-patch, which isn't great either. Why not simply bake it into json-pointer and be done with it? I'm sure json-patch is not the only place where it could be useful.
> >> >> 
> >> >> On Tue, Oct 16, 2012 at 9:00 AM, Paul C. Bryan <
> >> pbryan@anode.ca
> >> > wrote:
> >> >>> [snip]
> >> >>> 
> >> >> 
> >> >> 
> >> >> I wouldn't want to bake -1 into json-pointer. I think it should remain in json-patch.
> >> >> 
> >> >> Paul
> >> >> 
> >> >> _______________________________________________
> >> >> 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/
> 
> 
> 



--=-Xnzl+Y5+SsoQbDNUuCrm
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


Grumble mumble...



On Wed, 2012-10-17 at 11:29 +1100, Mark Nottingham wrote:



OK, unless anyone yells (or speaks in a not-so-soft voice), I'll add a single "-" as "end of array" in pointer.

Cheers,


On 17/10/2012, at 11:27 AM, James M Snell <jasnell@gmail.com> wrote:

> Hmm... that's a slippery slope, indeed. I think mechanisms such as the "test" operation and my proposals in the JSON Predicates draft give us plenty of options for testing values once they have been selected with a JSON Pointer. I don't think we need to go down the path of building predicate operations into the pointer itself. 
> 
> As for Mark's comment, I'm good with either negative indices in general or a single special case like "-" to indicate the end of the array. I agree the latter would be simpler (and therefore likely marginally better)
> 
> Btw... If we do go with negative indices, the reference for the last element in the array really should be "-0" since we're using zero based arrays...
> 
>   {"foo": ["a","b","c"]}
> 
>   /foo/0  => "a"
>   /foo/1  => "b"
>   /foo/2  => "c"
> 
>   /foo/-0 => "c"
>   /foo/-1 => "b"
>   /foo/-2 => "a"
> 
>   /foo/-  => (the end of the array past c)
> 
>   [{"op": "set", "path": "/foo/-", "value": "d"},
>   {"op": "set", "path": "/foo/-0", "value": "e"},
>   {"op": "insert", "path": "/foo/1", "value": "f"}]
> 
>   Would result in:
> 
>   {"foo": ["a","f","b","e","d"]}
> 
> 
> - James 
>  
> 
> On Tue, Oct 16, 2012 at 5:12 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
> Okay, if we're opening-up json-pointer to change, I think the other thing I'm seeing in other threads is a desire to identify an object that contains a specific member-value. Would you be open to discussing this? I know this pushes final call out even further, but we're discussing enhancements so I thought I'd put it out there.
> 
> Paul
> 
> 
> On Wed, 2012-10-17 at 11:07 +1100, Mark Nottingham wrote:
>> I tend to agree that if we're going to do it, it should be in pointer.
>> 
>> If it were left to me, I think I'd just have *one* special value whose semantics is "the end of the array." Simpler.
>> 
>> Cheers,
>> 
>> 
>> On 17/10/2012, at 11:04 AM, James M Snell <
>> jasnell@gmail.com
>> > wrote:
>> 
>> > Special handling when the path refers to a non-existent object is different than allowing for a json-patch specific variation in the pointer syntax itself. If we allow for the use of negative indices then that change should be baked in to json pointer itself. I see little harm in doing so.
>> > 
>> > - James
>> > 
>> > On Tue, Oct 16, 2012 at 10:00 AM, Paul C. Bryan <
>> pbryan@anode.ca
>> > wrote:
>> > We already have special semantics in json-patch for how to handle the case where the value doesn't exist (when it's being added). This seems like another case of handling a non-existing referenced value.
>> > 
>> > Paul
>> > 
>> > 
>> > On Tue, 2012-10-16 at 09:57 -0700, James M Snell wrote:
>> >> Hmm... that would mean having to special case json-pointer expressions specifically for json-patch, which isn't great either. Why not simply bake it into json-pointer and be done with it? I'm sure json-patch is not the only place where it could be useful.
>> >> 
>> >> On Tue, Oct 16, 2012 at 9:00 AM, Paul C. Bryan <
>> pbryan@anode.ca
>> > wrote:
>> >>> [snip]
>> >>> 
>> >> 
>> >> 
>> >> I wouldn't want to bake -1 into json-pointer. I think it should remain in json-patch.
>> >> 
>> >> Paul
>> >> 
>> >> _______________________________________________
>> >> 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/












--=-Xnzl+Y5+SsoQbDNUuCrm--


From barryleiba@gmail.com  Wed Oct 17 19:25:18 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D553A21F85A0; Wed, 17 Oct 2012 19:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.063
X-Spam-Level: 
X-Spam-Status: No, score=-103.063 tagged_above=-999 required=5 tests=[AWL=-0.086, 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 BQ-zbS5vzQt9; Wed, 17 Oct 2012 19:25:17 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F264C21F858F; Wed, 17 Oct 2012 19:25:16 -0700 (PDT)
Received: by mail-vb0-f44.google.com with SMTP id fc26so9059434vbb.31 for ; Wed, 17 Oct 2012 19:25:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=wDQUSB9tpDe14FGwx645Vg/vnew7n8nYqFeGQB6O4aE=; b=rzY++5GMc6OqwX7RSVaS0nPa7hZGiYaEfPteBu1izozhiDV8oX3vMDA/cUhjP4/ofb fDLLB3IIn0+mmvfVB6kQgp6IMPufbLHBhLS73XaHs+GOZdn7WkPXNo22dSH8WebcPRGi ypyZ7prrfaAYqaXfcIo4rCIkOZg93lHz+8rZIKqAtd2do3Sgkw+1a25gYF7efyX8XOuJ /WcOeYevY30MH5+sQPxvViYnWkNx/EbGs/06Gr4KkcKWIVJIXUiuBfQu7tjuTAYK8BGw YOhluEo8kV7W3AbBWqjV0K9UzTEFiH93lPknyQSozjviJ3vEluNu6InCEh3kSfhi8oFh DgJg==
MIME-Version: 1.0
Received: by 10.220.220.5 with SMTP id hw5mr2987796vcb.53.1350527116394; Wed, 17 Oct 2012 19:25:16 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.58.28.231 with HTTP; Wed, 17 Oct 2012 19:25:16 -0700 (PDT)
Date: Wed, 17 Oct 2012 22:25:16 -0400
X-Google-Sender-Auth: FotLzZ0QiWKnuBHTBtR-wzeeV4Y
Message-ID: 
From: Barry Leiba 
To: http-state@ietf.org, websec@ietf.org, ietf-http-wg@w3.org,  apps-discuss@ietf.org, oauth@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [apps-discuss] Input for conflict review of draft-secure-cookie-session-protocol
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: saag@ietf.org
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2012 02:25:18 -0000

A document titled "Secure Cookie Sessions for HTTP" has been submitted
to the Independent Stream Editor (ISE):
http://datatracker.ietf.org/doc/draft-secure-cookie-session-protocol/

The IESG has been asked to review the document, as specified in RFC
5742, Section 3.  The Security and Applications Area Directors are
looking for input for that review.  Please post any relevant comments
to the Security Area list, , as soon as possible, and at
least by 1 November 2012.

Note: Please do NOT post responses to any of these mailing lists.
Respond only to  (using the subject line of this
message).

Please read RFC 5742, Section 3, and be aware that we are not looking
for detailed comments on the document itself (see below).  We
specifically need input on whether this document is in conflict with
work that's being done in the IETF.  Look at the five possible
responses specified in that section, and help us determine whether any
of 2 through 5 applies.  Please be specific in your response.

In addition to this, we're sure that the authors and the ISE would
appreciate comments about the document.  If you have those, you may
send them directly to the authors at

and to the ISE at .
General discussion of the document on these lists or the saag list will
likely not get to the authors or the ISE.

Barry Leiba, Applications AD

From jasnell@gmail.com  Thu Oct 18 10:22:10 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F50721F8781 for ; Thu, 18 Oct 2012 10:22:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.833
X-Spam-Level: 
X-Spam-Status: No, score=-4.833 tagged_above=-999 required=5 tests=[AWL=-1.235, 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 MxejVT6fwhTr for ; Thu, 18 Oct 2012 10:22:09 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 50D5521F8786 for ; Thu, 18 Oct 2012 10:22:09 -0700 (PDT)
Received: by mail-qa0-f51.google.com with SMTP id j40so1469377qab.10 for ; Thu, 18 Oct 2012 10:22:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=hQf+aKPObe2gPcI885xasHtdOzFvKgf97yahW0bycjY=; b=glohWj7NcQcV4kEx0byht2J3EW4CP3bdTorth5bPGzUXZp/b5izfbA1DLzTh0yPXuy vHAPV9NoaJ5QzaTxbtWFI320bxIfIxMNlaSZLK/zwkyWF1X9Nj5mQOD3fiOHOAr/Gl1h mEp5xsld/sJk3S5GOJW76ZZxBBRrpodgqKxW2+IkdPLTRjcbX2Bu6QltUhFUe2XFtt9Z 1oXgUR4JRh5f+40M5OAC2WdEjs3Orfb1g6FIczZrNE22x2L62bcni2a/V6MK+yKObKAi 2s9cPQWo5nzHGn3mdJLcmI2o+DpEGv1tABGMzYpqMoXRlM59XfU2PVVZJsSH45W886IH LHtw==
Received: by 10.49.5.9 with SMTP id o9mr46333035qeo.55.1350580928858; Thu, 18 Oct 2012 10:22:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.81.230 with HTTP; Thu, 18 Oct 2012 10:21:48 -0700 (PDT)
From: James M Snell 
Date: Thu, 18 Oct 2012 10:21:48 -0700
Message-ID: 
To: IETF Apps Discuss 
Content-Type: multipart/alternative; boundary=047d7bea32da8149ad04cc58a005
Subject: [apps-discuss] Updated 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, 18 Oct 2012 17:22:10 -0000

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

Based on received feedback, mostly editorial modifications and a few
updates to the rules to cover a couple additional cases (thanks to James
Manger for pointing out the gaps and providing new language for the intro).

  http://www.ietf.org/id/draft-snell-merge-patch-05.txt

- James

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

Based on received feedback, mostly edi=
torial modifications and a few updates to the rules to cover a couple addit=
ional cases (thanks to James Manger for pointing out the gaps and providing=
 new language for the intro).







- James


--047d7bea32da8149ad04cc58a005--

From jasnell@gmail.com  Thu Oct 18 14:56:56 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F2221F8505 for ; Thu, 18 Oct 2012 14:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.784
X-Spam-Level: 
X-Spam-Status: No, score=-4.784 tagged_above=-999 required=5 tests=[AWL=-1.186, 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 kwE7xxZPRrBK for ; Thu, 18 Oct 2012 14:56:55 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFB721F8419 for ; Thu, 18 Oct 2012 14:56:55 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id s14so8131527qcg.31 for ; Thu, 18 Oct 2012 14:56:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=SPzBm3ICfk48W0/MJcVo/Guw8PZcDJvg5iC7cbQAKDg=; b=Q527sGBgWw/zFjsaIsIhQMJo997pchUvxwfSCxDkzYvwQRFJ9Yivd+gBMcy1kwgFAd QMTcUNPziFsCL5bu5xuq+fUtstd5FQwyXvnr64Ozqi+ch0FGUpo+KQS7dvhQGwg/rHtF usz+D8PLXPs9uPua9nIV14DuPf5cPNv8i9KZFLdn9kB3bYWJ7Wu+AyJDerZ0Gi+D+qGR svta2/jTNX2xbzPlS7t8ASF28velcoUT1qn30rWx6ZjBj0tbQtRJhxuEP3drdMnYR4v9 6QnU6a2p2a5EMdKQAi2x1A+RQlCVvCWE1i826gOWZqhPhI+d6wGosqoQ9pVxA8Hh+7no 0fTQ==
Received: by 10.229.137.85 with SMTP id v21mr9230048qct.17.1350597414711; Thu, 18 Oct 2012 14:56:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.81.230 with HTTP; Thu, 18 Oct 2012 14:56:34 -0700 (PDT)
From: James M Snell 
Date: Thu, 18 Oct 2012 14:56:34 -0700
Message-ID: 
To: IETF Apps Discuss 
Content-Type: multipart/alternative; boundary=00235452e9602372b004cc5c77b8
Subject: [apps-discuss] Update to 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: Thu, 18 Oct 2012 21:56:56 -0000

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

Based on some initial direct feedback I received on the -00 draft, I have
submitted an updated draft..

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

Several key modifications were made..

 1. Specific mention is made re: the use of the JSON-Patch "test" operation
as a Predicate with the addition of an optional "ignore_case" member
consistent with the other text comparison predicates.

 2. Addition of an "in" predicate operation that tests whether the value is
part of a given list of values.. for instance:

    {"op": "in", "path": "/a/b/c", "value": [1,2,3,4,5]}

    Returns true if the value of "/a/b/c" is in the array [1,2,3,4,5]

 3. Additional types for the "type" predicate operation including: date,
time, date-time, lang, lang-range, iri and absolute-iri. These are intended
to test if a JSON string conforms to a specific set of common RFC defined
data types. The types are drawn from RFC's 3339, 3987, 4646, and 4647.
These types are common to many JSON data formats.

    {"op": "type", "path": "/a/b/c", "value": "date-time"}

    Returns true if the value of "/a/b/c" is an RFC3339 date-time like
"2012-12-12T12:12:12Z"

    {"op": "type", "path": "/a/b/c", "value": "absolute-iri"}

    Returns true if the value of "/a/b/c" is an Absolute IRI reference like
"http://example.org/foo"

    {"op": "type", "path": "/a/b/c", "value": "lang"}

    Returns true if the value of "/a/b/c" is a Language Tag like "en-US"

4. Several clarifications and editorial fixes were made.

As always, comments are welcome. Unless there are significant changes made
to JSON Patch or significant issues found with this specification, I do not
anticipate making any further technical changes.

- James

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

Based on some initial direct feedback =
I received on the -00 draft, I have submitted an updated draft..




Several key modifications were made..

=C2=A01. Specific mention is made re: the us=
e of the JSON-Patch "test" operation as a Predicate with the addi=
tion of an optional "ignore_case" member consistent with the othe=
r text comparison predicates.




=C2=A02. Addition of an "in" predicat=
e operation that tests whether the value is part of a given list of values.=
. for instance:




=C2=A0 =C2=A0 {"op": "in", =
"path": "/a/b/c", "value": [1,2,3,4,5]}



=C2=A0 =C2=A0 Returns true if the value of "/a/=
b/c" is in the array [1,2,3,4,5]




=C2=A03. Additional=
 types for the "type" predicate operation including: date, time, =
date-time, lang, lang-range, iri and absolute-iri. These are intended to te=
st if a JSON string conforms to a specific set of common RFC defined data t=
ypes. The types are drawn from RFC's 3339, 3987, 4646, and 4647. These =
types are common to many JSON data formats.




=C2=A0 =C2=A0 {"op": "type"=
, "path": "/a/b/c", "value": "date-time&=
quot;}




=C2=A0 =C2=A0 Returns true if the value of &quo=
t;/a/b/c" is an RFC3339 date-time like "2012-12-12T12:12:12Z"=
;




=C2=A0 =C2=A0 {"op": "type"=
, "path": "/a/b/c", "value": "absolute-i=
ri"}




=C2=A0 =C2=A0 Returns true if the value of &quo=
t;/a/b/c" is an Absolute IRI reference like "http://example.org/foo"




=C2=A0 =C2=A0 {"op": "type"=
, "path": "/a/b/c", "value": "lang"=
}




=C2=A0 =C2=A0 Returns true if the value of &quo=
t;/a/b/c" is a Language Tag like "en-US"




4. Several clarific=
ations and editorial fixes were made.

As always, comments are welcome. Unless there are significant changes ma=
de to JSON Patch or significant issues found with this specification, I do =
not anticipate making any further technical changes.




- James


--00235452e9602372b004cc5c77b8--

From James.H.Manger@team.telstra.com  Thu Oct 18 17:13:43 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E1E21F8493 for ; Thu, 18 Oct 2012 17:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.872
X-Spam-Level: 
X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[AWL=0.028,  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 73XJSgVV0q5t for ; Thu, 18 Oct 2012 17:13:43 -0700 (PDT)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id A592521F8491 for ; Thu, 18 Oct 2012 17:13:41 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,610,1344175200"; d="scan'208,217";a="99121466"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 19 Oct 2012 11:13:39 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6869"; a="93842354"
Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcdvi.tcif.telstra.com.au with ESMTP; 19 Oct 2012 11:13:38 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Fri, 19 Oct 2012 11:13:38 +1100
From: "Manger, James H" 
To: James M Snell , IETF Apps Discuss 
Date: Fri, 19 Oct 2012 11:13:36 +1100
Thread-Topic: [apps-discuss] Updated Merge Patch
Thread-Index: Ac2tVR+4n2TXmXx7Qi+0gzHigeD0RgAKWihw
Message-ID: <255B9BB34FB7D647A506DC292726F6E114FDE43DC2@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_255B9BB34FB7D647A506DC292726F6E114FDE43DC2WSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: Re: [apps-discuss] Updated 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: Fri, 19 Oct 2012 00:13:44 -0000

--_000_255B9BB34FB7D647A506DC292726F6E114FDE43DC2WSMSG3153Vsrv_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SmFtZXMsDQoNCmRyYWZ0LXNuZWxsLW1lcmdlLXBhdGNoLTA1IGxvb2tzIGJldHRlciwgYnV0IGlz
IG5vdCBxdWl0ZSByaWdodC4NCg0KwqcyIHN0ZXAgMQ0KIElmIGVpdGhlciB0aGUgcm9vdCBvZiB0
aGUgSlNPTiBkYXRhIHByb3ZpZGVkIGluIHRoZSBwYXlsb2FkIG9yDQogdGhlIHJvb3Qgb2YgdGhl
IHRhcmdldCByZXNvdXJjZSBhcmUgSlNPTiBBcnJheXMsIHRoZSB0YXJnZXQNCiByZXNvdXJjZSBp
cyB0byBiZSByZXBsYWNlZCwgaW4gd2hvbGUsIGJ5IHRoZSBwcm92aWRlZCBkYXRhLg0KSW1wbGll
cyAodGFyZ2V0ICsgbWVyZ2UgPSByZXN1bHQpOg0KWzEsMl0gKyB7ImEiOjMsICJiIjpudWxsfSA9
IHsiYSI6MywgImIiOm51bGx9DQpCdXQgdGhlIHJlc3VsdCBzaG91bGQgaW5zdGVhZCBiZSB7ImEi
OjN9Lg0KDQpUaGUgc2FtZSBtaXN0YWtlIGlzIG1hZGUgaW4gc3RlcCAyLCA0dGggZG90IHBvaW50
Lg0KDQpTdGVwIDEgY291bGQgYmUgcmV3cml0dGVuIGFzOg0KICDigJxJZiB0aGUgcm9vdCBvZiB0
aGUgcGF0Y2ggaXMgYSBzdHJpbmcsIG51bWJlciwgYm9vbGVhbiwgb3IgYXJyYXksIHRoZSB0YXJn
ZXQgaXMgcmVwbGFjZWQgd2l0aCB0aGUgcGF0Y2ggdmFsdWUu4oCdDQoNClRoaXMgcnVsZSBpcyBu
b3QgYWN0dWFsbHkgc3BlY2lmaWMgdG8gdGhlIHJvb3Qgc28gaXQgcHJvYmFibHkgZG9lc27igJl0
IG5lZWQgdG8gYmUgYSBzcGVjaWFsIGNhc2UuDQoNCg0KTXkgc3RhYiBhdCB0aGUgcHJvY2Vzc2lu
ZyBydWxlczoNCg0K4oCcVGhlIHByb2Nlc3Npbmcgc3RlcHMgd2FsayB0aHJvdWdoIHRoZSBvYmpl
Y3QgZWxlbWVudHMgaW4gdGhlIG1lcmdlLXBhdGNoIGRvY3VtZW50IGFuZCB0aGUgY29ycmVzcG9u
ZGluZyBlbGVtZW50cyBpbiB0aGUgZG9jdW1lbnQgYmVpbmcgbW9kaWZpZWQuIExldCDigJhwYXRj
aOKAmSBhbmQg4oCYdGFyZ2V04oCZIHJlcHJlc2VudCB0aGUgY3VycmVudCBwb3NpdGlvbiBpbiB0
aGVzZSBkb2N1bWVudHMgcmVzcGVjdGl2ZWx5LiBJbml0aWFsbHkg4oCYcGF0Y2jigJkgaXMgdGhl
IHJvb3Qgb2YgdGhlIG1lcmdlLXBhdGNoIGRvY3VtZW50LCBhbmQg4oCYdGFyZ2V04oCZIGlzIHRo
ZSByb290IG9mIHRoZSBkb2N1bWVudCBiZWluZyBtb2RpZmllZC4gQXQgYW55IHBvaW50IOKAmHRh
cmdldOKAmSBtYXkgbm90IGV4aXN0Lg0KDQoNCjEuICAgICAgIElmIHRoZSBwYXRjaCB2YWx1ZSBp
cyBudWxsOiByZW1vdmUgdGFyZ2V0Lg0KSXQgaXMgbm90IGFuIGVycm9yIGlmIHRhcmdldCBkb2Vz
IG5vdCBleGlzdCwgdGhlcmUgaXMgc2ltcGx5IG5vIG1vZGlmaWNhdGlvbiB0byBtYWtlLg0KUmVt
b3ZpbmcgdGhlIHJvb3QgbGVhdmVzIGFuIGVtcHR5IGRvY3VtZW50IChpZSBhIHJlc291cmNlIHdp
dGggYSBjb250ZW50LWxlbmd0aCBvZiAwKS4NCg0KMi4gICAgICAgT3RoZXJ3aXNlLCBpZiB0aGUg
cGF0Y2ggdmFsdWUgaXMgYSBzdHJpbmcsIG51bWJlciwgYm9vbGVhbiwgb3IgYXJyYXk6IHNldCB0
YXJnZXQgdG8gcGF0Y2guIFRoaXMgY3JlYXRlcyBhIG5ldyBvYmplY3QgZWxlbWVudCBpZiB0YXJn
ZXQgZGlkbuKAmXQgZXhpc3QsIG9yIHJlcGxhY2VzIHRhcmdldOKAmXMgdmFsdWUgaWYgaXQgZGlk
IGV4aXN0Lg0KDQozLiAgICAgICBPdGhlcndpc2UsIHRoZSBwYXRjaCB2YWx1ZSBpcyBhbiBvYmpl
Y3QuIFBlcmZvcm0gdGhlIG5leHQgdHdvIHN1Yi1zdGVwczoNCg0KYS4gICAgICAgSWYgdGFyZ2V0
IGRvZXMgbm90IGV4aXN0IG9yIGlmIGl0cyB2YWx1ZSBpcyBub3QgYW4gb2JqZWN0OiBzZXQgdGFy
Z2V0IHRvIGFuIGVsZW1lbnQgd2l0aCB0aGUgcGF0Y2ggbmFtZSwgYW5kIGFuIGVtcHR5IG9iamVj
dCBhcyBpdHMgdmFsdWUgKGllIHt9KS4NCkZvciB0aGUgcm9vdCB0aGVyZSBpc27igJl0IHJlYWxs
eSBhbiBlbGVtZW50IG5hbWUsIGp1c3QgYSB2YWx1ZS4NCg0KYi4gICAgICBGb3IgZWFjaCBlbGVt
ZW50IG9mIHRoZSBwYXRjaCB2YWx1ZSBvYmplY3Q6IHJlcGVhdCB0aGUgcHJvY2Vzc2luZyBzdGVw
cyB3aXRoIHBhdGNoIGJlaW5nIHRoYXQgZWxlbWVudCwgYW5kIHRhcmdldCBiZWluZyB0aGUgZWxl
bWVudCBvZiB0aGUgcHJldmlvdXMgdGFyZ2V0IHdpdGggdGhlIHNhbWUgbmFtZSAoaWYgc3VjaCBh
biBlbGVtZW50IGV4aXN0cykuDQrigJ0NCg0KVGhpcyBpcyBoYXJkZXIgdG8gd3JpdGUgaW4gRW5n
bGlzaCB0aGFuIGNvZGUhDQoNCg0KSXQgd291bGQgYmUgd29ydGggaW5jbHVkaW5nIGV4YW1wbGVz
IG9mIHRoZSBsZXNzIG9idmlvdXMgY2FzZXMuDQoNClRhcmdldCAgICsgbWVyZ2UgPSByZXN1bHQN
Cg0KeyJhIjpbMSx7ImJiIjoyLCAiY2MiOjN9XX0gKyB7ImEiOlsxLHsiYmIiOjQsICJjYyI6bnVs
bH1dfSA9IHsiYSI6WzEseyJiYiI6NCwgImNjIjpudWxsfV19DQogIChzaG93aW5nIHRoYXQgeW91
IGRvbuKAmXQgbWVyZ2Ugb2JqZWN0cyB3aXRoaW4gYW4gYXJyYXkpDQoNCnsiYSI6MX0gKyB7ImIi
OnsiY2MiOnsiZGRkIjpudWxsfX19ID0geyJhIjoxLCAiYiI6eyJjYyI6eyB9fX0NCiAgKHNob3dp
bmcgdGhhdCBvYmplY3RzIG9uIGEgcGF0aCBnZXQgY3JlYXRlZCAoc3RlcCAzYSksIGV2ZW4gaWYg
dGhlIG9ubHkgdGFza3MgYXQgdGhlIGVuZCBvZiB0aGUgcGF0aCB0dXJucyBvdXQgdG8gYmUgcmVt
b3ZpbmcgZWxlbWVudHMpDQoNClsxLDJdICsgeyJhIjozLCAiYiI6bnVsbH0gPSB7ImEiOjN9DQog
IChzaG93aW5nIHlvdSBzdGlsbCBoYXZlIHRvIHdhbGsgdGhyb3VnaCB0aGUgcGF0Y2gsIGV2ZW4g
d2hlbiB0aGUgY29ycmVzcG9uZGluZyBwYXJ0IG9mIHRoZSB0YXJnZXQgd2FzbuKAmXQgYWxzbyBh
biBvYmplY3QpDQoNCnsiYSI6MX0gKyBudWxsID0gPGVtcHR5Pg0KDQoNClNwbGl0dGluZyB0aGUg
cHJvY2Vzc2luZyBzdGVwcyBhbmQgdGhlIHdvcmtlZCBleGFtcGxlIChzZWN0aW9uIDIpIGludG8g
c2VwYXJhdGUgc2VjdGlvbnMgd291bGQgYmUgYW4gaW1wcm92ZW1lbnQuDQoNClRoZW4gY2FuIHdl
IGhhdmUgdGhpcyBvcGVyYXRpb24gaW4ganNvbi1wYXRjaDogeyJvcCI6Im1lcmdlIiwgInBhdGgi
Ojxwb2ludGVyPiwgInZhbHVlIjo8bWVyZ2UtcGF0Y2g+fT8NCg0KLS0NCkphbWVzIE1hbmdlcg0K
DQpGcm9tOiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vz
cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFtZXMgTSBTbmVsbA0KU2VudDogRnJp
ZGF5LCAxOSBPY3RvYmVyIDIwMTIgNDoyMiBBTQ0KVG86IElFVEYgQXBwcyBEaXNjdXNzDQpTdWJq
ZWN0OiBbYXBwcy1kaXNjdXNzXSBVcGRhdGVkIE1lcmdlIFBhdGNoDQoNCkJhc2VkIG9uIHJlY2Vp
dmVkIGZlZWRiYWNrLCBtb3N0bHkgZWRpdG9yaWFsIG1vZGlmaWNhdGlvbnMgYW5kIGEgZmV3IHVw
ZGF0ZXMgdG8gdGhlIHJ1bGVzIHRvIGNvdmVyIGEgY291cGxlIGFkZGl0aW9uYWwgY2FzZXMgKHRo
YW5rcyB0byBKYW1lcyBNYW5nZXIgZm9yIHBvaW50aW5nIG91dCB0aGUgZ2FwcyBhbmQgcHJvdmlk
aW5nIG5ldyBsYW5ndWFnZSBmb3IgdGhlIGludHJvKS4NCg0KICBodHRwOi8vd3d3LmlldGYub3Jn
L2lkL2RyYWZ0LXNuZWxsLW1lcmdlLXBhdGNoLTA1LnR4dA0KDQotIEphbWVzDQo=

--_000_255B9BB34FB7D647A506DC292726F6E114FDE43DC2WSMSG3153Vsrv_
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
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K
CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1z
b0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0
eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0
b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi
O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz
cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h
dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU
TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBE
ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9u
MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg
NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlz
dCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTUxNzAzODMxNDsNCglt
c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NzUyNjQ4NTYyIDIw
MTkxNjQzMSAyMDE5MTY0NDEgMjAxOTE2NDQzIDIwMTkxNjQzMSAyMDE5MTY0NDEgMjAxOTE2NDQz
IDIwMTkxNjQzMSAyMDE5MTY0NDEgMjAxOTE2NDQzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0Kb2wNCgl7
bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHls
ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi
IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+
PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0
IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48
Ym9keSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2Vj
dGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFtZXMsPG86
cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5
N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm
Ijtjb2xvcjojMUY0OTdEJz5kcmFmdC1zbmVsbC1tZXJnZS1wYXRjaC0wNSBsb29rcyBiZXR0ZXIs
IGJ1dCBpcyBub3QgcXVpdGUgcmlnaHQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z
b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CpzIgc3RlcCAxPG86
cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ncGFnZS1icmVhay1i
ZWZvcmU6YWx3YXlzJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xv
cjpibGFjayc+IMKgSWYgZWl0aGVyIHRoZSByb290IG9mIHRoZSBKU09OIGRhdGEgcHJvdmlkZWQg
aW4gdGhlIHBheWxvYWQgb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs
IHN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIHN0eWxlPSdmb250LWZhbWls
eToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz4gwqB0aGUgcm9vdCBvZiB0aGUgdGFyZ2V0IHJl
c291cmNlIGFyZSBKU09OIEFycmF5cywgdGhlIHRhcmdldDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PHNwYW4g
c3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPiDCoHJlc291cmNl
IGlzIHRvIGJlIHJlcGxhY2VkLCBpbiB3aG9sZSwgYnkgdGhlIHByb3ZpZGVkIGRhdGEuPG86cD48
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn
PkltcGxpZXMgKHRhcmdldCArIG1lcmdlID0gcmVzdWx0KTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+IFsxLDJdICsgeyZxdW90
O2EmcXVvdDs6MywgJnF1b3Q7YiZxdW90OzpudWxsfSA9IHsmcXVvdDthJnF1b3Q7OjMsICZxdW90
O2ImcXVvdDs6bnVsbH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7Y29sb3I6IzFGNDk3RCc+QnV0IHRoZSByZXN1bHQgc2hvdWxkIGluc3RlYWQgYmUgeyZx
dW90O2EmcXVvdDs6M30uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz
cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgc2FtZSBtaXN0YWtlIGlzIG1h
ZGUgaW4gc3RlcCAyLCA0PHN1cD50aDwvc3VwPiBkb3QgcG9pbnQuPG86cD48L286cD48L3NwYW4+
PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE
Jz5TdGVwIDEgY291bGQgYmUgcmV3cml0dGVuIGFzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoCDigJxJZiB0aGUgcm9vdCBv
ZiB0aGUgcGF0Y2ggaXMgYSBzdHJpbmcsIG51bWJlciwgYm9vbGVhbiwgb3IgYXJyYXksIHRoZSB0
YXJnZXQgaXMgcmVwbGFjZWQgd2l0aCB0aGUgcGF0Y2ggdmFsdWUu4oCdPG86cD48L286cD48L3Nw
YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0
OTdEJz5UaGlzIHJ1bGUgaXMgbm90IGFjdHVhbGx5IHNwZWNpZmljIHRvIHRoZSByb290IHNvIGl0
IHByb2JhYmx5IGRvZXNu4oCZdCBuZWVkIHRvIGJlIGEgc3BlY2lhbCBjYXNlLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6
IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk15IHN0YWIgYXQgdGhlIHByb2Nlc3NpbmcgcnVsZXM6PG86
cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5
N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm
Ijtjb2xvcjojMUY0OTdEJz7igJxUaGUgcHJvY2Vzc2luZyBzdGVwcyB3YWxrIHRocm91Z2ggdGhl
IG9iamVjdCBlbGVtZW50cyBpbiB0aGUgbWVyZ2UtcGF0Y2ggZG9jdW1lbnQgYW5kIHRoZSBjb3Jy
ZXNwb25kaW5nIGVsZW1lbnRzIGluIHRoZSBkb2N1bWVudCBiZWluZyBtb2RpZmllZC4gTGV0IOKA
mHBhdGNo4oCZIGFuZCDigJh0YXJnZXTigJkgcmVwcmVzZW50IHRoZSBjdXJyZW50IHBvc2l0aW9u
IGluIHRoZXNlIGRvY3VtZW50cyByZXNwZWN0aXZlbHkuIEluaXRpYWxseSDigJhwYXRjaOKAmSBp
cyB0aGUgcm9vdCBvZiB0aGUgbWVyZ2UtcGF0Y2ggZG9jdW1lbnQsIGFuZCDigJh0YXJnZXTigJkg
aXMgdGhlIHJvb3Qgb2YgdGhlIGRvY3VtZW50IGJlaW5nIG1vZGlmaWVkLiBBdCBhbnkgcG9pbnQg
4oCYdGFyZ2V04oCZIG1heSBub3QgZXhpc3QuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz
PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs
aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotMTguMHB0
O21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv
bG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjEuPHNwYW4gc3R5bGU9
J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj
MUY0OTdEJz5JZiB0aGUgcGF0Y2ggdmFsdWUgaXMgbnVsbDogcmVtb3ZlIHRhcmdldC48YnI+SXQg
aXMgbm90IGFuIGVycm9yIGlmIHRhcmdldCBkb2VzIG5vdCBleGlzdCwgdGhlcmUgaXMgc2ltcGx5
IG5vIG1vZGlmaWNhdGlvbiB0byBtYWtlLjxicj5SZW1vdmluZyB0aGUgcm9vdCBsZWF2ZXMgYW4g
ZW1wdHkgZG9jdW1lbnQgKGllIGEgcmVzb3VyY2Ugd2l0aCBhIGNvbnRlbnQtbGVuZ3RoIG9mIDAp
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0
ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9y
dExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25v
cmUnPjIuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp
Zl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5PdGhlcndpc2UsIGlmIHRoZSBwYXRjaCB2YWx1ZSBp
cyBhIHN0cmluZywgbnVtYmVyLCBib29sZWFuLCBvciBhcnJheTogc2V0IHRhcmdldCB0byBwYXRj
aC4gVGhpcyBjcmVhdGVzIGEgbmV3IG9iamVjdCBlbGVtZW50IGlmIHRhcmdldCBkaWRu4oCZdCBl
eGlzdCwgb3IgcmVwbGFjZXMgdGFyZ2V04oCZcyB2YWx1ZSBpZiBpdCBkaWQgZXhpc3QuPG86cD48
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5k
ZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNd
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+My48
c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiO2NvbG9yOiMxRjQ5N0QnPk90aGVyd2lzZSwgdGhlIHBhdGNoIHZhbHVlIGlzIGFuIG9iamVj
dC4gUGVyZm9ybSB0aGUgbmV4dCB0d28gc3ViLXN0ZXBzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1p
bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0
c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz5h
LjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7Y29sb3I6IzFGNDk3RCc+SWYgdGFyZ2V0IGRvZXMgbm90IGV4aXN0IG9yIGlmIGl0cyB2
YWx1ZSBpcyBub3QgYW4gb2JqZWN0OiBzZXQgdGFyZ2V0IHRvIGFuIGVsZW1lbnQgd2l0aCB0aGUg
cGF0Y2ggbmFtZSwgYW5kIGFuIGVtcHR5IG9iamVjdCBhcyBpdHMgdmFsdWUgKGllIHt9KS48YnI+
Rm9yIHRoZSByb290IHRoZXJlIGlzbuKAmXQgcmVhbGx5IGFuIGVsZW1lbnQgbmFtZSwganVzdCBh
IHZhbHVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0
eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs
ZXZlbDIgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48
c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz5iLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJU
aW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwv
c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Rm9yIGVhY2ggZWxl
bWVudCBvZiB0aGUgcGF0Y2ggdmFsdWUgb2JqZWN0OiByZXBlYXQgdGhlIHByb2Nlc3Npbmcgc3Rl
cHMgd2l0aCBwYXRjaCBiZWluZyB0aGF0IGVsZW1lbnQsIGFuZCB0YXJnZXQgYmVpbmcgdGhlIGVs
ZW1lbnQgb2YgdGhlIHByZXZpb3VzIHRhcmdldCB3aXRoIHRoZSBzYW1lIG5hbWUgKGlmIHN1Y2gg
YW4gZWxlbWVudCBleGlzdHMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt
YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh
c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoaXMgaXMg
aGFyZGVyIHRvIHdyaXRlIGluIEVuZ2xpc2ggdGhhbiBjb2RlITxvOnA+PC9vOnA+PC9zcGFuPjwv
cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv
bG9yOiMxRjQ5N0QnPkl0IHdvdWxkIGJlIHdvcnRoIGluY2x1ZGluZyBleGFtcGxlcyBvZiB0aGUg
bGVzcyBvYnZpb3VzIGNhc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt
YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg
Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGFyZ2V0wqDCoCArIG1lcmdl
ID0gcmVzdWx0PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O
b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz57JnF1b3Q7YSZxdW90OzpbMSx7JnF1b3Q7YmIm
cXVvdDs6MiwgJnF1b3Q7Y2MmcXVvdDs6M31dfSArIHsmcXVvdDthJnF1b3Q7OlsxLHsmcXVvdDti
YiZxdW90Ozo0LCAmcXVvdDtjYyZxdW90OzpudWxsfV19ID0geyZxdW90O2EmcXVvdDs6WzEseyZx
dW90O2JiJnF1b3Q7OjQsICZxdW90O2NjJnF1b3Q7Om51bGx9XX08bzpwPjwvbzpwPjwvc3Bhbj48
L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+wqAgKHNob3dpbmcg
dGhhdCB5b3UgZG9u4oCZdCBtZXJnZSBvYmplY3RzIHdpdGhpbiBhbiBhcnJheSk8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y
OiMxRjQ5N0QnPnsmcXVvdDthJnF1b3Q7OjF9ICsgeyZxdW90O2ImcXVvdDs6eyZxdW90O2NjJnF1
b3Q7OnsmcXVvdDtkZGQmcXVvdDs6bnVsbH19fSA9IHsmcXVvdDthJnF1b3Q7OjEsICZxdW90O2Im
cXVvdDs6eyZxdW90O2NjJnF1b3Q7OnsgfX19PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz
PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs
aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgIChzaG93aW5nIHRoYXQgb2JqZWN0
cyBvbiBhIHBhdGggZ2V0IGNyZWF0ZWQgKHN0ZXAgM2EpLCBldmVuIGlmIHRoZSBvbmx5IHRhc2tz
IGF0IHRoZSBlbmQgb2YgdGhlIHBhdGggdHVybnMgb3V0IHRvIGJlIHJlbW92aW5nIGVsZW1lbnRz
KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj
MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7Y29sb3I6IzFGNDk3RCc+IFsxLDJdICsgeyZxdW90O2EmcXVvdDs6MywgJnF1b3Q7YiZx
dW90OzpudWxsfSA9IHsmcXVvdDthJnF1b3Q7OjN9PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs
YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgIChzaG93aW5nIHlvdSBzdGls
bCBoYXZlIHRvIHdhbGsgdGhyb3VnaCB0aGUgcGF0Y2gsIGV2ZW4gd2hlbiB0aGUgY29ycmVzcG9u
ZGluZyBwYXJ0IG9mIHRoZSB0YXJnZXQgd2FzbuKAmXQgYWxzbyBhbiBvYmplY3QpPG86cD48L286
cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv
cjojMUY0OTdEJz57JnF1b3Q7YSZxdW90OzoxfSArIG51bGwgPSAmbHQ7ZW1wdHkmZ3Q7PG86cD48
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj
b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y
bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi
c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+U3BsaXR0aW5nIHRoZSBwcm9jZXNzaW5nIHN0ZXBz
IGFuZCB0aGUgd29ya2VkIGV4YW1wbGUgKHNlY3Rpb24gMikgaW50byBzZXBhcmF0ZSBzZWN0aW9u
cyB3b3VsZCBiZSBhbiBpbXByb3ZlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9
TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZW4gY2FuIHdl
IGhhdmUgdGhpcyBvcGVyYXRpb24gaW4ganNvbi1wYXRjaDogeyZxdW90O29wJnF1b3Q7OiZxdW90
O21lcmdlJnF1b3Q7LCAmcXVvdDtwYXRoJnF1b3Q7OiZsdDtwb2ludGVyJmd0OywgJnF1b3Q7dmFs
dWUmcXVvdDs6Jmx0O21lcmdlLXBhdGNoJmd0O30/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs
YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLTxvOnA+
PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE
Jz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5
bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20g
MGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv
bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNv
Tm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1F
Ti1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z
ZXJpZiInPiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vz
cy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkphbWVzIE0gU25lbGw8YnI+
PGI+U2VudDo8L2I+IEZyaWRheSwgMTkgT2N0b2JlciAyMDEyIDQ6MjIgQU08YnI+PGI+VG86PC9i
PiBJRVRGIEFwcHMgRGlzY3Vzczxicj48Yj5TdWJqZWN0OjwvYj4gW2FwcHMtZGlzY3Vzc10gVXBk
YXRlZCBNZXJnZSBQYXRjaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFz
cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz5CYXNlZCBvbiByZWNlaXZlZCBmZWVk
YmFjaywgbW9zdGx5IGVkaXRvcmlhbCBtb2RpZmljYXRpb25zIGFuZCBhIGZldyB1cGRhdGVzIHRv
IHRoZSBydWxlcyB0byBjb3ZlciBhIGNvdXBsZSBhZGRpdGlvbmFsIGNhc2VzICh0aGFua3MgdG8g
SmFtZXMgTWFuZ2VyIGZvciBwb2ludGluZyBvdXQgdGhlIGdhcHMgYW5kIHByb3ZpZGluZyBuZXcg
bGFuZ3VhZ2UgZm9yIHRoZSBpbnRybykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xh
c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv
Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgPGEg
aHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1zbmVsbC1tZXJnZS1wYXRjaC0wNS50
eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtc25lbGwtbWVyZ2UtcGF0Y2gtMDUudHh0
PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48
bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz
dHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+LSBKYW1lczwvc3Bhbj48bzpwPjwvbzpw
PjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg==

--_000_255B9BB34FB7D647A506DC292726F6E114FDE43DC2WSMSG3153Vsrv_--

From internet-drafts@ietf.org  Thu Oct 18 20:20:57 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD59011E8099; Thu, 18 Oct 2012 20:20:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.518
X-Spam-Level: 
X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 MCL2GhtXdKc9; Thu, 18 Oct 2012 20:20:57 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D924911E8097; Thu, 18 Oct 2012 20:20:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121019032056.23291.40130.idtracker@ietfa.amsl.com>
Date: Thu, 18 Oct 2012 20:20:56 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-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: Fri, 19 Oct 2012 03:20:58 -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           : The 'acct' URI Scheme
	Author(s)       : Peter Saint-Andre
	Filename        : draft-ietf-appsawg-acct-uri-01.txt
	Pages           : 7
	Date            : 2012-10-18

Abstract:
   This document defines the 'acct' URI scheme as a way to identify a
   user's account at a service provider, irrespective of the particular
   protocols that can be used to interact with the account.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-acct-uri-01


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


From stpeter@stpeter.im  Thu Oct 18 20:30:46 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0DC11E80AD for ; Thu, 18 Oct 2012 20:30:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.987
X-Spam-Level: 
X-Spam-Status: No, score=-101.987 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 m+SjCy7DrX6T for ; Thu, 18 Oct 2012 20:30:46 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6152711E8099 for ; Thu, 18 Oct 2012 20:30:46 -0700 (PDT)
Received: from [192.168.1.5] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B6EEF40062 for ; Thu, 18 Oct 2012 21:33:28 -0600 (MDT)
Message-ID: <5080C96A.5070208@stpeter.im>
Date: Thu, 18 Oct 2012 21:30:50 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
CC: apps-discuss@ietf.org
References: <20121019032056.23291.40130.idtracker@ietfa.amsl.com>
In-Reply-To: <20121019032056.23291.40130.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-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: Fri, 19 Oct 2012 03:30:46 -0000

Some relatively small tweaks to address feedback received. (However, I
realize just now that the ABNF simplification might not be what we want...)

Peter

On 10/18/12 9:20 PM, internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Applications Area Working Group Working Group of the IETF.
> 
> 	Title           : The 'acct' URI Scheme
> 	Author(s)       : Peter Saint-Andre
> 	Filename        : draft-ietf-appsawg-acct-uri-01.txt
> 	Pages           : 7
> 	Date            : 2012-10-18
> 
> Abstract:
>    This document defines the 'acct' URI scheme as a way to identify a
>    user's account at a service provider, irrespective of the particular
>    protocols that can be used to interact with the account.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-01
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-acct-uri-01
> 
> 
> 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 James.H.Manger@team.telstra.com  Fri Oct 19 00:10:59 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8367121F85C6 for ; Fri, 19 Oct 2012 00:10:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.873
X-Spam-Level: 
X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=0.027,  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 YjR4hzC+mS3J for ; Fri, 19 Oct 2012 00:10:58 -0700 (PDT)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id B999F21F858C for ; Fri, 19 Oct 2012 00:10:53 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,612,1344175200"; d="scan'208,217";a="98929039"
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 19 Oct 2012 18:10:51 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6869"; a="93406662"
Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcbvi.tcif.telstra.com.au with ESMTP; 19 Oct 2012 18:10:51 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Fri, 19 Oct 2012 18:10:50 +1100
From: "Manger, James H" 
To: James M Snell 
Date: Fri, 19 Oct 2012 18:10:50 +1100
Thread-Topic: [apps-discuss] Update to JSON Predicates
Thread-Index: Ac2te4UkEcoYecRVRcyJy660YPQqBAAFzL2g
Message-ID: <255B9BB34FB7D647A506DC292726F6E114FDEC39B3@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_255B9BB34FB7D647A506DC292726F6E114FDEC39B3WSMSG3153Vsrv_"
MIME-Version: 1.0
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] Update to 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: Fri, 19 Oct 2012 07:10:59 -0000

--_000_255B9BB34FB7D647A506DC292726F6E114FDEC39B3WSMSG3153Vsrv_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SmFtZXMsDQoNClRoaXMgcHJlZGljYXRlIHN5bnRheCBoYXMgc2lnbmlmaWNhbnQgcHJvYmxlbXMg
W2RyYWZ0LXNuZWxsLWpzb24tdGVzdC0wMV0uDQoNCg0KMS4gICAgICAgSXQgZG9lc27igJl0IHBs
YXkgbmljZWx5IHdpdGgganNvbi1wYXRjaC4gSXQgc3RvbXBzIGFsbCBvdmVyIGpzb24tcGF0Y2ji
gJlzIG5hbWVzcGFjZSBmb3Ig4oCcb3DigJ0gbmFtZXMsIGRlZmluaW5nIGFub3RoZXIgMTQgdmFs
dWVzLiBJdCB3b3VsZCBiZSBiZXR0ZXIgdG8gdXNlIG9uZSBuYW1lLCBzYXksIOKAnHRlc3Qy4oCd
Lg0KDQoyLiAgICAgICBUaGUgc2VwYXJhdGUgcGF0Y2ggb3AgZm9yIGVhY2ggcHJlZGljYXRlIGlz
IG5vdCB0aGUgcmlnaHQgbW9kZWwuIFRoZSBzeW50YXggZm9yIHRoZSBwcmVkaWNhdGVzIHNob3Vs
ZCBiZSBlbWJlZGRlZCBpbiBhIHdyYXBwZXIgdGhhdCBwcm92aWRlczogdGhlIHZhbHVlIHRvIHRl
c3Q7IGFuZCBhbnkgYWN0aW9ucyB0byBkbyBpZiB0aGUgdGVzdCBwYXNzZXMuIFRoZSB3cmFwcGVy
IGNhbiBiZSBhIGpzb24tcGF0Y2ggb3BlcmF0aW9uLg0KDQozLiAgICAgICDigJxhbmTigJ0v4oCd
b3LigJ0v4oCdbm904oCdIGhhdmUgYW4g4oCcYXBwbHnigJ0gYXJyYXkgb2Ygb3BzLiBDYW4gdGhl
c2Ugb3BzIG9ubHkgYmUgb3RoZXIgdGVzdHMsIG9yIGNhbiB0aGV5IG1vZGlmeSB0aGUgdGFyZ2V0
Pw0KDQo0LiAgICAgICBBIGpzb24tcGF0Y2ggc2F5cyBvcHMgTVVTVCBoYXZlIGEgcGF0aDsgd2hp
bGUgdGhpcyBkb2Mgc2F5cyDigJxhbmTigJ0v4oCdb3LigJ0v4oCdbm904oCdIE1BWSBoYXZlIGEg
cGF0aC4NCg0KNS4gICAgICAgVGhlIGV4YW1wbGUgaW4gdGhlIGludHJvZHVjdGlvbiBpcyB3cm9u
Zy4gVGhlIHBhdGhzIGZvciB0aGUg4oCcdHlwZeKAnSAmIOKAnGNvbnRhaW5z4oCdIG9wcyBzaG91
bGQgYmUg4oCcL2PigJ0gKG5vdCDigJwvYS9iL2PigJ0pLg0KDQo2LiAgICAgICBXYXkgdG9vIHZl
cmJvc2UuDQoNCjcuICAgICAgIExlc3MgYW5kIG1vcmUgYXJlIG5vdCBzdWZmaWNpZW50LCB5b3Ug
YWxzbyBuZWVkIDw9IGFuZCA+PS4NCg0KOC4gICAgICAg4oCcY29udGFpbnPigJ0sIOKAnGVuZHPi
gJ0sIOKAnHN0YXJ0c+KAnSBhcmUgc3Vic2V0cyBvZiDigJxtYXRjaGVz4oCdLiBNaWdodCBiZSBj
bGVhbmVyIHRvIG9ubHkgaGF2ZSB0aGUgbGF0dGVyLg0KDQo5LiAgICAgICDigJxpbuKAnSBjYW4g
YmUgd3JpdHRlbiB1c2luZyDigJxvcuKAnS4gUGVyaGFwcyDigJxpbuKAnSBpcyBjb21tb24gZW5v
dWdoIHRvIGhhdmUgYSBkZWRpY2F0ZWQsIGxlc3MgdmVyYm9zZSBzeW50YXguDQoNCjEwLiAgIOKA
nG5vdOKAnSBzaG91bGQgYXBwbHkgdG8gMSBwcmVkaWNhdGUsIG5vdCBhbiBhcnJheSBvZiB0aGVt
Lg0KDQoxMS4gICDigJxvcuKAnSBpcyBpbXBsaWVkIGZvciDigJxub3TigJ3igJlzIGFycmF5IG9m
IG9wczsgd2hpbGUgIOKAnGFuZOKAnSBpcyBpbXBsaWVkIGZvciB0aGUgdG9wLWxldmVsIGFycmF5
IG9mIG9wcy4gSW5jb25zaXN0ZW50Lg0KDQoxMi4gICBUaGVyZSBhcmUgbXVsdGlwbGUgd2F5cyB0
byBkbyDigJxhbmTigJ06IGV4cGxpY2l0bHkgd2l0aCDigJxhbmTigJ07IGp1c3QgY29uY2F0ZW5h
dGluZyBhbGwgdGhlIG9wcw0KDQpIb3cgYWJvdXQ6DQoNCkEgPHByZWRpY2F0ZT4gZXZhbHVhdGVz
IHRvIHRydWUgb3IgZmFsc2Ugd2hlbiBhcHBsaWVkIHRvIGEgdGFyZ2V0IEpTT04gdmFsdWUgKHdo
aWNoIG1heSBub3QgZXhpc3QpLg0KQSA8cHJlZGljYXRlPiBpcyBhbiBvYmplY3Qgd2l0aCBhbnkg
bnVtYmVyIG9mIDxwcmVkaWNhdGUtb3A+IGVsZW1lbnRzLiBUaGUgPHByZWRpY2F0ZT4gaXMgdHJ1
ZSBpZiwgYW5kIG9ubHkgaWYsIGVhY2ggPHByZWRpY2F0ZS1vcD4gaXMgdHJ1ZSAoe30gaXMgdHJ1
ZSkuDQpUaGUgPHByZWRpY2F0ZS1vcD5zIGFyZToNCiogImFuZCI6WzxwcmVkaWNhdGUtb3A+4oCm
XSDigJQgdHJ1ZSBpZiBub25lIG9mIHRoZSA8cHJlZGljYXRlLW9wPnMgaW4gdGhlIGFycmF5IGFy
ZSBmYWxzZTsgZmFsc2Ugb3RoZXJ3aXNlLiAiYW5kIjpbXSBpcyB0cnVlLg0KKiAib3IiOls8cHJl
ZGljYXRlLW9wPuKApl0g4oCUIHRydWUgaWYgYW55IG9mIHRoZSA8cHJlZGljYXRlLW9wPnMgaW4g
aXRzIHZhbHVlIGFyZSB0cnVlOyBmYWxzZSBvdGhlcndpc2UuICJvciI6W10gaXMgZmFsc2UuDQoq
ICJub3QiOjxwcmVkaWNhdGU+IOKAlCB0cnVlIGlmIDxwcmVkaWNhdGU+IGV2YWx1YXRlcyB0byBm
YWxzZTsgZmFsc2Ugb3RoZXJ3aXNlDQoqICJwcmVzZW50Ijo8Ym9vbGVhbj4g4oCUIHRydWUgaWYg
dGhlIHZhbHVlIGlzIHRydWUgYW5kIHRoZSB0YXJnZXQgaXMgcHJlc2VudCwgb3IgdGhlIHZhbHVl
IGlzIGZhbHNlIGFuZCB0aGUgdGFyZ2V0IGlzIGFic2VudDsgZmFsc2Ugb3RoZXJ3aXNlDQoqICI9
Ijo8YW55PiDigJQgdHJ1ZSBpZiB0aGUgdmFsdWUgYW5kIHRhcmdldCBhcmUgZXF1YWwNCiogInR5
cGUiOjxhbnk+IOKAlCB0cnVlIGlmIHRoZSB2YWx1ZSBhbmQgdGFyZ2V0IGhhdmUgdGhlIHNhbWUg
dHlwZTsgZmFsc2Ugb3RoZXJ3aXNlLiBTdWdnZXN0ZWQgdmFsdWVzIHRvIHVzZSBmb3IgdGhlIDYg
SlNPTiB0eXBlcyBhcmUgbnVsbCwgdHJ1ZSwgMCwgIiIsIFtdLCBhbmQge30gZm9yIG51bGwsIGJv
b2xlYW4sIG51bWJlciwgc3RyaW5nLCBhcnJheSwgYW5kIG9iamVjdCByZXNwZWN0aXZlbHkuDQoq
ICJtYXRjaCI6PHJlZ2V4PiDigJQgdHJ1ZSBpZiB0aGUgdGFyZ2V0IGlzIGEgc3RyaW5nLCBhbmQg
aXQgbWF0Y2hlcyB0aGUgZ2l2ZSByZWd1bGFyIGV4cHJlc3Npb247IGZhbHNlIG90aGVyd2lzZS4g
VGhlIGV4cHJlc3Npb24g4oCcKD9pKeKAnSBjYW4gYmUgaW5jbHVkZWQgaW4gdGhlIHJlZ2V4IGZv
ciBjYXNlLWluc2Vuc2l0aXZlIG1hdGNoaW5nLg0KKiAiPCI6PG51bWJlcj4g4oCUIHRydWUgaWYg
dGhlIHRhcmdldCBpcyBhIG51bWJlciwgYW5kIGlzIGxlc3MgdGhhbiB0aGUgZ2l2ZW4gdmFsdWU7
IGZhbHNlIG90aGVyd2lzZQ0KKiAiPiIsICI8PSIsICI+PSIg4oCUIHNpbWlsYXIgdG8gIjwiDQoq
IDxwb2ludGVyPjo8cHJlZGljYXRlPiDigJQgZXZhbHVhdGUgdGhlIHByZWRpY2F0ZSBhZ2FpbnN0
IHRoZSBwYXJ0IG9mIHRoZSB0YXJnZXQgc2VsZWN0ZWQgYnkgdGhlIHBvaW50ZXIuIEEgPHBvaW50
ZXI+IGNhbiBvbmx5IGJlIHRoZSBlbXB0eSBzdHJpbmcgb3IgYSBzdHJpbmcgc3RhcnRpbmcgd2l0
aCAiLyIsIHdoaWNoIGFsbG93cyBhbGwgcG9zc2libGUgcG9pbnRlcnMgdG8gYmUgZGlzdGluZ3Vp
c2hlZCBmcm9tIG90aGVyIDxwcmVkaWNhdGUtb3A+IG5hbWVzLg0KKiA8dW5yZWNvZ25pemVkPjo8
YW55PiDigJQgYW55IHVucmVjb2duaXplZCBlbGVtZW50IGluIGEgPHByZWRpY2F0ZT4gaXMgdHJl
YXRlZCBhcyB0aG91Z2ggaXQgZXZhbHVhdGVzIHRvIGZhbHNlDQoNCiJ0ZXN0MiIgaXMgYSBuZXcg
b3BlcmF0aW9uIGRlZmluZWQgZm9yIGpzb24tcGF0Y2guIEl0IE1VU1QgaGF2ZSBhICI/IiBtZW1i
ZXIgd2hvc2UgdmFsdWUgaXMgYSA8cHJlZGljYXRlPiB0aGF0IGV2YWx1YXRlcyB0aGUgdGFyZ2V0
IHNlbGVjdGVkIGJ5IHRoZSAicGF0aCIgbWVtYmVyLiBJdCBNQVkgaGF2ZSBhICJvcHMiIG1lbWJl
ciB3aG9zZSB2YWx1ZSBpcyBhbiBhcnJheSBvZiBvcGVyYXRpb25zLiBUaG9zZSBvcGVyYXRpb25z
IGFyZSBhcHBsaWVkIG9ubHkgaWYgdGhlIHByZWRpY2F0ZSBldmFsdWF0ZXMgdG8gdHJ1ZS4gSXQg
aXMgYW4gZXJyb3IgaWYgdGhlIHByZWRpY2F0ZSBldmFsdWF0ZXMgdG8gZmFsc2UgYW5kICJvcHMi
IGlzIG5vdCBwcmVzZW50LCBpZSBwcm9jZXNzaW5nIHRoZSBwYXRjaCBmYWlscy4gTm90aGluZyBo
YXBwZW5zIGluIHRoZSBvdGhlciB0d28gY2FzZXMgKHByZWRpY2F0ZSBpcyBmYWxzZSBhbmQgb3Bz
IHByZXNlbnQ7IHByZWRpY2F0ZSB0cnVlIGFuZCBvcHMgYWJzZW50KS4NCg0KDQpUaGUgZXhhbXBs
ZXMgZnJvbSBkcmFmdC1zbmVsbC1qc29uLXRlc3QtMDEgcmUtd3JpdHRlbiBpbiB0aGlzIHN5bnRh
eC4NCg0KwqcxLiBJbnRyb2R1Y3Rpb24gW21hdGNoIGltcGxlbWVudHMg4oCcY29udGFpbnPigJ0s
IGFuZCBpbXBsaWVzIOKAnHR5cGXigJ0gc2luY2UgaXQgb25seSB3b3JrcyBhZ2FpbnN0IHN0cmlu
Z3NdDQoNCiAgW3sib3AiOiJ0ZXN0MiIsICJwYXRoIjoiL2EvYi9jIiwgIj8iOnsibWF0Y2giOiIu
KkFCQy4qIn0gfSwNCiAgIHsib3AiOiJyZXBsYWNlIiwgInBhdGgiOiIvYS9iL2MiLCAidmFsdWUi
OjEyM31dDQoNCsKnMi4yLjEuIGNvbnRhaW5zDQoNCiAgW3sib3AiOiJ0ZXN0MiIsICJwYXRoIjoi
L2EvYiIsICI/Ijp7Im1hdGNoIjoiLiogaXMgYSAuKiJ9IH1dDQoNCiAgW3sib3AiOiJ0ZXN0MiIs
ICJwYXRoIjoiL2EvYiIsICI/Ijp7Im1hdGNoIjoiKD9pKS4qIElzIEEgLioifSB9XQ0KDQrCpzIu
Mi4yIGRlZmluZWQNCg0KICBbeyJvcCI6InRlc3QyIiwgInBhdGgiOiIvYS9iIiwgIj8iOnsicHJl
c2VudCI6dHJ1ZX0gfV0NCg0KICBbeyJvcCI6InRlc3QyIiwgInBhdGgiOiIvYS9jIiwgIj8iOnsi
cHJlc2VudCI6dHJ1ZX0gfV0NCg0KwqcyLjIuMy4gZW5kcw0KDQogIFt7Im9wIjoidGVzdDIiLCAi
cGF0aCI6Ii9hL2IiLCAiPyI6eyJtYXRjaCI6Ii4qIHRlc3QifSB9XQ0KDQogIFt7Im9wIjoidGVz
dDIiLCAicGF0aCI6Ii9hL2IiLCAiPyI6eyJtYXRjaCI6Iig/aSkuKiBURVNUIn0gfV0NCg0Kwqcy
LjIuNC4gaW4NCg0KICBbeyJvcCI6InRlc3QyIiwgInBhdGgiOiIvYS9iIiwgIj8iOg0KICAgICB7
Im9yIjpbeyI9IjoxfSwgeyI9IjoiZm9vIn0sIHsiPSI6MTB9LCB7Ij0iOnsieiI6InkifX1dfSB9
XQ0KDQrCpzIuMi41LiBsZXNzDQoNCiAgW3sib3AiOiJ0ZXN0MiIsICJwYXRoIjoiL2EvYiIsICI/
Ijp7IjwiOjE1fSB9XQ0KDQrCpzIuMi42LiBtYXRjaGVzIFthbiBleGFtcGxlIHdoZXJlIGNhc2Ug
c2Vuc2l0aXZpdHkgbWF0dGVycyB3b3VsZCBiZSBiZXR0ZXJdDQoNCiAgW3sib3AiOiJ0ZXN0MiIs
ICJwYXRoIjoiL2EvYiIsICI/Ijp7Im1hdGNoIjoiW1xcd1xcc10qIn0gfV0NCg0KICBbeyJvcCI6
InRlc3QyIiwgInBhdGgiOiIvYS9iIiwgIj8iOnsibWF0Y2giOiIoP2kpW1xcd1xcc10qIn0gfV0N
Cg0KwqcyLjIuNy4gbW9yZQ0KDQogIFt7Im9wIjoidGVzdDIiLCAicGF0aCI6Ii9hL2IiLCAiPyI6
eyI+Ijo1fSB9XQ0KDQrCpzIuMi44LiBzdGFydHMNCg0KICBbeyJvcCI6InRlc3QyIiwgInBhdGgi
OiIvYS9iIiwgIj8iOnsibWF0Y2giOiJUaGlzIC4qIn0gfV0NCg0KICBbeyJvcCI6InRlc3QyIiwg
InBhdGgiOiIvYS9iIiwgIj8iOnsibWF0Y2giOiIoP2kpVGhpcyAuKiJ9IH1dDQoNCsKnMi4yLjku
IHRlc3QNCg0KICBbeyJvcCI6InRlc3QyIiwgInBhdGgiOiIvYS9iIiwgIj8iOnsiPSI6InRoaXMg
aXMgYSB0ZXN0In0gfV0NCg0KwqcyLjIuMTAuIHR5cGUgW3VzZSAicHJlc2VudCI6ZmFsc2UgZm9y
ICJ1bmRlZmluZWQiOyAibWF0Y2giOjxyZWdleD4gZm9yIGRhdGUsIGRhdGUtdGltZSwgdGltZSwg
bGFuZywgbGFuZy1yYW5nZSwgaXJpLCBhYnNvbHV0ZS1pcmldDQoNCiAgW3sib3AiOiJ0ZXN0MiIs
ICJwYXRoIjoiL2EvYiIsICI/Ijp7InR5cGUiOiIifSB9XQ0KDQrCpzIuMi4xMSB1bmRlZmluZWQN
Cg0KICBbeyJvcCI6InRlc3QyIiwgInBhdGgiOiIvYS9jIiwgIj8iOnsicHJlc2VudCI6ZmFsc2V9
IH1dDQoNCiAgW3sib3AiOiJ0ZXN0MiIsICJwYXRoIjoiL2EvYiIsICI/Ijp7InByZXNlbnQiOmZh
bHNlfSB9XQ0KDQrCpzIuMy4gU2Vjb25kLU9yZGVyIFByZWRpY2F0ZXMNCg0KICBbeyJvcCI6InRl
c3QyIiwgInBhdGgiOiIvYS9iIiwgIj8iOnsiL2MiOnsicHJlc2VudCI6dHJ1ZX19IH1dDQoNCsKn
Mi4zLjEuIGFuZCAoZG9u4oCZdCBuZWVkIHRvIHVzZSDigJxhbmTigJ0gdW5sZXNzIGFwcGx5aW5n
IHRoZSBzYW1lIDxwcmVkaWNhdGUtb3A+IHRvIHRoZSBzYW1lIHZhbHVlIHR3byBvciBtb3JlIHRp
bWVzLCB3aGljaCBzaG91bGQgYmUgcmFyZSkgW2NoZWNraW5nIHByZXNlbmNlIGlzIHJlZHVuZGFu
dCBpZiBjaGVja2luZyB0eXBlXQ0KDQogIFt7Im9wIjoidGVzdDIiLCAicGF0aCI6IiIsICI/Ijp7
DQogICAgICAiL2EvYiI6eyJwcmVzZW50Ijp0cnVlfSwNCiAgICAgICIvYS9jL2QiOnsiPCI6MTV9
IH0gfV0NCg0KICBbeyJvcCI6InRlc3QyIiwgInBhdGgiOiIiLCAiPyI6ew0KICAgICAgIi9hL2Mi
OnsicHJlc2VudCI6dHJ1ZX0sDQogICAgICAiL2EvYyI6eyJ0eXBlIjoiIn0gfSB9XQ0KDQrCpzIu
My4yLiBub3QNCg0KICBbeyJvcCI6InRlc3QyIiwgInBhdGgiOiIiLCAiPyI6eyJub3QiOnsib3Ii
OlsNCiAgICAgIHsiL2EvYi9lIjp7InByZXNlbnQiOnRydWV9fSwNCiAgICAgIHsiL2EvYy9kIjp7
IjwiOjV9fSB9IH1dDQoNCiAgW3sib3AiOiJ0ZXN0MiIsICJwYXRoIjoiIiwgIj8iOnsibm90Ijp7
Im9yIjpbDQogICAgICB7Ii9hL2MiOnsicHJlc2VudCI6ZmFsc2V9fSwNCiAgICAgIHsiL2EvYiI6
eyJtYXRjaCI6ImYuKiJ9fSBdfX0gfV0NCg0KwqcyLjMuMy4gb3IgW2V4YW1wbGVzIGFyZSB3cm9u
ZyBhcyB0aGV5IHVzZSDigJx0ZXN04oCdIHdpdGhvdXQgYSDigJx2YWx1ZeKAnV0NCg0KICBbeyJv
cCI6InRlc3QyIiwgInBhdGgiOiIiLCAiPyI6eyJvciI6Ww0KICAgICAgeyIvYS9iIjp7InByZXNl
bnQiOnRydWV9fSwNCiAgICAgIHsiL2EvYy9kIjp7IjwiOjV9fSBdfSB9XQ0KDQogIFt7Im9wIjoi
dGVzdDIiLCAicGF0aCI6IiIsICI/Ijp7Im9yIjpbDQogICAgICB7Ii9hL2UiOnsicHJlc2VudCI6
dHJ1ZX19LA0KICAgICAgeyIvYS9mIjp7InByZXNlbnQiOnRydWV9fSBdfSB9XQ0KDQrCpzIuMy40
LiBOZXN0aW5nIFNlY29uZCBPcmRlciBQcmVkaWNhdGVzICBbdHlwZSB0ZXN0IGlzIHJlZHVuZGFu
dCBoZXJlXQ0KDQogIFt7Im9wIjoidGVzdDIiLCAicGF0aCI6Ii9hL2IiLCAiPyI6DQogICAgeyJv
ciI6Ww0KICAgICAgeyIvYyI6eyJub3QiOnsib3IiOlsNCiAgICAgICAgeyJwcmVzZW50IjpmYWxz
ZX0sIHsibWF0Y2giOiJmLioifQ0KICAgICAgXX19fSwNCiAgICAgIHsiL2QiOnsibm90Ijp7Im9y
IjpbDQogICAgICAgIHsicHJlc2VudCI6dHJ1ZX0sIHsidHlwZSI6MH0NCiAgICAgIF19fX0NCiAg
ICBdfQ0KICBdDQoNCg0KLS0NCkphbWVzIE1hbmdlcg0KDQpGcm9tOiBhcHBzLWRpc2N1c3MtYm91
bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYgT2YgSmFtZXMgTSBTbmVsbA0KU2VudDogRnJpZGF5LCAxOSBPY3RvYmVyIDIwMTIgODo1
NyBBTQ0KVG86IElFVEYgQXBwcyBEaXNjdXNzDQpTdWJqZWN0OiBbYXBwcy1kaXNjdXNzXSBVcGRh
dGUgdG8gSlNPTiBQcmVkaWNhdGVzDQoNCkJhc2VkIG9uIHNvbWUgaW5pdGlhbCBkaXJlY3QgZmVl
ZGJhY2sgSSByZWNlaXZlZCBvbiB0aGUgLTAwIGRyYWZ0LCBJIGhhdmUgc3VibWl0dGVkIGFuIHVw
ZGF0ZWQgZHJhZnQuLg0KDQogIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtc25lbGwtanNv
bi10ZXN0LTAxLnR4dA0KDQpTZXZlcmFsIGtleSBtb2RpZmljYXRpb25zIHdlcmUgbWFkZS4uDQoN
CiAxLiBTcGVjaWZpYyBtZW50aW9uIGlzIG1hZGUgcmU6IHRoZSB1c2Ugb2YgdGhlIEpTT04tUGF0
Y2ggInRlc3QiIG9wZXJhdGlvbiBhcyBhIFByZWRpY2F0ZSB3aXRoIHRoZSBhZGRpdGlvbiBvZiBh
biBvcHRpb25hbCAiaWdub3JlX2Nhc2UiIG1lbWJlciBjb25zaXN0ZW50IHdpdGggdGhlIG90aGVy
IHRleHQgY29tcGFyaXNvbiBwcmVkaWNhdGVzLg0KDQogMi4gQWRkaXRpb24gb2YgYW4gImluIiBw
cmVkaWNhdGUgb3BlcmF0aW9uIHRoYXQgdGVzdHMgd2hldGhlciB0aGUgdmFsdWUgaXMgcGFydCBv
ZiBhIGdpdmVuIGxpc3Qgb2YgdmFsdWVzLi4gZm9yIGluc3RhbmNlOg0KDQogICAgeyJvcCI6ICJp
biIsICJwYXRoIjogIi9hL2IvYyIsICJ2YWx1ZSI6IFsxLDIsMyw0LDVdfQ0KDQogICAgUmV0dXJu
cyB0cnVlIGlmIHRoZSB2YWx1ZSBvZiAiL2EvYi9jIiBpcyBpbiB0aGUgYXJyYXkgWzEsMiwzLDQs
NV0NCg0KIDMuIEFkZGl0aW9uYWwgdHlwZXMgZm9yIHRoZSAidHlwZSIgcHJlZGljYXRlIG9wZXJh
dGlvbiBpbmNsdWRpbmc6IGRhdGUsIHRpbWUsIGRhdGUtdGltZSwgbGFuZywgbGFuZy1yYW5nZSwg
aXJpIGFuZCBhYnNvbHV0ZS1pcmkuIFRoZXNlIGFyZSBpbnRlbmRlZCB0byB0ZXN0IGlmIGEgSlNP
TiBzdHJpbmcgY29uZm9ybXMgdG8gYSBzcGVjaWZpYyBzZXQgb2YgY29tbW9uIFJGQyBkZWZpbmVk
IGRhdGEgdHlwZXMuIFRoZSB0eXBlcyBhcmUgZHJhd24gZnJvbSBSRkMncyAzMzM5LCAzOTg3LCA0
NjQ2LCBhbmQgNDY0Ny4gVGhlc2UgdHlwZXMgYXJlIGNvbW1vbiB0byBtYW55IEpTT04gZGF0YSBm
b3JtYXRzLg0KDQogICAgeyJvcCI6ICJ0eXBlIiwgInBhdGgiOiAiL2EvYi9jIiwgInZhbHVlIjog
ImRhdGUtdGltZSJ9DQoNCiAgICBSZXR1cm5zIHRydWUgaWYgdGhlIHZhbHVlIG9mICIvYS9iL2Mi
IGlzIGFuIFJGQzMzMzkgZGF0ZS10aW1lIGxpa2UgIjIwMTItMTItMTJUMTI6MTI6MTJaIg0KDQog
ICAgeyJvcCI6ICJ0eXBlIiwgInBhdGgiOiAiL2EvYi9jIiwgInZhbHVlIjogImFic29sdXRlLWly
aSJ9DQoNCiAgICBSZXR1cm5zIHRydWUgaWYgdGhlIHZhbHVlIG9mICIvYS9iL2MiIGlzIGFuIEFi
c29sdXRlIElSSSByZWZlcmVuY2UgbGlrZSAiaHR0cDovL2V4YW1wbGUub3JnL2ZvbyINCg0KICAg
IHsib3AiOiAidHlwZSIsICJwYXRoIjogIi9hL2IvYyIsICJ2YWx1ZSI6ICJsYW5nIn0NCg0KICAg
IFJldHVybnMgdHJ1ZSBpZiB0aGUgdmFsdWUgb2YgIi9hL2IvYyIgaXMgYSBMYW5ndWFnZSBUYWcg
bGlrZSAiZW4tVVMiDQoNCjQuIFNldmVyYWwgY2xhcmlmaWNhdGlvbnMgYW5kIGVkaXRvcmlhbCBm
aXhlcyB3ZXJlIG1hZGUuDQoNCkFzIGFsd2F5cywgY29tbWVudHMgYXJlIHdlbGNvbWUuIFVubGVz
cyB0aGVyZSBhcmUgc2lnbmlmaWNhbnQgY2hhbmdlcyBtYWRlIHRvIEpTT04gUGF0Y2ggb3Igc2ln
bmlmaWNhbnQgaXNzdWVzIGZvdW5kIHdpdGggdGhpcyBzcGVjaWZpY2F0aW9uLCBJIGRvIG5vdCBh
bnRpY2lwYXRlIG1ha2luZyBhbnkgZnVydGhlciB0ZWNobmljYWwgY2hhbmdlcy4NCg0KLSBKYW1l
cw0K

--_000_255B9BB34FB7D647A506DC292726F6E114FDEC39B3WSMSG3153Vsrv_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv
bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N
c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw
aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJp
Z2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFy
Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp
bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K
CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K
CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K
CXttc28tbGlzdC1pZDo4NDc2MDA4NjY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp
c3QtdGVtcGxhdGUtaWRzOi0xMjczOTkyOTQwIDIwMTkxNjQzMSAyMDE5MTY0NDEgMjAxOTE2NDQz
IDIwMTkxNjQzMSAyMDE5MTY0NDEgMjAxOTE2NDQzIDIwMTkxNjQzMSAyMDE5MTY0NDEgMjAxOTE2
NDQzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpvbA0K
CXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0
eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp
dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5
XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk
aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFk
Pjxib2R5IGxhbmc9RU4tQVUgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRT
ZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5KYW1lcyw8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG
NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiO2NvbG9yOiMxRjQ5N0QnPlRoaXMgcHJlZGljYXRlIHN5bnRheCBoYXMgc2lnbmlmaWNhbnQg
cHJvYmxlbXMgW2RyYWZ0LXNuZWxsLWpzb24tdGVzdC0wMV0uPG86cD48L286cD48L3NwYW4+PC9w
PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVu
dDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjEuPHNw
YW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm
Ijtjb2xvcjojMUY0OTdEJz5JdCBkb2VzbuKAmXQgcGxheSBuaWNlbHkgd2l0aCBqc29uLXBhdGNo
LiBJdCBzdG9tcHMgYWxsIG92ZXIganNvbi1wYXRjaOKAmXMgbmFtZXNwYWNlIGZvciDigJxvcOKA
nSBuYW1lcywgZGVmaW5pbmcgYW5vdGhlciAxNCB2YWx1ZXMuIEl0IHdvdWxkIGJlIGJldHRlciB0
byB1c2Ugb25lIG5hbWUsIHNheSwg4oCcdGVzdDLigJ0uPG86cD48L286cD48L3NwYW4+PC9wPjxw
IGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp
c3Q6bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG
NDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Mi48c3BhbiBzdHlsZT0nZm9udDo3
LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn
PlRoZSBzZXBhcmF0ZSBwYXRjaCBvcCBmb3IgZWFjaCBwcmVkaWNhdGUgaXMgbm90IHRoZSByaWdo
dCBtb2RlbC4gVGhlIHN5bnRheCBmb3IgdGhlIHByZWRpY2F0ZXMgc2hvdWxkIGJlIGVtYmVkZGVk
IGluIGEgd3JhcHBlciB0aGF0IHByb3ZpZGVzOiB0aGUgdmFsdWUgdG8gdGVzdDsgYW5kIGFueSBh
Y3Rpb25zIHRvIGRvIGlmIHRoZSB0ZXN0IHBhc3Nlcy4gVGhlIHdyYXBwZXIgY2FuIGJlIGEganNv
bi1wYXRjaCBvcGVyYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQ
YXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm
bzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5
bGU9J21zby1saXN0Oklnbm9yZSc+My48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3
IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3Nw
YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPuKAnGFuZOKAnS/igJ1v
cuKAnS/igJ1ub3TigJ0gaGF2ZSBhbiDigJxhcHBseeKAnSBhcnJheSBvZiBvcHMuIENhbiB0aGVz
ZSBvcHMgb25seSBiZSBvdGhlciB0ZXN0cywgb3IgY2FuIHRoZXkgbW9kaWZ5IHRoZSB0YXJnZXQ/
PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3Rl
eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0
TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9y
ZSc+NC48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm
XT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh
bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkEganNvbi1wYXRjaCBzYXlzIG9wcyBNVVNUIGhhdmUg
YSBwYXRoOyB3aGlsZSB0aGlzIGRvYyBzYXlzIOKAnGFuZOKAnS/igJ1vcuKAnS/igJ1ub3TigJ0g
TUFZIGhhdmUgYSBwYXRoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFy
YWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8x
Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxl
PSdtc28tbGlzdDpJZ25vcmUnPjUuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBS
b21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFu
Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgZXhhbXBsZSBpbiB0
aGUgaW50cm9kdWN0aW9uIGlzIHdyb25nLiBUaGUgcGF0aHMgZm9yIHRoZSDigJx0eXBl4oCdICZh
bXA7IOKAnGNvbnRhaW5z4oCdIG9wcyBzaG91bGQgYmUg4oCcL2PigJ0gKG5vdCDigJwvYS9iL2Pi
gJ0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxl
PSd0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3Vw
cG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs
aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJ
Z25vcmUnPjYuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl
bmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5XYXkgdG9vIHZlcmJvc2UuPG86cD48L286cD48
L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0x
OC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Ny48c3BhbiBz
dHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv
bG9yOiMxRjQ5N0QnPkxlc3MgYW5kIG1vcmUgYXJlIG5vdCBzdWZmaWNpZW50LCB5b3UgYWxzbyBu
ZWVkICZsdDs9IGFuZCAmZ3Q7PS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlz
dFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEg
bGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBz
dHlsZT0nbXNvLWxpc3Q6SWdub3JlJz44LjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBO
ZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwv
c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+4oCcY29udGFpbnPi
gJ0sIOKAnGVuZHPigJ0sIOKAnHN0YXJ0c+KAnSBhcmUgc3Vic2V0cyBvZiDigJxtYXRjaGVz4oCd
LiBNaWdodCBiZSBjbGVhbmVyIHRvIG9ubHkgaGF2ZSB0aGUgbGF0dGVyLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotMTgu
MHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
O2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjkuPHNwYW4gc3R5
bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv
cjojMUY0OTdEJz7igJxpbuKAnSBjYW4gYmUgd3JpdHRlbiB1c2luZyDigJxvcuKAnS4gUGVyaGFw
cyDigJxpbuKAnSBpcyBjb21tb24gZW5vdWdoIHRvIGhhdmUgYSBkZWRpY2F0ZWQsIGxlc3MgdmVy
Ym9zZSBzeW50YXguPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3Jh
cGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjwh
W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21z
by1saXN0Oklnbm9yZSc+MTAuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21h
biInPiZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj
b2xvcjojMUY0OTdEJz7igJxub3TigJ0gc2hvdWxkIGFwcGx5IHRvIDEgcHJlZGljYXRlLCBub3Qg
YW4gYXJyYXkgb2YgdGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBh
cmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZv
MSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHls
ZT0nbXNvLWxpc3Q6SWdub3JlJz4xMS48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3
IFJvbWFuIic+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiO2NvbG9yOiMxRjQ5N0QnPuKAnG9y4oCdIGlzIGltcGxpZWQgZm9yIOKAnG5vdOKAneKAmXMg
YXJyYXkgb2Ygb3BzOyB3aGlsZSDCoOKAnGFuZOKAnSBpcyBpbXBsaWVkIGZvciB0aGUgdG9wLWxl
dmVsIGFycmF5IG9mIG9wcy4gSW5jb25zaXN0ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj
bGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0
OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5
N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjEyLjxzcGFuIHN0eWxlPSdmb250Ojcu
MHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+
PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlcmUgYXJlIG11bHRpcGxlIHdheXMg
dG8gZG8g4oCcYW5k4oCdOiBleHBsaWNpdGx5IHdpdGgg4oCcYW5k4oCdOyBqdXN0IGNvbmNhdGVu
YXRpbmcgYWxsIHRoZSBvcHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs
YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhvdyBhYm91dDo8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y
OiMxRjQ5N0QnPkEgJmx0O3ByZWRpY2F0ZSZndDsgZXZhbHVhdGVzIHRvIHRydWUgb3IgZmFsc2Ug
d2hlbiBhcHBsaWVkIHRvIGEgdGFyZ2V0IEpTT04gdmFsdWUgKHdoaWNoIG1heSBub3QgZXhpc3Qp
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj
MUY0OTdEJz5BICZsdDtwcmVkaWNhdGUmZ3Q7IGlzIGFuIG9iamVjdCB3aXRoIGFueSBudW1iZXIg
b2YgJmx0O3ByZWRpY2F0ZS1vcCZndDsgZWxlbWVudHMuIFRoZSAmbHQ7cHJlZGljYXRlJmd0OyBp
cyB0cnVlIGlmLCBhbmQgb25seSBpZiwgZWFjaCAmbHQ7cHJlZGljYXRlLW9wJmd0OyBpcyB0cnVl
ICh7fSBpcyB0cnVlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlICZsdDtwcmVkaWNhdGUtb3AmZ3Q7cyBhcmU6PG86cD48
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn
PiogJnF1b3Q7YW5kJnF1b3Q7OlsmbHQ7cHJlZGljYXRlLW9wJmd0O+KApl0g4oCUIHRydWUgaWYg
bm9uZSBvZiB0aGUgJmx0O3ByZWRpY2F0ZS1vcCZndDtzIGluIHRoZSBhcnJheSBhcmUgZmFsc2U7
IGZhbHNlIG90aGVyd2lzZS4gJnF1b3Q7YW5kJnF1b3Q7OltdIGlzIHRydWUuPG86cD48L286cD48
L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiogJnF1
b3Q7b3ImcXVvdDs6WyZsdDtwcmVkaWNhdGUtb3AmZ3Q74oCmXSDigJQgdHJ1ZSBpZiBhbnkgb2Yg
dGhlICZsdDtwcmVkaWNhdGUtb3AmZ3Q7cyBpbiBpdHMgdmFsdWUgYXJlIHRydWU7IGZhbHNlIG90
aGVyd2lzZS4gJnF1b3Q7b3ImcXVvdDs6W10gaXMgZmFsc2UuPG86cD48L286cD48L3NwYW4+PC9w
PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiogJnF1b3Q7bm90JnF1
b3Q7OiZsdDtwcmVkaWNhdGUmZ3Q7IOKAlCB0cnVlIGlmICZsdDtwcmVkaWNhdGUmZ3Q7IGV2YWx1
YXRlcyB0byBmYWxzZTsgZmFsc2Ugb3RoZXJ3aXNlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs
YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiogJnF1b3Q7cHJlc2VudCZxdW90
OzombHQ7Ym9vbGVhbiZndDsg4oCUIHRydWUgaWYgdGhlIHZhbHVlIGlzIHRydWUgYW5kIHRoZSB0
YXJnZXQgaXMgcHJlc2VudCwgb3IgdGhlIHZhbHVlIGlzIGZhbHNlIGFuZCB0aGUgdGFyZ2V0IGlz
IGFic2VudDsgZmFsc2Ugb3RoZXJ3aXNlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z
b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiogJnF1b3Q7PSZxdW90OzombHQ7YW55Jmd0
OyDigJQgdHJ1ZSBpZiB0aGUgdmFsdWUgYW5kIHRhcmdldCBhcmUgZXF1YWw8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+KiAmcXVv
dDt0eXBlJnF1b3Q7OiZsdDthbnkmZ3Q7IOKAlCB0cnVlIGlmIHRoZSB2YWx1ZSBhbmQgdGFyZ2V0
IGhhdmUgdGhlIHNhbWUgdHlwZTsgZmFsc2Ugb3RoZXJ3aXNlLiBTdWdnZXN0ZWQgdmFsdWVzIHRv
IHVzZSBmb3IgdGhlIDYgSlNPTiB0eXBlcyBhcmUgbnVsbCwgdHJ1ZSwgMCwgJnF1b3Q7JnF1b3Q7
LCBbXSwgYW5kIHt9IGZvciBudWxsLCBib29sZWFuLCBudW1iZXIsIHN0cmluZywgYXJyYXksIGFu
ZCBvYmplY3QgcmVzcGVjdGl2ZWx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O
b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4qICZxdW90O21hdGNoJnF1b3Q7OiZsdDtyZWdl
eCZndDsg4oCUIHRydWUgaWYgdGhlIHRhcmdldCBpcyBhIHN0cmluZywgYW5kIGl0IG1hdGNoZXMg
dGhlIGdpdmUgcmVndWxhciBleHByZXNzaW9uOyBmYWxzZSBvdGhlcndpc2UuIFRoZSBleHByZXNz
aW9uIOKAnCg/aSnigJ0gY2FuIGJlIGluY2x1ZGVkIGluIHRoZSByZWdleCBmb3IgY2FzZS1pbnNl
bnNpdGl2ZSBtYXRjaGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+KiAmcXVvdDsmbHQ7JnF1b3Q7OiZsdDtudW1iZXImZ3Q7
IOKAlCB0cnVlIGlmIHRoZSB0YXJnZXQgaXMgYSBudW1iZXIsIGFuZCBpcyBsZXNzIHRoYW4gdGhl
IGdpdmVuIHZhbHVlOyBmYWxzZSBvdGhlcndpc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh
c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+KiAmcXVvdDsmZ3Q7JnF1b3Q7LCAm
cXVvdDsmbHQ7PSZxdW90OywgJnF1b3Q7Jmd0Oz0mcXVvdDsg4oCUIHNpbWlsYXIgdG8gJnF1b3Q7
Jmx0OyZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm
Ijtjb2xvcjojMUY0OTdEJz4qICZsdDtwb2ludGVyJmd0OzombHQ7cHJlZGljYXRlJmd0OyDigJQg
ZXZhbHVhdGUgdGhlIHByZWRpY2F0ZSBhZ2FpbnN0IHRoZSBwYXJ0IG9mIHRoZSB0YXJnZXQgc2Vs
ZWN0ZWQgYnkgdGhlIHBvaW50ZXIuIEEgJmx0O3BvaW50ZXImZ3Q7IGNhbiBvbmx5IGJlIHRoZSBl
bXB0eSBzdHJpbmcgb3IgYSBzdHJpbmcgc3RhcnRpbmcgd2l0aCAmcXVvdDsvJnF1b3Q7LCB3aGlj
aCBhbGxvd3MgYWxsIHBvc3NpYmxlIHBvaW50ZXJzIHRvIGJlIGRpc3Rpbmd1aXNoZWQgZnJvbSBv
dGhlciAmbHQ7cHJlZGljYXRlLW9wJmd0OyBuYW1lcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg
Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+KiAmbHQ7dW5yZWNvZ25pemVk
Jmd0OzombHQ7YW55Jmd0OyDigJQgYW55IHVucmVjb2duaXplZCBlbGVtZW50IGluIGEgJmx0O3By
ZWRpY2F0ZSZndDsgaXMgdHJlYXRlZCBhcyB0aG91Z2ggaXQgZXZhbHVhdGVzIHRvIGZhbHNlPG86
cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5
N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm
Ijtjb2xvcjojMUY0OTdEJz4mcXVvdDt0ZXN0MiZxdW90OyBpcyBhIG5ldyBvcGVyYXRpb24gZGVm
aW5lZCBmb3IganNvbi1wYXRjaC4gSXQgTVVTVCBoYXZlIGEgJnF1b3Q7PyZxdW90OyBtZW1iZXIg
d2hvc2UgdmFsdWUgaXMgYSAmbHQ7cHJlZGljYXRlJmd0OyB0aGF0IGV2YWx1YXRlcyB0aGUgdGFy
Z2V0IHNlbGVjdGVkIGJ5IHRoZSAmcXVvdDtwYXRoJnF1b3Q7IG1lbWJlci4gSXQgTUFZIGhhdmUg
YSAmcXVvdDtvcHMmcXVvdDsgbWVtYmVyIHdob3NlIHZhbHVlIGlzIGFuIGFycmF5IG9mIG9wZXJh
dGlvbnMuIFRob3NlIG9wZXJhdGlvbnMgYXJlIGFwcGxpZWQgb25seSBpZiB0aGUgcHJlZGljYXRl
IGV2YWx1YXRlcyB0byB0cnVlLiBJdCBpcyBhbiBlcnJvciBpZiB0aGUgcHJlZGljYXRlIGV2YWx1
YXRlcyB0byBmYWxzZSBhbmQgJnF1b3Q7b3BzJnF1b3Q7IGlzIG5vdCBwcmVzZW50LCBpZSBwcm9j
ZXNzaW5nIHRoZSBwYXRjaCBmYWlscy4gTm90aGluZyBoYXBwZW5zIGluIHRoZSBvdGhlciB0d28g
Y2FzZXMgKHByZWRpY2F0ZSBpcyBmYWxzZSBhbmQgb3BzIHByZXNlbnQ7IHByZWRpY2F0ZSB0cnVl
IGFuZCBvcHMgYWJzZW50KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs
YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgZXhh
bXBsZXMgZnJvbSBkcmFmdC1zbmVsbC1qc29uLXRlc3QtMDEgcmUtd3JpdHRlbiBpbiB0aGlzIHN5
bnRheC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s
b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h
bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv
cjojMUY0OTdEJz7CpzEuIEludHJvZHVjdGlvbiBbbWF0Y2ggaW1wbGVtZW50cyDigJxjb250YWlu
c+KAnSwgYW5kIGltcGxpZXMg4oCcdHlwZeKAnSBzaW5jZSBpdCBvbmx5IHdvcmtzIGFnYWluc3Qg
c3RyaW5nc108bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0Qn
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+
wqAgW3smcXVvdDtvcCZxdW90OzomcXVvdDt0ZXN0MiZxdW90OywgJnF1b3Q7cGF0aCZxdW90Ozom
cXVvdDsvYS9iL2MmcXVvdDssICZxdW90Oz8mcXVvdDs6eyZxdW90O21hdGNoJnF1b3Q7OiZxdW90
Oy4qQUJDLiomcXVvdDt9IH0sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h
bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv
cjojMUY0OTdEJz7CoCDCoHsmcXVvdDtvcCZxdW90OzomcXVvdDtyZXBsYWNlJnF1b3Q7LCAmcXVv
dDtwYXRoJnF1b3Q7OiZxdW90Oy9hL2IvYyZxdW90OywgJnF1b3Q7dmFsdWUmcXVvdDs6MTIzfV08
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+wqcyLjIuMS4g
Y29udGFpbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0Qn
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+
wqAgW3smcXVvdDtvcCZxdW90OzomcXVvdDt0ZXN0MiZxdW90OywgJnF1b3Q7cGF0aCZxdW90Ozom
cXVvdDsvYS9iJnF1b3Q7LCAmcXVvdDs/JnF1b3Q7OnsmcXVvdDttYXRjaCZxdW90OzomcXVvdDsu
KiBpcyBhIC4qJnF1b3Q7fSB9XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt
YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s
b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h
bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv
cjojMUY0OTdEJz7CoCBbeyZxdW90O29wJnF1b3Q7OiZxdW90O3Rlc3QyJnF1b3Q7LCAmcXVvdDtw
YXRoJnF1b3Q7OiZxdW90Oy9hL2ImcXVvdDssICZxdW90Oz8mcXVvdDs6eyZxdW90O21hdGNoJnF1
b3Q7OiZxdW90Oyg/aSkuKiBJcyBBIC4qJnF1b3Q7fSB9XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw
IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7CpzIuMi4yIGRlZmluZWQ8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+wqAgW3smcXVvdDtvcCZxdW90OzomcXVv
dDt0ZXN0MiZxdW90OywgJnF1b3Q7cGF0aCZxdW90OzomcXVvdDsvYS9iJnF1b3Q7LCAmcXVvdDs/
JnF1b3Q7OnsmcXVvdDtwcmVzZW50JnF1b3Q7OnRydWV9IH1dPG86cD48L286cD48L3NwYW4+PC9w
PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKgIFt7JnF1b3Q7b3AmcXVvdDs6JnF1b3Q7dGVz
dDImcXVvdDssICZxdW90O3BhdGgmcXVvdDs6JnF1b3Q7L2EvYyZxdW90OywgJnF1b3Q7PyZxdW90
Ozp7JnF1b3Q7cHJlc2VudCZxdW90Ozp0cnVlfSB9XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs
YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
b25zb2xhcztjb2xvcjojMUY0OTdEJz7CpzIuMi4zLiBlbmRzPG86cD48L286cD48L3NwYW4+PC9w
PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKgIFt7JnF1b3Q7b3AmcXVvdDs6JnF1b3Q7dGVz
dDImcXVvdDssICZxdW90O3BhdGgmcXVvdDs6JnF1b3Q7L2EvYiZxdW90OywgJnF1b3Q7PyZxdW90
Ozp7JnF1b3Q7bWF0Y2gmcXVvdDs6JnF1b3Q7LiogdGVzdCZxdW90O30gfV08bzpwPjwvbzpwPjwv
c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+wqAgW3smcXVvdDtvcCZxdW90Ozom
cXVvdDt0ZXN0MiZxdW90OywgJnF1b3Q7cGF0aCZxdW90OzomcXVvdDsvYS9iJnF1b3Q7LCAmcXVv
dDs/JnF1b3Q7OnsmcXVvdDttYXRjaCZxdW90OzomcXVvdDsoP2kpLiogVEVTVCZxdW90O30gfV08
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+wqcyLjIuNC4g
aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+wqAgW3sm
cXVvdDtvcCZxdW90OzomcXVvdDt0ZXN0MiZxdW90OywgJnF1b3Q7cGF0aCZxdW90OzomcXVvdDsv
YS9iJnF1b3Q7LCAmcXVvdDs/JnF1b3Q7OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N
c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s
YXM7Y29sb3I6IzFGNDk3RCc+wqDCoMKgwqAgeyZxdW90O29yJnF1b3Q7Olt7JnF1b3Q7PSZxdW90
OzoxfSwgeyZxdW90Oz0mcXVvdDs6JnF1b3Q7Zm9vJnF1b3Q7fSwgeyZxdW90Oz0mcXVvdDs6MTB9
LCB7JnF1b3Q7PSZxdW90Ozp7JnF1b3Q7eiZxdW90OzomcXVvdDt5JnF1b3Q7fX1dfSB9XTxvOnA+
PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7CpzIuMi41LiBsZXNz
PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKgIFt7JnF1
b3Q7b3AmcXVvdDs6JnF1b3Q7dGVzdDImcXVvdDssICZxdW90O3BhdGgmcXVvdDs6JnF1b3Q7L2Ev
YiZxdW90OywgJnF1b3Q7PyZxdW90Ozp7JnF1b3Q7Jmx0OyZxdW90OzoxNX0gfV08bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+wqcyLjIuNi4gbWF0Y2hlcyBb
YW4gZXhhbXBsZSB3aGVyZSBjYXNlIHNlbnNpdGl2aXR5IG1hdHRlcnMgd291bGQgYmUgYmV0dGVy
XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7CoCBbeyZx
dW90O29wJnF1b3Q7OiZxdW90O3Rlc3QyJnF1b3Q7LCAmcXVvdDtwYXRoJnF1b3Q7OiZxdW90Oy9h
L2ImcXVvdDssICZxdW90Oz8mcXVvdDs6eyZxdW90O21hdGNoJnF1b3Q7OiZxdW90O1tcXHdcXHNd
KiZxdW90O30gfV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5
N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3
RCc+wqAgW3smcXVvdDtvcCZxdW90OzomcXVvdDt0ZXN0MiZxdW90OywgJnF1b3Q7cGF0aCZxdW90
OzomcXVvdDsvYS9iJnF1b3Q7LCAmcXVvdDs/JnF1b3Q7OnsmcXVvdDttYXRjaCZxdW90OzomcXVv
dDsoP2kpW1xcd1xcc10qJnF1b3Q7fSB9XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N
c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s
YXM7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z
b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xh
cztjb2xvcjojMUY0OTdEJz7CpzIuMi43LiBtb3JlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs
YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
b25zb2xhcztjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh
c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv
bnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKgIFt7JnF1b3Q7b3AmcXVvdDs6JnF1b3Q7dGVzdDImcXVv
dDssICZxdW90O3BhdGgmcXVvdDs6JnF1b3Q7L2EvYiZxdW90OywgJnF1b3Q7PyZxdW90Ozp7JnF1
b3Q7Jmd0OyZxdW90Ozo1fSB9XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt
YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s
b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h
bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv
cjojMUY0OTdEJz7CpzIuMi44LiBzdGFydHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9
TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv
bGFzO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N
c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s
YXM7Y29sb3I6IzFGNDk3RCc+wqAgW3smcXVvdDtvcCZxdW90OzomcXVvdDt0ZXN0MiZxdW90Oywg
JnF1b3Q7cGF0aCZxdW90OzomcXVvdDsvYS9iJnF1b3Q7LCAmcXVvdDs/JnF1b3Q7OnsmcXVvdDtt
YXRjaCZxdW90OzomcXVvdDtUaGlzIC4qJnF1b3Q7fSB9XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw
IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7CoCBbeyZxdW90O29wJnF1b3Q7OiZxdW90O3Rlc3Qy
JnF1b3Q7LCAmcXVvdDtwYXRoJnF1b3Q7OiZxdW90Oy9hL2ImcXVvdDssICZxdW90Oz8mcXVvdDs6
eyZxdW90O21hdGNoJnF1b3Q7OiZxdW90Oyg/aSlUaGlzIC4qJnF1b3Q7fSB9XTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7CpzIuMi45LiB0ZXN0PG86cD48
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKgIFt7JnF1b3Q7b3Am
cXVvdDs6JnF1b3Q7dGVzdDImcXVvdDssICZxdW90O3BhdGgmcXVvdDs6JnF1b3Q7L2EvYiZxdW90
OywgJnF1b3Q7PyZxdW90Ozp7JnF1b3Q7PSZxdW90OzomcXVvdDt0aGlzIGlzIGEgdGVzdCZxdW90
O30gfV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+wqcy
LjIuMTAuIHR5cGUgW3VzZSAmcXVvdDtwcmVzZW50JnF1b3Q7OmZhbHNlIGZvciAmcXVvdDt1bmRl
ZmluZWQmcXVvdDs7ICZxdW90O21hdGNoJnF1b3Q7OiZsdDtyZWdleCZndDsgZm9yIGRhdGUsIGRh
dGUtdGltZSwgdGltZSwgbGFuZywgbGFuZy1yYW5nZSwgaXJpLCBhYnNvbHV0ZS1pcmldPG86cD48
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKgIFt7JnF1b3Q7b3Am
cXVvdDs6JnF1b3Q7dGVzdDImcXVvdDssICZxdW90O3BhdGgmcXVvdDs6JnF1b3Q7L2EvYiZxdW90
OywgJnF1b3Q7PyZxdW90Ozp7JnF1b3Q7dHlwZSZxdW90OzomcXVvdDsmcXVvdDt9IH1dPG86cD48
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKnMi4yLjExIHVuZGVm
aW5lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7CoCBb
eyZxdW90O29wJnF1b3Q7OiZxdW90O3Rlc3QyJnF1b3Q7LCAmcXVvdDtwYXRoJnF1b3Q7OiZxdW90
Oy9hL2MmcXVvdDssICZxdW90Oz8mcXVvdDs6eyZxdW90O3ByZXNlbnQmcXVvdDs6ZmFsc2V9IH1d
PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKgIFt7JnF1
b3Q7b3AmcXVvdDs6JnF1b3Q7dGVzdDImcXVvdDssICZxdW90O3BhdGgmcXVvdDs6JnF1b3Q7L2Ev
YiZxdW90OywgJnF1b3Q7PyZxdW90Ozp7JnF1b3Q7cHJlc2VudCZxdW90OzpmYWxzZX0gfV08bzpw
PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+wqcyLjMuIFNlY29u
ZC1PcmRlciBQcmVkaWNhdGVzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h
bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv
cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y
OiMxRjQ5N0QnPsKgIFt7JnF1b3Q7b3AmcXVvdDs6JnF1b3Q7dGVzdDImcXVvdDssICZxdW90O3Bh
dGgmcXVvdDs6JnF1b3Q7L2EvYiZxdW90OywgJnF1b3Q7PyZxdW90Ozp7JnF1b3Q7L2MmcXVvdDs6
eyZxdW90O3ByZXNlbnQmcXVvdDs6dHJ1ZX19IH1dPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs
YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
b25zb2xhcztjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh
c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv
bnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKnMi4zLjEuIGFuZCAoZG9u4oCZdCBuZWVkIHRvIHVzZSDi
gJxhbmTigJ0gdW5sZXNzIGFwcGx5aW5nIHRoZSBzYW1lICZsdDtwcmVkaWNhdGUtb3AmZ3Q7IHRv
IHRoZSBzYW1lIHZhbHVlIHR3byBvciBtb3JlIHRpbWVzLCB3aGljaCBzaG91bGQgYmUgcmFyZSkg
W2NoZWNraW5nIHByZXNlbmNlIGlzIHJlZHVuZGFudCBpZiBjaGVja2luZyB0eXBlXTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7CoCBbeyZxdW90O29wJnF1
b3Q7OiZxdW90O3Rlc3QyJnF1b3Q7LCAmcXVvdDtwYXRoJnF1b3Q7OiZxdW90OyZxdW90OywgJnF1
b3Q7PyZxdW90Ozp7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0
OTdEJz7CoMKgwqDCoMKgICZxdW90Oy9hL2ImcXVvdDs6eyZxdW90O3ByZXNlbnQmcXVvdDs6dHJ1
ZX0sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7CoMKg
wqDCoMKgICZxdW90Oy9hL2MvZCZxdW90Ozp7JnF1b3Q7Jmx0OyZxdW90OzoxNX0gfSB9XTxvOnA+
PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7CoCBbeyZxdW90O29w
JnF1b3Q7OiZxdW90O3Rlc3QyJnF1b3Q7LCAmcXVvdDtwYXRoJnF1b3Q7OiZxdW90OyZxdW90Oywg
JnF1b3Q7PyZxdW90Ozp7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj
MUY0OTdEJz7CoMKgwqDCoMKgICZxdW90Oy9hL2MmcXVvdDs6eyZxdW90O3ByZXNlbnQmcXVvdDs6
dHJ1ZX0sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7C
oMKgwqDCoMKgICZxdW90Oy9hL2MmcXVvdDs6eyZxdW90O3R5cGUmcXVvdDs6JnF1b3Q7JnF1b3Q7
fSB9IH1dPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKn
Mi4zLjIuIG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3
RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdE
Jz7CoCBbeyZxdW90O29wJnF1b3Q7OiZxdW90O3Rlc3QyJnF1b3Q7LCAmcXVvdDtwYXRoJnF1b3Q7
OiZxdW90OyZxdW90OywgJnF1b3Q7PyZxdW90Ozp7JnF1b3Q7bm90JnF1b3Q7OnsmcXVvdDtvciZx
dW90OzpbPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7C
oMKgwqDCoMKgIHsmcXVvdDsvYS9iL2UmcXVvdDs6eyZxdW90O3ByZXNlbnQmcXVvdDs6dHJ1ZX19
LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+wqDCoMKg
wqDCoCB7JnF1b3Q7L2EvYy9kJnF1b3Q7OnsmcXVvdDsmbHQ7JnF1b3Q7OjV9fSB9IH1dPG86cD48
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKgIFt7JnF1b3Q7b3Am
cXVvdDs6JnF1b3Q7dGVzdDImcXVvdDssICZxdW90O3BhdGgmcXVvdDs6JnF1b3Q7JnF1b3Q7LCAm
cXVvdDs/JnF1b3Q7OnsmcXVvdDtub3QmcXVvdDs6eyZxdW90O29yJnF1b3Q7Ols8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKgwqAgeyZxdW90
Oy9hL2MmcXVvdDs6eyZxdW90O3ByZXNlbnQmcXVvdDs6ZmFsc2V9fSw8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKgwqAgeyZxdW90Oy9hL2Im
cXVvdDs6eyZxdW90O21hdGNoJnF1b3Q7OiZxdW90O2YuKiZxdW90O319IF19fSB9XTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7CpzIuMy4zLiBvciBbZXhh
bXBsZXMgYXJlIHdyb25nIGFzIHRoZXkgdXNlIOKAnHRlc3TigJ0gd2l0aG91dCBhIOKAnHZhbHVl
4oCdXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7CoCBb
eyZxdW90O29wJnF1b3Q7OiZxdW90O3Rlc3QyJnF1b3Q7LCAmcXVvdDtwYXRoJnF1b3Q7OiZxdW90
OyZxdW90OywgJnF1b3Q7PyZxdW90Ozp7JnF1b3Q7b3ImcXVvdDs6WzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+wqDCoMKgwqDCoCB7JnF1b3Q7L2EvYiZx
dW90Ozp7JnF1b3Q7cHJlc2VudCZxdW90Ozp0cnVlfX0sPG86cD48L286cD48L3NwYW4+PC9wPjxw
IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7CoMKgwqDCoMKgIHsmcXVvdDsvYS9jL2QmcXVvdDs6
eyZxdW90OyZsdDsmcXVvdDs6NX19IF19IH1dPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz
PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25z
b2xhcztjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9
TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv
bGFzO2NvbG9yOiMxRjQ5N0QnPsKgIFt7JnF1b3Q7b3AmcXVvdDs6JnF1b3Q7dGVzdDImcXVvdDss
ICZxdW90O3BhdGgmcXVvdDs6JnF1b3Q7JnF1b3Q7LCAmcXVvdDs/JnF1b3Q7OnsmcXVvdDtvciZx
dW90OzpbPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7C
oMKgwqDCoMKgIHsmcXVvdDsvYS9lJnF1b3Q7OnsmcXVvdDtwcmVzZW50JnF1b3Q7OnRydWV9fSw8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKg
wqAgeyZxdW90Oy9hL2YmcXVvdDs6eyZxdW90O3ByZXNlbnQmcXVvdDs6dHJ1ZX19IF19IH1dPG86
cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKnMi4zLjQuIE5l
c3RpbmcgU2Vjb25kIE9yZGVyIFByZWRpY2F0ZXPCoCBbdHlwZSB0ZXN0IGlzIHJlZHVuZGFudCBo
ZXJlXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz7CoCBb
eyZxdW90O29wJnF1b3Q7OiZxdW90O3Rlc3QyJnF1b3Q7LCAmcXVvdDtwYXRoJnF1b3Q7OiZxdW90
Oy9hL2ImcXVvdDssICZxdW90Oz8mcXVvdDs6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz
PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25z
b2xhcztjb2xvcjojMUY0OTdEJz7CoMKgwqAgeyZxdW90O29yJnF1b3Q7Ols8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKgwqAgeyZxdW90Oy9j
JnF1b3Q7OnsmcXVvdDtub3QmcXVvdDs6eyZxdW90O29yJnF1b3Q7Ols8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKgwqDCoMKgIHsmcXVvdDtw
cmVzZW50JnF1b3Q7OmZhbHNlfSwgeyZxdW90O21hdGNoJnF1b3Q7OiZxdW90O2YuKiZxdW90O308
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKg
wqAgXX19fSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0Qn
PsKgwqDCoMKgwqAgeyZxdW90Oy9kJnF1b3Q7OnsmcXVvdDtub3QmcXVvdDs6eyZxdW90O29yJnF1
b3Q7Ols8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPsKg
wqDCoMKgwqDCoMKgIHsmcXVvdDtwcmVzZW50JnF1b3Q7OnRydWV9LCB7JnF1b3Q7dHlwZSZxdW90
OzowfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+wqDC
oMKgwqDCoCBdfX19PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0
OTdEJz7CoMKgwqAgXX08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMx
RjQ5N0QnPsKgIF08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5
N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3
RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
O2NvbG9yOiMxRjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h
bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh
bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2Jv
cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj
bSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206
PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYu
b3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBP
ZiA8L2I+SmFtZXMgTSBTbmVsbDxicj48Yj5TZW50OjwvYj4gRnJpZGF5LCAxOSBPY3RvYmVyIDIw
MTIgODo1NyBBTTxicj48Yj5Ubzo8L2I+IElFVEYgQXBwcyBEaXNjdXNzPGJyPjxiPlN1YmplY3Q6
PC9iPiBbYXBwcy1kaXNjdXNzXSBVcGRhdGUgdG8gSlNPTiBQcmVkaWNhdGVzPG86cD48L286cD48
L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw
PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVy
IE5ldyInPkJhc2VkIG9uIHNvbWUgaW5pdGlhbCBkaXJlY3QgZmVlZGJhY2sgSSByZWNlaXZlZCBv
biB0aGUgLTAwIGRyYWZ0LCBJIGhhdmUgc3VibWl0dGVkIGFuIHVwZGF0ZWQgZHJhZnQuLjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw
PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1p
bHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9y
Zy9pZC9kcmFmdC1zbmVsbC1qc29uLXRlc3QtMDEudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2lk
L2RyYWZ0LXNuZWxsLWpzb24tdGVzdC0wMS50eHQ8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv
ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjxk
aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBO
ZXciJz5TZXZlcmFsIGtleSBtb2RpZmljYXRpb25zIHdlcmUgbWFkZS4uPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi
Q291cmllciBOZXciJz4mbmJzcDsxLiBTcGVjaWZpYyBtZW50aW9uIGlzIG1hZGUgcmU6IHRoZSB1
c2Ugb2YgdGhlIEpTT04tUGF0Y2ggJnF1b3Q7dGVzdCZxdW90OyBvcGVyYXRpb24gYXMgYSBQcmVk
aWNhdGUgd2l0aCB0aGUgYWRkaXRpb24gb2YgYW4gb3B0aW9uYWwgJnF1b3Q7aWdub3JlX2Nhc2Um
cXVvdDsgbWVtYmVyIGNvbnNpc3RlbnQgd2l0aCB0aGUgb3RoZXIgdGV4dCBjb21wYXJpc29uIHBy
ZWRpY2F0ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y
bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz
cGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsyLiBBZGRpdGlvbiBv
ZiBhbiAmcXVvdDtpbiZxdW90OyBwcmVkaWNhdGUgb3BlcmF0aW9uIHRoYXQgdGVzdHMgd2hldGhl
ciB0aGUgdmFsdWUgaXMgcGFydCBvZiBhIGdpdmVuIGxpc3Qgb2YgdmFsdWVzLi4gZm9yIGluc3Rh
bmNlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48
bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz
dHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwOyB7JnF1b3Q7b3Am
cXVvdDs6ICZxdW90O2luJnF1b3Q7LCAmcXVvdDtwYXRoJnF1b3Q7OiAmcXVvdDsvYS9iL2MmcXVv
dDssICZxdW90O3ZhbHVlJnF1b3Q7OiBbMSwyLDMsNCw1XX08L3NwYW4+PG86cD48L286cD48L3A+
PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+
PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVy
IE5ldyInPiZuYnNwOyAmbmJzcDsgUmV0dXJucyB0cnVlIGlmIHRoZSB2YWx1ZSBvZiAmcXVvdDsv
YS9iL2MmcXVvdDsgaXMgaW4gdGhlIGFycmF5IFsxLDIsMyw0LDVdPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwv
ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291
cmllciBOZXciJz4mbmJzcDszLiBBZGRpdGlvbmFsIHR5cGVzIGZvciB0aGUgJnF1b3Q7dHlwZSZx
dW90OyBwcmVkaWNhdGUgb3BlcmF0aW9uIGluY2x1ZGluZzogZGF0ZSwgdGltZSwgZGF0ZS10aW1l
LCBsYW5nLCBsYW5nLXJhbmdlLCBpcmkgYW5kIGFic29sdXRlLWlyaS4gVGhlc2UgYXJlIGludGVu
ZGVkIHRvIHRlc3QgaWYgYSBKU09OIHN0cmluZyBjb25mb3JtcyB0byBhIHNwZWNpZmljIHNldCBv
ZiBjb21tb24gUkZDIGRlZmluZWQgZGF0YSB0eXBlcy4gVGhlIHR5cGVzIGFyZSBkcmF3biBmcm9t
IFJGQydzIDMzMzksIDM5ODcsIDQ2NDYsIGFuZCA0NjQ3LiBUaGVzZSB0eXBlcyBhcmUgY29tbW9u
IHRvIG1hbnkgSlNPTiBkYXRhIGZvcm1hdHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk
aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg
Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4m
bmJzcDsgJm5ic3A7IHsmcXVvdDtvcCZxdW90OzogJnF1b3Q7dHlwZSZxdW90OywgJnF1b3Q7cGF0
aCZxdW90OzogJnF1b3Q7L2EvYi9jJnF1b3Q7LCAmcXVvdDt2YWx1ZSZxdW90OzogJnF1b3Q7ZGF0
ZS10aW1lJnF1b3Q7fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z
b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h
bD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwOyBS
ZXR1cm5zIHRydWUgaWYgdGhlIHZhbHVlIG9mICZxdW90Oy9hL2IvYyZxdW90OyBpcyBhbiBSRkMz
MzM5IGRhdGUtdGltZSBsaWtlICZxdW90OzIwMTItMTItMTJUMTI6MTI6MTJaJnF1b3Q7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250
LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7IHsmcXVvdDtvcCZxdW90OzogJnF1
b3Q7dHlwZSZxdW90OywgJnF1b3Q7cGF0aCZxdW90OzogJnF1b3Q7L2EvYi9jJnF1b3Q7LCAmcXVv
dDt2YWx1ZSZxdW90OzogJnF1b3Q7YWJzb2x1dGUtaXJpJnF1b3Q7fTwvc3Bhbj48bzpwPjwvbzpw
PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48
L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNv
dXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwOyBSZXR1cm5zIHRydWUgaWYgdGhlIHZhbHVlIG9mICZx
dW90Oy9hL2IvYyZxdW90OyBpcyBhbiBBYnNvbHV0ZSBJUkkgcmVmZXJlbmNlIGxpa2UgJnF1b3Q7
PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUub3JnL2ZvbyI+aHR0cDovL2V4YW1wbGUub3JnL2Zvbzwv
YT4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt
YWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw
YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDsgeyZxdW90
O29wJnF1b3Q7OiAmcXVvdDt0eXBlJnF1b3Q7LCAmcXVvdDtwYXRoJnF1b3Q7OiAmcXVvdDsvYS9i
L2MmcXVvdDssICZxdW90O3ZhbHVlJnF1b3Q7OiAmcXVvdDtsYW5nJnF1b3Q7fTwvc3Bhbj48bzpw
PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw
PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1p
bHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwOyBSZXR1cm5zIHRydWUgaWYgdGhlIHZhbHVl
IG9mICZxdW90Oy9hL2IvYyZxdW90OyBpcyBhIExhbmd1YWdlIFRhZyBsaWtlICZxdW90O2VuLVVT
JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz40LiBTZXZlcmFsIGNsYXJpZmljYXRp
b25zIGFuZCBlZGl0b3JpYWwgZml4ZXMgd2VyZSBtYWRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48
L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48
ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIg
TmV3Iic+QXMgYWx3YXlzLCBjb21tZW50cyBhcmUgd2VsY29tZS4gVW5sZXNzIHRoZXJlIGFyZSBz
aWduaWZpY2FudCBjaGFuZ2VzIG1hZGUgdG8gSlNPTiBQYXRjaCBvciBzaWduaWZpY2FudCBpc3N1
ZXMgZm91bmQgd2l0aCB0aGlzIHNwZWNpZmljYXRpb24sIEkgZG8gbm90IGFudGljaXBhdGUgbWFr
aW5nIGFueSBmdXJ0aGVyIHRlY2huaWNhbCBjaGFuZ2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48
L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48
ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIg
TmV3Iic+LSBKYW1lczwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Jv
ZHk+PC9odG1sPg==

--_000_255B9BB34FB7D647A506DC292726F6E114FDEC39B3WSMSG3153Vsrv_--

From jan.algermissen@nordsc.com  Fri Oct 19 02:27:40 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EB021F8689 for ; Fri, 19 Oct 2012 02:27:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Roo4F82ExUAN for ; Fri, 19 Oct 2012 02:27:39 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4285D21F8584 for ; Fri, 19 Oct 2012 02:27:39 -0700 (PDT)
Received: from [10.90.130.25] ([87.253.171.208]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Ld3qq-1Syurq1mOO-00iJB3; Fri, 19 Oct 2012 11:27:38 +0200
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Jan Algermissen 
In-Reply-To: 
Date: Fri, 19 Oct 2012 11:27:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CC34B21-09D5-4766-BEA4-525102ECF133@nordsc.com>
References: 
To: James M Snell 
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:eOLGFd3TgPUJMh2sRjWegzVAsDUSuMiBsymV5ypyhSt x1b2sA2RY2cX3VMtssHDdTgiJeNUOj835ExqddP2I7HHL0ssbB 79ESDW3ZIzjs2QacCCvmQ1vH6LM1qipBDXUx6ETVoHKMpr0ntR p+xAodNTsjqz8eny5M8k5jZh4BSAzbRFWax/A/6WpVKBbLzaeV ZPP+3babqFaa6yKs6PoHKgeG+nOF5ZfNAsb25So5LIrlJXZSA4 4tyR6rQEjh48o6WMZzQcWroxsrJZe9Ofbne2QfNfIU6e2QZGUA IgqMAvETZ/+3j0i+Eyf47HOJ+GW6wrY/ssCZjXeRuL+Zt+fFRu V5iL3IqCG4nBJwKc3Rawmggd188urMJ7W7f4etZb788/MuFEUe 6Bvqod5f+fc7Q==
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] Updated 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: Fri, 19 Oct 2012 09:27:40 -0000

Hi James,

On Oct 18, 2012, at 7:21 PM, James M Snell wrote:

>=20
>   http://www.ietf.org/id/draft-snell-merge-patch-05.txt

Just thought that this bears an interesting use case for '+json'. Your =
media type does not only apply to application/json, but to all +json =
media types.

That said, a client can not only patch a resource with you media type =
that is available in application/json. It can also reasonably infer that =
if, if a resource is available as, eg. application/vnd.foo.product+json =
it makes sense to construct and send a PATCH using your media type.

That put a totally different light on +json, which I personally have =
seen as sort of YAGNI so far. Interesting.

You might want to consider making a note to that when you touch the =
draft next time.

Jan




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


From jasnell@gmail.com  Fri Oct 19 09:13:03 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1E021F876B for ; Fri, 19 Oct 2012 09:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.762
X-Spam-Level: 
X-Spam-Status: No, score=-4.762 tagged_above=-999 required=5 tests=[AWL=-1.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFHuyMbt7O7j for ; Fri, 19 Oct 2012 09:13:03 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 40AEC21F870E for ; Fri, 19 Oct 2012 09:13:03 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id s14so471966qcg.31 for ; Fri, 19 Oct 2012 09:13:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=t4XztL5Q+6WhpecQdoGNXOxRG3+8r/KrY7980+1rV0g=; b=LuQil+cvPv5VHBldgP7N3v0KecvOjbGtv0sDzFTSFlxeLsB9p8T8rsgfUgF2mJ/DR6 3MyeW+9czVPGZ0LjInP1Gp1tyWAiFWIiAyLRzsFUspvOpLeGTHccQTJdYstgZwwCWKCV OCJkkAld3USt41lhtuPwfOw+34+t/AicWNQ4SvTtvOOtdVR92j4dEjKpipLZj9XGWjMR MK7Dq36ZX+5MBStLYxNGUVCXnN0EGmzs21UxxgI2FAqk6ciUkDqaiiOkcb1jyxvCWwRJ YBGNXHkVUdCNB0k9+usb69cJxBAAyjoZYz7lRIM061XfWXGICV5Rpg6emQjDhJmLG5h7 vXtA==
Received: by 10.229.175.37 with SMTP id v37mr188794qcz.134.1350663182747; Fri, 19 Oct 2012 09:13:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.81.230 with HTTP; Fri, 19 Oct 2012 09:12:42 -0700 (PDT)
In-Reply-To: <8CC34B21-09D5-4766-BEA4-525102ECF133@nordsc.com>
References:  <8CC34B21-09D5-4766-BEA4-525102ECF133@nordsc.com>
From: James M Snell 
Date: Fri, 19 Oct 2012 09:12:42 -0700
Message-ID: 
To: Jan Algermissen 
Content-Type: multipart/alternative; boundary=00504502964338082f04cc6bc729
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] Updated 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: Fri, 19 Oct 2012 16:13:04 -0000

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

+1 ... yes, that would be worthwhile to mention.

On Fri, Oct 19, 2012 at 2:27 AM, Jan Algermissen  wrote:

> Hi James,
>
> On Oct 18, 2012, at 7:21 PM, James M Snell wrote:
>
> >
> >   http://www.ietf.org/id/draft-snell-merge-patch-05.txt
>
> Just thought that this bears an interesting use case for '+json'. Your
> media type does not only apply to application/json, but to all +json media
> types.
>
> That said, a client can not only patch a resource with you media type that
> is available in application/json. It can also reasonably infer that if, if
> a resource is available as, eg. application/vnd.foo.product+json it makes
> sense to construct and send a PATCH using your media type.
>
> That put a totally different light on +json, which I personally have seen
> as sort of YAGNI so far. Interesting.
>
> You might want to consider making a note to that when you touch the draft
> next time.
>
> Jan
>
>
>
>
> >
> > - James
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

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

+1 ... yes, that would be worthwhile t=
o mention.

On Fri, Oct 19, 2012 at=
 2:27 AM, Jan Algermissen <jan.algermissen@nordsc.com> wrote:



Hi James,



On Oct 18, 2012, at 7:21 PM, James M Snell wrote:



>

> =C2=A0 http://www.ietf.org/id/draft-snell-merge-patch-05.txt<=
/a>



Just thought that this bears an interesting use case for '+json'. Y=
our media type does not only apply to application/json, but to all +json me=
dia types.



That said, a client can not only patch a resource with you media type that =
is available in application/json. It can also reasonably infer that if, if =
a resource is available as, eg. application/vnd.foo.product+json it makes s=
ense to construct and send a PATCH using your media type.





That put a totally different light on +json, which I personally have seen a=
s sort of YAGNI so far. Interesting.



You might want to consider making a note to that when you touch the draft n=
ext time.



Jan









>

> - James

> _______________________________________________

> apps-discuss mailing list

> apps-discuss@ietf.org

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







--00504502964338082f04cc6bc729--

From internet-drafts@ietf.org  Fri Oct 19 18:20:57 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E654B21F8830; Fri, 19 Oct 2012 18:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.528
X-Spam-Level: 
X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 6QknYUY20XPo; Fri, 19 Oct 2012 18:20:56 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C08F21F8847; Fri, 19 Oct 2012 18:20:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121020012056.4511.47340.idtracker@ietfa.amsl.com>
Date: Fri, 19 Oct 2012 18:20:56 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-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: Sat, 20 Oct 2012 01:20:57 -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-01.txt
	Pages           : 26
	Date            : 2012-10-19

Abstract:
   This specification defines the WebFinger protocol.  WebFinger may be
   used to discover information about people on the Internet, such as a
   person's personal profile address, identity service, telephone
   number, or preferred avatar.  WebFinger may also be used to discover
   information about objects on the network, such as the amount of toner
   in a printer or the physical location of a server.


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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-01


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


From paulej@packetizer.com  Fri Oct 19 18:22:11 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7566921F881C for ; Fri, 19 Oct 2012 18:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.386
X-Spam-Level: 
X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.212,  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 sDLmsDJ8sIN9 for ; Fri, 19 Oct 2012 18:22:09 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4225C21F84B8 for ; Fri, 19 Oct 2012 18:22:09 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9K1M70H022121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Oct 2012 21:22:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1350696128; bh=pQfwQtxkDx9Zf2HsgllgoLXbfXNx8mVq94HFqJDgpa8=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=jZ+tVMms5M6Xp2+iRRgcgVF5Y90LE2tLCuKyCzUDQLcgNCe3KAuqUKKHE3W6l50z5 ot15knK0vcIO95f2Kibu+6HXuDgMLDMTc5TuL7tZzBK70ntVPgA4EGFFkssGAA3Mzr 6N0n1CQkpTkscYRwEmhhXf5aAIfXzyH90L49gSIY=
From: "Paul E. Jones" 
To: , 
Date: Fri, 19 Oct 2012 21:22:18 -0400
Message-ID: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_025C_01CDAE3F.D20E2F10"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac2uYU+3+AfvfD1SR8WCUo4W5V/9hg==
Content-Language: en-us
Subject: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-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: Sat, 20 Oct 2012 01:22:11 -0000

This is a multipart message in MIME format.

------=_NextPart_000_025C_01CDAE3F.D20E2F10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Folks,

 

I just posted a revised version of the WebFinger specification, taking into
consideration all of the discussion on the lists since the last document was
posted.

 

Here is a summary of the changes:

.         Editorial improvements, including non-technical changes

.         Made all examples in the main body of the document JSON only

.         JSON Resource Descriptor (JRD) documents are the only mandatory
format required to be implemented by a WebFinger server

.         Extensible Resource Descriptor (XRD) documents are now optional to
implement on the server

.         The default format for /.well-known/host-meta is XRD if the server
implements XRD; clients must be prepared to receive a JRD; the "Accept"
header is still used to negotiate the preferred type

.         The default format for /.well-known/host-meta.json is JRD

.         New text to consider hosting the WebFinger service elsewhere,
including outsourcing the service for the entire domain or only part of the
domain (the latter is more complex for the WebFinger server to implement,
but the former is straight-forward using HTTP redirection)

.         New text to address a few interoperability considerations with RFC
6415

.         Removal of the "Implementation Note" relating to the "acct" URI
since "acct" URI material is no longer a part of the document

.         Introduced a new Appendix that shows one of the examples from the
main body in XML format, along with procedures for using XML, and security
consideration related to this XRD signatures

 

I tried very hard to strike the right balance between what people want in
terms of having a very simple client implementation and the fact that there
are existing clients and servers.  Of course, new JSON-only clients will not
be able to get useful information from XML-only servers.  Likewise, XML-only
clients will not get useful information from JSON-only servers.  However, a
complete server implementation (XML and JSON) would work with either new or
old clients.

 

That said, this draft does represent what I believe is the consensus for
going forward.  The minimum requirements would be JSON on the client and
server side, and support for the "resource" parameter.  This allows a client
to get everything it's seeking with a request like this:

 

     GET /.well-known/host-meta.json?resource=acct%3Acarol%40example.com
HTTP/1.1

 

Comments are certainly welcome!  I hope we're getting close with this
version :-)

 

Paul

 

 

Filename:   draft-ietf-appsawg-webfinger

Revision:   01

Title:            WebFinger

Creation date:    2012-10-19

WG ID:            appsawg

Number of pages: 26

URL:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-01.txt

Status:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger

Htmlized:        http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-01

Diff:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-01

 


------=_NextPart_000_025C_01CDAE3F.D20E2F10
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Folks,
 
I just =
posted a revised version of the WebFinger specification, taking into =
consideration all of the discussion on the lists since the last document =
was posted.
 
Here is a summary of the changes:
·         =
Editorial improvements, including =
non-technical changes
·         =
Made all examples in the main body of the =
document JSON only
·         =
JSON Resource Descriptor (JRD) documents =
are the only mandatory format required to be implemented by a WebFinger =
server
·         =
Extensible Resource Descriptor (XRD) =
documents are now optional to implement on the server
·         =
The default format for =
/.well-known/host-meta is XRD if the server implements =
XRD; clients must be prepared to receive a JRD; the “Accept” =
header is still used to negotiate the preferred type
·         =
The default format for =
/.well-known/host-meta.json is JRD
·         =
New text to consider hosting the =
WebFinger service elsewhere, including outsourcing the service for the =
entire domain or only part of the domain (the latter is more complex for =
the WebFinger server to implement, but the former is straight-forward =
using HTTP redirection)
·         =
New text to address a few =
interoperability considerations with RFC 6415
·         =
Removal of the “Implementation =
Note” relating to the “acct” URI since =
“acct” URI material is no longer a part of the =
document
·         =
Introduced a new Appendix that shows one =
of the examples from the main body in XML format, along with procedures =
for using XML, and security consideration related to this XRD =
signatures
 
I tried very hard to strike the right balance between =
what people want in terms of having a very simple client implementation =
and the fact that there are existing clients and servers.  Of =
course, new JSON-only clients will not be able to get useful information =
from XML-only servers.  Likewise, XML-only clients will not get =
useful information from JSON-only servers.  However, a complete =
server implementation (XML and JSON) would work with either new or old =
clients.
 
That said, this draft does represent what I believe is =
the consensus for going forward.  The minimum requirements would be =
JSON on the client and server side, and support for the =
“resource” parameter.  This allows a client to get =
everything it’s seeking with a request like this:
 
     GET =
/.well-known/host-meta.json?resource=3Dacct%3Acarol%40example.com =
HTTP/1.1
 
Comments are =
certainly welcome!  I hope we’re getting close with this =
version :-)
 
Paul
 
 
Filename:    =
draft-ietf-appsawg-webfinger
Revision:    01
Title:       &nbs=
p;     WebFinger
Creation date:     =
2012-10-19
WG =
ID:             =
appsawg
Number of pages: =
26
URL:        =
     http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-=
01.txt
Status:       &nb=
sp;  htt=
p://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger<=
/p>
Htmlized:        =
http:=
//tools.ietf.org/html/draft-ietf-appsawg-webfinger-01
<=
p =
class=3DMsoPlainText>Diff:        =
;    http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-01=

 

------=_NextPart_000_025C_01CDAE3F.D20E2F10--


From evan@status.net  Sat Oct 20 08:37:19 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D9021F846F for ; Sat, 20 Oct 2012 08:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.154
X-Spam-Level: 
X-Spam-Status: No, score=-3.154 tagged_above=-999 required=5 tests=[AWL=-0.556, 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 lgBZsy95TSOc for ; Sat, 20 Oct 2012 08:37:18 -0700 (PDT)
Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 23B6921F8460 for ; Sat, 20 Oct 2012 08:37:17 -0700 (PDT)
Received: from [192.168.69.113] (modemcable107.194-202-24.mc.videotron.ca [24.202.194.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 376AF8D63A1 for ; Sat, 20 Oct 2012 15:48:22 +0000 (UTC)
Message-ID: <5082C526.3050100@status.net>
Date: Sat, 20 Oct 2012 11:37:10 -0400
From: Evan Prodromou 
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: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com>
In-Reply-To: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com>
Content-Type: multipart/alternative; boundary="------------000002070400050504070905"
Subject: Re: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-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: Sat, 20 Oct 2012 15:37:19 -0000

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

Paul,

Thanks for the update! I really like what I see; take the following 
notes as suggestions and not absolute rules.

  * It's long. With RFC 6415 as a basis, the requirements of this
    specification are actually quite small (add CORS, resource, and rel;
    JRD required, XRD optional). It would be nice if the document length
    and complexity reflected that.
  * The introduction in section 1 would be better if it ignored "finger"
    entirely. Just say what Webfinger does: lets a host define links and
    properties for an URI.
  * The first three paragraphs of section 3 are unnecessary and
    confusing. This is what references are for. Starting at "Thus the
    framework..." (without the "thus") is a lot clearer.
  * Section 4 is unnecessary and confusing. Also, as applications are
    built using Webfinger, it will probably become obsolete and
    incorrect. I think it should be struck entirely out.
  * Section 5.1 makes the order of queries (HTTPS, HTTP) a MUST on
    behalf of clients. The client should determine the level of
    authenticity they need from the server. I suggest a SHOULD here,
    with similar language as RFC 6415 for
  * Section 5.2 says that servers MUST support "resource" "as a means of
    improving performance and reducing client complexity". I think the
    performance improvement is debatable, and maybe even the reduction
    in client complexity. So, maybe just strike this language? By which
    I mean: leave the requirement, but don't try to justify it.
  * Section 5.2 suggests that the server should literally make an HTTP
    request to fetch the LRDD link. That is the hard way to do it. Can
    we just assume that the server can figure out its own implementation
    details?
  * Section 5.2 recommends using host-meta.json, which I think is excellent.
  * Section 5.3 uses space-separated "rel" parameters. There is some
    precedent for using space separation for a single rel in HTML
    ("alternate feed"), which makes this a little tricky. How about
    comma (",") instead?
  * Section 5.4 should probably also call out the "tag" URI scheme.
  * Section 5.4 should make special mention of "http" and "https" URIs.
    There are other discovery methods that can be used with this kind of
    URI; is there a recommended order for using Webfinger versus, say,
    doing a HEAD request and looking at the Link: headers? Doing a GET
    request with Accept set to "text/html" and parsing for  and
     elements?
  * I'm not convinced we need "acct" rels (section 6). At the very
    least, the name is confusing w/r/t the acct: URI scheme.
  * Section 7 makes support for CORS a MUST and then turns around and
    said if you have a good reason not to support it, you SHOULD NOT. I
    suggest that support for CORS should just be a SHOULD. I can figure
    out myself whether I want to be the exception.
  * Section 8 should recommend a base representation for host and
    resource descriptors be available with no authentication, and
    enhanced representations available with authentication. Host meta is
    the initial introduction for clients and servers that don't
    otherwise know each other; there should always be some information
    available - even if it's just the information on how to authenticate
    to get more information.
  * Section 9 is implementation detail that should probably be out of
    scope. I realize that these configurations are why we support 3xx
    redirects, but maybe figuring out the topology of those redirects is
    best left as an exercise for implementers.
  * Section A seems unnecessary, since it's already covered in RFC 6415.
    Am I missing something?

Overall I think the protocol itself is great, with some minor tweaks 
between MUSTs and SHOULDs. Shortening the document will make it clearer 
and easier to implement.

-Evan

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


  
    
  
  
    
Paul,

      

      Thanks for the update! I really like what I see; take the
      following notes as suggestions and not absolute rules.

      
    
        
  • It's long. With RFC 6415 as a basis, the requirements of
          this specification are actually quite small (add CORS,
          resource, and rel; JRD required, XRD optional). It would be
          nice if the document length and complexity reflected that.
    • 
        
  • The introduction in section 1 would be better if it ignored
          "finger" entirely. Just say what Webfinger does: lets a host
          define links and properties for an URI.
    
        
    • 
        
  • The first three paragraphs of section 3 are unnecessary and
          confusing. This is what references are for. Starting at "Thus
          the framework..." (without the "thus") is a lot clearer.
    
        
    • 
        
  • Section 4 is unnecessary and confusing. Also, as
          applications are built using Webfinger, it will probably
          become obsolete and incorrect. I think it should be struck
          entirely out.
    • 
        
  • Section 5.1 makes the order of queries (HTTPS, HTTP) a MUST
          on behalf of clients. The client should determine the level of
          authenticity they need from the server. I suggest a SHOULD
          here, with similar language as RFC 6415 for 
    
        
    • 
        
  • Section 5.2 says that servers MUST support "resource" "as a
          means of improving performance and reducing client
          complexity". I think the performance improvement is debatable,
          and maybe even the reduction in client complexity. So, maybe
          just strike this language? By which I mean: leave the
          requirement, but don't try to justify it.
    
        
    • 
        
  • Section 5.2 suggests that the server should literally make
          an HTTP request to fetch the LRDD link. That is the hard way
          to do it. Can we just assume that the server can figure out
          its own implementation details?
    • 
        
  • Section 5.2 recommends using host-meta.json, which I think
          is excellent.
    • 
        
  • Section 5.3 uses space-separated "rel" parameters. There is
          some precedent for using space separation for a single rel in
          HTML ("alternate feed"), which makes this a little tricky. How
          about comma (",") instead?
    
        
    • 
        
  • Section 5.4 should probably also call out the "tag" URI
          scheme.
    • 
        
  • Section 5.4 should make special mention of "http" and
          "https" URIs. There are other discovery methods that can be
          used with this kind of URI; is there a recommended order for
          using Webfinger versus, say, doing a HEAD request and looking
          at the Link: headers? Doing a GET request with Accept set to
          "text/html" and parsing for <meta> and <link>
          elements?
    • 
        
  • I'm not convinced we need "acct" rels (section 6). At the
          very least, the name is confusing w/r/t the acct: URI scheme.
    
        
    • 
        
  • Section 7 makes support for CORS a MUST and then turns
          around and said if you have a good reason not to support it,
          you SHOULD NOT. I suggest that support for CORS should just be
          a SHOULD. I can figure out myself whether I want to be the
          exception.
    
        
    • 
        
  • Section 8 should recommend a base representation for host
          and resource descriptors be available with no authentication,
          and enhanced representations available with authentication.
          Host meta is the initial introduction for clients and servers
          that don't otherwise know each other; there should always be
          some information available - even if it's just the information
          on how to authenticate to get more information.
    
        
    • 
        
  • Section 9 is implementation detail that should probably be
          out of scope. I realize that these configurations are why we
          support 3xx redirects, but maybe figuring out the topology of
          those redirects is best left as an exercise for implementers.
    • 
        
  • Section A seems unnecessary, since it's already covered in
          RFC 6415. Am I missing something?
    
        
    • 
      

      Overall I think the protocol itself is great, with some minor
      tweaks between MUSTs and SHOULDs. Shortening the document will
      make it clearer and easier to implement.

      

      -Evan

    

  


--------------000002070400050504070905--

From jan.algermissen@nordsc.com  Sat Oct 20 15:33:06 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F2621F86EB for ; Sat, 20 Oct 2012 15:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.964
X-Spam-Level: 
X-Spam-Status: No, score=-2.964 tagged_above=-999 required=5 tests=[AWL=-0.715, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vujSC25An7eV for ; Sat, 20 Oct 2012 15:33:06 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id C5AA521F869A for ; Sat, 20 Oct 2012 15:33:05 -0700 (PDT)
Received: from [192.168.2.103] (p548FB15A.dip.t-dialin.net [84.143.177.90]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MaG3Y-1TjZw82kEy-00KSW9; Sun, 21 Oct 2012 00:33:04 +0200
From: Jan Algermissen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sun, 21 Oct 2012 00:33:02 +0200
Message-Id: <23E04C5A-2806-4D28-B90C-A547FB0B042E@nordsc.com>
To: IETF Apps Discuss 
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:sDQyY6RG8ysD0Nl5lQZ5Czvz/GAJgwS6IZH/YuRsJP3 pYoACOs0ajdXdn3F2EiAUigtvK40zHAbtBTB4SB7gUuoIHxhSD w4F2gZjQ8SyFAJmPLwyV6ddKHyRFJdU+pVRQgC1Othh5yuUpaS mnRWLDo3H9YnfPKCyOHepiXUd6E/WeOfwXwIQT0zqu8oNhSyOv i7srWr9Uilsaxhx16brmPDho04q1+9ueBzRWT3x8nkp8emeb8H pSXNNiZB6oM/hJw9GiEZGGywJLoucT3tDSGEAvTfsOL4PmfipC o3S5IUsVVMvEo/rDpMhPZoOS60TNCN3xIz+Td2xh5cALWKCqgt Ajtl+LOtMG9haNoImnSomv4FSg87RBxzzdW7F2URUwAyODo65K Vl/IvVHr6eLfA==
Subject: [apps-discuss] Link rel uniqueness
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Oct 2012 22:33:06 -0000

Hi,

I am seeking a clarification ragarding link rel uniqueness in =
http://tools.ietf.org/html/rfc5988

AFAIU the required uniqueness of rel is 'per header' and thus, the =
following HTTP response headers in a single response would be valid =
according to RFC 5988:

=20
Link: ; rel=3D"describedBy"
Link: ; rel=3D"describedBy"

Correct?

Jan=

From paulej@packetizer.com  Sat Oct 20 15:34:28 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BAD21F841C for ; Sat, 20 Oct 2012 15:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.397
X-Spam-Level: 
X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.201,  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 p42LcKj-mibl for ; Sat, 20 Oct 2012 15:34:22 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9470521F8417 for ; Sat, 20 Oct 2012 15:34:22 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9KMYKrk006890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 20 Oct 2012 18:34:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1350772460; bh=lRLCITWS8y/SAa0WTa49mYnbj4xlkxCks+bWECQjcuc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=WAErWbS6Zx7H6vH0CczUODOdhLbZW/LnrdZScFMD5AE78p+NizIkyLoMsLIinCiHx BzzvGGLI9ohD2+qu7ipSvdD8mvtK51Zy2F+/rVJ0zyTtzIMRm38ETqdZo2KoRQ2JzG WQc9/aBFo+6K4TGZlexl2KOVlAOEhxJpLX1t2584=
From: "Paul E. Jones" 
To: "'Evan Prodromou'" , 
References: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com> <5082C526.3050100@status.net>
In-Reply-To: <5082C526.3050100@status.net>
Date: Sat, 20 Oct 2012 18:34:33 -0400
Message-ID: <00c501cdaf13$13ef6d30$3bce4790$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C6_01CDAEF1.8CDF7AE0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGcFKYbM2jJ0wiJf9oQM3Qhr6BdxwGjlKSjmBjKVrA=
Content-Language: en-us
Cc: webfinger@googlegroups.com
Subject: Re: [apps-discuss] WebFinger Draft Updated -	draft-ietf-appsawg-webfinger-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: Sat, 20 Oct 2012 22:34:28 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00C6_01CDAEF1.8CDF7AE0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Evan,

 

Please see my comments inline in green:

 

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
On Behalf Of Evan Prodromou
Sent: Saturday, October 20, 2012 11:37 AM
To: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger Draft Updated -
draft-ietf-appsawg-webfinger-01

 

Paul,

Thanks for the update! I really like what I see; take the following notes as
suggestions and not absolute rules.

*	It's long. With RFC 6415 as a basis, the requirements of this
specification are actually quite small (add CORS, resource, and rel; JRD
required, XRD optional). It would be nice if the document length and
complexity reflected that.

PEJ: You're correct that it is a bit lengthy and you're right that the
length does not represent the complexity.  It is a simply protocol.  Much of
the length comes from examples and a desire to make each step unambiguous.
If there is material we should remove, we can do that, but I don't want to
reduce the length only for the sake of length and risk introducing
ambiguity.

*	The introduction in section 1 would be better if it ignored "finger"
entirely. Just say what Webfinger does: lets a host define links and
properties for an URI.

PEJ: We could do that, but it only occupies a bit of space and helps explain
the history of the name.

*	The first three paragraphs of section 3 are unnecessary and
confusing. This is what references are for. Starting at "Thus the
framework..." (without the "thus") is a lot clearer.

PEJ: I agree that "thus" should go.  I've removed it from my copy.  But, I
do think the previous paragraphs are useful.

*	Section 4 is unnecessary and confusing. Also, as applications are
built using Webfinger, it will probably become obsolete and incorrect. I
think it should be struck entirely out.

PEJ: Section 4 is only examples.  There is nothing to make obsolete.  I
think it's always good to provide examples, as this helps people understand
better than just the normative wording.  I would really prefer to keep all
examples.

*	Section 5.1 makes the order of queries (HTTPS, HTTP) a MUST on
behalf of clients. The client should determine the level of authenticity
they need from the server. I suggest a SHOULD here, with similar language as
RFC 6415 for 

PEJ: A server is not required to run using HTTPS, but I do think we should
require consistent behavior.  So, I picked "try HTTPS first and fall back to
HTTP".  We could change the wording to say that clients SHOULD try "HTTPS"
first, but I would prefer consistency in implementations.  What would be a
reason for not doing that?  What do others think on this one?

*	Section 5.2 says that servers MUST support "resource" "as a means of
improving performance and reducing client complexity". I think the
performance improvement is debatable, and maybe even the reduction in client
complexity. So, maybe just strike this language? By which I mean: leave the
requirement, but don't try to justify it.

PEJ: While I do agree that both objectives are reached, I will remove "as a
means of improving performance and reducing client complexity" as you
suggest because we do not need to give justification.  It's just required.
:-)

*	Section 5.2 suggests that the server should literally make an HTTP
request to fetch the LRDD link. That is the hard way to do it. Can we just
assume that the server can figure out its own implementation details?

PEJ: On my server, I don't make an HTTP query.  I just pull the data from
the database and return it.  I fully agree that how the server returns the
information is an implementation matter.  That said, we do not want a server
returning an LRDD link relation that forces the client to resolve it.  How
about this modified paragraph:

"It is not the responsibility of the WebFinger server to verify, for
example, that a URI pointing to a person's avatar is a valid URI.  If the
WebFinger server needs to query an LRDD resource to collect additional
resource-specific information, any errors (e.g., 500 or 404) MUST be ignored
by the server.  When a request for an LRDD fails, the server MUST NOT
attempt to augment missing resource information or return a "template" type
link relation to a client that utilizes the "resource" parameter.  Note that
a WebFinger server might be implemented such that all LRDD resource-specific
information can be resolved without issuing HTTP requests.  How a WebFinger
collects and expands such resource-specific link relations is an
implementation matter."

*	Section 5.2 recommends using host-meta.json, which I think is
excellent.
*	Section 5.3 uses space-separated "rel" parameters. There is some
precedent for using space separation for a single rel in HTML ("alternate
feed"), which makes this a little tricky. How about comma (",") instead?

PEJ: It was the fact that HTML uses a space-separated list that I specified
it this way.  I like consistency.  Is there a technical reason for not
trying to have a consistent syntax with HTML's  syntax?

*	Section 5.4 should probably also call out the "tag" URI scheme.

PEJ: My only concern is that it is an informational RFC, is it not?  I'd
prefer to avoid having normative text referring to informational material.

*	Section 5.4 should make special mention of "http" and "https" URIs.
There are other discovery methods that can be used with this kind of URI; is
there a recommended order for using Webfinger versus, say, doing a HEAD
request and looking at the Link: headers? Doing a GET request with Accept
set to "text/html" and parsing for  and  elements?

PEJ: Trying to discuss how WebFinger might be used in relation to any other
discovery protocol will start getting messy and we will never get consensus
:-)

*	I'm not convinced we need "acct" rels (section 6). At the very
least, the name is confusing w/r/t the acct: URI scheme.

PEJ: The name should not be confusing, since the "acct" link relation is
intended to be used only with the "acct" URI. However, since we moved out
the "acct" URI, we could also move out the "acct" link relation text to a
different Internet Draft.  Do others have a preference? Any volunteers to
take that action?

*	Section 7 makes support for CORS a MUST and then turns around and
said if you have a good reason not to support it, you SHOULD NOT. I suggest
that support for CORS should just be a SHOULD. I can figure out myself
whether I want to be the exception.

PEJ: You're entirely right about that and that text bugged me, too.  There
was a strong desire for CORS to the point I was asked to make it a MUST, yet
there was the desire to allow an enterprise do something more restrictive.
I have no strong preference, myself, but I do think that if we make it a
SHOULD, though, that it will make it impossible to build a client in a
browser.  What does the group want here?

*	Section 8 should recommend a base representation for host and
resource descriptors be available with no authentication, and enhanced
representations available with authentication. Host meta is the initial
introduction for clients and servers that don't otherwise know each other;
there should always be some information available - even if it's just the
information on how to authenticate to get more information.

PEJ: This one is hard.  We might debate a year on what a baseline document
should contain :-)  Is a server name?  Is it a copyright date?  I think an
empty document should be OK. :-)  We'll know if WF is working simply based
on a valid response. I'd prefer to not make requirements on baseline
documents. 

*	Section 9 is implementation detail that should probably be out of
scope. I realize that these configurations are why we support 3xx redirects,
but maybe figuring out the topology of those redirects is best left as an
exercise for implementers.

PEJ: This is all new text because there were folks who said we need to have
a means of allowing the WF services to be hosted.  We talked about using 3xx
and we talked about introducing a URI DNS record.  The latter is a cool
idea, but the spec is not finalized.  It also introduces one more code path
in the client.  The 3xx must already be handled.  We could make this section
non-normative if folks prefer, but I think having this content will help
people understand how they can re-locate and outsource WF services.

*	Section A seems unnecessary, since it's already covered in RFC 6415.
Am I missing something?

PEJ: That's part of why it is in an appendix.  I wanted to have this here
since it provides an XRD example of the exact same example in Section 4.1.
I thought this might be useful for people.  Even if they do not implement
XRD in a client or server, it helps to illustrate in this document what an
RFC 6415-compliant server would do.  I could remove it, but I think it's
educational and it's already marked as non-normative.

Overall I think the protocol itself is great, with some minor tweaks between
MUSTs and SHOULDs. Shortening the document will make it clearer and easier
to implement.

 

PEJ: I do hope we're getting closer.  I'm challenged to see how we can make
it much shorter and also keep it in a form that makes it perfectly clear to
implemeners.  (Of course, somebody will still misinterpret something, but I
do aim to avoid misinterpretation.)  Consider my comments above.  I've made
a few changes and I could try to get a -02 published before the deadline
Monday.

 

PEJ: Thanks for the thorough review!

 

Paul



-Evan


------=_NextPart_000_00C6_01CDAEF1.8CDF7AE0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Evan,
 
Please see my comments inline in green:
 
 
From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of Evan =
Prodromou
Sent: Saturday, October 20, 2012 11:37 =
AM
To: apps-discuss@ietf.org
Subject: Re: =
[apps-discuss] WebFinger Draft Updated - =
draft-ietf-appsawg-webfinger-01
 
Paul,

Thanks for the update! I really like what =
I see; take the following notes as suggestions and not absolute =
rules.
  • It's long. With RFC 6415 as a basis, the requirements of =
this specification are actually quite small (add CORS, resource, and =
rel; JRD required, XRD optional). It would be nice if the document =
length and complexity reflected that.
PEJ: You’re correct that it is a bit lengthy and you’re =
right that the length does not represent the complexity.  It is a =
simply protocol.  Much of the length comes from examples and a =
desire to make each step unambiguous.  If there is material we =
should remove, we can do that, but I don’t want to reduce the =
length only for the sake of length and risk introducing =
ambiguity.
  • The introduction in section 1 would be better if it ignored =
"finger" entirely. Just say what Webfinger does: lets a host =
define links and properties for an URI.
PEJ: We could do that, but it only occupies a bit of space and helps =
explain the history of the name.
  • The first three paragraphs of section 3 are unnecessary and =
confusing. This is what references are for. Starting at "Thus the =
framework..." (without the "thus") is a lot =
clearer.
PEJ: I agree that “thus” should go.  I’ve =
removed it from my copy.  But, I do think the previous paragraphs =
are useful.
  • Section 4 is unnecessary and confusing. Also, as =
applications are built using Webfinger, it will probably become obsolete =
and incorrect. I think it should be struck entirely =
out.
PEJ: Section 4 is only examples.  There is nothing to make =
obsolete.  I think it’s always good to provide examples, as =
this helps people understand better than just the normative =
wording.  I would really prefer to keep all =
examples.
  • Section 5.1 makes the order of queries (HTTPS, HTTP) a MUST =
on behalf of clients. The client should determine the level of =
authenticity they need from the server. I suggest a SHOULD here, with =
similar language as RFC 6415 for 
PEJ: A server is not required to run using HTTPS, but I do think we =
should require consistent behavior.  So, I picked “try HTTPS =
first and fall back to HTTP”.  We could change the wording to =
say that clients SHOULD try “HTTPS” first, but I would =
prefer consistency in implementations.  What would be a reason for =
not doing that?  What do others think on this =
one?
  • Section 5.2 says that servers MUST support =
"resource" "as a means of improving performance and =
reducing client complexity". I think the performance improvement is =
debatable, and maybe even the reduction in client complexity. So, maybe =
just strike this language? By which I mean: leave the requirement, but =
don't try to justify it.
PEJ: While I do agree that both objectives are reached, I will remove =
“as a means of improving performance and reducing client =
complexity” as you suggest because we do not need to give =
justification.  It’s just required. =
:-)
  • Section 5.2 suggests that the server should literally make =
an HTTP request to fetch the LRDD link. That is the hard way to do it. =
Can we just assume that the server can figure out its own implementation =
details?
PEJ: On my server, I don’t make an HTTP query.  I just =
pull the data from the database and return it.  I fully agree that =
how the server returns the information is an implementation =
matter.  That said, we do not want a server returning an LRDD link =
relation that forces the client to resolve it.  How about this =
modified paragraph:
“It is not the responsibility of the WebFinger server to =
verify, for example, that a URI pointing to a person’s avatar is a =
valid URI.  If the WebFinger server needs to query an LRDD resource =
to collect additional resource-specific information, any errors (e.g., =
500 or 404) MUST be ignored by the server.  When a request for an =
LRDD fails, the server MUST NOT attempt to augment missing resource =
information or return a “template” type link relation to a =
client that utilizes the “resource” parameter.  Note =
that a WebFinger server might be implemented such that all LRDD =
resource-specific information can be resolved without issuing HTTP =
requests.  How a WebFinger collects and expands such =
resource-specific link relations is an implementation =
matter.”
  • Section 5.2 recommends using host-meta.json, which I think =
is excellent.
  • Section 5.3 uses space-separated "rel" =
parameters. There is some precedent for using space separation for a =
single rel in HTML ("alternate feed"), which makes this a =
little tricky. How about comma (",") =
instead?
PEJ: It was the fact that HTML uses a space-separated list that I =
specified it this way.  I like consistency.  Is there a =
technical reason for not trying to have a consistent syntax with =
HTML’s <Link> syntax?
  • Section 5.4 should probably also call out the =
"tag" URI scheme.
PEJ: My only concern is that it is an informational RFC, is it =
not?  I’d prefer to avoid having normative text referring to =
informational material.
  • Section 5.4 should make special mention of "http" =
and "https" URIs. There are other discovery methods that can =
be used with this kind of URI; is there a recommended order for using =
Webfinger versus, say, doing a HEAD request and looking at the Link: =
headers? Doing a GET request with Accept set to "text/html" =
and parsing for <meta> and <link> =
elements?
PEJ: Trying to discuss how WebFinger might be used in relation to any =
other discovery protocol will start getting messy and we will never get =
consensus :-)
  • I'm not convinced we need "acct" rels (section =
6). At the very least, the name is confusing w/r/t the acct: URI =
scheme.
PEJ: The name should not be confusing, since the “acct” =
link relation is intended to be used only with the “acct” =
URI. However, since we moved out the “acct” URI, we could =
also move out the “acct” link relation text to a different =
Internet Draft.  Do others have a preference? Any volunteers to =
take that action?
  • Section 7 makes support for CORS a MUST and then turns =
around and said if you have a good reason not to support it, you SHOULD =
NOT. I suggest that support for CORS should just be a SHOULD. I can =
figure out myself whether I want to be the =
exception.
PEJ: You’re entirely right about that and that text bugged me, =
too.  There was a strong desire for CORS to the point I was asked =
to make it a MUST, yet there was the desire to allow an enterprise do =
something more restrictive.  I have no strong preference, myself, =
but I do think that if we make it a SHOULD, though, that it will make it =
impossible to build a client in a browser.  What does the group =
want here?
  • Section 8 should recommend a base representation for host =
and resource descriptors be available with no authentication, and =
enhanced representations available with authentication. Host meta is the =
initial introduction for clients and servers that don't otherwise know =
each other; there should always be some information available - even if =
it's just the information on how to authenticate to get more =
information.
PEJ: This one is hard.  We might debate a year on what a =
baseline document should contain :-)  Is a server name?  Is it =
a copyright date?  I think an empty document should be OK. =
:-)  We’ll know if WF is working simply based on a valid =
response. I’d prefer to not make requirements on baseline =
documents. 
  • Section 9 is implementation detail that should probably be =
out of scope. I realize that these configurations are why we support 3xx =
redirects, but maybe figuring out the topology of those redirects is =
best left as an exercise for implementers.
PEJ: This is all new text because there were folks who said we need =
to have a means of allowing the WF services to be hosted.  We =
talked about using 3xx and we talked about introducing a URI DNS =
record.  The latter is a cool idea, but the spec is not =
finalized.  It also introduces one more code path in the =
client.  The 3xx must already be handled.  We could make this =
section non-normative if folks prefer, but I think having this content =
will help people understand how they can re-locate and outsource WF =
services.
  • Section A seems unnecessary, since it's already covered in =
RFC 6415. Am I missing something?
PEJ: That’s part of why it is in an appendix.  I wanted to =
have this here since it provides an XRD example of the exact same =
example in Section 4.1.  I thought this might be useful for =
people.  Even if they do not implement XRD in a client or server, =
it helps to illustrate in this document what an RFC 6415-compliant =
server would do.  I could remove it, but I think it’s =
educational and it’s already marked as =
non-normative.
Overall I think =
the protocol itself is great, with some minor tweaks between MUSTs and =
SHOULDs. Shortening the document will make it clearer and easier to =
implement.
 
PEJ: I do hope we’re getting closer.  I’m challenged =
to see how we can make it much shorter and also keep it in a form that =
makes it perfectly clear to implemeners.  (Of course, somebody will =
still misinterpret something, but I do aim to avoid =
misinterpretation.)  Consider my comments above.  I’ve =
made a few changes and I could try to get a -02 published before the =
deadline Monday.
 
PEJ: Thanks for the thorough review!
 
Paul


-Evan

------=_NextPart_000_00C6_01CDAEF1.8CDF7AE0--


From paulej@packetizer.com  Sat Oct 20 15:38:34 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9989921F8789 for ; Sat, 20 Oct 2012 15:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.408
X-Spam-Level: 
X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191,  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 9Ute1tCdEHJn for ; Sat, 20 Oct 2012 15:38:34 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id CA94121F86EB for ; Sat, 20 Oct 2012 15:38:25 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9KMcOb4007072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 20 Oct 2012 18:38:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1350772705; bh=3rslFArnJVycZ7nsnH3EFM7amNtR575NJ+UsVXXclw8=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=NuivWkhdIOqYoPJjLZNTiim6h7z97lwV1Ux3C5wc+SbJ4EHaB7YDuUIqN9ObZWiWe RESeXdosfgJLxkShaYNKqZi/csTTFj+BQOaSp0iVRTHUIrRwD/SUYKU8K7r/pQbizO oxBrCUBkKV+ydt5sB/eZ4uVcB8UUR+Js3CzILs3Y=
From: "Paul E. Jones" 
To: "'Jan Algermissen'" , "'IETF Apps Discuss'" 
References: <23E04C5A-2806-4D28-B90C-A547FB0B042E@nordsc.com>
In-Reply-To: <23E04C5A-2806-4D28-B90C-A547FB0B042E@nordsc.com>
Date: Sat, 20 Oct 2012 18:38:37 -0400
Message-ID: <00d201cdaf13$a5d19e30$f174da90$@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: AQG/fw9XQb4wwVfuLii3ju5+8fep0JffKDyQ
Content-Language: en-us
Subject: Re: [apps-discuss] Link rel uniqueness
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Oct 2012 22:38:34 -0000

Jan,

It's quite common in HTML documents to have multiple  headers with the
same "rel" value pointing to different information, such as including
multiple CSS documents.

That said, what would a browser do if it sees multiple  relations for
a shortcut icon?

Perhaps the answer to your question is "it depends" :-)

Paul

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of Jan Algermissen
> Sent: Saturday, October 20, 2012 6:33 PM
> To: IETF Apps Discuss
> Subject: [apps-discuss] Link rel uniqueness
> 
> Hi,
> 
> I am seeking a clarification ragarding link rel uniqueness in
> http://tools.ietf.org/html/rfc5988
> 
> AFAIU the required uniqueness of rel is 'per header' and thus, the
> following HTTP response headers in a single response would be valid
> according to RFC 5988:
> 
> 
> Link: ; rel="describedBy"
> Link: ; rel="describedBy"
> 
> Correct?
> 
> Jan
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From melvincarvalho@gmail.com  Sat Oct 20 16:05:55 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBAB21F879E for ; Sat, 20 Oct 2012 16:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.182
X-Spam-Level: 
X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416,  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 NQTgL8PZG8dh for ; Sat, 20 Oct 2012 16:05:54 -0700 (PDT)
Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 278EE21F8674 for ; Sat, 20 Oct 2012 16:05:54 -0700 (PDT)
Received: by mail-ia0-f172.google.com with SMTP id o25so1418694iad.31 for ; Sat, 20 Oct 2012 16:05:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VIe4xX4uEJo1nhYTtWexZlj24pnqKK5PnVyHyyYEhb0=; b=xCoxlblhwCoUiiznYZWHd/7Z8NP12fT9XKZ2TcCz1nCFB6aPl9Ihj8sc72HptpiFSu /4AgMotm2jDcjeoQDsZTqmrWwPsA9lLr+4RTKg45G+ahEOC7xqbdB5WfvBkRZA7ya2K9 W2q86DUyCl2fwnaMh/QsDPNVkXfX2tm2O9SDvOfUVCtt6CoFvLzbmK3mk9aXRD4G5qkk U8Qz3r93rvDLqPOU0NFq8EYcPD2wnspJpVuPWVmh0YaN8F+sNFYCDCvhA3tCbRb+8Uk5 A2cveQVNk3ETRItL7hElWT3iuhSnSKWXolW8RMqqrHpN5uQcrx/IcByfKhXGy3naA97f ZMtA==
MIME-Version: 1.0
Received: by 10.50.95.161 with SMTP id dl1mr5040181igb.0.1350774353715; Sat, 20 Oct 2012 16:05:53 -0700 (PDT)
Received: by 10.42.247.129 with HTTP; Sat, 20 Oct 2012 16:05:53 -0700 (PDT)
In-Reply-To: <5082C526.3050100@status.net>
References: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com> <5082C526.3050100@status.net>
Date: Sun, 21 Oct 2012 01:05:53 +0200
Message-ID: 
From: Melvin Carvalho 
To: Evan Prodromou 
Content-Type: multipart/alternative; boundary=e89a8f3b9c3f86621204cc85a9cd
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-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: Sat, 20 Oct 2012 23:05:55 -0000

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

On 20 October 2012 17:37, Evan Prodromou  wrote:

>  Paul,
>
> Thanks for the update! I really like what I see; take the following notes
> as suggestions and not absolute rules.
>
>    - It's long. With RFC 6415 as a basis, the requirements of this
>    specification are actually quite small (add CORS, resource, and rel; JRD
>    required, XRD optional). It would be nice if the document length and
>    complexity reflected that.
>    - The introduction in section 1 would be better if it ignored "finger"
>    entirely. Just say what Webfinger does: lets a host define links and
>    properties for an URI.
>     - The first three paragraphs of section 3 are unnecessary and
>    confusing. This is what references are for. Starting at "Thus the
>    framework..." (without the "thus") is a lot clearer.
>     - Section 4 is unnecessary and confusing. Also, as applications are
>    built using Webfinger, it will probably become obsolete and incorrect. I
>    think it should be struck entirely out.
>    - Section 5.1 makes the order of queries (HTTPS, HTTP) a MUST on
>    behalf of clients. The client should determine the level of authenticity
>    they need from the server. I suggest a SHOULD here, with similar language
>    as RFC 6415 for
>     - Section 5.2 says that servers MUST support "resource" "as a means
>    of improving performance and reducing client complexity". I think the
>    performance improvement is debatable, and maybe even the reduction in
>    client complexity. So, maybe just strike this language? By which I mean:
>    leave the requirement, but don't try to justify it.
>     - Section 5.2 suggests that the server should literally make an HTTP
>    request to fetch the LRDD link. That is the hard way to do it. Can we just
>    assume that the server can figure out its own implementation details?
>    - Section 5.2 recommends using host-meta.json, which I think is
>    excellent.
>    - Section 5.3 uses space-separated "rel" parameters. There is some
>    precedent for using space separation for a single rel in HTML ("alternate
>    feed"), which makes this a little tricky. How about comma (",") instead?
>     - Section 5.4 should probably also call out the "tag" URI scheme.
>    - Section 5.4 should make special mention of "http" and "https" URIs.
>    There are other discovery methods that can be used with this kind of URI;
>    is there a recommended order for using Webfinger versus, say, doing a HEAD
>    request and looking at the Link: headers? Doing a GET request with Accept
>    set to "text/html" and parsing for  and  elements?
>
>
HTTP GET is generally recommended to get more information from an HTTP
URI.  HEAD may not contain the information you need.  Of course, it may
become popular to deference an HTTP URI using webfinger.  Though there may
be issues with the correct response codes, consistency of information etc.


>
>    - I'm not convinced we need "acct" rels (section 6). At the very
>    least, the name is confusing w/r/t the acct: URI scheme.
>     - Section 7 makes support for CORS a MUST and then turns around and
>    said if you have a good reason not to support it, you SHOULD NOT. I suggest
>    that support for CORS should just be a SHOULD. I can figure out myself
>    whether I want to be the exception.
>     - Section 8 should recommend a base representation for host and
>    resource descriptors be available with no authentication, and enhanced
>    representations available with authentication. Host meta is the initial
>    introduction for clients and servers that don't otherwise know each other;
>    there should always be some information available - even if it's just the
>    information on how to authenticate to get more information.
>     - Section 9 is implementation detail that should probably be out of
>    scope. I realize that these configurations are why we support 3xx
>    redirects, but maybe figuring out the topology of those redirects is best
>    left as an exercise for implementers.
>    - Section A seems unnecessary, since it's already covered in RFC 6415.
>    Am I missing something?
>
> Overall I think the protocol itself is great, with some minor tweaks
> between MUSTs and SHOULDs. Shortening the document will make it clearer and
> easier to implement.
>
> -Evan
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

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



On 20 October 2012 17:37, Evan Prodromou=
 <evan@status.net> wrote:


 =20
   =20
 =20
  

    
Paul,

      

      Thanks for the update! I really like what I see; take the
      following notes as suggestions and not absolute rules.

      
    
        
  • It's long. With RFC 6415 as a basis, the requirements of
          this specification are actually quite small (add CORS,
          resource, and rel; JRD required, XRD optional). It would be
          nice if the document length and complexity reflected that.
    • 
        
  • The introduction in section 1 would be better if it ignored
          "finger" entirely. Just say what Webfinger does: lets a=
 host
          define links and properties for an URI.
    
        
    • 
        
  • The first three paragraphs of section 3 are unnecessary and
          confusing. This is what references are for. Starting at "Thu=
s
          the framework..." (without the "thus") is a lot cl=
earer.
    
        
    • 
        
  • Section 4 is unnecessary and confusing. Also, as
          applications are built using Webfinger, it will probably
          become obsolete and incorrect. I think it should be struck
          entirely out.
    • 
        
  • Section 5.1 makes the order of queries (HTTPS, HTTP) a MUST
          on behalf of clients. The client should determine the level of
          authenticity they need from the server. I suggest a SHOULD
          here, with similar language as RFC 6415 for 
    
        
    • 
        
  • Section 5.2 says that servers MUST support "resource"=
 "as a
          means of improving performance and reducing client
          complexity". I think the performance improvement is debatabl=
e,
          and maybe even the reduction in client complexity. So, maybe
          just strike this language? By which I mean: leave the
          requirement, but don't try to justify it.
    
        
    • 
        
  • Section 5.2 suggests that the server should literally make
          an HTTP request to fetch the LRDD link. That is the hard way
          to do it. Can we just assume that the server can figure out
          its own implementation details?
    • 
        
  • Section 5.2 recommends using host-meta.json, which I think
          is excellent.
    • 
        
  • Section 5.3 uses space-separated "rel" parameters. Th=
ere is
          some precedent for using space separation for a single rel in
          HTML ("alternate feed"), which makes this a little tric=
ky. How
          about comma (",") instead?
    
        
    • 
        
  • Section 5.4 should probably also call out the "tag" U=
RI
          scheme.
    • 
        
  • Section 5.4 should make special mention of "http" and
          "https" URIs. There are other discovery methods that ca=
n be
          used with this kind of URI; is there a recommended order for
          using Webfinger versus, say, doing a HEAD request and looking
          at the Link: headers? Doing a GET request with Accept set to
          "text/html" and parsing for <meta> and <link&g=
t;
          elements?

HTTP GET is =
generally recommended to get more information from an HTTP URI.=A0 HEAD may=
 not contain the information you need.=A0 Of course, it may become popular =
to deference an HTTP URI using webfinger.=A0 Though there may be issues wit=
h the correct response codes, consistency of information etc.

=A0
    
        
  • I'm not convinced we need "acct" rels (section 6)=
. At the
          very least, the name is confusing w/r/t the acct: URI scheme.
    
        
    • 
        
  • Section 7 makes support for CORS a MUST and then turns
          around and said if you have a good reason not to support it,
          you SHOULD NOT. I suggest that support for CORS should just be
          a SHOULD. I can figure out myself whether I want to be the
          exception.
    
        
    • 
        
  • Section 8 should recommend a base representation for host
          and resource descriptors be available with no authentication,
          and enhanced representations available with authentication.
          Host meta is the initial introduction for clients and servers
          that don't otherwise know each other; there should always be
          some information available - even if it's just the informatio=
n
          on how to authenticate to get more information.
    
        
    • 
        
  • Section 9 is implementation detail that should probably be
          out of scope. I realize that these configurations are why we
          support 3xx redirects, but maybe figuring out the topology of
          those redirects is best left as an exercise for implementers.
        
  • Section A seems unnecessary, since it's already covered in
          RFC 6415. Am I missing something?
    
        
    • 
      

      Overall I think the protocol itself is great, with some minor
      tweaks between MUSTs and SHOULDs. Shortening the document will
      make it clearer and easier to implement.

      

      -Evan

    

  



_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--e89a8f3b9c3f86621204cc85a9cd--

From mnot@mnot.net  Sat Oct 20 20:52:13 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A390E21F899B for ; Sat, 20 Oct 2012 20:52:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.164
X-Spam-Level: 
X-Spam-Status: No, score=-104.164 tagged_above=-999 required=5 tests=[AWL=-1.565, 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 ooCwjF36UZ2r for ; Sat, 20 Oct 2012 20:52:13 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0560D21F894E for ; Sat, 20 Oct 2012 20:52:12 -0700 (PDT)
Received: from mnot-mini.mnot.net (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2265F22E253; Sat, 20 Oct 2012 23:52:05 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: <23E04C5A-2806-4D28-B90C-A547FB0B042E@nordsc.com>
Date: Sun, 21 Oct 2012 14:52:00 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <23E04C5A-2806-4D28-B90C-A547FB0B042E@nordsc.com>
To: Jan Algermissen 
X-Mailer: Apple Mail (2.1499)
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] Link rel uniqueness
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Oct 2012 03:52:13 -0000

Hi Jan,

What's the specific requirement you're referring to?

Semantically, in ANY HTTP header defined using the "," list production, =
the following are equivalent:

Foo: 1
Foo: 2

and

Foo: 1, 2

Regards,


On 21/10/2012, at 9:33 AM, Jan Algermissen  =
wrote:

> Hi,
>=20
> I am seeking a clarification ragarding link rel uniqueness in =
http://tools.ietf.org/html/rfc5988
>=20
> AFAIU the required uniqueness of rel is 'per header' and thus, the =
following HTTP response headers in a single response would be valid =
according to RFC 5988:
>=20
>=20
> Link: ; rel=3D"describedBy"
> Link: ; rel=3D"describedBy"
>=20
> Correct?
>=20
> Jan
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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




From jan.algermissen@nordsc.com  Sun Oct 21 00:49:39 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A136421F847F for ; Sun, 21 Oct 2012 00:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.845
X-Spam-Level: 
X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrTil3+ejekp for ; Sun, 21 Oct 2012 00:49:39 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id C6A8021F843E for ; Sun, 21 Oct 2012 00:49:38 -0700 (PDT)
Received: from [192.168.2.103] (p548FA5C5.dip.t-dialin.net [84.143.165.197]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0M0RJt-1TBC9C19e1-00uY2E; Sun, 21 Oct 2012 09:49:35 +0200
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Jan Algermissen 
In-Reply-To: 
Date: Sun, 21 Oct 2012 09:49:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <23E04C5A-2806-4D28-B90C-A547FB0B042E@nordsc.com> 
To: Mark Nottingham 
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:70LwcULEyGE7XfkH3itM3C0hn1CL9Hl6CuZMbzCxrzG eJYzWHTN1A7eUx3aVKaMEdmd1vvPisb5aixL6JSkgRMmKe+5kg l7TqBlKxDMGXZBMLaTjF8SgzuGt+5nPQAq1+ydT6lInyyYmQnQ 0hq+PV4loLDCIqR+nCQ2Sd06KPAhGlw/s5+wMhvqXSX+spC0TP BJ+umUIuD3chCnpVV5o86Om+apOdven+b2FnRgJ4QnDrOKg8M+ doqMpv9C5OXkjdDFLutfodc0Rkd5krWdlRgonNMjsDhS3T+tqD A4cWRZH3vlGeB6UCE54GgLpkbw2MuP9XDMpF6L3FDvUELD5OHS fz46TJIIxbloj6UnaCJVEUkmmz0pwARCxILlc9dqnJMPok1LHu 0+XVNxtt/W8Yw==
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] Link rel uniqueness
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Oct 2012 07:49:39 -0000

On Oct 21, 2012, at 5:52 AM, Mark Nottingham wrote:

> Hi Jan,
>=20
> What's the specific requirement you're referring to?

Section 5.3.:

"The relation type of a link is conveyed in the "rel" parameter's
   value.  The "rel" parameter MUST NOT appear more than once in a given
   link-value; occurrences after the first MUST be ignored by parsers."

I was unsure what the link-value refers to but from what you write below =
I understand that it refers to the combination of all header values of =
the same name.

That would then mean that parsers, when seeing

>> Link: ; rel=3D"describedBy"
>> Link: ; rel=3D"describedBy"

would, per 5.3., have to produce only

>> Link: ; rel=3D"describedBy"

(ignoring the Link to /b)

Correct?


P.S. I find that a bit counter intuitive. Given that further links might =
occur elsewhere in the entity.

Jan







>=20
> Semantically, in ANY HTTP header defined using the "," list =
production, the following are equivalent:
>=20
> Foo: 1
> Foo: 2
>=20
> and
>=20
> Foo: 1, 2
>=20
> Regards,
>=20
>=20
> On 21/10/2012, at 9:33 AM, Jan Algermissen =
 wrote:
>=20
>> Hi,
>>=20
>> I am seeking a clarification ragarding link rel uniqueness in =
http://tools.ietf.org/html/rfc5988
>>=20
>> AFAIU the required uniqueness of rel is 'per header' and thus, the =
following HTTP response headers in a single response would be valid =
according to RFC 5988:
>>=20
>>=20
>> Link: ; rel=3D"describedBy"
>> Link: ; rel=3D"describedBy"
>>=20
>> Correct?
>>=20
>> Jan
>> _______________________________________________
>> 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


From mnot@mnot.net  Sun Oct 21 00:51:17 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFE021F849A for ; Sun, 21 Oct 2012 00:51:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.134
X-Spam-Level: 
X-Spam-Status: No, score=-104.134 tagged_above=-999 required=5 tests=[AWL=-1.535, 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 EZ-aGgoPPpB3 for ; Sun, 21 Oct 2012 00:51:16 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id B7F2221F848F for ; Sun, 21 Oct 2012 00:51:16 -0700 (PDT)
Received: from [192.168.1.72] (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B34F922E253; Sun, 21 Oct 2012 03:51:09 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: 
Date: Sun, 21 Oct 2012 18:51:03 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <23E04C5A-2806-4D28-B90C-A547FB0B042E@nordsc.com>  
To: Jan Algermissen 
X-Mailer: Apple Mail (2.1499)
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] Link rel uniqueness
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Oct 2012 07:51:17 -0000

No. link-value is the syntactic construct of *one* link; see the ABNF. =
There can be multiple links with the same target; this is just saying =
that there can only be one "rel" parameter on each link.

Cheers,


On 21/10/2012, at 6:49 PM, Jan Algermissen  =
wrote:

>=20
> On Oct 21, 2012, at 5:52 AM, Mark Nottingham wrote:
>=20
>> Hi Jan,
>>=20
>> What's the specific requirement you're referring to?
>=20
> Section 5.3.:
>=20
> "The relation type of a link is conveyed in the "rel" parameter's
>   value.  The "rel" parameter MUST NOT appear more than once in a =
given
>   link-value; occurrences after the first MUST be ignored by parsers."
>=20
> I was unsure what the link-value refers to but from what you write =
below I understand that it refers to the combination of all header =
values of the same name.
>=20
> That would then mean that parsers, when seeing
>=20
>>> Link: ; rel=3D"describedBy"
>>> Link: ; rel=3D"describedBy"
>=20
> would, per 5.3., have to produce only
>=20
>>> Link: ; rel=3D"describedBy"
>=20
> (ignoring the Link to /b)
>=20
> Correct?
>=20
>=20
> P.S. I find that a bit counter intuitive. Given that further links =
might occur elsewhere in the entity.
>=20
> Jan
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>>=20
>> Semantically, in ANY HTTP header defined using the "," list =
production, the following are equivalent:
>>=20
>> Foo: 1
>> Foo: 2
>>=20
>> and
>>=20
>> Foo: 1, 2
>>=20
>> Regards,
>>=20
>>=20
>> On 21/10/2012, at 9:33 AM, Jan Algermissen =
 wrote:
>>=20
>>> Hi,
>>>=20
>>> I am seeking a clarification ragarding link rel uniqueness in =
http://tools.ietf.org/html/rfc5988
>>>=20
>>> AFAIU the required uniqueness of rel is 'per header' and thus, the =
following HTTP response headers in a single response would be valid =
according to RFC 5988:
>>>=20
>>>=20
>>> Link: ; rel=3D"describedBy"
>>> Link: ; rel=3D"describedBy"
>>>=20
>>> Correct?
>>>=20
>>> Jan
>>> _______________________________________________
>>> 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/




From melvincarvalho@gmail.com  Sun Oct 21 02:13:54 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C4621F8908 for ; Sun, 21 Oct 2012 02:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.241
X-Spam-Level: 
X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=0.357,  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 rM3v9LOTYe51 for ; Sun, 21 Oct 2012 02:13:54 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E939D21F8907 for ; Sun, 21 Oct 2012 02:13:53 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 9so2885062iec.31 for ; Sun, 21 Oct 2012 02:13:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F1i8zEc2mMR+Ltl1EvyO7u3fn9BrHDca/vrrpZwdip0=; b=m3BYKiClKjXlrRElSaGFeIW6NysgzOG68L/OZwSy1HIV+fjhf1NU0d5ldJJu30bLPI fzEXrgncsNuI9lLwp1pU5e4DVvqwxLonEdFgKK7AoqfXYmKooDbnAbu8BVDS1K7NgtWm BqtVg3AARhXkWCyXqGZY3QmDh0NSJG0f37fe53VybzQVmPRUBU0xUSp+UdD6LlPm9I0c SuSDneUCfQ017StL8ePqqoLfgiNMrYzEkQ65dU9TkUTkiidcvxsam/1WCsRYuuKJ0Srl Sb78X8tv+GwfQ7Hl6NnVdK5yNidhLN1ikgb+s23cgmhWyfaxQQ8m5J47a6hQ1e4TnQWE aw8g==
MIME-Version: 1.0
Received: by 10.50.16.172 with SMTP id h12mr6199912igd.41.1350810833434; Sun, 21 Oct 2012 02:13:53 -0700 (PDT)
Received: by 10.42.247.129 with HTTP; Sun, 21 Oct 2012 02:13:53 -0700 (PDT)
In-Reply-To: <20121021093728.590d2898@bogo>
References: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com> <5082C526.3050100@status.net> <00c501cdaf13$13ef6d30$3bce4790$@packetizer.com> <20121021093728.590d2898@bogo>
Date: Sun, 21 Oct 2012 11:13:53 +0200
Message-ID: 
From: Melvin Carvalho 
To: webfinger@googlegroups.com
Content-Type: multipart/alternative; boundary=f46d04428c6ee2b79004cc8e2720
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-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, 21 Oct 2012 09:13:54 -0000

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

On 21 October 2012 09:37, Christian Weiske  wrote:

> Hello Paul,
>
>
> >> *    Section 7 makes support for CORS a MUST and then turns
> >> around and said if you have a good reason not to support it, you
> >> SHOULD NOT. I suggest that support for CORS should just be a SHOULD.
> >> I can figure out myself whether I want to be the exception.
> > PEJ: You're entirely right about that and that text bugged me, too.
> > There was a strong desire for CORS to the point I was asked to make
> > it a MUST, yet there was the desire to allow an enterprise do
> > something more restrictive. I have no strong preference, myself, but
> > I do think that if we make it a SHOULD, though, that it will make it
> > impossible to build a client in a browser.  What does the group want
> > here?
>
> Not supporting CORS does not make the data any more secure. If someone
> wants security for their intranet, they have to implement real security
> measurements, e.g. based on IP whitelists.
>
> Please leave CORS support a MUST.
>

+1

>
> --
> Regards/Mit freundlichen Gr=C3=BC=C3=9Fen
> Christian Weiske
>
> -=3D=E2=89=A1 Geeking around in the name of science since 1982 =E2=89=A1=
=3D-
>

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



On 21 October 2012 09:37, Christian Weis=
ke <cweiske@cweiske.de> wrote:

Hello Paul,





>> * =C2=A0 =C2=A0Section 7 makes support for CORS a MUST and then tu=
rns


>> around and said if you have a good reason not to=
 support it, you

>> SHOULD NOT. I suggest that support for CORS should just be a SHOUL=
D.

>> I can figure out myself whether I want to be the exception.

> PEJ: You're entirely right about that and that text bugged me, too=
.

> There was a strong desire for CORS to the point I was asked to make
> it a MUST, yet there was the desire to allow an enterprise do

> something more restrictive. I have no strong preference, myself, but
> I do think that if we make it a SHOULD, though, that it will make it
> impossible to build a client in a browser. =C2=A0What does the group w=
ant

> here?




Not supporting CORS does not make the data any more secure. If someon=
e

wants security for their intranet, they have to implement real security

measurements, e.g. based on IP whitelists.



Please leave CORS support a MUST.

+1 



--

Regards/Mit freundlichen Gr=C3=BC=C3=9Fen

Christian Weiske



-=3D=E2=89=A1 Geeking around in the name of science since 1982 =E2=89=A1=3D=
-





--f46d04428c6ee2b79004cc8e2720--

From GK@ninebynine.org  Sun Oct 21 05:50:24 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5593521F8984 for ; Sun, 21 Oct 2012 05:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.542
X-Spam-Level: 
X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 KC84B1hnNuAE for ; Sun, 21 Oct 2012 05:50:23 -0700 (PDT)
Received: from relay3.mail.ox.ac.uk (relay3.mail.ox.ac.uk [163.1.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id EB26021F8988 for ; Sun, 21 Oct 2012 05:50:19 -0700 (PDT)
Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay3.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1TPuyw-0006r0-Ax; Sun, 21 Oct 2012 13:50:18 +0100
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TPuyv-0008Rh-6R; Sun, 21 Oct 2012 13:50:18 +0100
Message-ID: <5083B3A7.3060205@ninebynine.org>
Date: Sun, 21 Oct 2012 09:34:47 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Peter Saint-Andre 
References: <20121019032056.23291.40130.idtracker@ietfa.amsl.com> <5080C96A.5070208@stpeter.im>
In-Reply-To: <5080C96A.5070208@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-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, 21 Oct 2012 12:50:24 -0000

Hi Peter,

I've made this comment before, but I didn't get any clear sense of rtesolution 
in the ensuing discussion.

With the scheme semantics watered down to point that dereferencing is defined 
only in the context of a protocol in which is appears, I'm not seeing why this 
justifies being a new URI scheme.

For example, if I am browsing an HTML document (obtained by unspecified means) 
containing "foo account", can I not expect 
anything consistent to happen if I click on this link?

When I was involved in earlier reviews of this scheme, part of the reason I 
perceived that justified it being a separate URI scheme was that dereferencing 
would be performed using the WebFinger protocol, irrespective of the service for 
which for which is may be an account identifier.  This does not prevent use of 
the acct: URI in specialized contexts which handle it in different ways (such as 
lookup against a table of known accounts).

If you feel this point was fully considered and disregarded for cogent reasons, 
then I don't feel so strongly about this to pursue it, but I'm not sure if it 
might be falling through the cracks.

#g
--


On 19/10/2012 04:30, Peter Saint-Andre wrote:
> Some relatively small tweaks to address feedback received. (However, I
> realize just now that the ABNF simplification might not be what we want...)
>
> Peter
>
> On 10/18/12 9:20 PM, internet-drafts@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>   This draft is a work item of the Applications Area Working Group Working Group of the IETF.
>>
>> 	Title           : The 'acct' URI Scheme
>> 	Author(s)       : Peter Saint-Andre
>> 	Filename        : draft-ietf-appsawg-acct-uri-01.txt
>> 	Pages           : 7
>> 	Date            : 2012-10-18
>>
>> Abstract:
>>     This document defines the 'acct' URI scheme as a way to identify a
>>     user's account at a service provider, irrespective of the particular
>>     protocols that can be used to interact with the account.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-01
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-acct-uri-01
>>
>>
>> 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
>>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From paulej@packetizer.com  Sun Oct 21 08:51:47 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5AE21F8928 for ; Sun, 21 Oct 2012 08:51:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.418
X-Spam-Level: 
X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181,  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 6NoAS1-SwY+F for ; Sun, 21 Oct 2012 08:51:46 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1397621F8917 for ; Sun, 21 Oct 2012 08:51:45 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9LFpiQJ017288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 21 Oct 2012 11:51:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1350834705; bh=IUvLWBEWWMJcu+1D4OKUMsjVXlmqgylgqf4ponjJr+w=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ggicaS9GjWlmErbI1DbL/yQzFki4WU73sHm51VWVIEw0HQ7cN0psqFEHJvO+80mxV rwT3Nn8GRZpJmAVd6uydR/PJK9jlq9ZB4gCNIp4B5XS/m19UE9jko81xZ2JHuyeTtT rfq9myTIQfwPzfekUqbxrN+D/CaCRt6wFNh/oUaE=
From: "Paul E. Jones" 
To: "'Graham Klyne'" , "'Peter Saint-Andre'" 
References: <20121019032056.23291.40130.idtracker@ietfa.amsl.com>	<5080C96A.5070208@stpeter.im> <5083B3A7.3060205@ninebynine.org>
In-Reply-To: <5083B3A7.3060205@ninebynine.org>
Date: Sun, 21 Oct 2012 11:51:59 -0400
Message-ID: <019701cdafa4$01a5c1b0$04f14510$@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: AQGrz9t+g0yG0FmxPWZgTDKJna7qYQIPXHhEApWEFryX4n2OUA==
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-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, 21 Oct 2012 15:51:47 -0000

Graham,

My opinions on this...

If the browser encountered "acct:", I would like to have the browser open up
a "page" that displays the information obtained via WebFinger.  It might be
presented in the form of a user "profile" page, showing the person's
picture, name, contact information, blog URL, etc.  It might not show
everything discovered, since the browser may not know what the rel type
"foo" means, but it could assemble a useful page for known data elements.

At least that was my thought for using "acct" within the context of an HTML
page.

Outside of an HTML page, "acct" would be used by WebFinger to query for
information about a user account and the client issuing the query might be
looking for lots of information or very specific pieces of information
(e.g., an OpenID URL).

I think there was a question raised on the list before about "do we see use
of acct outside of WebFinger."  I think it might be used outside, e.g., in
HTML documents, but my assumption had been that it would still relate to a
WebFinger query.  It might be used elsewhere, but the main driver has been
WebFinger.

Paul

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of Graham Klyne
> Sent: Sunday, October 21, 2012 4:35 AM
> To: Peter Saint-Andre
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-
> 01.txt
> 
> Hi Peter,
> 
> I've made this comment before, but I didn't get any clear sense of
> rtesolution in the ensuing discussion.
> 
> With the scheme semantics watered down to point that dereferencing is
> defined only in the context of a protocol in which is appears, I'm not
> seeing why this justifies being a new URI scheme.
> 
> For example, if I am browsing an HTML document (obtained by unspecified
> means) containing "foo account", can
> I not expect anything consistent to happen if I click on this link?
> 
> When I was involved in earlier reviews of this scheme, part of the
> reason I perceived that justified it being a separate URI scheme was
> that dereferencing would be performed using the WebFinger protocol,
> irrespective of the service for which for which is may be an account
> identifier.  This does not prevent use of the acct: URI in specialized
> contexts which handle it in different ways (such as lookup against a
> table of known accounts).
> 
> If you feel this point was fully considered and disregarded for cogent
> reasons, then I don't feel so strongly about this to pursue it, but I'm
> not sure if it might be falling through the cracks.
> 
> #g
> --
> 
> 
> On 19/10/2012 04:30, Peter Saint-Andre wrote:
> > Some relatively small tweaks to address feedback received. (However, I
> > realize just now that the ABNF simplification might not be what we
> > want...)
> >
> > Peter
> >
> > On 10/18/12 9:20 PM, internet-drafts@ietf.org wrote:
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >>   This draft is a work item of the Applications Area Working Group
> Working Group of the IETF.
> >>
> >> 	Title           : The 'acct' URI Scheme
> >> 	Author(s)       : Peter Saint-Andre
> >> 	Filename        : draft-ietf-appsawg-acct-uri-01.txt
> >> 	Pages           : 7
> >> 	Date            : 2012-10-18
> >>
> >> Abstract:
> >>     This document defines the 'acct' URI scheme as a way to identify
> a
> >>     user's account at a service provider, irrespective of the
> particular
> >>     protocols that can be used to interact with the account.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri
> >>
> >> There's also a htmlized version available at:
> >> http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-01
> >>
> >> A diff from the previous version is available at:
> >> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-acct-uri-01
> >>
> >>
> >> 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
> >>
> > _______________________________________________
> > 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 cweiske@cweiske.de  Sun Oct 21 00:37:31 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472B421F88CF for ; Sun, 21 Oct 2012 00:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOSwoQlJs3CY for ; Sun, 21 Oct 2012 00:37:30 -0700 (PDT)
Received: from mail.cweiske.de (mail.cweiske.de [IPv6:2a01:488:66:1000:53a9:7c6:0:1]) by ietfa.amsl.com (Postfix) with ESMTP id 264BC21F88BD for ; Sun, 21 Oct 2012 00:37:29 -0700 (PDT)
Received: by mail.cweiske.de (Postfix, from userid 65534) id 31F6B1043801F; Sun, 21 Oct 2012 09:37:28 +0200 (CEST)
Received: from bogo (p54BD7959.dip.t-dialin.net [84.189.121.89]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.cweiske.de (Postfix) with ESMTPSA id 68CDD1043801E; Sun, 21 Oct 2012 09:37:26 +0200 (CEST)
Date: Sun, 21 Oct 2012 09:37:28 +0200
From: Christian Weiske 
To: webfinger@googlegroups.com
Message-ID: <20121021093728.590d2898@bogo>
In-Reply-To: <00c501cdaf13$13ef6d30$3bce4790$@packetizer.com>
References: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com> <5082C526.3050100@status.net> <00c501cdaf13$13ef6d30$3bce4790$@packetizer.com>
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/p0rMIiX/SNZDSozf70ROj3y"; protocol="application/pgp-signature"
X-Mailman-Approved-At: Sun, 21 Oct 2012 10:41:13 -0700
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-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, 21 Oct 2012 07:37:31 -0000

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

Hello Paul,


>> *	Section 7 makes support for CORS a MUST and then turns
>> around and said if you have a good reason not to support it, you
>> SHOULD NOT. I suggest that support for CORS should just be a SHOULD.
>> I can figure out myself whether I want to be the exception.
> PEJ: You're entirely right about that and that text bugged me, too.
> There was a strong desire for CORS to the point I was asked to make
> it a MUST, yet there was the desire to allow an enterprise do
> something more restrictive. I have no strong preference, myself, but
> I do think that if we make it a SHOULD, though, that it will make it
> impossible to build a client in a browser.  What does the group want
> here?

Not supporting CORS does not make the data any more secure. If someone
wants security for their intranet, they have to implement real security
measurements, e.g. based on IP whitelists.

Please leave CORS support a MUST.

--=20
Regards/Mit freundlichen Gr=C3=BC=C3=9Fen
Christian Weiske

-=3D=E2=89=A1 Geeking around in the name of science since 1982 =E2=89=A1=3D-

--Sig_/p0rMIiX/SNZDSozf70ROj3y
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlCDpjgACgkQFMhaCCTq+CN1HACgtVM79Urg9LWVFNnyh7VqKFYF
tG4AnjEzyOlGgVOqSAPXQmG1Rsu+PZUM
=Q4N/
-----END PGP SIGNATURE-----

--Sig_/p0rMIiX/SNZDSozf70ROj3y--

From mnot@mnot.net  Sun Oct 21 21:35:11 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA2821F8B01 for ; Sun, 21 Oct 2012 21:35:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.105
X-Spam-Level: 
X-Spam-Status: No, score=-104.105 tagged_above=-999 required=5 tests=[AWL=-1.506, 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 ca3jmApUKTOK for ; Sun, 21 Oct 2012 21:35:10 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id DF72321F8AFE for ; Sun, 21 Oct 2012 21:35:08 -0700 (PDT)
Received: from mnot-mini.mnot.net (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4D6FF22E259; Mon, 22 Oct 2012 00:34:59 -0400 (EDT)
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: Mon, 22 Oct 2012 15:34:51 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <39B5CA24-1345-481D-B3B1-716B27EF24FB@mnot.net>
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642F4D@WSMSG3153V.srv.dir.telstra.com> 
To: "Manger, James H" 
X-Mailer: Apple Mail (2.1499)
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: draft 05 comments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Oct 2012 04:35:11 -0000

On 01/10/2012, at 9:45 PM, Mark Nottingham  wrote:

>> 4.5. copy: can you copy a value into a component of itself? That is, =
can "path" be a prefix of "to"?
>> {"op":"copy", "path":"/a", "to":"/a/b/c"}

Addressing with:

                The location in the "to" member MUST NOT be part of =
the
                location defined by "path"; i.e., a location cannot be =
[copied | moved]
                into one of its children.


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




From internet-drafts@ietf.org  Sun Oct 21 21:43:03 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F42521F8B46; Sun, 21 Oct 2012 21:43:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.526
X-Spam-Level: 
X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 48g9-6pJ7HSB; Sun, 21 Oct 2012 21:43:02 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58DE21F8B2A; Sun, 21 Oct 2012 21:43:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121022044301.9947.54201.idtracker@ietfa.amsl.com>
Date: Sun, 21 Oct 2012 21:43:01 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2012 04:43:04 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Applications Area Working Group Working G=
roup of the IETF.

	Title           : JSON Pointer
	Author(s)       : Paul C. Bryan
                          Kris Zyp
                          Mark Nottingham
	Filename        : draft-ietf-appsawg-json-pointer-05.txt
	Pages           : 8
	Date            : 2012-10-21

Abstract:
   JSON Pointer defines a string syntax for identifying a specific value
   within a JSON document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-pointer-05


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


From internet-drafts@ietf.org  Sun Oct 21 21:43:21 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EB421F8B67; Sun, 21 Oct 2012 21:43:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.523
X-Spam-Level: 
X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 urdWM3orQoyc; Sun, 21 Oct 2012 21:43:20 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB89121F8B4F; Sun, 21 Oct 2012 21:43:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121022044317.9951.84768.idtracker@ietfa.amsl.com>
Date: Sun, 21 Oct 2012 21:43:17 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-06.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, 22 Oct 2012 04:43:21 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Applications Area Working Group Working G=
roup of the IETF.

	Title           : JSON Patch
	Author(s)       : Paul C. Bryan
                          Mark Nottingham
	Filename        : draft-ietf-appsawg-json-patch-06.txt
	Pages           : 16
	Date            : 2012-10-21

Abstract:
   JSON Patch defines the media type "application/json-patch", a JSON
   document structure for expressing a sequence of operations to apply
   to a JSON document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-06

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


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


From mnot@mnot.net  Sun Oct 21 21:45:04 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218C121F8AAB for ; Sun, 21 Oct 2012 21:45:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.077
X-Spam-Level: 
X-Spam-Status: No, score=-104.077 tagged_above=-999 required=5 tests=[AWL=-1.478, 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 aJopF+h6vnxG for ; Sun, 21 Oct 2012 21:45:02 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8544F21F8B8F for ; Sun, 21 Oct 2012 21:45:01 -0700 (PDT)
Received: from mnot-mini.mnot.net (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F2DA322E257 for ; Mon, 22 Oct 2012 00:44:54 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: <20121022044301.9947.54201.idtracker@ietfa.amsl.com>
Date: Mon, 22 Oct 2012 15:44:45 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20121022044301.9947.54201.idtracker@ietfa.amsl.com>
To: "apps-discuss@ietf.org Discuss" 
X-Mailer: Apple Mail (2.1499)
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2012 04:45:04 -0000

This was just adding '-' to reference the end of the array.


On 22/10/2012, at 3:43 PM, internet-drafts@ietf.org wrote:

>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Applications Area Working Group =
Working Group of the IETF.
>=20
> 	Title           : JSON Pointer
> 	Author(s)       : Paul C. Bryan
>                          Kris Zyp
>                          Mark Nottingham
> 	Filename        : draft-ietf-appsawg-json-pointer-05.txt
> 	Pages           : 8
> 	Date            : 2012-10-21
>=20
> Abstract:
>   JSON Pointer defines a string syntax for identifying a specific =
value
>   within a JSON document.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-05
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-pointer-05
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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




From mnot@mnot.net  Sun Oct 21 21:48:17 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BDB21F86D6 for ; Sun, 21 Oct 2012 21:48:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.05
X-Spam-Level: 
X-Spam-Status: No, score=-104.05 tagged_above=-999 required=5 tests=[AWL=-1.451, 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 vgQ-x2FPiztQ for ; Sun, 21 Oct 2012 21:48:16 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB6221F8555 for ; Sun, 21 Oct 2012 21:48:16 -0700 (PDT)
Received: from mnot-mini.mnot.net (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DE06322E257 for ; Mon, 22 Oct 2012 00:48:14 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: <20121022044317.9951.84768.idtracker@ietfa.amsl.com>
Date: Mon, 22 Oct 2012 15:48:05 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20121022044317.9951.84768.idtracker@ietfa.amsl.com>
To: "apps-discuss@ietf.org Discuss" 
X-Mailer: Apple Mail (2.1499)
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-06.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, 22 Oct 2012 04:48:17 -0000

This draft:

  - accommodated the '-' reference to the end of an array
  - loosened the requirements around existing objects, contents of the =
root object and "add"
  - prohibited recursive "move" and "copy"
  - added a few more examples
  - cleaned up some of the terminology

Cheers,


On 22/10/2012, at 3:43 PM, internet-drafts@ietf.org wrote:

>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Applications Area Working Group =
Working Group of the IETF.
>=20
> 	Title           : JSON Patch
> 	Author(s)       : Paul C. Bryan
>                          Mark Nottingham
> 	Filename        : draft-ietf-appsawg-json-patch-06.txt
> 	Pages           : 16
> 	Date            : 2012-10-21
>=20
> Abstract:
>   JSON Patch defines the media type "application/json-patch", a JSON
>   document structure for expressing a sequence of operations to apply
>   to a JSON document.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-06
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-patch-06
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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




From romeda@gmail.com  Mon Oct 22 01:49:49 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0ED621F8525 for ; Mon, 22 Oct 2012 01:49:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJYj7q7IgDDZ for ; Mon, 22 Oct 2012 01:49:49 -0700 (PDT)
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2CD21F855D for ; Mon, 22 Oct 2012 01:49:49 -0700 (PDT)
Received: by mail-pa0-f44.google.com with SMTP id fb11so1767042pad.31 for ; Mon, 22 Oct 2012 01:49:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=UPuKqKLtkn7dNUQ2J9+xKbvnqyOwG9heMCGdjRuVUPk=; b=rdgVAEqB8CJqtw5T8RNkURW4gXuJkeZB9xf7Un9Kb+4Aqq3JWWw/2xKKQ5jMw3WhbA 3p4A2yco3oUJuCKSra2EB823McpAQqvbMq8L49SWvrIBKW9n0e8t6S5ZWxTfpQz2fCzv 8cMe7TJ86idxzFieo5V/A1g+WXN8s46GMT7bK0xrtF+1KSF0UUD5QGTfCHspCuNALT/h t/PSY/5Mv3MgvmKD/hOMeAfvoMq1i6aL+uNjq++uN9lMSc8u5AivHwCYRC4BnRa00Ict dGJ9Cdpf3SalLFeCKSU27IK1sK5DC60bsyh18bKjKCNOBK7uqVABjjwXR2dk4Gcn/PYj /nhw==
Received: by 10.66.85.10 with SMTP id d10mr24180366paz.52.1350895788738; Mon, 22 Oct 2012 01:49:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.67.2.101 with HTTP; Mon, 22 Oct 2012 01:49:28 -0700 (PDT)
In-Reply-To: 
References: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com> <5082C526.3050100@status.net> <00c501cdaf13$13ef6d30$3bce4790$@packetizer.com> <20121021093728.590d2898@bogo> 
From: Blaine Cook 
Date: Mon, 22 Oct 2012 04:49:28 -0400
Message-ID: 
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: webfinger@googlegroups.com
Subject: Re: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-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: Mon, 22 Oct 2012 08:49:49 -0000

Preamble: This spec looks absolutely nothing like I imagined
Webfinger, which was, and was meant to be, a light-weight and simple
method to look up resource data for an email address. I'm not happy
with this *at all*, and probably won't implement it, either client or
server. I've achieved the login handling using a much simpler (but
less powerful and intentful) heuristic that I'll talk about soon.

1. +1 on CORS support.

2. Since I appear to have fully and completely lost the argument on
structuring Webfinger like DNS (despite the many positive reactions
outside this list I've received regarding the alternate proposal), two
proposals:

2a. Drop the template URI stuff.
2b. Have only one method for following redirects. If the participants
in this process think that it's OK to require static hosts to use HTTP
semantics (30x) to redirect /.well-known/host-meta, then use that
everywhere, since the hard place to do that is for static hosts =E2=80=93
anyone responding dynamically requests can trivially issue HTTP
redirects, rather than generating JSON.

Some notes on redirects:

=E2=80=93=C2=A0The redirect code MUST NOT be 301. This would make it imposs=
ible
under some circumstances for the host to regain control over lookups,
and is *never* the correct behaviour from a normative standpoint
(where the behaviour being enabled is like DNS =E2=80=93=C2=A0you can *neve=
r*
permanently redirect a DNS lookup).
=E2=80=93=C2=A0Clients MUST treat 301 response codes as 307.
=E2=80=93=C2=A0The redirect code SHOULD be 307, and the server SHOULD use
appropriate HTTP caching semantics.

Note that we are actually getting *worse* performance characteristics
out of this scheme for hosts using 3rd party webfinger providers,
since each request to a different user results in two requests; one to
the base domain, and one to the 3rd party server.

Drop all the redirect JRD stuff.

Hope that's helpful.

b.

On 21 October 2012 05:13, Melvin Carvalho  wrote:
>
>
> On 21 October 2012 09:37, Christian Weiske  wrote:
>>
>> Hello Paul,
>>
>>
>> >> *    Section 7 makes support for CORS a MUST and then turns
>> >> around and said if you have a good reason not to support it, you
>> >> SHOULD NOT. I suggest that support for CORS should just be a SHOULD.
>> >> I can figure out myself whether I want to be the exception.
>> > PEJ: You're entirely right about that and that text bugged me, too.
>> > There was a strong desire for CORS to the point I was asked to make
>> > it a MUST, yet there was the desire to allow an enterprise do
>> > something more restrictive. I have no strong preference, myself, but
>> > I do think that if we make it a SHOULD, though, that it will make it
>> > impossible to build a client in a browser.  What does the group want
>> > here?
>>
>> Not supporting CORS does not make the data any more secure. If someone
>> wants security for their intranet, they have to implement real security
>> measurements, e.g. based on IP whitelists.
>>
>> Please leave CORS support a MUST.
>
>
> +1
>>
>>
>> --
>> Regards/Mit freundlichen Gr=C3=BC=C3=9Fen
>> Christian Weiske
>>
>> -=3D=E2=89=A1 Geeking around in the name of science since 1982 =E2=89=A1=
=3D-
>
>

From paulej@packetizer.com  Mon Oct 22 11:18:14 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AE511E80A4 for ; Mon, 22 Oct 2012 11:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level: 
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172,  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 SxvB1Ex+9bH5 for ; Mon, 22 Oct 2012 11:18:13 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE5911E80EE for ; Mon, 22 Oct 2012 11:18:13 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9MIIAA9023726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Oct 2012 14:18:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1350929891; bh=GJ9PZWYWOaj0FBbDDBRO5/jUeTawrv2SrkQASehPWpk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Oil+Ed5BWzfzTaqViU0cCe5BXxyGFXXEWmd4U6aQA5vAAcwUNmwAMBoaet/GTolSU BiLiRS6EzS5nyriovjWt5aiREuoQHHnG7qDroBsbI9ZrixIhXH+QCND+jgflVCwHon A6a4v3yh33hpJ6Igd0s9ho2pXfBIWfyzqNDyJjpc=
From: "Paul E. Jones" 
To: "'Blaine Cook'" , 
References: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com>	<5082C526.3050100@status.net>	<00c501cdaf13$13ef6d30$3bce4790$@packetizer.com>	<20121021093728.590d2898@bogo>	 
In-Reply-To: 
Date: Mon, 22 Oct 2012 14:18:27 -0400
Message-ID: <029901cdb081$a253e7d0$e6fbb770$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGcFKYbM2jJ0wiJf9oQM3Qhr6BdxwGjlKSjAlziv24CTWS12wD2u3/eAL94oFSX6JVosA==
Content-Language: en-us
Cc: webfinger@googlegroups.com
Subject: Re: [apps-discuss] WebFinger Draft Updated -	draft-ietf-appsawg-webfinger-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: Mon, 22 Oct 2012 18:18:15 -0000

Blaine,

> Preamble: This spec looks absolutely nothing like I imagined =
Webfinger,
> which was, and was meant to be, a light-weight and simple method to =
look
> up resource data for an email address. I'm not happy with this *at =
all*,
> and probably won't implement it, either client or server. I've =
achieved
> the login handling using a much simpler (but less powerful and =
intentful)
> heuristic that I'll talk about soon.

How can you say that when the current WebFinger draft actually makes RFC =
6415 even simpler than it was before.  Now, JSON is the only MTI format =
and a client can get everything it's looking for with a simple query =
like

 GET /.well-known/host-meta.json?resource=3Dacct%3Abob%40example.com =
HTTP/1.1

That returns the complete resource descriptor.  The server-side code is =
also simple.  My code just outputs data from a database that matches the =
URI "acct:bob@example.com".

It seems pretty light-weight to me, yet flexible enough to allow one to =
convey a list of link relations.
=20
> 1. +1 on CORS support.

There seems to be a lot of support to keep that.
=20
> 2. Since I appear to have fully and completely lost the argument on
> structuring Webfinger like DNS (despite the many positive reactions
> outside this list I've received regarding the alternate proposal), two
> proposals:

WebFinger is structured the way it was described in Eran's posts, the =
WebFinger list, and RFC 6415.  I don't recall exactly what your proposal =
was now, but there were proposals to use DNS records like "URI" type =
records.  I like that idea, but it's a chicken and egg problem.  Many =
solutions require more complexity on the client, and we tried to make =
the client simpler.
=20
> 2a. Drop the template URI stuff.

That comes from RFC 6415 and a server would likely expose at least one =
link of type "template" if the client queries the host-meta resource =
without using the "resource" parameter.  Name, it would likely send the =
"lrdd" template type.  However, a client will NEVER see the templates if =
it uses the "resource" parameter.  I think that is important, because =
that makes the client code simpler.

> 2b. Have only one method for following redirects. If the participants =
in
> this process think that it's OK to require static hosts to use HTTP
> semantics (30x) to redirect /.well-known/host-meta, then use that
> everywhere, since the hard place to do that is for static hosts =
=E2=80=93 anyone
> responding dynamically requests can trivially issue HTTP redirects,
> rather than generating JSON.

Can you clarify the point of concern?  The only redirection mechanism =
proposed in the spec is 3xx.  What text is troubling you?

> Some notes on redirects:
>=20
> =E2=80=93 The redirect code MUST NOT be 301. This would make it =
impossible under
> some circumstances for the host to regain control over lookups, and is
> *never* the correct behaviour from a normative standpoint (where the
> behaviour being enabled is like DNS =E2=80=93 you can *never* =
permanently
> redirect a DNS lookup).

I would argue that this should be a deployment matter. The only thing we =
say in the spec is that clients need to follow redirection on 301, 302, =
or 307.  (That's what RFC 6415 says, and it's reasonable.  Browsers do =
that.)

> =E2=80=93 Clients MUST treat 301 response codes as 307.

We cannot require this.  Browsers, for example, are in control of that =
behavior, not the WF client running in the browser.  Also, 301 and 307 =
have different semantics.

> =E2=80=93 The redirect code SHOULD be 307, and the server SHOULD use =
appropriate
> HTTP caching semantics.

While using 307 might be the right way to deploy, that is (again) a =
deployment matter.  I'll note that many web sites still use 302, not =
307.  WF clients should accept any of the listed 3xx codes.
=20
> Note that we are actually getting *worse* performance characteristics
> out of this scheme for hosts using 3rd party webfinger providers, =
since
> each request to a different user results in two requests; one to the
> base domain, and one to the 3rd party server.

For those hosting their own WebFinger server (and it really is trivial =
code), performance is not an issue.  There would be a single =
request/response.

Large companies will likely run their own servers and could respond =
directly to requests.  For large companies that want to redirect queries =
away from example.com/.well-known/host-meta.json to =
webfinger.example.com/wherever/ (for example) could (and probably =
should) use 301 replies to encourage clients to redirect more optimally. =
 This would be a deployment option we should allow.

Where a domain owner has requests coming in from many distinct clients =
and they use 3xx to redirect to a WebFinger provider, we end up with two =
request/response exchanges: one for the original request and one to the =
new location.  But, this would only be necessary if the domain owner =
does not want to point the A record for their domain to the WebFinger =
provider.  For those who more-or-less host the whole host (or domain) =
where the WF service exists, it's not an issue.  The extra exchange will =
come in only where only the WF service is hosted elsewheer.

In any case, there are many possible deployment models, each with pros =
and cons.
=20
> Drop all the redirect JRD stuff.

Are you referring to Section 9 or somewhere else?  I think there is =
value in having Section 9 since it describes some hosting options.  It =
could perhaps be made non-normative, but we do make the normative =
requirement for clients to handle 3xx responses.  RFC 6415 made that =
optional for clients.

> Hope that's helpful.

Any input is helpful.  We need to get on the same page and agree on how =
this should work.  The current draft is not a significant departure from =
what was defined already, and it wasn't intended to be.  I'd summarize =
it as RFC 6415 - XML + JRD + "resource" parameter.  I'm actually =
surprised you had such a negative reaction to the text. :-)

Paul
=20
> b.
>=20
> On 21 October 2012 05:13, Melvin Carvalho 
> wrote:
> >
> >
> > On 21 October 2012 09:37, Christian Weiske  =
wrote:
> >>
> >> Hello Paul,
> >>
> >>
> >> >> *    Section 7 makes support for CORS a MUST and then turns
> >> >> around and said if you have a good reason not to support it, you
> >> >> SHOULD NOT. I suggest that support for CORS should just be a
> SHOULD.
> >> >> I can figure out myself whether I want to be the exception.
> >> > PEJ: You're entirely right about that and that text bugged me, =
too.
> >> > There was a strong desire for CORS to the point I was asked to =
make
> >> > it a MUST, yet there was the desire to allow an enterprise do
> >> > something more restrictive. I have no strong preference, myself,
> >> > but I do think that if we make it a SHOULD, though, that it will
> >> > make it impossible to build a client in a browser.  What does the
> >> > group want here?
> >>
> >> Not supporting CORS does not make the data any more secure. If
> >> someone wants security for their intranet, they have to implement
> >> real security measurements, e.g. based on IP whitelists.
> >>
> >> Please leave CORS support a MUST.
> >
> >
> > +1
> >>
> >>
> >> --
> >> Regards/Mit freundlichen Gr=C3=BC=C3=9Fen
> >> Christian Weiske
> >>
> >> -=3D=E2=89=A1 Geeking around in the name of science since 1982 =
=E2=89=A1=3D-
> >
> >
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From GK@ninebynine.org  Mon Oct 22 12:33:27 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEF821F8525 for ; Mon, 22 Oct 2012 12:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.566
X-Spam-Level: 
X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.034,  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 oBdwRdZ6KAjs for ; Mon, 22 Oct 2012 12:33:26 -0700 (PDT)
Received: from relay1.mail.ox.ac.uk (relay1.mail.ox.ac.uk [129.67.1.165]) by ietfa.amsl.com (Postfix) with ESMTP id 08C2621F84C5 for ; Mon, 22 Oct 2012 12:33:26 -0700 (PDT)
Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay1.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1TQNkY-0008V2-5e; Mon, 22 Oct 2012 20:33:22 +0100
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1TQNkX-0006KC-6o; Mon, 22 Oct 2012 20:33:22 +0100
Message-ID: <50859CDC.5070506@ninebynine.org>
Date: Mon, 22 Oct 2012 20:22:04 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Paul E. Jones" 
References: <20121019032056.23291.40130.idtracker@ietfa.amsl.com>	<5080C96A.5070208@stpeter.im> <5083B3A7.3060205@ninebynine.org> <019701cdafa4$01a5c1b0$04f14510$@packetizer.com>
In-Reply-To: <019701cdafa4$01a5c1b0$04f14510$@packetizer.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-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: Mon, 22 Oct 2012 19:33:27 -0000

Paul,

I regard your position here as being consistent with dereferencing of acct: URIs 
using WebFinger.  Some additional use of content negotiation (recalling that 
WebFinger is HTTP-based) might be needed to achieve the full effect in-browser 
that you describe, but IMO the principle that WebFinger is the main/default 
mechanism for dereferencing acct: URIs stands.

#g
--

On 21/10/2012 16:51, Paul E. Jones wrote:
> Graham,
>
> My opinions on this...
>
> If the browser encountered "acct:", I would like to have the browser open up
> a "page" that displays the information obtained via WebFinger.  It might be
> presented in the form of a user "profile" page, showing the person's
> picture, name, contact information, blog URL, etc.  It might not show
> everything discovered, since the browser may not know what the rel type
> "foo" means, but it could assemble a useful page for known data elements.
>
> At least that was my thought for using "acct" within the context of an HTML
> page.
>
> Outside of an HTML page, "acct" would be used by WebFinger to query for
> information about a user account and the client issuing the query might be
> looking for lots of information or very specific pieces of information
> (e.g., an OpenID URL).
>
> I think there was a question raised on the list before about "do we see use
> of acct outside of WebFinger."  I think it might be used outside, e.g., in
> HTML documents, but my assumption had been that it would still relate to a
> WebFinger query.  It might be used elsewhere, but the main driver has been
> WebFinger.
>
> Paul
>
>> -----Original Message-----
>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>> bounces@ietf.org] On Behalf Of Graham Klyne
>> Sent: Sunday, October 21, 2012 4:35 AM
>> To: Peter Saint-Andre
>> Cc: apps-discuss@ietf.org
>> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-
>> 01.txt
>>
>> Hi Peter,
>>
>> I've made this comment before, but I didn't get any clear sense of
>> rtesolution in the ensuing discussion.
>>
>> With the scheme semantics watered down to point that dereferencing is
>> defined only in the context of a protocol in which is appears, I'm not
>> seeing why this justifies being a new URI scheme.
>>
>> For example, if I am browsing an HTML document (obtained by unspecified
>> means) containing "foo account", can
>> I not expect anything consistent to happen if I click on this link?
>>
>> When I was involved in earlier reviews of this scheme, part of the
>> reason I perceived that justified it being a separate URI scheme was
>> that dereferencing would be performed using the WebFinger protocol,
>> irrespective of the service for which for which is may be an account
>> identifier.  This does not prevent use of the acct: URI in specialized
>> contexts which handle it in different ways (such as lookup against a
>> table of known accounts).
>>
>> If you feel this point was fully considered and disregarded for cogent
>> reasons, then I don't feel so strongly about this to pursue it, but I'm
>> not sure if it might be falling through the cracks.
>>
>> #g
>> --
>>
>>
>> On 19/10/2012 04:30, Peter Saint-Andre wrote:
>>> Some relatively small tweaks to address feedback received. (However, I
>>> realize just now that the ABNF simplification might not be what we
>>> want...)
>>>
>>> Peter
>>>
>>> On 10/18/12 9:20 PM, internet-drafts@ietf.org wrote:
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>>>    This draft is a work item of the Applications Area Working Group
>> Working Group of the IETF.
>>>>
>>>> 	Title           : The 'acct' URI Scheme
>>>> 	Author(s)       : Peter Saint-Andre
>>>> 	Filename        : draft-ietf-appsawg-acct-uri-01.txt
>>>> 	Pages           : 7
>>>> 	Date            : 2012-10-18
>>>>
>>>> Abstract:
>>>>      This document defines the 'acct' URI scheme as a way to identify
>> a
>>>>      user's account at a service provider, irrespective of the
>> particular
>>>>      protocols that can be used to interact with the account.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri
>>>>
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-01
>>>>
>>>> A diff from the previous version is available at:
>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-acct-uri-01
>>>>
>>>>
>>>> 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
>>>>
>>> _______________________________________________
>>> 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
>

From internet-drafts@ietf.org  Mon Oct 22 13:52:20 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082001F0C49; Mon, 22 Oct 2012 13:52:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaW6BZBR7Mh8; Mon, 22 Oct 2012 13:52:19 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA491F0C5C; Mon, 22 Oct 2012 13:52:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121022205219.31308.5422.idtracker@ietfa.amsl.com>
Date: Mon, 22 Oct 2012 13:52:19 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-07.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, 22 Oct 2012 20:52:20 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Applications Area Working Group Working G=
roup of the IETF.

	Title           : Additional Media Type Structured Syntax Suffixes
	Author(s)       : Tony Hansen
                          Alexey Melnikov
	Filename        : draft-ietf-appsawg-media-type-suffix-regs-07.txt
	Pages           : 14
	Date            : 2012-10-22

Abstract:
   A content media type name sometimes includes partitioned meta-
   information distinguish by a Structured Syntax, to permit noting an
   attribute of the media as a suffix to the name.  This document
   defines several Structured Syntax Suffixes for use with media type
   registrations.  In particular, it defines and registers the "+json",
   "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax
   Suffixes, and provides a Message Type Structured Syntax Suffix
   registration form for the "+xml" Structured Syntax Suffix.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-suffix-regs

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-media-type-suffix-reg=
s-07


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


From ajs@anvilwalrusden.com  Mon Oct 22 15:00:39 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E818A1F0C49 for ; Mon, 22 Oct 2012 15:00:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.84
X-Spam-Level: 
X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000,  BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0p9nlXKFxC4z for ; Mon, 22 Oct 2012 15:00:39 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5293D1F042B for ; Mon, 22 Oct 2012 15:00:39 -0700 (PDT)
Received: from crankycanuck.ca (dhcp-222-230.meetings.nanog.org [199.187.222.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 130EC8A031 for ; Mon, 22 Oct 2012 22:00:38 +0000 (UTC)
Date: Mon, 22 Oct 2012 18:00:30 -0400
From: Andrew Sullivan 
To: apps-discuss@ietf.org
Message-ID: <20121022220029.GA50793@crankycanuck.ca>
References: <20121022211516.15926.49394.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20121022211516.15926.49394.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [apps-discuss] New Version Notification for draft-sullivan-domain-origin-assert-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, 22 Oct 2012 22:00:40 -0000

Dear colleagues,

On Mon, Oct 22, 2012 at 02:15:16PM -0700, internet-drafts@ietf.org wrote:
> 
> Filename:	 draft-sullivan-domain-origin-assert
> Revision:	 02
> Title:		 Asserting DNS Administrative Boundaries Within DNS Zones
> Creation date:	 2012-10-22
> WG ID:		 Individual Submission
> Number of pages: 19
> URL:             http://www.ietf.org/internet-drafts/draft-sullivan-domain-origin-assert-02.txt

After the positive feedback in the last IETF meeting, and after some
useful comments from John Klensin, I updated this draft.  It now
contains a discussion of two different approaches: the scheme-and-port
that was in the -01 version, and the names-only approach that I tried
in the -00 version (but which got quite a lot of negative feedback
from the browser development community).  Thoughts are welcome.  If
this work is to proceed at all, this issue needs to be decided.

Best,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From internet-drafts@ietf.org  Mon Oct 22 16:38:24 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5880B11E80F7; Mon, 22 Oct 2012 16:38:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.546
X-Spam-Level: 
X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 AU8Zq0u-wVIZ; Mon, 22 Oct 2012 16:38:23 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE91721F88C6; Mon, 22 Oct 2012 16:38:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121022233823.23364.11116.idtracker@ietfa.amsl.com>
Date: Mon, 22 Oct 2012 16:38:23 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-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, 22 Oct 2012 23:38:24 -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-02.txt
	Pages           : 26
	Date            : 2012-10-22

Abstract:
   This specification defines the WebFinger protocol.  WebFinger may be
   used to discover information about people on the Internet, such as a
   person's personal profile address, identity service, telephone
   number, or preferred avatar.  WebFinger may also be used to discover
   information about objects on the network, such as the amount of toner
   in a printer or the physical location of a server.


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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-02


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


From paulej@packetizer.com  Mon Oct 22 18:19:52 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA81F21F8904 for ; Mon, 22 Oct 2012 18:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.434
X-Spam-Level: 
X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165,  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 AflFJajNJI+R for ; Mon, 22 Oct 2012 18:19:52 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id EB3BF21F88EE for ; Mon, 22 Oct 2012 18:19:51 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9N1Jod1011116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Oct 2012 21:19:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1350955190; bh=dXn7IkiUUN5zGTTilLfShKGrUCAXNba/Jp5BxOvN2DY=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=kOC3vyIzNBQtf06LmL2G+nVjH4BWgpNAomr2PV2OKejSZe66IF8Ma6qr10myiUR3z RUWoxXq8dEG70LQ5tK/rHS2ZjzTT3dwp6KAxKKqGj19H2OFipXzyl4pVR0b/Swpl7t ASit9CdHeZQkwd2bWHtd8EOOZuA7ooNmd6DoIGT0=
From: "Paul E. Jones" 
To: , 
Date: Mon, 22 Oct 2012 21:20:07 -0400
Message-ID: <031801cdb0bc$8a5048f0$9ef0dad0$@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: Ac2wvEQslABaxXnaQFqLx1qBWbIq/Q==
Content-Language: en-us
Subject: [apps-discuss] Updated: draft-ietf-appsawg-webfinger-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: Tue, 23 Oct 2012 01:19:53 -0000

Folks,

I posted a slightly revised draft considering input received over the
weekend.  You can see the differences are fairly minor, but they were
changes I could easily make to improve the text.

Paul

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
> Sent: Monday, October 22, 2012 7:38 PM
> To: i-d-announce@ietf.org
> Cc: apps-discuss@ietf.org
> Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-02.txt
> 
> 
> 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           : WebFinger
> 	Author(s)       : Paul E. Jones
>                           Gonzalo Salgueiro
>                           Joseph Smarr
> 	Filename        : draft-ietf-appsawg-webfinger-02.txt
> 	Pages           : 26
> 	Date            : 2012-10-22
> 
> Abstract:
>    This specification defines the WebFinger protocol.  WebFinger may be
>    used to discover information about people on the Internet, such as a
>    person's personal profile address, identity service, telephone
>    number, or preferred avatar.  WebFinger may also be used to discover
>    information about objects on the network, such as the amount of toner
>    in a printer or the physical location of a server.
> 
> 
> 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-02
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-02
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From bkihara.l@gmail.com  Tue Oct 23 07:29:14 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05EC21F8504; Tue, 23 Oct 2012 07:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.164
X-Spam-Level: 
X-Spam-Status: No, score=-3.164 tagged_above=-999 required=5 tests=[AWL=0.435,  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 gXqPB4qtQrSs; Tue, 23 Oct 2012 07:29:14 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 299E121F84F5; Tue, 23 Oct 2012 07:29:13 -0700 (PDT)
Received: by mail-vb0-f44.google.com with SMTP id fc26so4730212vbb.31 for ; Tue, 23 Oct 2012 07:29:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PCaES+dDQ1h6RuLoLN35zgu89YJhxH4Fjb9hMFONA70=; b=lZpHxTHOvyZmMFTHdpW4LUlUhXNEVQ3wwG7kTqvc68i1BVCp5gveepu/e0/FLRH3xp zCKwyzsCIYEtdfEJIxi+Jrzo4poJ9Fa7pdfHdIZf0GJhuFllTVvhFMpSs5PCGk0h3IiA GKtROBmw2UYsoI5cH5JW3ZbwV8PAZiRbsVzRs2HpP9pzPF8LQohE5l/GRxytn7ynkXWl ZGJ8KGncOl+pCzcqfsvgIB0xEMh1L/T5zTP1yJaxy+1/17Z59D/6WMsGq/wImEnfOmhf gOV7zgKJhog2Y/0MnUHHAVvihdgzQ7SCKJJCCQx6Ydjn5Yh0chO7/MTCvawoYd5YEOPx z0xA==
MIME-Version: 1.0
Received: by 10.52.22.72 with SMTP id b8mr16893649vdf.88.1351002553111; Tue, 23 Oct 2012 07:29:13 -0700 (PDT)
Received: by 10.58.221.33 with HTTP; Tue, 23 Oct 2012 07:29:13 -0700 (PDT)
Date: Tue, 23 Oct 2012 23:29:13 +0900
Message-ID: 
From: "KIHARA, Boku" 
To: apps-discuss@ietf.org, saag@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [apps-discuss] Considerations for Protocols with Compression over 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: Tue, 23 Oct 2012 14:29:14 -0000

Hello,

I'm writing a draft on cosiderations for protocols with compression over
TLS, since I was shocked by the CRIME attack.
http://tools.ietf.org/html/draft-kihara-compression-considered-harmful-01

What I want to say are:
* the CRIME attack may be applied if compression is applied in any form
* disabling TLS Compression and SPDY header compression is not a perfect
  solution; the threat has not gone!
* there should be some mitigations to take when using compression in TLS

Because I am neither a cryptographer nor a security expert there must
many mistakes in the draft in addition to language faults, but I think
it is good that we have some guides for comression in TLS.
Is IETF the write place to do such things?

Regards,
Boku Kihara.

From fgaliegue@gmail.com  Tue Oct 23 15:51:15 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D359C1F0C95 for ; Tue, 23 Oct 2012 15:51:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.624
X-Spam-Level: 
X-Spam-Status: No, score=-3.624 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 t4onw09NaoDO for ; Tue, 23 Oct 2012 15:51:15 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 572911F0C3A for ; Tue, 23 Oct 2012 15:51:15 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id v19so4778714obq.31 for ; Tue, 23 Oct 2012 15:51:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KdTEsFGVjGmXd0CLzQoPPZbx5pgXHLq1XYi9jyY+oFI=; b=B9+NvZ/yY9wfwE2bVFWKU50oByISZWPWQpo0C7GbRnqVUdK9Y7XTKNUx7Lb9DED8SO i7Kx/O4pc2R2beheGyb8Ig05i/QZl1Y2DRFXknMypDMXzaCI+LbIShphYLoCNNTy4is9 M3FjoEAT212Iyl+rHe7sehOur55RAM7rulTVlY9lIZveob9t+PShDle4IMTwTUlllkc0 RxmfnPc17d2gV6ufccwJ9YO4N/wl0YnLnUWNcRkrF3I4cIbYtg59FD+NyBIejWTmS/LI xQgzJxlWMqKAaMTJHM/6/wtuU3lLO//LlycI/OEoliqsMWby26SJfuF9e+HFFIrd1AlH xZ6Q==
MIME-Version: 1.0
Received: by 10.182.54.102 with SMTP id i6mr10791741obp.67.1351032674718; Tue, 23 Oct 2012 15:51:14 -0700 (PDT)
Received: by 10.60.32.163 with HTTP; Tue, 23 Oct 2012 15:51:14 -0700 (PDT)
In-Reply-To: 
References:   
Date: Wed, 24 Oct 2012 00:51:14 +0200
Message-ID: 
From: Francis Galiegue 
To: Andrew Newton 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] RFC 4627 and text vs values
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2012 22:51:16 -0000

On Thu, Sep 27, 2012 at 3:01 PM, Francis Galiegue  wro=
te:
[...]
>
> That kind of begs the question: why wouldn't it be legal to produce
> JSON values other than arrays/objects? "Primitve" JSON values are
> potentially useful as well, I don't see the point of forbidding their
> production. This looks like limiting the expressiveness of JSON to me.
>

Ping on that one...

--=20
Francis Galiegue, fgaliegue@gmail.com
"It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The
Art of SQL", ISBN 0-596-00894-5)

From mnot@mnot.net  Tue Oct 23 22:02:36 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BEA21F8C36 for ; Tue, 23 Oct 2012 22:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.158
X-Spam-Level: 
X-Spam-Status: No, score=-104.158 tagged_above=-999 required=5 tests=[AWL=-1.859, 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 aKsvge-HM6xt for ; Tue, 23 Oct 2012 22:02:34 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D114621F8C18 for ; Tue, 23 Oct 2012 22:02:33 -0700 (PDT)
Received: from [192.168.1.82] (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F33AC22E1F4; Wed, 24 Oct 2012 01:02:25 -0400 (EDT)
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: <5086C026.7030908@skoegl.net>
Date: Wed, 24 Oct 2012 16:02:27 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5086C026.7030908@skoegl.net>
To: =?iso-8859-1?Q?Stefan_K=F6gl?= 
X-Mailer: Apple Mail (2.1499)
Cc: Apps Discuss 
Subject: Re: [apps-discuss] draft-ietf-appsawg-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, 24 Oct 2012 05:02:36 -0000

[forwarding to the WG]

Hi Stefan,

My .02 - this is really a question about JSON implementation, I think. =
JSON-Patch is designed to operate upon JSON documents (where this =
question doesn't come up), not upon Python data structures.

Cheers,


On 24/10/2012, at 3:04 AM, Stefan K=F6gl  wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Dear Working Group,
>=20
> I'm the maintainer of python-json-pointer [1], a Python implementation
> of the json-pointer drafts.
>=20
> In Python the natural representation of a JSON object is a dictionary.
> One of the differences is that a Python dictionary can have keys of
> different types. I could, for instance, define the following =
dictionary
>=20
> {"1": "a", 1: "b"}
>=20
> and try to resolve the pointer /1. I see several possible ways of
> resolving such cases:
>=20
> * Ignore any non-string key
> * Fail on non-string keys
> * Interpret both keys as equal and fail according to the following
>  sentence of the current draft:
>  " If a referenced member name is not unique in an object, the member
>    that is referenced is not unique in an object, the member that is
>    referenced is undefined, and evaluation fails (see below). "
>=20
> I understand that this problem can not occur in "pure" JSON where keys
> can only be strings, but I assume that also implementations in other
> languages will face the same issue. What is the opinion of the working
> group on this? Maybe it could be addressed in future drafts.
>=20
>=20
> Best regards,
>=20
> Stefan K=F6gl
>=20
>=20
> [1] https://github.com/stefankoegl/python-json-pointer
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>=20
> iEYEARECAAYFAlCGwCUACgkQ638pvJMAJ9BbsQCfYeu9SVDSKE2Z6DBYUKaAl1/b
> Z9gAoLRaMjzBgun8K8Wd3QEic0bYTxaC
> =3DttNc
> -----END PGP SIGNATURE-----

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




From mnot@mnot.net  Tue Oct 23 23:49:40 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15FC21F8C8D for ; Tue, 23 Oct 2012 23:49:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.294
X-Spam-Level: 
X-Spam-Status: No, score=-104.294 tagged_above=-999 required=5 tests=[AWL=-1.695, 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 xl6GaDoqJelN for ; Tue, 23 Oct 2012 23:49:40 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 191C621F8C88 for ; Tue, 23 Oct 2012 23:49:40 -0700 (PDT)
Received: from [192.168.1.82] (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 32BC922E253; Wed, 24 Oct 2012 02:49:32 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FD642E67@WSMSG3153V.srv.dir.telstra.com>
Date: Wed, 24 Oct 2012 17:49:39 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B079501-EF09-4916-B559-123362A23413@mnot.net>
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E67@WSMSG3153V.srv.dir.telstra.com>
To: "Manger, James H" 
X-Mailer: Apple Mail (2.1499)
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] json-patch: "op":"tree"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Oct 2012 06:49:40 -0000

This didn't make it into the last draft, and I'd like to get us to WGLC =
soon.

Personally, I'm going to push back on it; it's a syntactic convenience =
at most, and I think that most JSON Patch documents will be generated by =
code. This format really needs to be as simple as possible, and IME a =
convenience function like this doesn't make the cut.

However, that's just me.

Do people adamantly-want-this, or is it just nice-to-have?

What do the people actually implementing JSON Patch think?

Cheers,


On 01/10/2012, at 3:41 PM, "Manger, James H" =
 wrote:

> RE: draft-ietf-appsawg-json-patch-05
>=20
> Suggestion: define a "tree" operation for grouping operations that =
apply to part of the JSON doc being changed. It avoids repeating a path =
prefix in lots of operations; it simplifies writing a patch that can be =
applied at different points; its easier to separate the patch for =
changing a value from where that value is in a larger JSO structure. New =
text:
>=20
>  4.7. tree
>=20
>    The "tree" operation applies other operations to a subset of
>    the target. The operation object MUST include "path" and "ops"
>    members. "path" holds a JSON pointer that identifies the value
>    to which the other operations apply. "ops" holds an array of
>    operation objects. JSON pointers within "ops" are relative
>    to the value identified by "path".
>=20
>    Example:
>    Old:   {"a":{"b":{"c":{"d":{"e":{"name":"Alice"}}}}}}
>    Patch: [{"op":"tree", "path":"/a/b/c/d/e", "ops":[
>              {"op":"add", "path":"/age", "value":20},
>              {"op":"add", "path":"/email", "value":"a@eg.com"}]}]
>    New:   {"a":{"b":{"c":{"d":{"e":{
>            "name":"Alice", "age":20, "email":"a@eg.com"}}}}}}
>=20
> --
> James Manger

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




From jasnell@gmail.com  Tue Oct 23 23:54:27 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2CC21F8C8D for ; Tue, 23 Oct 2012 23:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.834
X-Spam-Level: 
X-Spam-Status: No, score=-4.834 tagged_above=-999 required=5 tests=[AWL=-1.236, 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 WcVyhg3HYFEQ for ; Tue, 23 Oct 2012 23:54:26 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6E14F21F8C9C for ; Tue, 23 Oct 2012 23:54:26 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id s14so107711qcg.31 for ; Tue, 23 Oct 2012 23:54:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=POl2PazWz2ussDKXOIQnWdtFmky8st1UqOPEXRMqScA=; b=wInkELe5EzqqG3zSU77Zm+siVJgp/HfrCKkqXyO6cDWy5APyF/Srut5RcUqmZZndHJ 8i7j+oswrQrwVTRJSrPDQuEKWJg72ixSUxeDSQP+DN2CQga8lqKQ5DVN75k7kuHCF4ZT 6QzjpCTN6UaW2LN/OgZmUzm3XxHW9NEGSFw7cq9nYV0fYaXOEJvt7oc10rhpXON1QnIK 13ENChWu584o9usvpzoKyK9l6TVdkL+X2hjT8s5dm5HbdI7DGGnAJsR8m0S1J5AsXNM1 n5GURaNG8TTk8qXIN27LneDkmVO8qzRlkgichXJ/LoR59dd6GaPbNjzIpBKxopxZ2fPG is2A==
MIME-Version: 1.0
Received: by 10.224.97.197 with SMTP id m5mr6894584qan.57.1351061665731; Tue, 23 Oct 2012 23:54:25 -0700 (PDT)
Received: by 10.49.81.230 with HTTP; Tue, 23 Oct 2012 23:54:25 -0700 (PDT)
Received: by 10.49.81.230 with HTTP; Tue, 23 Oct 2012 23:54:25 -0700 (PDT)
In-Reply-To: <6B079501-EF09-4916-B559-123362A23413@mnot.net>
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E67@WSMSG3153V.srv.dir.telstra.com> <6B079501-EF09-4916-B559-123362A23413@mnot.net>
Date: Tue, 23 Oct 2012 23:54:25 -0700
Message-ID: 
From: James M Snell 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=20cf3074b0daa7d68e04ccc88ee5
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] json-patch: "op":"tree"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Oct 2012 06:54:27 -0000

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

On Oct 23, 2012 11:49 PM, "Mark Nottingham"  wrote:
>
> This didn't make it into the last draft, and I'd like to get us to WGLC
soon.
>
> Personally, I'm going to push back on it; it's a syntactic convenience at
most, and I think that most JSON Patch documents will be generated by code.
This format really needs to be as simple as possible, and IME a convenience
function like this doesn't make the cut.

+1

>
> However, that's just me.
>
> Do people adamantly-want-this, or is it just nice-to-have?
>
> What do the people actually implementing JSON Patch think?
>
> Cheers,
>
>
> On 01/10/2012, at 3:41 PM, "Manger, James H" <
James.H.Manger@team.telstra.com> wrote:
>
> > RE: draft-ietf-appsawg-json-patch-05
> >
> > Suggestion: define a "tree" operation for grouping operations that
apply to part of the JSON doc being changed. It avoids repeating a path
prefix in lots of operations; it simplifies writing a patch that can be
applied at different points; its easier to separate the patch for changing
a value from where that value is in a larger JSO structure. New text:
> >
> >  4.7. tree
> >
> >    The "tree" operation applies other operations to a subset of
> >    the target. The operation object MUST include "path" and "ops"
> >    members. "path" holds a JSON pointer that identifies the value
> >    to which the other operations apply. "ops" holds an array of
> >    operation objects. JSON pointers within "ops" are relative
> >    to the value identified by "path".
> >
> >    Example:
> >    Old:   {"a":{"b":{"c":{"d":{"e":{"name":"Alice"}}}}}}
> >    Patch: [{"op":"tree", "path":"/a/b/c/d/e", "ops":[
> >              {"op":"add", "path":"/age", "value":20},
> >              {"op":"add", "path":"/email", "value":"a@eg.com"}]}]
> >    New:   {"a":{"b":{"c":{"d":{"e":{
> >            "name":"Alice", "age":20, "email":"a@eg.com"}}}}}}
> >
> > --
> > James Manger
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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




On Oct 23, 2012 11:49 PM, "Mark Nottingham" <mnot@mnot.net> wrote:

>

> This didn't make it into the last draft, and I'd like to get u=
s to WGLC soon.

>

> Personally, I'm going to push back on it; it's a syntactic con=
venience at most, and I think that most JSON Patch documents will be genera=
ted by code. This format really needs to be as simple as possible, and IME =
a convenience function like this doesn't make the cut.



+1


>

> However, that's just me.

>

> Do people adamantly-want-this, or is it just nice-to-have?

>

> What do the people actually implementing JSON Patch think?

>

> Cheers,

>

>

> On 01/10/2012, at 3:41 PM, "Manger, James H" <James.H.Manger@team.telstra.com=
> wrote:

>

> > RE: draft-ietf-appsawg-json-patch-05

> >

> > Suggestion: define a "tree" operation for grouping oper=
ations that apply to part of the JSON doc being changed. It avoids repeatin=
g a path prefix in lots of operations; it simplifies writing a patch that c=
an be applied at different points; its easier to separate the patch for cha=
nging a value from where that value is in a larger JSO structure. New text:=



> >

> > =C2=A04.7. tree

> >

> > =C2=A0 =C2=A0The "tree" operation applies other operati=
ons to a subset of

> > =C2=A0 =C2=A0the target. The operation object MUST include "=
path" and "ops"

> > =C2=A0 =C2=A0members. "path" holds a JSON pointer that =
identifies the value

> > =C2=A0 =C2=A0to which the other operations apply. "ops"=
 holds an array of

> > =C2=A0 =C2=A0operation objects. JSON pointers within "ops&qu=
ot; are relative

> > =C2=A0 =C2=A0to the value identified by "path".

> >

> > =C2=A0 =C2=A0Example:

> > =C2=A0 =C2=A0Old: =C2=A0 {"a":{"b":{"c&q=
uot;:{"d":{"e":{"name":"Alice"}}}}}=
}

> > =C2=A0 =C2=A0Patch: [{"op":"tree", "path=
":"/a/b/c/d/e", "ops":[

> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{"op":&=
quot;add", "path":"/age", "value":20},
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{"op":&=
quot;add", "path":"/email", "value":&quo=
t;a@eg.com"}]}]

> > =C2=A0 =C2=A0New: =C2=A0 {"a":{"b":{"c&q=
uot;:{"d":{"e":{

> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"name":"A=
lice", "age":20, "email":"a@eg.com"}}}}}}

> >

> > --

> > James Manger

>

> --

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

>

>

>

> _______________________________________________

> apps-discuss mailing list

> apps-discuss@ietf.org

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




--20cf3074b0daa7d68e04ccc88ee5--

From superuser@gmail.com  Wed Oct 24 08:20:32 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D8621F8B75 for ; Wed, 24 Oct 2012 08:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.579
X-Spam-Level: 
X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020,  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 dUwbpqZozr0F for ; Wed, 24 Oct 2012 08:20:31 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBE821F8B71 for ; Wed, 24 Oct 2012 08:20:31 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id k13so1285714lbo.31 for ; Wed, 24 Oct 2012 08:20:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=eEyRfyO2KvTLmUkVLjpvCi8qRXacCym1ssxKYUvaExc=; b=k2ctbQHc/2nPZcW2p0QdzbNmfw9x1D2/q+ClVzzWfJfUXFpr0G0Q2qZm1NDEzJ99om y2c234PA5x+BvUPkvVwmtFIOeGQFt2Hzox2eMV3xOTbiZqPWemf3r+okr7hz970wWXIR dCWgNW2zgCvltIm/Mc2ydnZeaNByQBPw0TM/WUSyY/cEsqMelmppgOi/ClkNeOnWV8OL TnxTJWJcRXFJg/W7F9ha1JXcqNnTvXBIhM4KqLCDF0BhB9qmODcCZBMcoGa0lHUCWVUd nUDXcmbPvCv3GkzNF6Y5JBvRfLug1kYIvn1qrzUuorw6SFwkZSsZM7oCFmw8g8ySXbha 8tRA==
MIME-Version: 1.0
Received: by 10.152.110.42 with SMTP id hx10mr14829197lab.0.1351092030239; Wed, 24 Oct 2012 08:20:30 -0700 (PDT)
Received: by 10.112.144.164 with HTTP; Wed, 24 Oct 2012 08:20:30 -0700 (PDT)
Date: Wed, 24 Oct 2012 11:20:30 -0400
Message-ID: 
From: "Murray S. Kucherawy" 
To: IETF Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [apps-discuss] Agenda deadline is today
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Oct 2012 15:20:32 -0000

The deadline for submitting preliminary agendas for working group
meetings is today.  If you would like to request a time slot for our
meeting in November, please email appsawg-chairs@tools.ietf.org ASAP.
If you have already sent a request but haven't heard back yet, feel
free to send us a reminder.

-MSK, co-chair

From mccabe@archive.org  Wed Oct 24 08:52:38 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FEB21F8C84 for ; Wed, 24 Oct 2012 08:52:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Us5JJ-Yfxfzs for ; Wed, 24 Oct 2012 08:52:37 -0700 (PDT)
Received: from mail.archive.org (mail.us.archive.org [207.241.224.6]) by ietfa.amsl.com (Postfix) with ESMTP id 355E521F84D7 for ; Wed, 24 Oct 2012 08:52:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.archive.org (Postfix) with ESMTP id D91776840243; Wed, 24 Oct 2012 08:52:36 -0700 (PDT)
Received: from mail.archive.org ([127.0.0.1]) by localhost (mail.archive.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zZvep5kvA-Vk; Wed, 24 Oct 2012 08:52:35 -0700 (PDT)
Received: from mikemac-2.local (208-90-212-115.PUBLIC.monkeybrains.net [208.90.212.115]) by mail.archive.org (Postfix) with ESMTPSA id BF9BD6840242; Wed, 24 Oct 2012 08:52:35 -0700 (PDT)
Message-ID: <50880EBD.5020108@archive.org>
Date: Wed, 24 Oct 2012 08:52:29 -0700
From: Mike McCabe 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20120927033703.3356.43186.idtracker@ietfa.amsl.com>  <255B9BB34FB7D647A506DC292726F6E114FD642E67@WSMSG3153V.srv.dir.telstra.com> <6B079501-EF09-4916-B559-123362A23413@mnot.net>
In-Reply-To: <6B079501-EF09-4916-B559-123362A23413@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] json-patch: "op":"tree"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Oct 2012 15:52:38 -0000

I also agree.  I don't think that this adds much utility - it would also 
mean a considerable departure from the existing flat 'op' structure.

Regards,
Mike



On 10/23/12 11:49 PM, Mark Nottingham wrote:
> This didn't make it into the last draft, and I'd like to get us to WGLC soon.
>
> Personally, I'm going to push back on it; it's a syntactic convenience at most, and I think that most JSON Patch documents will be generated by code. This format really needs to be as simple as possible, and IME a convenience function like this doesn't make the cut.
>
> However, that's just me.
>
> Do people adamantly-want-this, or is it just nice-to-have?
>
> What do the people actually implementing JSON Patch think?
>
> Cheers,
>
>
> On 01/10/2012, at 3:41 PM, "Manger, James H"  wrote:
>
>> RE: draft-ietf-appsawg-json-patch-05
>>
>> Suggestion: define a "tree" operation for grouping operations that apply to part of the JSON doc being changed. It avoids repeating a path prefix in lots of operations; it simplifies writing a patch that can be applied at different points; its easier to separate the patch for changing a value from where that value is in a larger JSO structure. New text:
>>
>>   4.7. tree
>>
>>     The "tree" operation applies other operations to a subset of
>>     the target. The operation object MUST include "path" and "ops"
>>     members. "path" holds a JSON pointer that identifies the value
>>     to which the other operations apply. "ops" holds an array of
>>     operation objects. JSON pointers within "ops" are relative
>>     to the value identified by "path".
>>
>>     Example:
>>     Old:   {"a":{"b":{"c":{"d":{"e":{"name":"Alice"}}}}}}
>>     Patch: [{"op":"tree", "path":"/a/b/c/d/e", "ops":[
>>               {"op":"add", "path":"/age", "value":20},
>>               {"op":"add", "path":"/email", "value":"a@eg.com"}]}]
>>     New:   {"a":{"b":{"c":{"d":{"e":{
>>             "name":"Alice", "age":20, "email":"a@eg.com"}}}}}}
>>
>> --
>> James Manger
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From masinter@adobe.com  Wed Oct 24 09:35:30 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D996921F8C4B for ; Wed, 24 Oct 2012 09:35:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.599
X-Spam-Level: 
X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 0+Q9whBoUicl for ; Wed, 24 Oct 2012 09:35:29 -0700 (PDT)
Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 0E66C21F8C15 for ; Wed, 24 Oct 2012 09:35:28 -0700 (PDT)
Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKUIgYsk4l+MaV3GHqdzaNDdRNncRugYaO@postini.com; Wed, 24 Oct 2012 09:35:29 PDT
Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q9OGWD1v028527; Wed, 24 Oct 2012 09:32:14 -0700 (PDT)
Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q9OGYYXe016170; Wed, 24 Oct 2012 09:34:55 -0700 (PDT)
Received: from SJ1SWM219.corp.adobe.com (10.5.77.61) by nacas03.corp.adobe.com (10.8.189.121) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 24 Oct 2012 09:34:34 -0700
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by SJ1SWM219.corp.adobe.com ([fe80::d55c:7209:7a34:fcf7%11]) with mapi; Wed, 24 Oct 2012 09:34:34 -0700
From: Larry Masinter 
To: Erik Wilde , "apps-discuss@ietf.org application-layer protocols" 
Date: Wed, 24 Oct 2012 09:34:31 -0700
Thread-Topic: [apps-discuss] how to use non-URI registered identifiers when URIs are needed (for RDF)
Thread-Index: Ac2niMFu0XgMSFbBT1ykd924Lq2ZiwKfFwxQ
Message-ID: 
References:  <2CC809E7-4468-43F8-9259-682782BEF117@emc.com>  <50768058.9040108@berkeley.edu>
In-Reply-To: <50768058.9040108@berkeley.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "johnarwe@us.ibm.com" 
Subject: Re: [apps-discuss] how to use non-URI registered identifiers when URIs are needed (for RDF)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Oct 2012 16:35:31 -0000

To turn a non-URI registered identifier into a URI when you need one, I'd s=
uggest=20
using RFC 3553=20

 IETF URN Sub-namespace for Registered Protocol Parameters
 http://tools.ietf.org/html/rfc3553


> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
]
> On Behalf Of Erik Wilde
> Sent: Thursday, October 11, 2012 1:16 AM
> To: apps-discuss@ietf.org application-layer protocols
> Cc: johnarwe@us.ibm.com
> Subject: [apps-discuss] how to use non-URI registered identifiers when UR=
Is are
> needed (for RDF)
>=20
> hello.
>=20
> i had an interesting discussion about how it is allowed to refer to
> registered link relation types, and since this may be of interest for
> other non-URI identifiers as well, i thought i raise this as a general
> question. the starting point was john arwe asking whether it would be ok
> to use URIs as link relation type identifiers, which is allowed by RFC
> 4287, but then neither allowed nor specifically disallowed by RFC 5988,
> which updates RFC 4287. john did a great job at digging through the
> history of this, and here is what he found:
>=20
> On 2012-10-09 10:34 , John Arwe wrote:
> > It may be that 5988 was attempting to incorporate some aspects of 4287
> > when 5988 took over and expanded the registry.
> > [1] lays out the equivalence and requires it.  Odd to expect people to
> > read Atom in a "superseding" RFC (quotes b/c I realize it's only the
> > registry that 5988 takes over and expands upon).
> > POWDER relies on it too, as recently as 2010 [2]
> > If I infer from the URI that [3] was an antecedent to 5988, it was
> > explicit in the past.  [4] also mentions it, but I infer from [5] that
> > it was dropped as a result of AnneVK's comment.  The TAG was also
> > batting this around in 2008 [6] and apparently affirming it (via POWDER
> > again) in  2012 [7].  RDFa also mentions/uses it.
> > [1] http://tools.ietf.org/html/rfc4287#section-4.2.7.2
> > [2] http://www.w3.org/2007/powder/powder-errata
> > [3] http://tools.ietf.org/id/draft-nottingham-http-link-header-02.xml
> > [4] http://tools.ietf.org/id/draft-nottingham-http-link-header-06.xml
> > [5] http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0547.ht=
ml
> > [6] http://www.w3.org/2008/10/02-tagmem-minutes
> > [7] http://lists.w3.org/Archives/Public/www-tag/2012Mar/0090.html
>=20
> the starting point is the question how RDF scenarios, requiring URIs as
> identifiers, could reuse concepts such as link relation types. in this
> specific example the concrete question is whether RFC 5988, since it
> does not mention URIs as being equivalent to simple string values,
> effectively disallows what RFC 4287 allowed. my guess is that this is
> the case, but maybe it would help to make this more explicit (maybe as
> an erratum to RFC 5988?).
>=20
> the bigger question then is: how is RDF supposed to refer to these
> registered values? is that just RDF's problem, being URI-centric when it
> comes to identifiers, or would it make sense to have some kind of best
> practice or method how registered values for the Internet or the Web,
> which very often are not URIs, and the requirement of RDF to have URIs
> as identifiers, can be sorted out.
>=20
> i am asking both for guidance about the specific question about RFC
> 4287, as well as for ideas (and maybe even existing experience or
> examples) how to bridge the gap between non-URI identifiers we might
> want to use in application layer protocols, and RDF's requirement to
> have URIs as identifiers.
>=20
> thanks and kind regards,
>=20
> dret.
>=20
> --
> erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
>             | UC Berkeley  -  School of Information (ISchool) |
>             | http://dret.net/netdret http://twitter.com/dret |
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From Michael.Jones@microsoft.com  Wed Oct 24 11:47:24 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C846021F84ED for ; Wed, 24 Oct 2012 11:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.071
X-Spam-Level: 
X-Spam-Status: No, score=-3.071 tagged_above=-999 required=5 tests=[AWL=-0.472, 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 TY+VpmGcGnhd for ; Wed, 24 Oct 2012 11:47:24 -0700 (PDT)
Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.31]) by ietfa.amsl.com (Postfix) with ESMTP id DB20B21F8472 for ; Wed, 24 Oct 2012 11:47:23 -0700 (PDT)
Received: from BL2FFO11FD003.protection.gbl (10.173.161.202) by BL2FFO11HUB035.protection.gbl (10.173.161.115) with Microsoft SMTP Server (TLS) id 15.0.545.8; Wed, 24 Oct 2012 18:47:16 +0000
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD003.mail.protection.outlook.com (10.173.160.103) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Wed, 24 Oct 2012 18:47:15 +0000
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Wed, 24 Oct 2012 18:46:46 +0000
From: Mike Jones 
To: "Murray S. Kucherawy" , IETF Apps Discuss 
Thread-Topic: [apps-discuss] Agenda deadline is today
Thread-Index: AQHNsfsh/ZJzTM0t5Uqf1rWW1V3AE5fIyd3w
Date: Wed, 24 Oct 2012 18:46:45 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436687B9FF@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.36]
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:(164054002)(377454001)(13464001)(52044001)(51856001)(8716001)(46102001)(2666001)(54316001)(4196001)(3846001)(16826001)(4396001)(20776001)(54356001)(53806001)(74502001)(47446002)(47776002)(50466001)(50986001)(74662001)(47976001)(31966008)(33656001)(44976002)(47736001)(1076001)(5343655001)(49866001)(48376001)(550184003)(16406001)(16696001)(316001)(3746001)(3556001); DIR:OUT; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0644578634
Subject: Re: [apps-discuss] Agenda deadline is today
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Oct 2012 18:47:24 -0000

I'd like to request time on the agenda on the topic of discovery.  Items I =
expect to have us discuss include:
  - Discovery when a .well-known document cannot be practically hosted in t=
he root of the domain for which discovery is being performed
  - Discovery when a port other than 443 is used
  - Identifying the remaining open issues for WebFinger (and a process for =
hopefully closing them in a timely manner)
  - Building consensus on how to finish our discovery work in a timely mann=
er

I'd think I can cover this in 20-25 minutes.

				Thanks,
				-- Mike

-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Murray S. Kucherawy
Sent: Wednesday, October 24, 2012 8:21 AM
To: IETF Apps Discuss
Subject: [apps-discuss] Agenda deadline is today

The deadline for submitting preliminary agendas for working group meetings =
is today.  If you would like to request a time slot for our meeting in Nove=
mber, please email appsawg-chairs@tools.ietf.org ASAP.
If you have already sent a request but haven't heard back yet, feel free to=
 send us a reminder.

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


From masinter@adobe.com  Wed Oct 24 19:42:50 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D8321F8231 for ; Wed, 24 Oct 2012 19:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.099
X-Spam-Level: 
X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=2.500, 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 LFgwvzogNVDv for ; Wed, 24 Oct 2012 19:42:49 -0700 (PDT)
Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id 60B1421F8200 for ; Wed, 24 Oct 2012 19:42:49 -0700 (PDT)
Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKUIinKKnedCswqIqsqt7nR5i6uGKcYQCJ@postini.com; Wed, 24 Oct 2012 19:42:49 PDT
Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q9P2e51v005595; Wed, 24 Oct 2012 19:40:05 -0700 (PDT)
Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q9P2gmNc000155; Wed, 24 Oct 2012 19:42:48 -0700 (PDT)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Wed, 24 Oct 2012 19:42:48 -0700
From: Larry Masinter 
To: Jan Algermissen , "apps-discuss@ietf.org application-layer protocols" 
Date: Wed, 24 Oct 2012 19:42:44 -0700
Thread-Topic: [apps-discuss] Media Type for HTML 'snippets'?
Thread-Index: Ac2m94m7U/thciyuRlyyGl4FcxrGjwLXhYfg
Message-ID: 
References: <8573713A-4AEC-4C63-8379-F2FDE9274BB6@mac.com>
In-Reply-To: <8573713A-4AEC-4C63-8379-F2FDE9274BB6@mac.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] Media Type for HTML 'snippets'?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Oct 2012 02:42:50 -0000

Content-type annotations are only advisory, in a world where receivers regu=
larly "sniff" the content and override the content-type label anyway.

Since you have an application which receives these snippits and processes t=
hem, and you don't want intermediaries or proxies to rewrite them, search t=
hem, or do any generic processing of the content,  perhaps "application/oct=
et-stream" would be appropriate. Or no content-type at all... who cares?

The new registration for text/html  http://www.iana.org/assignments/media-t=
ypes/text/html
points to the HTML5 spec;  snippets wrapped  
   
 would be proces=
sed fine, so "text/html" would be appropriate.

If you mean for the snippets to be processed as XML and not as HTML, consid=
er=20
(from http://tools.ietf.org/html/draft-lilley-xml-mediatypes-00 )=20
"text/xml-external-parsed-entity" (or "application/xml-external-parsed-enti=
ty") might do you.


> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
]
> On Behalf Of Jan Algermissen
> Sent: Wednesday, October 10, 2012 4:03 AM
> To: apps-discuss@ietf.org application-layer protocols
> Subject: [apps-discuss] Media Type for HTML 'snippets'?
>=20
> Hi,
>=20
> I am looking for an appropriate media type to use when serving HTML snipp=
ets
> that have a 
 as their root element.
>=20
> I feel that serving HTML document fragments has become such a common
> scenario, I think there must be some solution already. However - I cannot=
 find
> anything appropriate.
>=20
> The closest thing is likely Atom's type attribute:
> http://tools.ietf.org/html/rfc4287#section-3.1.1.3
>=20
> Can anyone provide a pointer or ideas?
>=20
> Or is it time probably time for application/xhtml-div+xml
>=20
> Jan
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From hsivonen@gmail.com  Thu Oct 25 00:21:03 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9847E21F9084 for ; Thu, 25 Oct 2012 00:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwuvmEtxpPlR for ; Thu, 25 Oct 2012 00:21:02 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 33F9D21F906A for ; Thu, 25 Oct 2012 00:21:01 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so1172327lam.31 for ; Thu, 25 Oct 2012 00:21:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Ww7lnTY/K0ToZm5dsITMT+6KTuzDQSyQ72AqdophRKQ=; b=yvapGOIf/ug3uFP3pXUN0wCqt/FCN4bdZArHfu34kERIoqD9xipHstz8ddNcHBNBca 2YoGbcnGsybJGL6eLXt8JA/cSJbegN6TKuxbbuB6TSRKaAvY+4QdwJvvdba1hBXKCZFw BQshpNzJVEbaqU11RewaG+R7mcnH9gGR7WbaF/56UY6zokeQYFh9JTM340vluRgTwfko 4P0F3UI3ipCiPHxCyXcI7r32DuHxBls88fHHil6+Q8TRBg0sFxzZ1logIewh8H6BtIvP ds0/L47BDeMeWHRjBe0e4uzWTi4uSmUqtWJes8XTsfNw5tO8q15bJyyMY6YKcMVQ3qXF kZfA==
MIME-Version: 1.0
Received: by 10.112.17.40 with SMTP id l8mr7215691lbd.58.1351149661098; Thu, 25 Oct 2012 00:21:01 -0700 (PDT)
Sender: hsivonen@gmail.com
Received: by 10.112.99.9 with HTTP; Thu, 25 Oct 2012 00:21:00 -0700 (PDT)
In-Reply-To: <4F4D581E.20503@gmx.de>
References:  <4F4D581E.20503@gmx.de>
Date: Thu, 25 Oct 2012 10:21:00 +0300
X-Google-Sender-Auth: 6AIfZ0zZVU8-McwAE8qtVeVlgRI
Message-ID: 
From: Henri Sivonen 
To: Julian Reschke 
Content-Type: text/plain; charset=UTF-8
Cc: Anne van Kesteren , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Feedback about "Update to MIME regarding Charset Parameter Handling in Textual Media Types"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Oct 2012 07:21:03 -0000

On Wed, Feb 29, 2012 at 12:41 AM, Julian Reschke  wrote:
> Also, I see that you would like us to sanction whatever algorithm the HTML5
> spec has come up with for handling text/html; potentially including content
> inspection and out-of-band information.
>
> I think out-of-band information is a non-starter; it just doesn't work for
> many environments, and breaks basic assumptions about message semantics; if
> you need to do that for text/html so be it, and label it a "willful
> violation", but by all means don't let this hack leak into new media type
> definitions.

text/html, text/css, text/plain, text/javascript and
application/javascript all use out of band information. Saying
otherwise would be denying reality and withholding relevant
information from developers who wish to write interoperable software.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

From hsivonen@gmail.com  Thu Oct 25 00:29:23 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F3F21F848F for ; Thu, 25 Oct 2012 00:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.827
X-Spam-Level: 
X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 uNOOz3ZjWL2e for ; Thu, 25 Oct 2012 00:29:22 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2884221F84E9 for ; Thu, 25 Oct 2012 00:29:21 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so1181690lam.31 for ; Thu, 25 Oct 2012 00:29:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=px69bZIkggR14O7phkHcjxixt815M4m1IWtg89uQwXk=; b=mkyIyah3yfqBCWwKf9faTX4kcCLPd12EX2wqIreAej9SD/sOJ3tXd6scQ/mzbaWyUM j6t4pohzp8DIjyMeaZv2V3KN8yFG8nkNSTXaM8d8gyqOq22iGoUpf11F3kVqMkxWIiTd Vj2lgTBMgXXu6INTo3vucKkrwGYqql5tlEv5j10B+jkcwcSakQvoZ8t+EJ1BReIoUhmS Y6b/pJURazhCasCSesb0CvmWn0IsJ1yYTn47Gnax3zedVfN1I2H5cmrhhuFxMsYw7CV5 MWThDTb793Dh8pNfi5IVHbAK/ZZ4vfPolZxenBWiCyH7NaW968RCoAxr8uNnmWZYxJ9B FRFA==
MIME-Version: 1.0
Received: by 10.152.104.77 with SMTP id gc13mr16542280lab.16.1351150161079; Thu, 25 Oct 2012 00:29:21 -0700 (PDT)
Sender: hsivonen@gmail.com
Received: by 10.112.99.9 with HTTP; Thu, 25 Oct 2012 00:29:20 -0700 (PDT)
In-Reply-To: <4F4D8ED0.1030800@it.aoyama.ac.jp>
References:  <4F4D581E.20503@gmx.de> <01OCJ7KAZHWG00ZUIL@mauve.mrochek.com> <4F4D8ED0.1030800@it.aoyama.ac.jp>
Date: Thu, 25 Oct 2012 10:29:20 +0300
X-Google-Sender-Auth: _GypXl3iqjcm3l6nPUgA5oXy1RY
Message-ID: 
From: Henri Sivonen 
To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Julian Reschke , Anne van Kesteren , Ned Freed , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Feedback about "Update to MIME regarding Charset Parameter Handling in Textual Media Types"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Oct 2012 07:29:23 -0000

On Wed, Feb 29, 2012 at 4:34 AM, "Martin J. D=C3=BCrst"
 wrote:
> Do we really, in this day and age, expect a new type to define an ASCII
> compatible encoding that's not UTF-8 as a default?

I hope not!

> If the MUST is some basic Mime requirement, then I don't see any reason t=
o
> repeat it here. If it's not, then I don't see why it couldn't be
> UTF-16(LE|BE) or some such.

Recently, I have again cleaned up a part of the mess made by people
who thought it was a good idea to allow UTF-16 to be used for
interchange. (See https://bugzilla.mozilla.org/show_bug.cgi?id=3D599320
Also, letting the BOM override HTTP could be seen as cleaning up the
UTF-16 mess.) The variants of UTF-16 are the only ASCII-incompatible
encodings left on the Web (see http://encoding.spec.whatwg.org/ ).
It=E2=80=99s really annoying to have to write special cases for them.
Especially when they have no good use compared to UTF-8.

For new formats, it makes the most sense to make them UTF-8 only. But
*at least*, please, ban UTF-16 for new formats.

--=20
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

From hsivonen@gmail.com  Thu Oct 25 03:34:23 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC90A21F8853 for ; Thu, 25 Oct 2012 03:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.675
X-Spam-Level: 
X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=-1.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, 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 bb3MK31pjn95 for ; Thu, 25 Oct 2012 03:34:23 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 96C0921F88E0 for ; Thu, 25 Oct 2012 03:34:22 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so1425090lam.31 for ; Thu, 25 Oct 2012 03:34:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6oKFzAqLw3nS3yrhJR7+3d2ypU0I2Y2lAIN2fkRu5l4=; b=RLv4gNZy6+od5OrLnxbc/zNL9vu9WpYDl9BDYOangM+0IULW0ktwSYnJe5/ORHN8AC znPcTQP7GVebtWN+MOeDGK2sW0Ed3bmPL8KWpUNjHrB9OvWzMnBT+hqwACUNJ6xlzqoa 2tseWVEXIgA5l5d7b5HzgSmrXtAGuuPuA/hYSGOx4HsHLH6EV2QA0wL6lxdfAToFBkvg djHEAMLHh8VcNLRA06yV2IkbDK0ldPx6dhJPFIywa+/valI/wN6ZP4U7Y44fFTigo+RN ymGb1tnrvDrQUfRtAyhTYHZKWlIXhCZ+jO/J3PR3A5V0ty2IGZN7iznp0kctH6WvPXuX izVw==
MIME-Version: 1.0
Received: by 10.152.104.115 with SMTP id gd19mr17311270lab.13.1351161261403; Thu, 25 Oct 2012 03:34:21 -0700 (PDT)
Sender: hsivonen@gmail.com
Received: by 10.112.99.9 with HTTP; Thu, 25 Oct 2012 03:34:21 -0700 (PDT)
In-Reply-To: 
References: <8573713A-4AEC-4C63-8379-F2FDE9274BB6@mac.com> 
Date: Thu, 25 Oct 2012 13:34:21 +0300
X-Google-Sender-Auth: 4qNliuopGqy3ue5zkYXv8IGm3vk
Message-ID: 
From: Henri Sivonen 
To: Larry Masinter 
Content-Type: text/plain; charset=UTF-8
Cc: "apps-discuss@ietf.org application-layer protocols" , Jan Algermissen 
Subject: Re: [apps-discuss] Media Type for HTML 'snippets'?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Oct 2012 10:34:23 -0000

On Wed, Oct 10, 2012 at 2:03 PM, Jan Algermissen
 wrote:
> I am looking for an appropriate media type to use when serving HTML snippets that have a 
 as their root element.

On Thu, Oct 25, 2012 at 5:42 AM, Larry Masinter  wrote:
> The new registration for text/html  http://www.iana.org/assignments/media-types/text/html
> points to the HTML5 spec;  snippets wrapped  
   
 would be processed fine, so "text/html" would be appropriate.

Parsing such as snippet as text/html results in a document with "html"
as its root element. (Parsing text/html *always* results in the root
being "html" regardless of the contents of the file.)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

From pbryan@anode.ca  Thu Oct 25 16:25:56 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5D421F856D for ; Thu, 25 Oct 2012 16:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 3-X2bU-z+kY2 for ; Thu, 25 Oct 2012 16:25:55 -0700 (PDT)
Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id B082421F84F2 for ; Thu, 25 Oct 2012 16:25:55 -0700 (PDT)
Received: from [10.126.22.51] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 6BAC86452; Thu, 25 Oct 2012 23:25:54 +0000 (UTC)
From: "Paul C. Bryan" 
To: Mark Nottingham 
In-Reply-To: 
References: <5086C026.7030908@skoegl.net> 
Content-Type: multipart/alternative; boundary="=-22Z+tvKYNSOH9B8Ad6b7"
Date: Thu, 25 Oct 2012 16:25:31 -0700
Message-ID: <1351207531.29744.17.camel@pbryan-wsl.internal.salesforce.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: Apps Discuss , Stefan =?ISO-8859-1?Q?K=F6gl?= 
Subject: Re: [apps-discuss] draft-ietf-appsawg-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, 25 Oct 2012 23:25:57 -0000

--=-22Z+tvKYNSOH9B8Ad6b7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

I agree. JSON specifies only strings as member names, so there is no
ambiguity when resolving within an object. This issue boils-down to the
difference between JSON objects and Python dictionaries.

To help answer your question, perhaps I could know more about the Python
JSON library you're using to serialize Python data structures. How will
it handle the case where a key is not a string?

Without knowing this, I would be inclined to fail on non-string keys,
because the data structure is not conforming to the JSON specification.

Paul

On Wed, 2012-10-24 at 16:02 +1100, Mark Nottingham wrote: 

> [forwarding to the WG]
> 
> Hi Stefan,
> 
> My .02 - this is really a question about JSON implementation, I think. JSON-Patch is designed to operate upon JSON documents (where this question doesn't come up), not upon Python data structures.
> 
> Cheers,
> 
> 
> On 24/10/2012, at 3:04 AM, Stefan Kögl  wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Dear Working Group,
> > 
> > I'm the maintainer of python-json-pointer [1], a Python implementation
> > of the json-pointer drafts.
> > 
> > In Python the natural representation of a JSON object is a dictionary.
> > One of the differences is that a Python dictionary can have keys of
> > different types. I could, for instance, define the following dictionary
> > 
> > {"1": "a", 1: "b"}
> > 
> > and try to resolve the pointer /1. I see several possible ways of
> > resolving such cases:
> > 
> > * Ignore any non-string key
> > * Fail on non-string keys
> > * Interpret both keys as equal and fail according to the following
> >  sentence of the current draft:
> >  " If a referenced member name is not unique in an object, the member
> >    that is referenced is not unique in an object, the member that is
> >    referenced is undefined, and evaluation fails (see below). "
> > 
> > I understand that this problem can not occur in "pure" JSON where keys
> > can only be strings, but I assume that also implementations in other
> > languages will face the same issue. What is the opinion of the working
> > group on this? Maybe it could be addressed in future drafts.
> > 
> > 
> > Best regards,
> > 
> > Stefan Kögl
> > 
> > 
> > [1] https://github.com/stefankoegl/python-json-pointer
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.11 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
> > 
> > iEYEARECAAYFAlCGwCUACgkQ638pvJMAJ9BbsQCfYeu9SVDSKE2Z6DBYUKaAl1/b
> > Z9gAoLRaMjzBgun8K8Wd3QEic0bYTxaC
> > =ttNc
> > -----END PGP SIGNATURE-----
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss




--=-22Z+tvKYNSOH9B8Ad6b7
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit




  
  


I agree. JSON specifies only strings as member names, so there is no ambiguity when resolving within an object. This issue boils-down to the difference between JSON objects and Python dictionaries.



To help answer your question, perhaps I could know more about the Python JSON library you're using to serialize Python data structures. How will it handle the case where a key is not a string?



Without knowing this, I would be inclined to fail on non-string keys, because the data structure is not conforming to the JSON specification.



Paul



On Wed, 2012-10-24 at 16:02 +1100, Mark Nottingham wrote: 



[forwarding to the WG]

Hi Stefan,

My .02 - this is really a question about JSON implementation, I think. JSON-Patch is designed to operate upon JSON documents (where this question doesn't come up), not upon Python data structures.

Cheers,


On 24/10/2012, at 3:04 AM, Stefan Kögl <stefan@skoegl.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dear Working Group,
> 
> I'm the maintainer of python-json-pointer [1], a Python implementation
> of the json-pointer drafts.
> 
> In Python the natural representation of a JSON object is a dictionary.
> One of the differences is that a Python dictionary can have keys of
> different types. I could, for instance, define the following dictionary
> 
> {"1": "a", 1: "b"}
> 
> and try to resolve the pointer /1. I see several possible ways of
> resolving such cases:
> 
> * Ignore any non-string key
> * Fail on non-string keys
> * Interpret both keys as equal and fail according to the following
>  sentence of the current draft:
>  " If a referenced member name is not unique in an object, the member
>    that is referenced is not unique in an object, the member that is
>    referenced is undefined, and evaluation fails (see below). "
> 
> I understand that this problem can not occur in "pure" JSON where keys
> can only be strings, but I assume that also implementations in other
> languages will face the same issue. What is the opinion of the working
> group on this? Maybe it could be addressed in future drafts.
> 
> 
> Best regards,
> 
> Stefan Kögl
> 
> 
> [1] https://github.com/stefankoegl/python-json-pointer
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
> 
> iEYEARECAAYFAlCGwCUACgkQ638pvJMAJ9BbsQCfYeu9SVDSKE2Z6DBYUKaAl1/b
> Z9gAoLRaMjzBgun8K8Wd3QEic0bYTxaC
> =ttNc
> -----END PGP SIGNATURE-----

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



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











--=-22Z+tvKYNSOH9B8Ad6b7--


From melvincarvalho@gmail.com  Sat Oct 27 09:31:20 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D52921F8553 for ; Sat, 27 Oct 2012 09:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.34
X-Spam-Level: 
X-Spam-Status: No, score=-3.34 tagged_above=-999 required=5 tests=[AWL=0.258,  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 EUrxWIxEM+Xz for ; Sat, 27 Oct 2012 09:31:19 -0700 (PDT)
Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25CA621F84FC for ; Sat, 27 Oct 2012 09:31:19 -0700 (PDT)
Received: by mail-ia0-f172.google.com with SMTP id x24so1124885iak.31 for ; Sat, 27 Oct 2012 09:31:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gl37w9r/VKhLzavEwHkMB22aih0U7ekTGXFOqKDBqUs=; b=ew3KScgUTvTnIzutmjYS1v+Z1XM0dhvU9hdLIYxKe9JfeKiontxkDgwwqwVwKoMev2 /C88mQlYyy3m4lGTIh3Ka/dhIXODf6tKLJN+9a5fs45jc9yO3u5H69f9zovaAZLuvM3B ZSB6O9a9uCwNTCMI/9j8x9PkYvy+2Janlk4lgvk4Qyhv7e/+Q+6fSD0tFoQCtW7yfksb e6+djBUFB1YP0KeWSjVGL5sfAaosV5aOMhmTjXXEavDZJVeU4C6D/zm5dLNdm2v8E0jk qL8JeJIDtIN/ctIVvsOLezHhQGH56wy6+0bT/b3LDUx37hp9h9+JNkpkGtDyhbIdilPx NL7g==
MIME-Version: 1.0
Received: by 10.50.242.74 with SMTP id wo10mr5277418igc.51.1351355478699; Sat, 27 Oct 2012 09:31:18 -0700 (PDT)
Received: by 10.42.247.129 with HTTP; Sat, 27 Oct 2012 09:31:18 -0700 (PDT)
In-Reply-To: 
References: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com> <5082C526.3050100@status.net> <00c501cdaf13$13ef6d30$3bce4790$@packetizer.com> <20121021093728.590d2898@bogo>  
Date: Sat, 27 Oct 2012 18:31:18 +0200
Message-ID: 
From: Melvin Carvalho 
To: webfinger@googlegroups.com
Content-Type: multipart/alternative; boundary=f46d044787d345ed6c04cd0cf720
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-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: Sat, 27 Oct 2012 16:31:20 -0000

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

On 22 October 2012 10:49, Blaine Cook  wrote:

> Preamble: This spec looks absolutely nothing like I imagined
> Webfinger, which was, and was meant to be, a light-weight and simple
> method to look up resource data for an email address. I'm not happy
> with this *at all*, and probably won't implement it, either client or
> server. I've achieved the login handling using a much simpler (but
> less powerful and intentful) heuristic that I'll talk about soon.
>
> 1. +1 on CORS support.
>
> 2. Since I appear to have fully and completely lost the argument on
> structuring Webfinger like DNS (despite the many positive reactions
> outside this list I've received regarding the alternate proposal), two
> proposals:
>
> 2a. Drop the template URI stuff.
> 2b. Have only one method for following redirects. If the participants
> in this process think that it's OK to require static hosts to use HTTP
> semantics (30x) to redirect /.well-known/host-meta, then use that
> everywhere, since the hard place to do that is for static hosts =E2=80=93
> anyone responding dynamically requests can trivially issue HTTP
> redirects, rather than generating JSON.
>
> Some notes on redirects:
>
> =E2=80=93 The redirect code MUST NOT be 301. This would make it impossibl=
e
> under some circumstances for the host to regain control over lookups,
> and is *never* the correct behaviour from a normative standpoint
> (where the behaviour being enabled is like DNS =E2=80=93 you can *never*
> permanently redirect a DNS lookup).
> =E2=80=93 Clients MUST treat 301 response codes as 307.
> =E2=80=93 The redirect code SHOULD be 307, and the server SHOULD use
> appropriate HTTP caching semantics.
>
> Note that we are actually getting *worse* performance characteristics
> out of this scheme for hosts using 3rd party webfinger providers,
> since each request to a different user results in two requests; one to
> the base domain, and one to the 3rd party server.
>
> Drop all the redirect JRD stuff.
>

I've been thinking about this a fair bit.

Webfinger is now in its fourth year and one thing that has remained
constant is that it would be valuable on the internet to perform discovery
on an email address to get more information such as blog address, homepage
etc.

I thought we had a consensus to use JRD and drop everything else.  I
strongly think this should be the stance of the spec.  There is one
interesting aspect to this.  JRD has an advantage over XRD in that you can
have more than one subject per document, whereas in XRD you would be in
(willful) violation of the XML Schema.  It turns out that this pretty much
makes both XRD and RDF equivalents modulo a regular expression.  That is
quite exciting and brings two worlds and big ecosystems together.

Regarding XRD and content negotiation.  If you want XRD you should request
it in the header.

Regarding the default serialization.  There's one important aspect here.
That is that browsers have no way of setting a content type.  So the any
default should be browser friendly if specified.  As far as I can see that
leaves RDFa or schema.org etc. as the stand out choices.  I dont think it's
necessary to specify a default in this version of the spec.

It's worth noting that the problem to be solved, ie to query a data
document to some results is solved both in the specific and general case,
using a query language such as SPARQL.  I suspect the argument for not
using SPARQL here is that it may be overkill for the use case required.
Therefore you build a query structure into the spec as a kind of
simplification.  But if you want to simplify the general case, perhaps SWD
is the best candidate we've seen, or some tweak of that.

Regarding having any URI as the input, this is an example of good
engineering.  However, is it really practical?  Does the spec show how to
find a well known location for *any* URI, or just a subset?  What about
sip: xmpp: tel: etc.  In particular I think tel: would break the spec, as
would many other URIs (essentially the non DNS based ones).

That also leads to the thorny issue of http: ... do we really want yet
another way to dereference an HTTP URI other than GET?   What about
response codes, sync of data, attack surfaces?

On the whole I think paul has done a great job in difficult circumstances,
with lots of requests, from all angles.  I hope we can come to a consensus
soon and solve the core use case of discovering information on an email
address at web scale.


>
> Hope that's helpful.
>
> b.
>
> On 21 October 2012 05:13, Melvin Carvalho 
> wrote:
> >
> >
> > On 21 October 2012 09:37, Christian Weiske  wrote:
> >>
> >> Hello Paul,
> >>
> >>
> >> >> *    Section 7 makes support for CORS a MUST and then turns
> >> >> around and said if you have a good reason not to support it, you
> >> >> SHOULD NOT. I suggest that support for CORS should just be a SHOULD=
.
> >> >> I can figure out myself whether I want to be the exception.
> >> > PEJ: You're entirely right about that and that text bugged me, too.
> >> > There was a strong desire for CORS to the point I was asked to make
> >> > it a MUST, yet there was the desire to allow an enterprise do
> >> > something more restrictive. I have no strong preference, myself, but
> >> > I do think that if we make it a SHOULD, though, that it will make it
> >> > impossible to build a client in a browser.  What does the group want
> >> > here?
> >>
> >> Not supporting CORS does not make the data any more secure. If someone
> >> wants security for their intranet, they have to implement real securit=
y
> >> measurements, e.g. based on IP whitelists.
> >>
> >> Please leave CORS support a MUST.
> >
> >
> > +1
> >>
> >>
> >> --
> >> Regards/Mit freundlichen Gr=C3=BC=C3=9Fen
> >> Christian Weiske
> >>
> >> -=3D=E2=89=A1 Geeking around in the name of science since 1982 =E2=89=
=A1=3D-
> >
> >
>

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



On 22 October 2012 10:49, Blaine Cook <r=
omeda@gmail.com> wrote:

Preamble: This spec looks absolutely nothing like I imagined

Webfinger, which was, and was meant to be, a light-weight and simple

method to look up resource data for an email address. I'm not happy

with this *at all*, and probably won't implement it, either client or
server. I've achieved the login handling using a much simpler (but

less powerful and intentful) heuristic that I'll talk about soon.



1. +1 on CORS support.



2. Since I appear to have fully and completely lost the argument on

structuring Webfinger like DNS (despite the many positive reactions

outside this list I've received regarding the alternate proposal), two<=
br>
proposals:



2a. Drop the template URI stuff.

2b. Have only one method for following redirects. If the participants

in this process think that it's OK to require static hosts to use HTTP<=
br>
semantics (30x) to redirect /.well-known/host-meta, then use that

everywhere, since the hard place to do that is for static hosts =E2=80=93
anyone responding dynamically requests can trivially issue HTTP

redirects, rather than generating JSON.



Some notes on redirects:



=E2=80=93=C2=A0The redirect code MUST NOT be 301. This would make it imposs=
ible

under some circumstances for the host to regain control over lookups,

and is *never* the correct behaviour from a normative standpoint

(where the behaviour being enabled is like DNS =E2=80=93=C2=A0you can *neve=
r*

permanently redirect a DNS lookup).

=E2=80=93=C2=A0Clients MUST treat 301 response codes as 307.

=E2=80=93=C2=A0The redirect code SHOULD be 307, and the server SHOULD use
appropriate HTTP caching semantics.



Note that we are actually getting *worse* performance characteristics

out of this scheme for hosts using 3rd party webfinger providers,

since each request to a different user results in two requests; one to

the base domain, and one to the 3rd party server.



Drop all the redirect JRD stuff.

I've been thi=
nking about this a fair bit.=C2=A0 

Webfinger is now in its fourth y=
ear and one thing that has remained constant is that it would be valuable o=
n the internet to perform discovery on an email address to get more informa=
tion such as blog address, homepage etc.


I thought we had a consensus to use JRD and drop everything else.=C2=A0=
 I strongly think this should be the stance of the spec.=C2=A0 There is one=
 interesting aspect to this.=C2=A0 JRD has an advantage over XRD in that yo=
u can have more than one subject per document, whereas in XRD you would be =
in (willful) violation of the XML Schema.=C2=A0 It turns out that this pret=
ty much makes both XRD and RDF equivalents modulo a regular expression.=C2=
=A0 That is quite exciting and brings two worlds and big ecosystems togethe=
r.


Regarding XRD and content negotiation.=C2=A0 If you want XRD you should=
 request it in the header.=C2=A0 

Regarding the default serializatio=
n.=C2=A0 There's one important aspect here.=C2=A0 That is that browsers=
 have no way of setting a content type.=C2=A0 So the any default should be =
browser friendly if specified.=C2=A0 As far as I can see that leaves RDFa o=
r schema.org etc. as the stand out choice=
s.=C2=A0 I dont think it's necessary to specify a default in this versi=
on of the spec.


It's worth noting that the problem to be solved, ie to query a data=
 document to some results is solved both in the specific and general case, =
using a query language such as SPARQL.=C2=A0 I suspect the argument for not=
 using SPARQL here is that it may be overkill for the use case required.=C2=
=A0 Therefore you build a query structure into the spec as a kind of simpli=
fication.=C2=A0 But if you want to simplify the general case, perhaps SWD i=
s the best candidate we've seen, or some tweak of that.


Regarding having any URI as the input, this is an example of good engin=
eering.=C2=A0 However, is it really practical?=C2=A0 Does the spec show how=
 to find a well known location for *any* URI, or just a subset?=C2=A0 What =
about sip: xmpp: tel: etc.=C2=A0 In particular I think tel: would break the=
 spec, as would many other URIs (essentially the non DNS based ones).=C2=A0=
 


That also leads to the thorny issue of http: ... do we really want yet =
another way to dereference an HTTP URI other than GET?=C2=A0=C2=A0 What abo=
ut response codes, sync of data, attack surfaces?=C2=A0 

On the whol=
e I think paul has done a great job in difficult circumstances, with lots o=
f requests, from all angles.=C2=A0 I hope we can come to a consensus soon a=
nd solve the core use case of discovering information on an email address a=
t web scale.

=C2=A0



Hope that's helpful.



b.




On 21 October 2012 05:13, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

>

>

> On 21 October 2012 09:37, Christian Weiske <cweiske@cweiske.de> wrote:

>>

>> Hello Paul,

>>

>>

>> >> * =C2=A0 =C2=A0Section 7 makes support for CORS a MUST an=
d then turns

>> >> around and said if you have a good reason not to support =
it, you

>> >> SHOULD NOT. I suggest that support for CORS should just b=
e a SHOULD.

>> >> I can figure out myself whether I want to be the exceptio=
n.

>> > PEJ: You're entirely right about that and that text bugge=
d me, too.

>> > There was a strong desire for CORS to the point I was asked t=
o make

>> > it a MUST, yet there was the desire to allow an enterprise do=


>> > something more restrictive. I have no strong preference, myse=
lf, but

>> > I do think that if we make it a SHOULD, though, that it will =
make it

>> > impossible to build a client in a browser. =C2=A0What does th=
e group want

>> > here?

>>

>> Not supporting CORS does not make the data any more secure. If som=
eone

>> wants security for their intranet, they have to implement real sec=
urity

>> measurements, e.g. based on IP whitelists.

>>

>> Please leave CORS support a MUST.

>

>

> +1

>>

>>

>> --

>> Regards/Mit freundlichen Gr=C3=BC=C3=9Fen

>> Christian Weiske

>>

>> -=3D=E2=89=A1 Geeking around in the name of science since 1982 =E2=
=89=A1=3D-

>

>





--f46d044787d345ed6c04cd0cf720--

From paul.hoffman@vpnc.org  Sat Oct 27 09:44:00 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180E421F84BF for ; Sat, 27 Oct 2012 09:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 W19GYcHa8UVE for ; Sat, 27 Oct 2012 09:43:59 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE6321F84B0 for ; Sat, 27 Oct 2012 09:43:59 -0700 (PDT)
Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9RGhvxV060448 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 27 Oct 2012 09:43:58 -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: <9EAB966B-4B21-4CF9-BFEB-4DAD639FE81C@vpnc.org>
Date: Sat, 27 Oct 2012 09:43:59 -0700
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] Solving the file format problem
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Oct 2012 16:44:00 -0000

There are many people on this list that care a lot about Internet =
applications but are not active in IETF protocol work who might be =
wondering how they can help. If you are such a person (or you are active =
in the IETF *and* you care about the problem of having a zillion file =
formats), maybe take a look at . This =
is a one-month sprint to add to the catalog of formats from the past and =
present and document or create conversion programs that will allow =
someone holding an item that is in a "dead" format to retrieve the =
useful data from it. A recent blog post from the organizer is here: =
. There are lots of =
opportunities for people on all levels of ability.

To be clear, the effort is about formats that are in stored files, not =
on-the-wire protocols. Although the latter is the focus of the IETF =
Applications Area, the former was important to us not that many decades =
ago.

--Paul Hoffman=

From wmills@yahoo-inc.com  Sat Oct 27 18:11:23 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6571821F8650 for ; Sat, 27 Oct 2012 18:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.998
X-Spam-Level: 
X-Spam-Status: No, score=-14.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 OAq2wwG6zsz6 for ; Sat, 27 Oct 2012 18:11:22 -0700 (PDT)
Received: from nm31-vm6.bullet.mail.ne1.yahoo.com (nm31-vm6.bullet.mail.ne1.yahoo.com [98.138.229.46]) by ietfa.amsl.com (Postfix) with ESMTP id A2D4221F8645 for ; Sat, 27 Oct 2012 18:11:21 -0700 (PDT)
Received: from [98.138.90.49] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 28 Oct 2012 01:11:15 -0000
Received: from [98.138.87.5] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 28 Oct 2012 01:11:15 -0000
Received: from [127.0.0.1] by omp1005.mail.ne1.yahoo.com with NNFMP; 28 Oct 2012 01:11:15 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 446502.93523.bm@omp1005.mail.ne1.yahoo.com
Received: (qmail 96449 invoked by uid 60001); 28 Oct 2012 01:11:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1351386674; bh=lPJyiab7dexbcFI86RJ8RKc8BBvj8G31ZW0ytbloHGE=; 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=K9OWD6wzq9hTlYZlYD4mpbkSvCU/aT5deqgHkewPxfo5L38hz1nsirbz+5w56nG0di5QseY2EFr/dgg/mf+f9lQRF2C7f1w+8JR+TMNV/jdyXKCXgy40+WcsaDmRIAromB2vmYsF17LmBhvmjyR52SbSOaowSqbFQ447hqPTGWk=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.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=cr40l+QOHaYJkP7IDDwUKA+3t8+jl+h5WxM4k0BRJqH3XMIwML+ndMxcKvA8kV95qeyQqgBkbDRX5M+z2LryGqeGvFFxZdLpfkaq15npKgJhK14owxr4fI/gkR2rbzHnCokyR8QgjVRns4Cjk55NR14Y4r4Xouu8LcQKCT5UZSg=;
X-YMail-OSG: qQ18ib4VM1mfjVctPSH.pDhLASso7l8L3Lw_ryJkloqO.qY tWw7YXmrLu4.blmNlfxi_GqyubbkBJ3TgzPG7HMCMZPf9cLqyzhipEJp8IEA FVhWYVzawA1dbaME_.2dCsWAm6ajWYNPuVuQ3omJv.Z.CNyOW2XwNgvMlQ_p s9NDRUmw46MDdFQYO5b8vN1NXPpv67ZF6YJefYmw94naB2jXEbtL_15q_N7L nR2Hjo6uhis6jCwWLtybzBJtdxJjX0RB7dnqXZYqugF9p3UjbXXQTfdZEyc0 VuwvTykpCRrQyZFDGOI584EjLIofoeztViQSaidzkrAoaSGNIiSOE_nQM9jh g3hp5hjYpY0xpiI4yd.UXF5YqMASkA.VoL342dtSYVv36rofgiplw0WJXeQU fYVBo6_gmrm14.c6YOclxMalwFfSRGdqbTnkVWgLNcXzTkZmQQkBuv5sRr4Y X1Xfjf7SvcgxXJHXjd9_IIGOQZOze6KUfZQ9ucPpuS7qcYGYckYWSApQIqJR wnKngig--
Received: from [99.31.212.42] by web31804.mail.mud.yahoo.com via HTTP; Sat, 27 Oct 2012 18:11:14 PDT
X-Rocket-MIMEInfo: 001.001, VmFyaW91cyBwZW9wbGUgaGF2ZSBzYWlkICJqdXN0IGdvIHdpdGggSlJELCBpdCdzIHNvIG11Y2ggYmV0dGVyIHRoYW4gWFJEIiwgYnV0IHRoaXMgc3BlYyBpcyBzdGlsbCB0cnlpbmcgdG8gc3RpcmtlIGEgYmFsYW5jZSBoZXJlIHNpbmNlIHRoZXJlIGlzIGFscmVhZHkgYW5kIGluc3RhbGxlZCBiYXNlIHVuZGVyIHRoZSBjdXJyZW50IFdGIFhSRCBhcyBNVEkgc3BlYy7CoCBUaGVyZSBoYXMgYmVlbiB1bmRlcnN0YW5kYWJsZSByZXRpY2VuY2UgdG8gZGVjbGFyaW5nIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyABMAEBAQE-
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.123.460
References: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com> <5082C526.3050100@status.net> <00c501cdaf13$13ef6d30$3bce4790$@packetizer.com> <20121021093728.590d2898@bogo>   
Message-ID: <1351386674.45982.YahooMailNeo@web31804.mail.mud.yahoo.com>
Date: Sat, 27 Oct 2012 18:11:14 -0700 (PDT)
From: William Mills 
To: Melvin Carvalho , "webfinger@googlegroups.com" 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="835683298-892432109-1351386674=:45982"
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-01
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: Sun, 28 Oct 2012 01:11:23 -0000

--835683298-892432109-1351386674=:45982
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Various people have said "just go with JRD, it's so much better than XRD", =
but this spec is still trying to stirke a balance here since there is alrea=
dy and installed base under the current WF XRD as MTI spec.=C2=A0 There has=
 been understandable reticence to declaring existing implementations to be =
no longer compliant with the spec.=C2=A0 I am strongly opposed to morphing =
WF into something that does that.=0A=0AI am *highly* in favor of simplicity=
, and I think we're moving to a more complex thing that will make the trivi=
al case more work to support.=0A=0A-bill=0A=0A=0A=0A=0A=0A>________________=
________________=0A> From: Melvin Carvalho =0A>To=
: webfinger@googlegroups.com =0A>Cc: apps-discuss@ietf.org =0A>Sent: Saturd=
ay, October 27, 2012 9:31 AM=0A>Subject: Re: [apps-discuss] WebFinger Draft=
 Updated - draft-ietf-appsawg-webfinger-01=0A> =0A>=0A>=0A>=0A>=0A>On 22 Oc=
tober 2012 10:49, Blaine Cook  wrote:=0A>=0A>Preamble: Th=
is spec looks absolutely nothing like I imagined=0A>>Webfinger, which was, =
and was meant to be, a light-weight and simple=0A>>method to look up resour=
ce data for an email address. I'm not happy=0A>>with this *at all*, and pro=
bably won't implement it, either client or=0A>>server. I've achieved the lo=
gin handling using a much simpler (but=0A>>less powerful and intentful) heu=
ristic that I'll talk about soon.=0A>>=0A>>1. +1 on CORS support.=0A>>=0A>>=
2. Since I appear to have fully and completely lost the argument on=0A>>str=
ucturing Webfinger like DNS (despite the many positive reactions=0A>>outsid=
e this list I've received regarding the alternate proposal), two=0A>>propos=
als:=0A>>=0A>>2a. Drop the template URI stuff.=0A>>2b. Have only one method=
 for following redirects. If the participants=0A>>in this process think tha=
t it's OK to require static hosts to use HTTP=0A>>semantics (30x) to redire=
ct /.well-known/host-meta, then use that=0A>>everywhere, since the hard pla=
ce to do that is for static hosts =E2=80=93=0A>>anyone responding dynamical=
ly requests can trivially issue HTTP=0A>>redirects, rather than generating =
JSON.=0A>>=0A>>Some notes on redirects:=0A>>=0A>>=E2=80=93=C2=A0The redirec=
t code MUST NOT be 301. This would make it impossible=0A>>under some circum=
stances for the host to regain control over lookups,=0A>>and is *never* the=
 correct behaviour from a normative standpoint=0A>>(where the behaviour bei=
ng enabled is like DNS =E2=80=93=C2=A0you can *never*=0A>>permanently redir=
ect a DNS lookup).=0A>>=E2=80=93=C2=A0Clients MUST treat 301 response codes=
 as 307.=0A>>=E2=80=93=C2=A0The redirect code SHOULD be 307, and the server=
 SHOULD use=0A>>appropriate HTTP caching semantics.=0A>>=0A>>Note that we a=
re actually getting *worse* performance characteristics=0A>>out of this sch=
eme for hosts using 3rd party webfinger providers,=0A>>since each request t=
o a different user results in two requests; one to=0A>>the base domain, and=
 one to the 3rd party server.=0A>>=0A>>Drop all the redirect JRD stuff.=0A>=
>=0A>=0A>I've been thinking about this a fair bit.=C2=A0 =0A>=0A>Webfinger =
is now in its fourth year and one thing that has remained constant is that =
it would be valuable on the internet to perform discovery on an email addre=
ss to get more information such as blog address, homepage etc.=0A>=0A>I tho=
ught we had a consensus to use JRD and drop everything else.=C2=A0 I strong=
ly think this should be the stance of the spec.=C2=A0 There is one interest=
ing aspect to this.=C2=A0 JRD has an advantage over XRD in that you can hav=
e more than one subject per document, whereas in XRD you would be in (willf=
ul) violation of the XML Schema.=C2=A0 It turns out that this pretty much m=
akes both XRD and RDF equivalents modulo a regular expression.=C2=A0 That i=
s quite exciting and brings two worlds and big ecosystems together.=0A>=0A>=
Regarding XRD and content negotiation.=C2=A0 If you want XRD you should req=
uest it in the header.=C2=A0 =0A>=0A>Regarding the default serialization.=
=C2=A0 There's one important aspect here.=C2=A0 That is that browsers have =
no way of setting a content type.=C2=A0 So the any default should be browse=
r friendly if specified.=C2=A0 As far as I can see that leaves RDFa or sche=
ma.org etc. as the stand out choices.=C2=A0 I dont think it's necessary to =
specify a default in this version of the spec.=0A>=0A>It's worth noting tha=
t the problem to be solved, ie to query a data document to some results is =
solved both in the specific and general case, using a query language such a=
s SPARQL.=C2=A0 I suspect the argument for not using SPARQL here is that it=
 may be overkill for the use case required.=C2=A0 Therefore you build a que=
ry structure into the spec as a kind of simplification.=C2=A0 But if you wa=
nt to simplify the general case, perhaps SWD is the best candidate we've se=
en, or some tweak of that.=0A>=0A>Regarding having any URI as the input, th=
is is an example of good engineering.=C2=A0 However, is it really practical=
?=C2=A0 Does the spec show how to find a well known location for *any* URI,=
 or just a subset?=C2=A0 What about sip: xmpp: tel: etc.=C2=A0 In particula=
r I think tel: would break the spec, as would many other URIs (essentially =
the non DNS based ones).=C2=A0 =0A>=0A>That also leads to the thorny issue =
of http: ... do we really want yet another way to dereference an HTTP URI o=
ther than GET?=C2=A0=C2=A0 What about response codes, sync of data, attack =
surfaces?=C2=A0 =0A>=0A>On the whole I think paul has done a great job in d=
ifficult circumstances, with lots of requests, from all angles.=C2=A0 I hop=
e we can come to a consensus soon and solve the core use case of discoverin=
g information on an email address at web scale.=0A>=C2=A0=0A>=0A>>Hope that=
's helpful.=0A>>=0A>>b.=0A>>=0A>>=0A>>On 21 October 2012 05:13, Melvin Carv=
alho  wrote:=0A>>>=0A>>>=0A>>> On 21 October 2012=
 09:37, Christian Weiske  wrote:=0A>>>>=0A>>>> Hello Pa=
ul,=0A>>>>=0A>>>>=0A>>>> >> * =C2=A0 =C2=A0Section 7 makes support for CORS=
 a MUST and then turns=0A>>>> >> around and said if you have a good reason =
not to support it, you=0A>>>> >> SHOULD NOT. I suggest that support for COR=
S should just be a SHOULD.=0A>>>> >> I can figure out myself whether I want=
 to be the exception.=0A>>>> > PEJ: You're entirely right about that and th=
at text bugged me, too.=0A>>>> > There was a strong desire for CORS to the =
point I was asked to make=0A>>>> > it a MUST, yet there was the desire to a=
llow an enterprise do=0A>>>> > something more restrictive. I have no strong=
 preference, myself, but=0A>>>> > I do think that if we make it a SHOULD, t=
hough, that it will make it=0A>>>> > impossible to build a client in a brow=
ser. =C2=A0What does the group want=0A>>>> > here?=0A>>>>=0A>>>> Not suppor=
ting CORS does not make the data any more secure. If someone=0A>>>> wants s=
ecurity for their intranet, they have to implement real security=0A>>>> mea=
surements, e.g. based on IP whitelists.=0A>>>>=0A>>>> Please leave CORS sup=
port a MUST.=0A>>>=0A>>>=0A>>> +1=0A>>>>=0A>>>>=0A>>>> --=0A>>>> Regards/Mi=
t freundlichen Gr=C3=BC=C3=9Fen=0A>>>> Christian Weiske=0A>>>>=0A>>>> -=3D=
=E2=89=A1 Geeking around in the name of science since 1982 =E2=89=A1=3D-=0A=
>>>=0A>>>=0A>>=0A>=0A>_______________________________________________=0A>ap=
ps-discuss mailing list=0A>apps-discuss@ietf.org=0A>https://www.ietf.org/ma=
ilman/listinfo/apps-discuss=0A>=0A>=0A>
--835683298-892432109-1351386674=:45982
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Various p=
eople have said "just go with JRD, it's so much better than XRD", but this =
spec is still trying to stirke a balance here since there is already and in=
stalled base under the current WF XRD as MTI spec.  There has been und=
erstandable reticence to declaring existing implementations to be no longer=
 compliant with the spec.  I am strongly opposed to morphing WF into s=
omething that does that.

I am *highly* in favor of simplicity, and I=
 think we're moving to a more complex thing that will make the trivial case=
 more work to support.

-bill

  
 
 
  
 =
 From: Melvin Carvalho <=
melvincarvalho@gmail.com>
 To:<=
/span> webfinger@googlegroups.com 
Cc: apps-discuss@ietf.org 
 Sent: Saturday, October 27, 2012 9:31 AM
 Subject: Re: [apps-discuss] WebFing=
er Draft Updated - draft-ietf-appsawg-webfinger-01
  
 
<=
div id=3D"yiv1449688581">

On=
 22 October 2012 10:49, Blaine Cook <romeda@gmail.com> wrote:
=
=0APreamble: This spec looks absolutely nothing like I imagined
=0AWebfi=
nger, which was, and was meant to be, a light-weight and simple
=0Ametho=
d to look up resource data for an email address. I'm not happy
=0Awith t=
his *at all*, and probably won't implement it, either client or
=0Aserve=
r. I've achieved the login handling using a much simpler (but
=0Aless po=
werful and intentful) heuristic that I'll talk about soon.
=0A
=0A1. =
+1 on CORS support.
=0A
=0A2. Since I appear to have fully and comple=
tely lost the argument on
=0Astructuring Webfinger like DNS (despite the=
 many positive reactions
=0Aoutside this list I've received regarding th=
e alternate proposal), two
=0Aproposals:
=0A
=0A2a. Drop the templ=
ate URI stuff.
=0A2b. Have only one method for following redirects. If t=
he participants
=0Ain this process think that it's OK to require static =
hosts to use HTTP
=0Asemantics (30x) to redirect /.well-known/host-meta,=
 then use that
=0Aeverywhere, since the hard place to do that is for sta=
tic hosts =E2=80=93
=0Aanyone responding dynamically requests can trivia=
lly issue HTTP
=0Aredirects, rather than generating JSON.
=0A
=0AS=
ome notes on redirects:
=0A
=0A=E2=80=93 The redirect code MUST =
NOT be 301. This would make it impossible
=0Aunder some circumstances fo=
r the host to regain control over lookups,
=0Aand is *never* the correct=
 behaviour from a normative standpoint
=0A(where the behaviour being ena=
bled is like DNS =E2=80=93 you can *never*
=0Apermanently redirect =
a DNS lookup).
=0A=E2=80=93 Clients MUST treat 301 response codes a=
s 307.
=0A=E2=80=93 The redirect code SHOULD be 307, and the server=
 SHOULD use
=0Aappropriate HTTP caching semantics.
=0A
=0ANote tha=
t we are actually getting *worse* performance characteristics
=0Aout of =
this scheme for hosts using 3rd party webfinger providers,
=0Asince each=
 request to a different user results in two requests; one to
=0Athe base=
 domain, and one to the 3rd party server.
=0A
=0ADrop all the redirec=
t JRD stuff.

I've been thinking about this a fair =
bit.  

Webfinger is now in its fourth year and one thing that h=
as remained constant is that it would be valuable on the internet to perfor=
m discovery on an email address to get more information such as blog addres=
s, homepage etc.
=0A
I thought we had a consensus to use JRD and drop=
 everything else.  I strongly think this should be the stance of the s=
pec.  There is one interesting aspect to this.  JRD has an advant=
age over XRD in that you can have more than one subject per document, where=
as in XRD you would be in (willful) violation of the XML Schema.  It t=
urns out that this pretty much makes both XRD and RDF equivalents modulo a =
regular expression.  That is quite exciting and brings two worlds and =
big ecosystems together.
=0A
Regarding XRD and content negotiation.&n=
bsp; If you want XRD you should request it in the header.  

Reg=
arding the default serialization.  There's one important aspect here.&=
nbsp; That is that browsers have no way of setting a content type.  So=
 the any default should be browser friendly if specified.  As far as I=
 can see that leaves RDFa or schema.org etc. as the stand out choices.  I d=
ont think it's necessary to specify a default in this version of the spec.<=
br>=0A
It's worth noting that the problem to be solved, ie to query a da=
ta document to some results is solved both in the specific and general case=
, using a query language such as SPARQL.  I suspect the argument for n=
ot using SPARQL here is that it may be overkill for the use case required.&=
nbsp; Therefore you build a query structure into the spec as a kind of simp=
lification.  But if you want to simplify the general case, perhaps SWD=
 is the best candidate we've seen, or some tweak of that.
=0A
Regardi=
ng having any URI as the input, this is an example of good engineering.&nbs=
p; However, is it really practical?  Does the spec show how to find a =
well known location for *any* URI, or just a subset?  What about sip: =
xmpp: tel: etc.  In particular I think tel: would break the spec, as w=
ould many other URIs (essentially the non DNS based ones).  
=0AThat also leads to the thorny issue of http: ... do we really want yet ano=
ther way to dereference an HTTP URI other than GET?   What about =
response codes, sync of data, attack surfaces?  

On the whole I=
 think paul has done a great job in difficult circumstances, with lots of r=
equests, from all angles.  I hope we can come to a consensus soon and =
solve the core use case of discovering information on an email address at w=
eb scale.
=0A 
=
=0A
=0AHope that's helpful.
=0A
=0Ab.
=0A

=0AOn 21 October 2012 05:13,=
 Melvin Carvalho <melvin=
carvalho@gmail.com> wrote:
=0A>
=0A>
=0A> On 21 Oc=
tober 2012 09:37, Christian Weiske <=
cweiske@cweiske.de> wrote:
=0A>>
=0A>> Hello Paul,=

=0A>>
=0A>>
=0A>> >> *    Secti=
on 7 makes support for CORS a MUST and then turns
=0A>> >> a=
round and said if you have a good reason not to support it, you
=0A>&=
gt; >> SHOULD NOT. I suggest that support for CORS should just be a S=
HOULD.
=0A>> >> I can figure out myself whether I want to be=
 the exception.
=0A>> > PEJ: You're entirely right about that a=
nd that text bugged me, too.
=0A>> > There was a strong desire =
for CORS to the point I was asked to make
=0A>> > it a MUST, ye=
t there was the desire to allow an enterprise do
=0A>> > someth=
ing more restrictive. I have no strong preference, myself, but
=0A>&g=
t; > I do think that if we make it a SHOULD, though, that it will make i=
t
=0A>> > impossible to build a client in a browser.  What=
 does the group want
=0A>> > here?
=0A>>
=0A>>=
; Not supporting CORS does not make the data any more secure. If someone=0A>> wants security for their intranet, they have to implement real=
 security
=0A>> measurements, e.g. based on IP whitelists.
=0A&=
gt;>
=0A>> Please leave CORS support a MUST.
=0A>
=0A&=
gt;
=0A> +1
=0A>>
=0A>>
=0A>> --
=0A>=
;> Regards/Mit freundlichen Gr=C3=BC=C3=9Fen
=0A>> Christian We=
iske
=0A>>
=0A>> -=3D=E2=89=A1 Geeking around in the name=
 of science since 1982 =E2=89=A1=3D-
=0A>
=0A>
=0A

=0A

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

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

<=
br> 
 
 
   

--835683298-892432109-1351386674=:45982--

From paulej@packetizer.com  Sat Oct 27 19:25:05 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB5D21F86A0 for ; Sat, 27 Oct 2012 19:25:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.225
X-Spam-Level: 
X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[AWL=1.375,  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 0l5PD1SGaNDN for ; Sat, 27 Oct 2012 19:25:04 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B156221F8678 for ; Sat, 27 Oct 2012 19:25:04 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9S2OxfZ021642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 27 Oct 2012 22:25:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351391100; bh=qF/ClAU0Z3BJOFSYSpTAZ4yuyh962NCm3uqZ2Tqv97w=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=sRGzaebPO//3tw7YgtLeL80iz7jbB0rZZarvMNj9DaNwxjIsktOljf3+z/w9ZmK2/ jXtie7ohTDDwmathW2O8BNBM+uhzxCvj4F/mmhiDYcI9j893vMFLBpUMtiDSTk8JRw o/OgWx3FH9eDUHF2vWsM7JVkJ34l6SpUglN+FSX4=
From: "Paul E. Jones" 
To: , "'Melvin Carvalho'" 
References: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com>	<5082C526.3050100@status.net>	<00c501cdaf13$13ef6d30$3bce4790$@packetizer.com>	<20121021093728.590d2898@bogo>		 
In-Reply-To: 
Date: Sat, 27 Oct 2012 22:25:01 -0400
Message-ID: <094c01cdb4b3$6f78b620$4e6a2260$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGcFKYbM2jJ0wiJf9oQM3Qhr6BdxwGjlKSjAlziv24CTWS12wD2u3/eAL94oFQB/N04zJfhJt/Q
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-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, 28 Oct 2012 02:25:05 -0000

Melvin,

> Webfinger is now in its fourth year and one thing that has
> remained constant is that it would be valuable on the internet to
> perform discovery on an email address to get more information
> such as blog address, homepage etc.

Fully agree there!
=20
> I thought we had a consensus to use JRD and drop everything else.
> I strongly think this should be the stance of the spec.

The only mandatory format is JRD now.  XRD still exists in RFC 6415 and =
there are servers that use it.  We should not ignore it entirely, so we =
speak about the fact that it already exists today.  Going forward, =
though, no new implementation would be required to support XRD.

> There is
> one interesting aspect to this.  JRD has an advantage over XRD in
> that you can have more than one subject per document, whereas in
> XRD you would be in (willful) violation of the XML Schema.  It
> turns out that this pretty much makes both XRD and RDF
> equivalents modulo a regular expression.  That is quite exciting
> and brings two worlds and big ecosystems together.

The JRD syntax does NOT allow more than one Subject or Expires.  If a =
JavaScript processor saw this:
   { "Subject" : "s1", "Subject" : "s2" }

Then it would likely replace the value of "Subject" it saw previously =
with "s2". I don't know what the standard says in this case, but you =
will not have access to two "Subject" values.  So, it is entirely =
consistent with XML.

> Regarding XRD and content negotiation.  If you want XRD you
> should request it in the header. =20

You can always request a format using standard content negotiation.  =
However, we need a default value when anything is accepted or something =
unknown is requested.  So, we have these as default values:
   /.well-known/host-meta - defaults to XRD (iff XRD is supported, else =
JRD)
   /.well-known/host-meta.json - defaults to JRD

We are recommending use of host-meta.json, though a client capable of =
accepting either and/or preferring XRD could use host-meta.  Trying not =
to break what's there any more than necessary.  Be mindful, too, that =
WebFinger does not replace RFC 6415.

> Regarding the default serialization.  There's one important
> aspect here.  That is that browsers have no way of setting a
> content type.

That's not true.  This will do it:
  request.setRequestHeader("Accept", "application/xml");

(Where "request" is an XML HTTP Request object.)

And, one can check the return type like this:
  Request.getResponseHeader("Content-Type");

That said, there might be some who find the work to set the "Accept" =
header just one too many lines of code ;-) I don't know.  I always use =
the Accept header when I write web interface code.

Nonetheless, we do have defaults specified "just in case" (or to help =
the lazy programmer).

> So the any default should be browser friendly if
> specified.  As far as I can see that leaves RDFa or schema.org
> etc. as the stand out choices.  I dont think it's necessary to
> specify a default in this version of the spec.

I'm confused. You are suggesting that RDFa should be a default?  One =
could certainly build a server to return RDFa or anything else, but we'd =
have to specify exactly what the response should look like.  Given folks =
wanted one format we go forward with, I do not dare want to suggest =
opening that can of worms again :-)

> It's worth noting that the problem to be solved, ie to query a
> data document to some results is solved both in the specific and
> general case, using a query language such as SPARQL.  I suspect
> the argument for not using SPARQL here is that it may be overkill
> for the use case required.  Therefore you build a query structure
> into the spec as a kind of simplification.  But if you want to
> simplify the general case, perhaps SWD is the best candidate
> we've seen, or some tweak of that.

WebFinger is really simple. It would allow one to take an identifier =
like "acct:paulej@packetizer.com" and transform that into a set of link =
relations with a single request to the server.  I think that simplicity, =
plus the JSON format, is what people want/need/desire/prefer with a =
simple web discovery mechanism.

> Regarding having any URI as the input, this is an example of good
> engineering.  However, is it really practical?  Does the spec
> show how to find a well known location for *any* URI, or just a
> subset?  What about sip: xmpp: tel: etc.  In particular I think
> tel: would break the spec, as would many other URIs (essentially
> the non DNS based ones). =20

Tel URIs are not useful for WebFinger since, as you note, there is no =
associated host information.  However, we should allow any URI that does =
have a domain part.  After all, the purpose is to go to the server and =
say "tell me about this URI".  If the server knows, it will provide an =
answer.  If the server has no information on the URI, it will return a =
404.

We should allow "sip:" as that might be used to tell my SIP client how =
to configure itself (e.g., the address of the outbound proxy).  Same =
argument goes for mailto:, xmpp:, h323:, etc.

> That also leads to the thorny issue of http: ... do we really
> want yet another way to dereference an HTTP URI other than GET?
> What about response codes, sync of data, attack surfaces? =20

What's wrong with using "http" ones?  This might be used to provide =
author, copyright, and contact information for the author of a blog =
article specified article at the HTTP address.  It might also be used as =
a means of converting identifiers into other identifiers.  For example, =
if OpenID did not already have a discovery mechanism, then you can =
imagine how an OpenID identifier could be queried using WebFinger to =
find the OpenID Provider URL.

This is not dereferencing an HTTP URI, but discovering information =
*about* the URI.  This is quite different.

> On the whole I think paul has done a great job in difficult
> circumstances, with lots of requests, from all angles.  I hope we
> can come to a consensus soon and solve the core use case of
> discovering information on an email address at web scale.

Thanks for the kind words.  It has been an interesting ride, starting =
way back when I asked on the OpenID lists whether folks had considered =
using an email ID rather than an HTTP URL.  I got blasted for suggesting =
that! :-)  But, I was persistent (foolish?) and asked some time later =
and people pointed me to the WebFinger work.  When I first saw the =
concept, I fell in love with it.  So, credit for the work goes out to a =
lot of people other than me.  It's not my concept at all, but I've been =
trying my best to reach agreement so that we can have spec we can all =
implement. I think this will be a very useful service on the Internet =
and inside corporate networks.

Paul



From paulej@packetizer.com  Sat Oct 27 19:37:50 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F34821F84C8 for ; Sat, 27 Oct 2012 19:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level: 
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=1.099,  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 2DtYdQpxTMUx for ; Sat, 27 Oct 2012 19:37:49 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B565821F84C4 for ; Sat, 27 Oct 2012 19:37:48 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9S2bkUe022294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 27 Oct 2012 22:37:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351391867; bh=vGQN34eu56kS343gc7kPS9RMDzDacQ67WEJizbdtzX0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=lGK+vEwzbPc21NfKlWqrog5KQEl+dfNvTrIEv6dMRCr+xLzFhtjE2MqLzd98rJ9Ws U4alUExor76rEN6G0P0gguSXq2o/0J0nqXrk0hv/FknTKqsUYE6HBAIyVr8Vk8y471 5f/DsGziWX2LhKRFu24l13kI/y2W8qDrtqm2ks/A=
From: "Paul E. Jones" 
To: "'William Mills'" , "'Melvin Carvalho'" , 
References: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com>	<5082C526.3050100@status.net>	<00c501cdaf13$13ef6d30$3bce4790$@packetizer.com>	<20121021093728.590d2898@bogo>			 <1351386674.45982.YahooMailNeo@web31804.mail.mud.yahoo.com>
In-Reply-To: <1351386674.45982.YahooMailNeo@web31804.mail.mud.yahoo.com>
Date: Sat, 27 Oct 2012 22:37:48 -0400
Message-ID: <094e01cdb4b5$3869f200$a93dd600$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_094F_01CDB493.B159FFB0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGcFKYbM2jJ0wiJf9oQM3Qhr6BdxwGjlKSjAlziv24CTWS12wD2u3/eAL94oFQB/N04zAHEEpK5l9MYWWA=
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger Draft Updated -	draft-ietf-appsawg-webfinger-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, 28 Oct 2012 02:37:50 -0000

This is a multipart message in MIME format.

------=_NextPart_000_094F_01CDB493.B159FFB0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Bill,

=20

Since JRD is the only MTI format, how is this morphing into something =
complex?  In this most recent draft (-02), we=E2=80=99ve moved away from =
requiring both to requiring only JRD.  That=E2=80=99s true of both =
clients and servers.

=20

Paul

=20

From: apps-discuss-bounces@ietf.org =
[mailto:apps-discuss-bounces@ietf.org] On Behalf Of William Mills
Sent: Saturday, October 27, 2012 9:11 PM
To: Melvin Carvalho; webfinger@googlegroups.com
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger Draft Updated - =
draft-ietf-appsawg-webfinger-01

=20

Various people have said "just go with JRD, it's so much better than =
XRD", but this spec is still trying to stirke a balance here since there =
is already and installed base under the current WF XRD as MTI spec.  =
There has been understandable reticence to declaring existing =
implementations to be no longer compliant with the spec.  I am strongly =
opposed to morphing WF into something that does that.

I am *highly* in favor of simplicity, and I think we're moving to a more =
complex thing that will make the trivial case more work to support.

-bill

=20

=20


  _____ =20


From: Melvin Carvalho 
To: webfinger@googlegroups.com=20
Cc: apps-discuss@ietf.org=20
Sent: Saturday, October 27, 2012 9:31 AM
Subject: Re: [apps-discuss] WebFinger Draft Updated - =
draft-ietf-appsawg-webfinger-01

=20

=20

On 22 October 2012 10:49, Blaine Cook  wrote:

Preamble: This spec looks absolutely nothing like I imagined
Webfinger, which was, and was meant to be, a light-weight and simple
method to look up resource data for an email address. I'm not happy
with this *at all*, and probably won't implement it, either client or
server. I've achieved the login handling using a much simpler (but
less powerful and intentful) heuristic that I'll talk about soon.

1. +1 on CORS support.

2. Since I appear to have fully and completely lost the argument on
structuring Webfinger like DNS (despite the many positive reactions
outside this list I've received regarding the alternate proposal), two
proposals:

2a. Drop the template URI stuff.
2b. Have only one method for following redirects. If the participants
in this process think that it's OK to require static hosts to use HTTP
semantics (30x) to redirect /.well-known/host-meta, then use that
everywhere, since the hard place to do that is for static hosts =
=E2=80=93
anyone responding dynamically requests can trivially issue HTTP
redirects, rather than generating JSON.

Some notes on redirects:

=E2=80=93 The redirect code MUST NOT be 301. This would make it =
impossible
under some circumstances for the host to regain control over lookups,
and is *never* the correct behaviour from a normative standpoint
(where the behaviour being enabled is like DNS =E2=80=93 you can *never*
permanently redirect a DNS lookup).
=E2=80=93 Clients MUST treat 301 response codes as 307.
=E2=80=93 The redirect code SHOULD be 307, and the server SHOULD use
appropriate HTTP caching semantics.

Note that we are actually getting *worse* performance characteristics
out of this scheme for hosts using 3rd party webfinger providers,
since each request to a different user results in two requests; one to
the base domain, and one to the 3rd party server.

Drop all the redirect JRD stuff.


I've been thinking about this a fair bit. =20

Webfinger is now in its fourth year and one thing that has remained =
constant is that it would be valuable on the internet to perform =
discovery on an email address to get more information such as blog =
address, homepage etc.

I thought we had a consensus to use JRD and drop everything else.  I =
strongly think this should be the stance of the spec.  There is one =
interesting aspect to this.  JRD has an advantage over XRD in that you =
can have more than one subject per document, whereas in XRD you would be =
in (willful) violation of the XML Schema.  It turns out that this pretty =
much makes both XRD and RDF equivalents modulo a regular expression.  =
That is quite exciting and brings two worlds and big ecosystems =
together.

Regarding XRD and content negotiation.  If you want XRD you should =
request it in the header. =20

Regarding the default serialization.  There's one important aspect here. =
 That is that browsers have no way of setting a content type.  So the =
any default should be browser friendly if specified.  As far as I can =
see that leaves RDFa or schema.org   etc. as the =
stand out choices.  I dont think it's necessary to specify a default in =
this version of the spec.

It's worth noting that the problem to be solved, ie to query a data =
document to some results is solved both in the specific and general =
case, using a query language such as SPARQL.  I suspect the argument for =
not using SPARQL here is that it may be overkill for the use case =
required.  Therefore you build a query structure into the spec as a kind =
of simplification.  But if you want to simplify the general case, =
perhaps SWD is the best candidate we've seen, or some tweak of that.

Regarding having any URI as the input, this is an example of good =
engineering.  However, is it really practical?  Does the spec show how =
to find a well known location for *any* URI, or just a subset?  What =
about sip: xmpp: tel: etc.  In particular I think tel: would break the =
spec, as would many other URIs (essentially the non DNS based ones). =20

That also leads to the thorny issue of http: ... do we really want yet =
another way to dereference an HTTP URI other than GET?   What about =
response codes, sync of data, attack surfaces? =20

On the whole I think paul has done a great job in difficult =
circumstances, with lots of requests, from all angles.  I hope we can =
come to a consensus soon and solve the core use case of discovering =
information on an email address at web scale.
=20


Hope that's helpful.

b.


On 21 October 2012 05:13, Melvin Carvalho  =
wrote:
>
>
> On 21 October 2012 09:37, Christian Weiske  wrote:
>>
>> Hello Paul,
>>
>>
>> >> *    Section 7 makes support for CORS a MUST and then turns
>> >> around and said if you have a good reason not to support it, you
>> >> SHOULD NOT. I suggest that support for CORS should just be a =
SHOULD.
>> >> I can figure out myself whether I want to be the exception.
>> > PEJ: You're entirely right about that and that text bugged me, too.
>> > There was a strong desire for CORS to the point I was asked to make
>> > it a MUST, yet there was the desire to allow an enterprise do
>> > something more restrictive. I have no strong preference, myself, =
but
>> > I do think that if we make it a SHOULD, though, that it will make =
it
>> > impossible to build a client in a browser.  What does the group =
want
>> > here?
>>
>> Not supporting CORS does not make the data any more secure. If =
someone
>> wants security for their intranet, they have to implement real =
security
>> measurements, e.g. based on IP whitelists.
>>
>> Please leave CORS support a MUST.
>
>
> +1
>>
>>
>> --
>> Regards/Mit freundlichen Gr=C3=BC=C3=9Fen
>> Christian Weiske
>>
>> -=3D=E2=89=A1 Geeking around in the name of science since 1982 =
=E2=89=A1=3D-
>
>

=20


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




------=_NextPart_000_094F_01CDB493.B159FFB0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Bill,
 
Since JRD is the only MTI format, how is this morphing into something =
complex?=C2=A0 In this most recent draft (-02), we=E2=80=99ve moved away =
from requiring both to requiring only JRD.=C2=A0 That=E2=80=99s true of =
both clients and servers.
 
Paul
 
From:=
 =
apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of William Mills
Sent: Saturday, October 27, =
2012 9:11 PM
To: Melvin Carvalho; =
webfinger@googlegroups.com
Cc: =
apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger =
Draft Updated - =
draft-ietf-appsawg-webfinger-01
 
Various =
people have said "just go with JRD, it's so much better than =
XRD", but this spec is still trying to stirke a balance here since =
there is already and installed base under the current WF XRD as MTI =
spec.  There has been understandable reticence to declaring =
existing implementations to be no longer compliant with the spec.  =
I am strongly opposed to morphing WF into something that does =
that.

I am *highly* in favor of simplicity, and I think we're =
moving to a more complex thing that will make the trivial case more work =
to support.

-bill
 
 
<=
hr size=3D1 width=3D"100%" align=3Dcenter>
F=
rom: =
Melvin Carvalho <melvincarvalho@gmail.com>=

To: webfinger@googlegroups.com=
 
Cc: apps-discuss@ietf.org =

Sent: Saturday, October 27, 2012 9:31 AM
Subject: =
Re: [apps-discuss] WebFinger Draft Updated - =
draft-ietf-appsawg-webfinger-01
 
 
On 22 October 2012 10:49, Blaine Cook <romeda@gmail.com> =
wrote:
Preamble: This =
spec looks absolutely nothing like I imagined
Webfinger, which was, =
and was meant to be, a light-weight and simple
method to look up =
resource data for an email address. I'm not happy
with this *at all*, =
and probably won't implement it, either client or
server. I've =
achieved the login handling using a much simpler (but
less powerful =
and intentful) heuristic that I'll talk about soon.

1. +1 on CORS =
support.

2. Since I appear to have fully and completely lost the =
argument on
structuring Webfinger like DNS (despite the many positive =
reactions
outside this list I've received regarding the alternate =
proposal), two
proposals:

2a. Drop the template URI =
stuff.
2b. Have only one method for following redirects. If the =
participants
in this process think that it's OK to require static =
hosts to use HTTP
semantics (30x) to redirect /.well-known/host-meta, =
then use that
everywhere, since the hard place to do that is for =
static hosts =E2=80=93
anyone responding dynamically requests can =
trivially issue HTTP
redirects, rather than generating =
JSON.

Some notes on redirects:

=E2=80=93 The redirect =
code MUST NOT be 301. This would make it impossible
under some =
circumstances for the host to regain control over lookups,
and is =
*never* the correct behaviour from a normative standpoint
(where the =
behaviour being enabled is like DNS =E2=80=93 you can =
*never*
permanently redirect a DNS lookup).
=E2=80=93 Clients =
MUST treat 301 response codes as 307.
=E2=80=93 The redirect =
code SHOULD be 307, and the server SHOULD use
appropriate HTTP =
caching semantics.

Note that we are actually getting *worse* =
performance characteristics
out of this scheme for hosts using 3rd =
party webfinger providers,
since each request to a different user =
results in two requests; one to
the base domain, and one to the 3rd =
party server.

Drop all the redirect JRD =
stuff.

I've been =
thinking about this a fair bit.  

Webfinger is now in its =
fourth year and one thing that has remained constant is that it would be =
valuable on the internet to perform discovery on an email address to get =
more information such as blog address, homepage etc.

I thought we =
had a consensus to use JRD and drop everything else.  I strongly =
think this should be the stance of the spec.  There is one =
interesting aspect to this.  JRD has an advantage over XRD in that =
you can have more than one subject per document, whereas in XRD you =
would be in (willful) violation of the XML Schema.  It turns out =
that this pretty much makes both XRD and RDF equivalents modulo a =
regular expression.  That is quite exciting and brings two worlds =
and big ecosystems together.

Regarding XRD and content =
negotiation.  If you want XRD you should request it in the =
header.  

Regarding the default serialization.  There's =
one important aspect here.  That is that browsers have no way of =
setting a content type.  So the any default should be browser =
friendly if specified.  As far as I can see that leaves RDFa or schema.org etc. as the =
stand out choices.  I dont think it's necessary to specify a =
default in this version of the spec.

It's worth noting that the =
problem to be solved, ie to query a data document to some results is =
solved both in the specific and general case, using a query language =
such as SPARQL.  I suspect the argument for not using SPARQL here =
is that it may be overkill for the use case required.  Therefore =
you build a query structure into the spec as a kind of =
simplification.  But if you want to simplify the general case, =
perhaps SWD is the best candidate we've seen, or some tweak of =
that.

Regarding having any URI as the input, this is an example =
of good engineering.  However, is it really practical?  Does =
the spec show how to find a well known location for *any* URI, or just a =
subset?  What about sip: xmpp: tel: etc.  In particular I =
think tel: would break the spec, as would many other URIs (essentially =
the non DNS based ones).  

That also leads to the thorny =
issue of http: ... do we really want yet another way to dereference an =
HTTP URI other than GET?   What about response codes, sync of =
data, attack surfaces?  

On the whole I think paul has done =
a great job in difficult circumstances, with lots of requests, from all =
angles.  I hope we can come to a consensus soon and solve the core =
use case of discovering information on an email address at web =
scale.
 

Hope that's =
helpful.

b.

On 21 October 2012 05:13, Melvin Carvalho =
<melvincarvalho@gmail.com> =
wrote:
>
>
> On 21 October 2012 09:37, Christian =
Weiske <cweiske@cweiske.de> =
wrote:
>>
>> Hello =
Paul,
>>
>>
>> >> *   =
 Section 7 makes support for CORS a MUST and then turns
>> =
>> around and said if you have a good reason not to support it, =
you
>> >> SHOULD NOT. I suggest that support for CORS =
should just be a SHOULD.
>> >> I can figure out myself =
whether I want to be the exception.
>> > PEJ: You're =
entirely right about that and that text bugged me, too.
>> > =
There was a strong desire for CORS to the point I was asked to =
make
>> > it a MUST, yet there was the desire to allow an =
enterprise do
>> > something more restrictive. I have no =
strong preference, myself, but
>> > I do think that if we =
make it a SHOULD, though, that it will make it
>> > =
impossible to build a client in a browser.  What does the group =
want
>> > here?
>>
>> Not supporting CORS =
does not make the data any more secure. If someone
>> wants =
security for their intranet, they have to implement real =
security
>> measurements, e.g. based on IP =
whitelists.
>>
>> Please leave CORS support a =
MUST.
>
>
> +1
>>
>>
>> =
--
>> Regards/Mit freundlichen Gr=C3=BC=C3=9Fen
>> =
Christian Weiske
>>
>> -=3D=E2=89=A1 Geeking around in =
the name of science since 1982 =
=E2=89=A1=3D-
>
>
 

_______________________________________________=

apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<=
br>
<=
/div>
------=_NextPart_000_094F_01CDB493.B159FFB0--


From melvincarvalho@gmail.com  Sun Oct 28 04:42:13 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC93821F870C for ; Sun, 28 Oct 2012 04:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyjJdqW2NGCW for ; Sun, 28 Oct 2012 04:42:12 -0700 (PDT)
Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5AF321F8708 for ; Sun, 28 Oct 2012 04:42:11 -0700 (PDT)
Received: by mail-ia0-f172.google.com with SMTP id x24so1506474iak.31 for ; Sun, 28 Oct 2012 04:42:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ve0PXQFSwj/DpjgSCWEROKWFgfGxw21yPbKRvNqgFSk=; b=WztzhBXpyeKkrhe4U1le8pBZMqnvM3YIh2++yCzgX+LSt/vYtp0vdQlmTf4KQ41vfR exP+7NJECtwtqcsG8G/n8gdmJz0T1DT8zlh/xUKRCu67PTihDnNFk41wFI9hCUa8jJM2 qkoyVsMoodCzw/CyUtR5XoPS2EzDQM4WXvvy99ypbynGwd98k53tcWoLhxF1I0FkezhW bijHe7zK60HNNJ1CI633SlrtUjt0EB4oWWrBwkHnkUDyRhYVwIFftHzsJj306ji6s5YO Hox2T+cD+0Lvxx2T+A+MJkIaV4pFG0i8HAWSIU1dFGjW439K/4OjZHg93Mh7VzGmGcyM w7rw==
MIME-Version: 1.0
Received: by 10.50.190.234 with SMTP id gt10mr6764048igc.20.1351424530596; Sun, 28 Oct 2012 04:42:10 -0700 (PDT)
Received: by 10.42.247.129 with HTTP; Sun, 28 Oct 2012 04:42:10 -0700 (PDT)
In-Reply-To: <094c01cdb4b3$6f78b620$4e6a2260$@packetizer.com>
References: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com> <5082C526.3050100@status.net> <00c501cdaf13$13ef6d30$3bce4790$@packetizer.com> <20121021093728.590d2898@bogo>    <094c01cdb4b3$6f78b620$4e6a2260$@packetizer.com>
Date: Sun, 28 Oct 2012 12:42:10 +0100
Message-ID: 
From: Melvin Carvalho 
To: "Paul E. Jones" 
Content-Type: multipart/alternative; boundary=14dae93408dd1643d604cd1d0b44
Cc: webfinger@googlegroups.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-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, 28 Oct 2012 11:42:13 -0000

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

On 28 October 2012 03:25, Paul E. Jones  wrote:

> Melvin,
>
> > Webfinger is now in its fourth year and one thing that has
> > remained constant is that it would be valuable on the internet to
> > perform discovery on an email address to get more information
> > such as blog address, homepage etc.
>
> Fully agree there!
>
> > I thought we had a consensus to use JRD and drop everything else.
> > I strongly think this should be the stance of the spec.
>
> The only mandatory format is JRD now.  XRD still exists in RFC 6415 and
> there are servers that use it.  We should not ignore it entirely, so we
> speak about the fact that it already exists today.  Going forward, though,
> no new implementation would be required to support XRD.
>
> > There is
> > one interesting aspect to this.  JRD has an advantage over XRD in
> > that you can have more than one subject per document, whereas in
> > XRD you would be in (willful) violation of the XML Schema.  It
> > turns out that this pretty much makes both XRD and RDF
> > equivalents modulo a regular expression.  That is quite exciting
> > and brings two worlds and big ecosystems together.
>
> The JRD syntax does NOT allow more than one Subject or Expires.  If a
> JavaScript processor saw this:
>    { "Subject" : "s1", "Subject" : "s2" }
>
> Then it would likely replace the value of "Subject" it saw previously with
> "s2". I don't know what the standard says in this case, but you will not
> have access to two "Subject" values.  So, it is entirely consistent with
> XML.
>

I think what you would do in the json is have several objects each with a
single subject, it's essentially entity attribute value which is the
generalization of but rdf and xrd.

The only real difference between XRD and RDF is that (according to XML
schema) recommends one object per document, but RDF is open ended.  JSON
can easily handle mulbiple objects per document which means that one model
can be translated to another and vice versa.


>
> > Regarding XRD and content negotiation.  If you want XRD you
> > should request it in the heade
>
> You can always request a format using standard content negotiation.
>  However, we need a default value when anything is accepted or something
> unknown is requested.  So, we have these as default values:
>    /.well-known/host-meta - defaults to XRD (iff XRD is supported, else
> JRD)
>    /.well-known/host-meta.json - defaults to JRD
>
> We are recommending use of host-meta.json, though a client capable of
> accepting either and/or preferring XRD could use host-meta.  Trying not to
> break what's there any more than necessary.  Be mindful, too, that
> WebFinger does not replace RFC 6415.
>

When dealing with a relatively bespoke format like xrd, the client should
always set the content type, imho.


>
> > Regarding the default serialization.  There's one important
> > aspect here.  That is that browsers have no way of setting a
> > content type.
>
> That's not true.  This will do it:
>   request.setRequestHeader("Accept", "application/xml");
>
> (Where "request" is an XML HTTP Request object.)
>
> And, one can check the return type like this:
>   Request.getResponseHeader("Content-Type");
>
> That said, there might be some who find the work to set the "Accept"
> header just one too many lines of code ;-) I don't know.  I always use the
> Accept header when I write web interface code.
>
> Nonetheless, we do have defaults specified "just in case" (or to help the
> lazy programmer).
>

Ah yes, what I meant to say was that the browser doesnt normally send a
content type when clicking on a hyperlink.

Accept header is too many lines of code, it should only be 1?  Hopefully
something even 'lazy' programmers can handle :)


>
> > So the any default should be browser friendly if
> > specified.  As far as I can see that leaves RDFa or schema.org
> > etc. as the stand out choices.  I dont think it's necessary to
> > specify a default in this version of the spec.
>
> I'm confused. You are suggesting that RDFa should be a default?  One could
> certainly build a server to return RDFa or anything else, but we'd have to
> specify exactly what the response should look like.  Given folks wanted one
> format we go forward with, I do not dare want to suggest opening that can
> of worms again :-)
>

No, I think that there should be no default set at all.  The point I was
making above is that the main benefit from a default content type is for
the case where the client is *unable* to easily set it and that is the case
of the browser hyperlink.  So since that's not part of the use cases, it
need not be covered now.  But say in future, there may be a use case
oriented around clicking from a hyperlink to a webfinger record, you never
know ..


>
> > It's worth noting that the problem to be solved, ie to query a
> > data document to some results is solved both in the specific and
> > general case, using a query language such as SPARQL.  I suspect
> > the argument for not using SPARQL here is that it may be overkill
> > for the use case required.  Therefore you build a query structure
> > into the spec as a kind of simplification.  But if you want to
> > simplify the general case, perhaps SWD is the best candidate
> > we've seen, or some tweak of that.
>
> WebFinger is really simple. It would allow one to take an identifier like "
> acct:paulej@packetizer.com" and transform that into a set of link
> relations with a single request to the server.  I think that simplicity,
> plus the JSON format, is what people want/need/desire/prefer with a simple
> web discovery mechanism.
>

Largely agree, tho I'm just pointing out the general case has a query
language, therefore the high level goals of webfinger can be oriented to
the practical cases (eg email discovery) rather than the general.  Was
really just a side comment :)


>
> > Regarding having any URI as the input, this is an example of good
> > engineering.  However, is it really practical?  Does the spec
> > show how to find a well known location for *any* URI, or just a
> > subset?  What about sip: xmpp: tel: etc.  In particular I think
> > tel: would break the spec, as would many other URIs (essentially
> > the non DNS based ones).
>
> Tel URIs are not useful for WebFinger since, as you note, there is no
> associated host information.  However, we should allow any URI that does
> have a domain part.  After all, the purpose is to go to the server and say
> "tell me about this URI".  If the server knows, it will provide an answer.
>  If the server has no information on the URI, it will return a 404.
>

Sure, tho im not sure the language in the spec, but I guess it should point
out the WF is only oriented at those that have a domain part, or list the
ones that are valid?


>
> We should allow "sip:" as that might be used to tell my SIP client how to
> configure itself (e.g., the address of the outbound proxy).  Same argument
> goes for mailto:, xmpp:, h323:, etc.
>
> > That also leads to the thorny issue of http: ... do we really
> > want yet another way to dereference an HTTP URI other than GET?
> > What about response codes, sync of data, attack surfaces?
>
> What's wrong with using "http" ones?  This might be used to provide
> author, copyright, and contact information for the author of a blog article
> specified article at the HTTP address.  It might also be used as a means of
> converting identifiers into other identifiers.  For example, if OpenID did
> not already have a discovery mechanism, then you can imagine how an OpenID
> identifier could be queried using WebFinger to find the OpenID Provider URL.
>
> This is not dereferencing an HTTP URI, but discovering information *about*
> the URI.  This is quite different.
>

This is possible but there are well established methods for getting
information about a URI.  Essentially that's what the last 10 years of work
by the w3c has focused on.


>
> > On the whole I think paul has done a great job in difficult
> > circumstances, with lots of requests, from all angles.  I hope we
> > can come to a consensus soon and solve the core use case of
> > discovering information on an email address at web scale.
>
> Thanks for the kind words.  It has been an interesting ride, starting way
> back when I asked on the OpenID lists whether folks had considered using an
> email ID rather than an HTTP URL.  I got blasted for suggesting that! :-)
>  But, I was persistent (foolish?) and asked some time later and people
> pointed me to the WebFinger work.  When I first saw the concept, I fell in
> love with it.  So, credit for the work goes out to a lot of people other
> than me.  It's not my concept at all, but I've been trying my best to reach
> agreement so that we can have spec we can all implement. I think this will
> be a very useful service on the Internet and inside corporate networks.
>

+1


>
> Paul
>
>
>

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



On 28 October 2012 03:25, Paul E. Jones =
<paulej@packetizer.com> wrote:

Melvin,




> Webfinger is now in its fourth year and one thing that has

> remained constant is that it would be valuable on the internet to

> perform discovery on an email address to get more information

> such as blog address, homepage etc.




Fully agree there!




> I thought we had a consensus to use JRD and drop everything else.

> I strongly think this should be the stance of the spec.




The only mandatory format is JRD now. =A0XRD still exists in RFC 6415=
 and there are servers that use it. =A0We should not ignore it entirely, so=
 we speak about the fact that it already exists today. =A0Going forward, th=
ough, no new implementation would be required to support XRD.





> There is

> one interesting aspect to this. =A0JRD has an advantage over XRD in
> that you can have more than one subject per document, whereas in

> XRD you would be in (willful) violation of the XML Schema. =A0It

> turns out that this pretty much makes both XRD and RDF

> equivalents modulo a regular expression. =A0That is quite exciting

> and brings two worlds and big ecosystems together.




The JRD syntax does NOT allow more than one Subject or Expires. =A0If=
 a JavaScript processor saw this:

=A0 =A0{ "Subject" : "s1", "Subject" : "=
s2" }



Then it would likely replace the value of "Subject" it saw previo=
usly with "s2". I don't know what the standard says in this c=
ase, but you will not have access to two "Subject" values. =A0So,=
 it is entirely consistent with XML.



I think what you would do in the json is have several=
 objects each with a single subject, it's essentially entity attribute =
value which is the generalization of but rdf and xrd.=A0 

The only r=
eal difference between XRD and RDF is that (according to XML schema) recomm=
ends one object per document, but RDF is open ended.=A0 JSON can easily han=
dle mulbiple objects per document which means that one model can be transla=
ted to another and vice versa.=A0 

=A0




> Regarding XRD and content negotiation. =A0If you want XRD you

> should request it in the heade




You can always request a format using standard content negotiation. =
=A0However, we need a default value when anything is accepted or something =
unknown is requested. =A0So, we have these as default values:

=A0 =A0/.well-known/host-meta - defaults to XRD (iff XRD is supported, else=
 JRD)

=A0 =A0/.well-known/host-meta.json - defaults to JRD



We are recommending use of host-meta.json, though a client capable of accep=
ting either and/or preferring XRD could use host-meta. =A0Trying not to bre=
ak what's there any more than necessary. =A0Be mindful, too, that WebFi=
nger does not replace RFC 6415.



When dealing with a relatively bespoke format like xr=
d, the client should always set the content type, imho.=A0 
=A0





> Regarding the default serialization. =A0There's one important

> aspect here. =A0That is that browsers have no way of setting a

> content type.




That's not true. =A0This will do it:

=A0 request.setRequestHeader("Accept", "application/xml"=
;);



(Where "request" is an XML HTTP Request object.)



And, one can check the return type like this:

=A0 Request.getResponseHeader("Content-Type");



That said, there might be some who find the work to set the "Accept&qu=
ot; header just one too many lines of code ;-) I don't know. =A0I alway=
s use the Accept header when I write web interface code.



Nonetheless, we do have defaults specified "just in case" (or to =
help the lazy programmer).

Ah yes, what I meant to=
 say was that the browser doesnt normally send a content type when clicking=
 on a hyperlink.


Accept header is too many lines of code, it should only be 1?=A0 Hopefu=
lly something even 'lazy' programmers can handle :)
=A0





> So the any default should be browser friendly if

> specified. =A0As far as I can see that leaves RDFa or schema.org

> etc. as the stand out choices. =A0I dont think it's necessary to
> specify a default in this version of the spec.




I'm confused. You are suggesting that RDFa should be a default? =
=A0One could certainly build a server to return RDFa or anything else, but =
we'd have to specify exactly what the response should look like. =A0Giv=
en folks wanted one format we go forward with, I do not dare want to sugges=
t opening that can of worms again :-)



No, I think that there should be no default set at al=
l.=A0 The point I was making above is that the main benefit from a default =
content type is for the case where the client is *unable* to easily set it =
and that is the case of the browser hyperlink.=A0 So since that's not p=
art of the use cases, it need not be covered now.=A0 But say in future, the=
re may be a use case oriented around clicking from a hyperlink to a webfing=
er record, you never know ..

=A0




> It's worth noting that the problem to be solved, ie to query a

> data document to some results is solved both in the specific and

> general case, using a query language such as SPARQL. =A0I suspect

> the argument for not using SPARQL here is that it may be overkill

> for the use case required. =A0Therefore you build a query structure
> into the spec as a kind of simplification. =A0But if you want to

> simplify the general case, perhaps SWD is the best candidate

> we've seen, or some tweak of that.




WebFinger is really simple. It would allow one to take an identifier =
like "acct:paulej@pack=
etizer.com" and transform that into a set of link relations with a=
 single request to the server. =A0I think that simplicity, plus the JSON fo=
rmat, is what people want/need/desire/prefer with a simple web discovery me=
chanism.



Largely agree, tho I'm just pointing out the gene=
ral case has a query language, therefore the high level goals of webfinger =
can be oriented to the practical cases (eg email discovery) rather than the=
 general.=A0 Was really just a side comment :)

=A0




> Regarding having any URI as the input, this is an example of good

> engineering. =A0However, is it really practical? =A0Does the spec

> show how to find a well known location for *any* URI, or just a

> subset? =A0What about sip: xmpp: tel: etc. =A0In particular I think
> tel: would break the spec, as would many other URIs (essentially

> the non DNS based ones).




Tel URIs are not useful for WebFinger since, as you note, there is no=
 associated host information. =A0However, we should allow any URI that does=
 have a domain part. =A0After all, the purpose is to go to the server and s=
ay "tell me about this URI". =A0If the server knows, it will prov=
ide an answer. =A0If the server has no information on the URI, it will retu=
rn a 404.



Sure, tho im not sure the language in the spec, but I=
 guess it should point out the WF is only oriented at those that have a dom=
ain part, or list the ones that are valid?
=A0




We should allow "sip:" as that might be used to tell my SIP clien=
t how to configure itself (e.g., the address of the outbound proxy). =A0Sam=
e argument goes for mailto:, xmpp:, h323:, etc.




> That also leads to the thorny issue of http: ... do we really

> want yet another way to dereference an HTTP URI other than GET?

> What about response codes, sync of data, attack surfaces?




What's wrong with using "http" ones? =A0This might be u=
sed to provide author, copyright, and contact information for the author of=
 a blog article specified article at the HTTP address. =A0It might also be =
used as a means of converting identifiers into other identifiers. =A0For ex=
ample, if OpenID did not already have a discovery mechanism, then you can i=
magine how an OpenID identifier could be queried using WebFinger to find th=
e OpenID Provider URL.




This is not dereferencing an HTTP URI, but discovering information *about* =
the URI. =A0This is quite different.

This is possi=
ble but there are well established methods for getting information about a =
URI.=A0 Essentially that's what the last 10 years of work by the w3c ha=
s focused on.

=A0




> On the whole I think paul has done a great job in difficult

> circumstances, with lots of requests, from all angles. =A0I hope we
> can come to a consensus soon and solve the core use case of

> discovering information on an email address at web scale.




Thanks for the kind words. =A0It has been an interesting ride, starti=
ng way back when I asked on the OpenID lists whether folks had considered u=
sing an email ID rather than an HTTP URL. =A0I got blasted for suggesting t=
hat! :-) =A0But, I was persistent (foolish?) and asked some time later and =
people pointed me to the WebFinger work. =A0When I first saw the concept, I=
 fell in love with it. =A0So, credit for the work goes out to a lot of peop=
le other than me. =A0It's not my concept at all, but I've been tryi=
ng my best to reach agreement so that we can have spec we can all implement=
. I think this will be a very useful service on the Internet and inside cor=
porate networks.



+1
=A0



Paul









--14dae93408dd1643d604cd1d0b44--

From paul.hoffman@vpnc.org  Sun Oct 28 11:55:51 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B026921F85B3 for ; Sun, 28 Oct 2012 11:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sg24Vy8xSUgw for ; Sun, 28 Oct 2012 11:55:51 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD1621F85B0 for ; Sun, 28 Oct 2012 11:55:51 -0700 (PDT)
Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9SItmbI009629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 28 Oct 2012 11:55:49 -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: Sun, 28 Oct 2012 11:55:48 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2843204E-4DE5-4016-9B56-804DC31D604C@vpnc.org>
References: <20121011222613.1172.25374.idtracker@ietfa.amsl.com> 
To: "apps-discuss@ietf.org Discuss" 
X-Mailer: Apple Mail (2.1499)
Subject: [apps-discuss] How various TLDs use IDN variants
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Oct 2012 18:55:51 -0000

Greetings again. John Levine and I have prepared a short catalog of how =
various TLDs use IDN variants. Because this is just a catalog of what is =
out there, it is intended to be an independent submission, not an IETF =
document. The current version is at =
. We have sent =
messages to the gTLDs' administrative contacts listed in the IANA =
database. We intend to finish the document before end of November, and =
we would appreciate any more comments before then.

I only bring the draft to this list because there might be some =
IDN-cognizant people here who did not see the earlier drafts. This is =
not at all meant to be part of the Apps Area discussion.

--Paul Hoffman=

From salvatore.loreto@ericsson.com  Sun Oct 28 12:02:09 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94B721F86C0 for ; Sun, 28 Oct 2012 12:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.615
X-Spam-Level: 
X-Spam-Status: No, score=-105.615 tagged_above=-999 required=5 tests=[AWL=0.633, 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 pGimLjozvO1O for ; Sun, 28 Oct 2012 12:02:07 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 284B821F86B6 for ; Sun, 28 Oct 2012 12:02:06 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f1e6d000002d2c-17-508d812dd2ea
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C9.74.11564.D218D805; Sun, 28 Oct 2012 20:02:05 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Sun, 28 Oct 2012 20:02:05 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 0DE6C2AF3; Sun, 28 Oct 2012 21:02:04 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 64C9753699; Sun, 28 Oct 2012 21:02:04 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0329251BCF; Sun, 28 Oct 2012 21:02:03 +0200 (EET)
Message-ID: <508D812C.5040708@ericsson.com>
Date: Sun, 28 Oct 2012 21:02:04 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "Paul E. Jones" 
References: <031801cdb0bc$8a5048f0$9ef0dad0$@packetizer.com>
In-Reply-To: <031801cdb0bc$8a5048f0$9ef0dad0$@packetizer.com>
Content-Type: multipart/alternative; boundary="------------020402090101080003090301"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvra5uY2+AwdX3BharX65gszh/YQOT xc/7R9gcmD32TDzJ5rFkyU8mj4Z9R9kDmKO4bFJSczLLUov07RK4Mu6cW8RY0JtY8eXTI9YG xu8+XYwcHBICJhIn/iZ0MXICmWISF+6tZ+ti5OIQEjjJKPGz7zsLhLOBUeLttzWMEM4uRon9 PxugMmsZJab+OscK4WxjlFj04hcryFxeAW2J92clQEwWAVWJ7pYikBVsAmYSzx9uYQaxRQWS JeZtuApm8woISpyc+YQFxBYB6jxz7SFYnFnAVOLkg91gcWEBD4lVN/axgdhCAjYSTa2TwGo4 BWwlHqydyARRHyZx++oGdoh31CSuntvEDFGvJdF7tpNpAqPILCTrZiFpgbBtJS7MuQ4Vl5fY /nYOM4StK3Hh/xQU8QWMbKsY2XMTM3PSyw03MQIj5+CW37o7GE+dEznEKM3BoiTOy5W0319I ID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY7jY6nDz+WGXV+yc9mM922Ph40Ey+gKfTTZfyf99 5+zSrdelnaI/H3j9Skbfy0+1vy5NcmKWfe6VPHtz3b3NL77FVqy8bv62lkdtmanLmzbu2h0+ HeYtbQYOn2aUPdz/f2eG83SnfTearsiKHrM1vTFH9dOdkOsT/1c8iVPl+7/tBr+XbldtoxJL cUaioRZzUXEiAKoZP/dqAgAA
Cc: webfinger@googlegroups.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Updated: draft-ietf-appsawg-webfinger-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: Sun, 28 Oct 2012 19:02:09 -0000

--------------020402090101080003090301
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Paul,

I have read the last 02 version and I have the following comments:

1)
In the Abstract, you define WebFinger

    WebFinger may be
    used to discover information about people on the Internet, such as a
    person's personal profile address, identity service, telephone
    number, or preferred avatar.

however I found this definition slightly different from the one you 
provide in the Overview:

    WebFinger enables the discovery of information about accounts,
    devices, and other entities that are associated with a host.


I think it would be better to align the two


2) In Section 5.2

        *  Collect and expand all resource-specific link relations,
           including those returned by querying for any LRDD link
           relations, discard any host-wide link relations, and return a
           complete resource descriptor following the processing rules in
           Section 4.2 of RFC 6415  ; and

as a nit: above you should remove the "and".


    It is not the responsibility of the WebFinger server to verify, for
    example, that a URI pointing to a person's avatar is a valid URI.  If
    the WebFinger server needs to query an LRDD resource to collect
    additional resource-specific information, any errors (e.g., 500 or
    404) MUST be ignored by the server.  When a request for an LRDD
    fails, the server MUST NOT attempt to augment missing resource
    information or return a "template" type link relation to a client
    that utilizes the "resource" parameter.


Is it correct my interpretation that if a request for an LRDD fails, the
server will remove it from the response?
if so what is the rationale for this behavior?

3) In Section 5.4

    A host MAY utilize one or more URIs that serve as aliases for the
    user's account, such as URIs that use the "http" URI scheme [2  ].  A
    WebFinger server MUST return substantially the same response to both
    an "acct" URI and any alias URI for the account, including the same
    set of link relations and properties.


I don't like the "MUST return substantially" expression, it leaves to 
much ambiguities.
You should explicitly say what are the expected differences if any.


/Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com



On 10/23/12 4:20 AM, Paul E. Jones wrote:
> Folks,
>
> I posted a slightly revised draft considering input received over the
> weekend.  You can see the differences are fairly minor, but they were
> changes I could easily make to improve the text.
>
> Paul
>
>> -----Original Message-----
>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>> bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
>> Sent: Monday, October 22, 2012 7:38 PM
>> To: i-d-announce@ietf.org
>> Cc: apps-discuss@ietf.org
>> Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-02.txt
>>
>>
>> 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           : WebFinger
>> 	Author(s)       : Paul E. Jones
>>                            Gonzalo Salgueiro
>>                            Joseph Smarr
>> 	Filename        : draft-ietf-appsawg-webfinger-02.txt
>> 	Pages           : 26
>> 	Date            : 2012-10-22
>>
>> Abstract:
>>     This specification defines the WebFinger protocol.  WebFinger may be
>>     used to discover information about people on the Internet, such as a
>>     person's personal profile address, identity service, telephone
>>     number, or preferred avatar.  WebFinger may also be used to discover
>>     information about objects on the network, such as the amount of toner
>>     in a printer or the physical location of a server.
>>
>>
>> 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-02
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-02
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>



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


  
    
  
  
    
Hi Paul,

      

      I have read the last 02 version and I have the following comments:

      

      1)

      In the Abstract, you define WebFinger

      

      
      
   WebFinger may be
   used to discover information about people on the Internet, such as a
   person's personal profile address, identity service, telephone
   number, or preferred avatar.

      however I found this definition slightly different from the one
      you provide in the Overview:

      

      
      
   WebFinger enables the discovery of information about accounts,
   devices, and other entities that are associated with a host.

      

      I think it would be better to align the two

      

      

      2) In Section 5.2 

      

      
      
       *  Collect and expand all resource-specific link relations,
          including those returned by querying for any LRDD link
          relations, discard any host-wide link relations, and return a
          complete resource descriptor following the processing rules in
          Section 4.2 of RFC 6415; and



      as a nit: above you should remove the "and".

      

   It is not the responsibility of the WebFinger server to verify, for
   example, that a URI pointing to a person's avatar is a valid URI.  If
   the WebFinger server needs to query an LRDD resource to collect
   additional resource-specific information, any errors (e.g., 500 or
   404) MUST be ignored by the server.  When a request for an LRDD
   fails, the server MUST NOT attempt to augment missing resource
   information or return a "template" type link relation to a client
   that utilizes the "resource" parameter.


      

      Is it correct my interpretation that if a request for an LRDD
      fails, the

      server will remove it from the response?

      if so what is the rationale for this behavior?

      

      3) In Section 5.4

      

      
      
   A host MAY utilize one or more URIs that serve as aliases for the
   user's account, such as URIs that use the "http" URI scheme [2].  A
   WebFinger server MUST return substantially the same response to both
   an "acct" URI and any alias URI for the account, including the same
   set of link relations and properties.

      

      I don't like the "MUST return substantially" expression, it leaves
      to much ambiguities.

      You should explicitly say what are the expected differences if
      any.

      

      

      /Salvatore

      

      
-- 
Salvatore Loreto, PhD
www.sloreto.com

      

      

      On 10/23/12 4:20 AM, Paul E. Jones wrote:

    

    

      
Folks,

I posted a slightly revised draft considering input received over the
weekend.  You can see the differences are fairly minor, but they were
changes I could easily make to improve the text.

Paul



      

        
-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: Monday, October 22, 2012 7:38 PM
To: i-d-announce@ietf.org
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-02.txt


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           : WebFinger
	Author(s)       : Paul E. Jones
                          Gonzalo Salgueiro
                          Joseph Smarr
	Filename        : draft-ietf-appsawg-webfinger-02.txt
	Pages           : 26
	Date            : 2012-10-22

Abstract:
   This specification defines the WebFinger protocol.  WebFinger may be
   used to discover information about people on the Internet, such as a
   person's personal profile address, identity service, telephone
   number, or preferred avatar.  WebFinger may also be used to discover
   information about objects on the network, such as the amount of toner
   in a printer or the physical location of a server.


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

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


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

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


      

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



    

    

    

  


--------------020402090101080003090301--

From paulej@packetizer.com  Sun Oct 28 12:39:27 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4187921F860E for ; Sun, 28 Oct 2012 12:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuGiD433D6WS for ; Sun, 28 Oct 2012 12:39:26 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 17E3D21F85FD for ; Sun, 28 Oct 2012 12:39:26 -0700 (PDT)
Received: from email.packetizer.com (dublin.packetizer.com [75.101.130.125]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9SJdN0b001964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Oct 2012 15:39:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351453164; bh=otHsoL/WtC/9XsIn/NxDy54HK52gaZVqbOaAaf91lpM=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Date:From:To: Cc:Subject:In-Reply-To:References:Message-ID; b=nlS+cN8aPn2DBaj8G0wXYbPSo//652AgVci/Jk36yjkwzgbbeQMB1p63Z/o1+lGsb 42MDpymMJ2Q55kv8tJEOqr/FeTNp9s3f3W01WudZZB0nmVcf7rVgGXmaFA63k0aTgw EG7QThi8CKbZBF2GE4otnDa2e1h3AAJGd5MZ7n6Y=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Sun, 28 Oct 2012 15:39:23 -0400
From: "Paul E. Jones" 
To: Melvin Carvalho 
In-Reply-To: 
References: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com> <5082C526.3050100@status.net> <00c501cdaf13$13ef6d30$3bce4790$@packetizer.com> <20121021093728.590d2898@bogo>    <094c01cdb4b3$6f78b620$4e6a2260$@packetizer.com> 
Message-ID: <616511fcbbf92d7b8c63aaadf7dc7b86@packetizer.com>
X-Sender: paulej@packetizer.com
User-Agent: Roundcube Webmail/0.5.3
Cc: webfinger@googlegroups.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-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, 28 Oct 2012 19:39:27 -0000

Melvin

On Sun, 28 Oct 2012 12:42:10 +0100, Melvin Carvalho wrote:
> On 28 October 2012 03:25, Paul E. Jones  wrote:
>
>> Melvin,
>>
>> > Webfinger is now in its fourth year and one thing that has
>> > remained constant is that it would be valuable on the internet to
>> > perform discovery on an email address to get more information
>> > such as blog address, homepage etc.
>>
>> Fully agree there!
>>
>> > I thought we had a consensus to use JRD and drop everything else.
>> > I strongly think this should be the stance of the spec.
>>
>> The only mandatory format is JRD now.  XRD still exists in RFC
>> 6415 and there are servers that use it.  We should not ignore it
>> entirely, so we speak about the fact that it already exists today.
>>  Going forward, though, no new implementation would be required to
>> support XRD.
>>
>> > There is
>> > one interesting aspect to this.  JRD has an advantage over XRD
>> in
>> > that you can have more than one subject per document, whereas in
>> > XRD you would be in (willful) violation of the XML Schema.  It
>> > turns out that this pretty much makes both XRD and RDF
>> > equivalents modulo a regular expression.  That is quite exciting
>> > and brings two worlds and big ecosystems together.
>>
>> The JRD syntax does NOT allow more than one Subject or Expires.
>>  If a JavaScript processor saw this:
>>    { "Subject" : "s1", "Subject" : "s2" }
>>
>> Then it would likely replace the value of "Subject" it saw
>> previously with "s2". I dont know what the standard says in this
>> case, but you will not have access to two "Subject" values.  So, it
>> is entirely consistent with XML.
>
> I think what you would do in the json is have several objects each
> with a single subject, its essentially entity attribute value which 
> is
> the generalization of but rdf and xrd. 

I do not think we should be redefining JRD at this point.  More 
importantly, I do not believe we need to. There are "aliases" and I 
think that is sufficient to serve the purpose.  The subject line should 
be the entity queried.

> The only real difference between XRD and RDF is that (according to 
> XML
> schema) recommends one object per document, but RDF is open ended. 
> JSON can easily handle mulbiple objects per document which means that
> one model can be translated to another and vice versa. 
>   
>
>>> Regarding XRD and content negotiation.  If you want XRD you
>> > should request it in the heade
>>
>> You can always request a format using standard content negotiation.
>>  However, we need a default value when anything is accepted or
>> something unknown is requested.  So, we have these as default
>> values:
>>    /.well-known/host-meta - defaults to XRD (iff XRD is
>> supported, else JRD)
>>    /.well-known/host-meta.json - defaults to JRD
>>
>> We are recommending use of host-meta.json, though a client capable
>> of accepting either and/or preferring XRD could use host-meta.
>>  Trying not to break whats there any more than necessary.  Be
>> mindful, too, that WebFinger does not replace RFC 6415.
>
> When dealing with a relatively bespoke format like xrd, the client
> should always set the content type, imho. 

You mean clients should always set the Accept header?  I would agree, 
but people rarely do.  Usually, it's set to */* or some such.  In any 
case, the header is there and we do mention that it can be set.
   
>> .  That is that browsers have no way of setting a
>> > content type.
>>
>> Thats not true.  This will do it:
>>   request.setRequestHeader("Accept", "application/xml");
>>
>> (Where "request" is an XML HTTP Request object.)
>>
>> And, one can check the return type like this:
>>   Request.getResponseHeader("Content-Type");
>>
>> That said, there might be some who find the work to set the
>> "Accept" header just one too many lines of code ;-) I dont know.  I
>> always use the Accept header when I write web interface code.
>>
>> Nonetheless, we do have defaults specified "just in case" (or to
>> help the lazy programmer).
>>
>> Ah yes, what I meant to say was that the browser doesnt normally
>> send a content type when click
> rlink.
>
> Accept header is too many lines of code, it should only be 1? 
> Hopefully something even lazy programmers can handle :)

It is one line of code.  I'm confused :-)

This is the one line that would be set in JavaScript:
   request.setRequestHeader("Accept", "application/json");

 
>  > So the any default should be browser friendly if
>  > specified.  As far as I
>
>> as the stand out choices.  I dont think its necessary to
>> > specify a default in this version of the spec.
>>
>> Im confused. You are suggesting that RDFa should be a default?
>>  One could certainly build a server to return RDFa or anything
>> else, but wed have to specify exactly what the response should look
>> like.  Given folks wanted one format we go forward with, I do not
>> dare want to suggest opening that can of worms again :-)
>>
>> No, I think that there should be no default set at all.  The point
>> I was making above is that the main benefit from a default content
>> type is for the case where the client is *unable* to easily
> at is the case of the browser hyperlink.  So since thats not part of
> the use cases, it need not be covered now.  in futuBut say re, there
> may be a use case oriented around clicking from a hyperlink to a
> webfinger record, you never know ..

You really think the resources should have no default format?

We really must specify what the default value should be.  I think the 
specified defaults in the document are reasonable and will lead to 
consistent implementations.  If the "Accept" header has "*/*" (which is 
fairly common practice), then at least we can predict the results.

    
>> Tel URIs are not useful for WebFinger since, as you note, there is
>> no associated host information.  However, we should allow any URI
>> that does have a domain part.  After all, the purpose is to go to
>> the server and say "tell me about this URI".  If the server knows,
>> it will provide an answer.  If the server has no information on the
>> URI, it will return a 404.
>>
> Sure, tho im not sure the language in the spec, but I guess it
> should point out the WF is only oriented at those that have a domain
> part, or list the ones that are valid?

I think this is pretty clear in the spec already, if not obvious on the 
face of it.  For example, bullet point 3 in Section 3 speaks of "URI at 
the host" and gives examples.  However, if we add text, I think the 
right place would be Section 5.4 where we talk about WebFinger and URIs. 
Perhaps we could add a sentence to the end of the first paragraph where 
we talk about WebFinger being URI scheme agnostic?  I'm not sure what to 
add, though.  Suggestions?
   
>> This is not dereferencing an HTTP URI, but discovering information
>> *about* the URI.  This is quite different.
>>
> This is possible but there are well established methods for getting
> information about a URI.  Essentially thats what the last 10 years
> of work by the w3c has focused on.

This could become a politically charged issue, but what comes to mind 
is "the wonderful thing about standards is that there are so many from 
which to choose" :-)

Perhaps another thing that comes to mind is "pick the right tool for 
the job".  If I want to know how about acct:paulej@packetizer.com, I'm 
going to use WF. If I want to know how to configure my email client, I 
might use WF with mailto:paulej@packetizer.com, but there might be a 
better set of tools.  We have a spec that defines this via DNS.  WF 
might prove to be the better tool, but there might be something else 
more preferred.

Note: if I missed anything, feel free to repeat it.  I can see your 
email in my client OK, but when I reply, it's challenging unless I use 
color-coding in Outlook.  So, I switched to a different email client and 
then it did not always show your responses clearly to me.  I like HTML 
for email, but it does make it hard for inline commenting, at least with 
Outlook.  Wish Microsoft would improve that. :-/

Paul


From melvincarvalho@gmail.com  Sun Oct 28 12:49:51 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF34C21F85C1 for ; Sun, 28 Oct 2012 12:49:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7TkXVhBZhdM for ; Sun, 28 Oct 2012 12:49:50 -0700 (PDT)
Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B52621F853A for ; Sun, 28 Oct 2012 12:49:50 -0700 (PDT)
Received: by mail-ia0-f172.google.com with SMTP id x24so1699157iak.31 for ; Sun, 28 Oct 2012 12:49:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LYJZ5RJHij00UDessgjQbpVSwMFFeuyhp4KKzmIiwC4=; b=MYzjJHOz3DH5MAxOXaZfXVULAfLivKoovCU/xyOfhmWxcKQ9ahWBPm4POGnBKfpRMy B+s4NxzYXmfMi97nlxz/Vv7ujvCFdawZ+vClsZZMEFSj2zf0zh7BtsXeu3TaDuKBFtCb NCcSFTYG0vLYtwgv0FEMN/Fp3QB7ghuzx/ymB0hRiaukkxAQXP/HCbp5dH+WB+sKgHki H3yr1S3DtEEHGZ+VAMU2OiGKCk46tg1RWvgqvZ5C1CeugtHjst/18a3JDquwJCU3zvMT CKZ+5UHV0SLVirfV7qZittUipFGGXkuQklL+SROCLKLkfUlKOQgRafOqfr4Lh4iyKKy+ 603w==
MIME-Version: 1.0
Received: by 10.50.202.73 with SMTP id kg9mr4305693igc.51.1351453789702; Sun, 28 Oct 2012 12:49:49 -0700 (PDT)
Received: by 10.42.247.129 with HTTP; Sun, 28 Oct 2012 12:49:49 -0700 (PDT)
In-Reply-To: <616511fcbbf92d7b8c63aaadf7dc7b86@packetizer.com>
References: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com> <5082C526.3050100@status.net> <00c501cdaf13$13ef6d30$3bce4790$@packetizer.com> <20121021093728.590d2898@bogo>    <094c01cdb4b3$6f78b620$4e6a2260$@packetizer.com>  <616511fcbbf92d7b8c63aaadf7dc7b86@packetizer.com>
Date: Sun, 28 Oct 2012 20:49:49 +0100
Message-ID: 
From: Melvin Carvalho 
To: "Paul E. Jones" 
Content-Type: multipart/alternative; boundary=f46d0447a25110cb1104cd23db90
Cc: webfinger@googlegroups.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-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, 28 Oct 2012 19:49:51 -0000

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

On 28 October 2012 20:39, Paul E. Jones  wrote:

> Melvin
>
> On Sun, 28 Oct 2012 12:42:10 +0100, Melvin Carvalho wrote:
>
>> On 28 October 2012 03:25, Paul E. Jones  wrote:
>>
>>  Melvin,
>>>
>>> > Webfinger is now in its fourth year and one thing that has
>>> > remained constant is that it would be valuable on the internet to
>>> > perform discovery on an email address to get more information
>>> > such as blog address, homepage etc.
>>>
>>> Fully agree there!
>>>
>>> > I thought we had a consensus to use JRD and drop everything else.
>>> > I strongly think this should be the stance of the spec.
>>>
>>> The only mandatory format is JRD now.  XRD still exists in RFC
>>> 6415 and there are servers that use it.  We should not ignore it
>>> entirely, so we speak about the fact that it already exists today.
>>>  Going forward, though, no new implementation would be required to
>>> support XRD.
>>>
>>> > There is
>>> > one interesting aspect to this.  JRD has an advantage over XRD
>>> in
>>> > that you can have more than one subject per document, whereas in
>>> > XRD you would be in (willful) violation of the XML Schema.  It
>>> > turns out that this pretty much makes both XRD and RDF
>>> > equivalents modulo a regular expression.  That is quite exciting
>>> > and brings two worlds and big ecosystems together.
>>>
>>> The JRD syntax does NOT allow more than one Subject or Expires.
>>>  If a JavaScript processor saw this:
>>>    { "Subject" : "s1", "Subject" : "s2" }
>>>
>>> Then it would likely replace the value of "Subject" it saw
>>> previously with "s2". I dont know what the standard says in this
>>>
>>> case, but you will not have access to two "Subject" values.  So, it
>>> is entirely consistent with XML.
>>>
>>
>> I think what you would do in the json is have several objects each
>> with a single subject, its essentially entity attribute value which is
>>
>> the generalization of but rdf and xrd.
>>
>
> I do not think we should be redefining JRD at this point.  More
> importantly, I do not believe we need to. There are "aliases" and I think
> that is sufficient to serve the purpose.  The subject line should be the
> entity queried.
>

Sure


>
>  The only real difference between XRD and RDF is that (according to XML
>> schema) recommends one object per document, but RDF is open ended.
>> JSON can easily handle mulbiple objects per document which means that
>> one model can be translated to another and vice versa.
>>
>>
>>  Regarding XRD and content negotiation.  If you want XRD you
>>>>
>>> > should request it in the heade
>>>
>>> You can always request a format using standard content negotiation.
>>>  However, we need a default value when anything is accepted or
>>> something unknown is requested.  So, we have these as default
>>> values:
>>>    /.well-known/host-meta - defaults to XRD (iff XRD is
>>> supported, else JRD)
>>>    /.well-known/host-meta.json - defaults to JRD
>>>
>>> We are recommending use of host-meta.json, though a client capable
>>> of accepting either and/or preferring XRD could use host-meta.
>>>  Trying not to break whats there any more than necessary.  Be
>>>
>>> mindful, too, that WebFinger does not replace RFC 6415.
>>>
>>
>> When dealing with a relatively bespoke format like xrd, the client
>> should always set the content type, imho.
>>
>
> You mean clients should always set the Accept header?  I would agree, but
> people rarely do.  Usually, it's set to */* or some such.  In any case, the
> header is there and we do mention that it can be set.
>

I mean the spec should say that the client should set accept the accept
header.  If they dont follow that advice behaviour will be unspecified.


>
>
>> .  That is that browsers have no way of setting a
>>> > content type.
>>>
>>> Thats not true.  This will do it:
>>>
>>>   request.setRequestHeader("**Accept", "application/xml");
>>>
>>> (Where "request" is an XML HTTP Request object.)
>>>
>>> And, one can check the return type like this:
>>>   Request.getResponseHeader("**Content-Type");
>>>
>>> That said, there might be some who find the work to set the
>>> "Accept" header just one too many lines of code ;-) I dont know.  I
>>>
>>> always use the Accept header when I write web interface code.
>>>
>>> Nonetheless, we do have defaults specified "just in case" (or to
>>> help the lazy programmer).
>>>
>>> Ah yes, what I meant to say was that the browser doesnt normally
>>> send a content type when click
>>>
>> rlink.
>>
>>
>> Accept header is too many lines of code, it should only be 1?
>> Hopefully something even lazy programmers can handle :)
>>
>
> It is one line of code.  I'm confused :-)
>
> This is the one line that would be set in JavaScript:
>   request.setRequestHeader("**Accept", "application/json");
>

Yes similar in PHP etc.


>
>
>
>>  > So the any default should be browser friendly if
>>  > specified.  As far as I
>>
>>  as the stand out choices.  I dont think its necessary to
>>>
>>> > specify a default in this version of the spec.
>>>
>>> Im confused. You are suggesting that RDFa should be a default?
>>>  One could certainly build a server to return RDFa or anything
>>> else, but wed have to specify exactly what the response should look
>>>
>>> like.  Given folks wanted one format we go forward with, I do not
>>> dare want to suggest opening that can of worms again :-)
>>>
>>> No, I think that there should be no default set at all.  The point
>>> I was making above is that the main benefit from a default content
>>> type is for the case where the client is *unable* to easily
>>>
>> at is the case of the browser hyperlink.  So since thats not part of
>> the use cases, it need not be covered now.  in futuBut say re, there
>>
>> may be a use case oriented around clicking from a hyperlink to a
>> webfinger record, you never know ..
>>
>
> You really think the resources should have no default format?
>
> We really must specify what the default value should be.  I think the
> specified defaults in the document are reasonable and will lead to
> consistent implementations.  If the "Accept" header has "*/*" (which is
> fairly common practice), then at least we can predict the results.


No problem with JRD being the default in practice.  Relying on defaults
such as */* can simply be out of scope of the spec.


>
>
>
>
>> Tel URIs are not useful for WebFinger since, as you note, there is
>>> no associated host information.  However, we should allow any URI
>>> that does have a domain part.  After all, the purpose is to go to
>>> the server and say "tell me about this URI".  If the server knows,
>>> it will provide an answer.  If the server has no information on the
>>> URI, it will return a 404.
>>>
>>>  Sure, tho im not sure the language in the spec, but I guess it
>> should point out the WF is only oriented at those that have a domain
>> part, or list the ones that are valid?
>>
>
> I think this is pretty clear in the spec already, if not obvious on the
> face of it.  For example, bullet point 3 in Section 3 speaks of "URI at the
> host" and gives examples.  However, if we add text, I think the right place
> would be Section 5.4 where we talk about WebFinger and URIs. Perhaps we
> could add a sentence to the end of the first paragraph where we talk about
> WebFinger being URI scheme agnostic?  I'm not sure what to add, though.
>  Suggestions?
>

Unsure on this one.  I guess if the reviewers at the IETF think it's self
evident, that should be fine.  There's so many URI schemes today that it's
hard to even know if there are grey areas on this one.


>
>
>> This is not dereferencing an HTTP URI, but discovering information
>>> *about* the URI.  This is quite different.
>>>
>>>  This is possible but there are well established methods for getting
>> information about a URI.  Essentially thats what the last 10 years
>>
>> of work by the w3c has focused on.
>>
>
> This could become a politically charged issue, but what comes to mind is
> "the wonderful thing about standards is that there are so many from which
> to choose" :-)
>

lol ... well there's always a degree of politics in standards and discovery
has been one of the more contentious ones ... the point i make above is
that the different serializations are very close to each other, so
hopefully we can all get along! :)

it really just related to dereferencing an HTTP URI ... if webfinger is one
more way to do that, then so much the better, I guess more choice doesnt
hurt, but the W3C has innovated extensively in this space, as it's a core
focus of that standards body


>
> Perhaps another thing that comes to mind is "pick the right tool for the
> job".  If I want to know how about acct:paulej@packetizer.com, I'm going
> to use WF. If I want to know how to configure my email client, I might use
> WF with mailto:paulej@packetizer.com, but there might be a better set of
> tools.  We have a spec that defines this via DNS.  WF might prove to be the
> better tool, but there might be something else more preferred.
>

sure

>
> Note: if I missed anything, feel free to repeat it.  I can see your email
> in my client OK, but when I reply, it's challenging unless I use
> color-coding in Outlook.  So, I switched to a different email client and
> then it did not always show your responses clearly to me.  I like HTML for
> email, but it does make it hard for inline commenting, at least with
> Outlook.  Wish Microsoft would improve that. :-/
>

oops apologies, thanks for pointing this out, I was not aware of that ... I
tend to use the gmail web client for most mail ... I'll try to ensure my
text is more readable going forward!


>
> Paul
>
>

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



On 28 October 2012 20:39, Paul E. Jones =
<paulej@packetizer.com> wrote:

Melvin



On Sun, 28 Oct 2012 12:42:10 +0100, Melvin Carvalho wrote:



On 28 October 2012 03:25, Paul E. Jones =A0wrote:





Melvin,



> Webfinger is now in its fourth year and one thing that has

> remained constant is that it would be valuable on the internet to

> perform discovery on an email address to get more information

> such as blog address, homepage etc.



Fully agree there!



> I thought we had a consensus to use JRD and drop everything else.

> I strongly think this should be the stance of the spec.



The only mandatory format is JRD now. =A0XRD still exists in RFC

6415 and there are servers that use it. =A0We should not ignore it

entirely, so we speak about the fact that it already exists today.

=A0Going forward, though, no new implementation would be required to

support XRD.



> There is

> one interesting aspect to this. =A0JRD has an advantage over XRD

in

> that you can have more than one subject per document, whereas in

> XRD you would be in (willful) violation of the XML Schema. =A0It

> turns out that this pretty much makes both XRD and RDF

> equivalents modulo a regular expression. =A0That is quite exciting

> and brings two worlds and big ecosystems together.



The JRD syntax does NOT allow more than one Subject or Expires.

=A0If a JavaScript processor saw this:

=A0 =A0{ "Subject" : "s1", "Subject" : "=
s2" }



Then it would likely replace the value of "Subject" it saw

previously with "s2". I dont know what the standard says in this<=
div class=3D"im">

case, but you will not have access to two "Subject" values. =A0So=
, it

is entirely consistent with XML.





I think what you would do in the json is have several objects each

with a single subject, its essentially entity attribute value which is


the generalization of but rdf and xrd.=A0





I do not think we should be redefining JRD at this point. =A0More important=
ly, I do not believe we need to. There are "aliases" and I think =
that is sufficient to serve the purpose. =A0The subject line should be the =
entity queried.



Sure
=A0





The only real difference between XRD and RDF is that (according to XML

schema) recommends one object per document, but RDF is open ended.=A0

JSON can easily handle mulbiple objects per document which means that

one model can be translated to another and vice versa.=A0

=A0=A0






Regarding XRD and content negotiation. =A0If you want XRD you



> should request it in the heade



You can always request a format using standard content negotiation.

=A0However, we need a default value when anything is accepted or

something unknown is requested. =A0So, we have these as default

values:

=A0 =A0/.well-known/host-meta - defaults to XRD (iff XRD is

supported, else JRD)

=A0 =A0/.well-known/host-meta.json - defaults to JRD



We are recommending use of host-meta.json, though a client capable

of accepting either and/or preferring XRD could use host-meta.

=A0Trying not to break whats there any more than necessary. =A0Be


mindful, too, that WebFinger does not replace RFC 6415.





When dealing with a relatively bespoke format like xrd, the client

should always set the content type, imho.=A0





You mean clients should always set the Accept header? =A0I would agree, but=
 people rarely do. =A0Usually, it's set to */* or some such. =A0In any =
case, the header is there and we do mention that it can be set.



I mean the spec should say that the client should set accept the a=
ccept header.=A0 If they dont follow that advice behaviour will be unspecif=
ied.
=A0


=A0=A0




. =A0That is that browsers have no way of setting a

> content type.



Thats not true. =A0This will do it:


=A0 request.setRequestHeader("Accept", "application/x=
ml");



(Where "request" is an XML HTTP Request object.)



And, one can check the return type like this:

=A0 Request.getResponseHeader("Content-Type");



That said, there might be some who find the work to set the

"Accept" header just one too many lines of code ;-) I dont know. =
=A0I


always use the Accept header when I write web interface code.



Nonetheless, we do have defaults specified "just in case" (or to<=
br>
help the lazy programmer).



Ah yes, what I meant to say was that the browser doesnt normally

send a content type when click



rlink.




Accept header is too many lines of code, it should only be 1?=A0

Hopefully something even lazy programmers can handle :)





It is one line of code. =A0I'm confused :-)



This is the one line that would be set in JavaScript:

=A0 request.setRequestHeader("Accept", "application/j=
son");

Yes similar in PHP etc.
=A0




=A0



=A0> So the any default should be browser friendly if

=A0> specified. =A0As far as I





as the stand out choices. =A0I dont think its necessary to


> specify a default in this version of the spec.



Im confused. You are suggesting that RDFa should be a default?

=A0One could certainly build a server to return RDFa or anything

else, but wed have to specify exactly what the response should look


like. =A0Given folks wanted one format we go forward with, I do not

dare want to suggest opening that can of worms again :-)



No, I think that there should be no default set at all.=A0 The point

I was making above is that the main benefit from a default content

type is for the case where the client is *unable* to easily



at is the case of the browser hyperlink.=A0 So since thats not part of

the use cases, it need not be covered now.=A0 in futuBut say re, there


may be a use case oriented around clicking from a hyperlink to a

webfinger record, you never know ..





You really think the resources should have no default format?



We really must specify what the default value should be. =A0I think the spe=
cified defaults in the document are reasonable and will lead to consistent =
implementations. =A0If the "Accept" header has "*/*" (w=
hich is fairly common practice), then at least we can predict the results.<=
/blockquote>


No problem with JRD being the default in practice.=A0 Relying on d=
efaults such as */* can simply be out of scope of the spec.=A0 
=A0






=A0 =A0



Tel URIs are not useful for WebFinger since, as you note, there is

no associated host information. =A0However, we should allow any URI

that does have a domain part. =A0After all, the purpose is to go to

the server and say "tell me about this URI". =A0If the server kno=
ws,

it will provide an answer. =A0If the server has no information on the

URI, it will return a 404.





Sure, tho im not sure the language in the spec, but I guess it

should point out the WF is only oriented at those that have a domain

part, or list the ones that are valid?





I think this is pretty clear in the spec already, if not obvious on the fac=
e of it. =A0For example, bullet point 3 in Section 3 speaks of "URI at=
 the host" and gives examples. =A0However, if we add text, I think the=
 right place would be Section 5.4 where we talk about WebFinger and URIs. P=
erhaps we could add a sentence to the end of the first paragraph where we t=
alk about WebFinger being URI scheme agnostic? =A0I'm not sure what to =
add, though. =A0Suggestions?



Unsure on this one.=A0 I guess if the reviewers at th=
e IETF think it's self evident, that should be fine.=A0 There's so =
many URI schemes today that it's hard to even know if there are grey ar=
eas on this one.=A0 

=A0

=A0=A0




This is not dereferencing an HTTP URI, but discovering information

*about* the URI. =A0This is quite different.





This is possible but there are well established methods for getting

information about a URI.=A0 Essentially thats what the last 10 years


of work by the w3c has focused on.





This could become a politically charged issue, but what comes to mind is &q=
uot;the wonderful thing about standards is that there are so many from whic=
h to choose" :-)

lol ... well there's alw=
ays a degree of politics in standards and discovery has been one of the mor=
e contentious ones ... the point i make above is that the different seriali=
zations are very close to each other, so hopefully we can all get along! :)=



it really just related to dereferencing an HTTP URI ... if webfinger is=
 one more way to do that, then so much the better, I guess more choice does=
nt hurt, but the W3C has innovated extensively in this space, as it's a=
 core focus of that standards body

=A0



Perhaps another thing that comes to mind is "pick the right tool for t=
he job". =A0If I want to know how about acct:paulej@packetizer.com, I'm=
 going to use WF. If I want to know how to configure my email client, I mig=
ht use WF with mailto:paulej@packetizer.com, but there might be a better set of tools. =
=A0We have a spec that defines this via DNS. =A0WF might prove to be the be=
tter tool, but there might be something else more preferred.



sure 



Note: if I missed anything, feel free to repeat it. =A0I can see your email=
 in my client OK, but when I reply, it's challenging unless I use color=
-coding in Outlook. =A0So, I switched to a different email client and then =
it did not always show your responses clearly to me. =A0I like HTML for ema=
il, but it does make it hard for inline commenting, at least with Outlook. =
=A0Wish Microsoft would improve that. :-/



oops apologies, thanks for pointing thi=
s out, I was not aware of that ... I tend to use the gmail web client for m=
ost mail ... I'll try to ensure my text is more readable going forward!=


=A0



Paul







--f46d0447a25110cb1104cd23db90--

From paulej@packetizer.com  Sun Oct 28 13:25:51 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4101321F84B5 for ; Sun, 28 Oct 2012 13:25:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.874
X-Spam-Level: 
X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.724,  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 Xw5tbGJ5XAkh for ; Sun, 28 Oct 2012 13:25:47 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA2B21F84AD for ; Sun, 28 Oct 2012 13:25:47 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9SKPglj003917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Oct 2012 16:25:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351455943; bh=QdxziG7n3dMfTxIoWN+g+TtTChYSYlh6yCgNaiBY/UI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=A/XJKDHpoDxCXfLFlWOm8f3ph97bfWSLerSgIQLdFVl4EzYJm9wDz8NZUiSqonXXa BeyAXSfzX51jHqtkIf7JC+f3kIcXH9MPURHs5SZdrj54mXnHbvKnLfm989VTAJy9qE qoHs0M6Wage14aQwSQ5N79wXj2ovshEylSezU9jw=
From: "Paul E. Jones" 
To: "'Salvatore Loreto'" 
References: <031801cdb0bc$8a5048f0$9ef0dad0$@packetizer.com> <508D812C.5040708@ericsson.com>
In-Reply-To: <508D812C.5040708@ericsson.com>
Date: Sun, 28 Oct 2012 16:25:46 -0400
Message-ID: <09b801cdb54a$69abb340$3d0319c0$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_09B9_01CDB528.E29C0F10"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKlQ0K+dU+mmhgivh5zej+ojwmWyQFDJ+TJlhXuvAA=
Content-Language: en-us
Cc: webfinger@googlegroups.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Updated: draft-ietf-appsawg-webfinger-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: Sun, 28 Oct 2012 20:25:51 -0000

This is a multipart message in MIME format.

------=_NextPart_000_09B9_01CDB528.E29C0F10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Sal,

 

For (1), what is not aligned.  I saw in the abstract I used "one the
network" rather than "on the Internet" in once place, so I want to change
that.  Otherwise, it's different wording, but the same message, I think.
Perhaps change "objects" in the Abstract to "other entities"?  What were you
thinking in terms of alignment?

 

For (2), the "and" is easy.  How to handle issues where the WF server fails
to retrieve LRDD information is more challenging.  The rationale was simply
that we needed to provide an answer to the question. ;-)  We should decide
what the appropriate action is.  We can either ignore it, which might result
in a partial set of link relations or no link relations.  That's the current
wording.  The other option is to return some specific 5xx error code.  I'm
happy with whatever the group proposes here.

 

Related to (2), if the server is requesting 5 pieces of information in the
background and one request results in 5xx, do we return 5xx?  What if four
requests return a reply and one returns 404?  Does the server just ignore
the 404? Or does it return 5xx?  What if there are a mix of errors?

 

For (3), I like "substantially" myself, because it does tell me something.
But, your point is taken.  Rather than removing "substantially", how about I
add the following sentence right after:

 

The only elements in the response that MAY be different include "subject",
"expires", and "aliases".

 

I think it is only those three that are affected.  The expires element might
change with every request, though if issued in parallel might be the same.
The subject line must change, of course, and if the subject changes, then
the set of aliases changes. 

 

Paul

 

From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] 
Sent: Sunday, October 28, 2012 3:02 PM
To: Paul E. Jones
Cc: apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: [apps-discuss] Updated: draft-ietf-appsawg-webfinger-02.txt

 

Hi Paul,

I have read the last 02 version and I have the following comments:

1)
In the Abstract, you define WebFinger

   WebFinger may be
   used to discover information about people on the Internet, such as a
   person's personal profile address, identity service, telephone
   number, or preferred avatar.

however I found this definition slightly different from the one you provide
in the Overview:

   WebFinger enables the discovery of information about accounts,
   devices, and other entities that are associated with a host.


I think it would be better to align the two


2) In Section 5.2 

       *  Collect and expand all resource-specific link relations,
          including those returned by querying for any LRDD link
          relations, discard any host-wide link relations, and return a
          complete resource descriptor following the processing rules in
          Section   4.2 of
RFC 6415; and
 

as a nit: above you should remove the "and".

 
 
   It is not the responsibility of the WebFinger server to verify, for
   example, that a URI pointing to a person's avatar is a valid URI.  If
   the WebFinger server needs to query an LRDD resource to collect
   additional resource-specific information, any errors (e.g., 500 or
   404) MUST be ignored by the server.  When a request for an LRDD
   fails, the server MUST NOT attempt to augment missing resource
   information or return a "template" type link relation to a client
   that utilizes the "resource" parameter.


Is it correct my interpretation that if a request for an LRDD fails, the
server will remove it from the response?
if so what is the rationale for this behavior?

3) In Section 5.4

   A host MAY utilize one or more URIs that serve as aliases for the
   user's account, such as URIs that use the "http" URI scheme [2
 ].  A
   WebFinger server MUST return substantially the same response to both
   an "acct" URI and any alias URI for the account, including the same
   set of link relations and properties.


I don't like the "MUST return substantially" expression, it leaves to much
ambiguities.
You should explicitly say what are the expected differences if any.


/Salvatore




-- 
Salvatore Loreto, PhD
www.sloreto.com



On 10/23/12 4:20 AM, Paul E. Jones wrote:

Folks,
 
I posted a slightly revised draft considering input received over the
weekend.  You can see the differences are fairly minor, but they were
changes I could easily make to improve the text.
 
Paul
 

-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: Monday, October 22, 2012 7:38 PM
To: i-d-announce@ietf.org
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-02.txt
 
 
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           : WebFinger
  Author(s)       : Paul E. Jones
                          Gonzalo Salgueiro
                          Joseph Smarr
  Filename        : draft-ietf-appsawg-webfinger-02.txt
  Pages           : 26
  Date            : 2012-10-22
 
Abstract:
   This specification defines the WebFinger protocol.  WebFinger may be
   used to discover information about people on the Internet, such as a
   person's personal profile address, identity service, telephone
   number, or preferred avatar.  WebFinger may also be used to discover
   information about objects on the network, such as the amount of toner
   in a printer or the physical location of a server.
 
 
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-02
 
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-02
 
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

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

 


------=_NextPart_000_09B9_01CDB528.E29C0F10
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Sal,
 
For (1), what is not aligned.  I saw in the abstract I used =
“one the network” rather than “on the Internet” =
in once place, so I want to change that.  Otherwise, it’s =
different wording, but the same message, I think.  Perhaps change =
“objects” in the Abstract to “other =
entities”?  What were you thinking in terms of =
alignment?
 
For (2), the “and” is easy.  How to handle issues =
where the WF server fails to retrieve LRDD information is more =
challenging.  The rationale was simply that we needed to provide an =
answer to the question. ;-)  We should decide what the appropriate =
action is.  We can either ignore it, which might result in a =
partial set of link relations or no link relations.  That’s =
the current wording.  The other option is to return some specific =
5xx error code.  I’m happy with whatever the group proposes =
here.
 
Related to (2), if the server is requesting 5 pieces of information =
in the background and one request results in 5xx, do we return =
5xx?  What if four requests return a reply and one returns =
404?  Does the server just ignore the 404? Or does it return =
5xx?  What if there are a mix of errors?
 
For (3), I like “substantially” myself, because it does =
tell me something.  But, your point is taken.  Rather than =
removing “substantially”, how about I add the following =
sentence right after:
 
The only elements in the response that MAY be different include =
“subject”, “expires”, and =
“aliases”.
 
I think it is only those three that are affected.  The expires =
element might change with every request, though if issued in parallel =
might be the same.  The subject line must change, of course, and if =
the subject changes, then the set of aliases changes. =

 
Paul
 
From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] =

Sent: Sunday, October 28, 2012 3:02 PM
To: Paul E. =
Jones
Cc: apps-discuss@ietf.org; =
webfinger@googlegroups.com
Subject: Re: [apps-discuss] =
Updated: =
draft-ietf-appsawg-webfinger-02.txt
 
Hi Paul,

I have read the last 02 =
version and I have the following comments:

1)
In the Abstract, =
you define WebFinger
   WebFinger may =
be
   used to discover information about =
people on the Internet, such as a
   =
person's personal profile address, identity service, =
telephone
   number, or preferred =
avatar.
however I found this definition slightly =
different from the one you provide in the =
Overview:
   WebFinger enables the =
discovery of information about =
accounts,
   devices, and other entities =
that are associated with a host.

I think it would be better to align =
the two


2) In Section 5.2 =

       *  =
Collect and expand all resource-specific link =
relations,
    =
      including those returned by querying =
for any LRDD =
link
        =
;  relations, discard any host-wide link relations, and return =
a
        &n=
bsp; complete resource descriptor following the processing rules =
in
        &=
nbsp; Section 4.2 =
of RFC 6415; and
 
as a nit: above you should remove the =
"and".
 
&nbs=
p;
   It is not the responsibility of the =
WebFinger server to verify, for
   =
example, that a URI pointing to a person's avatar is a valid URI.  =
If
   the WebFinger server needs to query =
an LRDD resource to collect
   additional =
resource-specific information, any errors (e.g., 500 =
or
   404) MUST be ignored by the =
server.  When a request for an =
LRDD
   fails, the server MUST NOT =
attempt to augment missing resource
   =
information or return a "template" type link relation to a =
client
   that utilizes the =
"resource" parameter.

Is it correct my interpretation that =
if a request for an LRDD fails, the
server will remove it from the =
response?
if so what is the rationale for this behavior?

3) In =
Section 5.4
   A host MAY utilize one or =
more URIs that serve as aliases for =
the
   user's account, such as URIs that =
use the "http" URI scheme [2].  A
   =
WebFinger server MUST return substantially the same response to =
both
   an "acct" URI and any =
alias URI for the account, including the =
same
   set of link relations and =
properties.

I don't like the =
"MUST return substantially" expression, it leaves to much =
ambiguities.
You should explicitly say what are the expected =
differences if =
any.


/Salvatore


-- =

Salvatore Loreto, PhD
www.sloreto.com


On 10/23/12 4:20 AM, Paul E. Jones =
wrote:
Folks,
 
I posted a slightly revised draft =
considering input received over the
weekend.  =
You can see the differences are fairly minor, but they =
were
changes I could easily make to improve the =
text.
 
Paul
 
-----Original =
Message-----
From: apps-discuss-bounces@ietf.o=
rg [mailto:apps-discuss-
bounces@ietf.org] On Behalf Of =
internet-drafts@ietf.org
Sent: Monday, October 22, 2012 7:38 =
PM
To: i-d-announce@ietf.org
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: =
draft-ietf-appsawg-webfinger-02.txt
 
 
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           : =
WebFinger
  =
Author(s)       : Paul E. =
Jones
       &nbs=
p;            =
;      Gonzalo =
Salgueiro
       =
            &=
nbsp;      Joseph =
Smarr
  =
Filename        : =
draft-ietf-appsawg-webfinger-02.txt
  =
Pages           : =
26
  Date =
           : =
2012-10-22
 
Abstract:
   This specification defines the WebFinger =
protocol.  WebFinger may be
   used =
to discover information about people on the Internet, such as =
a
   person's personal profile address, =
identity service, telephone
   number, or =
preferred avatar.  WebFinger may also be used to =
discover
   information about objects on =
the network, such as the amount of =
toner
   in a printer or the physical =
location of a =
server.
 
 
The IETF datatracker status page for this draft =
is:
ht=
tps://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-02
 
A diff from the previous version is =
available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-02=

 
 
=

Internet-Drafts are also available by anonymous FTP =
at:
ftp://ftp.ietf.org/internet-=
drafts/
 
____________=
___________________________________
apps-discuss =
mailing list
apps-discuss@ietf.org
https://www.i=
etf.org/mailman/listinfo/apps-discuss
 
__________________________________________=
_____
apps-discuss mailing =
list
apps-discuss@ietf.org
https://www.i=
etf.org/mailman/listinfo/apps-discuss
 =
;
 

------=_NextPart_000_09B9_01CDB528.E29C0F10--


From mnot@mnot.net  Sun Oct 28 16:35:14 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37AB21F85D2 for ; Sun, 28 Oct 2012 16:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 jvZwClr4-d9D for ; Sun, 28 Oct 2012 16:35:14 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 240ED21F860B for ; Sun, 28 Oct 2012 16:35:14 -0700 (PDT)
Received: from [192.168.1.82] (unknown [118.209.87.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 12BE222E259; Sun, 28 Oct 2012 19:35:04 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham 
In-Reply-To: <9EAB966B-4B21-4CF9-BFEB-4DAD639FE81C@vpnc.org>
Date: Mon, 29 Oct 2012 10:35:02 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9EAB966B-4B21-4CF9-BFEB-4DAD639FE81C@vpnc.org>
To: Paul Hoffman 
X-Mailer: Apple Mail (2.1499)
Cc: "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] Solving the file format problem
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Oct 2012 23:35:14 -0000

The fact that =
 does not list =
 says something; =
I'm not sure who about, but I doubt it's good.


On 28/10/2012, at 3:43 AM, Paul Hoffman  wrote:

> There are many people on this list that care a lot about Internet =
applications but are not active in IETF protocol work who might be =
wondering how they can help. If you are such a person (or you are active =
in the IETF *and* you care about the problem of having a zillion file =
formats), maybe take a look at . This =
is a one-month sprint to add to the catalog of formats from the past and =
present and document or create conversion programs that will allow =
someone holding an item that is in a "dead" format to retrieve the =
useful data from it. A recent blog post from the organizer is here: =
. There are lots of =
opportunities for people on all levels of ability.
>=20
> To be clear, the effort is about formats that are in stored files, not =
on-the-wire protocols. Although the latter is the focus of the IETF =
Applications Area, the former was important to us not that many decades =
ago.
>=20
> --Paul Hoffman
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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




From paul.hoffman@vpnc.org  Sun Oct 28 16:58:08 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302BD21F8549 for ; Sun, 28 Oct 2012 16:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhPMM5XmfO2l for ; Sun, 28 Oct 2012 16:58:07 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 767D121F851C for ; Sun, 28 Oct 2012 16:58:07 -0700 (PDT)
Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9SNw5kE020275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Oct 2012 16:58:06 -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: Sun, 28 Oct 2012 16:58:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <18D4E4AB-FE5D-4D66-A076-19BF81830845@vpnc.org>
References: <9EAB966B-4B21-4CF9-BFEB-4DAD639FE81C@vpnc.org> 
To: Mark Nottingham 
X-Mailer: Apple Mail (2.1499)
Cc: "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] Solving the file format problem
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Oct 2012 23:58:08 -0000

On Oct 28, 2012, at 4:35 PM, Mark Nottingham  wrote:

> The fact that =
 does not list =
 says something; =
I'm not sure who about, but I doubt it's good.

One could argue that the IANA registry is not meant to be a list of =
formats, just the small subset for which there are registered types. If =
there are formats in the IANA registry that aren't on that list, that =
would be an issue, but I don't think that's the case.

--Paul Hoffman=

From superuser@gmail.com  Sun Oct 28 23:01:29 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C971821F85E0 for ; Sun, 28 Oct 2012 23:01:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.32
X-Spam-Level: 
X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.279,  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 2VkBethDU+u1 for ; Sun, 28 Oct 2012 23:01:28 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8934221F85D5 for ; Sun, 28 Oct 2012 23:01:28 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so3917584lam.31 for ; Sun, 28 Oct 2012 23:01:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+0lHaaeKAhMHd9FmyS+z2q1QL20DSSy164yV7k+tx8U=; b=krFeeYPOnDXuSmxZPo2snjuf2lgDF6tQWwAHwzL6MOvRTd1SPTS/D2ftZD3/+Nq+H4 gND2QKlsRqxkdLGquys2q/5dU9E+tX41CLFCj0gdu2hsbv7/GPO7QVB+Zs/b9uy45Tet T8or+dEtVsL2lPpoxHVUeSH+MlnCT755KiwuW/egfFe8795mN0HIJYQppSF5FJTLX47r ZFVY396hRBfXPUE3qdUneqMjnUiihsKbjT6SmS4p+rLgQPALnawL4yXPl46KZMEW7Zd/ n8ZmY2S6v2WQvRfokRKmUz/LD+zDDFrayd3Qq+cGNfYy+t3bLmvaRgev2MqXinicHXgF jk0w==
MIME-Version: 1.0
Received: by 10.112.29.71 with SMTP id i7mr1452397lbh.85.1351490487533; Sun, 28 Oct 2012 23:01:27 -0700 (PDT)
Received: by 10.112.144.164 with HTTP; Sun, 28 Oct 2012 23:01:27 -0700 (PDT)
Date: Sun, 28 Oct 2012 23:01:27 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: IETF Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [apps-discuss] IETF 85 Agenda
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Oct 2012 06:01:29 -0000

Colleagues,

We've uploaded a preliminary agenda for our meeting in Atlanta next
Monday.  It's available here:

http://www.ietf.org/proceedings/85/agenda/agenda-85-appsawg

If you requested a slot and we did not assign you one, please drop us
a note.  Also, if your assigned slot is too long or not long enough,
please drop us a note.

If you have been assigned a slot to discuss an active working group
document, please provide a list of specific open issues that need
discussion at the meeting.  Time slots about WG drafts should be used
to discuss open issues, not to do document walk-throughs or recap
resolved issues.

Finally, we need to secure presentations from people representing BoFs
or new working groups.  If anyone on this list is such a person and
would like to volunteer to discuss same, please let us know so we can
assign a name to the slot.

Thanks, see you all in Atlanta.

-MSK, co-chair

From sm@resistor.net  Mon Oct 29 01:18:51 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A61421F8528 for ; Mon, 29 Oct 2012 01:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.996
X-Spam-Level: 
X-Spam-Status: No, score=-101.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 ApV0KSYCBmUs for ; Mon, 29 Oct 2012 01:18:50 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 704CD21F8516 for ; Mon, 29 Oct 2012 01:18:50 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q9T8IfDk000056 for ; Mon, 29 Oct 2012 01:18:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351498729; bh=BzAyoSXtMSP3KcKAn51qDRjHmKwx64Ek0OmwmEHB+xE=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=ppZAKkCbddMnor0Ed3pVDRkDPa/WKBbnpbnZDy27MV12nbOfYZ1OpT+gG+omygipV qZVH8JjzTaWt4PbU+KbFqA7xjX5aHJyeqIhxLfgWpif0t66SmJME1z3hlstsT8KBl9 KuiCQSp2fIbn2Ko69LYjFUDBuZsbjdR9I2bc342k=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351498729; i=@resistor.net; bh=BzAyoSXtMSP3KcKAn51qDRjHmKwx64Ek0OmwmEHB+xE=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=dZMXXSptmgw3mJF2mqQDD24Tc+mtLh45B+ug1ssT41bP2ro4TfYFzcWTMreEhCm03 vKzVN9EKZU5ppGL6yzQ6dHluyQ2C3oatNVz0Z7LGKBBOYxLwc0MHdI9s20vW6newJh z72nH0KZjE7zTp9DsTqdirck2sV7GRePlLQBXg7E=
Message-Id: <6.2.5.6.2.20121029010910.0b334dc0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 29 Oct 2012 01:17:38 -0700
To: apps-discuss@ietf.org
From: SM 
In-Reply-To: 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [apps-discuss] IETF 85 Agenda
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Oct 2012 08:18:51 -0000

At 23:01 28-10-2012, Murray S. Kucherawy wrote:
>http://www.ietf.org/proceedings/85/agenda/agenda-85-appsawg

I guess that the author of draft-ietf-appsawg-acct-uri open issues 
won't be able to be physically present to discuss the draft due to 
visa issues. :-)

Are there any Internet-Drafts I should read to be able to follow the 
discussion about the following topics:

  - Service Discovery Topics
  - JSON Content Rules
  - DMARC

Regards,
-sm 


From cabo@tzi.org  Mon Oct 29 01:27:22 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1EA21F85A5 for ; Mon, 29 Oct 2012 01:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.424
X-Spam-Level: 
X-Spam-Status: No, score=-108.424 tagged_above=-999 required=5 tests=[AWL=-2.175, 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 Kio2zrQfvghg for ; Mon, 29 Oct 2012 01:27:22 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 731E521F8581 for ; Mon, 29 Oct 2012 01:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q9T8RAUJ018522; Mon, 29 Oct 2012 09:27:10 +0100 (CET)
Received: from [192.168.217.105] (p548935CB.dip.t-dialin.net [84.137.53.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 631DEC55; Mon, 29 Oct 2012 09:27:10 +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: Mon, 29 Oct 2012 09:27:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2366ED43-8D58-406B-AFA7-6ACBA241DC11@tzi.org>
References: 
To: "Murray S. Kucherawy" 
X-Mailer: Apple Mail (2.1499)
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] IETF 85 Agenda
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Oct 2012 08:27:22 -0000

On Oct 29, 2012, at 07:01, "Murray S. Kucherawy"  =
wrote:

> http://www.ietf.org/proceedings/85/agenda/agenda-85-appsawg

Could we please start a concerted effort to get the secretariat to =
finally present text/plain as UTF-8?

(I tried once, and then a random Windows user had a strange problem with =
some Windows tool inserting BOMs, messing up their ASCII processing =
chain, and the secretariat backed down.)

Gr=FC=DFe, Carsten


From salvatore.loreto@ericsson.com  Mon Oct 29 01:56:15 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BF421F851F for ; Mon, 29 Oct 2012 01:56:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.808
X-Spam-Level: 
X-Spam-Status: No, score=-105.808 tagged_above=-999 required=5 tests=[AWL=0.440, 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 PcplpPiG9nyL for ; Mon, 29 Oct 2012 01:56:11 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E5AB621F84E1 for ; Mon, 29 Oct 2012 01:56:10 -0700 (PDT)
X-AuditID: c1b4fb30-b7f936d0000018b3-62-508e44a9b7e3
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2C.E2.06323.9A44E805; Mon, 29 Oct 2012 09:56:09 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Mon, 29 Oct 2012 09:56: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 82C2824C7; Mon, 29 Oct 2012 10:56:04 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 03B6653A30; Mon, 29 Oct 2012 10:56:04 +0200 (EET)
Received: from n94.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A0C47534C0; Mon, 29 Oct 2012 10:56:03 +0200 (EET)
Message-ID: <508E44A3.909@ericsson.com>
Date: Mon, 29 Oct 2012 10:56:03 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "Paul E. Jones" 
References: <031801cdb0bc$8a5048f0$9ef0dad0$@packetizer.com> <508D812C.5040708@ericsson.com> <09b801cdb54a$69abb340$3d0319c0$@packetizer.com>
In-Reply-To: <09b801cdb54a$69abb340$3d0319c0$@packetizer.com>
Content-Type: multipart/alternative; boundary="------------090705060603070002070604"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+Jvre5Kl74Ag8NPJS1Wv1zBZnH+wgYm i5/3j7A5MHvsmXiSzWPJkp9MHg37jrIHMEdx2aSk5mSWpRbp2yVwZbzbfI6pYGkTU8W+6U/Z GhifH2PsYuTkkBAwkZix4TUbhC0mceHeeiCbi0NI4CSjxIPX38ASQgIbGCXOXcmCSOxilJh1 ZAY7hLOWUWLh8WWsEM5SRomWg+1gLbwC6hKtfw6A7WARUJX4t+Y3WJxNwEzi+cMtzCC2qECy xLwNV5kh6gUlTs58wgJiiwhoS5y59hAszixgKnHywW6wuLCAh8SqG/ug7usFuu/ACyaQBKeA rcTe/6+BlnEANYRJ9Jw3h/hHTeLquU3MEC9oSfSe7WSawCgyC8m6WQgds8C22UpcmHOdBcKW l9j+dg4zhK0rceH/FBTxBYxsqxjZcxMzc9LLzTcxAuPn4JbfBjsYN90XO8QozcGiJM6rp7rf X0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjwjrNvcLT3BpuCqgp52vXaGVkd6uv5/hqZiwj 71zH33Fhp36uR7/ElaIq+51xEkmn5jSZuYtsrIh86Orh9+/J10KH47sybzY4LTJ4oOv4Mcba P1L9aFCKtUg8k822TXcurw3UTen/zLZ+2kSX8izlyoQzbjvKv9vKvVY5Vqv/0Ix597brf5VY ijMSDbWYi4oTATjWUCVtAgAA
Cc: webfinger@googlegroups.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Updated: draft-ietf-appsawg-webfinger-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, 29 Oct 2012 08:56:15 -0000

--------------090705060603070002070604
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 10/28/12 10:25 PM, Paul E. Jones wrote:
>
> Sal,
>
> For (1), what is not aligned.  I saw in the abstract I used "one the 
> network" rather than "on the Internet" in once place, so I want to 
> change that.
>

great!

> Otherwise, it's different wording, but the same message, I think.  
> Perhaps change "objects" in the Abstract to "other entities"?
>

yes I would prefer "entities" to "objects"

> What were you thinking in terms of alignment?
>

what you have already spotted. thanks!

> For (2), the "and" is easy.
>
:-)
>
> How to handle issues where the WF server fails to retrieve LRDD 
> information is more challenging.  The rationale was simply that we 
> needed to provide an answer to the question. ;-)  We should decide 
> what the appropriate action is.  We can either ignore it, which might 
> result in a partial set of link relations or no link relations.  
> That's the current wording.
>

I think it is the right choice. It is much better to return a little set 
of info then an error.
My concerns are more on the clarity of the text about the fact that in 
the final response
the LRDD that fails to be retrieved is completely removed

> The other option is to return some specific 5xx error code.  I'm happy 
> with whatever the group proposes here.
>
> Related to (2), if the server is requesting 5 pieces of information in 
> the background and one request results in 5xx, do we return 5xx?  What 
> if four requests return a reply and one returns 404?  Does the server 
> just ignore the 404? Or does it return 5xx?  What if there are a mix 
> of errors?
>

if we get only errors then we have to decide which is the most important 
to return... :-)
but that is something that we can leave to the implementors

however if we have a mix of errors and info, then lets return the 
content info we get


> For (3), I like "substantially" myself, because it does tell me 
> something.  But, your point is taken.  Rather than removing 
> "substantially", how about I add the following sentence right after:
>
> The only elements in the response that MAY be different include 
> "subject", "expires", and "aliases".
>
perfect!
with this addition the all paragraph will be much clear.


Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com


> I think it is only those three that are affected.  The expires element 
> might change with every request, though if issued in parallel might be 
> the same.  The subject line must change, of course, and if the subject 
> changes, then the set of aliases changes.
>

> Paul
>
> *From:*Salvatore Loreto [mailto:salvatore.loreto@ericsson.com]
> *Sent:* Sunday, October 28, 2012 3:02 PM
> *To:* Paul E. Jones
> *Cc:* apps-discuss@ietf.org; webfinger@googlegroups.com
> *Subject:* Re: [apps-discuss] Updated: draft-ietf-appsawg-webfinger-02.txt
>
> Hi Paul,
>
> I have read the last 02 version and I have the following comments:
>
> 1)
> In the Abstract, you define WebFinger
>
>     WebFinger may be
>     used to discover information about people on the Internet, such as a
>     person's personal profile address, identity service, telephone
>     number, or preferred avatar.
>
> however I found this definition slightly different from the one you 
> provide in the Overview:
>
>     WebFinger enables the discovery of information about accounts,
>     devices, and other entities that are associated with a host.
>
>
> I think it would be better to align the two
>
>
> 2) In Section 5.2
>
>         *  Collect and expand all resource-specific link relations,
>            including those returned by querying for any LRDD link
>            relations, discard any host-wide link relations, and return a
>            complete resource descriptor following the processing rules in
>            Section 4.2 of RFC 6415  ; and
>   
>
> as a nit: above you should remove the "and".
>
>   
>   
>     It is not the responsibility of the WebFinger server to verify, for
>     example, that a URI pointing to a person's avatar is a valid URI.  If
>     the WebFinger server needs to query an LRDD resource to collect
>     additional resource-specific information, any errors (e.g., 500 or
>     404) MUST be ignored by the server.  When a request for an LRDD
>     fails, the server MUST NOT attempt to augment missing resource
>     information or return a "template" type link relation to a client
>     that utilizes the "resource" parameter.
>
>
> Is it correct my interpretation that if a request for an LRDD fails, the
> server will remove it from the response?
> if so what is the rationale for this behavior?
>
> 3) In Section 5.4
>
>     A host MAY utilize one or more URIs that serve as aliases for the
>     user's account, such as URIs that use the "http" URI scheme [2  ].  A
>     WebFinger server MUST return substantially the same response to both
>     an "acct" URI and any alias URI for the account, including the same
>     set of link relations and properties.
>
>
> I don't like the "MUST return substantially" expression, it leaves to 
> much ambiguities.
> You should explicitly say what are the expected differences if any.
>
>
> /Salvatore
>
>
> -- 
> Salvatore Loreto, PhD
> www.sloreto.com  
>
>
>
> On 10/23/12 4:20 AM, Paul E. Jones wrote:
>
>     Folks,
>
>       
>
>     I posted a slightly revised draft considering input received over the
>
>     weekend.  You can see the differences are fairly minor, but they were
>
>     changes I could easily make to improve the text.
>
>       
>
>     Paul
>
>       
>
>         -----Original Message-----
>
>         From:apps-discuss-bounces@ietf.org    [mailto:apps-discuss-
>
>         bounces@ietf.org  ] On Behalf Ofinternet-drafts@ietf.org  
>
>         Sent: Monday, October 22, 2012 7:38 PM
>
>         To:i-d-announce@ietf.org  
>
>         Cc:apps-discuss@ietf.org  
>
>         Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-02.txt
>
>           
>
>           
>
>         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           : WebFinger
>
>            Author(s)       : Paul E. Jones
>
>                                    Gonzalo Salgueiro
>
>                                    Joseph Smarr
>
>            Filename        : draft-ietf-appsawg-webfinger-02.txt
>
>            Pages           : 26
>
>            Date            : 2012-10-22
>
>           
>
>         Abstract:
>
>             This specification defines the WebFinger protocol.  WebFinger may be
>
>             used to discover information about people on the Internet, such as a
>
>             person's personal profile address, identity service, telephone
>
>             number, or preferred avatar.  WebFinger may also be used to discover
>
>             information about objects on the network, such as the amount of toner
>
>             in a printer or the physical location of a server.
>
>           
>
>           
>
>         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-02
>
>           
>
>         A diff from the previous version is available at:
>
>         http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-02
>
>           
>
>           
>
>         Internet-Drafts are also available by anonymous FTP at:
>
>         ftp://ftp.ietf.org/internet-drafts/
>
>           
>
>         _______________________________________________
>
>         apps-discuss mailing list
>
>         apps-discuss@ietf.org  
>
>         https://www.ietf.org/mailman/listinfo/apps-discuss
>
>       
>
>     _______________________________________________
>
>     apps-discuss mailing list
>
>     apps-discuss@ietf.org  
>
>     https://www.ietf.org/mailman/listinfo/apps-discuss
>
>       
>


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


  
    
  
  
    
On 10/28/12 10:25 PM, Paul E. Jones
      wrote:

    

    

      
      
      
      

        
Sal,

        
 

        
For
            (1), what is not aligned.  I saw in the abstract I used “one
            the network” rather than “on the Internet” in once place, so
            I want to change that. 

          

      

    

    

    great!

    

    

      

        

            Otherwise, it’s different wording, but the same message, I
            think.  Perhaps change “objects” in the Abstract to “other
            entities”?  

      

    

    

    yes I would prefer "entities" to "objects"

    

    

      

        
What
            were you thinking in terms of alignment?

      

    

    

    what you have already spotted. thanks! 

    

    

      

        

        
 

        
For
            (2), the “and” is easy.  

      

    

    :-)

    

      

        
How
            to handle issues where the WF server fails to retrieve LRDD
            information is more challenging.  The rationale was simply
            that we needed to provide an answer to the question. ;-)  We
            should decide what the appropriate action is.  We can either
            ignore it, which might result in a partial set of link
            relations or no link relations.  That’s the current
            wording.  

      

    

    

    I think it is the right choice. It is much better to return a little
    set of info then an error.

    My concerns are more on the clarity of the text about the fact that
    in the final response 

    the LRDD that fails to be retrieved is completely removed 

    

    

      

        
The
            other option is to return some specific 5xx error code.  I’m
            happy with whatever the group proposes here.

        
 

        
Related
            to (2), if the server is requesting 5 pieces of information
            in the background and one request results in 5xx, do we
            return 5xx?  What if four requests return a reply and one
            returns 404?  Does the server just ignore the 404? Or does
            it return 5xx?  What if there are a mix of errors?

      

    

    

    if we get only errors then we have to decide which is the most
    important to return... :-)

    but that is something that we can leave to the implementors

    

    however if we have a mix of errors and info, then lets return the
    content info we get 

    

    

    

      

        

        
 

        
For
            (3), I like “substantially” myself, because it does tell me
            something.  But, your point is taken.  Rather than removing
            “substantially”, how about I add the following sentence
            right after:

        
 

        
The
            only elements in the response that MAY be different include
            “subject”, “expires”, and “aliases”.

      

    

    perfect! 

    with this addition the all paragraph will be much clear.

    

    

    Salvatore

    

    
-- 
Salvatore Loreto, PhD
www.sloreto.com

    

    

      

        

        
 

        
I
            think it is only those three that are affected.  The expires
            element might change with every request, though if issued in
            parallel might be the same.  The subject line must change,
            of course, and if the subject changes, then the set of
            aliases changes. 

      

    

    

    

      

        

        
 

        
Paul

        
 

        

          

            

              
From:
                  Salvatore Loreto
                  [mailto:salvatore.loreto@ericsson.com] 

                  Sent: Sunday, October 28, 2012 3:02 PM

                  To: Paul E. Jones

                  Cc: apps-discuss@ietf.org;
                  webfinger@googlegroups.com

                  Subject: Re: [apps-discuss] Updated:
                  draft-ietf-appsawg-webfinger-02.txt

            

          

          
 

          

            
Hi Paul,

              

              I have read the last 02 version and I have the following
              comments:

              

              1)

              In the Abstract, you define WebFinger

            
   WebFinger may be

            
   used to discover information about people on the Internet, such as a

            
   person's personal profile address, identity service, telephone

            
   number, or preferred avatar.

            
however I
              found this definition slightly different from the one you
              provide in the Overview:

            
   WebFinger enables the discovery of information about accounts,

            
   devices, and other entities that are associated with a host.

            


              I think it would be better to align the two

              

              

              2) In Section 5.2 

            
       *  Collect and expand all resource-specific link relations,

            
          including those returned by querying for any LRDD link

            
          relations, discard any host-wide link relations, and return a

            
          complete resource descriptor following the processing rules in

            
          Section 4.2 of RFC 6415; and

            
 

            
as a nit: above you should remove the
              "and".

            
 

            
 

            
   It is not the responsibility of the WebFinger server to verify, for

            
   example, that a URI pointing to a person's avatar is a valid URI.  If

            
   the WebFinger server needs to query an LRDD resource to collect

            
   additional resource-specific information, any errors (e.g., 500 or

            
   404) MUST be ignored by the server.  When a request for an LRDD

            
   fails, the server MUST NOT attempt to augment missing resource

            
   information or return a "template" type link relation to a client

            
   that utilizes the "resource" parameter.

            


              Is it correct my interpretation that if a request for an
              LRDD fails, the

              server will remove it from the response?

              if so what is the rationale for this behavior?

              

              3) In Section 5.4

            
   A host MAY utilize one or more URIs that serve as aliases for the

            
   user's account, such as URIs that use the "http" URI scheme [2].  A

            
   WebFinger server MUST return substantially the same response to both

            
   an "acct" URI and any alias URI for the account, including the same

            
   set of link relations and properties.

            


              I don't like the "MUST return substantially" expression,
              it leaves to much ambiguities.

              You should explicitly say what are the expected
              differences if any.

              

              

              /Salvatore

              

              

              

            
-- 

            
Salvatore Loreto, PhD

            
www.sloreto.com

            


              

              On 10/23/12 4:20 AM, Paul E. Jones wrote:

          

          

            
Folks,

            
 

            
I posted a slightly revised draft considering input received over the

            
weekend.  You can see the differences are fairly minor, but they were

            
changes I could easily make to improve the text.

            
 

            
Paul

            
 

            

              
-----Original Message-----

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

              
bounces@ietf.org] On Behalf Of internet-drafts@ietf.org

              
Sent: Monday, October 22, 2012 7:38 PM

              
To: i-d-announce@ietf.org

              
Cc: apps-discuss@ietf.org

              
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-02.txt

              
 

              
 

              
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           : WebFinger

              
  Author(s)       : Paul E. Jones

              
                          Gonzalo Salgueiro

              
                          Joseph Smarr

              
  Filename        : draft-ietf-appsawg-webfinger-02.txt

              
  Pages           : 26

              
  Date            : 2012-10-22

              
 

              
Abstract:

              
   This specification defines the WebFinger protocol.  WebFinger may be

              
   used to discover information about people on the Internet, such as a

              
   person's personal profile address, identity service, telephone

              
   number, or preferred avatar.  WebFinger may also be used to discover

              
   information about objects on the network, such as the amount of toner

              
   in a printer or the physical location of a server.

              
 

              
 

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

              
 

              
A diff from the previous version is available at:

              
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-02

              
 

              
 

              
Internet-Drafts are also available by anonymous FTP at:

              
ftp://ftp.ietf.org/internet-drafts/

              
 

              
_______________________________________________

              
apps-discuss mailing list

              
apps-discuss@ietf.org

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

            

            
 

            
_______________________________________________

            
apps-discuss mailing list

            
apps-discuss@ietf.org

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

            
 

          

          
 

        

      

    

    

  


--------------090705060603070002070604--

From ned.freed@mrochek.com  Mon Oct 29 02:31:06 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469C421F857C for ; Mon, 29 Oct 2012 02:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-sWc-85DZJi for ; Mon, 29 Oct 2012 02:31:05 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2C521F8514 for ; Mon, 29 Oct 2012 02:31:04 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OLZ58ZB0OG000U6W@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 29 Oct 2012 02:25:03 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OLSVO3D2CW00008S@mauve.mrochek.com>; Mon, 29 Oct 2012 02:25:01 -0700 (PDT)
Message-id: <01OLZ58XOQAE00008S@mauve.mrochek.com>
Date: Mon, 29 Oct 2012 02:21:24 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Sun, 28 Oct 2012 16:58:05 -0700" <18D4E4AB-FE5D-4D66-A076-19BF81830845@vpnc.org>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <9EAB966B-4B21-4CF9-BFEB-4DAD639FE81C@vpnc.org>  <18D4E4AB-FE5D-4D66-A076-19BF81830845@vpnc.org>
To: Paul Hoffman 
Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] Solving the file format problem
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Oct 2012 09:31:06 -0000

> On Oct 28, 2012, at 4:35 PM, Mark Nottingham  wrote:

> > The fact that
> > 
> > does not list  says
> > something; I'm not sure who about, but I doubt it's good.

I concur.

> One could argue that the IANA registry is not meant to be a list of formats,
> just the small subset for which there are registered types.

Except that registering a type is good hygiene for any format intended for
transfer or storage on the Internet.

It used to be the case that type registration was considered to be something
reserved for a subset of formats, but that notion died an unlamented death
with the publication of RFC 4288, if not earlier.

				Ned

From stephen.farrell@cs.tcd.ie  Mon Oct 29 04:22:59 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EED21F84E6 for ; Mon, 29 Oct 2012 04:22:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.74
X-Spam-Level: 
X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 p2H+6RWptM6p for ; Mon, 29 Oct 2012 04:22:59 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4A55621F84D3 for ; Mon, 29 Oct 2012 04:22:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3A7B8C7AD for ; Mon, 29 Oct 2012 11:22:36 +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 0jdYuI8KBGTD for ; Mon, 29 Oct 2012 11:22:35 +0000 (GMT)
Received: from [10.87.48.4] (unknown [86.42.30.34]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8D6FFC7AB for ; Mon, 29 Oct 2012 11:22:35 +0000 (GMT)
Message-ID: <508E66FB.4070708@cs.tcd.ie>
Date: Mon, 29 Oct 2012 11:22:35 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1
MIME-Version: 1.0
To: Apps Discuss 
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Oct 2012 11:22:59 -0000

The draft says:

"  Let's assume your email client discovers that blog automatically for
   you.  After receiving the message from Bob (bob@example.com), your
   email client performs the following steps behind the scenes."

...then describes how I send out a request containing the
string bob@example.com.

The net result of that appears to be that I'll be sending out details
about who I'm contacting (or want to contact) to a server with which
I've no existing relationship, and that is probably going to turn out
to be operated by one of the few very large providers.

That seems to me to have potentially serious privacy issues. (As with
all privacy issues, you never know when they're more than potential
until its too late;-)

Is that accurate?

I wondered why the wg didn't consider (even as an option) allowing
the client to send a hash of Bob's URI? That way, if the request
goes to the wrong place, things are a bit more privacy friendly.
(I think an earlier draft from James Snell suggested this, but
don't recall subsequent discussion about that.)

One argument for doing something privacy friendly here is that
it would make sense to follow the approach of the safe web
browsing mechanisms here - if its considered sensitive to tell
a large provider about the URLs I'm visiting, then why is it ok
to tell such a provider the names of the people I want to finger?
(Having said that, yes, other mechanisms, such as URL completion
take the opposite approach.)

More generally, it'd be good if webfinger privacy were discussed
more on the list since maybe there are other privacy issues or
mitigations that'd be better or easier.

(Note: I would raise a DISCUSS during IESG eval for this, but since
it could lead to a change in the protocol, I'm raising it now in the
hope that's more likely to be doable if it needs to be done.)

Cheers,
S.

From john-ietf@jck.com  Mon Oct 29 04:40:50 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3416121F85E0 for ; Mon, 29 Oct 2012 04:40:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.11
X-Spam-Level: 
X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 kmblUCm6Pf9s for ; Mon, 29 Oct 2012 04:40:49 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7885421F85CD for ; Mon, 29 Oct 2012 04:40:49 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TSni0-00013J-Tt; Mon, 29 Oct 2012 07:40:44 -0400
Date: Mon, 29 Oct 2012 07:40:39 -0400
From: John C Klensin 
To: Ned Freed , Paul Hoffman 
Message-ID: 
In-Reply-To: <01OLZ58XOQAE00008S@mauve.mrochek.com>
References: <9EAB966B-4B21-4CF9-BFEB-4DAD639FE81C@vpnc.org>  <18D4E4AB-FE5D-4D66-A076-19BF81830845@vpnc.org> <01OLZ58XOQAE00008S@mauve.mrochek.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: Mark Nottingham , "apps-discuss@ietf.org Discuss" 
Subject: Re: [apps-discuss] Solving the file format problem
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Oct 2012 11:40:50 -0000

--On Monday, October 29, 2012 02:21 -0700 Ned Freed
 wrote:

>> On Oct 28, 2012, at 4:35 PM, Mark Nottingham 
>> wrote:
> 
>> > The fact that
>> > > > ist_of_Places_Keeping_Track_of_Formats> does not list
>> > 
>> > says something; I'm not sure who about, but I doubt it's
>> > good.
> 
> I concur.

Agreed.  The same comment would apply to
Content-transfer-encodings and I note that, at least as of some
hours ago, Base64 and Quoted-printable did not seem to be on the
list.

>...

The list itself has become both redundant (with many things
listed more than once) and a little strange, mixing hardware and
physical formats without distinction from actual file formats.
For example, "paper tape", "1/2 inch open reel tape", and "IBM
[punch?] cards" aren't file formats (although many file formats
were used with each, most of them not on the list either) nor
are they even sufficiently precise enough physical or logical
formats to be useful.   I'm aware of at least two, physically
incompatible, paper tape formats and would be not at all
surprised if there are more, open reel magnetic tape came in at
least 7 and 9 bit formats (again mutually incompatible wrt
reader/writer heads), and those punched cards existed in both
row formats and the more familiar column ones.   

As with media types, the observation that people didn't manage
to even recognize those differences enough to organize things
into categories before there were well over a thousand entries
on the list doesn't bode well for this project, even as a
catalog.

  john


From andy@hxr.us  Mon Oct 29 04:41:56 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097C221F85CD for ; Mon, 29 Oct 2012 04:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iG6izoXEmPHl for ; Mon, 29 Oct 2012 04:41:55 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D5AB221F85E0 for ; Mon, 29 Oct 2012 04:41:43 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so4124288lam.31 for ; Mon, 29 Oct 2012 04:41:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=S+9OvlrmPW7XR/MR7Ja0+9FySwBZn4wQ9K8QmPbkvtA=; b=Nc/PHyb+larUf0JrE3plcm+jJQLDafcW4Uztz33VgyPFo2w+mKuIJ8CWsQX4J4QvgH bEsDfkamUiw9hypyv3UHK8zSS3EiJC+kMqizqOar36YdatQ4M3sUjDLtRSn4XVIGd+js 6rGruYzC7JY2UE14ZJivYYsoyrV+PptNqDZF5ROE133mBgpelEURRe1WyVI/DJz4gi+x QZAu4TME73ZYTztyTFCdPhLrjwRIV8r7l5WopFJCPUltcTRSJESSkI1HwtnsEtBItLiU SvTtdN3Oyddlc+x/FeiEdJJheWvDEfmE7YlKUH1+NZf1ulOpsFQ4c27plZbGC9/gyi82 F2/g==
MIME-Version: 1.0
Received: by 10.152.103.38 with SMTP id ft6mr26528194lab.40.1351510902813; Mon, 29 Oct 2012 04:41:42 -0700 (PDT)
Received: by 10.112.155.138 with HTTP; Mon, 29 Oct 2012 04:41:42 -0700 (PDT)
X-Originating-IP: [192.149.252.11]
In-Reply-To: <6.2.5.6.2.20121029010910.0b334dc0@resistor.net>
References:  <6.2.5.6.2.20121029010910.0b334dc0@resistor.net>
Date: Mon, 29 Oct 2012 07:41:42 -0400
Message-ID: 
From: Andrew Newton 
To: SM 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlEflXx1++7lIe/DiCxhOz7aeEaeAxBX4Y+te5Yj9TQ0qrs3hvhJjoH61w/QFllK4jGB6n5
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] IETF 85 Agenda
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Oct 2012 11:41:56 -0000

SM,

On Mon, Oct 29, 2012 at 4:17 AM, SM  wrote:
> Are there any Internet-Drafts I should read to be able to follow the
> discussion about the following topics:
>
>  - JSON Content Rules

http://tools.ietf.org/html/draft-newton-json-content-rules-00

-andy

From salvatore.loreto@ericsson.com  Mon Oct 29 06:13:05 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653B721F853E for ; Mon, 29 Oct 2012 06:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.657
X-Spam-Level: 
X-Spam-Status: No, score=-104.657 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 z3mB1bfxHAtL for ; Mon, 29 Oct 2012 06:13:04 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 871A321F84A5 for ; Mon, 29 Oct 2012 06:13:03 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f1e6d000002d2c-dc-508e80dd0717
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5E.92.11564.DD08E805; Mon, 29 Oct 2012 14:13:02 +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, 29 Oct 2012 14:12:59 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id E45222ADA	for ; Mon, 29 Oct 2012 15:12:59 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8B37353A8A	for ; Mon, 29 Oct 2012 15:12:59 +0200 (EET)
Received: from n94.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3F8C453A3C	for ; Mon, 29 Oct 2012 15:12:59 +0200 (EET)
Message-ID: <508E80DB.9030603@ericsson.com>
Date: Mon, 29 Oct 2012 15:12:59 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: apps-discuss@ietf.org
References:  <34966E97BE8AD64EAE9D3D6E4DEE36F21ED43779@szxeml525-mbx.china.huawei.com>
In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F21ED43779@szxeml525-mbx.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------000407020607050406030707"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvre69hr4Ag6Y5nBarX65gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpwnf1kLXvUwVnz5M5+9gXFhThcjJ4eEgInEwemTmCFsMYkL 99azdTFycQgJnGSUaFh8jRnC2cAo8eDOZBYI5xqjxP4fWxlBWsDKbu+AajnIKLHw3lUmkASv gLbE5AkzwGwWAVWJFd++gO1gEzCTeP5wC5gtKpAsMW/DVWaIekGJkzOfsIDYIgKSEvtmTQaL Cwv4SKyfPpcVYsF8RolHe/6BJTgFwiRu/1wGtJmDgxnIfv3CD+IHNYmr5zYxQxynJdF7tpNp AqPwLCQrZiF0QJhAVbv0QSqYBeQlmrfOZoawgyR+fT7FCGFrSnz7uZ4JU424xP4rbVC2osSU 7ofsELaRxMstzxgXMHKtYmTPTczMSS833MQIjK2DW37r7mA8dU7kEKM0B4uSOC9X0n5/IYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzejM4sHhV2ddHLnzq/WuEZY8zD5/8l/Zzw3tLrAjr7 nvtrzhYM+yv00o674+quOcrlkyWOrJO2jfBTdzzrMvfF/aBlnHZP2lUyHdc7PjfwYJPk2LT9 ws/Mtzru5YuXL3w1TbCnM+1l5ds/bRY1FlLBCYpnKp/v0F1wYv0q6fkNqzNq07Y7XVZiKc5I NNRiLipOBAAjkZnXewIAAA==
Subject: Re: [apps-discuss] New version of I-D for ENUM service for acct URI
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Oct 2012 13:13:05 -0000

--------------000407020607050406030707
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit

I have read the last version of the draft, and I think that is more then
reasonable and useful register an
ENUM service for 'acct' URIs.


from Section 3, it is not completely clear to me if OMA Social Network
Enabler will be built on acct URI,
or it is just an example to highlight the need to translate MSISDN to
"information about people on the Internet".

moreover it is also not clear to what specific acct URI it will be mapped.
I mean is it limited to the one provided by the telecom service provider
or it can be any acct URIs

thanks
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com




On 9/13/12 3:38 AM, Likepeng wrote:
>
> Just to clarify that in the previous enum-sn-service draft, it only
> focuses on social network account.
>
> Now in the new enum-acct-uri draft, we change that to acct uri, don¡¯t
> limit it to social network account.
>
> We received many valuable offline discussion comments for the previous
> draft, hope to get feedback to the new draft.
>
> Thanks,
>
> Kind Regards
>
> Kepeng
>
> *·¢¼þÈË:*Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]
> *·¢ËÍ Ê±¼ä:*2012Äê9ÔÂ11ÈÕ21:54
> *ÊÕ¼þÈË:*apps-discuss@ietf.org
> *³­ËÍ:*Likepeng
> *Ö÷Ìâ:*New version of I-D for ENUM service for acct URI
>
> Dear all,
>
> I just uploaded this draft [1] as a revision of former
> draft-goix-appsawg-enum-sn-service-02 based on the discussion held in
> Vancouver.
>
> In particular the text was generalized and a use cases section was
> added to clarify the problem to be solved as requested by Dave.
>
> We also expanded the security section to clarify potential privacy
> issues as requested by Ted and Hannes, further clarifying why
> inserting link rel endpoint directly in ENUM itself are not
> appropriate. The example was slightly revised as well.
>
> Finally, on whether RAI or APPS should handle this draft, the authors
> sponsor APPS, and in particular APPSAWG, which already handles the
> webfinger and acct uri drafts and the related experts. Enum experts
> already performed a sanity check on previous versions of this draft.
>
> We welcome your feedback on this revision.
>
> Walter
>
> [1] http://tools.ietf.org/html/draft-goix-appsawg-enum-acct-uri-00
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente
> alle persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente
> vietate. Qualora abbiate ricevuto questo documento per errore siete
> cortesemente pregati di darne immediata comunicazione al mittente e di
> provvedere alla sua distruzione, Grazie.
>
> /This e-mail and any attachments//is //confidential and may contain
> privileged information intended for the addressee(s) only.
> Dissemination, copying, printing or use by anybody else is
> unauthorised. If you are not the intended recipient, please delete
> this message and any attachments and advise the sender by return
> e-mail, Thanks./
>
> *rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se
> non ¨¨ necessario.*
>


--------------000407020607050406030707
Content-Type: multipart/related;
	boundary="------------070405090403090002090702"

--------------070405090403090002090702
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: 8bit


  
    
  
  
    
I have read the last version of the
      draft, and I think that is more then reasonable and useful
      register  an

      ENUM service for 'acct' URIs.

      

      

      from Section 3, it is not completely clear to me if OMA Social
      Network Enabler will be built on acct URI,

      or it is just an example to highlight the need to translate MSISDN
      to "information about people on the Internet".

      

      moreover it is also not clear to what specific acct URI it will be
      mapped.

      I mean is it limited to the one provided by the telecom service
      provider or it can be any acct URIs

      

      thanks

      Salvatore

      
-- 
Salvatore Loreto, PhD
www.sloreto.com

       
      

      

      

      On 9/13/12 3:38 AM, Likepeng wrote:

    

    

      
      
      
      
      

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

        
 

        
Now in
            the new enum-acct-uri draft, we change that to acct uri,
            don¡¯t limit it to social network account.

        
 

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

        
 

        
Thanks,

        
 

        
Kind
            Regards

        
Kepeng

        
 

        

          

            
·¢¼þÈË:
                Goix Laurent Walter
                [mailto:laurentwalter.goix@telecomitalia.it]
                

              ·¢ËÍ
                  ʱ¼ä:
                2012Äê9ÔÂ11ÈÕ 21:54

                ÊÕ¼þÈË: apps-discuss@ietf.org

                ³­ËÍ: Likepeng

                Ö÷Ìâ: New version of I-D for ENUM service for
                  acct URI

          

        

        
 

        
Dear all,

        
 

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

        
 

        
In particular the text
            was generalized and a use cases section was added to clarify
            the problem to be solved as requested by Dave.
            

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

        
 

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

        
 

        
We welcome your feedback
            on this revision.

        
Walter

        
 

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

        
 

        
 

        

          
            

              
                

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

                

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

                
rispetta l'ambienteRispetta

                      l'ambiente. Non stampare questa mail se non ¨¨
                      necessario.
                    

              		
            

          
        

        
 

      

    

    

  


--------------070405090403090002090702
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-ID: 

R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+g
gbzo8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs
5vX8/ez5+4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs
8sXZzfH18pq9p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAA
AAAaACgAAAb/wJxwSBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyj
fXMhCmqGgR4r2S5dIBV0FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZ
M0kMbSYcIjYCBDg4LTYLf0V6YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQT
FDg2ATgHGkIs2wyyAqbUtgICCwfluh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg
4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1I
oIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaVOmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs
98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDioY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRA
gFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAknqnrYYCXCBxGkqlYtgbtLhOcbMNSw
0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs=
--------------070405090403090002090702--

--------------000407020607050406030707--

From john-ietf@jck.com  Mon Oct 29 07:21:18 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C0D21F86ED for ; Mon, 29 Oct 2012 07:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.227
X-Spam-Level: 
X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 vyt2wOho+fSl for ; Mon, 29 Oct 2012 07:21:17 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 817EF21F86EB for ; Mon, 29 Oct 2012 07:21:17 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TSqDM-0001Co-FB; Mon, 29 Oct 2012 10:21:16 -0400
Date: Mon, 29 Oct 2012 10:21:11 -0400
From: John C Klensin 
To: "Murray S. Kucherawy" 
Message-ID: 
In-Reply-To: <2366ED43-8D58-406B-AFA7-6ACBA241DC11@tzi.org>
References:  <2366ED43-8D58-406B-AFA7-6ACBA241DC11@tzi.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] IETF 85 Agenda
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Oct 2012 14:21:18 -0000

> On Oct 29, 2012, at 07:01, "Murray S. Kucherawy"
>  wrote:
> 
>> http://www.ietf.org/proceedings/85/agenda/agenda-85-appsawg

Murray,

A suggestion for either the Appsawg or Appsarea part of the
meeting.  There have been several ongoing threads on the
Webfinger and Json issues that seem to cover more territory than
the three drafts that are listed on your agenda.   I admit to
not having read nearly every message on those threads, partially
because I've been busy with "day job" stuff but also because
some of the arguments seem to be about very small issues that
need to be settled but that probably make little difference in
the grand scheme of things.

The net result is that I'm too bewildered and confused about
what is actually going on to be able to participate
constructively in a LC review.

Perhaps I'm the only AppsAWG participant who is in that position
but, if  there are a non-trivial number of others, I think it
would be _really_ helpful -- far more helpful than just ten
minute presentations on a few  drafts -- to get a serious
presentation or two on these topics, their context, what the
open issues are today, and what new work and issues are likely
to appear in the relatively near future.  

I'd prefer to see that before draft-specific presentations /
discussions rather than instead of them but, if I had to choose,
I'd argue that the overviews are much more important.  Without
those overviews, some of us may not be able to participate
meaningfully in the WGLC.  With them, if the drafts are not
close to self-explanatory, that is a defect that ought to be
fixed prior to IETF LC anyway.

In a normal WG with a single topic area, this request would be
unnecessary and unreasonable because we would expect all
participants to be thoroughly familiar with the WG task area,
one that would be documented in the charter or in supplementary
"framework", "overview", and/or "requirements" documents.  But
AppsAWG is just too broad for that expectation to be reasonable.

I could probably make similar comments about the URI work
cluster, but I think that, after years of URx WGs and efforts,
more or us are familiar with the general context of what is
going on there.  In the webfinger and json cases, there has
never been a topic-focused IETF WG that could be drawn on for
context.

  best,
   john


From superuser@gmail.com  Mon Oct 29 07:32:24 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE4621F870B for ; Mon, 29 Oct 2012 07:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.355
X-Spam-Level: 
X-Spam-Status: No, score=-3.355 tagged_above=-999 required=5 tests=[AWL=0.244,  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 CmD5FqDs3A2R for ; Mon, 29 Oct 2012 07:32:23 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D70E21F8557 for ; Mon, 29 Oct 2012 07:32:23 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id k13so3462611lbo.31 for ; Mon, 29 Oct 2012 07:32:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=frP5+gBNocy7GlarP4+njBJkSweunk1rrU2p0x6Wau4=; b=to6MgwtHfNPFDfI3xtTHlbpd9V26jD6Y6w3tO+9VbKrRC6v0cRdU+mTxNz7bBXKKdN SUA76y18LrasaUa7YqJXI6Cb0i9U1rfWQ0NVZjHFqy+LSnJx1sOgQZG2kyBxORdrgs1A gowAWxwKPmQKlwtRTF4fyj90A9NhDuqOuCpGeP0kM43tDDGO0Y/5XNV1uC73YcUI54IW JoqBr9PaNAZJToVwdwEWK8cFCE++fqpgOAdrb8YhGgUTuz1OHTynRq+aDZFz3hQ7z66k TrqjDwdTjf0nwBlOtKHm9ghuzDlytxjFtXvtDfMbzO1MUMYpGd77GWjxS0kr/Db3ZlVf Pv0A==
MIME-Version: 1.0
Received: by 10.152.47.97 with SMTP id c1mr26945842lan.37.1351521142499; Mon, 29 Oct 2012 07:32:22 -0700 (PDT)
Received: by 10.112.144.164 with HTTP; Mon, 29 Oct 2012 07:32:22 -0700 (PDT)
In-Reply-To: <6.2.5.6.2.20121029010910.0b334dc0@resistor.net>
References:  <6.2.5.6.2.20121029010910.0b334dc0@resistor.net>
Date: Mon, 29 Oct 2012 07:32:22 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: SM 
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] IETF 85 Agenda
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Oct 2012 14:32:24 -0000

On Mon, Oct 29, 2012 at 1:17 AM, SM  wrote:
> Are there any Internet-Drafts I should read to be able to follow the
> discussion about the following topics:
>
>  - Service Discovery Topics

This may be merged with the webfinger material earlier in the session.
 There's not a draft at this point that I know of.

>  - JSON Content Rules

Andy provided one separately.  I'll update the agenda to reference it shortly.

>  - DMARC

DMARC hasn't been submitted yet as an I-D, but there is one available.
 I'll add a link to it to the agenda soon.  This presentation is more
preliminary; the group promoting it will likely be requesting a BoF
after the Atlanta meeting, but is seeking early feedback and
participation.

-MSK

From stpeter@stpeter.im  Mon Oct 29 08:03:27 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0456221F84BC for ; Mon, 29 Oct 2012 08:03:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8DRTTpl-bsi for ; Mon, 29 Oct 2012 08:03:26 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABD921F84BA for ; Mon, 29 Oct 2012 08:03:26 -0700 (PDT)
Received: from [64.101.72.26] (unknown [64.101.72.26]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CBB4C40126; Mon, 29 Oct 2012 09:06:42 -0600 (MDT)
Message-ID: <508E9713.3030301@stpeter.im>
Date: Mon, 29 Oct 2012 08:47:47 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: 'Graham Klyne' 
Subject: [apps-discuss] open issues with acct-uri spec
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Oct 2012 15:03:27 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I see two open issues with draft-ietf-appsawg-acct-uri (which I think
we can resolve on the mailing list, thus saving precious meeting time
for topics that require realtime discussion):

1. In version -01, I think that I was too aggressive about trying to
simplify the ABNF, to wit:

   acctURI      =  "acct" ":" userinfo "@" host

The userinfo rule allows the colon character ':', but I don't think
that's what we want here. Instead, I think we want:

   acctURI      =  "acct" ":" userpart "@" host
   userpart     =  1*( unreserved / pct-encoded / sub-delims )

If you disagree with that definition, please reply to this message.

2. I would like to verify that the updated text about dereferencing
'acct' URIs is sensible. That is (last paragraph of
draft-ietf-appsawg-acct-uri-01, section 3):

   Because an 'acct' URI enables identification only and not
   interaction, it cannot be deferenced directly.  Any protocol that
   might use the 'acct' URI scheme, such as the WebFinger protocol
   [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol
   [I-D.jones-simple-web-discovery], is responsible for specifying how
   an 'acct' URI is dereferenced in the context of that protocol.  For
   example, an 'acct' URI might be passed as a parameter in an HTTP
   request and the service might retrieve the relevant information
   associated with the account identified by that URI and then provide
   that information to the requesting entity in an HTTP response.

Thanks!

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCOlxMACgkQNL8k5A2w/vxQCwCgrqd0q3htJMobf2z27UHh92UP
gCgAnRsWVcc9r/2tli3uyOZwtZpX8p57
=oyo4
-----END PGP SIGNATURE-----

From laurentwalter.goix@telecomitalia.it  Mon Oct 29 08:04:27 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE41821F8705 for ; Mon, 29 Oct 2012 08:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.718
X-Spam-Level: 
X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXVOoe5ICypn for ; Mon, 29 Oct 2012 08:04:25 -0700 (PDT)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7236B21F85D4 for ; Mon, 29 Oct 2012 08:04:23 -0700 (PDT)
Content-Type: multipart/mixed; boundary="_54391536-a095-4cf2-b23b-7ecb0f74e58a_"
Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Mon, 29 Oct 2012 16:04:14 +0100
Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Mon, 29 Oct 2012 16:04:02 +0100
From: Goix Laurent Walter 
To: Melvin Carvalho , "Paul E. Jones" 
Date: Mon, 29 Oct 2012 16:04:00 +0100
Thread-Topic: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-01
Thread-Index: Ac21RWrvlsEjkAqcSCOEJDmYfRakbgAn0csw
Message-ID: 
References: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com> <5082C526.3050100@status.net> <00c501cdaf13$13ef6d30$3bce4790$@packetizer.com> <20121021093728.590d2898@bogo>    <094c01cdb4b3$6f78b620$4e6a2260$@packetizer.com>  <616511fcbbf92d7b8c63aaadf7dc7b86@packetizer.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: it-IT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
x-ti-disclaimer: Disclaimer1
MIME-Version: 1.0
Cc: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" 
Subject: [apps-discuss] R: WebFinger Draft Updated -	draft-ietf-appsawg-webfinger-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: Mon, 29 Oct 2012 15:04:28 -0000

--_54391536-a095-4cf2-b23b-7ecb0f74e58a_
Content-Type: multipart/alternative;
	boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A4EE495AGRFMBX704BA02_"

--_000_A09A9E0A4B9C654E8672D1DC003633AE53A4EE495AGRFMBX704BA02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

[snip]



Tel URIs are not useful for WebFinger since, as you note, there is
no associated host information.  However, we should allow any URI
that does have a domain part.  After all, the purpose is to go to
the server and say "tell me about this URI".  If the server knows,
it will provide an answer.  If the server has no information on the
URI, it will return a 404.
Sure, tho im not sure the language in the spec, but I guess it
should point out the WF is only oriented at those that have a domain
part, or list the ones that are valid?

I think this is pretty clear in the spec already, if not obvious on the fac=
e of it.  For example, bullet point 3 in Section 3 speaks of "URI at the ho=
st" and gives examples.  However, if we add text, I think the right place w=
ould be Section 5.4 where we talk about WebFinger and URIs. Perhaps we coul=
d add a sentence to the end of the first paragraph where we talk about WebF=
inger being URI scheme agnostic?  I'm not sure what to add, though.  Sugges=
tions?

Unsure on this one.  I guess if the reviewers at the IETF think it's self e=
vident, that should be fine.  There's so many URI schemes today that it's h=
ard to even know if there are grey areas on this one.

[walter] I guess the current "uri scheme-agnostic" text in 5.4 is fine. in =
general i would avoid formally restricting URI types through white- or blac=
klisting. This would allow a richer usage of this spec imo although it may =
not always be "meaningful". Specifically on tel URIs I'd like to recall the=
 enum draft [1] that aims at converting phone numbers into accounts to furt=
her perform webfinger requests. Yet in an alternative approach a "default" =
server (eg whose name is built based on mobile network information) could p=
robably handle wf requests to tel: URIs, whatever process rules are applied=
 at the server to answer or not that query and how (eg to "proxy" the reque=
st to the authoritative server/operator for that number)

[1] http://tools.ietf.org/html/draft-goix-appsawg-enum-acct-uri-00
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.

This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.

[cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No=
n stampare questa mail se non ? necessario.


--_000_A09A9E0A4B9C654E8672D1DC003633AE53A4EE495AGRFMBX704BA02_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

















[snip] 












   




Tel URIs are not usef=
ul for WebFinger since, as you note, there is

no associated host information.  However, we should allow any URI

that does have a domain part.  After all, the purpose is to go to

the server and say "tell me about this URI".  If the server =
knows,

it will provide an answer.  If the server has no information on the
URI, it will return a 404.




Sure, tho im not sure the language in the spec, but =
I guess it

should point out the WF is only oriented at those that have a domain

part, or list the ones that are valid?


 




I think this is pretty clear in the spec already, if=
 not obvious on the face of it.  For example, bullet point 3 in Sectio=
n 3 speaks of "URI at the host" and gives examples.  However=
, if we add text, I think the right place would be Section
 5.4 where we talk about WebFinger and URIs. Perhaps we could add a sentenc=
e to the end of the first paragraph where we talk about WebFinger being URI=
 scheme agnostic?  I'm not sure what to add, though.  Suggestions=
?








Unsure on this one.  I guess if the reviewers at the IETF think it's s=
elf evident, that should be fine.  There's so many URI schemes today t=
hat it's hard to even know if there are grey areas on this one. 



 


[walter] I guess the current “uri scheme-agnostic̶=
1; text in 5.4 is fine. in general i would avoid formally restricting URI t=
ypes through white-
 or blacklisting. This would allow a richer usage of this spec imo although=
 it may not always be “meaningful”. Specifically on tel URIs I&=
#8217;d like to recall the enum draft [1] that aims at converting phone num=
bers into accounts to further perform webfinger requests.
 Yet in an alternative approach a “default” server (eg whose na=
me is built based on mobile network information) could probably handle wf r=
equests to tel: URIs, whatever process rules are applied at the server to a=
nswer or not that query and how (eg to “proxy”
 the request to the authoritative server/operator for that number)


 


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


















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



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


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











--_000_A09A9E0A4B9C654E8672D1DC003633AE53A4EE495AGRFMBX704BA02_--

--_54391536-a095-4cf2-b23b-7ecb0f74e58a_
Content-Description: logo Ambiente_foglia2.jpg
Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg"
Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg"
Content-Transfer-Encoding: base64
Content-ID: 00000000000000000000000000000003@TI.Disclaimer

R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo
8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5
+4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9
p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw
SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0
FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6
YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl
uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds
3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV
OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi
oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn
qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs=

--_54391536-a095-4cf2-b23b-7ecb0f74e58a_--

From laurentwalter.goix@telecomitalia.it  Mon Oct 29 08:18:13 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2D421F8503 for ; Mon, 29 Oct 2012 08:18:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.094
X-Spam-Level: *
X-Spam-Status: No, score=1.094 tagged_above=-999 required=5 tests=[AWL=-2.812,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45,  RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qt+MVRsVb6WR for ; Mon, 29 Oct 2012 08:18:12 -0700 (PDT)
Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 75E5C21F84FD for ; Mon, 29 Oct 2012 08:18:11 -0700 (PDT)
Content-Type: multipart/mixed; boundary="_a5bc545c-37ef-438c-9afa-e00a6beb8baf_"
Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Mon, 29 Oct 2012 16:17:56 +0100
Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Mon, 29 Oct 2012 16:17:56 +0100
From: Goix Laurent Walter 
To: Salvatore Loreto , "apps-discuss@ietf.org" 
Date: Mon, 29 Oct 2012 16:17:54 +0100
Thread-Topic: [apps-discuss] New version of I-D for ENUM service for acct URI
Thread-Index: Ac211zko0ALeyw6SSYKCpn+0OTp7bAAEAIUQ
Message-ID: 
References:  <34966E97BE8AD64EAE9D3D6E4DEE36F21ED43779@szxeml525-mbx.china.huawei.com> <508E80DB.9030603@ericsson.com>
In-Reply-To: <508E80DB.9030603@ericsson.com>
Accept-Language: en-US, it-IT
Content-Language: it-IT
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, it-IT
x-ti-disclaimer: Disclaimer1
MIME-Version: 1.0
Subject: [apps-discuss] R: New version of I-D for ENUM service for acct URI
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Oct 2012 15:18:13 -0000

--_a5bc545c-37ef-438c-9afa-e00a6beb8baf_
Content-Type: multipart/related;
	boundary="_004_A09A9E0A4B9C654E8672D1DC003633AE53A4EE497DGRFMBX704BA02_";
	type="multipart/alternative"

--_004_A09A9E0A4B9C654E8672D1DC003633AE53A4EE497DGRFMBX704BA02_
Content-Type: multipart/alternative;
	boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A4EE497DGRFMBX704BA02_"

--_000_A09A9E0A4B9C654E8672D1DC003633AE53A4EE497DGRFMBX704BA02_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

VGhhbmsgeW91IHNhbHZhdG9yZSBmb3IgdGhlIHJldmlldy4gTXkgYW5zd2VycyBpbmxpbmUNCg0K
RGE6IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJv
dW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBTYWx2YXRvcmUgTG9yZXRvDQpJbnZpYXRvOiBs
dW5lZKisIDI5IG90dG9icmUgMjAxMiAxNC4xMw0KQTogYXBwcy1kaXNjdXNzQGlldGYub3JnDQpP
Z2dldHRvOiBSZTogW2FwcHMtZGlzY3Vzc10gTmV3IHZlcnNpb24gb2YgSS1EIGZvciBFTlVNIHNl
cnZpY2UgZm9yIGFjY3QgVVJJDQoNCkkgaGF2ZSByZWFkIHRoZSBsYXN0IHZlcnNpb24gb2YgdGhl
IGRyYWZ0LCBhbmQgSSB0aGluayB0aGF0IGlzIG1vcmUgdGhlbiByZWFzb25hYmxlIGFuZCB1c2Vm
dWwgcmVnaXN0ZXIgIGFuDQpFTlVNIHNlcnZpY2UgZm9yICdhY2N0JyBVUklzLg0KDQoNCmZyb20g
U2VjdGlvbiAzLCBpdCBpcyBub3QgY29tcGxldGVseSBjbGVhciB0byBtZSBpZiBPTUEgU29jaWFs
IE5ldHdvcmsgRW5hYmxlciB3aWxsIGJlIGJ1aWx0IG9uIGFjY3QgVVJJLA0Kb3IgaXQgaXMganVz
dCBhbiBleGFtcGxlIHRvIGhpZ2hsaWdodCB0aGUgbmVlZCB0byB0cmFuc2xhdGUgTVNJU0ROIHRv
ICJpbmZvcm1hdGlvbiBhYm91dCBwZW9wbGUgb24gdGhlIEludGVybmV0Ii4NCg0KW3dhbHRlcl0g
aW5kZWVkIHRoZSBlbmFibGVyIGJ1aWxkcyBvbiBhY2N0IDogVVJJcy4gU3VwcG9ydCBmb3IgYWNj
dDogYW5kIHRlbDogVVJJIHNjaGVtZXMgaXMgbWFuZGF0ZWQgaW4gdGhlIHNwZWMgKG9wdGlvbmFs
bHkgb3RoZXIgbWF5IGJlIHN1cHBvcnRlZCksIGFsc28gdG8gaW50ZXJvcGVyYXRlIHdpdGggbm9u
LW1vYmlsZSBzb2NpYWwgbmV0d29ya3MuIFJlZmVyZW5jZSB0byB0aGlzIGVudW0gZHJhZnQgaXMg
YWxzbyBwYXJ0IG9mIHRoZSBzcGVjIG9mIGNvdXJzZS4gSSBtYXkgY2xhcmlmeSB0aGlzIGluIHRo
ZSB0ZXh0IGlmIHlvdSBoYXZlIHNvbWUgc3VnZ2VzdGlvbi4NCg0KDQptb3Jlb3ZlciBpdCBpcyBh
bHNvIG5vdCBjbGVhciB0byB3aGF0IHNwZWNpZmljIGFjY3QgVVJJIGl0IHdpbGwgYmUgbWFwcGVk
Lg0KSSBtZWFuIGlzIGl0IGxpbWl0ZWQgdG8gdGhlIG9uZSBwcm92aWRlZCBieSB0aGUgdGVsZWNv
bSBzZXJ2aWNlIHByb3ZpZGVyIG9yIGl0IGNhbiBiZSBhbnkgYWNjdCBVUklzDQpbd2FsdGVyXSBh
bHRob3VnaCBpIGV4cGVjdCB0aGlzIHRvIGJlIHRoZSBtYWluIHVzZSBjYXNlIChtYWlubHkgc29s
dmluZyB0aGUgYXV0aG9yaXRhdGl2ZSB0ZWxjbyBmb3IgdGhhdCBudW1iZXIpIGl0IG1heSBub3Qg
YWx3YXlzIGJlIHRoZSBjYXNlLiBGb3IgZXhhbXBsZSBpZiB0aGF0IG51bWJlciBJcyBhIGNvbXBh
bnktcHJvdmlkZWQgbW9iaWxlIG51bWJlciwgaXQgbWF5IGFsc28gcG9pbnQgdG8gdGhlIHJlbGF0
ZWQgYWNjb3VudCAoanVzdCBsaWtlIHlvdSBjb3VsZCBmaW5kIGJvdGggZGV0YWlscyBvbiBhIGJ1
c2luZXNzIGNhcmQpLiBJIGNvdWxkIGNpdGUgdGhpcyB1c2UgY2FzZSBpbiB0aGUgZXhhbXBsZSBz
ZWN0aW9uIGlmIHlvdSBiZWxpZXZlIGl0IGlzIHJlbGV2YW50Lg0KDQp3YWx0ZXINCg0KDQp0aGFu
a3MNClNhbHZhdG9yZQ0KDQoNCi0tDQoNClNhbHZhdG9yZSBMb3JldG8sIFBoRA0KDQp3d3cuc2xv
cmV0by5jb208aHR0cDovL3d3dy5zbG9yZXRvLmNvbT4NCg0KDQoNCk9uIDkvMTMvMTIgMzozOCBB
TSwgTGlrZXBlbmcgd3JvdGU6DQpKdXN0IHRvIGNsYXJpZnkgdGhhdCBpbiB0aGUgcHJldmlvdXMg
ZW51bS1zbi1zZXJ2aWNlIGRyYWZ0LCBpdCBvbmx5IGZvY3VzZXMgb24gc29jaWFsIG5ldHdvcmsg
YWNjb3VudC4NCg0KTm93IGluIHRoZSBuZXcgZW51bS1hY2N0LXVyaSBkcmFmdCwgd2UgY2hhbmdl
IHRoYXQgdG8gYWNjdCB1cmksIGRvbqGvdCBsaW1pdCBpdCB0byBzb2NpYWwgbmV0d29yayBhY2Nv
dW50Lg0KDQpXZSByZWNlaXZlZCBtYW55IHZhbHVhYmxlIG9mZmxpbmUgZGlzY3Vzc2lvbiBjb21t
ZW50cyBmb3IgdGhlIHByZXZpb3VzIGRyYWZ0LCBob3BlIHRvIGdldCBmZWVkYmFjayB0byB0aGUg
bmV3IGRyYWZ0Lg0KDQpUaGFua3MsDQoNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQoNCreivP7Iyzog
R29peCBMYXVyZW50IFdhbHRlciBbbWFpbHRvOmxhdXJlbnR3YWx0ZXIuZ29peEB0ZWxlY29taXRh
bGlhLml0XQ0Kt6LLzSDKsbzkOiAyMDEyxOo51MIxMcjVIDIxOjU0DQrK1bz+yMs6IGFwcHMtZGlz
Y3Vzc0BpZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnPg0Ks63LzTogTGlrZXBl
bmcNCtb3zOI6IE5ldyB2ZXJzaW9uIG9mIEktRCBmb3IgRU5VTSBzZXJ2aWNlIGZvciBhY2N0IFVS
SQ0KDQpEZWFyIGFsbCwNCg0KSSBqdXN0IHVwbG9hZGVkIHRoaXMgZHJhZnQgWzFdIGFzIGEgcmV2
aXNpb24gb2YgZm9ybWVyIGRyYWZ0LWdvaXgtYXBwc2F3Zy1lbnVtLXNuLXNlcnZpY2UtMDIgYmFz
ZWQgb24gdGhlIGRpc2N1c3Npb24gaGVsZCBpbiBWYW5jb3V2ZXIuDQoNCkluIHBhcnRpY3VsYXIg
dGhlIHRleHQgd2FzIGdlbmVyYWxpemVkIGFuZCBhIHVzZSBjYXNlcyBzZWN0aW9uIHdhcyBhZGRl
ZCB0byBjbGFyaWZ5IHRoZSBwcm9ibGVtIHRvIGJlIHNvbHZlZCBhcyByZXF1ZXN0ZWQgYnkgRGF2
ZS4NCldlIGFsc28gZXhwYW5kZWQgdGhlIHNlY3VyaXR5IHNlY3Rpb24gdG8gY2xhcmlmeSBwb3Rl
bnRpYWwgcHJpdmFjeSBpc3N1ZXMgYXMgcmVxdWVzdGVkIGJ5IFRlZCBhbmQgSGFubmVzLCBmdXJ0
aGVyIGNsYXJpZnlpbmcgd2h5IGluc2VydGluZyBsaW5rIHJlbCBlbmRwb2ludCBkaXJlY3RseSBp
biBFTlVNIGl0c2VsZiBhcmUgbm90IGFwcHJvcHJpYXRlLiBUaGUgZXhhbXBsZSB3YXMgc2xpZ2h0
bHkgcmV2aXNlZCBhcyB3ZWxsLg0KDQpGaW5hbGx5LCBvbiB3aGV0aGVyIFJBSSBvciBBUFBTIHNo
b3VsZCBoYW5kbGUgdGhpcyBkcmFmdCwgdGhlIGF1dGhvcnMgc3BvbnNvciBBUFBTLCBhbmQgaW4g
cGFydGljdWxhciBBUFBTQVdHLCB3aGljaCBhbHJlYWR5IGhhbmRsZXMgdGhlIHdlYmZpbmdlciBh
bmQgYWNjdCB1cmkgZHJhZnRzIGFuZCB0aGUgcmVsYXRlZCBleHBlcnRzLiBFbnVtIGV4cGVydHMg
YWxyZWFkeSBwZXJmb3JtZWQgYSBzYW5pdHkgY2hlY2sgb24gcHJldmlvdXMgdmVyc2lvbnMgb2Yg
dGhpcyBkcmFmdC4NCg0KV2Ugd2VsY29tZSB5b3VyIGZlZWRiYWNrIG9uIHRoaXMgcmV2aXNpb24u
DQpXYWx0ZXINCg0KWzFdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdvaXgtYXBw
c2F3Zy1lbnVtLWFjY3QtdXJpLTAwDQoNCg0KUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxl
Z2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0
ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lIGRlcml2YW50
ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1l
bnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBl
ciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNv
bXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXpp
b25lLCBHcmF6aWUuDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlk
ZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZv
ciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5n
IG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0
aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55
IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFu
a3MuDQpbY2lkOmltYWdlMDAxLmdpZkAwMUNEQjVGMC4yMDg5RTk2MF1SaXNwZXR0YSBsJ2FtYmll
bnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIKioIG5lY2Vzc2FyaW8uDQoNCg0K
DQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNj
bHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBv
IHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVl
c3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJp
YXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVu
dGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBl
IGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1h
aWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHBy
aXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4g
RGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBp
cyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs
ZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0
aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0KW2NpZDowMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwM0BUSS5EaXNjbGFpbWVyXVJpc3BldHRhIGwnYW1iaWVudGUuIE5v
biBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gqKggbmVjZXNzYXJpby4NCg0K

--_000_A09A9E0A4B9C654E8672D1DC003633AE53A4EE497DGRFMBX704BA02_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Thank y=
ou salvatore for the review. My answers inline


 








Da: =
apps-discuss-bounces@ietf.org
 [mailto:apps-discuss-bounces@ietf.org] Per conto di Salvatore Loret=
o

Inviato: luned=A8=AC 29 ottobre 2012 14.13

A: apps-discuss@ietf.org

Oggetto: Re: [apps-discuss] New version of I-D for ENUM service for =
acct URI






 




I have read the last version of the draft, and I thi=
nk that is more then reasonable and useful register  an

ENUM service for 'acct' URIs.





from Section 3, it is not completely clear to me if OMA Social Network Enab=
ler will be built on acct URI,

or it is just an example to highlight the need to translate MSISDN to "=
;information about people on the Internet".


 


[walter=
] indeed the enabler builds on acct : URIs. Support for acct: and tel:=
 URI schemes is mandated in the spec (optionally other may be supported), a=
lso to interoperate with non-mobile social
 networks. Reference to this enum draft is also part of the spec of course.=
 I may clarify this in the text if you have some suggestion.






moreover it is also not clear to what specific acct URI it will be mapped.<=
br>
I mean is it limited to the one provided by the telecom service prov=
ider or it can be any acct URIs


[walter=
] although i expect this to be the main use case (mainly solving the author=
itative telco for that number) it may not always be the case. For example i=
f that number Is a company-provided mobile
 number, it may also point to the related account (just like you could find=
 both details on a business card). I could cite this use case in the exampl=
e section if you believe it is relevant.


&n=
bsp;


walter<=
o:p>






thanks

Salvatore






-- 


Salvatore Loreto, PhD


www.sloreto.com

  





On 9/13/12 3:38 AM, Likepeng wrote:






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



 


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


 


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


 


Thanks,


 


Kind Regards


Kepeng


 






=B7=A2=BC=FE=C8=CB: Goix Laurent
 Walter [mailto:laur=
entwalter.goix@telecomitalia.it]


=B7=A2=CB=CD
=CA=B1=BC=E4: 2012=C4=EA9=D4=C211=C8=D5
 21:54

=CA=D5=BC=FE=C8=CB:
apps-discuss@ietf.org

=B3=AD=CB=CD: Likepeng

=D6=F7=CC=E2: New version of I-D for ENUM service
 for acct URI






 


Dear all,


 


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


 


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



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


 


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


 


We welcome your feedback on thi=
s revision.


Walter


 


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


 


 










Questo messaggi=
o e i suoi allegati sono indirizzati esclusivamente alle persone
 indicate. La diffusione, copia o qualsiasi altra azione derivante dalla co=
noscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate=
 ricevuto questo documento per errore siete cortesemente pregati di darne i=
mmediata comunicazione al mittente
 e di provvedere alla sua distruzione, Grazie. 



This e-mail and any attachments&=
nbsp;is confidential and may contain privileged information intended
 for the addressee(s) only. Dissemination, copying, printing or use by anyb=
ody else is unauthorised. If you are not the intended recipient, please del=
ete this message and any attachments and advise the sender by return e-mail=
, Thanks.



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









 =





=
 













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



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


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











--_000_A09A9E0A4B9C654E8672D1DC003633AE53A4EE497DGRFMBX704BA02_--

--_004_A09A9E0A4B9C654E8672D1DC003633AE53A4EE497DGRFMBX704BA02_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=677;
	creation-date="Mon, 29 Oct 2012 15:17:55 GMT";
	modification-date="Mon, 29 Oct 2012 15:17:55 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo
8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5
+4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9
p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw
SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0
FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6
YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl
uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds
3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV
OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi
oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn
qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs=

--_004_A09A9E0A4B9C654E8672D1DC003633AE53A4EE497DGRFMBX704BA02_--

--_a5bc545c-37ef-438c-9afa-e00a6beb8baf_
Content-Description: logo Ambiente_foglia2.jpg
Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg"
Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg"
Content-Transfer-Encoding: base64
Content-ID: 00000000000000000000000000000003@TI.Disclaimer

R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo
8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5
+4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9
p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw
SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0
FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6
YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl
uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds
3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV
OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi
oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn
qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs=

--_a5bc545c-37ef-438c-9afa-e00a6beb8baf_--

From paulej@packetizer.com  Mon Oct 29 09:04:44 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCBB21F86DD for ; Mon, 29 Oct 2012 09:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.609,  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 ZDWgNso0PSYx for ; Mon, 29 Oct 2012 09:04:39 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4621A21F86C4 for ; Mon, 29 Oct 2012 09:04:39 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9TG4YCN032073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Oct 2012 12:04:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351526675; bh=mrtTUIVKtcDL/lJQwC6FRoZuiIiRpTnv05Jr+dHNrjQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Bg2g69RTfTJ3B7tN7sn2qkHefkpK31As++bGLcGyAJaYJ44carmjS+IGOq1YJM20s kVBmJiFZ/iGH7YNjvsZj0Fh0HwELJA7k8qPaU3p2IX09WM2QN6k5n0Yv98PzTHN3Ty e8aNyJlyfV8jKlLKVNU0zytKffKSfqokGZ1uXyU4=
From: "Paul E. Jones" 
To: "'Salvatore Loreto'" 
References: <031801cdb0bc$8a5048f0$9ef0dad0$@packetizer.com> <508D812C.5040708@ericsson.com> <09b801cdb54a$69abb340$3d0319c0$@packetizer.com> <508E44A3.909@ericsson.com>
In-Reply-To: <508E44A3.909@ericsson.com>
Date: Mon, 29 Oct 2012 12:04:39 -0400
Message-ID: <0ac401cdb5ef$1a5aec70$4f10c550$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0AC5_01CDB5CD.934BBD70"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKlQ0K+dU+mmhgivh5zej+ojwmWyQFDJ+TJAZa1L1kB4t0POpX7cO9g
Content-Language: en-us
Cc: webfinger@googlegroups.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Updated: draft-ietf-appsawg-webfinger-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, 29 Oct 2012 16:04:44 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0AC5_01CDB5CD.934BBD70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Sal,

 

Regarding error handling when using the "resource" parameter.  I have added
a couple of sentences and changed it slightly.  I have this:

 

If the WebFinger server needs to query an LRDD resource to collect
additional resource-specific information, any errors (e.g., 500 or 404) MUST
be handled by the server.  It is RECOMMENDED that if part of the
resource-specific information is available to return to the WebFinger client
that the server return the information is has.  If all requests made by the
server for resource-specific information fail, the server SHOULD return a
500 status code.  When a request for an LRDD fails, the server MUST NOT
attempt to augment missing resource information or return a "template" type
link relation to a client that utilizes the "resource" parameter.  Note that
a WebFinger server might be implemented such that all LRDD resource-specific
information can be resolved without issuing HTTP requests.  How a WebFinger
server collects and expands such resource-specific link relations is an
implementation matter.

 

How is this?  This allows some information through (if available), but we
specify to return 500 if the server fails to retrieve any at all.

 

Paul

 

From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] 
Sent: Monday, October 29, 2012 4:56 AM
To: Paul E. Jones
Cc: apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: [apps-discuss] Updated: draft-ietf-appsawg-webfinger-02.txt

 

On 10/28/12 10:25 PM, Paul E. Jones wrote:

Sal,

 

For (1), what is not aligned.  I saw in the abstract I used "one the
network" rather than "on the Internet" in once place, so I want to change
that. 


great!




Otherwise, it's different wording, but the same message, I think.  Perhaps
change "objects" in the Abstract to "other entities"?  


yes I would prefer "entities" to "objects"




What were you thinking in terms of alignment?


what you have already spotted. thanks! 




 

For (2), the "and" is easy.  

:-)



How to handle issues where the WF server fails to retrieve LRDD information
is more challenging.  The rationale was simply that we needed to provide an
answer to the question. ;-)  We should decide what the appropriate action
is.  We can either ignore it, which might result in a partial set of link
relations or no link relations.  That's the current wording.  


I think it is the right choice. It is much better to return a little set of
info then an error.
My concerns are more on the clarity of the text about the fact that in the
final response 
the LRDD that fails to be retrieved is completely removed 




The other option is to return some specific 5xx error code.  I'm happy with
whatever the group proposes here.

 

Related to (2), if the server is requesting 5 pieces of information in the
background and one request results in 5xx, do we return 5xx?  What if four
requests return a reply and one returns 404?  Does the server just ignore
the 404? Or does it return 5xx?  What if there are a mix of errors?


if we get only errors then we have to decide which is the most important to
return... :-)
but that is something that we can leave to the implementors

however if we have a mix of errors and info, then lets return the content
info we get 





 

For (3), I like "substantially" myself, because it does tell me something.
But, your point is taken.  Rather than removing "substantially", how about I
add the following sentence right after:

 

The only elements in the response that MAY be different include "subject",
"expires", and "aliases".

perfect! 
with this addition the all paragraph will be much clear.


Salvatore




-- 
Salvatore Loreto, PhD
www.sloreto.com





 

I think it is only those three that are affected.  The expires element might
change with every request, though if issued in parallel might be the same.
The subject line must change, of course, and if the subject changes, then
the set of aliases changes. 





 

Paul

 

From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] 
Sent: Sunday, October 28, 2012 3:02 PM
To: Paul E. Jones
Cc: apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: [apps-discuss] Updated: draft-ietf-appsawg-webfinger-02.txt

 

Hi Paul,

I have read the last 02 version and I have the following comments:

1)
In the Abstract, you define WebFinger

   WebFinger may be
   used to discover information about people on the Internet, such as a
   person's personal profile address, identity service, telephone
   number, or preferred avatar.

however I found this definition slightly different from the one you provide
in the Overview:

   WebFinger enables the discovery of information about accounts,
   devices, and other entities that are associated with a host.


I think it would be better to align the two


2) In Section 5.2 

       *  Collect and expand all resource-specific link relations,
          including those returned by querying for any LRDD link
          relations, discard any host-wide link relations, and return a
          complete resource descriptor following the processing rules in
          Section   4.2 of
RFC 6415; and
 

as a nit: above you should remove the "and".

 
 
   It is not the responsibility of the WebFinger server to verify, for
   example, that a URI pointing to a person's avatar is a valid URI.  If
   the WebFinger server needs to query an LRDD resource to collect
   additional resource-specific information, any errors (e.g., 500 or
   404) MUST be ignored by the server.  When a request for an LRDD
   fails, the server MUST NOT attempt to augment missing resource
   information or return a "template" type link relation to a client
   that utilizes the "resource" parameter.


Is it correct my interpretation that if a request for an LRDD fails, the
server will remove it from the response?
if so what is the rationale for this behavior?

3) In Section 5.4

   A host MAY utilize one or more URIs that serve as aliases for the
   user's account, such as URIs that use the "http" URI scheme [2
 ].  A
   WebFinger server MUST return substantially the same response to both
   an "acct" URI and any alias URI for the account, including the same
   set of link relations and properties.


I don't like the "MUST return substantially" expression, it leaves to much
ambiguities.
You should explicitly say what are the expected differences if any.


/Salvatore





-- 
Salvatore Loreto, PhD
www.sloreto.com



On 10/23/12 4:20 AM, Paul E. Jones wrote:

Folks,
 
I posted a slightly revised draft considering input received over the
weekend.  You can see the differences are fairly minor, but they were
changes I could easily make to improve the text.
 
Paul
 

-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: Monday, October 22, 2012 7:38 PM
To: i-d-announce@ietf.org
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-02.txt
 
 
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           : WebFinger
  Author(s)       : Paul E. Jones
                          Gonzalo Salgueiro
                          Joseph Smarr
  Filename        : draft-ietf-appsawg-webfinger-02.txt
  Pages           : 26
  Date            : 2012-10-22
 
Abstract:
   This specification defines the WebFinger protocol.  WebFinger may be
   used to discover information about people on the Internet, such as a
   person's personal profile address, identity service, telephone
   number, or preferred avatar.  WebFinger may also be used to discover
   information about objects on the network, such as the amount of toner
   in a printer or the physical location of a server.
 
 
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-02
 
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-02
 
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

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

 

 


------=_NextPart_000_0AC5_01CDB5CD.934BBD70
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Sal,
 
Regarding error handling when using the “resource” =
parameter.  I have added a couple of sentences and changed it =
slightly.  I have this:
 
If the WebFinger server needs to query an LRDD resource to collect =
additional resource-specific information, any errors (e.g., 500 or 404) =
MUST be handled by the server.  It is RECOMMENDED that if part of =
the resource-specific information is available to return to the =
WebFinger client that the server return the information is has.  If =
all requests made by the server for resource-specific information fail, =
the server SHOULD return a 500 status code.  When a request for an =
LRDD fails, the server MUST NOT attempt to augment missing resource =
information or return a “template” type link relation to a =
client that utilizes the “resource” parameter.  Note =
that a WebFinger server might be implemented such that all LRDD =
resource-specific information can be resolved without issuing HTTP =
requests.  How a WebFinger server collects and expands such =
resource-specific link relations is an implementation =
matter.
 
How is this?  This allows some information through (if =
available), but we specify to return 500 if the server fails to retrieve =
any at all.
 
Paul
 
From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] =

Sent: Monday, October 29, 2012 4:56 AM
To: Paul E. =
Jones
Cc: apps-discuss@ietf.org; =
webfinger@googlegroups.com
Subject: Re: [apps-discuss] =
Updated: =
draft-ietf-appsawg-webfinger-02.txt
 
On =
10/28/12 10:25 PM, Paul E. Jones wrote:
Sal,
 
For (1), what is not aligned.  I saw in the abstract I used =
“one the network” rather than “on the Internet” =
in once place, so I want to change that. =


great!


Otherwise, it’s different wording, but the same message, I =
think.  Perhaps change “objects” in the Abstract to =
“other entities”?  

yes I would prefer "entities" to =
"objects"


What were you thinking in terms of alignment?

what you have already spotted. thanks! =



 
For (2), the “and” is easy.  =

:-)

How to handle issues where the WF server fails to retrieve LRDD =
information is more challenging.  The rationale was simply that we =
needed to provide an answer to the question. ;-)  We should decide =
what the appropriate action is.  We can either ignore it, which =
might result in a partial set of link relations or no link =
relations.  That’s the current wording.  =


I think it is the right =
choice. It is much better to return a little set of info then an =
error.
My concerns are more on the clarity of the text about the fact =
that in the final response 
the LRDD that fails to be retrieved is =
completely removed 


The other option is to return some specific 5xx error code.  =
I’m happy with whatever the group proposes =
here.
 
Related to (2), if the server is requesting 5 pieces of information =
in the background and one request results in 5xx, do we return =
5xx?  What if four requests return a reply and one returns =
404?  Does the server just ignore the 404? Or does it return =
5xx?  What if there are a mix of errors?

if we get only errors then we have to decide which =
is the most important to return... :-)
but that is something that we =
can leave to the implementors

however if we have a mix of errors =
and info, then lets return the content info we get =




 
For (3), I like “substantially” myself, because it does =
tell me something.  But, your point is taken.  Rather than =
removing “substantially”, how about I add the following =
sentence right after:
 
The only elements in the response that MAY be different include =
“subject”, “expires”, and =
“aliases”.
perfect! 
with this addition the all paragraph will =
be much clear.


Salvatore


-- =

Salvatore Loreto, PhD
www.sloreto.com


 
I think it is only those three that are affected.  The expires =
element might change with every request, though if issued in parallel =
might be the same.  The subject line must change, of course, and if =
the subject changes, then the set of aliases changes. =



 
Paul
 
From: Salvatore Loreto [mailto:salvatore.loreto@eri=
csson.com] 
Sent: Sunday, October 28, 2012 3:02 =
PM
To: Paul E. Jones
Cc: apps-discuss@ietf.org; webfinger@googlegroups.com=

Subject: Re: [apps-discuss] Updated: =
draft-ietf-appsawg-webfinger-02.txt
 
Hi Paul,

I have read the last 02 =
version and I have the following comments:

1)
In the Abstract, =
you define WebFinger
   WebFinger may =
be
   used to discover information about =
people on the Internet, such as a
   =
person's personal profile address, identity service, =
telephone
   number, or preferred =
avatar.
however I found this definition slightly =
different from the one you provide in the =
Overview:
   WebFinger enables the =
discovery of information about =
accounts,
   devices, and other entities =
that are associated with a host.

I think it would be better to align =
the two


2) In Section 5.2 =

       *  =
Collect and expand all resource-specific link =
relations,
    =
      including those returned by querying =
for any LRDD =
link
        =
;  relations, discard any host-wide link relations, and return =
a
        &n=
bsp; complete resource descriptor following the processing rules =
in
        &=
nbsp; Section 4.2 =
of RFC 6415; and
 
as a nit: above you should remove the =
"and".
 
 
   It is not the responsibility of the =
WebFinger server to verify, for
   =
example, that a URI pointing to a person's avatar is a valid URI.  =
If
   the WebFinger server needs to query =
an LRDD resource to collect
   additional =
resource-specific information, any errors (e.g., 500 =
or
   404) MUST be ignored by the =
server.  When a request for an =
LRDD
   fails, the server MUST NOT =
attempt to augment missing resource
   =
information or return a "template" type link relation to a =
client
   that utilizes the =
"resource" parameter.

Is it correct my interpretation that =
if a request for an LRDD fails, the
server will remove it from the =
response?
if so what is the rationale for this behavior?

3) In =
Section 5.4
   A host MAY utilize one or =
more URIs that serve as aliases for =
the
   user's account, such as URIs that =
use the "http" URI scheme [2].  A
   =
WebFinger server MUST return substantially the same response to =
both
   an "acct" URI and any =
alias URI for the account, including the =
same
   set of link relations and =
properties.

I don't like the =
"MUST return substantially" expression, it leaves to much =
ambiguities.
You should explicitly say what are the expected =
differences if =
any.


/Salvatore



-- =

Salvatore Loreto, PhD
www.sloreto.com


On 10/23/12 4:20 AM, Paul E. Jones =
wrote:
Folks,
 
I posted a slightly revised draft =
considering input received over the
weekend.  =
You can see the differences are fairly minor, but they =
were
changes I could easily make to improve the =
text.
 
Paul
 
-----Original =
Message-----
From: apps-discuss-bounces@ietf.o=
rg [mailto:apps-discuss-
bounces@ietf.org] On Behalf Of =
internet-drafts@ietf.org
Sent: Monday, October 22, 2012 7:38 =
PM
To: i-d-announce@ietf.org
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: =
draft-ietf-appsawg-webfinger-02.txt
 
 
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           : =
WebFinger
  =
Author(s)       : Paul E. =
Jones
       &nbs=
p;            =
;      Gonzalo =
Salgueiro
       =
            &=
nbsp;      Joseph =
Smarr
  =
Filename        : =
draft-ietf-appsawg-webfinger-02.txt
  =
Pages           : =
26
  Date =
           : =
2012-10-22
 
Abstract:
   This specification defines the WebFinger =
protocol.  WebFinger may be
   used =
to discover information about people on the Internet, such as =
a
   person's personal profile address, =
identity service, telephone
   number, or =
preferred avatar.  WebFinger may also be used to =
discover
   information about objects on =
the network, such as the amount of =
toner
   in a printer or the physical =
location of a =
server.
 
 
The IETF datatracker status page for this draft =
is:
ht=
tps://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-02
 
A diff from the previous version is =
available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-02=

 
 
=

Internet-Drafts are also available by anonymous FTP =
at:
ftp://ftp.ietf.org/internet-=
drafts/
 
____________=
___________________________________
apps-discuss =
mailing list
apps-discuss@ietf.org
https://www.i=
etf.org/mailman/listinfo/apps-discuss
 
__________________________________________=
_____
apps-discuss mailing =
list
apps-discuss@ietf.org
https://www.i=
etf.org/mailman/listinfo/apps-discuss
 
 
 

------=_NextPart_000_0AC5_01CDB5CD.934BBD70--


From paulej@packetizer.com  Mon Oct 29 09:22:10 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE6221F8669 for ; Mon, 29 Oct 2012 09:22:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[AWL=-0.202,  BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTOOM0JfxDMV for ; Mon, 29 Oct 2012 09:22:08 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D669D21F8715 for ; Mon, 29 Oct 2012 09:22:07 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9TGM5b3000356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Oct 2012 12:22:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351527726; bh=OXA1gG/u6Bg3zNTJowde5nnvorl8Hxs3AOcmYSi/bdQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=QEW+li2s8UpZhcLHUUNJqSgFRsGcyN+XL/hARdWzqFDgZR/vAqUKzUp7aCtw2CFqL 12+cOuKCbmg51xQND+EEMdtBn3U9szCN4a5S0VCCTB2mSdtiyddkyl2mmC/fq1Rrec lmji6pCg0aNXyfLQNWnseXi5blOzVNvOuXnyRJ5A=
From: "Paul E. Jones" 
To: "'Goix Laurent Walter'" , "'Melvin Carvalho'" 
References: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com>	<5082C526.3050100@status.net>	<00c501cdaf13$13ef6d30$3bce4790$@packetizer.com>	<20121021093728.590d2898@bogo>				<094c01cdb4b3$6f78b620$4e6a2260$@packetizer.com>		<616511fcbbf92d7b8c63aaadf7dc7b86@packetizer.com>  
In-Reply-To: 
Date: Mon, 29 Oct 2012 12:22:10 -0400
Message-ID: <0adc01cdb5f1$8c9652a0$a5c2f7e0$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_0ADD_01CDB5D0.0585C410"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGcFKYbM2jJ0wiJf9oQM3Qhr6BdxwGjlKSjAlziv24CTWS12wD2u3/eAL94oFQB/N04zAHvy6dSAN+XiegCaNzriwGKl9m2AfZT7aaXneY5oA==
Content-Language: en-us
Cc: webfinger@googlegroups.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger Draft Updated -	draft-ietf-appsawg-webfinger-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: Mon, 29 Oct 2012 16:22:10 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0ADD_01CDB5D0.0585C410
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0ADE_01CDB5D0.0585C410"


------=_NextPart_001_0ADE_01CDB5D0.0585C410
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Walter,

=20

What you say is certainly true.  I believe that most service providers
operate their own ENUM services (if they use ENUM at all), so there is, =
in
effect, a default service.  The same could be extended to WF.  So, you =
make
a valid point.

=20

And, of course, I do like the mapping to acct URIs :-)

=20

Paul

=20

From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]=20
Sent: Monday, October 29, 2012 11:04 AM
To: Melvin Carvalho; Paul E. Jones
Cc: webfinger@googlegroups.com; apps-discuss@ietf.org
Subject: R: [apps-discuss] WebFinger Draft Updated -
draft-ietf-appsawg-webfinger-01

=20

[snip]=20



  =20

Tel URIs are not useful for WebFinger since, as you note, there is
no associated host information.  However, we should allow any URI
that does have a domain part.  After all, the purpose is to go to
the server and say "tell me about this URI".  If the server knows,
it will provide an answer.  If the server has no information on the
URI, it will return a 404.

Sure, tho im not sure the language in the spec, but I guess it
should point out the WF is only oriented at those that have a domain
part, or list the ones that are valid?

=20

I think this is pretty clear in the spec already, if not obvious on the =
face
of it.  For example, bullet point 3 in Section 3 speaks of "URI at the =
host"
and gives examples.  However, if we add text, I think the right place =
would
be Section 5.4 where we talk about WebFinger and URIs. Perhaps we could =
add
a sentence to the end of the first paragraph where we talk about =
WebFinger
being URI scheme agnostic?  I'm not sure what to add, though.  =
Suggestions?


Unsure on this one.  I guess if the reviewers at the IETF think it's =
self
evident, that should be fine.  There's so many URI schemes today that =
it's
hard to even know if there are grey areas on this one. =20

=20

[walter] I guess the current =93uri scheme-agnostic=94 text in 5.4 is =
fine. in
general i would avoid formally restricting URI types through white- or
blacklisting. This would allow a richer usage of this spec imo although =
it
may not always be =93meaningful=94. Specifically on tel URIs I=92d like =
to recall
the enum draft [1] that aims at converting phone numbers into accounts =
to
further perform webfinger requests. Yet in an alternative approach a
=93default=94 server (eg whose name is built based on mobile network
information) could probably handle wf requests to tel: URIs, whatever
process rules are applied at the server to answer or not that query and =
how
(eg to =93proxy=94 the request to the authoritative server/operator for =
that
number)

=20

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


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

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

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non =
=E8
necessario.=20

=20


------=_NextPart_001_0ADE_01CDB5D0.0585C410
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Walter,
 
What you say is certainly true.=A0 I believe that most service =
providers operate their own ENUM services (if they use ENUM at all), so =
there is, in effect, a default service.=A0 The same could be extended to =
WF.=A0 So, you make a valid point.
 
And, of course, I do like the mapping to acct URIs =
:-)
 
Paul
 
From:=
 =
Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] =

Sent: Monday, October 29, 2012 11:04 AM
To: Melvin =
Carvalho; Paul E. Jones
Cc: webfinger@googlegroups.com; =
apps-discuss@ietf.org
Subject: R: [apps-discuss] WebFinger =
Draft Updated - =
draft-ietf-appsawg-webfinger-01
 
[snip] 


  =
 
Tel URIs are not useful for WebFinger since, as you note, =
there is
no associated host information.  However, we should =
allow any URI
that does have a domain part.  After all, the =
purpose is to go to
the server and say "tell me about this =
URI".  If the server knows,
it will provide an answer. =
 If the server has no information on the
URI, it will return a =
404.
Sure, tho im not sure the language in the spec, but I guess =
it
should point out the WF is only oriented at those that have a =
domain
part, or list the ones that are valid?
 
I think this is pretty clear in the =
spec already, if not obvious on the face of it.  For example, =
bullet point 3 in Section 3 speaks of "URI at the host" and =
gives examples.  However, if we add text, I think the right place =
would be Section 5.4 where we talk about WebFinger and URIs. Perhaps we =
could add a sentence to the end of the first paragraph where we talk =
about WebFinger being URI scheme agnostic?  I'm not sure what to =
add, though. =
 Suggestions?

Unsure on this one.  I guess =
if the reviewers at the IETF think it's self evident, that should be =
fine.  There's so many URI schemes today that it's hard to even =
know if there are grey areas on this one.  
 
[walter] I guess the current “uri scheme-agnostic” text =
in 5.4 is fine. in general i would avoid formally restricting URI types =
through white- or blacklisting. This would allow a richer usage of this =
spec imo although it may not always be “meaningful”. =
Specifically on tel URIs I’d like to recall the enum draft [1] =
that aims at converting phone numbers into accounts to further perform =
webfinger requests. Yet in an alternative approach a =
“default” server (eg whose name is built based on mobile =
network information) could probably handle wf requests to tel: URIs, =
whatever process rules are applied at the server to answer or not that =
query and how (eg to “proxy” the request to the =
authoritative server/operator for that number)
 
[1] h=
ttp://tools.ietf.org/html/draft-goix-appsawg-enum-acct-uri-00 =

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

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

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

------=_NextPart_001_0ADE_01CDB5D0.0585C410--

------=_NextPart_000_0ADD_01CDB5D0.0585C410
Content-Type: image/gif;
	name="image001.gif"
Content-Transfer-Encoding: base64
Content-ID: 

R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo
8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5
+4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9
p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw
SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0
FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6
YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl
uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds
3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV
OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi
oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn
qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs=

------=_NextPart_000_0ADD_01CDB5D0.0585C410--


From perpetual-tripper@wwelves.org  Mon Oct 29 12:13:07 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DA121F85FE for ; Mon, 29 Oct 2012 12:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.285
X-Spam-Level: 
X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_42=0.6, 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 9SKrjJPNvgv2 for ; Mon, 29 Oct 2012 12:13:06 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC1A21F85F3 for ; Mon, 29 Oct 2012 12:13:06 -0700 (PDT)
X-Originating-IP: 217.70.178.138
Received: from mfilter9-d.gandi.net (mfilter9-d.gandi.net [217.70.178.138]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id F35BDA80A2; Mon, 29 Oct 2012 20:12:52 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter9-d.gandi.net
Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter9-d.gandi.net (mfilter9-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id g2sL16YF+bwQ; Mon, 29 Oct 2012 20:12:51 +0100 (CET)
X-Originating-IP: 217.11.53.243
Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 87A82A80BC; Mon, 29 Oct 2012 20:12:51 +0100 (CET)
Content-Type: text/plain; charset=UTF-8
From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= 
To: webfinger 
Date: Mon, 29 Oct 2012 19:12:50 +0000
Message-Id: <1351537589-sup-4189@heahdk.net>
User-Agent: Sup/0.12.1
Content-Transfer-Encoding: quoted-printable
Cc: apps-discuss 
Subject: [apps-discuss] Fwd: Transferable Identifiers
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Oct 2012 19:13:07 -0000

similar topic to one i spoken few times about on webfinger mailing list c=
ame up at list working on Mozilla Persona, scanning through webfinger lat=
est draft i couldn't spot our current solution for this case, i would app=
reciate pointing me to related section :) section 6.2 looks close but giv=
es no notion that i decided to deprecate use of requested account in favo=
r of another one. thanks!

--- Begin forwarded message from Sean McArthur ---
From: Sean McArthur 
To: dev-identity 
Date: Mon, 29 Oct 2012 18:36:24 +0000
Subject: Transferable Identifiers

This was brought up by the tent.io guys, but it's relevant to everyone. I
may start using Persona by logging in with my Gmail account. But
eventually, say Gmail becomes (more) evil, or I simply want to move to my
own domain, there is no way to use Persona to login with my new identifie=
r.
I can start using my new identifier, but that will give me brand new
accounts on all the sites I frequent.

Can we solve the desire to be able to change my e-mail address (or in the
future, some other kind of identifier) and have it be a decent experience
using Persona?
--- End forwarded message ---

From sm@resistor.net  Mon Oct 29 13:17:30 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED5021F86CD for ; Mon, 29 Oct 2012 13:17:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.297
X-Spam-Level: 
X-Spam-Status: No, score=-102.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 Dvy8gKUm3VbQ for ; Mon, 29 Oct 2012 13:17:29 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EEE21F85F5 for ; Mon, 29 Oct 2012 13:17:28 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q9TKHNW3024657 for ; Mon, 29 Oct 2012 13:17:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351541847; bh=hj1n1Nq/qyNB8ueKsLTTk2spS83Mqyc4OPS3NCo9QZU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=eYiZemfcYx3n9UpoLdjziHM8Tv6Fq+0VIl3srXHmFt50wHy6/1sp4r9B6P8/8APBY XHT/TvIEAocr75n3+YJCsYUlF7OcHXTiYW/vMPkJj21EIaIjPsXw4L96bg8rkComvE pPInli6UG0biYisDs2uoyVoI2++a+34DKoWg4+FY=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351541847; i=@resistor.net; bh=hj1n1Nq/qyNB8ueKsLTTk2spS83Mqyc4OPS3NCo9QZU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=kbVUCApVlBNhWMQHcMgpPH5HDjdICw6LC9YxIa90oGOdqDPnFgmYkpYEf+F4eABnv clC3S34JxLp0uCAPpqu+Gb4JxHSsxxv/ljyMPutIjVtuswsx0LXvceduEJnihEb+a1 e1kFTiCPlW28OL9X5W5WvatTGsKfHNNOE3BOHskM=
Message-Id: <6.2.5.6.2.20121029123813.0a776890@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 29 Oct 2012 13:04:04 -0700
To: apps-discuss@ietf.org
From: SM 
In-Reply-To: <508E66FB.4070708@cs.tcd.ie>
References: <508E66FB.4070708@cs.tcd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Oct 2012 20:17:30 -0000

At 04:22 29-10-2012, Stephen Farrell wrote:
>More generally, it'd be good if webfinger privacy were discussed
>more on the list since maybe there are other privacy issues or
>mitigations that'd be better or easier.

I took a look at draft-ietf-appsawg-webfinger-02.  From Section 11:

   "The easy access to user information via WebFinger was a design goal
    of the protocol, not a limitation."

The draft relies on "users [to] understand the risks".  I don't see 
any text in the draft for someone to understand the issues and assess 
the risks.  In my humble opinion the user information which will be 
made world-readable can generate enough work to keep a working group 
busy for some time.  The paragraph I quoted basically says that the 
design goal is to publish "private" information on the Internet.  I 
think that the protocol will be successful until people start asking 
for the "right to be deleted".

What's the plan to tackle the privacy issues?

Regards,
-sm 


From fgaliegue@gmail.com  Mon Oct 29 13:20:31 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754AC21F86C7 for ; Mon, 29 Oct 2012 13:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level: 
X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 nV0-uiaWzzXV for ; Mon, 29 Oct 2012 13:20:28 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F08CE21F86C4 for ; Mon, 29 Oct 2012 13:20:27 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id v19so5637285obq.31 for ; Mon, 29 Oct 2012 13:20:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=dBR8QLl+U4wi+uQ9ip+C8CvkC1y8bh+iiUYHQROhdzM=; b=jOgJicf4ZVls8uvIF8oDDXZFKQMomr+WOdq8C1jz06TWNKykbXYdXfrah/8C2+aIIC /2hMQZi6DRknx+L3YZSXxVkM3YRxopN03Rs3xfO0Q9EH+LC4jCdTQGvfmacSD3WWq2QK EazWft7szQ6+UNTRJPMZoAiAmmErGOvN3bMGszKcKKdNlG/RTlKu0CwVgmR9jnhGJaS6 wADZZLASVGbHIz/rpD31U6Y/qZJffjEr79kdcgA2Lbn0L0bitHNphLkmb1zz52NIe4SG nJsBUtfU/DaGc9Z3mNWYYcWqnfuABc2YHNH3bPBJKa2Z2xrsT5B3W2xf+IMqHLmJfExO BRYg==
MIME-Version: 1.0
Received: by 10.182.31.43 with SMTP id x11mr25495796obh.68.1351542027653; Mon, 29 Oct 2012 13:20:27 -0700 (PDT)
Received: by 10.60.32.163 with HTTP; Mon, 29 Oct 2012 13:20:27 -0700 (PDT)
In-Reply-To: 
References:    
Date: Mon, 29 Oct 2012 21:20:27 +0100
Message-ID: 
From: Francis Galiegue 
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [apps-discuss] RFC 4627 and text vs values
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Oct 2012 20:20:31 -0000

On Wed, Oct 24, 2012 at 12:51 AM, Francis Galiegue  wr=
ote:
> On Thu, Sep 27, 2012 at 3:01 PM, Francis Galiegue  w=
rote:
> [...]
>>
>> That kind of begs the question: why wouldn't it be legal to produce
>> JSON values other than arrays/objects? "Primitve" JSON values are
>> potentially useful as well, I don't see the point of forbidding their
>> production. This looks like limiting the expressiveness of JSON to me.
>>
>
> Ping on that one...
>

Ping again.

The more I think about it, the less the definition of a "JSON text" makes s=
ense.

--=20
Francis Galiegue, fgaliegue@gmail.com
"It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries" (St=C3=A9phane Faroult, in "The
Art of SQL", ISBN 0-596-00894-5)

From paulej@packetizer.com  Mon Oct 29 14:30:18 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9BF21F870C for ; Mon, 29 Oct 2012 14:30:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.075
X-Spam-Level: 
X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.524,  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 IXSk4tkvo5Cu for ; Mon, 29 Oct 2012 14:30:17 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7612F21F8702 for ; Mon, 29 Oct 2012 14:30:17 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9TLUBSC013659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Oct 2012 17:30:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351546213; bh=OAGueHKLROPUsHYS5vSkzAES6O2bhd47pbbrhJfIjzQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=oQ3qIasc1ck8iQbr9iLCXXCH/lleqSYi5BnAxoGsVmSh+auMbUU3vj9jAaHqhwJCw fdvoqsaf5NkvnOAI2TvmNkzpFK86rd0MbNs5LVA8bU+KY92FLSviUCHumnNAw+YacE y2rSATcejbl6tZVVPc8LGwWhKQInP+Pbq9nQuBf0=
From: "Paul E. Jones" 
To: "'Stephen Farrell'" , "'Apps Discuss'" 
References: <508E66FB.4070708@cs.tcd.ie>
In-Reply-To: <508E66FB.4070708@cs.tcd.ie>
Date: Mon, 29 Oct 2012 17:30:17 -0400
Message-ID: <0b3b01cdb61c$981dc600$c8595200$@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: AQFLsjjsRNcR0N0rPY8CMxV87xY2TZjU0Yrw
Content-Language: en-us
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Oct 2012 21:30:18 -0000

Stephen,

> The draft says:
> 
> "  Let's assume your email client discovers that blog automatically for
>    you.  After receiving the message from Bob (bob@example.com), your
>    email client performs the following steps behind the scenes."
> 
> ...then describes how I send out a request containing the string
> bob@example.com.
> 
> The net result of that appears to be that I'll be sending out details
> about who I'm contacting (or want to contact) to a server with which
> I've no existing relationship, and that is probably going to turn out to
> be operated by one of the few very large providers.
> 
> That seems to me to have potentially serious privacy issues. (As with
> all privacy issues, you never know when they're more than potential
> until its too late;-)
> 
> Is that accurate?

Yes, though be mindful that this just an non-normative example.
 
> I wondered why the wg didn't consider (even as an option) allowing the
> client to send a hash of Bob's URI? That way, if the request goes to the
> wrong place, things are a bit more privacy friendly.
> (I think an earlier draft from James Snell suggested this, but don't
> recall subsequent discussion about that.)

The request should not go to the wrong place, though a request could get
intercepted on the wire.  It is for these reasons that we strongly recommend
use of TLS.
 
> One argument for doing something privacy friendly here is that it would
> make sense to follow the approach of the safe web browsing mechanisms
> here - if its considered sensitive to tell a large provider about the
> URLs I'm visiting, then why is it ok to tell such a provider the names
> of the people I want to finger?
> (Having said that, yes, other mechanisms, such as URL completion take
> the opposite approach.)

Whether we hash the information or not, a request received at the legitimate
WebFinger server would still know what is being requested.  I think the only
case of concern is when non-TLS connections are used.
 
> More generally, it'd be good if webfinger privacy were discussed more on
> the list since maybe there are other privacy issues or mitigations
> that'd be better or easier.

We've had only a little discussion on privacy and I've tried to insert text
to address the concerns that have been raised in Section 11 (security
considerations), though I would be happy to insert a whole section on
privacy considerations if given some text.
 
> (Note: I would raise a DISCUSS during IESG eval for this, but since it
> could lead to a change in the protocol, I'm raising it now in the hope
> that's more likely to be doable if it needs to be done.)

We should certainly cover any security and privacy concerns, but the fact of
the matter is that use of WebFinger, Google, or any other service where you
search for information is going to reveal certain information about you.
Likewise, posting any information where the public can retrieve it has its
risks, which is why servers should be controlled and access to web resources
controlled.

If the security considerations section does not have the wording to address
concerns, then please provide some words and I'd be happy to add them.

Paul



From paulej@packetizer.com  Mon Oct 29 15:09:47 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE59821F86CD for ; Mon, 29 Oct 2012 15:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.113
X-Spam-Level: 
X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.486,  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 xqHps2I5h4aV for ; Mon, 29 Oct 2012 15:09:47 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 04ACF21F86C4 for ; Mon, 29 Oct 2012 15:09:46 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9TM9jeC015340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Oct 2012 18:09:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351548586; bh=Syl7EfK0b1xZ+BHVAZUyvRrxB3dE6vAOti92ZLS/yzk=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=roHT9fQzNx/OIzIZq7a3BjxjET588CxvEFmxt5+PFu3pp6oRkHeJQcccBbMz3/ezg o5vguvzEdxsT+ZZXgd8s/QjRLf2FYY+saTOI6jeM88rnufERyLKqKhh0YZdOxG+WFM IHXjiZACzcsW5MyMlpipbNfLucvEef+7EwxnRPdg=
From: "Paul E. Jones" 
To: "'SM'" , 
References: <508E66FB.4070708@cs.tcd.ie> <6.2.5.6.2.20121029123813.0a776890@resistor.net>
In-Reply-To: <6.2.5.6.2.20121029123813.0a776890@resistor.net>
Date: Mon, 29 Oct 2012 18:09:51 -0400
Message-ID: <0b4001cdb622$1e9fe0f0$5bdfa2d0$@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: AQFLsjjsRNcR0N0rPY8CMxV87xY2TQEpgXkamMuRaeA=
Content-Language: en-us
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Oct 2012 22:09:48 -0000

You didn't keep quoting.  It goes on to advise that if you wish to restrict
what information can be accessed, you should take such actions.

I can (and do actually) put all kinds of contact information on my personal
web page.  If people want to find that, they could.  Likewise, I could just
not publish it.  Just because a WF server exists does not mean one has to
populate it with information -- especially private information.

Consider Google+ as an example.  Information you share there is published
via WebFinger.  However, you as the user gets to select what information is
made public and what information is not.

Paul

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of SM
> Sent: Monday, October 29, 2012 4:04 PM
> To: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] webfinger privacy question/suggestion
> 
> At 04:22 29-10-2012, Stephen Farrell wrote:
> >More generally, it'd be good if webfinger privacy were discussed more
> >on the list since maybe there are other privacy issues or mitigations
> >that'd be better or easier.
> 
> I took a look at draft-ietf-appsawg-webfinger-02.  From Section 11:
> 
>    "The easy access to user information via WebFinger was a design goal
>     of the protocol, not a limitation."
> 
> The draft relies on "users [to] understand the risks".  I don't see any
> text in the draft for someone to understand the issues and assess the
> risks.  In my humble opinion the user information which will be made
> world-readable can generate enough work to keep a working group busy for
> some time.  The paragraph I quoted basically says that the design goal
> is to publish "private" information on the Internet.  I think that the
> protocol will be successful until people start asking for the "right to
> be deleted".
> 
> What's the plan to tackle the privacy issues?
> 
> Regards,
> -sm
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From stephen.farrell@cs.tcd.ie  Mon Oct 29 15:51:53 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB5B21F866D for ; Mon, 29 Oct 2012 15:51:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.496
X-Spam-Level: 
X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 dE6eTjb3aHfV for ; Mon, 29 Oct 2012 15:51:52 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B640D21F866C for ; Mon, 29 Oct 2012 15:51:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A278EC786; Mon, 29 Oct 2012 22:51:29 +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 HrKO0HWnCnUz; Mon, 29 Oct 2012 22:51:28 +0000 (GMT)
Received: from [10.87.48.4] (unknown [86.42.183.189]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7AE58C3B1; Mon, 29 Oct 2012 22:51:28 +0000 (GMT)
Message-ID: <508F0870.9050402@cs.tcd.ie>
Date: Mon, 29 Oct 2012 22:51:28 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1
MIME-Version: 1.0
To: "Paul E. Jones" 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com>
In-Reply-To: <0b3b01cdb61c$981dc600$c8595200$@packetizer.com>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: 'Apps Discuss' 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Oct 2012 22:51:53 -0000

Hiya,

On 10/29/2012 09:30 PM, Paul E. Jones wrote:
> Stephen,
> 
>> The draft says:
>>
>> "  Let's assume your email client discovers that blog automatically for
>>    you.  After receiving the message from Bob (bob@example.com), your
>>    email client performs the following steps behind the scenes."
>>
>> ...then describes how I send out a request containing the string
>> bob@example.com.
>>
>> The net result of that appears to be that I'll be sending out details
>> about who I'm contacting (or want to contact) to a server with which
>> I've no existing relationship, and that is probably going to turn out to
>> be operated by one of the few very large providers.
>>
>> That seems to me to have potentially serious privacy issues. (As with
>> all privacy issues, you never know when they're more than potential
>> until its too late;-)
>>
>> Is that accurate?
> 
> Yes, though be mindful that this just an non-normative example.

Sure. But one that does nicely expose the privacy concern.

>> I wondered why the wg didn't consider (even as an option) allowing the
>> client to send a hash of Bob's URI? That way, if the request goes to the
>> wrong place, things are a bit more privacy friendly.
>> (I think an earlier draft from James Snell suggested this, but don't
>> recall subsequent discussion about that.)
> 
> The request should not go to the wrong place, though a request could get
> intercepted on the wire.  It is for these reasons that we strongly recommend
> use of TLS.

Use of TLS is great (though some of the text about that might
need tweaking). But the wrong place problem needs more work
I suspect. In particular the (as you say non-normative) example
quoted says that this is all happening in the background, and
you don't normatively say how a client figures out the host to
query. Now maybe you can't in general, but if not, then I think
that causes the problem and TLS is no help in that.

One danger here would be that my mail client might by default
tell BigCo about the sender header field of all the mail I
receive and when I got it and might not give me any control
over that, all to try find a sender's blog 1 RTT quicker.
That'd be a bad thing to do by accident, right?

Another might be contexts where the derivation of the host
to use is less clear. In the case of mail, should I use the
sender or From domain for example if those differ? What about
mailing lists? Are there similar ambiguities in XMPP or other
protocols? I'd love to have a warm feeling that that's all
been considered - and maybe it has, but I don't get that
warm feeling as of now from the draft and my recollection of
the list traffic on this.

>> One argument for doing something privacy friendly here is that it would
>> make sense to follow the approach of the safe web browsing mechanisms
>> here - if its considered sensitive to tell a large provider about the
>> URLs I'm visiting, then why is it ok to tell such a provider the names
>> of the people I want to finger?
>> (Having said that, yes, other mechanisms, such as URL completion take
>> the opposite approach.)
> 
> Whether we hash the information or not, a request received at the legitimate
> WebFinger server would still know what is being requested.  I think the only
> case of concern is when non-TLS connections are used.

Right, non-TLS to the wrong place is the main concern. It could
be that some re-direction cases might also be an issue but not
sure.

>> More generally, it'd be good if webfinger privacy were discussed more on
>> the list since maybe there are other privacy issues or mitigations
>> that'd be better or easier.
> 
> We've had only a little discussion on privacy and I've tried to insert text
> to address the concerns that have been raised in Section 11 (security
> considerations), though I would be happy to insert a whole section on
> privacy considerations if given some text.

I hope that discussion happens on the list.

>> (Note: I would raise a DISCUSS during IESG eval for this, but since it
>> could lead to a change in the protocol, I'm raising it now in the hope
>> that's more likely to be doable if it needs to be done.)
> 
> We should certainly cover any security and privacy concerns, but the fact of
> the matter is that use of WebFinger, Google, or any other service where you
> search for information is going to reveal certain information about you.

Personally, I think the key thing is to try make sure that the
very very few folks who care are given some way to mitigate
their concerns, or if that's not possible say then that its not
possible after the list has had the discussion that reached
that conclusion.

> Likewise, posting any information where the public can retrieve it has its
> risks, which is why servers should be controlled and access to web resources
> controlled.

Yes, you cover that already at least to some extent and
there was some discussion on the list about it. I'm
not clear if that's considered "done" or not though (can't
recall). I guess the issue is whether there are any knobs
the user could twist or not, and at present, it's "not"
so webfinger is something that, if you use it, all the
stuff you put at one host is available to anyone who
can access that host. (Is that right?)

I think that that's mostly ok, perhaps with some added
advice about publishing stuff aimed at coders, e.g. to
say "don't automatically publish users' information
since that'd be a crappy way to deal with folks who
care about privacy" or similar.

> If the security considerations section does not have the wording to address
> concerns, then please provide some words and I'd be happy to add them.

I'd hope those emerge from list discussion - just
because I'd DISCUSS the current text doesn't make me
the right person to suggest new text.

Cheers,
S.


> 
> Paul
> 
> 
> 
> 

From jasnell@gmail.com  Mon Oct 29 16:10:10 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EF421F8648 for ; Mon, 29 Oct 2012 16:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRQZvryT8crv for ; Mon, 29 Oct 2012 16:10:10 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8776121F861B for ; Mon, 29 Oct 2012 16:10:09 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 9so8422623iec.31 for ; Mon, 29 Oct 2012 16:10:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YtqBM37nPWgfMvO71IWfUWumc/RcdwUhkjSIdTxqwdE=; b=e5SsYvuf+nPg8jydh94Xm0cg/uStE/bF4dXylJF1dAueEtAV/y7FaMCnBh+abbBy7v FAFLUy40G7joW+nDbTfQBH4zn7PBWcc//EkDPHxnU35e7VCZBlAsMUOo4L5EFPPrpFJW yz06ZAk+OkDPHsqg5/iMMUsN+8OEvZe6utmPCfs/DQX/llL8x7s4yWfroMnoA5R/zMV8 A8bTDMSqdyGmdPsWgzyktWWI2kdjccYVLQEC1U2SSa2rkphPg5uruQAKoJEXJibevut+ tu1LrbGNQFGJ8iVWrbXhfZy4RN/i9WBFX6jOSXFIgIp81fR7UVIe20WD3C6pnmhZ6piS UKUQ==
Received: by 10.42.180.10 with SMTP id bs10mr26520059icb.39.1351552208971; Mon, 29 Oct 2012 16:10:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.46.225 with HTTP; Mon, 29 Oct 2012 16:09:48 -0700 (PDT)
In-Reply-To: <0b3b01cdb61c$981dc600$c8595200$@packetizer.com>
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com>
From: James M Snell 
Date: Mon, 29 Oct 2012 16:09:48 -0700
Message-ID: 
To: "Paul E. Jones" 
Content-Type: multipart/alternative; boundary=90e6ba6e8aee4fa91004cd3ac5ff
Cc: Apps Discuss 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Oct 2012 23:10:11 -0000

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

On Mon, Oct 29, 2012 at 2:30 PM, Paul E. Jones wrote:

> [snip]
> >
> > That seems to me to have potentially serious privacy issues. (As with
> > all privacy issues, you never know when they're more than potential
> > until its too late;-)
> >
> > Is that accurate?
>
> Yes, though be mindful that this just an non-normative example.
>
>
Even so, it's an example that you explicitly call out in your spec that
very clearly highlights a privacy concern. If you're going to raise such an
example and not deal with the privacy implications beyond "use TLS", then
there is a problem. See below...


>
> > One argument for doing something privacy friendly here is that it would
> > make sense to follow the approach of the safe web browsing mechanisms
> > here - if its considered sensitive to tell a large provider about the
> > URLs I'm visiting, then why is it ok to tell such a provider the names
> > of the people I want to finger?
> > (Having said that, yes, other mechanisms, such as URL completion take
> > the opposite approach.)
>
> Whether we hash the information or not, a request received at the
> legitimate
> WebFinger server would still know what is being requested.  I think the
> only
> case of concern is when non-TLS connections are used.
>
>
That's not necessarily true. Some subcomponent of the server would have
access to the data, yes, but that doesn't mean every subcomponent on that
server should be allowed to have access to that information. Further, it
does not necessarily follow that the server is required to know exactly
whose data it is serving up.. just that there is some blob of data about
someone or something being requested. URLs and query string parameters tend
to wind up getting recorded in server logs that are completely unprotected
by TLS. Hashing the identities makes it significantly more difficult to
mine those for useful information (obviously not impossible, but the idea
is to make it more difficult, not impossible).

Note also, there are organizations with existing policies in place
forbidding the use of email identifiers within URI parameters. This is the
precise reason why lotus connections, for instance, provides an option to
use alternative identifiers within URIs. For such organizations, use of
WebFinger uri's is going to be quite problematic at best.

 [snip]

> We should certainly cover any security and privacy concerns, but the fact
> of
> the matter is that use of WebFinger, Google, or any other service where you
> search for information is going to reveal certain information about you.
> Likewise, posting any information where the public can retrieve it has its
> risks, which is why servers should be controlled and access to web
> resources
> controlled.
>
> If the security considerations section does not have the wording to address
> concerns, then please provide some words and I'd be happy to add them.
>
>
This is not really a question about just coming up with additional language
for the security concerns section, the ability to support hashed
identifiers rather than email or acct: id's should be built into the
protocol. In fact, for a protocol such as this, privacy should be THE
default option. Meaning, hashed identifiers should always be used, IMHO.

- James


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

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



On Mon, Oct 29, 2012 at 2:30 PM, Paul E. Jones <paulej@packetizer.=
com> wrote:



[snip]

>

> That seems to me to have potentially serious privacy issues. (As with<=
br>
> all privacy issues, you never know when they're more than potentia=
l

> until its too late;-)

>

> Is that accurate?




Yes, though be mindful that this just an non-normative example.




Even so, it=
9;s an example that you explicitly call out in your spec that very clearly =
highlights a privacy concern. If you're going to raise such an example =
and not deal with the privacy implications beyond "use TLS", then=
 there is a problem. See below...



=C2=A0


> One argument for doing something privacy friendly here is that it woul=
d

> make sense to follow the approach of the safe web browsing mechanisms<=
br>
> here - if its considered sensitive to tell a large provider about the<=
br>
> URLs I'm visiting, then why is it ok to tell such a provider the n=
ames

> of the people I want to finger?

> (Having said that, yes, other mechanisms, such as URL completion take<=
br>
> the opposite approach.)




Whether we hash the information or not, a request received at the leg=
itimate

WebFinger server would still know what is being requested. =C2=A0I think th=
e only

case of concern is when non-TLS connections are used.




That's not=
 necessarily true. Some subcomponent of the server would have access to the=
 data, yes, but that doesn't mean every subcomponent on that server sho=
uld be allowed to have access to that information. Further, it does not nec=
essarily follow that the server is required to know exactly whose data it i=
s serving up.. just that there is some blob of data about someone or someth=
ing being requested. URLs and query string parameters tend to wind up getti=
ng recorded in server logs that are completely unprotected by TLS. Hashing =
the identities makes it significantly more difficult to mine those for usef=
ul information (obviously not impossible, but the idea is to make it more d=
ifficult, not impossible).=C2=A0




Note also, there are organizations with existing polici=
es in place forbidding the use of email identifiers within URI parameters. =
This is the precise reason why lotus connections, for instance, provides an=
 option to use alternative identifiers within URIs. For such organizations,=
 use of WebFinger uri's is going to be quite problematic at best.




=C2=A0[snip]
We sho=
uld certainly cover any security and privacy concerns, but the fact of

the matter is that use of WebFinger, Google, or any other service where you=


search for information is going to reveal certain information about you.
Likewise, posting any information where the public can retrieve it has its<=
br>
risks, which is why servers should be controlled and access to web resource=
s

controlled.



If the security considerations section does not have the wording to address=


concerns, then please provide some words and I'd be happy to add them.<=
br>


This is not really a question about just coming up w=
ith additional language for the security concerns section, the ability to s=
upport hashed identifiers rather than email or acct: id's should be bui=
lt into the protocol. In fact, for a protocol such as this, privacy should =
be THE default option. Meaning, hashed identifiers should always be used, I=
MHO.




- James
=C2=A0

Paul






_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--90e6ba6e8aee4fa91004cd3ac5ff--

From jasnell@gmail.com  Mon Oct 29 16:38:49 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAD921F863F for ; Mon, 29 Oct 2012 16:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2mxTBal0VDR for ; Mon, 29 Oct 2012 16:38:48 -0700 (PDT)
Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB5621F8562 for ; Mon, 29 Oct 2012 16:38:48 -0700 (PDT)
Received: by mail-ia0-f172.google.com with SMTP id x24so2712327iak.31 for ; Mon, 29 Oct 2012 16:38:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gUF35D2TzQsH++VfE6ysuadN7rcV109Kcy4WjJwHPOk=; b=s5GkDo0PRNUvTJeYwKQ7HQcxoHwWlky+3CUdwbHvYrtjlOD/yXFu7xxMJD/KNSebbv idQqCwAwQys894M6AYH9VS9/JdVbSk6Gv7Foje+3iZwrH6CPrMUieFBYDfP0rxY9kyxX XDApRsJ6aaAY1zWLV+gF7M8ktDyPwyKu0EtAPdHsdyM8fyIFf0r7L4iObl889pbyOPh9 2yo8F4p9+uiZ4GbblecCKh8LH3sd5D44GjgY54QS+5Ieh6GXKYT11Smf9hKvW6rYREWt 0ZMLrxqxohYSLHwkZZdUGPCsjSRCCM5DGLXdsld6xh66VAV1z0sXTGZgbdreKTjG1PS/ oOcA==
Received: by 10.50.183.200 with SMTP id eo8mr11371784igc.54.1351553927492; Mon, 29 Oct 2012 16:38:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.46.225 with HTTP; Mon, 29 Oct 2012 16:38:27 -0700 (PDT)
In-Reply-To: 
References:     
From: James M Snell 
Date: Mon, 29 Oct 2012 16:38:27 -0700
Message-ID: 
To: Francis Galiegue 
Content-Type: multipart/alternative; boundary=14dae9340435be32c604cd3b2bc1
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] RFC 4627 and text vs values
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Oct 2012 23:38:49 -0000

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

FWIW, the ecmascript json support agrees with you... primitives can be
passed in with no problem. As for RFC4627 support for it, having a "JSON
document" that consists of a single primitive doesn't appear (to me) to be
overly useful.

- James

On Mon, Oct 29, 2012 at 1:20 PM, Francis Galiegue wrot=
e:

> On Wed, Oct 24, 2012 at 12:51 AM, Francis Galiegue 
> wrote:
> > On Thu, Sep 27, 2012 at 3:01 PM, Francis Galiegue 
> wrote:
> > [...]
> >>
> >> That kind of begs the question: why wouldn't it be legal to produce
> >> JSON values other than arrays/objects? "Primitve" JSON values are
> >> potentially useful as well, I don't see the point of forbidding their
> >> production. This looks like limiting the expressiveness of JSON to me.
> >>
> >
> > Ping on that one...
> >
>
> Ping again.
>
> The more I think about it, the less the definition of a "JSON text" makes
> sense.
>
> --
> 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)
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

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

FWIW, the ecmascript json support agre=
es with you... primitives can be passed in with no problem. As for RFC4627 =
support for it, having a "JSON document" that consists of a singl=
e primitive doesn't appear (to me) to be overly useful.



- James

On Mo=
n, Oct 29, 2012 at 1:20 PM, Francis Galiegue <fgaliegue@gmail.com&g=
t; wrote:



On Wed, Oct 24, 2012 at 12=
:51 AM, Francis Galiegue <fgalieg=
ue@gmail.com> wrote:



> On Thu, Sep 27, 2012 at 3:01 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:

> [...]

>>

>> That kind of begs the question: why wouldn't it be legal to pr=
oduce

>> JSON values other than arrays/objects? "Primitve" JSON v=
alues are

>> potentially useful as well, I don't see the point of forbiddin=
g their

>> production. This looks like limiting the expressiveness of JSON to=
 me.

>>

>

> Ping on that one...

>




Ping again.



The more I think about it, the less the definition of a "JSON text&quo=
t; makes sense.




--

Francis Galiegue, fgaliegue@gmail.co=
m

"It seems obvious [...] that at least some 'business intelligence&=
#39;

tools invest so much intelligence on the business side that they have

nothing left for generating SQL queries" (St=C3=A9phane Faroult, in &q=
uot;The

Art of SQL", ISBN 0-596-00894-5)

_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

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





--14dae9340435be32c604cd3b2bc1--

From paulej@packetizer.com  Mon Oct 29 17:37:33 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B062D21F84C4 for ; Mon, 29 Oct 2012 17:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.145
X-Spam-Level: 
X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.454,  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 vL-dkG1wh9Pr for ; Mon, 29 Oct 2012 17:37:28 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 79AAA21F86CE for ; Mon, 29 Oct 2012 17:37:28 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9U0bPxb022220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Oct 2012 20:37:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351557446; bh=tCHOB5mLAGcXSuq43aOQHDsgSluLYoEwLlGXzXGCYkk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=g4hgkhX6dv7t12c0hkuj7oSUi5/Cmaeyxk/ngNzCSjxbgsjbZmTFh4el4GKYY5ZHX OVrjp5ORd9BUWZ8Ggm6L8OA8yrAhVC3yQn2w+YdYXlBAuGDzW0x5oFJe6YSIcrnq3m Ce2Gcu28o8/KMRHRrN4McWgVRorA5dSIqQQTNgqU=
From: "Paul E. Jones" 
To: "'Stephen Farrell'" 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie>
In-Reply-To: <508F0870.9050402@cs.tcd.ie>
Date: Mon, 29 Oct 2012 20:37:31 -0400
Message-ID: <0b9901cdb636$bf951480$3ebf3d80$@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: AQFLsjjsRNcR0N0rPY8CMxV87xY2TQDs4XE+AookvBGYuUsdUA==
Content-Language: en-us
Cc: 'Apps Discuss' 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Oct 2012 00:37:33 -0000

Stephen,

There is so much information leaked around as one uses the Internet. The
mere fact that we exchanged email messages would tell BigCo that
packetizer.com had a dialog with cs.tld.ie.

If I didn't run my own mail server, the BigCo would have the complete
contents of my message to you, too -- even if I (as the user) thought it was
confidential.

Personally, I don't think we should be worrying too much about privacy
issues. Obviously, there are some things we can control (e.g., recommending
the use of TLS, so that all queries are hidden), but there are many things
outside our control (e.g., exactly what gets published, what gets queried,
and when that information gets queried).

The right approach, IMO, is what Google is going with Google+.  Ask users
what they want to make public or share with certain people.  In the case of
WebFinger, it's mostly a matter of "what's made public", but not always.  A
company, for example, can publish information about employees via WebFinger,
but they can have that server such that the information is accessible only
internally or only by authorized users.  They could elect to share some
information to the general public.

The example I gave where the client automatically looks up information is
just an example, but it is a valid example... to your point.  It is a good
example of the kinds of things people can do and, if WF is deployed widely,
probably will do.  Writing cautionary tales of any significant length in the
WF spec is not going to change anything, really. Many users like that
convenience.

So, somewhere we have to strike a balance between being overly concerned
with privacy and taking appropriate steps to ensure privacy.  People who are
insanely concerned about their privacy should first walk away from the
Internet.  People reasonably concerned should not publish anything via
WebFinger.  For most people, it is a matter of giving them the tools to
control what they publish for the world to see, WebFinger or otherwise.

If there were to be a treatise on social networking security, that might be
a good thing, but the WF document is not the right place to give it
appropriate treatment.

Paul

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Sent: Monday, October 29, 2012 6:51 PM
> To: Paul E. Jones
> Cc: 'Apps Discuss'
> Subject: Re: [apps-discuss] webfinger privacy question/suggestion
> 
> 
> Hiya,
> 
> On 10/29/2012 09:30 PM, Paul E. Jones wrote:
> > Stephen,
> >
> >> The draft says:
> >>
> >> "  Let's assume your email client discovers that blog automatically
> for
> >>    you.  After receiving the message from Bob (bob@example.com), your
> >>    email client performs the following steps behind the scenes."
> >>
> >> ...then describes how I send out a request containing the string
> >> bob@example.com.
> >>
> >> The net result of that appears to be that I'll be sending out details
> >> about who I'm contacting (or want to contact) to a server with which
> >> I've no existing relationship, and that is probably going to turn out
> >> to be operated by one of the few very large providers.
> >>
> >> That seems to me to have potentially serious privacy issues. (As with
> >> all privacy issues, you never know when they're more than potential
> >> until its too late;-)
> >>
> >> Is that accurate?
> >
> > Yes, though be mindful that this just an non-normative example.
> 
> Sure. But one that does nicely expose the privacy concern.
> 
> >> I wondered why the wg didn't consider (even as an option) allowing
> >> the client to send a hash of Bob's URI? That way, if the request goes
> >> to the wrong place, things are a bit more privacy friendly.
> >> (I think an earlier draft from James Snell suggested this, but don't
> >> recall subsequent discussion about that.)
> >
> > The request should not go to the wrong place, though a request could
> > get intercepted on the wire.  It is for these reasons that we strongly
> > recommend use of TLS.
> 
> Use of TLS is great (though some of the text about that might need
> tweaking). But the wrong place problem needs more work I suspect. In
> particular the (as you say non-normative) example quoted says that this
> is all happening in the background, and you don't normatively say how a
> client figures out the host to query. Now maybe you can't in general,
> but if not, then I think that causes the problem and TLS is no help in
> that.
> 
> One danger here would be that my mail client might by default tell BigCo
> about the sender header field of all the mail I receive and when I got
> it and might not give me any control over that, all to try find a
> sender's blog 1 RTT quicker.
> That'd be a bad thing to do by accident, right?
> 
> Another might be contexts where the derivation of the host to use is
> less clear. In the case of mail, should I use the sender or From domain
> for example if those differ? What about mailing lists? Are there similar
> ambiguities in XMPP or other protocols? I'd love to have a warm feeling
> that that's all been considered - and maybe it has, but I don't get that
> warm feeling as of now from the draft and my recollection of the list
> traffic on this.
> 
> >> One argument for doing something privacy friendly here is that it
> >> would make sense to follow the approach of the safe web browsing
> >> mechanisms here - if its considered sensitive to tell a large
> >> provider about the URLs I'm visiting, then why is it ok to tell such
> >> a provider the names of the people I want to finger?
> >> (Having said that, yes, other mechanisms, such as URL completion take
> >> the opposite approach.)
> >
> > Whether we hash the information or not, a request received at the
> > legitimate WebFinger server would still know what is being requested.
> > I think the only case of concern is when non-TLS connections are used.
> 
> Right, non-TLS to the wrong place is the main concern. It could be that
> some re-direction cases might also be an issue but not sure.
> 
> >> More generally, it'd be good if webfinger privacy were discussed more
> >> on the list since maybe there are other privacy issues or mitigations
> >> that'd be better or easier.
> >
> > We've had only a little discussion on privacy and I've tried to insert
> > text to address the concerns that have been raised in Section 11
> > (security considerations), though I would be happy to insert a whole
> > section on privacy considerations if given some text.
> 
> I hope that discussion happens on the list.
> 
> >> (Note: I would raise a DISCUSS during IESG eval for this, but since
> >> it could lead to a change in the protocol, I'm raising it now in the
> >> hope that's more likely to be doable if it needs to be done.)
> >
> > We should certainly cover any security and privacy concerns, but the
> > fact of the matter is that use of WebFinger, Google, or any other
> > service where you search for information is going to reveal certain
> information about you.
> 
> Personally, I think the key thing is to try make sure that the very very
> few folks who care are given some way to mitigate their concerns, or if
> that's not possible say then that its not possible after the list has
> had the discussion that reached that conclusion.
> 
> > Likewise, posting any information where the public can retrieve it has
> > its risks, which is why servers should be controlled and access to web
> > resources controlled.
> 
> Yes, you cover that already at least to some extent and there was some
> discussion on the list about it. I'm not clear if that's considered
> "done" or not though (can't recall). I guess the issue is whether there
> are any knobs the user could twist or not, and at present, it's "not"
> so webfinger is something that, if you use it, all the stuff you put at
> one host is available to anyone who can access that host. (Is that
> right?)
> 
> I think that that's mostly ok, perhaps with some added advice about
> publishing stuff aimed at coders, e.g. to say "don't automatically
> publish users' information since that'd be a crappy way to deal with
> folks who care about privacy" or similar.
> 
> > If the security considerations section does not have the wording to
> > address concerns, then please provide some words and I'd be happy to
> add them.
> 
> I'd hope those emerge from list discussion - just because I'd DISCUSS
> the current text doesn't make me the right person to suggest new text.
> 
> Cheers,
> S.
> 
> 
> >
> > Paul
> >
> >
> >
> >


From paulej@packetizer.com  Mon Oct 29 17:46:18 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A17A21F8661 for ; Mon, 29 Oct 2012 17:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.173
X-Spam-Level: 
X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.425,  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 6xQxrcOnBGXV for ; Mon, 29 Oct 2012 17:46:17 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0077221F85C5 for ; Mon, 29 Oct 2012 17:46:16 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9U0kBtF022598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Oct 2012 20:46:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351557973; bh=F7jRCGVqFb7qU6Zd3yahsC9Sl/06VMKUlzaea+BkCr0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=j84xdCtqEJNCyutYdKxUOelHoVIVyYVR7cGJCH+A/z0CY0Cpu/OQm2Q1ngyTWYW9i KHEuOIN9BN6AYAIKE8YGOZSwlaJ1OG344HhYu9U218zRAMeyr/Hr/kUHxktFhcpexB fgsiKtObONurFgCYoFh+gjAIoqj/QlQwvJDF5etk=
From: "Paul E. Jones" 
To: "'James M Snell'" 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> 
In-Reply-To: 
Date: Mon, 29 Oct 2012 20:46:17 -0400
Message-ID: <0b9b01cdb637$f9e14900$eda3db00$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B9C_01CDB616.72D0BA70"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFLsjjsRNcR0N0rPY8CMxV87xY2TQDs4XE+AoNv0LiYuYfDcA==
Content-Language: en-us
Cc: 'Apps Discuss' 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Oct 2012 00:46:18 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0B9C_01CDB616.72D0BA70
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

James,

=20

I don=E2=80=99t think a hash buys us a whole lot.  It obfuscates things, =
but it does not hide things.  So, I don=E2=80=99t know who users =
=E2=80=9C53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255=
=E2=80=9D is, but I can see you queried for them.  I could query for =
them and probably get their vcard and find out their name.  I can look =
for something.  I can also perhaps monitor your unencrypted email =
traffic or just get a hold of your address book and then easily map the =
hashes to real identifiers.

=20

What=E2=80=99s the expression=E2=80=A6 =E2=80=9Csecurity through =
obfuscation isn=E2=80=99t security=E2=80=9D, or some such.  It only =
serves to delay discovery, really.  To truly conceal .. at least the =
domain level .. one needs to use TLS.  Even then, a BigCo can see the =
unencrypted DNS requests and see that you might be talking to somebody =
at packetizer.com about something.  A search via Google would reveal the =
identity in a hurry. :-)

=20

Paul

=20

From: James M Snell [mailto:jasnell@gmail.com]=20
Sent: Monday, October 29, 2012 7:10 PM
To: Paul E. Jones
Cc: Stephen Farrell; Apps Discuss
Subject: Re: [apps-discuss] webfinger privacy question/suggestion

=20

=20

On Mon, Oct 29, 2012 at 2:30 PM, Paul E. Jones  =
wrote:

[snip]
>
> That seems to me to have potentially serious privacy issues. (As with
> all privacy issues, you never know when they're more than potential
> until its too late;-)
>
> Is that accurate?

Yes, though be mindful that this just an non-normative example.

=20

=20

Even so, it's an example that you explicitly call out in your spec that =
very clearly highlights a privacy concern. If you're going to raise such =
an example and not deal with the privacy implications beyond "use TLS", =
then there is a problem. See below...

=20

=20

> One argument for doing something privacy friendly here is that it =
would
> make sense to follow the approach of the safe web browsing mechanisms
> here - if its considered sensitive to tell a large provider about the
> URLs I'm visiting, then why is it ok to tell such a provider the names
> of the people I want to finger?
> (Having said that, yes, other mechanisms, such as URL completion take
> the opposite approach.)

Whether we hash the information or not, a request received at the =
legitimate
WebFinger server would still know what is being requested.  I think the =
only
case of concern is when non-TLS connections are used.

=20

=20

That's not necessarily true. Some subcomponent of the server would have =
access to the data, yes, but that doesn't mean every subcomponent on =
that server should be allowed to have access to that information. =
Further, it does not necessarily follow that the server is required to =
know exactly whose data it is serving up.. just that there is some blob =
of data about someone or something being requested. URLs and query =
string parameters tend to wind up getting recorded in server logs that =
are completely unprotected by TLS. Hashing the identities makes it =
significantly more difficult to mine those for useful information =
(obviously not impossible, but the idea is to make it more difficult, =
not impossible).=20

=20

Note also, there are organizations with existing policies in place =
forbidding the use of email identifiers within URI parameters. This is =
the precise reason why lotus connections, for instance, provides an =
option to use alternative identifiers within URIs. For such =
organizations, use of WebFinger uri's is going to be quite problematic =
at best.

=20

 [snip]

We should certainly cover any security and privacy concerns, but the =
fact of
the matter is that use of WebFinger, Google, or any other service where =
you
search for information is going to reveal certain information about you.
Likewise, posting any information where the public can retrieve it has =
its
risks, which is why servers should be controlled and access to web =
resources
controlled.

If the security considerations section does not have the wording to =
address
concerns, then please provide some words and I'd be happy to add them.

=20

This is not really a question about just coming up with additional =
language for the security concerns section, the ability to support =
hashed identifiers rather than email or acct: id's should be built into =
the protocol. In fact, for a protocol such as this, privacy should be =
THE default option. Meaning, hashed identifiers should always be used, =
IMHO.

=20

- James

=20

Paul



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

=20


------=_NextPart_000_0B9C_01CDB616.72D0BA70
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


James,
 
I don=E2=80=99t think a hash buys us a whole lot.=C2=A0 It obfuscates =
things, but it does not hide things.=C2=A0 So, I don=E2=80=99t know who =
users =
=E2=80=9C53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255=
=E2=80=9D is, but I can see you queried for them. =C2=A0I could query =
for them and probably get their vcard and find out their name.=C2=A0 I =
can look for something.=C2=A0 I can also perhaps monitor your =
unencrypted email traffic or just get a hold of your address book and =
then easily map the hashes to real identifiers.
 
What=E2=80=99s the expression=E2=80=A6 =E2=80=9Csecurity through =
obfuscation isn=E2=80=99t security=E2=80=9D, or some such.=C2=A0 It only =
serves to delay discovery, really.=C2=A0 To truly conceal .. at least =
the domain level .. one needs to use TLS.=C2=A0 Even then, a BigCo can =
see the unencrypted DNS requests and see that you might be talking to =
somebody at packetizer.com about something.=C2=A0 A search via Google =
would reveal the identity in a hurry. :-)
 
Paul
 
From:=
 =
James M Snell [mailto:jasnell@gmail.com] 
Sent: Monday, =
October 29, 2012 7:10 PM
To: Paul E. Jones
Cc: =
Stephen Farrell; Apps Discuss
Subject: Re: [apps-discuss] =
webfinger privacy =
question/suggestion
 
 
On Mon, Oct 29, 2012 at 2:30 PM, Paul E. Jones <paulej@packetizer.com> =
wrote:
[snip]
>
> That seems to me =
to have potentially serious privacy issues. (As with
> all privacy =
issues, you never know when they're more than potential
> until =
its too late;-)
>
> Is that accurate?
Yes, though be mindful that this just an non-normative =
example.
 
 
Even so, it's an example that you explicitly call out =
in your spec that very clearly highlights a privacy concern. If you're =
going to raise such an example and not deal with the privacy =
implications beyond "use TLS", then there is a problem. See =
below...
 
 
> One argument for doing something =
privacy friendly here is that it would
> make sense to follow the =
approach of the safe web browsing mechanisms
> here - if its =
considered sensitive to tell a large provider about the
> URLs I'm =
visiting, then why is it ok to tell such a provider the names
> of =
the people I want to finger?
> (Having said that, yes, other =
mechanisms, such as URL completion take
> the opposite =
approach.)
Whether we hash the =
information or not, a request received at the legitimate
WebFinger =
server would still know what is being requested.  I think the =
only
case of concern is when non-TLS connections are =
used.
 
 
That's not necessarily true. Some subcomponent of the =
server would have access to the data, yes, but that doesn't mean every =
subcomponent on that server should be allowed to have access to that =
information. Further, it does not necessarily follow that the server is =
required to know exactly whose data it is serving up.. just that there =
is some blob of data about someone or something being requested. URLs =
and query string parameters tend to wind up getting recorded in server =
logs that are completely unprotected by TLS. Hashing the identities =
makes it significantly more difficult to mine those for useful =
information (obviously not impossible, but the idea is to make it more =
difficult, not impossible). 
 
Note also, there are organizations with existing =
policies in place forbidding the use of email identifiers within URI =
parameters. This is the precise reason why lotus connections, for =
instance, provides an option to use alternative identifiers within URIs. =
For such organizations, use of WebFinger uri's is going to be quite =
problematic at best.
 
 [snip]
We should certainly cover any security =
and privacy concerns, but the fact of
the matter is that use of =
WebFinger, Google, or any other service where you
search for =
information is going to reveal certain information about =
you.
Likewise, posting any information where the public can retrieve =
it has its
risks, which is why servers should be controlled and =
access to web resources
controlled.

If the security =
considerations section does not have the wording to address
concerns, =
then please provide some words and I'd be happy to add =
them.
 
This is not really a question about just coming up =
with additional language for the security concerns section, the ability =
to support hashed identifiers rather than email or acct: id's should be =
built into the protocol. In fact, for a protocol such as this, privacy =
should be THE default option. Meaning, hashed identifiers should always =
be used, IMHO.
 
- =
James
 
Paul


_______________________________________________=

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

------=_NextPart_000_0B9C_01CDB616.72D0BA70--


From stephen.farrell@cs.tcd.ie  Mon Oct 29 18:21:26 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD1521F870A for ; Mon, 29 Oct 2012 18:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.506
X-Spam-Level: 
X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 mmwnUqcT0YXF for ; Mon, 29 Oct 2012 18:21:25 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5128C21F8708 for ; Mon, 29 Oct 2012 18:21:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D9D1BC786; Tue, 30 Oct 2012 01:20:57 +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 SlsT73vPeDZr; Tue, 30 Oct 2012 01:20:56 +0000 (GMT)
Received: from [10.87.48.4] (unknown [86.42.183.189]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4ECB6C3B1; Tue, 30 Oct 2012 01:20:56 +0000 (GMT)
Message-ID: <508F2B78.2000006@cs.tcd.ie>
Date: Tue, 30 Oct 2012 01:20:56 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1
MIME-Version: 1.0
To: "Paul E. Jones" 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com>
In-Reply-To: <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: 'Apps Discuss' 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Oct 2012 01:21:27 -0000

Hi,

On 10/30/2012 12:37 AM, Paul E. Jones wrote:
> Stephen,
> 
> There is so much information leaked around as one uses the Internet. The
> mere fact that we exchanged email messages would tell BigCo that
> packetizer.com had a dialog with cs.tld.ie.

Nice typo. cs.tcd.ie do have sysadmins who'd like to take
over the universe if it wasn't for those pesky tcd.ie folks.
But maybe that is actually a good lesson in mis-targetting?

> If I didn't run my own mail server, the BigCo would have the complete
> contents of my message to you, too -- even if I (as the user) thought it was
> confidential.

There is a real issue here, and a hard one: IMO, that is: privacy
is already so compromised that its not at all clear its worthwhile
bothering to make it less worse.

However, my take is that yes, incremental improvement is still a
good thing.

> Personally, I don't think we should be worrying too much about privacy
> issues. 

Hmmm. I disagree.

> Obviously, there are some things we can control (e.g., recommending
> the use of TLS, so that all queries are hidden), 

TLS has very little to do with privacy. That much ought be clear
to this list, but in case not, confidentiality != privacy ought
be a sufficient reminder.

> but there are many things
> outside our control (e.g., exactly what gets published, what gets queried,
> and when that information gets queried).

"When things get queried" ought presumably be entirely reasonable to
discuss when defining the protocol with which they are queried.

> The right approach, IMO, is what Google is going with Google+.  

I've no idea what that is. Where's it written down?

> Ask users
> what they want to make public or share with certain people.  

Isn't that only considering the publisher-user issues? And
that's (I hope clearly) not the main topic of my concern.

> In the case of
> WebFinger, it's mostly a matter of "what's made public", but not always.  A
> company, for example, can publish information about employees via WebFinger,
> but they can have that server such that the information is accessible only
> internally or only by authorized users.  They could elect to share some
> information to the general public.

Only relevant for the publisher, not the one sending the query.

And what'd be wrong with providing tools that allow a publisher
to reflect subtlety? Why is that harder or worse and for whom?

> The example I gave where the client automatically looks up information is
> just an example, but it is a valid example... to your point.  It is a good
> example of the kinds of things people can do and, if WF is deployed widely,
> probably will do.  Writing cautionary tales of any significant length in the
> WF spec is not going to change anything, really. Many users like that
> convenience.

The above paragraph is filler, right? If not, I don't get the argument.

> So, somewhere we have to strike a balance between being overly concerned
> with privacy and taking appropriate steps to ensure privacy. 

In the above, you begin to be be pejorative.

> People who are
> insanely concerned about their privacy should first walk away from the
> Internet.  

And now you perhaps perfect pejorative posing!

"balance" "overly" "appropriate" and "insanely" are all bad
fillers that really indicate a need for something to be fixed.

I do hope you recognise that the last few sentences would be
better not having been stated.

> People reasonably concerned should not publish anything via
> WebFinger.  For most people, it is a matter of giving them the tools to
> control what they publish for the world to see, WebFinger or otherwise.

Perhaps. But my question was about privacy for those whose
user agents might automatically issue queries. Ignoring the
question is not a way to answer the question.

> If there were to be a treatise on social networking security, that might be
> a good thing, but the WF document is not the right place to give it
> appropriate treatment.

I agree. This I-D ought not include a treatise. Neither
should discussion of this I-D base conclusions on bad
argument, such as that you've offered above.

S.


> 
> Paul
> 
>> -----Original Message-----
>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
>> Sent: Monday, October 29, 2012 6:51 PM
>> To: Paul E. Jones
>> Cc: 'Apps Discuss'
>> Subject: Re: [apps-discuss] webfinger privacy question/suggestion
>>
>>
>> Hiya,
>>
>> On 10/29/2012 09:30 PM, Paul E. Jones wrote:
>>> Stephen,
>>>
>>>> The draft says:
>>>>
>>>> "  Let's assume your email client discovers that blog automatically
>> for
>>>>    you.  After receiving the message from Bob (bob@example.com), your
>>>>    email client performs the following steps behind the scenes."
>>>>
>>>> ...then describes how I send out a request containing the string
>>>> bob@example.com.
>>>>
>>>> The net result of that appears to be that I'll be sending out details
>>>> about who I'm contacting (or want to contact) to a server with which
>>>> I've no existing relationship, and that is probably going to turn out
>>>> to be operated by one of the few very large providers.
>>>>
>>>> That seems to me to have potentially serious privacy issues. (As with
>>>> all privacy issues, you never know when they're more than potential
>>>> until its too late;-)
>>>>
>>>> Is that accurate?
>>>
>>> Yes, though be mindful that this just an non-normative example.
>>
>> Sure. But one that does nicely expose the privacy concern.
>>
>>>> I wondered why the wg didn't consider (even as an option) allowing
>>>> the client to send a hash of Bob's URI? That way, if the request goes
>>>> to the wrong place, things are a bit more privacy friendly.
>>>> (I think an earlier draft from James Snell suggested this, but don't
>>>> recall subsequent discussion about that.)
>>>
>>> The request should not go to the wrong place, though a request could
>>> get intercepted on the wire.  It is for these reasons that we strongly
>>> recommend use of TLS.
>>
>> Use of TLS is great (though some of the text about that might need
>> tweaking). But the wrong place problem needs more work I suspect. In
>> particular the (as you say non-normative) example quoted says that this
>> is all happening in the background, and you don't normatively say how a
>> client figures out the host to query. Now maybe you can't in general,
>> but if not, then I think that causes the problem and TLS is no help in
>> that.
>>
>> One danger here would be that my mail client might by default tell BigCo
>> about the sender header field of all the mail I receive and when I got
>> it and might not give me any control over that, all to try find a
>> sender's blog 1 RTT quicker.
>> That'd be a bad thing to do by accident, right?
>>
>> Another might be contexts where the derivation of the host to use is
>> less clear. In the case of mail, should I use the sender or From domain
>> for example if those differ? What about mailing lists? Are there similar
>> ambiguities in XMPP or other protocols? I'd love to have a warm feeling
>> that that's all been considered - and maybe it has, but I don't get that
>> warm feeling as of now from the draft and my recollection of the list
>> traffic on this.
>>
>>>> One argument for doing something privacy friendly here is that it
>>>> would make sense to follow the approach of the safe web browsing
>>>> mechanisms here - if its considered sensitive to tell a large
>>>> provider about the URLs I'm visiting, then why is it ok to tell such
>>>> a provider the names of the people I want to finger?
>>>> (Having said that, yes, other mechanisms, such as URL completion take
>>>> the opposite approach.)
>>>
>>> Whether we hash the information or not, a request received at the
>>> legitimate WebFinger server would still know what is being requested.
>>> I think the only case of concern is when non-TLS connections are used.
>>
>> Right, non-TLS to the wrong place is the main concern. It could be that
>> some re-direction cases might also be an issue but not sure.
>>
>>>> More generally, it'd be good if webfinger privacy were discussed more
>>>> on the list since maybe there are other privacy issues or mitigations
>>>> that'd be better or easier.
>>>
>>> We've had only a little discussion on privacy and I've tried to insert
>>> text to address the concerns that have been raised in Section 11
>>> (security considerations), though I would be happy to insert a whole
>>> section on privacy considerations if given some text.
>>
>> I hope that discussion happens on the list.
>>
>>>> (Note: I would raise a DISCUSS during IESG eval for this, but since
>>>> it could lead to a change in the protocol, I'm raising it now in the
>>>> hope that's more likely to be doable if it needs to be done.)
>>>
>>> We should certainly cover any security and privacy concerns, but the
>>> fact of the matter is that use of WebFinger, Google, or any other
>>> service where you search for information is going to reveal certain
>> information about you.
>>
>> Personally, I think the key thing is to try make sure that the very very
>> few folks who care are given some way to mitigate their concerns, or if
>> that's not possible say then that its not possible after the list has
>> had the discussion that reached that conclusion.
>>
>>> Likewise, posting any information where the public can retrieve it has
>>> its risks, which is why servers should be controlled and access to web
>>> resources controlled.
>>
>> Yes, you cover that already at least to some extent and there was some
>> discussion on the list about it. I'm not clear if that's considered
>> "done" or not though (can't recall). I guess the issue is whether there
>> are any knobs the user could twist or not, and at present, it's "not"
>> so webfinger is something that, if you use it, all the stuff you put at
>> one host is available to anyone who can access that host. (Is that
>> right?)
>>
>> I think that that's mostly ok, perhaps with some added advice about
>> publishing stuff aimed at coders, e.g. to say "don't automatically
>> publish users' information since that'd be a crappy way to deal with
>> folks who care about privacy" or similar.
>>
>>> If the security considerations section does not have the wording to
>>> address concerns, then please provide some words and I'd be happy to
>> add them.
>>
>> I'd hope those emerge from list discussion - just because I'd DISCUSS
>> the current text doesn't make me the right person to suggest new text.
>>
>> Cheers,
>> S.
>>
>>
>>>
>>> Paul
>>>
>>>
>>>
>>>
> 

From romeda@gmail.com  Mon Oct 29 18:30:16 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A75121F8566 for ; Mon, 29 Oct 2012 18:30:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRPHWjj5Oy3X for ; Mon, 29 Oct 2012 18:30:15 -0700 (PDT)
Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 09C9B21F84FF for ; Mon, 29 Oct 2012 18:30:15 -0700 (PDT)
Received: by mail-da0-f44.google.com with SMTP id h15so2617475dan.31 for ; Mon, 29 Oct 2012 18:30:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=HO3xOuPCHdqqi8V0/28q0rtXImKyDDUWK+3/MJfaskE=; b=XVpoowvVLLDz4wjaVQnA2ngIfBPLrBdHuOSXIKiKT4YJkh0zPFeMb0+mF9eTxN+j6y otpYNa46P7bs95A7saxudEr1vf9/G4mBRDlRcMA22vN+rkTK0UrONXAPCCPuzwFY2wnl l6N23bJvm5ta4Nk/quuiMS56UjUqQgvplcI9ROoO6mRAfycSdZO0pu5J4e7XETKheVvl Znt7pv88Eglqi2SZp5m3LPB5CUNQ/qjYyfOw3FMu0DwNgv6JjsS8zk6XFkrLSru7U0Tv kbt4z+o08dROpE8ROeg18CqsUsdhlyBCEystbMLlOl70+m0h/jn3bLDIpM+YKHeCRntu YZZQ==
Received: by 10.68.235.106 with SMTP id ul10mr98926056pbc.83.1351560614685; Mon, 29 Oct 2012 18:30:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.67.2.101 with HTTP; Mon, 29 Oct 2012 18:29:54 -0700 (PDT)
In-Reply-To: <029901cdb081$a253e7d0$e6fbb770$@packetizer.com>
References: <025b01cdae61$591e9690$0b5bc3b0$@packetizer.com> <5082C526.3050100@status.net> <00c501cdaf13$13ef6d30$3bce4790$@packetizer.com> <20121021093728.590d2898@bogo>   <029901cdb081$a253e7d0$e6fbb770$@packetizer.com>
From: Blaine Cook 
Date: Mon, 29 Oct 2012 18:29:54 -0700
Message-ID: 
To: "Paul E. Jones" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: webfinger@googlegroups.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-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: Tue, 30 Oct 2012 01:30:16 -0000

Hi Paul,

Sorry for the delay, the past week has been extraordinarily busy for
me. I want to separate my concerns about the draft, and my value of
your work on the draft =E2=80=93 I've really appreciated that you and other=
s
have kept working on it, and kept the work alive. Thank you. I don't
mean to rain on the parade, but I do want to make sure that webfinger
ends up being the best it can be.

On 22 October 2012 11:18, Paul E. Jones  wrote:
> Blaine,
>
> How can you say that when the current WebFinger draft actually makes RFC =
6415 even simpler than it was before.  Now, JSON is the only MTI format and=
 a client can get everything it's looking for with a simple query like
>
>  GET /.well-known/host-meta.json?resource=3Dacct%3Abob%40example.com HTTP=
/1.1
>
> That returns the complete resource descriptor.  The server-side code is a=
lso simple.  My code just outputs data from a database that matches the URI=
 "acct:bob@example.com".
>
> It seems pretty light-weight to me, yet flexible enough to allow one to c=
onvey a list of link relations.

I have reiterated my vehement opposition to the parameterised approach
both in person and on the list enough times that I won't again here. I
strongly believe that all the arguments that have been raised for the
parameter-based approach are specious, and do not reflect the needs of
genuine implementors.

The incorporation of *both* the template URIs and the parameter-based
approaches to dereferencing is deeply problematic for the developer
experience when implementing webfinger. I think the spec should be
simplified and include only one.

I was never happy about the XRD format, but went along with it because
I didn't think it was a *huge* issue. The JSON approach is better, but
honestly, it should just neatly break compatibility with previous
specs (everything else is, after all...)

> WebFinger is structured the way it was described in Eran's posts, the Web=
Finger list, and RFC 6415.  I don't recall exactly what your proposal was n=
ow, but there were proposals to use DNS records like "URI" type records.  I=
 like that idea, but it's a chicken and egg problem.  Many solutions requir=
e more complexity on the client, and we tried to make the client simpler.

Since this appears to be a question, by a "DNS-like approach" I simply
mean that the server that hosts webfinger requests is found by looking
up the lrdd link in the host-meta document (the equivalent of an "NS"
record), and then the URI ("name server") reflected there provides
results ("A", "MX", etc; on webfinger, these would be "photo-feed",
"likes", "links", or whatever -- the rel-values of the links).

> That comes from RFC 6415 and a server would likely expose at least one li=
nk of type "template" if the client queries the host-meta resource without =
using the "resource" parameter.  Name, it would likely send the "lrdd" temp=
late type.  However, a client will NEVER see the templates if it uses the "=
resource" parameter.  I think that is important, because that makes the cli=
ent code simpler.

It complicates generic implementations, and makes a casual read of the
documentation much more complicated. If the resource parameter is
required, then the template lookup is totally redundant.

> Can you clarify the point of concern?  The only redirection mechanism pro=
posed in the spec is 3xx.  What text is troubling you?

I think I'd misread the spec / intent around on of the sections. Retracted.

>> =E2=80=93 The redirect code MUST NOT be 301. This would make it impossib=
le under
>> some circumstances for the host to regain control over lookups, and is
>> *never* the correct behaviour from a normative standpoint (where the
>> behaviour being enabled is like DNS =E2=80=93 you can *never* permanentl=
y
>> redirect a DNS lookup).
>
> I would argue that this should be a deployment matter. The only thing we =
say in the spec is that clients need to follow redirection on 301, 302, or =
307.  (That's what RFC 6415 says, and it's reasonable.  Browsers do that.)
>
>> =E2=80=93 Clients MUST treat 301 response codes as 307.
>
> We cannot require this.  Browsers, for example, are in control of that be=
havior, not the WF client running in the browser.  Also, 301 and 307 have d=
ifferent semantics.
>
>> =E2=80=93 The redirect code SHOULD be 307, and the server SHOULD use app=
ropriate
>> HTTP caching semantics.
>
> While using 307 might be the right way to deploy, that is (again) a deplo=
yment matter.  I'll note that many web sites still use 302, not 307.  WF cl=
ients should accept any of the listed 3xx codes.

301 is not a deployment matter.

It's the equivalent of having a non-expiring, infinitely cached DNS
record. Deploying a wefinger server that returned 301 response codes
would be broken since those webfinger lookups would never be
changeable.

If we're going to force sites to host /.well-known/host-meta serve
dynamic responses, or responses with custom HTTP headers (which,
frankly is probably a pain for people hosting on Dreamhost or other
restricted systems, but whatever, I've given up on that since no-one
else here seems to care), then using the "correct" HTTP code seems
prudent, at least in the spec.

> For those hosting their own WebFinger server (and it really is trivial co=
de), performance is not an issue.  There would be a single request/response=
.
>
> Large companies will likely run their own servers and could respond direc=
tly to requests.  For large companies that want to redirect queries away fr=
om example.com/.well-known/host-meta.json to webfinger.example.com/wherever=
/ (for example) could (and probably should) use 301 replies to encourage cl=
ients to redirect more optimally.  This would be a deployment option we sho=
uld allow.

They *MUST NOT* use 301 responses, or else properly written clients
will NEVER respect changes to the webfinger server.

Small hosts are going to have to send a full response header and serve
a request for ever user lookup at /.well-known/host-meat. For an
organisation with 1000 users, this could be man requests per second.

For large hosts, they'll need to do the same. It won't be possible to
offload the full brunt of the traffic to a secondary host without
implementing relatively complex proxy rules.

I agree it's not a huge difference these days, but it is a difference
that should be acknowledged.

> Where a domain owner has requests coming in from many distinct clients an=
d they use 3xx to redirect to a WebFinger provider, we end up with two requ=
est/response exchanges: one for the original request and one to the new loc=
ation.  But, this would only be necessary if the domain owner does not want=
 to point the A record for their domain to the WebFinger provider.  For tho=
se who more-or-less host the whole host (or domain) where the WF service ex=
ists, it's not an issue.  The extra exchange will come in only where only t=
he WF service is hosted elsewheer.

That's crazy =E2=80=93 *most* if not *all* servers WILL NOT want to point t=
he
A record for their domain at a webfinger server, and most servers
*will* want to host their webfinger server elsewhere.

Hands up, who hosts their email locally versus on GMail or another
pay-for-service SMTP host? What about global statistics for that? My
claim: *most* people *do not* run their own local inbound mail server.

> In any case, there are many possible deployment models, each with pros an=
d cons.

*nod*

> Are you referring to Section 9 or somewhere else?  I think there is value=
 in having Section 9 since it describes some hosting options.  It could per=
haps be made non-normative, but we do make the normative requirement for cl=
ients to handle 3xx responses.  RFC 6415 made that optional for clients.

Simplicity is achieved not when there's nothing left to add, but when
there's nothing left to take away. This is supposed to be a simple
protocol, and will be most successful if it's truly a simple protocol.

> Any input is helpful.  We need to get on the same page and agree on how t=
his should work.  The current draft is not a significant departure from wha=
t was defined already, and it wasn't intended to be.  I'd summarize it as R=
FC 6415 - XML + JRD + "resource" parameter.  I'm actually surprised you had=
 such a negative reaction to the text. :-)

My reaction is very much out of concern that the new draft encodes too
many possibilities =E2=80=93=C2=A0at its core, it is in fact very similar t=
o the
original conception and early drafts, but it just has so many options
for implementations (and openings to get things wrong).

b.

From romeda@gmail.com  Mon Oct 29 18:32:22 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3508721F85D4 for ; Mon, 29 Oct 2012 18:32:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVTh8T5JdN10 for ; Mon, 29 Oct 2012 18:32:20 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 635D121F8566 for ; Mon, 29 Oct 2012 18:32:20 -0700 (PDT)
Received: by mail-pb0-f44.google.com with SMTP id ro8so4564372pbb.31 for ; Mon, 29 Oct 2012 18:32:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/WxOW9HIhARPRkFn/rJxFdR2P7PA5eVWC1mSIsAkWpU=; b=Q0TFXVnvI5yf+ENsRM8lo1VgTw1eZfCkjPfH1fQMJCS/W3pvnOZmSt4D/TwtSO9zYK BJ5ANEmNJvNIYEq6XTssM8z0OyK/FlQtHaApKzfBXKSawhE2ToN3TNIkiVafFU8Rwif6 hwKS7kcPUJPuMHm6H8umRdghHw/63MxOEWVFvQraIJLXrH9kIcmI69cMn3xe3fpFUFjO plGHiXvGHyshCaoSt8cSRurqhiHLJnAzWjAkWKsrAQ+jKynYnmEHxWBarEvu1oM0EQTq /xlh5C2SlTvhwBKSuWVSdXWXmArQ8Gsf2uU3TDn3O52GY+BUoKFG9UhfijHj35mK2km2 hGSw==
Received: by 10.68.224.69 with SMTP id ra5mr97586461pbc.114.1351560740201; Mon, 29 Oct 2012 18:32:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.67.2.101 with HTTP; Mon, 29 Oct 2012 18:32:00 -0700 (PDT)
In-Reply-To: <508F2B78.2000006@cs.tcd.ie>
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie>
From: Blaine Cook 
Date: Mon, 29 Oct 2012 18:32:00 -0700
Message-ID: 
To: Stephen Farrell 
Content-Type: text/plain; charset=UTF-8
Cc: Apps Discuss 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Oct 2012 01:32:22 -0000

A counter-argument to hashing identifiers:

one could increase privacy of casual HTTP-based browsing sessions by
hashing the URLs (host names and paths separately, for example). But
we don't, and it's fine.

b.

On 29 October 2012 18:20, Stephen Farrell  wrote:
>
> Hi,
>
> On 10/30/2012 12:37 AM, Paul E. Jones wrote:
>> Stephen,
>>
>> There is so much information leaked around as one uses the Internet. The
>> mere fact that we exchanged email messages would tell BigCo that
>> packetizer.com had a dialog with cs.tld.ie.
>
> Nice typo. cs.tcd.ie do have sysadmins who'd like to take
> over the universe if it wasn't for those pesky tcd.ie folks.
> But maybe that is actually a good lesson in mis-targetting?
>
>> If I didn't run my own mail server, the BigCo would have the complete
>> contents of my message to you, too -- even if I (as the user) thought it was
>> confidential.
>
> There is a real issue here, and a hard one: IMO, that is: privacy
> is already so compromised that its not at all clear its worthwhile
> bothering to make it less worse.
>
> However, my take is that yes, incremental improvement is still a
> good thing.
>
>> Personally, I don't think we should be worrying too much about privacy
>> issues.
>
> Hmmm. I disagree.
>
>> Obviously, there are some things we can control (e.g., recommending
>> the use of TLS, so that all queries are hidden),
>
> TLS has very little to do with privacy. That much ought be clear
> to this list, but in case not, confidentiality != privacy ought
> be a sufficient reminder.
>
>> but there are many things
>> outside our control (e.g., exactly what gets published, what gets queried,
>> and when that information gets queried).
>
> "When things get queried" ought presumably be entirely reasonable to
> discuss when defining the protocol with which they are queried.
>
>> The right approach, IMO, is what Google is going with Google+.
>
> I've no idea what that is. Where's it written down?
>
>> Ask users
>> what they want to make public or share with certain people.
>
> Isn't that only considering the publisher-user issues? And
> that's (I hope clearly) not the main topic of my concern.
>
>> In the case of
>> WebFinger, it's mostly a matter of "what's made public", but not always.  A
>> company, for example, can publish information about employees via WebFinger,
>> but they can have that server such that the information is accessible only
>> internally or only by authorized users.  They could elect to share some
>> information to the general public.
>
> Only relevant for the publisher, not the one sending the query.
>
> And what'd be wrong with providing tools that allow a publisher
> to reflect subtlety? Why is that harder or worse and for whom?
>
>> The example I gave where the client automatically looks up information is
>> just an example, but it is a valid example... to your point.  It is a good
>> example of the kinds of things people can do and, if WF is deployed widely,
>> probably will do.  Writing cautionary tales of any significant length in the
>> WF spec is not going to change anything, really. Many users like that
>> convenience.
>
> The above paragraph is filler, right? If not, I don't get the argument.
>
>> So, somewhere we have to strike a balance between being overly concerned
>> with privacy and taking appropriate steps to ensure privacy.
>
> In the above, you begin to be be pejorative.
>
>> People who are
>> insanely concerned about their privacy should first walk away from the
>> Internet.
>
> And now you perhaps perfect pejorative posing!
>
> "balance" "overly" "appropriate" and "insanely" are all bad
> fillers that really indicate a need for something to be fixed.
>
> I do hope you recognise that the last few sentences would be
> better not having been stated.
>
>> People reasonably concerned should not publish anything via
>> WebFinger.  For most people, it is a matter of giving them the tools to
>> control what they publish for the world to see, WebFinger or otherwise.
>
> Perhaps. But my question was about privacy for those whose
> user agents might automatically issue queries. Ignoring the
> question is not a way to answer the question.
>
>> If there were to be a treatise on social networking security, that might be
>> a good thing, but the WF document is not the right place to give it
>> appropriate treatment.
>
> I agree. This I-D ought not include a treatise. Neither
> should discussion of this I-D base conclusions on bad
> argument, such as that you've offered above.
>
> S.
>
>
>>
>> Paul
>>
>>> -----Original Message-----
>>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
>>> Sent: Monday, October 29, 2012 6:51 PM
>>> To: Paul E. Jones
>>> Cc: 'Apps Discuss'
>>> Subject: Re: [apps-discuss] webfinger privacy question/suggestion
>>>
>>>
>>> Hiya,
>>>
>>> On 10/29/2012 09:30 PM, Paul E. Jones wrote:
>>>> Stephen,
>>>>
>>>>> The draft says:
>>>>>
>>>>> "  Let's assume your email client discovers that blog automatically
>>> for
>>>>>    you.  After receiving the message from Bob (bob@example.com), your
>>>>>    email client performs the following steps behind the scenes."
>>>>>
>>>>> ...then describes how I send out a request containing the string
>>>>> bob@example.com.
>>>>>
>>>>> The net result of that appears to be that I'll be sending out details
>>>>> about who I'm contacting (or want to contact) to a server with which
>>>>> I've no existing relationship, and that is probably going to turn out
>>>>> to be operated by one of the few very large providers.
>>>>>
>>>>> That seems to me to have potentially serious privacy issues. (As with
>>>>> all privacy issues, you never know when they're more than potential
>>>>> until its too late;-)
>>>>>
>>>>> Is that accurate?
>>>>
>>>> Yes, though be mindful that this just an non-normative example.
>>>
>>> Sure. But one that does nicely expose the privacy concern.
>>>
>>>>> I wondered why the wg didn't consider (even as an option) allowing
>>>>> the client to send a hash of Bob's URI? That way, if the request goes
>>>>> to the wrong place, things are a bit more privacy friendly.
>>>>> (I think an earlier draft from James Snell suggested this, but don't
>>>>> recall subsequent discussion about that.)
>>>>
>>>> The request should not go to the wrong place, though a request could
>>>> get intercepted on the wire.  It is for these reasons that we strongly
>>>> recommend use of TLS.
>>>
>>> Use of TLS is great (though some of the text about that might need
>>> tweaking). But the wrong place problem needs more work I suspect. In
>>> particular the (as you say non-normative) example quoted says that this
>>> is all happening in the background, and you don't normatively say how a
>>> client figures out the host to query. Now maybe you can't in general,
>>> but if not, then I think that causes the problem and TLS is no help in
>>> that.
>>>
>>> One danger here would be that my mail client might by default tell BigCo
>>> about the sender header field of all the mail I receive and when I got
>>> it and might not give me any control over that, all to try find a
>>> sender's blog 1 RTT quicker.
>>> That'd be a bad thing to do by accident, right?
>>>
>>> Another might be contexts where the derivation of the host to use is
>>> less clear. In the case of mail, should I use the sender or From domain
>>> for example if those differ? What about mailing lists? Are there similar
>>> ambiguities in XMPP or other protocols? I'd love to have a warm feeling
>>> that that's all been considered - and maybe it has, but I don't get that
>>> warm feeling as of now from the draft and my recollection of the list
>>> traffic on this.
>>>
>>>>> One argument for doing something privacy friendly here is that it
>>>>> would make sense to follow the approach of the safe web browsing
>>>>> mechanisms here - if its considered sensitive to tell a large
>>>>> provider about the URLs I'm visiting, then why is it ok to tell such
>>>>> a provider the names of the people I want to finger?
>>>>> (Having said that, yes, other mechanisms, such as URL completion take
>>>>> the opposite approach.)
>>>>
>>>> Whether we hash the information or not, a request received at the
>>>> legitimate WebFinger server would still know what is being requested.
>>>> I think the only case of concern is when non-TLS connections are used.
>>>
>>> Right, non-TLS to the wrong place is the main concern. It could be that
>>> some re-direction cases might also be an issue but not sure.
>>>
>>>>> More generally, it'd be good if webfinger privacy were discussed more
>>>>> on the list since maybe there are other privacy issues or mitigations
>>>>> that'd be better or easier.
>>>>
>>>> We've had only a little discussion on privacy and I've tried to insert
>>>> text to address the concerns that have been raised in Section 11
>>>> (security considerations), though I would be happy to insert a whole
>>>> section on privacy considerations if given some text.
>>>
>>> I hope that discussion happens on the list.
>>>
>>>>> (Note: I would raise a DISCUSS during IESG eval for this, but since
>>>>> it could lead to a change in the protocol, I'm raising it now in the
>>>>> hope that's more likely to be doable if it needs to be done.)
>>>>
>>>> We should certainly cover any security and privacy concerns, but the
>>>> fact of the matter is that use of WebFinger, Google, or any other
>>>> service where you search for information is going to reveal certain
>>> information about you.
>>>
>>> Personally, I think the key thing is to try make sure that the very very
>>> few folks who care are given some way to mitigate their concerns, or if
>>> that's not possible say then that its not possible after the list has
>>> had the discussion that reached that conclusion.
>>>
>>>> Likewise, posting any information where the public can retrieve it has
>>>> its risks, which is why servers should be controlled and access to web
>>>> resources controlled.
>>>
>>> Yes, you cover that already at least to some extent and there was some
>>> discussion on the list about it. I'm not clear if that's considered
>>> "done" or not though (can't recall). I guess the issue is whether there
>>> are any knobs the user could twist or not, and at present, it's "not"
>>> so webfinger is something that, if you use it, all the stuff you put at
>>> one host is available to anyone who can access that host. (Is that
>>> right?)
>>>
>>> I think that that's mostly ok, perhaps with some added advice about
>>> publishing stuff aimed at coders, e.g. to say "don't automatically
>>> publish users' information since that'd be a crappy way to deal with
>>> folks who care about privacy" or similar.
>>>
>>>> If the security considerations section does not have the wording to
>>>> address concerns, then please provide some words and I'd be happy to
>>> add them.
>>>
>>> I'd hope those emerge from list discussion - just because I'd DISCUSS
>>> the current text doesn't make me the right person to suggest new text.
>>>
>>> Cheers,
>>> S.
>>>
>>>
>>>>
>>>> Paul
>>>>
>>>>
>>>>
>>>>
>>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From paulej@packetizer.com  Mon Oct 29 20:09:03 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1703D21F85EE for ; Mon, 29 Oct 2012 20:09:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level: 
X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.401,  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 osbj3spVDM7E for ; Mon, 29 Oct 2012 20:09:02 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DF53B21F85EA for ; Mon, 29 Oct 2012 20:09:01 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9U38vdc028575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Oct 2012 23:08:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351566538; bh=byZrCvzQpoqfQX738W4+pwtSdFu4S7txf5TxOSutkWM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=M4Uj93D6lvkyU546tElt67ktcVSKj6sbipOeo5A+PUNtMG+fIEA2zUnmd2Mf78ykv i5m6/ONhNyA3KJy7DOgbIb2aUHb4uxQo65VaM9owJCfKBUCl3fYIThZWTM+ZPYkqno 39C6c8quXIjS66okb+W/dYt5HDelf7fFNZ9H8GQk=
From: "Paul E. Jones" 
To: "'Stephen Farrell'" 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie>
In-Reply-To: <508F2B78.2000006@cs.tcd.ie>
Date: Mon, 29 Oct 2012 23:09:04 -0400
Message-ID: <0be001cdb64b$eb574560$c205d020$@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: AQFLsjjsRNcR0N0rPY8CMxV87xY2TQDs4XE+AookvBECZOavfwEZKXCrmJ14rGA=
Content-Language: en-us
Cc: 'Apps Discuss' 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Oct 2012 03:09:03 -0000

Stephen,

> > Obviously, there are some things we can control (e.g., recommending
> > the use of TLS, so that all queries are hidden),
> 
> TLS has very little to do with privacy. That much ought be clear to this
> list, but in case not, confidentiality != privacy ought be a sufficient
> reminder.

I understand that, but privacy starts with having the doors closed and
windows shut.  My neighbors appreciate that, I can assure you. :-)

TLS at least allows one to conduct business such that it's not in full view
the neighbor peeping.

It does not hide queries made to the WF service provider, of course.  But,
that's true of any kind of request made to any service provider, including
queries to Google, Facebook, etc.
 
> > but there are many things
> > outside our control (e.g., exactly what gets published, what gets
> > queried, and when that information gets queried).
> 
> "When things get queried" ought presumably be entirely reasonable to
> discuss when defining the protocol with which they are queried.

I'm not opposed to it, but I'm not sure how we can specify that. It's like
telling an email client developer when they can send an email.

> > The right approach, IMO, is what Google is going with Google+.
> 
> I've no idea what that is. Where's it written down?

I'm not sure where it is documented, but if you have a Google+ profile, go
there.  Select "Edit Profile".  The screen is full of information about
yourself, including your contact info, those you follow, those following
you, where you work, etc.  Every single section has the option to make it
public or share it with specific "circles".  You can specify precisely what
circles can see the information.  Some information made public is published
via WebFinger so that it can be queried outside Google+.

For example, this is what Google publishes via WebFinger about me:
  http://www.google.com/s2/webfinger/?q=acct:103173924987331945891@gmail.com

Note this only returns an XRD document, since Google's implementation has
not yet been updated with the current text in this draft.

> > Ask users
> > what they want to make public or share with certain people.
> 
> Isn't that only considering the publisher-user issues? And that's (I
> hope clearly) not the main topic of my concern.

There are many aspects to privacy.  What users expose to whom is one of
them.
 
> > In the case of
> > WebFinger, it's mostly a matter of "what's made public", but not
> > always.  A company, for example, can publish information about
> > employees via WebFinger, but they can have that server such that the
> > information is accessible only internally or only by authorized users.
> > They could elect to share some information to the general public.
> 
> Only relevant for the publisher, not the one sending the query.

But the person sending the query *wants* to send the query and he/she knows
who he/she is sending a query about.  It's no different than looking up a
person on FB or sending an email.
 
> And what'd be wrong with providing tools that allow a publisher to
> reflect subtlety? Why is that harder or worse and for whom?

I don't understand your question.
 
> > The example I gave where the client automatically looks up information
> > is just an example, but it is a valid example... to your point.  It is
> > a good example of the kinds of things people can do and, if WF is
> > deployed widely, probably will do.  Writing cautionary tales of any
> > significant length in the WF spec is not going to change anything,
> > really. Many users like that convenience.
> 
> The above paragraph is filler, right? If not, I don't get the argument.

My position is that lots of privacy-related text in the WF document is
probably not what is needed to properly cover privacy issues related to
social networking and publishing information on the Internet.
 
> > So, somewhere we have to strike a balance between being overly
> > concerned with privacy and taking appropriate steps to ensure privacy.
> 
> In the above, you begin to be be pejorative.

I tend to do that sometimes, but not intentionally.  Let me be very clear in
saying that I fully agree that privacy is an issue.  What I don't think,
though, is that adding a lot of text to the WF spec to address privacy is
the right solution.  I'm happy to insert any text the group feels should be
added -- especially if somebody writes it.  Happy to play that role as
editor.

That said, what I honestly believe is needed is a IETF paper on privacy that
speaks about it in more depth.  Do people have the slightest clue what kind
of information can be mined from HTTP logs?  Or email logs?  DNS queries?

> > People who are
> > insanely concerned about their privacy should first walk away from the
> > Internet.
> 
> And now you perhaps perfect pejorative posing!

No, that's actually being a realist.  Given the literal oozing of
information through every single service on the Internet, there is no
privacy.  And Google is in the world's best position to mine that, too.
Give them your name or other personal info once and they can then tell you
everywhere you've been on that machine or might have been.  Google Ads are
everywhere and everything is recorded.  You can tell this from the fact they
offer interest-based ads.  How do they know your interests.  How do they
know you are?  Google is just one example.
 
> "balance" "overly" "appropriate" and "insanely" are all bad fillers that
> really indicate a need for something to be fixed.

:-) Select a different description, but people have varying degrees of
privacy expectations.

> I do hope you recognise that the last few sentences would be better not
> having been stated.

I don't, no.  Your desire for privacy is very different than mine, perhaps.
People are different and certainly have different expectations.  It was not
intended to mean more than that.
 
> > People reasonably concerned should not publish anything via WebFinger.
> > For most people, it is a matter of giving them the tools to control
> > what they publish for the world to see, WebFinger or otherwise.
> 
> Perhaps. But my question was about privacy for those whose user agents
> might automatically issue queries. Ignoring the question is not a way to
> answer the question.

This side is even easier to control.  One does not have to automatically
query.  I recall Outlook once offered the ability (perhaps it still does) of
checking to see if a buddy is online or not.  I'm not sure if MS got a
request for status behind the scenes or not, but the idea is similar.  Users
can turn that off.

Users can control what they enter into Google.

Users can re-consider entering a URL into a browser.  Every aspect of that
page load can be recorded, from the DNS query, to the TCP connection, to
HTTP server logs.

>From the requestor's side, it's really a matter of giving users the ability
to control what their computers do autonomously.  WF is one protocol to
consider, but every protocol needs consideration w.r.t. privacy.

> > If there were to be a treatise on social networking security, that
> > might be a good thing, but the WF document is not the right place to
> > give it appropriate treatment.
> 
> I agree. This I-D ought not include a treatise. Neither should
> discussion of this I-D base conclusions on bad argument, such as that
> you've offered above.

Well, I'll immediately confess to saying that I'm not the best author for
that document.  However, I do believe the points you and others have raised
are valid concerns, but the whole social networking, blogging,
micro-blogging, web commenting, etc. movement brings about a whole lot of
privacy issues that probably do need to be considered holistically.

Paul



From sm@resistor.net  Mon Oct 29 22:05:20 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DCB21F8553 for ; Mon, 29 Oct 2012 22:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.358
X-Spam-Level: 
X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 cXFT36RxNcAH for ; Mon, 29 Oct 2012 22:05:18 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0B421F853B for ; Mon, 29 Oct 2012 22:05:18 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q9U55Ba5022068; Mon, 29 Oct 2012 22:05:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351573517; bh=GdSS0v1zCW+cjvrK1X6iP85zZbX5/J0JDAC950GyvLM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=T7xyR9CFSaQOUKexov3olkDOMBygmR/tcxlEnKiwbL20LR0SSROrBWFDVqsTK0bSj PnmJG/5fzZax7JYqdeIAoLVRqH7ULQ2pw0OCkmhamj/2aZRfw1We+9hHQN/cZc4IYO 1OHZM3u6X6IjCvVqBS8dPvRz1b7mNrvQmDK2KtwA=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351573517; i=@resistor.net; bh=GdSS0v1zCW+cjvrK1X6iP85zZbX5/J0JDAC950GyvLM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rwnEKxcpO+DRyN8N5t02OkrRpyutA3BUNgsM4aWi/eby2a6y7uiQMcL5rbZ9gXAmj j+Nq4bbQQz0Ft2f7jQn3krMePkOmW75brgEQ9CXzctSzw33lkIiArD4HRU/zGifTfx FnPWk/U8dDuJBw2hZHOjYTi1x12LqvW3vCV2ZwmQ=
Message-Id: <6.2.5.6.2.20121029175131.0b257498@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 29 Oct 2012 21:54:05 -0700
To: "Paul E. Jones" 
From: SM 
In-Reply-To: <0b4001cdb622$1e9fe0f0$5bdfa2d0$@packetizer.com>
References: <508E66FB.4070708@cs.tcd.ie> <6.2.5.6.2.20121029123813.0a776890@resistor.net> <0b4001cdb622$1e9fe0f0$5bdfa2d0$@packetizer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Oct 2012 05:05:20 -0000

Hi Paul,
At 15:09 29-10-2012, Paul E. Jones wrote:
>You didn't keep quoting.  It goes on to advise that if you wish to restrict

When I mentioned quoted I meant the sentence I quoted from Section 11.

>I can (and do actually) put all kinds of contact information on my personal
>web page.  If people want to find that, they could.  Likewise, I could just
>not publish it.  Just because a WF server exists does not mean one has to
>populate it with information -- especially private information.

Ok.

>Consider Google+ as an example.  Information you share there is published
>via WebFinger.  However, you as the user gets to select what information is
>made public and what information is not.

Where can I find the privacy considerations for the above example?

If the plan for privacy consideration is to say that all personal 
information given, for example, to Google+ is a matter of user 
discretion, the proposal could be labelled with "no privacy 
considerations".  Here's how the world out there look at such issues:

   "The CNIL concluded that it is impossible for the average user who reads
    the new policy to distinguish which purposes, collected data, recipients
    or access rights are currently relevant to his or her use of particular
    Google tools or services. The CNIL also found that, even for trained
    professionals, it is extremely difficult to know exactly which data is
    combined between which services for which purposes. Since Google applies
    a single privacy policy across most of its services, including the Google
    search engine and the Gmail email service, the policy is raising 
significant
    doubts and fears." [1]

Regards,
-sm

1. europarl.europa.eu, E-2012-004040 


From sm@resistor.net  Mon Oct 29 23:29:33 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3415321F84E9 for ; Mon, 29 Oct 2012 23:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.398
X-Spam-Level: 
X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 qAIBsjlmA2Jj for ; Mon, 29 Oct 2012 23:29:31 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0ED521F84C6 for ; Mon, 29 Oct 2012 23:29:31 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q9U6TQ1w003848 for ; Mon, 29 Oct 2012 23:29:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351578571; bh=JMeH67+LxpbefRgtg9EPfMVPe2pjeiWtMrD7yFl6aF0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=EFoqgL+sogozZQshq52Ye8zhTyK2vYdQnVQ8BRWHrxb0s+G/8UZXkecllfxGNB/JS rxsmkVGFbDD7A8v7t9zfmQeXGVJX9LxS6u6+nNcuFtSQA3wJ4m3l9mdUrB9aNtURrm JqE0keADl2kSeN7QSo+MQlYCeOnSLA97vgAXCEnI=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351578571; i=@resistor.net; bh=JMeH67+LxpbefRgtg9EPfMVPe2pjeiWtMrD7yFl6aF0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=aUK8Gmp7YXvYD/G5lKd0Xh8KAjxKwf3+0++wMLa2eO2aRxkbmuaBkdGEt1z1NnqXd 0Ng6JpGpQIn4LJT9RBcVnYPzAlzG2fiNn00gdiUFXpflAcqMh+ZutAG5b/SR0BqML3 USbrvCLNuSah77V6dZksdQMQLN942f5JvpSztiVE=
Message-Id: <6.2.5.6.2.20121029230140.0e494208@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 29 Oct 2012 23:27:42 -0700
To: apps-discuss@ietf.org
From: SM 
In-Reply-To: 
References:  <6.2.5.6.2.20121029010910.0b334dc0@resistor.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [apps-discuss] IETF 85 Agenda
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Oct 2012 06:29:33 -0000

Hello,

Thanks to Murray and Andy for the replies.  The following comments 
are not directed at them.

At 07:32 29-10-2012, Murray S. Kucherawy wrote:
>On Mon, Oct 29, 2012 at 1:17 AM, SM  wrote:
> > Are there any Internet-Drafts I should read to be able to follow the
> > discussion about the following topics:
> >
> >  - Service Discovery Topics
>
>This may be merged with the webfinger material earlier in the session.

There's a "Service Discovery Topics" item which is preceded by a lot 
of webfinger material.  If I recall correctly, discussions about 
these topics previously generated long discussions.  May I suggest a 
"do we need a working group" for all that?

> >  - JSON Content Rules
>
>Andy provided one separately.  I'll update the agenda to reference it shortly.

There's an item about "Do we need a JSON Working Group?".  It is 
followed by some previews and then there is "JSON Content 
Rules".  Could a merge be considered?

BTW, the above are merely suggestions.  It is ok not to reply to this message.

Regards,
-sm


From stephen.farrell@cs.tcd.ie  Tue Oct 30 03:01:30 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E3721F84ED for ; Tue, 30 Oct 2012 03:01:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.514
X-Spam-Level: 
X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 EOI1Z3lPbfux for ; Tue, 30 Oct 2012 03:01:29 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 53FA921F84DD for ; Tue, 30 Oct 2012 03:01:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1A951C787; Tue, 30 Oct 2012 10:01:05 +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 vpFCFlh1BF0a; Tue, 30 Oct 2012 10:01:03 +0000 (GMT)
Received: from [10.87.48.4] (unknown [86.42.183.189]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6E46BC384; Tue, 30 Oct 2012 10:01:03 +0000 (GMT)
Message-ID: <508FA55F.5020608@cs.tcd.ie>
Date: Tue, 30 Oct 2012 10:01:03 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1
MIME-Version: 1.0
To: "Paul E. Jones" 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com>
In-Reply-To: <0be001cdb64b$eb574560$c205d020$@packetizer.com>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: 'Apps Discuss' 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Oct 2012 10:01:31 -0000

Hiya,

On 10/30/2012 03:09 AM, Paul E. Jones wrote:
> Stephen,
> 
>>> Obviously, there are some things we can control (e.g., recommending
>>> the use of TLS, so that all queries are hidden),
>>
>> TLS has very little to do with privacy. That much ought be clear to this
>> list, but in case not, confidentiality != privacy ought be a sufficient
>> reminder.
> 
> I understand that, but privacy starts with having the doors closed and
> windows shut.  My neighbors appreciate that, I can assure you. :-)

Possibly. But its really not relevant to this part of the discussion.

> TLS at least allows one to conduct business such that it's not in full view
> the neighbor peeping.
> 
> It does not hide queries made to the WF service provider, of course.  But,
> that's true of any kind of request made to any service provider, including
> queries to Google, Facebook, etc.

I think you're wrong there. If I send H(bob@example.com) to any
server that doesn't know about bob@example.com then that server
has less information than otherwise, and that's independent of
whether TLS was used or not. The server can still correlate
two requests that contain H(bob@example.com) and could in
principle search for the string bob@example.com and verify when
its found the right string.

Hashing the URI also makes the code a teeny bit more
complex and perhaps significantly more complex for some
kinds of client (e.g. javascript, before the webcrypto
API is deployed).

So hashing the URI as an option is not a crystal clear winner,
but is worth discussing and is different from not being able
to hash the URI.

The only place this touches on TLS usage is that it H(URI)
exposes less to intermediaries if TLS is not used.

>>> but there are many things
>>> outside our control (e.g., exactly what gets published, what gets
>>> queried, and when that information gets queried).
>>
>> "When things get queried" ought presumably be entirely reasonable to
>> discuss when defining the protocol with which they are queried.
> 
> I'm not opposed to it, but I'm not sure how we can specify that. It's like
> telling an email client developer when they can send an email.

Generic note, just in case: I'm raising things to discuss; I
don't mean that all that discussion needs to go into the draft.

In this case, I suspect there's not been so much consideration
of the non-obvious cases where you have to figure out what
server to ask, but I could well be wrong, or maybe its not been
considered but will not turn out to be a problem. Has that
been considered?

>>> The right approach, IMO, is what Google is going with Google+.
>>
>> I've no idea what that is. Where's it written down?
> 
> I'm not sure where it is documented, but if you have a Google+ profile, go
> there.  Select "Edit Profile".  The screen is full of information about
> yourself, including your contact info, those you follow, those following
> you, where you work, etc.  Every single section has the option to make it
> public or share it with specific "circles".  You can specify precisely what
> circles can see the information.  Some information made public is published
> via WebFinger so that it can be queried outside Google+.
> 
> For example, this is what Google publishes via WebFinger about me:
>   http://www.google.com/s2/webfinger/?q=acct:103173924987331945891@gmail.com
> 
> Note this only returns an XRD document, since Google's implementation has
> not yet been updated with the current text in this draft.

Interesting that the acct URI looks like it shares a lot of
characteristics with a hash (long, hard to guess). Perhaps
that further indicates utility in allowing the client to
choose that feature? As is, only the service provider (Google
in the above) gets to make that choice.

> 
>>> Ask users
>>> what they want to make public or share with certain people.
>>
>> Isn't that only considering the publisher-user issues? And that's (I
>> hope clearly) not the main topic of my concern.
> 
> There are many aspects to privacy.  What users expose to whom is one of
> them.

Right. As is whether to enable a choice for the user or not.

>  
>>> In the case of
>>> WebFinger, it's mostly a matter of "what's made public", but not
>>> always.  A company, for example, can publish information about
>>> employees via WebFinger, but they can have that server such that the
>>> information is accessible only internally or only by authorized users.
>>> They could elect to share some information to the general public.
>>
>> Only relevant for the publisher, not the one sending the query.
> 
> But the person sending the query *wants* to send the query and he/she knows
> who he/she is sending a query about.  It's no different than looking up a
> person on FB or sending an email.

It is different in the example originally quoted where the UA is
said to be doing this in the background. At that point I have
no idea if the user wants the information or not.

Which reminds me: how is caching handled here? Is the UA expected
to run the WF protocol again each time or not? From the privacy
perspective saying "no need to do it each time" would be good I
guess. I don't see any text along those lines. Did I miss that?

>> And what'd be wrong with providing tools that allow a publisher to
>> reflect subtlety? Why is that harder or worse and for whom?
> 
> I don't understand your question.

Sorry. This relates to the publisher. We're not defining a
protocol for the publisher to tell the server which bits of
information it'd like published, nor any conditions that
it'd like put on those. I was asking why that'd not be a
good thing to do. (And a fine answer might be: "go ahead
and do it if you care that much":-)

>  
>>> The example I gave where the client automatically looks up information
>>> is just an example, but it is a valid example... to your point.  It is
>>> a good example of the kinds of things people can do and, if WF is
>>> deployed widely, probably will do.  Writing cautionary tales of any
>>> significant length in the WF spec is not going to change anything,
>>> really. Many users like that convenience.
>>
>> The above paragraph is filler, right? If not, I don't get the argument.
> 
> My position is that lots of privacy-related text in the WF document is
> probably not what is needed to properly cover privacy issues related to
> social networking and publishing information on the Internet.

You may be right, but since I never asked for lots of text its
not very relevant is it? :-)

>>> So, somewhere we have to strike a balance between being overly
>>> concerned with privacy and taking appropriate steps to ensure privacy.
>>
>> In the above, you begin to be be pejorative.
> 
> I tend to do that sometimes, but not intentionally.  Let me be very clear in
> saying that I fully agree that privacy is an issue.  What I don't think,
> though, is that adding a lot of text to the WF spec to address privacy is
> the right solution.  I'm happy to insert any text the group feels should be
> added -- especially if somebody writes it.  Happy to play that role as
> editor.
> 
> That said, what I honestly believe is needed is a IETF paper on privacy that
> speaks about it in more depth.  Do people have the slightest clue what kind
> of information can be mined from HTTP logs?  Or email logs?  DNS queries?

Some don't. Some do and care. Some do and don't care. Some do
and don't want to be privacy friendly. (That last is conjecture;-)

I agree that it'd be good if we had a Danvers doctrine equivalent but
right now, we don't. So we need to consider it piecemeal like this.

> 
>>> People who are
>>> insanely concerned about their privacy should first walk away from the
>>> Internet.
>>
>> And now you perhaps perfect pejorative posing!
> 
> No, that's actually being a realist.  

The choice of terms is not aiming at realism, but aiming to be
pejorative IMO. Go on admit it:-)

> Given the literal oozing of
> information through every single service on the Internet, there is no
> privacy.  

You appear to recognise the problem ("oozing" implies that) but
suggest just surrendering? I think we can and should try do better.

> And Google is in the world's best position to mine that, too.
> Give them your name or other personal info once and they can then tell you
> everywhere you've been on that machine or might have been.  Google Ads are
> everywhere and everything is recorded.  You can tell this from the fact they
> offer interest-based ads.  How do they know your interests.  How do they
> know you are?  Google is just one example.
>  
>> "balance" "overly" "appropriate" and "insanely" are all bad fillers that
>> really indicate a need for something to be fixed.
> 
> :-) Select a different description, but people have varying degrees of
> privacy expectations.

Entirely true. But suggesting some walk away from the Internet is
unhelpful.

>> I do hope you recognise that the last few sentences would be better not
>> having been stated.
> 
> I don't, no.  

Pity.

> Your desire for privacy is very different than mine, perhaps.
> People are different and certainly have different expectations.  It was not
> intended to mean more than that.

We ought therefore recognise that and give even the tin-foil hat
brigade some choices, right?

>>> People reasonably concerned should not publish anything via WebFinger.
>>> For most people, it is a matter of giving them the tools to control
>>> what they publish for the world to see, WebFinger or otherwise.
>>
>> Perhaps. But my question was about privacy for those whose user agents
>> might automatically issue queries. Ignoring the question is not a way to
>> answer the question.
> 
> This side is even easier to control.  One does not have to automatically
> query.  

Where is that stated in the draft?

> I recall Outlook once offered the ability (perhaps it still does) of
> checking to see if a buddy is online or not.  I'm not sure if MS got a
> request for status behind the scenes or not, but the idea is similar.  Users
> can turn that off.
> 
> Users can control what they enter into Google.
> 
> Users can re-consider entering a URL into a browser.  Every aspect of that
> page load can be recorded, from the DNS query, to the TCP connection, to
> HTTP server logs.
> 
>>From the requestor's side, it's really a matter of giving users the ability
> to control what their computers do autonomously.  WF is one protocol to
> consider, but every protocol needs consideration w.r.t. privacy.
> 
>>> If there were to be a treatise on social networking security, that
>>> might be a good thing, but the WF document is not the right place to
>>> give it appropriate treatment.
>>
>> I agree. This I-D ought not include a treatise. Neither should
>> discussion of this I-D base conclusions on bad argument, such as that
>> you've offered above.
> 
> Well, I'll immediately confess to saying that I'm not the best author for
> that document.  

I don't know what "that document" you mean. If you mean a general
privacy draft, I suspect you're correct;-) But again, that's not
what I asking for/about.

> However, I do believe the points you and others have raised
> are valid concerns, but the whole social networking, blogging,
> micro-blogging, web commenting, etc. movement brings about a whole lot of
> privacy issues that probably do need to be considered holistically.

Maybe true. But that does not mean we do nothing in the meantime.

Cheers,
S.

> 
> Paul
> 
> 
> 

From hannes.tschofenig@gmx.net  Tue Oct 30 03:16:35 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFC721F8539 for ; Tue, 30 Oct 2012 03:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 yKY0pRtfh4yq for ; Tue, 30 Oct 2012 03:16:35 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 71D3921F852C for ; Tue, 30 Oct 2012 03:16:34 -0700 (PDT)
Received: (qmail invoked by alias); 30 Oct 2012 10:16:27 -0000
Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp070) with SMTP; 30 Oct 2012 11:16:27 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX189F518VvU9H3Ak5MLEpBDYckrtjruULwzr1WKlBF anxD7aNNNOT0Bd
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: <508FA55F.5020608@cs.tcd.ie>
Date: Tue, 30 Oct 2012 12:16:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net>
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie>
To: "Paul E. Jones" 
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: Apps Discuss 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Oct 2012 10:16:35 -0000

Just few notes:=20

>> I honestly believe is needed is a IETF paper on privacy that
>> speaks about it in more depth.=20

Have a look at: =
http://tools.ietf.org/html/draft-iab-privacy-considerations-04

>> TLS has very little to do with privacy.=20

Wrong. See above document.=20

| | We've had only a little discussion on privacy=20

I have raised these privacy issues already last year. My comments got =
ignored.=20



From jasnell@gmail.com  Tue Oct 30 04:56:53 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1661C21F8542 for ; Tue, 30 Oct 2012 04:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ArNAwPwVmpL for ; Tue, 30 Oct 2012 04:56:51 -0700 (PDT)
Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C3BA021F8536 for ; Tue, 30 Oct 2012 04:56:51 -0700 (PDT)
Received: by mail-ia0-f172.google.com with SMTP id x24so138739iak.31 for ; Tue, 30 Oct 2012 04:56:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2JMk7qmzCEimbBSGnFyiFlfDhl9ebO9Z5Z4Wr0RKMmc=; b=Z5QUn3iOhdbkHcNW9UgfjQaRBtbDhRg0RwlKgSn05759VVgnayozPHZZauNhusOOjM sgfKMit/f61Hq221+aIbfZ8YvlGyYhXMROS7ZaBVNjC5m+xLR+5ePg6E3/YYkSwlO1RA y4BW/+NBf35qeF8VDOljDf1bcv6+sBNOKZzUP2uZMx29K0yQIh3IpYnY1IxPhdu9EfNF F6Dprg9kPYhrXbhHdK0GZZ+8fEUrnhUlUFIy0np0HrKFJl7gbX3uBzk87pJfHsJVRecH lAtalN1ZJW2CpcIiW2bZh65HjOtWYc5xGUSt3fvoLLno+ag4UOJvnUO9lXo85nQxpCjS SYkw==
MIME-Version: 1.0
Received: by 10.50.149.234 with SMTP id ud10mr1177811igb.12.1351598211287; Tue, 30 Oct 2012 04:56:51 -0700 (PDT)
Received: by 10.64.46.225 with HTTP; Tue, 30 Oct 2012 04:56:49 -0700 (PDT)
Received: by 10.64.46.225 with HTTP; Tue, 30 Oct 2012 04:56:49 -0700 (PDT)
In-Reply-To: <0b9b01cdb637$f9e14900$eda3db00$@packetizer.com>
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com>  <0b9b01cdb637$f9e14900$eda3db00$@packetizer.com>
Date: Tue, 30 Oct 2012 04:56:49 -0700
Message-ID: 
From: James M Snell 
To: "Paul E. Jones" 
Content-Type: multipart/alternative; boundary=e89a8f23516d434c9204cd457b40
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Oct 2012 11:56:53 -0000

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

On Oct 29, 2012 5:46 PM, "Paul E. Jones"  wrote:
>
> James,
>
>
>
> I don=E2=80=99t think a hash buys us a whole lot.  It obfuscates things, =
but it
does not hide things.  So, I don=E2=80=99t know who users
=E2=80=9C53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d9255=
=E2=80=9D is, but
I can see you queried for them.  I could query for them and probably get
their vcard and find out their name.  I can look for something.  I can also
perhaps monitor your unencrypted email traffic or just get a hold of your
address book and then easily map the hashes to real identifiers.
>
>

That is a separate issue, really... and speaks to why I'd much prefer the
use of mechanisms such as oauth2 with wf to control who is authorized to
access any data. In any case, the idea is to make it more difficult by some
degree, not make it impossible. The former speaks to incremental
improvement while the latter is simply impossible.

>
> What=E2=80=99s the expression=E2=80=A6 =E2=80=9Csecurity through obfuscat=
ion isn=E2=80=99t security=E2=80=9D, or
some such.  It only serves to delay discovery, really.  To truly conceal ..
at least the domain level .. one needs to use TLS.  Even then, a BigCo can
see the unencrypted DNS requests and see that you might be talking to
somebody at packetizer.com about something.  A search via Google would
reveal the identity in a hurry. :-)

We're not talking about security. We're talking about privacy. Two
different things.

- james

>
>
>
> Paul
>
>
>
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: Monday, October 29, 2012 7:10 PM
> To: Paul E. Jones
> Cc: Stephen Farrell; Apps Discuss
>
> Subject: Re: [apps-discuss] webfinger privacy question/suggestion
>
>
>
>
>
> On Mon, Oct 29, 2012 at 2:30 PM, Paul E. Jones 
wrote:
>
> [snip]
> >
> > That seems to me to have potentially serious privacy issues. (As with
> > all privacy issues, you never know when they're more than potential
> > until its too late;-)
> >
> > Is that accurate?
>
> Yes, though be mindful that this just an non-normative example.
>
>
>
>
>
> Even so, it's an example that you explicitly call out in your spec that
very clearly highlights a privacy concern. If you're going to raise such an
example and not deal with the privacy implications beyond "use TLS", then
there is a problem. See below...
>
>
>>
>>
>>
>> > One argument for doing something privacy friendly here is that it woul=
d
>> > make sense to follow the approach of the safe web browsing mechanisms
>> > here - if its considered sensitive to tell a large provider about the
>> > URLs I'm visiting, then why is it ok to tell such a provider the names
>> > of the people I want to finger?
>> > (Having said that, yes, other mechanisms, such as URL completion take
>> > the opposite approach.)
>>
>> Whether we hash the information or not, a request received at the
legitimate
>> WebFinger server would still know what is being requested.  I think the
only
>> case of concern is when non-TLS connections are used.
>>
>>
>
>
>
> That's not necessarily true. Some subcomponent of the server would have
access to the data, yes, but that doesn't mean every subcomponent on that
server should be allowed to have access to that information. Further, it
does not necessarily follow that the server is required to know exactly
whose data it is serving up.. just that there is some blob of data about
someone or something being requested. URLs and query string parameters tend
to wind up getting recorded in server logs that are completely unprotected
by TLS. Hashing the identities makes it significantly more difficult to
mine those for useful information (obviously not impossible, but the idea
is to make it more difficult, not impossible).
>
>
>
> Note also, there are organizations with existing policies in place
forbidding the use of email identifiers within URI parameters. This is the
precise reason why lotus connections, for instance, provides an option to
use alternative identifiers within URIs. For such organizations, use of
WebFinger uri's is going to be quite problematic at best.
>
>
>
>  [snip]
>>
>> We should certainly cover any security and privacy concerns, but the
fact of
>> the matter is that use of WebFinger, Google, or any other service where
you
>> search for information is going to reveal certain information about you.
>> Likewise, posting any information where the public can retrieve it has
its
>> risks, which is why servers should be controlled and access to web
resources
>> controlled.
>>
>> If the security considerations section does not have the wording to
address
>> concerns, then please provide some words and I'd be happy to add them.
>
>
>
> This is not really a question about just coming up with additional
language for the security concerns section, the ability to support hashed
identifiers rather than email or acct: id's should be built into the
protocol. In fact, for a protocol such as this, privacy should be THE
default option. Meaning, hashed identifiers should always be used, IMHO.
>
>
>
> - James
>
>
>>
>> Paul
>>
>>
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

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




On Oct 29, 2012 5:46 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:

>

> James,

>

> =C2=A0

>

> I don=E2=80=99t think a hash buys us a whole lot.=C2=A0 It obfuscates =
things, but it does not hide things.=C2=A0 So, I don=E2=80=99t know who use=
rs =E2=80=9C53ae56ef33ccb9550869e58820df36c3b1cc9574712556059a3bfc716b4d925=
5=E2=80=9D is, but I can see you queried for them. =C2=A0I could query for =
them and probably get their vcard and find out their name.=C2=A0 I can look=
 for something.=C2=A0 I can also perhaps monitor your unencrypted email tra=
ffic or just get a hold of your address book and then easily map the hashes=
 to real identifiers.


>

> =C2=A0


That is a separate issue, really... and speaks to why I'=
d much prefer the use of mechanisms such as oauth2 with wf to control who i=
s authorized to access any data. In any case, the idea is to make it more d=
ifficult by some degree, not make it impossible. The former speaks to incre=
mental improvement while the latter is simply impossible.



>

> What=E2=80=99s the expression=E2=80=A6 =E2=80=9Csecurity through obfus=
cation isn=E2=80=99t security=E2=80=9D, or some such.=C2=A0 It only serves =
to delay discovery, really.=C2=A0 To truly conceal .. at least the domain l=
evel .. one needs to use TLS.=C2=A0 Even then, a BigCo can see the unencryp=
ted DNS requests and see that you might be talking to somebody at packetizer.com about something.=C2=A0 A sear=
ch via Google would reveal the identity in a hurry. :-)



We're not talking about security. We're talking abou=
t privacy. Two different things.


- james


>

> =C2=A0

>

> Paul

>

> =C2=A0

>

> From: James M Snell [mailto:jasne=
ll@gmail.com] 

> Sent: Monday, October 29, 2012 7:10 PM

> To: Paul E. Jones

> Cc: Stephen Farrell; Apps Discuss

>

> Subject: Re: [apps-discuss] webfinger privacy question/suggestion

>

> =C2=A0

>

> =C2=A0

>

> On Mon, Oct 29, 2012 at 2:30 PM, Paul E. Jones <paulej@packetizer.com> wrote:

>

> [snip]

> >

> > That seems to me to have potentially serious privacy issues. (As =
with

> > all privacy issues, you never know when they're more than pot=
ential

> > until its too late;-)

> >

> > Is that accurate?

>

> Yes, though be mindful that this just an non-normative example.

>

> =C2=A0

>

> =C2=A0

>

> Even so, it's an example that you explicitly call out in your spec=
 that very clearly highlights a privacy concern. If you're going to rai=
se such an example and not deal with the privacy implications beyond "=
use TLS", then there is a problem. See below...


>

> =C2=A0

>>

>> =C2=A0

>>

>> > One argument for doing something privacy friendly here is tha=
t it would

>> > make sense to follow the approach of the safe web browsing me=
chanisms

>> > here - if its considered sensitive to tell a large provider a=
bout the

>> > URLs I'm visiting, then why is it ok to tell such a provi=
der the names

>> > of the people I want to finger?

>> > (Having said that, yes, other mechanisms, such as URL complet=
ion take

>> > the opposite approach.)

>>

>> Whether we hash the information or not, a request received at the =
legitimate

>> WebFinger server would still know what is being requested. =C2=A0I=
 think the only

>> case of concern is when non-TLS connections are used.

>>

>> =C2=A0

>

> =C2=A0

>

> That's not necessarily true. Some subcomponent of the server would=
 have access to the data, yes, but that doesn't mean every subcomponent=
 on that server should be allowed to have access to that information. Furth=
er, it does not necessarily follow that the server is required to know exac=
tly whose data it is serving up.. just that there is some blob of data abou=
t someone or something being requested. URLs and query string parameters te=
nd to wind up getting recorded in server logs that are completely unprotect=
ed by TLS. Hashing the identities makes it significantly more difficult to =
mine those for useful information (obviously not impossible, but the idea i=
s to make it more difficult, not impossible).=C2=A0


>

> =C2=A0

>

> Note also, there are organizations with existing policies in place for=
bidding the use of email identifiers within URI parameters. This is the pre=
cise reason why lotus connections, for instance, provides an option to use =
alternative identifiers within URIs. For such organizations, use of WebFing=
er uri's is going to be quite problematic at best.


>

> =C2=A0

>

> =C2=A0[snip]

>>

>> We should certainly cover any security and privacy concerns, but t=
he fact of

>> the matter is that use of WebFinger, Google, or any other service =
where you

>> search for information is going to reveal certain information abou=
t you.

>> Likewise, posting any information where the public can retrieve it=
 has its

>> risks, which is why servers should be controlled and access to web=
 resources

>> controlled.

>>

>> If the security considerations section does not have the wording t=
o address

>> concerns, then please provide some words and I'd be happy to a=
dd them.

>

> =C2=A0

>

> This is not really a question about just coming up with additional lan=
guage for the security concerns section, the ability to support hashed iden=
tifiers rather than email or acct: id's should be built into the protoc=
ol. In fact, for a protocol such as this, privacy should be THE default opt=
ion. Meaning, hashed identifiers should always be used, IMHO.


>

> =C2=A0

>

> - James

>

> =C2=A0

>>

>> Paul

>>

>>

>>

>> _______________________________________________

>> apps-discuss mailing list

>> apps-discuss@ietf.org=


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

>

> =C2=A0


--e89a8f23516d434c9204cd457b40--

From sm@resistor.net  Tue Oct 30 10:22:37 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238CC21F844E for ; Tue, 30 Oct 2012 10:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.427
X-Spam-Level: 
X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 KeMoQ4eDW43g for ; Tue, 30 Oct 2012 10:22:36 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1137D21F8442 for ; Tue, 30 Oct 2012 10:22:36 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q9UHMQal027569; Tue, 30 Oct 2012 10:22:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351617751; bh=NOhKs50rQ5K2LmCGHc/xc9crC4LtYrd/5NFKSxjZabI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Tmswg/5GqCHhR9679+wU8lzbO7k1peAb8Zb+97BSZ9M53EfslkIIeKhn/urbw4QVv Ycluja1A4XZEiHEJjcgRgQUXJgnXpp09K1hEqBe5Z8VjAvCNCbruc3ctdr9mO04ckE ZmEm8crNAoltFmH/coU1Y3BszJlBSVhk7Q0Qjq/M=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351617751; i=@resistor.net; bh=NOhKs50rQ5K2LmCGHc/xc9crC4LtYrd/5NFKSxjZabI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=p8wI5s4xpKKkBvVWUqQDENpWoeJC2ekGAevJd5vfA8JXIgLvq3nQYQeIZY2Jm06in Qt0P0irjsRL0H4iUTR0Ydsntxa1Ko7iDYOI1f4e2DwoNF/Q6gjEGU6SHL+8DV8KXId OgblhbgkDl3KgCsReoAYAJArpjBXXXLyUIg3X5yM=
Message-Id: <6.2.5.6.2.20121030093556.0a82b130@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 30 Oct 2012 10:18:43 -0700
To: Hannes Tschofenig 
From: SM 
In-Reply-To: <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net>
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Oct 2012 17:22:37 -0000

At 03:16 30-10-2012, Hannes Tschofenig wrote:
>Have a look at: http://tools.ietf.org/html/draft-iab-privacy-considerations-04

Hmm, that draft was mentioned several months ago [1].

>I have raised these privacy issues already last year. My comments got ignored.

The following question was asked around 11 months ago [2]:

   "What are you planning to do to ensure the draft properly addresses
    security, privacy, and netiquette issues?"

The current plan seems to be: do nothing.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04747.html
2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03804.html 


From evan@status.net  Tue Oct 30 10:33:07 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F38021F8629 for ; Tue, 30 Oct 2012 10:33:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkOlnKH0oh7R for ; Tue, 30 Oct 2012 10:33:06 -0700 (PDT)
Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id C292121F8622 for ; Tue, 30 Oct 2012 10:33:06 -0700 (PDT)
Received: from [192.168.0.101] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 598B08D6608; Tue, 30 Oct 2012 17:44:27 +0000 (UTC)
Message-ID: <50900F51.5040805@status.net>
Date: Tue, 30 Oct 2012 13:33:05 -0400
From: Evan Prodromou 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: SM 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net>
In-Reply-To: <6.2.5.6.2.20121030093556.0a82b130@resistor.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Oct 2012 17:33:07 -0000

There may be some use to having private sharing of discovery data.

However, it's such a complicated and difficult problem, that trying to 
solve it with this version of Webfinger will effectively disallow public 
discovery.

That is: it's a terrible morass, which will sink this effort.

I suggest making a note in the security considerations that Webfinger 
links are visible to all, so don't put private stuff in there, full stop.

-Evan

On 12-10-30 01:18 PM, SM wrote:
> At 03:16 30-10-2012, Hannes Tschofenig wrote:
>> Have a look at: 
>> http://tools.ietf.org/html/draft-iab-privacy-considerations-04
>
> Hmm, that draft was mentioned several months ago [1].
>
>> I have raised these privacy issues already last year. My comments got 
>> ignored.
>
> The following question was asked around 11 months ago [2]:
>
>   "What are you planning to do to ensure the draft properly addresses
>    security, privacy, and netiquette issues?"
>
> The current plan seems to be: do nothing.
>
> Regards,
> -sm
>
> 1. 
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04747.html
> 2. 
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03804.html
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


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


From jasnell@gmail.com  Tue Oct 30 10:54:45 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD3921F858B for ; Tue, 30 Oct 2012 10:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.765
X-Spam-Level: 
X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 nIxtagj9+S3I for ; Tue, 30 Oct 2012 10:54:45 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB6ED21F8582 for ; Tue, 30 Oct 2012 10:54:44 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 9so950391iec.31 for ; Tue, 30 Oct 2012 10:54:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AyEzZxNa04+/XCrOmS+idynXgQtM44ViXc33fwbaTv4=; b=WUi6lWpJAKOgJfEcUCFnJFiHKsYn4yLUaa9fpyvh4fQeGZVAqTm60cBp+A/syDOr8D egvNndV6vx/I4l8gnWtTPnIu5DKCxf7+9OKBWwl81MZPOv/1pda1nj2dPK/W82QDvt6b Z5Qh33N0Zu9fGVXEjSrJ3TlwQamZ1epb3Poq+7EbUnyJTtMZm86vGcoH2hgk8+m2aKHt HwgMAB3tY28OwnqUpbKxNjAHXYi5W4dCUJrD21rE5snPf1h7jkbw/F7qFRWZ5pjyXN/Z nj/OokfUHzbqKsj29ZNVlelPxI8+zzMD/eqJA4Xb5bFKeZYuK82dxfiQQw4LpFBqht0T pBQQ==
MIME-Version: 1.0
Received: by 10.50.36.163 with SMTP id r3mr2315923igj.54.1351619684367; Tue, 30 Oct 2012 10:54:44 -0700 (PDT)
Received: by 10.64.46.225 with HTTP; Tue, 30 Oct 2012 10:54:43 -0700 (PDT)
Received: by 10.64.46.225 with HTTP; Tue, 30 Oct 2012 10:54:43 -0700 (PDT)
In-Reply-To: <50900F51.5040805@status.net>
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <50900F51.5040805@status.net>
Date: Tue, 30 Oct 2012 10:54:43 -0700
Message-ID: 
From: James M Snell 
To: Evan Prodromou 
Content-Type: multipart/alternative; boundary=14dae9340bf3287f2a04cd4a7b38
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Oct 2012 17:54:45 -0000

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

Agreed, doing too much in this particular draft would be a mistake. What I
want, however, is an incremental strip in the right direction. Right now,
hashing the identifier is not an option. It should be. Doing so would allow
more complex solutions to be built... solutions that take privacy,
confidentiality, authorization and authentication into full account and
allow us to span from "only sharing public data" to "sharing any data".

- James
On Oct 30, 2012 10:33 AM, "Evan Prodromou"  wrote:

> There may be some use to having private sharing of discovery data.
>
> However, it's such a complicated and difficult problem, that trying to
> solve it with this version of Webfinger will effectively disallow public
> discovery.
>
> That is: it's a terrible morass, which will sink this effort.
>
> I suggest making a note in the security considerations that Webfinger
> links are visible to all, so don't put private stuff in there, full stop.
>
> -Evan
>
> On 12-10-30 01:18 PM, SM wrote:
>
>> At 03:16 30-10-2012, Hannes Tschofenig wrote:
>>
>>> Have a look at: http://tools.ietf.org/html/**draft-iab-privacy-**
>>> considerations-04
>>>
>>
>> Hmm, that draft was mentioned several months ago [1].
>>
>>  I have raised these privacy issues already last year. My comments got
>>> ignored.
>>>
>>
>> The following question was asked around 11 months ago [2]:
>>
>>   "What are you planning to do to ensure the draft properly addresses
>>    security, privacy, and netiquette issues?"
>>
>> The current plan seems to be: do nothing.
>>
>> Regards,
>> -sm
>>
>> 1. http://www.ietf.org/mail-**archive/web/apps-discuss/**
>> current/msg04747.html
>> 2. http://www.ietf.org/mail-**archive/web/apps-discuss/**
>> current/msg03804.html
>> ______________________________**_________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/**listinfo/apps-discuss
>>
>
>
> --
> 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
>

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


Agreed, doing too much in this particular draft would be a m=
istake. What I want, however, is an incremental strip in the right directio=
n. Right now, hashing the identifier is not an option. It should be. Doing =
so would allow more complex solutions to be built... solutions that take pr=
ivacy, confidentiality, authorization and authentication into full account =
and allow us to span from "only sharing public data" to "sha=
ring any data". 



- James


On Oct 30, 2012 10:33 AM, "Evan Prodromou&q=
uot; <evan@status.net> wrote:<=
br type=3D"attribution">

There may be some use to having private sharing of discovery data.



However, it's such a complicated and difficult problem, that trying to =
solve it with this version of Webfinger will effectively disallow public di=
scovery.



That is: it's a terrible morass, which will sink this effort.



I suggest making a note in the security considerations that Webfinger links=
 are visible to all, so don't put private stuff in there, full stop.


-Evan



On 12-10-30 01:18 PM, SM wrote:



At 03:16 30-10-2012, Hannes Tschofenig wrote:



Have a look at: http://tools.ietf.org/html/draft-i=
ab-privacy-considerations-04





Hmm, that draft was mentioned several months ago [1].





I have raised these privacy issues already last year. My comments got ignor=
ed.





The following question was asked around 11 months ago [2]:



=C2=A0 "What are you planning to do to ensure the draft properly addre=
sses

=C2=A0 =C2=A0security, privacy, and netiquette issues?"



The current plan seems to be: do nothing.



Regards,

-sm



1. http://www.ietf.org/mail-archive/web/a=
pps-discuss/current/msg04747.html

2. http://www.ietf.org/mail-archive/web/a=
pps-discuss/current/msg03804.html

_______________________________________________

apps-discuss mailing list

apps-discuss@iet=
f.org

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







-- 

Evan Prodromou, CEO and Founder, StatusNet Inc.

1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7

E: evan@status.net=
 P: +1-514-554-3826



_______________________________________________

apps-discuss mailing list

apps-discuss@iet=
f.org

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




--14dae9340bf3287f2a04cd4a7b38--

From evan@status.net  Tue Oct 30 11:40:43 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EB821F85B3 for ; Tue, 30 Oct 2012 11:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.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 pRvGyr9fF3KB for ; Tue, 30 Oct 2012 11:40:43 -0700 (PDT)
Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id DA27B21F85B1 for ; Tue, 30 Oct 2012 11:40:42 -0700 (PDT)
Received: from [192.168.0.101] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id AECF88D657B for ; Tue, 30 Oct 2012 18:52:00 +0000 (UTC)
Message-ID: <50901F1C.80706@status.net>
Date: Tue, 30 Oct 2012 14:40:28 -0400
From: Evan Prodromou 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: IETF Apps Discuss 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <50900F51.5040805@status.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070109080109050605040009"
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Oct 2012 18:40:43 -0000

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

I'd suggest a mechanism like the following:

 1. Always provide some discovery data at the endpoint, even if it's empty.
 2. If some form of authentication is given, show additional items in
    full for the authenticated user.

Dialback authentication would probably work [1], but otherwise we don't 
have a lot of reasonable remote authentication systems.

Local authentication (HTTP Basic, Digest, OAuth, whatever) is also 
reasonable although I think this kind intra-domain discovery more often 
happens with e.g. directory services.

-Evan

[1] http://www.ietf.org/id/draft-prodromou-dialback-00.txt

On 12-10-30 01:54 PM, James M Snell wrote:
>
> Agreed, doing too much in this particular draft would be a mistake. 
> What I want, however, is an incremental strip in the right direction. 
> Right now, hashing the identifier is not an option. It should be. 
> Doing so would allow more complex solutions to be built... solutions 
> that take privacy, confidentiality, authorization and authentication 
> into full account and allow us to span from "only sharing public data" 
> to "sharing any data".
>
> - James
>
> On Oct 30, 2012 10:33 AM, "Evan Prodromou"  > wrote:
>
>     There may be some use to having private sharing of discovery data.
>
>     However, it's such a complicated and difficult problem, that
>     trying to solve it with this version of Webfinger will effectively
>     disallow public discovery.
>
>     That is: it's a terrible morass, which will sink this effort.
>
>     I suggest making a note in the security considerations that
>     Webfinger links are visible to all, so don't put private stuff in
>     there, full stop.
>
>     -Evan
>
>     On 12-10-30 01:18 PM, SM wrote:
>
>         At 03:16 30-10-2012, Hannes Tschofenig wrote:
>
>             Have a look at:
>             http://tools.ietf.org/html/draft-iab-privacy-considerations-04
>
>
>         Hmm, that draft was mentioned several months ago [1].
>
>             I have raised these privacy issues already last year. My
>             comments got ignored.
>
>
>         The following question was asked around 11 months ago [2]:
>
>           "What are you planning to do to ensure the draft properly
>         addresses
>            security, privacy, and netiquette issues?"
>
>         The current plan seems to be: do nothing.
>
>         Regards,
>         -sm
>
>         1.
>         http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04747.html
>         2.
>         http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03804.html
>         _______________________________________________
>         apps-discuss mailing list
>         apps-discuss@ietf.org 
>         https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
>     -- 
>     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
>


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


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


  
    
  
  
    
I'd suggest a mechanism like the
      following:

      
    
        
  1. Always provide some discovery data at the endpoint, even if
          it's empty.
    2. 
        
  2. If some form of authentication is given, show additional
          items in full for the authenticated user.
    
        
    3. 
      

      Dialback authentication would probably work [1], but otherwise we
      don't have a lot of reasonable remote authentication systems.

      

      Local authentication (HTTP Basic, Digest, OAuth, whatever) is also
      reasonable although I think this kind intra-domain discovery more
      often happens with e.g. directory services.

      

      -Evan

      

      [1] http://www.ietf.org/id/draft-prodromou-dialback-00.txt

      

      On 12-10-30 01:54 PM, James M Snell wrote:

    

    

      
Agreed, doing too much in this particular draft would
        be a mistake. What I want, however, is an incremental strip in
        the right direction. Right now, hashing the identifier is not an
        option. It should be. Doing so would allow more complex
        solutions to be built... solutions that take privacy,
        confidentiality, authorization and authentication into full
        account and allow us to span from "only sharing public data" to
        "sharing any data". 

      
- James

      
On Oct 30, 2012 10:33 AM, "Evan
        Prodromou" <evan@status.net> wrote:

        

          There may be some use to having private sharing of discovery
          data.

          

          However, it's such a complicated and difficult problem, that
          trying to solve it with this version of Webfinger will
          effectively disallow public discovery.

          

          That is: it's a terrible morass, which will sink this effort.

          

          I suggest making a note in the security considerations that
          Webfinger links are visible to all, so don't put private stuff
          in there, full stop.

          

          -Evan

          

          On 12-10-30 01:18 PM, SM wrote:

          

            At 03:16 30-10-2012, Hannes Tschofenig wrote:

            

              Have a look at: http://tools.ietf.org/html/draft-iab-privacy-considerations-04

            

            

            Hmm, that draft was mentioned several months ago [1].

            

            

              I have raised these privacy issues already last year. My
              comments got ignored.

            

            

            The following question was asked around 11 months ago [2]:

            

              "What are you planning to do to ensure the draft properly
            addresses

               security, privacy, and netiquette issues?"

            

            The current plan seems to be: do nothing.

            

            Regards,

            -sm

            

            1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04747.html

            2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03804.html

            _______________________________________________

            apps-discuss mailing list

            apps-discuss@ietf.org

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

          

          

          

          -- 

          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

        

      

    

    

    

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

  


--------------070109080109050605040009--

From paulej@packetizer.com  Tue Oct 30 17:36:49 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE10E21F8489 for ; Tue, 30 Oct 2012 17:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.221
X-Spam-Level: 
X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.378,  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 ZoftG1WFxUPx for ; Tue, 30 Oct 2012 17:36:48 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4046D21F8480 for ; Tue, 30 Oct 2012 17:36:48 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9V0aigZ027590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Oct 2012 20:36:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351643805; bh=ICKeYy4NHI0BRdXWOMEDzX3o92savx33fVFiYAR+efE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=UPdRcJHSLHxVSMSVvkgG5kNFFYLIJ1uYILdghKyfhmq+Tl1ABdx9Kbtt95V5lPgEz x9O702MJIh0Yx54ppm/C/jP0ZxS6gPTarXCaZb55TJoK/YVwh1EQfHYiNZN8aPo+56 /k9Z9O2q3M4duCT6aYdUcWKd+pZ43CQGUnjT9dTw=
From: "Paul E. Jones" 
To: "'Stephen Farrell'" 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie>
In-Reply-To: <508FA55F.5020608@cs.tcd.ie>
Date: Tue, 30 Oct 2012 20:36:52 -0400
Message-ID: <00ec01cdb6ff$d2c7fd50$7857f7f0$@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: AQFLsjjsRNcR0N0rPY8CMxV87xY2TQDs4XE+AookvBECZOavfwEZKXCrAUbsN9ACb4OCXZiBJ1BQ
Content-Language: en-us
Cc: 'Apps Discuss' 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 00:36:49 -0000

Stephen,

> > I understand that, but privacy starts with having the doors closed and
> > windows shut.  My neighbors appreciate that, I can assure you. :-)
> 
> Possibly. But its really not relevant to this part of the discussion.

It does, actually.
 
> > TLS at least allows one to conduct business such that it's not in full
> > view the neighbor peeping.
> >
> > It does not hide queries made to the WF service provider, of course.
> > But, that's true of any kind of request made to any service provider,
> > including queries to Google, Facebook, etc.
> 
> I think you're wrong there. If I send H(bob@example.com) to any server
> that doesn't know about bob@example.com then that server has less
> information than otherwise, and that's independent of whether TLS was
> used or not. The server can still correlate two requests that contain
> H(bob@example.com) and could in principle search for the string
> bob@example.com and verify when its found the right string.

If I query Google for H, then Google knows I'm looking for H. If I query
example.com for H (since example.com is the domain responsible for H), then
example.com knows I searched for H. These are the same.
 
> Hashing the URI also makes the code a teeny bit more complex and perhaps
> significantly more complex for some kinds of client (e.g. javascript,
> before the webcrypto API is deployed).

Hashing hides your request from an intermediary, but the WebFinger server
queried knows what H is.  If you wish to hide from the intermediaries or
lurkers out there, you need TLS.
 
> So hashing the URI as an option is not a crystal clear winner, but is
> worth discussing and is different from not being able to hash the URI.

I just don't see how it helps, honestly, except to hide the fact you're
looking for bob@example.com when you query using plain old HTTP and you
don't want people to know you queried for Bob.  But, if the server returns
an answer, everything will be laid out in plain text, so hashing will not
help hide anything.  TLS helps hide.

> The only place this touches on TLS usage is that it H(URI) exposes less
> to intermediaries if TLS is not used.

TLS exposes only the DNS query and the TCP connection to the server.
Intermediaries see nothing, not even the fact the WebFinger service was
queried.
 
> >>> but there are many things
> >>> outside our control (e.g., exactly what gets published, what gets
> >>> queried, and when that information gets queried).
> >>
> >> "When things get queried" ought presumably be entirely reasonable to
> >> discuss when defining the protocol with which they are queried.
> >
> > I'm not opposed to it, but I'm not sure how we can specify that. It's
> > like telling an email client developer when they can send an email.
> 
> Generic note, just in case: I'm raising things to discuss; I don't mean
> that all that discussion needs to go into the draft.
> 
> In this case, I suspect there's not been so much consideration of the
> non-obvious cases where you have to figure out what server to ask, but I
> could well be wrong, or maybe its not been considered but will not turn
> out to be a problem. Has that been considered?

The server to ask to resolve acct:bob@example.com?  That would be the server
identified by the A record (or CNAME pointing to an A record) for
example.com.

> >>> The right approach, IMO, is what Google is going with Google+.
> >>
> >> I've no idea what that is. Where's it written down?
> >
> > I'm not sure where it is documented, but if you have a Google+
> > profile, go there.  Select "Edit Profile".  The screen is full of
> > information about yourself, including your contact info, those you
> > follow, those following you, where you work, etc.  Every single
> > section has the option to make it public or share it with specific
> > "circles".  You can specify precisely what circles can see the
> > information.  Some information made public is published via WebFinger
> so that it can be queried outside Google+.
> >
> > For example, this is what Google publishes via WebFinger about me:
> >
> > http://www.google.com/s2/webfinger/?q=acct:103173924987331945891@gmail
> > .com
> >
> > Note this only returns an XRD document, since Google's implementation
> > has not yet been updated with the current text in this draft.
> 
> Interesting that the acct URI looks like it shares a lot of
> characteristics with a hash (long, hard to guess). Perhaps that further
> indicates utility in allowing the client to choose that feature? As is,
> only the service provider (Google in the above) gets to make that choice.

:-)  That's my account ID on Google+, not a hash.  It's not secret.
 
> >>> In the case of
> >>> WebFinger, it's mostly a matter of "what's made public", but not
> >>> always.  A company, for example, can publish information about
> >>> employees via WebFinger, but they can have that server such that the
> >>> information is accessible only internally or only by authorized
> users.
> >>> They could elect to share some information to the general public.
> >>
> >> Only relevant for the publisher, not the one sending the query.
> >
> > But the person sending the query *wants* to send the query and he/she
> > knows who he/she is sending a query about.  It's no different than
> > looking up a person on FB or sending an email.
> 
> It is different in the example originally quoted where the UA is said to
> be doing this in the background. At that point I have no idea if the
> user wants the information or not.

True, but any software product should always allow such things to be
configurable. It's not a WF issue, but a broader issue.

Here's a scary one to consider... Linked In will actually tell me who looks
at my profile.  I don't ask for that, but they send that info to me for some
reason.  Now, isn't that just a bit over-the-top?  I'd say it is.

This is why I say these kinds of privacy issues need broad treatment.  We
need a little text in the WF spec, and we have that, but the privacy issues
abound on the Internet and there is no way we can give it proper treatment
in WF.  The text would be larger than the WF draft.

> Which reminds me: how is caching handled here? Is the UA expected to run
> the WF protocol again each time or not? From the privacy perspective
> saying "no need to do it each time" would be good I guess. I don't see
> any text along those lines. Did I miss that?

As a service built on HTTP, all HTTP features may be used, including Cache
Control.  We do not cover all of the HTTP features, since that is covered by
HTTP. 
 
> >> And what'd be wrong with providing tools that allow a publisher to
> >> reflect subtlety? Why is that harder or worse and for whom?
> >
> > I don't understand your question.
> 
> Sorry. This relates to the publisher. We're not defining a protocol for
> the publisher to tell the server which bits of information it'd like
> published, nor any conditions that it'd like put on those. I was asking
> why that'd not be a good thing to do. (And a fine answer might be: "go
> ahead and do it if you care that much":-)

If I said that, I think you'd tell me I was being perjorative again ;-)

If I share info via Google+ and Google+ puts that in WebFinger, who is the
publisher?  Me or Google+?

In the case of Google+, I am given control over what Google+ then publishes.
That's not a protocol that we can write, but an interface that Google
provides me and then they take my input and put into their database.

We did not define a protocol that feeds into WF.  WF is defined only between
a server and an entity requesting information.  How the information gets
into the WF server is implementation-specific.  (In my own server, you
manually insert stuff into the database and the server extracts whatever it
sees when queried.)
 
> I agree that it'd be good if we had a Danvers doctrine equivalent but
> right now, we don't. So we need to consider it piecemeal like this.

Getting somewhere? :-)
 
> >>> People who are
> >>> insanely concerned about their privacy should first walk away from
> >>> the Internet.
> >>
> >> And now you perhaps perfect pejorative posing!
> >
> > No, that's actually being a realist.
> 
> The choice of terms is not aiming at realism, but aiming to be
> pejorative IMO. Go on admit it:-)

Perhaps my words are too strong?  Would it sound better if I referred to
people who are "insanely concerned" as people who are "extremely concerned"?
It is true, though, that there is little privacy on the Internet when it
comes to as accessing information that is publicly available.  Visiting a
web site, even querying for a server, or sending an email (even if the email
was encrypted using PGP) leaks bits of information about that person.

> > Given the literal oozing of
> > information through every single service on the Internet, there is no
> > privacy.
> 
> You appear to recognise the problem ("oozing" implies that) but suggest
> just surrendering? I think we can and should try do better.

It's certainly a problem, yes, and I am not opposed to putting a reasonable
amount of text into WF. I've tried already. However, the Internet as a whole
is "out of control" in this regard.

The one that really has my head shaking this week is Yahoo!'s and Apache's
decision to ignore the "Do Not Track" header coming from Internet Explorer
because they felt Microsoft had not right to assume its users would prefer
that little bit of privacy.  The argument was they were in violation of the
DNT spec where it says users should enable that feature.  Really
unbelievable.

> > And Google is in the world's best position to mine that, too.
> > Give them your name or other personal info once and they can then tell
> > you everywhere you've been on that machine or might have been.  Google
> > Ads are everywhere and everything is recorded.  You can tell this from
> > the fact they offer interest-based ads.  How do they know your
> > interests.  How do they know you are?  Google is just one example.
> >
> >> "balance" "overly" "appropriate" and "insanely" are all bad fillers
> >> that really indicate a need for something to be fixed.
> >
> > :-) Select a different description, but people have varying degrees of
> > privacy expectations.
> 
> Entirely true. But suggesting some walk away from the Internet is
> unhelpful.

Oh! Is that what got me in trouble?  It was a bold statement, I agree.
Given the current state of affairs, though... it's true.  Consider that DNT
mess as a good example.  Microsoft cannot win for losing there.

> > Your desire for privacy is very different than mine, perhaps.
> > People are different and certainly have different expectations.  It
> > was not intended to mean more than that.
> 
> We ought therefore recognise that and give even the tin-foil hat brigade
> some choices, right?

They should have choices.  But where you're going with WF concerns, while
valid, are issues that are much larger than WF.  The issues must and need to
be considered more broadly.  WF is, perhaps, the first _standard_ that would
allow a user to post tons of easily discoverable information about
themselves and which can be easily retrieved in via automated processes.
(That's not entirely true, since one could publish anything on the web today
via HTML and many other protocols, but WF has the express purpose of helping
to discover information about person and entities easily through a
programmatic interface.)

> >>> People reasonably concerned should not publish anything via
> WebFinger.
> >>> For most people, it is a matter of giving them the tools to control
> >>> what they publish for the world to see, WebFinger or otherwise.
> >>
> >> Perhaps. But my question was about privacy for those whose user
> >> agents might automatically issue queries. Ignoring the question is
> >> not a way to answer the question.
> >
> > This side is even easier to control.  One does not have to
> > automatically query.
> 
> Where is that stated in the draft?

And where does it say a client must or even should?

I could change the example in the text to which you referred to say that
Alice pushes button to retrieve information about Bob.  But, no matter how
it is worded, the text in that section will have no impact on
implementations.

If we need wording, that is what the Security Considerations is for.  There
is text there, but we can add more... if somebody suggests it.

> >>> If there were to be a treatise on social networking security, that
> >>> might be a good thing, but the WF document is not the right place to
> >>> give it appropriate treatment.
> >>
> >> I agree. This I-D ought not include a treatise. Neither should
> >> discussion of this I-D base conclusions on bad argument, such as that
> >> you've offered above.
> >
> > Well, I'll immediately confess to saying that I'm not the best author
> > for that document.
> 
> I don't know what "that document" you mean. If you mean a general
> privacy draft, I suspect you're correct;-) But again, that's not what I
> asking for/about.

You saw this posted in response:
http://tools.ietf.org/html/draft-iab-privacy-considerations-04

This is an interesting document.  I've not read it, but the abstract gives
me cause for concern.  It said:
   "This document offers guidance for developing privacy
    considerations for inclusion in IETF documents."

The kind of document I'm suggesting is needed is a blanket document that
covers privacy issues in general.  Skimming over the referenced text, it
seems to cover some of those things.  But, rather than being directed toward
the protocol developer, I really think we need a document like that that is
directed toward the application developer, network administrator, and
businesses that collects, stores, and utilizes end-user information.

We know DNS can reveal a lot.  I can tell if my son visits a web site to
play a game, for example.  If I modified the DNS server code, I could even
log each time he made a request.  We could say things like that about every
protocol we have defined today.

> > However, I do believe the points you and others have raised are valid
> > concerns, but the whole social networking, blogging, micro-blogging,
> > web commenting, etc. movement brings about a whole lot of privacy
> > issues that probably do need to be considered holistically.
> 
> Maybe true. But that does not mean we do nothing in the meantime.

I never suggested we do nothing.  There is some text in the spec already.  I
solicited for text several times :-)  I cannot adequately write
considerations for privacy as evidenced from the discussion and feeling that
what is written is insufficient.

Paul



From paulej@packetizer.com  Tue Oct 30 17:48:40 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D28321F868A for ; Tue, 30 Oct 2012 17:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.241
X-Spam-Level: 
X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.358,  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 vlqQsFZ8jLGh for ; Tue, 30 Oct 2012 17:48:38 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD3D21F86CE for ; Tue, 30 Oct 2012 17:48:38 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9V0mYth028074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Oct 2012 20:48:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351644515; bh=CbkwzqAxKTOfDSwKayb7Fjyy/a0zr2DMJDO6myejQF0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=cXrAGYdmfVy0Bk2OhG021m1vX8K2kbc111bK4SHs8qHIKYp3eTZFVtmPBzXUJr3Fc Tb8ZUMsSzMAx8bN/k7ReLU7NC+usmchuG3eEszmyomGqg6gGs3eQHi1m6YcTvCYFdk fm8JdY1gw78iaz7I3gakP6kps/i6utyocpVTCNjE=
From: "Paul E. Jones" 
To: "'SM'" , "'Hannes Tschofenig'" 
References: <508E66FB.4070708@cs.tcd.ie>	<0b3b01cdb61c$981dc600$c8595200$@packetizer.com>	<508F0870.9050402@cs.tcd.ie>	<0b9901cdb636$bf951480$3ebf3d80$@packetizer.com>	<508F2B78.2000006@cs.tcd.ie>	<0be001cdb64b$eb574560$c205d020$@packetizer.com>	<508FA55F.5020608@cs.tcd.ie>	<5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net>
In-Reply-To: <6.2.5.6.2.20121030093556.0a82b130@resistor.net>
Date: Tue, 30 Oct 2012 20:48:42 -0400
Message-ID: <00ee01cdb701$7a68ef00$6f3acd00$@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: AQFLsjjsRNcR0N0rPY8CMxV87xY2TQDs4XE+AookvBECZOavfwEZKXCrAUbsN9ACb4OCXQI3fPywAU9o2S+YZQsAwA==
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 00:48:40 -0000

That's not an entirely true statement.  See:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02#section-11

Question is whether that is sufficient.  Thus far, I've not received any
additional text.

Paul

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of SM
> Sent: Tuesday, October 30, 2012 1:19 PM
> To: Hannes Tschofenig
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] webfinger privacy question/suggestion
> 
> At 03:16 30-10-2012, Hannes Tschofenig wrote:
> >Have a look at: http://tools.ietf.org/html/draft-iab-privacy-
> considerations-04
> 
> Hmm, that draft was mentioned several months ago [1].
> 
> >I have raised these privacy issues already last year. My comments got
> ignored.
> 
> The following question was asked around 11 months ago [2]:
> 
>    "What are you planning to do to ensure the draft properly addresses
>     security, privacy, and netiquette issues?"
> 
> The current plan seems to be: do nothing.
> 
> Regards,
> -sm
> 
> 1. http://www.ietf.org/mail-archive/web/apps-
> discuss/current/msg04747.html
> 2. http://www.ietf.org/mail-archive/web/apps-
> discuss/current/msg03804.html
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From sm@resistor.net  Wed Oct 31 01:55:35 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFAB21F8736 for ; Wed, 31 Oct 2012 01:55:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.448
X-Spam-Level: 
X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 C2F1xDbKK99j for ; Wed, 31 Oct 2012 01:55:34 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D917E21F8734 for ; Wed, 31 Oct 2012 01:55:34 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q9V8tT89012786; Wed, 31 Oct 2012 01:55:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351673733; bh=VlHgBVVq+WJu1btcIOZ/UJ5ecpvjWfM3/e7cKke5OYc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=v7fdGt2zCQQdfXjeG3MNPqMEU5vl1Nh+N6Zs2I8iLQPh0GtQ8HaS+0SpLNmukx8k0 8j1oPCLzS5D0sBdrvz8OpzuW9kbmBvNA6ns5rLbDeZgpEA9NpYUrqvO+91KbyYf3gz UgRShCeeCVOObIPYH6+N+H489KaoTWK9b5k174Dg=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351673733; i=@resistor.net; bh=VlHgBVVq+WJu1btcIOZ/UJ5ecpvjWfM3/e7cKke5OYc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2u4cwePXEzHYeTiZYI9MfEoAmVhPVnhUde2sdYyYOuzeukyswuNZemS5tP29l/QJU vvjgZZZba8PxQvQzwqsS4+Ml24IkgHL/+mPiNHdNZdmpAPcq6YYfCdU50KCqxfhx5s giwx+64u009FctVxQcXXQ97wCw7qhpaQ7GOF8qME=
Message-Id: <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 30 Oct 2012 23:57:35 -0700
To: "Paul E. Jones" 
From: SM 
In-Reply-To: <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com>
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 08:55:35 -0000

Hi Paul,
At 17:48 30-10-2012, Paul E. Jones wrote:
>That's not an entirely true statement.  See:
>http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02#section-11

Ok.

>Question is whether that is sufficient.  Thus far, I've not received any
>additional text.

As far as I am aware the IETF Stream is not an open source project 
where one does "send patch".  I read a draft and I comment about 
it.  There isn't any requirement for me to "send text".  It obviously 
does not help the working group to resolve issues if I do not put in 
the effort to "send text".  However, I see the effort as one-sided if 
"send text" is the only argument to address an issue.

It was mentioned that Google+ uses Webfinger [1].  It was argued that 
the right approach is what Google is going with Google+.  Nobody has 
been able to find where the documentation is.

 From Section 11 of the draft:

   "Service providers and users should be aware that placing information
    on the Internet accessible through WebFinger means that any user can
    access that information."

I strongly doubt that service providers will be overtly concerned 
about placing information about their users on the Internet.

   "While WebFinger can be an extremely useful tool for allowing quick
    and easy access to one's avatar, blog, or other personal information,
    users should understand the risks, too."

The user can only make that decision if he/she is provided with 
enough information.  I rewrote the following sentence:

   If one does not wish to share certain information with the world, one
   must not use any service supporting WebFinger.

Quoting draft-iab-privacy-considerations-04:

   "Correlation is the combination of various pieces of information
    related to an individual.  Correlation can defy people's expectations
    of the limits of what others know about them.  It can increase the
    power that those doing the correlating have over individuals as well
    as correlators' ability to pass judgment, threatening individual
    autonomy and reputation."

Is that an issue with respect to Webfinger?

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07685.html 


From stephen.farrell@cs.tcd.ie  Wed Oct 31 02:17:30 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2210021F875F for ; Wed, 31 Oct 2012 02:17:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EId8rGrxZxB for ; Wed, 31 Oct 2012 02:17:29 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5A14421F874E for ; Wed, 31 Oct 2012 02:17:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5621DC7C6; Wed, 31 Oct 2012 09:17:04 +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 TsBbR4Or+d5J; Wed, 31 Oct 2012 09:17:02 +0000 (GMT)
Received: from [10.87.48.4] (unknown [86.44.73.196]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E0897C7C5; Wed, 31 Oct 2012 09:17:01 +0000 (GMT)
Message-ID: <5090EC8D.5050900@cs.tcd.ie>
Date: Wed, 31 Oct 2012 09:17:01 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: SM 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net>
In-Reply-To: <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 09:17:30 -0000

Hi SM,

On 10/31/2012 06:57 AM, SM wrote:
> Hi Paul,
> At 17:48 30-10-2012, Paul E. Jones wrote:
>> That's not an entirely true statement.  See:
>> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02#section-11
> 
> Ok.
> 
>> Question is whether that is sufficient.  Thus far, I've not received any
>> additional text.
> 
> As far as I am aware the IETF Stream is not an open source project where
> one does "send patch".  I read a draft and I comment about it.  There
> isn't any requirement for me to "send text".  It obviously does not help
> the working group to resolve issues if I do not put in the effort to
> "send text".  However, I see the effort as one-sided if "send text" is
> the only argument to address an issue.

I kind of agree, but am also sympathetic to Paul's position.

If, as a document editor, he's being asked to put in stuff
with which he's not fully in agreement, (which seems to be the
case here, roughly), then "send text" seems to me like a pretty
reasonable response from any wg document editor in that position
who's willing to do the right thing and add text for which
there's rough consensus even if they don't personally like it.

If none of us that are commenting, (incl. me) have the energy
to suggest some text then that's also significant.

OTOH, I don't think we're that near a rough consensus on what
text might go in, so its arguably early for the document
editor to fall back to "send text."

Maybe we should try get a few folks who care about this into
a huddle in ATL if some of those who're interested will be
there? (If the Sunday reception worked then on Monday morning
Paul might be able to say something more than "we have insane
privacy nuts" :-)

S.

PS: Not wearing any hats and all that.



From mmn@hethane.se  Wed Oct 31 03:42:35 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D158E21F87EC for ; Wed, 31 Oct 2012 03:42:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCJY8N3aA7I8 for ; Wed, 31 Oct 2012 03:42:35 -0700 (PDT)
Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id D396421F875A for ; Wed, 31 Oct 2012 03:42:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 31 Oct 2012 11:42:31 +0100
From: Mikael Nordfeldth 
To: 
In-Reply-To: <5090EC8D.5050900@cs.tcd.ie>
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net> <5090EC8D.5050900@cs.tcd.ie>
Message-ID: 
X-Sender: mmn@hethane.se
User-Agent: Roundcube Webmail/0.7.1
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 10:42:36 -0000

31.10.2012 10:17 skrev Stephen Farrell:
> Maybe we should try get a few folks who care about this into
> a huddle in ATL if some of those who're interested will be
> there? (If the Sunday reception worked then on Monday morning
> Paul might be able to say something more than "we have insane
> privacy nuts" :-)
>
> S.
>
> PS: Not wearing any hats and all that.

Except the tinfoil one? ;-)

Either way I think it is important to remember that what Webfinger is 
basically just standardise the way humans, machines and our future 
androids will lookup information about pseudonyms. It does not in any 
way _produce_ more information.

Whatever reason you have to worry about the "hidden lookups" (which 
initiated this thread) or personal data collection/correlation, are not 
new issues created by Webfinger. The only thing WF maybe does is make it 
more obvious that such things can - and perhaps even do - occur. The 
data is already out there, on zillions of forums, communities, mailing 
lists etc, where users "ooze" their personal data.

I see a great opportunity in that transparency, the fact that maybe 
internet users can


Also, Stephen and whomever else is concerned. If you (or "normal 
people" or "privacy nuts") do not trust the service or application you 
run to handle your (or others') privacy well, I heavily recommend you to 
stop using it. Or simply don't give out data that can be correlated with 
whatever you don't want it correlated with.

If one is concerned with privacy and the service or software won't let 
you switch off this "oozing", simply stop using it (or make sure you use 
it in a privacy-minded manner). If it, say, uses Webfinger you can 
yourself verify it doesn't reveal any inappropriate data - or just stop 
using the service.

And if a third party somehow aggregates information about you without 
your consent, it's definitely a privacy issue and even illegal in many 
jurisdictions. If that is the case, it should be acted upon through 
court of law. Not by modifying suggested internet protocol standards.

-- 
Mikael Nordfeldth
http://blog.mmn-o.se/
mmn@hethane.se
+46705657637

From stephen.farrell@cs.tcd.ie  Wed Oct 31 04:56:50 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BB821F87B7 for ; Wed, 31 Oct 2012 04:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90x++RwmWk3E for ; Wed, 31 Oct 2012 04:56:50 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C945421F87B5 for ; Wed, 31 Oct 2012 04:56:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C485EC7C5; Wed, 31 Oct 2012 11:56:26 +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 cxQsCanzR9B1; Wed, 31 Oct 2012 11:56:21 +0000 (GMT)
Received: from [IPv6:2001:770:10:203:b029:7495:71cc:59b] (unknown [IPv6:2001:770:10:203:b029:7495:71cc:59b]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C50EFC3B1; Wed, 31 Oct 2012 11:56:21 +0000 (GMT)
Message-ID: <509111E5.8040403@cs.tcd.ie>
Date: Wed, 31 Oct 2012 11:56:21 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: Mikael Nordfeldth 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net> <5090EC8D.5050900@cs.tcd.ie> 
In-Reply-To: 
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 11:56:50 -0000

Hiya,

On 10/31/2012 10:42 AM, Mikael Nordfeldth wrote:
> 31.10.2012 10:17 skrev Stephen Farrell:
>> Maybe we should try get a few folks who care about this into
>> a huddle in ATL if some of those who're interested will be
>> there? (If the Sunday reception worked then on Monday morning
>> Paul might be able to say something more than "we have insane
>> privacy nuts" :-)
>>
>> S.
>>
>> PS: Not wearing any hats and all that.
> 
> Except the tinfoil one? ;-)

:-)

Generic (but interesting, for me) discussion below...

> Either way I think it is important to remember that what Webfinger is
> basically just standardise the way humans, machines and our future
> androids will lookup information about pseudonyms. It does not in any
> way _produce_ more information.

I could argue that aggregates are always more sensitive than
unaggregated information. I do think that may be relevant
for webfinger services, though maybe not much for the protocol
as currently specified.

> Whatever reason you have to worry about the "hidden lookups" (which
> initiated this thread) or personal data collection/correlation, are not
> new issues created by Webfinger. The only thing WF maybe does is make it
> more obvious that such things can - and perhaps even do - occur. The
> data is already out there, on zillions of forums, communities, mailing
> lists etc, where users "ooze" their personal data.

One of the things we try do when standardising stuff is to ensure
that appropriate (strong) security mechanisms are well-defined and
maybe mandatory to implement. That wasn't always the case, and we
still struggle with adding security more than a decade later, e.g.
with routing. (See sidr/karp for example.)

We don't have an IETF consensus that we ought also try
make things (be able to be) more privacy-friendly, and we're
IMO much less certain of what'd be right to do both in general,
and in specific cases like webfinger, but I personally reckon
we ought pay more attention to privacy and not just continue
oozing away mindlessly. But like I say, that's not a consensus
opinion by any means. It is a valid thing to question though.

> I see a great opportunity in that transparency, the fact that maybe
> internet users can

I agree things like webfinger create opportunities, perhaps
both good and bad. I'm not at all saying that webfinger is bad
btw.

> Also, Stephen and whomever else is concerned. If you (or "normal people"
> or "privacy nuts") do not trust the service or application you run to
> handle your (or others') privacy well, I heavily recommend you to stop
> using it. Or simply don't give out data that can be correlated with
> whatever you don't want it correlated with.
> 
> If one is concerned with privacy and the service or software won't let
> you switch off this "oozing", simply stop using it (or make sure you use
> it in a privacy-minded manner). If it, say, uses Webfinger you can
> yourself verify it doesn't reveal any inappropriate data - or just stop
> using the service.

Well, that's not always practical. And it'd also be a shame if say
adding webfinger to some site that was generally privacy-friendly
had to make that site less privacy-friendly. I'm not saying
that is the case here, its a generic argument about ooziness I guess.
(How many variants of "ooze" can we invent I wonder:-)

> And if a third party somehow aggregates information about you without
> your consent, it's definitely a privacy issue and even illegal in many
> jurisdictions. If that is the case, it should be acted upon through
> court of law. Not by modifying suggested internet protocol standards.

 is illegal somewhere does not imply the IETF should do nothing
about . I think that's a broken argument, though you may be
right that for some privacy issues, there's little that can be done
with our protocols. (Saying  is illegal somewhere therefore we
have to standardise a way to prevent  would be an equally
broken argument btw.)

Misuse of computers (e.g. via standards-track protocols) is illegal
in lots of places, as is spam, but we do quite a bit to try help
in such cases, and we do recognise that we cannot ignore the bad
actors that exist.

So I probably predictably disagree if your conclusion was either
that all's well in the world or that we're already so screwed it
doesn't matter.

And none of the above helps Paul know what to put in the draft;-)

S.



From hallam@gmail.com  Wed Oct 31 05:20:51 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2844921F854E for ; Wed, 31 Oct 2012 05:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUKA4yzwpBMT for ; Wed, 31 Oct 2012 05:20:50 -0700 (PDT)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9425821F8491 for ; Wed, 31 Oct 2012 05:20:50 -0700 (PDT)
Received: by mail-oa0-f44.google.com with SMTP id n5so1459404oag.31 for ; Wed, 31 Oct 2012 05:20:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9hqSNQ/Jl8+uZ9QbRO34GX2t86JFO0/gkNRA1Dmc/lU=; b=Ja5pyyd7nj3Swj9P5t9JSQaG6wwE0TU5CL6TgCQ2jvodNKGHkD8VrwAAC/Dlyn9Kdh +uiOWeM65adBniPlceLhql9PGEdA3mK2Rh+TyJV2sCqFh5Q4a7AjpsSPoc/7wzao6ex2 UZAZ3MKIxpVbOMUovGSFzNhv5ixVTLs2wMFN260fVEIo2TWrlX3PNTC2HEXxLT5Z4Vha pYs0axQ+xqpPyqz/MwfWtY9IxNwNAZfog50EecEox04IWtdKL/7ZExR2ZKSKQ+oxfh70 IDfMMefcMDk5qoK6/IN+2VOPJ7GuAV8gAJ1Dj+72O2D6dNnWNIcFAEzHCkVnu75C2ooc BnpQ==
MIME-Version: 1.0
Received: by 10.182.95.205 with SMTP id dm13mr30689143obb.9.1351686050179; Wed, 31 Oct 2012 05:20:50 -0700 (PDT)
Received: by 10.76.27.103 with HTTP; Wed, 31 Oct 2012 05:20:50 -0700 (PDT)
In-Reply-To: <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net>
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net>
Date: Wed, 31 Oct 2012 08:20:50 -0400
Message-ID: 
From: Phillip Hallam-Baker 
To: SM 
Content-Type: multipart/alternative; boundary=14dae93b6320de6a6c04cd59eefd
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 12:20:51 -0000

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

So i was at the OWASP conference in Austin last week and they had a whole
slew of Javascript hacks that pretty much demonstrate that with the Web as
it is right now, everyone gives pretty much everything away when they visit
any site.

The real culprit here is Javascript which basically was designed by people
who only cared about goosing their stock options. But being an application
conference, well 90% of the attendees make their living writing Javascript
so 'turn it off' is not an option for them.

Webfinger as currently designed is not going to make the situation any
worse, but it isn't going to make it better either.


Looking at the horrors that Javascript is committing and the refusal to
consider any changes that reduce functionality (including widely abused
functionality). I would put the chances of regulation at 100%. In a few
years those guys are going to be writing standards with more lawyers than
engineers sitting in the room unless they have a sudden change of mindset.

So rather than framing the argument as 'is Webfinger damaging privacy' I
would ask 'is Web finger helping people to do the sorts of things that
users want without unexpected privacy side effects'.

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

So i was at the OWASP conference in Austin last week and they had a whole s=
lew of Javascript hacks that pretty much demonstrate that with the Web as i=
t is right now, everyone gives pretty much everything away when they visit =
any site.


The real culprit here is Javascript which basically was desi=
gned by people who only cared about goosing their stock options. But being =
an application conference, well 90% of the attendees make their living writ=
ing Javascript so 'turn it off' is not an option for them.



Webfinger as currently designed is not going to make th=
e situation any worse, but it isn't going to make it better either.


Looking at the horrors that Javascript=
 is committing and the refusal to consider any changes that reduce function=
ality (including widely abused functionality). I would put the chances of r=
egulation at 100%. In a few years those guys are going to be writing standa=
rds with more lawyers than engineers sitting in the room unless they have a=
 sudden change of mindset.



So rather than framing the argument as 'is Webfinge=
r damaging privacy' I would ask 'is Web finger helping people to do=
 the sorts of things that users want without unexpected privacy side effect=
s'.


--14dae93b6320de6a6c04cd59eefd--

From hannes.tschofenig@gmx.net  Wed Oct 31 06:06:20 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB8221F87CC for ; Wed, 31 Oct 2012 06:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Noym6Uy-K4yA for ; Wed, 31 Oct 2012 06:06:20 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E00C321F85B3 for ; Wed, 31 Oct 2012 06:06:19 -0700 (PDT)
Received: (qmail invoked by alias); 31 Oct 2012 13:06:11 -0000
Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp024) with SMTP; 31 Oct 2012 14:06:11 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+BlekQPpWBbQ0J+4Uq6gqVBpH11/cJGQiCVdC2Ad pkzoF+9NHcA0cd
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: 
Date: Wed, 31 Oct 2012 15:06:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net> 
To: Phillip Hallam-Baker 
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 13:06:20 -0000

Hi Phillip,=20

On Oct 31, 2012, at 2:20 PM, Phillip Hallam-Baker wrote:

> Javascript which basically was designed by people who only cared about =
goosing their stock options.

I do not disagree with you here but WebFinger by itself does not =
necessarily need to be implemented in JavaScript(*).=20

> 'is Web finger helping people to do the sorts of things that users =
want without unexpected privacy side effects'

There are use cases where people want to use WebFinger as a discovery =
mechanism (such as OAuth) where the current design of WebFinger =
introduces privacy problems (unnecessarily). I raised this issue last =
year in May: =20
http://www.ietf.org/mail-archive/web/oauth/current/msg08965.html

It seems that WebFinger has become a solution in search of a problem for =
some people.=20

Ciao
Hannes

PS: (*) In the context of the use case I care about (namely identity =
management) implementations of JavaScript tend to have serious security =
problems. =20=

From sm@resistor.net  Wed Oct 31 07:15:38 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE4821F8804 for ; Wed, 31 Oct 2012 07:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.465
X-Spam-Level: 
X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 8eCrnhdS0NhH for ; Wed, 31 Oct 2012 07:15:37 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CCC21F86F4 for ; Wed, 31 Oct 2012 07:15:37 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q9VEFGKZ015220; Wed, 31 Oct 2012 07:15:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351692929; bh=K3w7eK3HnaWhxNN4besKxbdoi9OXJyvKY3XXkx+uQHc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pJj5QklGu01TprJ59/HfBl5O5itNgAbdprRRbPQqf3r77x+Ty8kZvWSlye8sMm20t v9wfLaIfYyKDy7dwrupx6d+JytT84BY+sS9QOLZeydrlc/GmziMgSRUGb9Wr/WSToI Em5ZkTjY1p/kzcITFNHdVqO9z4CFvuhjlQWUK7II=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351692929; i=@resistor.net; bh=K3w7eK3HnaWhxNN4besKxbdoi9OXJyvKY3XXkx+uQHc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FRdd1rzp6mEQ8rlzp37g6zzPYA0KIjkYF3XhSY5iYpiEeAo5jXivnCxi6JUAzYZA7 06NwnJDsQijl09Ucjulchk3P3aJt12RqaVfz2CPyzswccRD68r94UMsx17QF+NQkDh Wl4B9uscWygnCCYaelanJ+aGFRUqTiuSTawIo7Nk=
Message-Id: <6.2.5.6.2.20121031071004.0a6e4fa0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 31 Oct 2012 07:14:35 -0700
To: Phillip Hallam-Baker 
From: SM 
In-Reply-To: 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 14:15:38 -0000

Hi Phillip,
At 05:20 31-10-2012, Phillip Hallam-Baker wrote:
>the chances of regulation at 100%. In a few years those guys are 
>going to be writing standards with more lawyers than engineers 
>sitting in the room unless they have a sudden change of mindset.

Yes.

>So rather than framing the argument as 'is Webfinger damaging 
>privacy' I would ask 'is Web finger helping people to do the sorts 
>of things that users want without unexpected privacy side effects'.

That may be a better question.

Regards,
-sm 


From sm@resistor.net  Wed Oct 31 07:18:02 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39E721F8484 for ; Wed, 31 Oct 2012 07:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.478
X-Spam-Level: 
X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 TGfjjZ2qX+ml for ; Wed, 31 Oct 2012 07:18:02 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 777B521F847C for ; Wed, 31 Oct 2012 07:18:02 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q9VEFGKX015220; Wed, 31 Oct 2012 07:15:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351692925; bh=Qy4ntYdcwzntVZvBXARTbt/IwfJ1WLWJPK2fLvt7pG4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PXcS00TaJiRH8nCWbXqBmdkjQsspYIF96omKmWwORD2Xng7xU3Lct4CuwlVVjyPsg tS3zzSsQTLIvevElEVaO57hyghViI0GGz8NZl+NCG1GOvPUJMfkYBhXI1SAp5p8kxq l6bRHq7wFHXculcDf/VOo23r4xKAbU30OuhgJ+Mg=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351692925; i=@resistor.net; bh=Qy4ntYdcwzntVZvBXARTbt/IwfJ1WLWJPK2fLvt7pG4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=K2+eYhHv1smJRbCNIRr+vtxmnm4Rouw33bdvCjCFB1U94qXs/EFiSFyRTpVr6kccY iGrx7aRkVi0wnGGxMuiqtp0AE536nRTnMB76bzZekF1Qe42nPZ1jXbmdLU7F+hbtBz OJODfnIYdA+QivacsKoRil0vrP221/4jVdM9vnc4=
Message-Id: <6.2.5.6.2.20121031064926.0a6e4d10@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 31 Oct 2012 07:09:06 -0700
To: Stephen Farrell 
From: SM 
In-Reply-To: <5090EC8D.5050900@cs.tcd.ie>
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net> <5090EC8D.5050900@cs.tcd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 14:18:03 -0000

Hi Stephen,
At 02:17 31-10-2012, Stephen Farrell wrote:
>I kind of agree, but am also sympathetic to Paul's position.

Paul made some good arguments.

>If, as a document editor, he's being asked to put in stuff
>with which he's not fully in agreement, (which seems to be the
>case here, roughly), then "send text" seems to me like a pretty
>reasonable response from any wg document editor in that position
>who's willing to do the right thing and add text for which
>there's rough consensus even if they don't personally like it.

Yes.

>If none of us that are commenting, (incl. me) have the energy
>to suggest some text then that's also significant.

Agreed.

>Maybe we should try get a few folks who care about this into
>a huddle in ATL if some of those who're interested will be
>there? (If the Sunday reception worked then on Monday morning
>Paul might be able to say something more than "we have insane
>privacy nuts" :-)

As the privacy nut, let me try to step back.  The argument up to now 
has been that there are privacy concerns.  I understand that it is 
difficult to address that as it comes out as too broad.  I'll try to 
post some text to the privacy list as a starting point.

Regards,
-sm 


From hallam@gmail.com  Wed Oct 31 07:53:10 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD7621F8818 for ; Wed, 31 Oct 2012 07:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpcSsOTa-KsX for ; Wed, 31 Oct 2012 07:53:09 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 805FD21F84EA for ; Wed, 31 Oct 2012 07:53:09 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id v19so1625466obq.31 for ; Wed, 31 Oct 2012 07:53:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xsmetHMk2Qo71YesIfizVGES6J+eplJ1SNvfSYTTKHg=; b=qjAYMKbYtKq9Ponin8CiKfq2pfVSF8Sd8iIsNTFsPAT9JUjUBs2dEOhGYs79s/qiuD 8Rg0y87v+WMMpYyVm5lFhUBC4/4WcWBQjI+yOQBarrtzlZMZbhXbqD6xoKyWlpfJM2eU pwdF73vczLv6lIWZfQvJpvC4tL4UjUaoWhJL20tbTpHKHUSFANXnZRoGcK1qM5X4TBVJ nX2WhBWNoUJb/RVH2rlyHLG7iXscBDAp4XmQBElHmcKpmAZgSFwEeYLW6pw29498gsK4 DXiLMpCoqBjvWvN9kjI5f9jS9vHk/AP1SYku5v6dbwSvfqDktRYgZyk3380bf4j+uyhd ek3w==
MIME-Version: 1.0
Received: by 10.182.152.97 with SMTP id ux1mr30899092obb.13.1351695188993; Wed, 31 Oct 2012 07:53:08 -0700 (PDT)
Received: by 10.76.27.103 with HTTP; Wed, 31 Oct 2012 07:53:08 -0700 (PDT)
In-Reply-To: <6.2.5.6.2.20121031071004.0a6e4fa0@resistor.net>
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net>  <6.2.5.6.2.20121031071004.0a6e4fa0@resistor.net>
Date: Wed, 31 Oct 2012 10:53:08 -0400
Message-ID: 
From: Phillip Hallam-Baker 
To: SM 
Content-Type: multipart/alternative; boundary=f46d04462c0a95a5c904cd5c0f1f
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 14:53:10 -0000

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

On Wed, Oct 31, 2012 at 10:14 AM, SM  wrote:

> Hi Phillip,
>
> At 05:20 31-10-2012, Phillip Hallam-Baker wrote:
>
>> the chances of regulation at 100%. In a few years those guys are going to
>> be writing standards with more lawyers than engineers sitting in the room
>> unless they have a sudden change of mindset.
>>
>
> Yes.
>
>
>  So rather than framing the argument as 'is Webfinger damaging privacy' I
>> would ask 'is Web finger helping people to do the sorts of things that
>> users want without unexpected privacy side effects'.
>>
>
> That may be a better question.
>

Indeed, one of the pathologies here is that the apps people want to do X
but their proposal has a few minor security issues. So they are told they
can't do X and instead they work out that due to various holes in the
application layer they can do Y which is almost as good as X as far as they
are concerned but has infinitely more security issues.

So the blame here is not all on one side.


One of the reasons I wrote my draft on HTTP auth is that I see much of this
same pathology. The security side wants something that is perfect, the apps
people don't see that the security issues are relevant to their users. So
they give up on doing things through the channel with security expertise
and go find a different channel.

It is worth pointing out that if certain people had their way long long ago
(i.e. me, most others in the Web security area) then TLS would not have
happened because transport layer was the wrong place for security. Well it
was certainly a botch job at first but that might have been the only way
something could have been deployed.

http://tools.ietf.org/id/draft-hallambaker-httpauth-01.xml


A common refrain at OWASP was 'you are not going to fix Javascript because
people want to use it'. What was not really addressed was WHO wants to use
it. The fact that facebook wants to use it is of precisely zero interest to
me because I really have no use for that site. and I certainly could not
give a hoot if EU legislation ruins the business plans of certain Web
advertisers.

I have already turned off plugins (other than PDF) except for specific
sites. I am about to do the same for Javascript (but after I send this
email). What I think most users would be happiest with is a scheme that
allows that type of intelligence to be delivered to them from a third party
source that specializes in security and can work out whether a site is
likely malicious or clueless.

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

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



On Wed, Oct 31, 2012 at 10:14 AM, SM <sm@=
resistor.net> wrote:

Hi Phillip,


At 05:20 31-10-2012, Phillip Hallam-Baker wrote:



the chances of regulation at 100%. In a few years those guys are going to b=
e writing standards with more lawyers than engineers sitting in the room un=
less they have a sudden change of mindset.





Yes.






So rather than framing the argument as 'is Webfinger damaging privacy&#=
39; I would ask 'is Web finger helping people to do the sorts of things=
 that users want without unexpected privacy side effects'.





That may be a better question.

Indeed, =
one of the pathologies here is that the apps people want to do X but their =
proposal has a few minor security issues. So they are told they can't d=
o X and instead they work out that due to various holes in the application =
layer they can do Y which is almost as good as X as far as they are concern=
ed but has infinitely more security issues.



So the blame here is not all on one side.

One of the reasons I wrote my draft on HTTP auth=
 is that I see much of this same pathology. The security side wants somethi=
ng that is perfect, the apps people don't see that the security issues =
are relevant to their users. So they give up on doing things through the ch=
annel with security expertise and go find a different channel.



It is worth pointing out that if certain people had the=
ir way long long ago (i.e. me, most others in the Web security area) then T=
LS would not have happened because transport layer was the wrong place for =
security. Well it was certainly a botch job at first but that might have be=
en the only way something could have been deployed.





A common refrain at OW=
ASP was 'you are not going to fix Javascript because people want to use=
 it'. What was not really addressed was WHO wants to use it. The fact t=
hat facebook wants to use it is of precisely zero interest to me because I =
really have no use for that site. and I certainly could not give a hoot if =
EU legislation ruins the business plans of certain Web advertisers.



I have already turned off plugins (other than PDF) exce=
pt for specific sites. I am about to do the same for Javascript (but after =
I send this email). What I think most users would be happiest with is a sch=
eme that allows that type of intelligence to be delivered to them from a th=
ird party source that specializes in security and can work out whether a si=
te is likely malicious or clueless.



-- 
Website: http://h=
allambaker.com/



--f46d04462c0a95a5c904cd5c0f1f--

From stpeter@stpeter.im  Wed Oct 31 08:52:53 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EFF21F8475 for ; Wed, 31 Oct 2012 08:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WARaIRJ2KoVV for ; Wed, 31 Oct 2012 08:52:52 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 25B9521F846F for ; Wed, 31 Oct 2012 08:52:52 -0700 (PDT)
Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CC3B74011B; Wed, 31 Oct 2012 09:56:15 -0600 (MDT)
Message-ID: <50914952.7090100@stpeter.im>
Date: Wed, 31 Oct 2012 09:52:50 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: webfinger@googlegroups.com
References:  <22D799A3-D79C-47C4-B9B3-3FFD5146B35D@gmail.com>
In-Reply-To: <22D799A3-D79C-47C4-B9B3-3FFD5146B35D@gmail.com>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: public-fedsocweb@w3.org, "apps-discuss@ietf.org" , Dick Hardt 
Subject: Re: [apps-discuss] WebFinger compromises
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 15:52:53 -0000

[ +cc apps-discuss@ietf.org given that the spec is now an
Internet-Draft... ]

On 10/31/12 9:48 AM, Dick Hardt wrote:
> +1 on everything. 
> 
> A simple, easy to understand spec that solves the major use cases
> released soon is far superior to kitchen sink spec that solves all use
> cases that is released in a year.
> 
> JSON only (if that is not obvious, you need to write some code this decade)
> 
> 1 round trip vs 2 round. Pick one that is simple to implement. Let's not
> get caught up in optimization. Brad's comments below seem sane (as usual)
> 
> -- Dick
> 
> 
> On Oct 31, 2012, at 12:45 AM, Brad Fitzpatrick  > wrote:
> 
>> To everybody who recently saw me rant about WebFinger in person
>> recently, hello again.
>>
>> To everybody else, a brief summary:
>>
>> -- I was an early WebFinger evangelist. I remember discussing it at
>> conferences for years before it sorta became a thing. I think I even
>> named it?
>>
>> -- I added Google's WebFinger support
>> (https://groups.google.com/group/webfinger/msg/e8df6402708841ea)
>>
>> -- I think it's critically important for the Internet to preserve
>> user@host.com  hierarchical identifiers before
>> email gets too passe and we're stuck with single-namespaced walled
>> gardens.  It's on us to make email-looking identifiers more useful to
>> compete with all the latest proprietary silo hotness, before the
>> people of the internet no longer recognize them.
>>
>> (trying to establish that I'm a friend here)
>>
>> That said,
>>
>> -- this is the slowest moving community ever (I accept part of the
>> blame here)
>>
>> -- can we please stop changing things?
>>
>> -- JSON, XRD, great, whatever.  But let's just pick one.  If JSON is
>> now the hotness, let's pick *only* JSON.  Specs that say "X is
>> required but you can maybe do Y if you want to" just reek of political
>> compromise to gain a certain party's favor.  Look at OpenID 2.0.  (I
>> remember being sad about those political moves too, but I had lost the
>> energy to fight)
>>
>> -- My recommendation: just remove all mention of XRD from the latest
>> WebFinger spec.  Yes, this is counter to my "please stop changing
>> things" bullet earlier.  But WebFinger has a better chance of success
>> if it's a simple spec.  And you're not breaking compatibility with
>> anybody because *nobody uses WebFinger*.
>>
>> -- 1 round trip, 2 round trips. Don't really care. 2 round trips keeps
>> the spec simpler and the 1st will be highly cacheable (Expires:
>> weeks), so it's 1 round trip in practice, but I won't fight (too much)
>> *optional* parameters in the 1st request to possibly skip the 2nd
>> request.  It worries me, though.  I'd rather see that optimization
>> added in a subsequent version of the spec, so all 1.0 implementations
>> have then shown that they're capable of performing the base algorithm.
>>  I worry that too many servers will implement the optimization and
>> then lazy clients will become pervasive which only do one round trip,
>> thus making the "optional" optimization now de facto required for
>> servers.  So I'd really rather drop that from the spec too.  Let's add
>> it only later, once it's shown to be needed.  As is, clients could
>> even fire off two HTTP requests in parallel to reduce latency, one for
>> host-meta and one optimistically for the presumed host-meta location
>> in cases of big hosts that rarely change, or expired cached host-meta
>> documents.
>>
>> I will continue to fight for Google's WebFinger support, but I'm not
>> the only one losing patience.
>>
>> Everybody please hurry up, simplify, then hurry up.  I'll help however
>> I can.  I'm not sure whether this was helpful.
>>
>> - Brad
>>
>> (If any of the above is offensive to my employer, I'm speaking as myself.)
>>
> 


-- 
Peter Saint-Andre
https://stpeter.im/



From jasnell@gmail.com  Wed Oct 31 09:32:04 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC60721F85D2 for ; Wed, 31 Oct 2012 09:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.39
X-Spam-Level: 
X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.208,  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 aa1jlKSbe+f7 for ; Wed, 31 Oct 2012 09:32:02 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8F121F8586 for ; Wed, 31 Oct 2012 09:32:02 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id v19so1755205obq.31 for ; Wed, 31 Oct 2012 09:32:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t/sd9VNih8J2rbuYebMEC/K8+DW+2K2AkHPUE4VYf8w=; b=Rd/YYFPqwzZAqW4iPmsyIZgl8pNfGcSwsE+J9noVouIc6/E8gqUk6NDwmuGKm2QET1 lSpoWvCYsO784d06clAuKKsW8CXE1roMbBqXfHRxMesCtmJDYt0wrf2S8FgEFPQjYM3p t8z31/p34L1RTgrmbKsuo+x6jblL4GZiuBKpREOBYw49QN3mM7E3A/ceUd02wrdX/DXc +jeCb0SpjT2VpTdGLMUf6jxCykThRnI6ixx9TtlFLumqcgppvj6tbnjuFreVcadAIZ+V 66fedAyxR8Gw2DV0AyMWWAAKPMqmT5zcNKfY0VFS5LLVFlh8/nZn0NGVTNtNHcMOVgA6 0ndQ==
MIME-Version: 1.0
Received: by 10.182.18.196 with SMTP id y4mr27273723obd.52.1351701121583; Wed, 31 Oct 2012 09:32:01 -0700 (PDT)
Received: by 10.76.68.37 with HTTP; Wed, 31 Oct 2012 09:32:01 -0700 (PDT)
Received: by 10.76.68.37 with HTTP; Wed, 31 Oct 2012 09:32:01 -0700 (PDT)
In-Reply-To: <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com>
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com>
Date: Wed, 31 Oct 2012 09:32:01 -0700
Message-ID: 
From: James M Snell 
To: "Paul E. Jones" 
Content-Type: multipart/alternative; boundary=f46d04388ef531cb5404cd5d711c
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 16:32:05 -0000

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

Ordinarily I would provide a suggestion of alternative text but I've been
tied up on a few other matters. That said, a few notes...

The basic protocol itself is fine.. the way that the current resource
parameter is defined, I could in theory use a uri scheme that allows me to
hash the identifier without requiring changes to the basic protocol itself.
That itself is not so much of a problem.

What is a problem, however, is that you've mentioned a few times that TLS
could provide the necessary privacy control but there does not appear to be
any mention at all of TLS within the specification document. It really
should be called out as a specific recommendation in the text.

I also note that while you do cover some of the privacy issues in the
security considerations, one point could stand to be made clearer:
WebFinger should only be used to expose information the subject has
explicitly opted in to be shared. Or put another way, WebFinger MUST NOT be
used to provide information to any party the subject has not explicitly
authorized. This is loosely implied by the current text but, unless I
missed it, you never just come out and say it.

A couple other points that come to mind when re-reading the security
considerations...

1. There is nothing said about the validity and authenticity of the data
returned. There does not have to be an exhaustive discussion on this
matter, of course, but currently the protocol makes no guarantees and
provides no mechanisms for assuring that the information returned for a
given user is authentic, authoritative or valid in any way. It should at
least be noted that such mechanisms are out of the scope of the WebFinger
protocol.

2. A cryptographic hashed identifier could help prevent correlation style
breaches in privacy if the hash is generated based on a shared secret key
tied to the requesters authenticated identity. That is, if a WebFinger
server requires authentication to request data, the requester can generate
an hmac, for instance, using a shared secret key and specify that within
the URI request. Used in combination with TLS, for example, this would
provide a reasonable assurance of privacy between the requester and the
service provider, keeping prying eyes in the middle from knowing whose
information is being requested. Again, it is possible to do with currently
without any changes to the WF protocol as defined so no normative changes
would be necessary, but it might be worthwhile to draw out as an
informative example.

- James
 On Oct 30, 2012 5:48 PM, "Paul E. Jones"  wrote:

> That's not an entirely true statement.  See:
> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02#section-11
>
> Question is whether that is sufficient.  Thus far, I've not received any
> additional text.
>
> Paul
>
> > -----Original Message-----
> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> > bounces@ietf.org] On Behalf Of SM
> > Sent: Tuesday, October 30, 2012 1:19 PM
> > To: Hannes Tschofenig
> > Cc: apps-discuss@ietf.org
> > Subject: Re: [apps-discuss] webfinger privacy question/suggestion
> >
> > At 03:16 30-10-2012, Hannes Tschofenig wrote:
> > >Have a look at: http://tools.ietf.org/html/draft-iab-privacy-
> > considerations-04
> >
> > Hmm, that draft was mentioned several months ago [1].
> >
> > >I have raised these privacy issues already last year. My comments got
> > ignored.
> >
> > The following question was asked around 11 months ago [2]:
> >
> >    "What are you planning to do to ensure the draft properly addresses
> >     security, privacy, and netiquette issues?"
> >
> > The current plan seems to be: do nothing.
> >
> > Regards,
> > -sm
> >
> > 1. http://www.ietf.org/mail-archive/web/apps-
> > discuss/current/msg04747.html
> > 2. http://www.ietf.org/mail-archive/web/apps-
> > discuss/current/msg03804.html
> >
> > _______________________________________________
> > 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
>

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


Ordinarily I would provide a suggestion of alternative text =
but I've been tied up on a few other matters. That said, a few notes...=



The basic protocol itself is fine.. the way that the current=
 resource parameter is defined, I could in theory use a uri scheme that all=
ows me to hash the identifier without requiring changes to the basic protoc=
ol itself. That itself is not so much of a problem. 



What is a problem, however, is that you've mentioned a f=
ew times that TLS could provide the necessary privacy control but there doe=
s not appear to be any mention at all of TLS within the specification docum=
ent. It really should be called out as a specific recommendation in the tex=
t. 



I also note that while you do cover some of the privacy issu=
es in the security considerations, one point could stand to be made clearer=
: WebFinger should only be used to expose information the subject has expli=
citly opted in to be shared. Or put another way, WebFinger MUST NOT be used=
 to provide information to any party the subject has not explicitly authori=
zed. This is loosely implied by the current text but, unless I missed it, y=
ou never just come out and say it.



A couple other points that come to mind when re-reading the =
security considerations...


1. There is nothing said about the validity and authenticity=
 of the data returned. There does not have to be an exhaustive discussion o=
n this matter, of course, but currently the protocol makes no guarantees an=
d provides no mechanisms for assuring that the information returned for a g=
iven user is authentic, authoritative or valid in any way. It should at lea=
st be noted that such mechanisms are out of the scope of the WebFinger prot=
ocol.



2. A cryptographic hashed identifier could help prevent corr=
elation style breaches in privacy if the hash is generated based on a share=
d secret key tied to the requesters authenticated identity. That is, if a W=
ebFinger server requires authentication to request data, the requester can =
generate an hmac, for instance, using a shared secret key and specify that =
within the URI request. Used in combination with TLS, for example, this wou=
ld provide a reasonable assurance of privacy between the requester and the =
service provider, keeping prying eyes in the middle from knowing whose info=
rmation is being requested. Again, it is possible to do with currently with=
out any changes to the WF protocol as defined so no normative changes would=
 be necessary, but it might be worthwhile to draw out as an informative exa=
mple.



- James




On Oct 30, 2012 5:48 PM, "Paul E. Jones&quo=
t; <paulej@packetizer.com&g=
t; wrote:

That's not an entirely true statement. =C2=A0See:

http://tools.ietf.org/html/draft-ietf-appsawg-webf=
inger-02#section-11



Question is whether that is sufficient. =C2=A0Thus far, I've not receiv=
ed any

additional text.



Paul



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

> From: apps-discuss-bo=
unces@ietf.org [mailto:apps-discuss-

> bounces@ietf.org] On Behalf Of=
 SM

> Sent: Tuesday, October 30, 2012 1:19 PM

> To: Hannes Tschofenig

> Cc: apps-discuss@ietf.org=


> Subject: Re: [apps-discuss] webfinger privacy question/suggestion

>

> At 03:16 30-10-2012, Hannes Tschofenig wrote:

> >Have a look at: http://tools.ietf.org/html/draft-iab-privacy-=


> considerations-04

>

> Hmm, that draft was mentioned several months ago [1].

>

> >I have raised these privacy issues already last year. My comments =
got

> ignored.

>

> The following question was asked around 11 months ago [2]:

>

> =C2=A0 =C2=A0"What are you planning to do to ensure the draft pro=
perly addresses

> =C2=A0 =C2=A0 security, privacy, and netiquette issues?"

>

> The current plan seems to be: do nothing.

>

> Regards,

> -sm

>

> 1. http://www.ietf.org/mail-archive/web/apps-

> discuss/current/msg04747.html

> 2. http://www.ietf.org/mail-archive/web/apps-

> discuss/current/msg03804.html

>

> _______________________________________________

> 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




--f46d04388ef531cb5404cd5d711c--

From paulej@packetizer.com  Wed Oct 31 12:13:35 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FE721F8482 for ; Wed, 31 Oct 2012 12:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.258
X-Spam-Level: 
X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.341,  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 rFUXQ6-VW1Kn for ; Wed, 31 Oct 2012 12:13:34 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id CCA5C21F8471 for ; Wed, 31 Oct 2012 12:13:33 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9VJDWLI017678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Oct 2012 15:13:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351710813; bh=CHfuBcEwnuP3LomtJSn/0N8ko1j2HuOKcQZoM4hiefE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=MdOoKy6fAwKCnoiWUNLoKwndmjY2gipMMCQDLiCIwlmitsKiWX2tJyVoj2hti/FKW F8PtxNlo/o/t89B9I3hRWYb8ONWrr/QO315S2oPzEmteaPEDkm1+kARaPdeOKFr46F LCNIXElWGZkJGMu4pjRhU8Ida3bBclYwan7EXPcU=
From: "Paul E. Jones" 
To: "'SM'" 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net>
In-Reply-To: <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net>
Date: Wed, 31 Oct 2012 15:13:37 -0400
Message-ID: <000f01cdb79b$d4edf1b0$7ec9d510$@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: AQFLsjjsRNcR0N0rPY8CMxV87xY2TQDs4XE+AookvBECZOavfwEZKXCrAUbsN9ACb4OCXQI3fPywAU9o2S8CEskaJQFYBz0XmErjggA=
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 19:13:35 -0000

> >Question is whether that is sufficient.  Thus far, I've not received
> >any additional text.
> 
> As far as I am aware the IETF Stream is not an open source project where
> one does "send patch".  I read a draft and I comment about it.  There
> isn't any requirement for me to "send text".  It obviously does not help
> the working group to resolve issues if I do not put in the effort to
> "send text".  However, I see the effort as one-sided if "send text" is
> the only argument to address an issue.

No, but it is an open standards process where anyone can contribute text.
I've contributed text and I've tried to address the issues raised w.r.t.
privacy.  If it is not sufficient, then I need to be told what to put in
there.
 
> It was mentioned that Google+ uses Webfinger [1].  It was argued that
> the right approach is what Google is going with Google+.  Nobody has
> been able to find where the documentation is.

I do not know that it is documented.  However, I described how it works.
Just use your gmail.com ID and you can query Google's servers using that URL
I posted earlier.  It will show some of the content you had marked as
"Public" via Google+.
 
>  From Section 11 of the draft:
> 
>    "Service providers and users should be aware that placing information
>     on the Internet accessible through WebFinger means that any user can
>     access that information."
> 
> I strongly doubt that service providers will be overtly concerned about
> placing information about their users on the Internet.

Yeah, likely not.  This is why I don't think having extensive material in a
WF draft will make any difference.  A few comments on privacy make sense,
but a more complete treatment of the subject is needed elsewhere.

>    "While WebFinger can be an extremely useful tool for allowing quick
>     and easy access to one's avatar, blog, or other personal information,
>     users should understand the risks, too."
> 
> The user can only make that decision if he/she is provided with enough
> information.  I rewrote the following sentence:
> 
>    If one does not wish to share certain information with the world, one
>    must not use any service supporting WebFinger.

I think we should address post making info available and accessing it.  How
is this:

    If one does not wish to share certain information with the world,
    do not allow that information to be freely accessible through
    WebFinger and do not use any service supporting WebFinger.

That said, I do think it's going a bit far.  Following this logic, we should
go back and revise the DNS specs, too, to say "if one does not want the
world to know what one is accessing, do not use DNS."  It's the same issue,
really.
 
> Quoting draft-iab-privacy-considerations-04:
> 
>    "Correlation is the combination of various pieces of information
>     related to an individual.  Correlation can defy people's
> expectations
>     of the limits of what others know about them.  It can increase the
>     power that those doing the correlating have over individuals as well
>     as correlators' ability to pass judgment, threatening individual
>     autonomy and reputation."
> 
> Is that an issue with respect to Webfinger?

This can certainly be said of Google advertising, for example.  It can be
said of any web user habits, your email exchanges with me, blog posts,
comments on web sites, etc.  WebFinger is just one more service like so many
others.  The only thing that is perhaps strikingly different is that with
WebFinger, one is publishing information about themselves in a concentrated
place.  So, rather than visiting my home page to get some contact info, one
can query it via WebFinger in a nice automated way.  This can be abused, of
course, but so can posting profile information in one's Facebook account.

Paul



From evan@status.net  Wed Oct 31 12:25:33 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7C121F8C49 for ; Wed, 31 Oct 2012 12:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZleTjohxYAf for ; Wed, 31 Oct 2012 12:25:32 -0700 (PDT)
Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id D85AF21F8B80 for ; Wed, 31 Oct 2012 12:25:31 -0700 (PDT)
Received: from [192.168.0.101] (modemcable065.65-22-96.mc.videotron.ca [96.22.65.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 376258D6A9C for ; Wed, 31 Oct 2012 19:36:49 +0000 (UTC)
Message-ID: <50917B1E.1040508@status.net>
Date: Wed, 31 Oct 2012 15:25:18 -0400
From: Evan Prodromou 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: IETF Apps Discuss 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070502060408000602070402"
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 19:25:33 -0000

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

On 12-10-31 12:32 PM, James M Snell wrote:
> What is a problem, however, is that you've mentioned a few times that 
> TLS could provide the necessary privacy control but there does not 
> appear to be any mention at all of TLS within the specification 
> document. It really should be called out as a specific recommendation 
> in the text. 
>
> I also note that while you do cover some of the privacy issues in the 
> security considerations, one point could stand to be made clearer: 
> WebFinger should only be used to expose information the subject has 
> explicitly opted in to be shared. Or put another way, WebFinger MUST 
> NOT be used to provide information to any party the subject has not 
> explicitly authorized. This is loosely implied by the current text 
> but, unless I missed it, you never just come out and say it.
>
That seems exceptionally strong. It also doesn't reflect current 
practice for Web services which often provide profile pages or other 
human-readable endpoints that include by default at least some of the 
profile data provided by the user.

The best services let users choose what profile data to share with whom 
(show my phone number only to friends and family) and most just let the 
user choose whether to share the data at all or not.

For machine-readable endpoints, I think it's untenable. I can say right 
now that there's no way I'll /ever/ create user interfaces to ask that a 
user explicitly opt in to e.g. publishing their Salmon protocol endpoint.

Maybe a better way to say it is: the implementor SHOULD let users opt 
out of sharing personally-identifying information, or data that 
correlates to other accounts or identities, and SHOULD inform users that 
the data is being shared in e.g. a terms of service agreement.
> 2. A cryptographic hashed identifier could help prevent correlation 
> style breaches in privacy if the hash is generated based on a shared 
> secret key tied to the requesters authenticated identity. That is, if 
> a WebFinger server requires authentication to request data, the 
> requester can generate an hmac, for instance, using a shared secret 
> key and specify that within the URI request. Used in combination with 
> TLS, for example, this would provide a reasonable assurance of privacy 
> between the requester and the service provider, keeping prying eyes in 
> the middle from knowing whose information is being requested. Again, 
> it is possible to do with currently without any changes to the WF 
> protocol as defined so no normative changes would be necessary, but it 
> might be worthwhile to draw out as an informative example.
James, could you give an explicit example of the problem and what the 
solution is? I see at least two or three things here that you're laying out.

-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


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


  
    
  
  
    
On 12-10-31 12:32 PM, James M Snell
      wrote:

    

    
What is a problem, however, is that you've mentioned a
      few times that TLS could provide the necessary privacy control but
      there does not appear to be any mention at all of TLS within the
      specification document. It really should be called out as a
      specific recommendation in the text. 

    

      
I also note that while you do cover some of the
        privacy issues in the security considerations, one point could
        stand to be made clearer: WebFinger should only be used to
        expose information the subject has explicitly opted in to be
        shared. Or put another way, WebFinger MUST NOT be used to
        provide information to any party the subject has not explicitly
        authorized. This is loosely implied by the current text but,
        unless I missed it, you never just come out and say it.

    

    That seems exceptionally strong. It also doesn't reflect current
    practice for Web services which often provide profile pages or other
    human-readable endpoints that include by default at least some of
    the profile data provided by the user.

    

    The best services let users choose what profile data to share with
    whom (show my phone number only to friends and family) and most just
    let the user choose whether to share the data at all or not.

    

    For machine-readable endpoints, I think it's untenable. I can say
    right now that there's no way I'll ever create user
    interfaces to ask that a user explicitly opt in to e.g. publishing
    their Salmon protocol endpoint.

    

    Maybe a better way to say it is: the implementor SHOULD let users
    opt out of sharing personally-identifying information, or data that
    correlates to other accounts or identities, and SHOULD inform users
    that the data is being shared in e.g. a terms of service agreement.

    
2. A cryptographic hashed identifier could help
      prevent correlation style breaches in privacy if the hash is
      generated based on a shared secret key tied to the requesters
      authenticated identity. That is, if a WebFinger server requires
      authentication to request data, the requester can generate an
      hmac, for instance, using a shared secret key and specify that
      within the URI request. Used in combination with TLS, for example,
      this would provide a reasonable assurance of privacy between the
      requester and the service provider, keeping prying eyes in the
      middle from knowing whose information is being requested. Again,
      it is possible to do with currently without any changes to the WF
      protocol as defined so no normative changes would be necessary,
      but it might be worthwhile to draw out as an informative example.

    James, could you give an explicit example of the problem and what
    the solution is? I see at least two or three things here that you're
    laying out.

    

    -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

  


--------------070502060408000602070402--

From paulej@packetizer.com  Wed Oct 31 12:26:43 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C9E21F87F3 for ; Wed, 31 Oct 2012 12:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.275
X-Spam-Level: 
X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.324,  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 XoMHjHojeU6z for ; Wed, 31 Oct 2012 12:26:43 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C292F21F87FE for ; Wed, 31 Oct 2012 12:26:42 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9VJQc0k018271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Oct 2012 15:26:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351711599; bh=nLnCN7g5AfFuvYNrd7v5BtMDFB10LIK6TG35HLtXGsY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=QJmsdA8lMRCoELAMtFaFCU/CKgwTqXW8ZK10TfC06BQxJAtlLJFrWrNZXdiNYNTYV x6cVOiXgPCvhVwXuv2RJ3JN/MF/qXlv6QKb7b19O1GpP+viKHu2pCkuz9MWfmJuYKb JCPEzccVoMAVbeqgUrkeVwL68kq/nTw7lmXq0zF0=
From: "Paul E. Jones" 
To: "'Stephen Farrell'" , "'SM'" 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net> <5090EC8D.5050900@cs.tcd.ie>
In-Reply-To: <5090EC8D.5050900@cs.tcd.ie>
Date: Wed, 31 Oct 2012 15:26:43 -0400
Message-ID: <001e01cdb79d$a9a231e0$fce695a0$@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: AQFLsjjsRNcR0N0rPY8CMxV87xY2TQDs4XE+AookvBECZOavfwEZKXCrAUbsN9ACb4OCXQI3fPywAU9o2S8CEskaJQFYBz0XAdg6dGKYPCmdwA==
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 19:26:43 -0000

Stephen,

> Maybe we should try get a few folks who care about this into a huddle in
> ATL if some of those who're interested will be there? (If the Sunday
> reception worked then on Monday morning Paul might be able to say
> something more than "we have insane privacy nuts" :-)

Now that was funny ...

I'll be around most of the week and would be happy to take whatever text
folks want to provide and insert it into the document.  I really am at a
loss for words on this.  I do not know what to write.  While I don't share
the same privacy concerns, I do respect those who have privacy concerns.

I don't think anyone is insane, though.  I tend to use exaggerated language,
but I'm really more down-to-earth than that language might suggest. ;-)

Paul



From paulej@packetizer.com  Wed Oct 31 14:38:01 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF22721F856E for ; Wed, 31 Oct 2012 14:38:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.289
X-Spam-Level: 
X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.309,  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 ceMVu2PibBD5 for ; Wed, 31 Oct 2012 14:38:00 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA4621F8566 for ; Wed, 31 Oct 2012 14:38:00 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9VLbufl026176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Oct 2012 17:37:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351719477; bh=wzzPIg5XP3YqJZ2S3uR+4oFr3OUqPSv34B5aYZ7Eook=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=LdAZ/UF7dLfZ1u/UOyljS2frwABIlMA9/sp0BXfX9tjpIow6H3zBGQtpNaAfLrfKp z6ORucaoLo4b4I37lCwXhESo0qw+K/FYADbGMuEWLcod/lBEnGR8XiGEhaUWrZjV/Q nyUVCgTAmUr86IIK/MC3LEKy2Z/b71BHgIqd1t0E=
From: "Paul E. Jones" 
To: "'James M Snell'" 
References: <508E66FB.4070708@cs.tcd.ie>	<0b3b01cdb61c$981dc600$c8595200$@packetizer.com>	<508F0870.9050402@cs.tcd.ie>	<0b9901cdb636$bf951480$3ebf3d80$@packetizer.com>	<508F2B78.2000006@cs.tcd.ie>	<0be001cdb64b$eb574560$c205d020$@packetizer.com>	<508FA55F.5020608@cs.tcd.ie>	<5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net>	<6.2.5.6.2.20121030093556.0a82b130@resistor.net>	<00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> 
In-Reply-To: 
Date: Wed, 31 Oct 2012 17:38:01 -0400
Message-ID: <005f01cdb7b0$010fc430$032f4c90$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0060_01CDB78E.79FF35A0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFLsjjsRNcR0N0rPY8CMxV87xY2TQDs4XE+AookvBECZOavfwEZKXCrAUbsN9ACb4OCXQI3fPywAU9o2S8CEskaJQIt3MI3mERiNoA=
Content-Language: en-us
Cc: 'IETF Apps Discuss' 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 21:38:01 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0060_01CDB78E.79FF35A0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

James,

=20

HTTPS is recommended and shown throughout the document.  We do not say =
TLS, as HTTPS implies that.

=20

In the security section at the end of =E2=80=9CService providers and =
users=E2=80=A6=E2=80=9D how about this?

=20

Further, WebFinger servers MUST NOT be used to provide any personal =
information to any party unless authorized by the person whose =
information is being shared.

=20

As a final paragraph in that section, how about this?

=20

Finally, a WebFinger server has no means of ensuring that information =
provided by a user is accurate.  Likewise, neither the server nor the =
client can be absolutely guaranteed that information has not been =
manipulated either at the server or along the communication path between =
the client and server.  Use of HTTPS helps to address some concerns with =
manipulation of information along the communication path, but it clearly =
cannot address issues where the server provided incorrect information, =
either due to being provided false information or due to malicious =
behavior on the part of the server administrator.  As with any =
information service available on the Internet, users should wary of =
information received from untrusted sources.

=20

Paul

=20

From: James M Snell [mailto:jasnell@gmail.com]=20
Sent: Wednesday, October 31, 2012 12:32 PM
To: Paul E. Jones
Cc: IETF Apps Discuss; Hannes Tschofenig; SM
Subject: Re: [apps-discuss] webfinger privacy question/suggestion

=20

Ordinarily I would provide a suggestion of alternative text but I've =
been tied up on a few other matters. That said, a few notes...

The basic protocol itself is fine.. the way that the current resource =
parameter is defined, I could in theory use a uri scheme that allows me =
to hash the identifier without requiring changes to the basic protocol =
itself. That itself is not so much of a problem.=20

What is a problem, however, is that you've mentioned a few times that =
TLS could provide the necessary privacy control but there does not =
appear to be any mention at all of TLS within the specification =
document. It really should be called out as a specific recommendation in =
the text.=20

I also note that while you do cover some of the privacy issues in the =
security considerations, one point could stand to be made clearer: =
WebFinger should only be used to expose information the subject has =
explicitly opted in to be shared. Or put another way, WebFinger MUST NOT =
be used to provide information to any party the subject has not =
explicitly authorized. This is loosely implied by the current text but, =
unless I missed it, you never just come out and say it.

A couple other points that come to mind when re-reading the security =
considerations...

1. There is nothing said about the validity and authenticity of the data =
returned. There does not have to be an exhaustive discussion on this =
matter, of course, but currently the protocol makes no guarantees and =
provides no mechanisms for assuring that the information returned for a =
given user is authentic, authoritative or valid in any way. It should at =
least be noted that such mechanisms are out of the scope of the =
WebFinger protocol.

2. A cryptographic hashed identifier could help prevent correlation =
style breaches in privacy if the hash is generated based on a shared =
secret key tied to the requesters authenticated identity. That is, if a =
WebFinger server requires authentication to request data, the requester =
can generate an hmac, for instance, using a shared secret key and =
specify that within the URI request. Used in combination with TLS, for =
example, this would provide a reasonable assurance of privacy between =
the requester and the service provider, keeping prying eyes in the =
middle from knowing whose information is being requested. Again, it is =
possible to do with currently without any changes to the WF protocol as =
defined so no normative changes would be necessary, but it might be =
worthwhile to draw out as an informative example.

- James

On Oct 30, 2012 5:48 PM, "Paul E. Jones"  wrote:

That's not an entirely true statement.  See:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02#section-11

Question is whether that is sufficient.  Thus far, I've not received any
additional text.

Paul

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of SM
> Sent: Tuesday, October 30, 2012 1:19 PM
> To: Hannes Tschofenig
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] webfinger privacy question/suggestion
>
> At 03:16 30-10-2012, Hannes Tschofenig wrote:
> >Have a look at: http://tools.ietf.org/html/draft-iab-privacy-
> considerations-04
>
> Hmm, that draft was mentioned several months ago [1].
>
> >I have raised these privacy issues already last year. My comments got
> ignored.
>
> The following question was asked around 11 months ago [2]:
>
>    "What are you planning to do to ensure the draft properly addresses
>     security, privacy, and netiquette issues?"
>
> The current plan seems to be: do nothing.
>
> Regards,
> -sm
>
> 1. http://www.ietf.org/mail-archive/web/apps-
> discuss/current/msg04747.html
> 2. http://www.ietf.org/mail-archive/web/apps-
> discuss/current/msg03804.html
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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


------=_NextPart_000_0060_01CDB78E.79FF35A0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


James,
 
HTTPS is recommended and shown throughout the document.=C2=A0 We do =
not say TLS, as HTTPS implies that.
 
In the security section at the end of =E2=80=9CService providers and =
users=E2=80=A6=E2=80=9D how about this?
 
Further, WebFinger servers MUST NOT be used to provide any personal =
information to any party unless authorized by the person whose =
information is being shared.
 
As a final paragraph in that section, how about =
this?
 
Finally, a WebFinger server has no means of ensuring that information =
provided by a user is accurate.=C2=A0 Likewise, neither the server nor =
the client can be absolutely guaranteed that information has not been =
manipulated either at the server or along the communication path between =
the client and server.=C2=A0 Use of HTTPS helps to address some concerns =
with manipulation of information along the communication path, but it =
clearly cannot address issues where the server provided incorrect =
information, either due to being provided false information or due to =
malicious behavior on the part of the server administrator.=C2=A0 As =
with any information service available on the Internet, users should =
wary of information received from untrusted =
sources.
 
Paul
 
From:=
 =
James M Snell [mailto:jasnell@gmail.com] 
Sent: Wednesday, =
October 31, 2012 12:32 PM
To: Paul E. Jones
Cc: IETF =
Apps Discuss; Hannes Tschofenig; SM
Subject: Re: =
[apps-discuss] webfinger privacy =
question/suggestion
 
Ordinarily I would provide a =
suggestion of alternative text but I've been tied up on a few other =
matters. That said, a few notes...
The basic protocol =
itself is fine.. the way that the current resource parameter is defined, =
I could in theory use a uri scheme that allows me to hash the identifier =
without requiring changes to the basic protocol itself. That itself is =
not so much of a problem. 
What is a problem, however, =
is that you've mentioned a few times that TLS could provide the =
necessary privacy control but there does not appear to be any mention at =
all of TLS within the specification document. It really should be called =
out as a specific recommendation in the text. 
I also =
note that while you do cover some of the privacy issues in the security =
considerations, one point could stand to be made clearer: WebFinger =
should only be used to expose information the subject has explicitly =
opted in to be shared. Or put another way, WebFinger MUST NOT be used to =
provide information to any party the subject has not explicitly =
authorized. This is loosely implied by the current text but, unless I =
missed it, you never just come out and say it.
A couple =
other points that come to mind when re-reading the security =
considerations...
1. There is nothing said about the =
validity and authenticity of the data returned. There does not have to =
be an exhaustive discussion on this matter, of course, but currently the =
protocol makes no guarantees and provides no mechanisms for assuring =
that the information returned for a given user is authentic, =
authoritative or valid in any way. It should at least be noted that such =
mechanisms are out of the scope of the WebFinger =
protocol.
2. A cryptographic hashed identifier could =
help prevent correlation style breaches in privacy if the hash is =
generated based on a shared secret key tied to the requesters =
authenticated identity. That is, if a WebFinger server requires =
authentication to request data, the requester can generate an hmac, for =
instance, using a shared secret key and specify that within the URI =
request. Used in combination with TLS, for example, this would provide a =
reasonable assurance of privacy between the requester and the service =
provider, keeping prying eyes in the middle from knowing whose =
information is being requested. Again, it is possible to do with =
currently without any changes to the WF protocol as defined so no =
normative changes would be necessary, but it might be worthwhile to draw =
out as an informative example.
- =
James
On Oct 30, 2012 5:48 PM, =
"Paul E. Jones" <paulej@packetizer.com> =
wrote:
That's not an entirely true =
statement.  See:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger=
-02#section-11

Question is whether that is sufficient. =
 Thus far, I've not received any
additional =
text.

Paul

> -----Original Message-----
> From: =
apps-discuss-bounces@ietf.o=
rg [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of =
SM
> Sent: Tuesday, October 30, 2012 1:19 PM
> To: Hannes =
Tschofenig
> Cc: apps-discuss@ietf.org
> =
Subject: Re: [apps-discuss] webfinger privacy =
question/suggestion
>
> At 03:16 30-10-2012, Hannes =
Tschofenig wrote:
> >Have a look at: http://tools.ietf.org/html/draft-iab-privacy-
&g=
t; considerations-04
>
> Hmm, that draft was mentioned =
several months ago [1].
>
> >I have raised these privacy =
issues already last year. My comments got
> =
ignored.
>
> The following question was asked around 11 =
months ago [2]:
>
>    "What are you planning =
to do to ensure the draft properly addresses
>     =
security, privacy, and netiquette issues?"
>
> The =
current plan seems to be: do nothing.
>
> Regards,
> =
-sm
>
> 1. http://www.ietf.org/mail-archive/web/apps-
> =
discuss/current/msg04747.html
> 2. http://www.ietf.org/mail-archive/web/apps-
> =
discuss/current/msg03804.html
>
> =
_______________________________________________
> apps-discuss =
mailing list
> apps-discuss@ietf.org
> =
https://www.ietf.org/mailman/listinfo/apps-discuss<=
br>
_______________________________________________
apps-discuss =
mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<=
o:p>

------=_NextPart_000_0060_01CDB78E.79FF35A0--


From jasnell@gmail.com  Wed Oct 31 14:39:13 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF1A21F85A8 for ; Wed, 31 Oct 2012 14:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.431
X-Spam-Level: 
X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=0.167,  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 nOdP7mEXZOu3 for ; Wed, 31 Oct 2012 14:39:12 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDB021F858B for ; Wed, 31 Oct 2012 14:39:12 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 9so3166926iec.31 for ; Wed, 31 Oct 2012 14:39:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7c9UlPBlQsJUy9vBH73tGhQBhhWdmd+9BGX1jQAZvLw=; b=cRVRSlbsbTIB7tDX1uBPzWPD3X/xvOBGMj0v+0+dLQrY7XI1a94He+ZQuY3P1U2qvx ZV/rvQ7DcsIhbJydeD75Z4h/xvYiz5AH7/KAoYE4Hex+mj2u0uwLZZuZgakLmqf5/Dz1 tFUIyfiPPCToQj3zrZ4FwkY1ScjQRqIMQLWp3mBx6fNplh3IjmEh/a4MIVL+4vDbwruM 059uhqu1aolJlLvs4FLCCeW0F9KvEM4un26Cm1b8rQBFKqxmNaX/M641OP8tKM6M7Vtj t+ARTrzlhcsAKbAKnsY+9wGZH/kTuP3dFksS2SMkHaqMDlkKKhZYyGibNtjdJU/Qi1Ca UVMw==
Received: by 10.50.183.200 with SMTP id eo8mr3075291igc.54.1351719551944; Wed, 31 Oct 2012 14:39:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.46.225 with HTTP; Wed, 31 Oct 2012 14:38:51 -0700 (PDT)
In-Reply-To: <50917B1E.1040508@status.net>
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com>  <50917B1E.1040508@status.net>
From: James M Snell 
Date: Wed, 31 Oct 2012 14:38:51 -0700
Message-ID: 
To: Evan Prodromou 
Content-Type: multipart/alternative; boundary=14dae9340435bac79604cd61bb64
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 21:39:13 -0000

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

On Wed, Oct 31, 2012 at 12:25 PM, Evan Prodromou  wrote:

>  On 12-10-31 12:32 PM, James M Snell wrote:
>
> What is a problem, however, is that you've mentioned a few times that TLS
> could provide the necessary privacy control but there does not appear to be
> any mention at all of TLS within the specification document. It really
> should be called out as a specific recommendation in the text.
>
>  I also note that while you do cover some of the privacy issues in the
> security considerations, one point could stand to be made clearer:
> WebFinger should only be used to expose information the subject has
> explicitly opted in to be shared. Or put another way, WebFinger MUST NOT be
> used to provide information to any party the subject has not explicitly
> authorized. This is loosely implied by the current text but, unless I
> missed it, you never just come out and say it.
>
> That seems exceptionally strong. It also doesn't reflect current practice
> for Web services which often provide profile pages or other human-readable
> endpoints that include by default at least some of the profile data
> provided by the user.
>
> The best services let users choose what profile data to share with whom
> (show my phone number only to friends and family) and most just let the
> user choose whether to share the data at all or not.
>
> For machine-readable endpoints, I think it's untenable. I can say right
> now that there's no way I'll *ever* create user interfaces to ask that a
> user explicitly opt in to e.g. publishing their Salmon protocol endpoint.
>
> Maybe a better way to say it is: the implementor SHOULD let users opt out
> of sharing personally-identifying information, or data that correlates to
> other accounts or identities, and SHOULD inform users that the data is
> being shared in e.g. a terms of service agreement.
>
>
The critical points here are A) a user should never be surprised about what
data a particular service provider is offering up about them and B) a user
should never be surprised about which services are offering up data about
them.


> 2. A cryptographic hashed identifier could help prevent correlation style
> breaches in privacy if the hash is generated based on a shared secret key
> tied to the requesters authenticated identity. That is, if a WebFinger
> server requires authentication to request data, the requester can generate
> an hmac, for instance, using a shared secret key and specify that within
> the URI request. Used in combination with TLS, for example, this would
> provide a reasonable assurance of privacy between the requester and the
> service provider, keeping prying eyes in the middle from knowing whose
> information is being requested. Again, it is possible to do with currently
> without any changes to the WF protocol as defined so no normative changes
> would be necessary, but it might be worthwhile to draw out as an
> informative example.
>
> James, could you give an explicit example of the problem and what the
> solution is? I see at least two or three things here that you're laying out.
>
>
Very straightforward really... Org A wishes to access information about Org
B's users without all the parties in between knowing what's being
requested. For example... IBM has their SmartCloud for Social Business
service.. which is essentially a multi-tenant hosted version of our
Connections product. We have third party ISV's that integrate with that
product and provide extended services to our customers. This is just an
example, but what I want is to be able to provide secure Webfinger services
so that those ISV's can access non-public information about specific users.
It's the same basic WF protocol but with an added layer of security that
the privacy and confidentiality of potentially sensitive business
relationships.

- James


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

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



On Wed, Oct 31, 2012 at 12:25 PM, Evan Prodromou <=
evan@status.net>=
; wrote:




 =20
   =20
 =20
  

    
On 12-10-31 12:32 PM, James M Snell
      wrote:

    

    
What is a problem, however, is that you'v=
e mentioned a
      few times that TLS could provide the necessary privacy control but
      there does not appear to be any mention at all of TLS within the
      specification document. It really should be called out as a
      specific recommendation in the text. 

    

      
I also note that while you do cover some of the
        privacy issues in the security considerations, one point could
        stand to be made clearer: WebFinger should only be used to
        expose information the subject has explicitly opted in to be
        shared. Or put another way, WebFinger MUST NOT be used to
        provide information to any party the subject has not explicitly
        authorized. This is loosely implied by the current text but,
        unless I missed it, you never just come out and say it.

    

    That seems exceptionally strong. It also doesn't reflect current
    practice for Web services which often provide profile pages or other
    human-readable endpoints that include by default at least some of
    the profile data provided by the user.

    

    The best services let users choose what profile data to share with
    whom (show my phone number only to friends and family) and most just
    let the user choose whether to share the data at all or not.

    

    For machine-readable endpoints, I think it's untenable. I can say
    right now that there's no way I'll ever create user
    interfaces to ask that a user explicitly opt in to e.g. publishing
    their Salmon protocol endpoint.

    

    Maybe a better way to say it is: the implementor SHOULD let users
    opt out of sharing personally-identifying information, or data that
    correlates to other accounts or identities, and SHOULD inform users
    that the data is being shared in e.g. a terms of service agreement.

The critical=
 points here are A) a user should never be surprised about what data a part=
icular service provider is offering up about them and B) a user should neve=
r be surprised about which services are offering up data about them.



=C2=A0

    
2. A cryptographic hashed identifier could he=
lp
      prevent correlation style breaches in privacy if the hash is
      generated based on a shared secret key tied to the requesters
      authenticated identity. That is, if a WebFinger server requires
      authentication to request data, the requester can generate an
      hmac, for instance, using a shared secret key and specify that
      within the URI request. Used in combination with TLS, for example,
      this would provide a reasonable assurance of privacy between the
      requester and the service provider, keeping prying eyes in the
      middle from knowing whose information is being requested. Again,
      it is possible to do with currently without any changes to the WF
      protocol as defined so no normative changes would be necessary,
      but it might be worthwhile to draw out as an informative example.

    James, could you give an explicit example of the problem and what
    the solution is? I see at least two or three things here that you'r=
e
    laying out.

    

Very straightf=
orward really... Org A wishes to access information about Org B's users=
 without all the parties in between knowing what's being requested. For=
 example... IBM has their SmartCloud for Social Business service.. which is=
 essentially a multi-tenant hosted version of our Connections product. We h=
ave third party ISV's that integrate with that product and provide exte=
nded services to our customers. This is just an example, but what I want is=
 to be able to provide secure Webfinger services so that those ISV's ca=
n access non-public information about specific users. It's the same bas=
ic WF protocol but with an added layer of security that the privacy and con=
fidentiality of potentially sensitive business relationships.=C2=A0




- James
=C2=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





--14dae9340435bac79604cd61bb64--

From jasnell@gmail.com  Wed Oct 31 14:56:40 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5086321F8854 for ; Wed, 31 Oct 2012 14:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.459
X-Spam-Level: 
X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.139,  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 HVm9HK9YMeLU for ; Wed, 31 Oct 2012 14:56:39 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E6D7B21F8853 for ; Wed, 31 Oct 2012 14:56:38 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 9so3180252iec.31 for ; Wed, 31 Oct 2012 14:56:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8oS/V0763EALw1m6MB9MrjgCC9dJGcCsyJR1jfjIfDg=; b=mp/Zu1riZKmsbrTTppIdHunvcMgGvKTE7ocspE2HfiSpcIL79um6ahKt7RwgYmwrce WDHc0WwJke29RRMm3R0NSnCT031R8AXZS26uh/Zw+Umi7gpkqgxND58QB5/+I3fppEI4 jytMwrDpxKOdSbdqUpvOURwgjFqFdwD6wslJFOPdva+w7O9h9HbNq0ri4TWxoFucb8R0 OOft/J6n28w5quUvvrkRZSVdYAPxOJzX1mO0tvDC5IHJzrRLAQnkaFg7/PoE6bF4s1Gw sOP2V4gwNlPfze81LDoVd4oyKeVSfgIUBNGyUHCmK2DYvt9vL3OpZWRS+thnND4RChEz N1iw==
Received: by 10.42.210.12 with SMTP id gi12mr33233528icb.22.1351720598520; Wed, 31 Oct 2012 14:56:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.46.225 with HTTP; Wed, 31 Oct 2012 14:56:18 -0700 (PDT)
In-Reply-To: <005f01cdb7b0$010fc430$032f4c90$@packetizer.com>
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com>  <005f01cdb7b0$010fc430$032f4c90$@packetizer.com>
From: James M Snell 
Date: Wed, 31 Oct 2012 14:56:18 -0700
Message-ID: 
To: "Paul E. Jones" 
Content-Type: multipart/alternative; boundary=20cf304351d21c43ef04cd61fa48
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 21:56:40 -0000

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

On Wed, Oct 31, 2012 at 2:38 PM, Paul E. Jones wrote=
:

> James,****
>
> ** **
>
> HTTPS is recommended and shown throughout the document.  We do not say
> TLS, as HTTPS implies that.****
>
> **
>

>From the security considerations, I see...

"Of particular importance is the recommended use of HTTPS to ensure that
information is not modified during transit. Clients should verify that the
certificate used on an HTTPS connection is valid."

Why not make this a "SHOULD use HTTPS" (note the capitalized SHOULD) and
provide a normative reference to TLS? Why not make use of TLS the default?
Showing it in examples without a strong normative recommendation or
requirement is a good way to have it ignored or supported as an
afterthought.


>  **
>
> In the security section at the end of =E2=80=9CService providers and user=
s=E2=80=A6=E2=80=9D how
> about this?****
>
> ** **
>
> Further, WebFinger servers MUST NOT be used to provide any personal
> information to any party unless authorized by the person whose informatio=
n
> is being shared.****
>
> **
>

Perhaps something along the lines of...

  "Further, WebFinger servers MUST NOT be used to provide any personal
information to any party unless explicitly or implicitly authorized by the
person whose information is being shared. Implicit authorization can be
determined by the users voluntary utilization of a service as defined by
that service's relevant terms of use or published privacy policy."

Would have to fiddle with the wording there but basically... if a user is
voluntarily providing their information to a service that makes it know in
advance what information is going to be provided via WebFinger (e.g. within
a Terms of Service or Privacy Policy document) then we're good. Again, to
reiterate the point I made in another note, a user should never be
surprised what information is being shared and by whom.


> **
>
> As a final paragraph in that section, how about this?****
>
> ** **
>
> Finally, a WebFinger server has no means of ensuring that information
> provided by a user is accurate.  Likewise, neither the server nor the
> client can be absolutely guaranteed that information has not been
> manipulated either at the server or along the communication path between
> the client and server.  Use of HTTPS helps to address some concerns with
> manipulation of information along the communication path, but it clearly
> cannot address issues where the server provided incorrect information,
> either due to being provided false information or due to malicious behavi=
or
> on the part of the server administrator.  As with any information service
> available on the Internet, users should wary of information received from
> untrusted sources.****
>
> **
>

That works.

- James


> **
>
> Paul****
>
> ** **
>
> *From:* James M Snell [mailto:jasnell@gmail.com]
> *Sent:* Wednesday, October 31, 2012 12:32 PM
> *To:* Paul E. Jones
> *Cc:* IETF Apps Discuss; Hannes Tschofenig; SM
>
> *Subject:* Re: [apps-discuss] webfinger privacy question/suggestion****
>
> ** **
>
> Ordinarily I would provide a suggestion of alternative text but I've been
> tied up on a few other matters. That said, a few notes...****
>
> The basic protocol itself is fine.. the way that the current resource
> parameter is defined, I could in theory use a uri scheme that allows me t=
o
> hash the identifier without requiring changes to the basic protocol itsel=
f.
> That itself is not so much of a problem. ****
>
> What is a problem, however, is that you've mentioned a few times that TLS
> could provide the necessary privacy control but there does not appear to =
be
> any mention at all of TLS within the specification document. It really
> should be called out as a specific recommendation in the text. ****
>
> I also note that while you do cover some of the privacy issues in the
> security considerations, one point could stand to be made clearer:
> WebFinger should only be used to expose information the subject has
> explicitly opted in to be shared. Or put another way, WebFinger MUST NOT =
be
> used to provide information to any party the subject has not explicitly
> authorized. This is loosely implied by the current text but, unless I
> missed it, you never just come out and say it.****
>
> A couple other points that come to mind when re-reading the security
> considerations...****
>
> 1. There is nothing said about the validity and authenticity of the data
> returned. There does not have to be an exhaustive discussion on this
> matter, of course, but currently the protocol makes no guarantees and
> provides no mechanisms for assuring that the information returned for a
> given user is authentic, authoritative or valid in any way. It should at
> least be noted that such mechanisms are out of the scope of the WebFinger
> protocol.****
>
> 2. A cryptographic hashed identifier could help prevent correlation style
> breaches in privacy if the hash is generated based on a shared secret key
> tied to the requesters authenticated identity. That is, if a WebFinger
> server requires authentication to request data, the requester can generat=
e
> an hmac, for instance, using a shared secret key and specify that within
> the URI request. Used in combination with TLS, for example, this would
> provide a reasonable assurance of privacy between the requester and the
> service provider, keeping prying eyes in the middle from knowing whose
> information is being requested. Again, it is possible to do with currentl=
y
> without any changes to the WF protocol as defined so no normative changes
> would be necessary, but it might be worthwhile to draw out as an
> informative example.****
>
> - James****
>
> On Oct 30, 2012 5:48 PM, "Paul E. Jones"  wrote:**=
*
> *
>
> That's not an entirely true statement.  See:
> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02#section-11
>
> Question is whether that is sufficient.  Thus far, I've not received any
> additional text.
>
> Paul
>
> > -----Original Message-----
> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> > bounces@ietf.org] On Behalf Of SM
> > Sent: Tuesday, October 30, 2012 1:19 PM
> > To: Hannes Tschofenig
> > Cc: apps-discuss@ietf.org
> > Subject: Re: [apps-discuss] webfinger privacy question/suggestion
> >
> > At 03:16 30-10-2012, Hannes Tschofenig wrote:
> > >Have a look at: http://tools.ietf.org/html/draft-iab-privacy-
> > considerations-04
> >
> > Hmm, that draft was mentioned several months ago [1].
> >
> > >I have raised these privacy issues already last year. My comments got
> > ignored.
> >
> > The following question was asked around 11 months ago [2]:
> >
> >    "What are you planning to do to ensure the draft properly addresses
> >     security, privacy, and netiquette issues?"
> >
> > The current plan seems to be: do nothing.
> >
> > Regards,
> > -sm
> >
> > 1. http://www.ietf.org/mail-archive/web/apps-
> > discuss/current/msg04747.html
> > 2. http://www.ietf.org/mail-archive/web/apps-
> > discuss/current/msg03804.html
> >
> > _______________________________________________
> > 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****
>

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


On Wed, Oct 31, 2012 at 2:38 PM, Paul E. Jon=
es <paulej@packetizer.com> wrote:



James,


=C2=A0
HTTPS is recommended and shown throughout =
the document.=C2=A0 We do not say TLS, as HTTPS implies that.=




<=
/div>

From the security considerations, I s=
ee...




"Of particular importance is the recommended use o=
f HTTPS to ensure that information is not modified during transit. Clients =
should verify that the certificate used on an HTTPS connection is valid.&qu=
ot;




Why not make this a "SHOULD use HTTPS" (note =
the capitalized SHOULD) and provide a normative reference to TLS? Why not m=
ake use of TLS the default? Showing it in examples without a strong normati=
ve recommendation or requirement is a good way to have it ignored or suppor=
ted as an afterthought.



=C2=A0
=C2=A0



In the security section a=
t the end of =E2=80=9CService providers and users=E2=80=A6=E2=80=9D how abo=
ut this?



=C2=A0
Further, WebFinger servers MUST NOT be used to provide any personal=
 information to any party unless authorized by the person whose information=
 is being shared.



=C2=A0
<=
/div>

Perhaps something along the lin=
es of...



=C2=A0
=C2=A0 "Further, WebFinger servers MUST NOT be u=
sed to provide any personal information to any party unless explicitly or i=
mplicitly authorized by the person whose information is being shared. Impli=
cit authorization can be determined by the users voluntary utilization of a=
 service as defined by that service's relevant terms of use or publishe=
d privacy policy."




Would have to fiddle with the wording there but basical=
ly... if a user is voluntarily providing their information to a service tha=
t makes it know in advance what information is going to be provided via Web=
Finger (e.g. within a Terms of Service or Privacy Policy document) then we&=
#39;re good. Again, to reiterate the point I made in another note, a user s=
hould never be surprised what information is being shared and by whom.


=C2=A0



As a final paragraph in t=
hat section, how about this?

=C2=A0


=C2=A0
<=
/div>

That works.=C2=A0


- James
=C2=A0



Paul=

=C2=A0<=
/span>



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


Sent: Wednesday, October 31, 2012 12:32 PM
To: Paul E. Jon=
es
Cc: IETF Apps Discuss; Hannes Tschofenig; SM

Subject: Re: [apps-discuss] webfinger privacy qu=
estion/suggestion



<=
/u>=C2=A0
Ordinarily I would provide a suggestion of alternati=
ve text but I've been tied up on a few other matters. That said, a few =
notes...



The basic protocol itself is fine.. the way that the current resource pa=
rameter is defined, I could in theory use a uri scheme that allows me to ha=
sh the identifier without requiring changes to the basic protocol itself. T=
hat itself is not so much of a problem. 



What is a problem, however, is that you've mentioned a few times tha=
t TLS could provide the necessary privacy control but there does not appear=
 to be any mention at all of TLS within the specification document. It real=
ly should be called out as a specific recommendation in the text. 



I also note that while you do cover some of the privacy issues in the se=
curity considerations, one point could stand to be made clearer: WebFinger =
should only be used to expose information the subject has explicitly opted =
in to be shared. Or put another way, WebFinger MUST NOT be used to provide =
information to any party the subject has not explicitly authorized. This is=
 loosely implied by the current text but, unless I missed it, you never jus=
t come out and say it.



A couple other points that come to mind when re-reading the security con=
siderations...
1. There is nothing said about the valid=
ity and authenticity of the data returned. There does not have to be an exh=
austive discussion on this matter, of course, but currently the protocol ma=
kes no guarantees and provides no mechanisms for assuring that the informat=
ion returned for a given user is authentic, authoritative or valid in any w=
ay. It should at least be noted that such mechanisms are out of the scope o=
f the WebFinger protocol.



2. A cryptographic hashed identifier could help prevent correlation styl=
e breaches in privacy if the hash is generated based on a shared secret key=
 tied to the requesters authenticated identity. That is, if a WebFinger ser=
ver requires authentication to request data, the requester can generate an =
hmac, for instance, using a shared secret key and specify that within the U=
RI request. Used in combination with TLS, for example, this would provide a=
 reasonable assurance of privacy between the requester and the service prov=
ider, keeping prying eyes in the middle from knowing whose information is b=
eing requested. Again, it is possible to do with currently without any chan=
ges to the WF protocol as defined so no normative changes would be necessar=
y, but it might be worthwhile to draw out as an informative example.=




- James
On Oct 30, 2012 5:4=
8 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:
<=
p class=3D"MsoNormal">

That's not an entirely true statement. =C2=A0See:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02#section-1=
1



Question is whether that is sufficient. =C2=A0Thus far, I've not re=
ceived any
additional text.

Paul

> -----Original Messag=
e-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-


> bounces@ietf.org=
] On Behalf Of SM
> Sent: Tuesday, October 30, 2012 1:19 PM
&g=
t; To: Hannes Tschofenig
> Cc: apps-discuss@ietf.org


> Subject: Re: [apps-discuss] webfinger privacy question/suggestion
&=
gt;
> At 03:16 30-10-2012, Hannes Tschofenig wrote:
> >Have =
a look at: http://tools.ietf.org/html/draft-iab-privacy-


> considerations-04
>
> Hmm, that draft was mentioned severa=
l months ago [1].
>
> >I have raised these privacy issues al=
ready last year. My comments got
> ignored.
>
> The follo=
wing question was asked around 11 months ago [2]:


>
> =C2=A0 =C2=A0"What are you planning to do to ensure the d=
raft properly addresses
> =C2=A0 =C2=A0 security, privacy, and netiqu=
ette issues?"
>
> The current plan seems to be: do nothing=
.
>
> Regards,


> -sm
>
> 1. http://www.ietf.org/mail-archive/web/apps-> discuss/current/msg04747.html
> 2. http://www.ietf.org/mail-archi=
ve/web/apps-


> discuss/current/msg03804.html
>
> ________________________=
_______________________
> apps-discuss mailing list
> apps-discuss@ietf.org


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

_=
______________________________________________
apps-discuss mailing list=



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






--20cf304351d21c43ef04cd61fa48--

From paulej@packetizer.com  Wed Oct 31 15:36:09 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E10C21F8869 for ; Wed, 31 Oct 2012 15:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Level: 
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.296,  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 Mpop2s9zONo8 for ; Wed, 31 Oct 2012 15:36:08 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E798321F88A1 for ; Wed, 31 Oct 2012 15:36:07 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9VMa2ln028783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Oct 2012 18:36:03 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351722963; bh=acXs/+heWB6blIZzVFfA1J6AaMdDogJi7t6m9iJyidY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=VeRSVol/C0oWp6buiwCw9EGUex4oOyCVY3PR3XXeAgOmSZuwuczOn/l/wdkfuSlhe Sw1fj6Gb3Ov27IANHQMtGaj/A9gHqHvJdmTpYELG1xCJHuuLsX3GEkq9ceRcm6+9ah PitpRCVieuJykv0EcU93T4meu2Dxu2ay/yuoI8A0=
From: "Paul E. Jones" 
To: "'James M Snell'" 
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com>  <005f01cdb7b0$010fc430$032f4c90$@packetizer.com> 
In-Reply-To: 
Date: Wed, 31 Oct 2012 18:36:07 -0400
Message-ID: <009c01cdb7b8$1f349e60$5d9ddb20$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_009D_01CDB796.9824D320"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFLsjjsRNcR0N0rPY8CMxV87xY2TQDs4XE+AookvBECZOavfwEZKXCrAUbsN9ACb4OCXQI3fPywAU9o2S8CEskaJQIt3MI3Axry7YgCJSsFopgabV4Q
Content-Language: en-us
Cc: 'IETF Apps Discuss' 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 22:36:09 -0000

This is a multipart message in MIME format.

------=_NextPart_000_009D_01CDB796.9824D320
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

James,

=20

Comments in green:

=20

=20

From: James M Snell [mailto:jasnell@gmail.com]=20
Sent: Wednesday, October 31, 2012 5:56 PM
To: Paul E. Jones
Cc: IETF Apps Discuss; Hannes Tschofenig; SM
Subject: Re: [apps-discuss] webfinger privacy question/suggestion

=20

=20

On Wed, Oct 31, 2012 at 2:38 PM, Paul E. Jones  =
wrote:

James,

=20

HTTPS is recommended and shown throughout the document.  We do not say =
TLS, as HTTPS implies that.

=20

>From the security considerations, I see...

=20

"Of particular importance is the recommended use of HTTPS to ensure that =
information is not modified during transit. Clients should verify that =
the certificate used on an HTTPS connection is valid."

=20

Why not make this a "SHOULD use HTTPS" (note the capitalized SHOULD) and =
provide a normative reference to TLS? Why not make use of TLS the =
default? Showing it in examples without a strong normative =
recommendation or requirement is a good way to have it ignored or =
supported as an afterthought.

=20

PEJ: In Section 5.1 (=E2=80=9Cperforming a query), we have:

=20

It is strongly RECOMMENDED that WebFinger servers return content using =
secure (HTTPS) connections.  Clients MUST first attempt queries using =
HTTPS before attempting a query using HTTP.

=20

I think that is as strong as we can make it.  We cannot mandate the use =
of HTTPS.

=20

=20

In the security section at the end of =E2=80=9CService providers and =
users=E2=80=A6=E2=80=9D how about this?

=20

Further, WebFinger servers MUST NOT be used to provide any personal =
information to any party unless authorized by the person whose =
information is being shared.

=20

=20

Perhaps something along the lines of...

=20

  "Further, WebFinger servers MUST NOT be used to provide any personal =
information to any party unless explicitly or implicitly authorized by =
the person whose information is being shared. Implicit authorization can =
be determined by the users voluntary utilization of a service as defined =
by that service's relevant terms of use or published privacy policy."

=20

Would have to fiddle with the wording there but basically... if a user =
is voluntarily providing their information to a service that makes it =
know in advance what information is going to be provided via WebFinger =
(e.g. within a Terms of Service or Privacy Policy document) then we're =
good. Again, to reiterate the point I made in another note, a user =
should never be surprised what information is being shared and by whom.

=20

PEJ: Thanks!  I=E2=80=99ll insert that wording and then folks can =
propose changes, if desired.

=20

Paul

As a final paragraph in that section, how about this?

=20

Finally, a WebFinger server has no means of ensuring that information =
provided by a user is accurate.  Likewise, neither the server nor the =
client can be absolutely guaranteed that information has not been =
manipulated either at the server or along the communication path between =
the client and server.  Use of HTTPS helps to address some concerns with =
manipulation of information along the communication path, but it clearly =
cannot address issues where the server provided incorrect information, =
either due to being provided false information or due to malicious =
behavior on the part of the server administrator.  As with any =
information service available on the Internet, users should wary of =
information received from untrusted sources.

=20

=20

That works.=20

=20

- James

=20

Paul

=20

From: James M Snell [mailto:jasnell@gmail.com]=20
Sent: Wednesday, October 31, 2012 12:32 PM
To: Paul E. Jones
Cc: IETF Apps Discuss; Hannes Tschofenig; SM


Subject: Re: [apps-discuss] webfinger privacy question/suggestion

=20

Ordinarily I would provide a suggestion of alternative text but I've =
been tied up on a few other matters. That said, a few notes...

The basic protocol itself is fine.. the way that the current resource =
parameter is defined, I could in theory use a uri scheme that allows me =
to hash the identifier without requiring changes to the basic protocol =
itself. That itself is not so much of a problem.=20

What is a problem, however, is that you've mentioned a few times that =
TLS could provide the necessary privacy control but there does not =
appear to be any mention at all of TLS within the specification =
document. It really should be called out as a specific recommendation in =
the text.=20

I also note that while you do cover some of the privacy issues in the =
security considerations, one point could stand to be made clearer: =
WebFinger should only be used to expose information the subject has =
explicitly opted in to be shared. Or put another way, WebFinger MUST NOT =
be used to provide information to any party the subject has not =
explicitly authorized. This is loosely implied by the current text but, =
unless I missed it, you never just come out and say it.

A couple other points that come to mind when re-reading the security =
considerations...

1. There is nothing said about the validity and authenticity of the data =
returned. There does not have to be an exhaustive discussion on this =
matter, of course, but currently the protocol makes no guarantees and =
provides no mechanisms for assuring that the information returned for a =
given user is authentic, authoritative or valid in any way. It should at =
least be noted that such mechanisms are out of the scope of the =
WebFinger protocol.

2. A cryptographic hashed identifier could help prevent correlation =
style breaches in privacy if the hash is generated based on a shared =
secret key tied to the requesters authenticated identity. That is, if a =
WebFinger server requires authentication to request data, the requester =
can generate an hmac, for instance, using a shared secret key and =
specify that within the URI request. Used in combination with TLS, for =
example, this would provide a reasonable assurance of privacy between =
the requester and the service provider, keeping prying eyes in the =
middle from knowing whose information is being requested. Again, it is =
possible to do with currently without any changes to the WF protocol as =
defined so no normative changes would be necessary, but it might be =
worthwhile to draw out as an informative example.

- James

On Oct 30, 2012 5:48 PM, "Paul E. Jones"  wrote:

That's not an entirely true statement.  See:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02#section-11

Question is whether that is sufficient.  Thus far, I've not received any
additional text.

Paul

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of SM
> Sent: Tuesday, October 30, 2012 1:19 PM
> To: Hannes Tschofenig
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] webfinger privacy question/suggestion
>
> At 03:16 30-10-2012, Hannes Tschofenig wrote:
> >Have a look at: http://tools.ietf.org/html/draft-iab-privacy-
> considerations-04
>
> Hmm, that draft was mentioned several months ago [1].
>
> >I have raised these privacy issues already last year. My comments got
> ignored.
>
> The following question was asked around 11 months ago [2]:
>
>    "What are you planning to do to ensure the draft properly addresses
>     security, privacy, and netiquette issues?"
>
> The current plan seems to be: do nothing.
>
> Regards,
> -sm
>
> 1. http://www.ietf.org/mail-archive/web/apps-
> discuss/current/msg04747.html
> 2. http://www.ietf.org/mail-archive/web/apps-
> discuss/current/msg03804.html
>
> _______________________________________________
> 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

=20


------=_NextPart_000_009D_01CDB796.9824D320
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


James,
 
Comments in green:
 
 
From:=
 =
James M Snell [mailto:jasnell@gmail.com] 
Sent: Wednesday, =
October 31, 2012 5:56 PM
To: Paul E. Jones
Cc: IETF =
Apps Discuss; Hannes Tschofenig; SM
Subject: Re: =
[apps-discuss] webfinger privacy =
question/suggestion
 
 
On Wed, =
Oct 31, 2012 at 2:38 PM, Paul E. Jones <paulej@packetizer.com> =
wrote:
James,
 
HTTPS is recommended and shown throughout the document.  We do =
not say TLS, as HTTPS implies =
that.
 
From the security considerations, I =
see...
 
"Of particular importance is the recommended use =
of HTTPS to ensure that information is not modified during transit. =
Clients should verify that the certificate used on an HTTPS connection =
is valid."
 
Why not make this a "SHOULD use HTTPS" (note =
the capitalized SHOULD) and provide a normative reference to TLS? Why =
not make use of TLS the default? Showing it in examples without a strong =
normative recommendation or requirement is a good way to have it ignored =
or supported as an afterthought.
 
PEJ: In Section 5.1 (=E2=80=9Cperforming a query), we =
have:
 
It is strongly RECOMMENDED that WebFinger servers return content =
using secure (HTTPS) connections.=C2=A0 Clients MUST first attempt =
queries using HTTPS before attempting a query using =
HTTP.
 
I think that is as strong as we can make it.=C2=A0 We cannot mandate =
the use of HTTPS.
 
 
In the security section at the end of =E2=80=9CService providers and =
users=E2=80=A6=E2=80=9D how about this?
 
Further, WebFinger servers MUST NOT be used to provide any personal =
information to any party unless authorized by the person whose =
information is being shared.
 
 
Perhaps something along the lines =
of...
 
  "Further, WebFinger servers MUST NOT be =
used to provide any personal information to any party unless explicitly =
or implicitly authorized by the person whose information is being =
shared. Implicit authorization can be determined by the users voluntary =
utilization of a service as defined by that service's relevant terms of =
use or published privacy policy."
 
Would have to fiddle with the wording there but =
basically... if a user is voluntarily providing their information to a =
service that makes it know in advance what information is going to be =
provided via WebFinger (e.g. within a Terms of Service or Privacy Policy =
document) then we're good. Again, to reiterate the point I made in =
another note, a user should never be surprised what information is being =
shared and by whom.
 
PEJ: Thanks!=C2=A0 I=E2=80=99ll insert that wording and then folks =
can propose changes, if desired.
 
Paul
As a final paragraph in that section, how about =
this?
 
Finally, a WebFinger server has no means of ensuring that information =
provided by a user is accurate.  Likewise, neither the server nor =
the client can be absolutely guaranteed that information has not been =
manipulated either at the server or along the communication path between =
the client and server.  Use of HTTPS helps to address some concerns =
with manipulation of information along the communication path, but it =
clearly cannot address issues where the server provided incorrect =
information, either due to being provided false information or due to =
malicious behavior on the part of the server administrator.  As =
with any information service available on the Internet, users should =
wary of information received from untrusted =
sources.
 
 
That works. 
 
- =
James
 
Paul
 
From:=
 =
James M Snell [mailto:jasnell@gmail.com] 
Sent: Wednesday, =
October 31, 2012 12:32 PM
To: Paul E. Jones
Cc: IETF =
Apps Discuss; Hannes Tschofenig; SM

Subject: Re: [apps-discuss] webfinger =
privacy =
question/suggestion
 <=
/o:p>
Ordinarily I would provide a suggestion of alternative text =
but I've been tied up on a few other matters. That said, a few =
notes...
The basic protocol itself is fine.. the way =
that the current resource parameter is defined, I could in theory use a =
uri scheme that allows me to hash the identifier without requiring =
changes to the basic protocol itself. That itself is not so much of a =
problem. 
What is a problem, however, is that you've =
mentioned a few times that TLS could provide the necessary privacy =
control but there does not appear to be any mention at all of TLS within =
the specification document. It really should be called out as a specific =
recommendation in the text. 
I also note that while you =
do cover some of the privacy issues in the security considerations, one =
point could stand to be made clearer: WebFinger should only be used to =
expose information the subject has explicitly opted in to be shared. Or =
put another way, WebFinger MUST NOT be used to provide information to =
any party the subject has not explicitly authorized. This is loosely =
implied by the current text but, unless I missed it, you never just come =
out and say it.
A couple other points that come to mind =
when re-reading the security considerations...
1. There =
is nothing said about the validity and authenticity of the data =
returned. There does not have to be an exhaustive discussion on this =
matter, of course, but currently the protocol makes no guarantees and =
provides no mechanisms for assuring that the information returned for a =
given user is authentic, authoritative or valid in any way. It should at =
least be noted that such mechanisms are out of the scope of the =
WebFinger protocol.
2. A cryptographic hashed =
identifier could help prevent correlation style breaches in privacy if =
the hash is generated based on a shared secret key tied to the =
requesters authenticated identity. That is, if a WebFinger server =
requires authentication to request data, the requester can generate an =
hmac, for instance, using a shared secret key and specify that within =
the URI request. Used in combination with TLS, for example, this would =
provide a reasonable assurance of privacy between the requester and the =
service provider, keeping prying eyes in the middle from knowing whose =
information is being requested. Again, it is possible to do with =
currently without any changes to the WF protocol as defined so no =
normative changes would be necessary, but it might be worthwhile to draw =
out as an informative example.
- =
James
On Oct 30, =
2012 5:48 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:
That's not =
an entirely true statement.  See:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger=
-02#section-11

Question is whether that is sufficient. =
 Thus far, I've not received any
additional =
text.

Paul

> -----Original Message-----
> From: =
apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] =
On Behalf Of SM
> Sent: Tuesday, October 30, 2012 1:19 PM
> =
To: Hannes Tschofenig
> Cc: apps-discuss@ietf.org
> Subject: Re: =
[apps-discuss] webfinger privacy question/suggestion
>
> At =
03:16 30-10-2012, Hannes Tschofenig wrote:
> >Have a look at: =
http://tools.ietf.org/html/draft-iab-privacy-
&g=
t; considerations-04
>
> Hmm, that draft was mentioned =
several months ago [1].
>
> >I have raised these privacy =
issues already last year. My comments got
> =
ignored.
>
> The following question was asked around 11 =
months ago [2]:
>
>    "What are you planning =
to do to ensure the draft properly addresses
>     =
security, privacy, and netiquette issues?"
>
> The =
current plan seems to be: do nothing.
>
> Regards,
> =
-sm
>
> 1. http://www.ietf.org/mail-archive/web/apps-
> =
discuss/current/msg04747.html
> 2. http://www.ietf.org/mail-archive/web/apps-
> =
discuss/current/msg03804.html
>
> =
_______________________________________________
> apps-discuss =
mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss<=
br>
_______________________________________________
apps-discuss =
mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<=
o:p>
 

------=_NextPart_000_009D_01CDB796.9824D320--


From paulej@packetizer.com  Wed Oct 31 16:01:13 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DBD21F88A4 for ; Wed, 31 Oct 2012 16:01:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.315
X-Spam-Level: 
X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=0.284,  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 V1LToW4Ir38x for ; Wed, 31 Oct 2012 16:01:12 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC4421F88A5 for ; Wed, 31 Oct 2012 16:01:12 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9VN18j0030027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Oct 2012 19:01:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351724469; bh=zK2XLebf/kz42jzMhzHERA/WENs+FfQAAtnQhxOGypg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=dyW69BRfHuM7EPxJKlO6Y4/feOiPSUOREH7L6yvOueVvHGkkvIV6PiyNYutSfcSxn /ryj5S1IKcVbtfIP2I+EBDPDipvXFH1tRRZcngYnWvUFgjiNm1/rNdmO6EF6vWR1K8 dv4OoWqqMdn5tvJ00HHPbtFk+I25z9kqX2l2Opts=
From: "Paul E. Jones" 
To: "'Hannes Tschofenig'" , "'Phillip Hallam-Baker'" 
References: <508E66FB.4070708@cs.tcd.ie>	<0b3b01cdb61c$981dc600$c8595200$@packetizer.com>	<508F0870.9050402@cs.tcd.ie>	<0b9901cdb636$bf951480$3ebf3d80$@packetizer.com>	<508F2B78.2000006@cs.tcd.ie>	<0be001cdb64b$eb574560$c205d020$@packetizer.com>	<508FA55F.5020608@cs.tcd.ie>	<5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net>	<6.2.5.6.2.20121030093556.0a82b130@resistor.net>	<00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com>	<6.2.5.6.2.20121030230234.0b40f3c8@resistor.net>	 
In-Reply-To: 
Date: Wed, 31 Oct 2012 19:01:14 -0400
Message-ID: <00c201cdb7bb$a0dfc7c0$e29f5740$@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: AQFLsjjsRNcR0N0rPY8CMxV87xY2TQDs4XE+AookvBECZOavfwEZKXCrAUbsN9ACb4OCXQI3fPywAU9o2S8CEskaJQFYBz0XAsMF5t8BpBQe1Jgn7qJw
Content-Language: en-us
Cc: 'General discussion of application-layer protocols' 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 23:01:13 -0000

Hannes,

I'm not sure if it is possible to use OAuth with
/.well-known/host-meta.json.

Can OAuth be used to protect any resource on the Internet?  If so, it could
be used to control access to /.well-known/host-meta.*.  For certain, all of
the link relations provided could be protected with any authentication
scheme.  Just because my WF server provides the link to my address book does
not mean anyone would have authorization to retrieve it.

Sometimes I wonder if people have forgotten or not considered that fact.
Certain information is revealed just from the JRD document itself (e.g., the
very fact I have some piece of data published), but the actual referenced
document can be tightly controlled.

Within a corporate environment, I would even expect an internal WF query to
return different results than an external one.  That would not require
OAuth, but would be controlled based on whatever mechanism is used to
determine if a person has access rights as an employee.

Paul

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Wednesday, October 31, 2012 9:06 AM
> To: Phillip Hallam-Baker
> Cc: General discussion of application-layer protocols
> Subject: Re: [apps-discuss] webfinger privacy question/suggestion
> 
> Hi Phillip,
> 
> On Oct 31, 2012, at 2:20 PM, Phillip Hallam-Baker wrote:
> 
> > Javascript which basically was designed by people who only cared about
> goosing their stock options.
> 
> I do not disagree with you here but WebFinger by itself does not
> necessarily need to be implemented in JavaScript(*).
> 
> > 'is Web finger helping people to do the sorts of things that users
> want without unexpected privacy side effects'
> 
> There are use cases where people want to use WebFinger as a discovery
> mechanism (such as OAuth) where the current design of WebFinger
> introduces privacy problems (unnecessarily). I raised this issue last
> year in May:
> http://www.ietf.org/mail-archive/web/oauth/current/msg08965.html
> 
> It seems that WebFinger has become a solution in search of a problem for
> some people.
> 
> Ciao
> Hannes
> 
> PS: (*) In the context of the use case I care about (namely identity
> management) implementations of JavaScript tend to have serious security
> problems.
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From paulej@packetizer.com  Wed Oct 31 16:34:55 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8021C21F8951 for ; Wed, 31 Oct 2012 16:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.398
X-Spam-Level: 
X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=-1.657, BAYES_00=-2.599, FRT_PROFIT1=3.858]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSuGKFvp8OWf for ; Wed, 31 Oct 2012 16:34:53 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0DF21F886A for ; Wed, 31 Oct 2012 16:34:52 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9VNYoMk031511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Oct 2012 19:34:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351726491; bh=ZkP9MS1d5sQoDX7EuOgp0rBjOki+hfAjBmTmMsswlyc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Fkxx858npHS2eC4HPUVKepzYFgjEcGyji7e5Ls1BzaSJRMG525+O4vUKjnZ7lCvnL Ntm88+UYqOyTBUpooOUmyVQEvd/nEHrTmzRgxD1l6TiRFzAtgPVFIktdpXUx1TWd6O OmwL69WHLMOXVEX3NP0RZoEREuZbK7/lMjhmCyHw=
From: "Paul E. Jones" 
To: , 
References: 
In-Reply-To: 
Date: Wed, 31 Oct 2012 19:34:55 -0400
Message-ID: <00c401cdb7c0$55fe5eb0$01fb1c10$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGiIkVUmNNt45MdKJ8yW+kdIunFwpgrNRJw
Content-Language: en-us
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger compromises
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2012 23:34:55 -0000

Brad,

> To everybody who recently saw me rant about WebFinger in person
> recently, hello again.

Oh, I wish I was there... ;-)
=20
> To everybody else, a brief summary:
>=20
> -- I was an early WebFinger evangelist. I remember discussing it at
> conferences for years before it sorta became a thing. I think I even
> named it?

Cool! Always wondered where the name came from.
=20
> -- I added Google's WebFinger support
> (https://groups.google.com/group/webfinger/msg/e8df6402708841ea)

That also answers questions kept asking when I mentioned Google had =
support for it.
=20
> -- I think it's critically important for the Internet to preserve
> user@host.com hierarchical identifiers before email gets too passe and
> we're stuck with single-namespaced walled gardens.  It's on us to make
> email-looking identifiers more useful to compete with all the latest
> proprietary silo hotness, before the people of the internet no longer
> recognize them.

That WF has done.
=20
> (trying to establish that I'm a friend here)
>=20
> That said,

(gulp)
=20
> -- this is the slowest moving community ever (I accept part of the =
blame
> here)

No kidding.  Some I-Ds take 8 or more years in the IETF.  By the time we =
make it perfect, the "opportunity has set sail"... I've seen that happen =
several times.  Then people ask why we don't standardize some things.  =
It's the process sometimes.  Standardization is not always worth it.
=20
> -- can we please stop changing things?  -- JSON, XRD, great, whatever.
> But let's just pick one.  If JSON is now the hotness, let's pick =
*only*
> JSON.  Specs that say "X is required but you can maybe do Y if you =
want
> to" just reek of political compromise to gain a certain party's favor.
> Look at OpenID 2.0.  (I remember being sad about those political moves
> too, but I had lost the energy to fight)

The current language actually isn't political compromise, but more my =
desire to not break backward-compatibility any more than we have to.  =
Current spec recognizes, for example, that Google's WF server serves up =
XML.  Clients expecting XML will still work.  So long as any WF server =
wants to support both, those clients will work.

Going forward, XML is optional and JSON is mandatory.  I wanted to =
mandate both, but lost that argument.  (Still, supporting both is =
simple.  My server does both and will honor the Accept header.  It's =
trivial to do.)

At some point, I will publish my server code.  It's just a simple Perl =
script, but shows how trivial it is to implement a WF server.  It does =
both XML and JSON and I do wish we would continue with both.

Further, I accept the preference for JSON and only putting the =
requirement there.  But the fact is that any web resource can return ANY =
format.  This is a basic part of HTTP and the reason the Accept header =
exists.  So we should design the service such that we can support =
whatever the next hot format is.

So, my position is:
1) Let's not just kill XML because we decided we do not like it this =
week (killing all hope for backward-compatibility)
2) Let's have a web service that could serve XML or JSON or =
next-hot-thing (i.e., future-proof it)
3) Let's use HTTP the way it is supposed to be used and allow the =
"Accept" header to work via /.well-known/host-meta.
4) Since host-meta.json is already defined (and I would have argued =
against it, but it's there), let's fully embrace it.
=20
> -- My recommendation: just remove all mention of XRD from the latest
> WebFinger spec.  Yes, this is counter to my "please stop changing
> things" bullet earlier.  But WebFinger has a better chance of success =
if
> it's a simple spec.  And you're not breaking compatibility with =
anybody
> because *nobody uses WebFinger*.

I'd prefer not to for the above-stated reasons.  Note that only JSON is =
required.
=20
> -- 1 round trip, 2 round trips. Don't really care. 2 round trips keeps
> the spec simpler and the 1st will be highly cacheable (Expires: =
weeks),
> so it's 1 round trip in practice, but I won't fight (too much)
> *optional* parameters in the 1st request to possibly skip the 2nd
> request.  It worries me, though.  I'd rather see that optimization =
added
> in a subsequent version of the spec, so all 1.0 implementations have
> then shown that they're capable of performing the base algorithm.  I
> worry that too many servers will implement the optimization and then
> lazy clients will become pervasive which only do one round trip, thus
> making the "optional" optimization now de facto required for servers.
> So I'd really rather drop that from the spec too.  Let's add it only
> later, once it's shown to be needed.  As is, clients could even fire =
off
> two HTTP requests in parallel to reduce latency, one for host-meta and
> one optimistically for the presumed host-meta location in cases of big
> hosts that rarely change, or expired cached host-meta documents.

We support both.  RFC 6415 defined the base for 2 round trips.  The =
current WF spec adds that extension to allow for one round trip.

And both are trivially implemented, so simple it can be done via static =
files with an Apache server:
http://www.packetizer.com/webfinger/server.html
=20
> I will continue to fight for Google's WebFinger support, but I'm not =
the
> only one losing patience.

You're right there, which is why I'm serving the role of editor.  I'm =
personally pretty happy with the way things are currently defined.  =
Aside from the vast number of comments regarding privacy, I'm not =
hearing a lot in the way of technical issues.  I'd like to move forward.
=20
> Everybody please hurry up, simplify, then hurry up.  I'll help however =
I
> can.  I'm not sure whether this was helpful.

It's doesn't get much simpler than this:

   curl https://packetizer.com/.well-known/host-meta.json?
        resource=3Dacct:paulej@packetizer.com

Now we need to just move on to agreeing on some useful link relations =
for WF.

Paul



From tbray@textuality.com  Wed Oct 31 18:04:50 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84EB21F88B8 for ; Wed, 31 Oct 2012 18:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.481
X-Spam-Level: ***
X-Spam-Status: No, score=3.481 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, FRT_PROFIT1=3.858, 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 EcGp9V3dyjns for ; Wed, 31 Oct 2012 18:04:50 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 00E3B21F88B4 for ; Wed, 31 Oct 2012 18:04:49 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id v19so2225168obq.31 for ; Wed, 31 Oct 2012 18:04:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=aRbFqLD3vlvnQZ29xtQZXpj/BcraNeUTWOfureKN+JU=; b=pYa1v7pe76dfaLEklrm7IgY1jn8aF3/jxkXbo3Ng5eSNkqY2v52LgXctEbZqNqj3LH AvrnQTnE5nSmOxqqYp2ahZWgiT1a3ISGqjldDPsrC0KpMvlrCmIfOBcMcASz2bKj+Lgl j9MuDK1i45U+HboAWHlL5gG6ws0U9ko5kO8Ae1cQfehhnPQitvd0ybcH2/g80wRRmBYb ZKPDkusBiwuBAPXWjWYfcwl1Rm3LlWHGttPecm7AvtlyKFAzCeUcfgv4QAez57CS0N3H tF92cY73EEt+3/IXuhPQTdw4L8Xo18v4CFwzJDyZN6STaD77zcbJJQ+dFDWc+H/qKMkt z8+A==
MIME-Version: 1.0
Received: by 10.182.146.46 with SMTP id sz14mr31654704obb.76.1351731889596; Wed, 31 Oct 2012 18:04:49 -0700 (PDT)
Received: by 10.76.87.136 with HTTP; Wed, 31 Oct 2012 18:04:49 -0700 (PDT)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <00c401cdb7c0$55fe5eb0$01fb1c10$@packetizer.com>
References:  <00c401cdb7c0$55fe5eb0$01fb1c10$@packetizer.com>
Date: Wed, 31 Oct 2012 18:04:49 -0700
Message-ID: 
From: Tim Bray 
To: "Paul E. Jones" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmdslzsyjpbgfGmc3UejTnkwXyIvPf0T9Aiukd5VAu74IIH5AK38+XVBd+3lM1StGxB7yWo
Cc: public-fedsocweb@w3.org, webfinger@googlegroups.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger compromises
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 01 Nov 2012 01:04:50 -0000

At this point, the XML is a distraction and an irritant and offers
zero benefit to implementers.  Just. Drop. It.  Not optional, just
gone.

 -T

On Wed, Oct 31, 2012 at 4:34 PM, Paul E. Jones  wrot=
e:
> Brad,
>
>> To everybody who recently saw me rant about WebFinger in person
>> recently, hello again.
>
> Oh, I wish I was there... ;-)
>
>> To everybody else, a brief summary:
>>
>> -- I was an early WebFinger evangelist. I remember discussing it at
>> conferences for years before it sorta became a thing. I think I even
>> named it?
>
> Cool! Always wondered where the name came from.
>
>> -- I added Google's WebFinger support
>> (https://groups.google.com/group/webfinger/msg/e8df6402708841ea)
>
> That also answers questions kept asking when I mentioned Google had suppo=
rt for it.
>
>> -- I think it's critically important for the Internet to preserve
>> user@host.com hierarchical identifiers before email gets too passe and
>> we're stuck with single-namespaced walled gardens.  It's on us to make
>> email-looking identifiers more useful to compete with all the latest
>> proprietary silo hotness, before the people of the internet no longer
>> recognize them.
>
> That WF has done.
>
>> (trying to establish that I'm a friend here)
>>
>> That said,
>
> (gulp)
>
>> -- this is the slowest moving community ever (I accept part of the blame
>> here)
>
> No kidding.  Some I-Ds take 8 or more years in the IETF.  By the time we =
make it perfect, the "opportunity has set sail"... I've seen that happen se=
veral times.  Then people ask why we don't standardize some things.  It's t=
he process sometimes.  Standardization is not always worth it.
>
>> -- can we please stop changing things?  -- JSON, XRD, great, whatever.
>> But let's just pick one.  If JSON is now the hotness, let's pick *only*
>> JSON.  Specs that say "X is required but you can maybe do Y if you want
>> to" just reek of political compromise to gain a certain party's favor.
>> Look at OpenID 2.0.  (I remember being sad about those political moves
>> too, but I had lost the energy to fight)
>
> The current language actually isn't political compromise, but more my des=
ire to not break backward-compatibility any more than we have to.  Current =
spec recognizes, for example, that Google's WF server serves up XML.  Clien=
ts expecting XML will still work.  So long as any WF server wants to suppor=
t both, those clients will work.
>
> Going forward, XML is optional and JSON is mandatory.  I wanted to mandat=
e both, but lost that argument.  (Still, supporting both is simple.  My ser=
ver does both and will honor the Accept header.  It's trivial to do.)
>
> At some point, I will publish my server code.  It's just a simple Perl sc=
ript, but shows how trivial it is to implement a WF server.  It does both X=
ML and JSON and I do wish we would continue with both.
>
> Further, I accept the preference for JSON and only putting the requiremen=
t there.  But the fact is that any web resource can return ANY format.  Thi=
s is a basic part of HTTP and the reason the Accept header exists.  So we s=
hould design the service such that we can support whatever the next hot for=
mat is.
>
> So, my position is:
> 1) Let's not just kill XML because we decided we do not like it this week=
 (killing all hope for backward-compatibility)
> 2) Let's have a web service that could serve XML or JSON or next-hot-thin=
g (i.e., future-proof it)
> 3) Let's use HTTP the way it is supposed to be used and allow the "Accept=
" header to work via /.well-known/host-meta.
> 4) Since host-meta.json is already defined (and I would have argued again=
st it, but it's there), let's fully embrace it.
>
>> -- My recommendation: just remove all mention of XRD from the latest
>> WebFinger spec.  Yes, this is counter to my "please stop changing
>> things" bullet earlier.  But WebFinger has a better chance of success if
>> it's a simple spec.  And you're not breaking compatibility with anybody
>> because *nobody uses WebFinger*.
>
> I'd prefer not to for the above-stated reasons.  Note that only JSON is r=
equired.
>
>> -- 1 round trip, 2 round trips. Don't really care. 2 round trips keeps
>> the spec simpler and the 1st will be highly cacheable (Expires: weeks),
>> so it's 1 round trip in practice, but I won't fight (too much)
>> *optional* parameters in the 1st request to possibly skip the 2nd
>> request.  It worries me, though.  I'd rather see that optimization added
>> in a subsequent version of the spec, so all 1.0 implementations have
>> then shown that they're capable of performing the base algorithm.  I
>> worry that too many servers will implement the optimization and then
>> lazy clients will become pervasive which only do one round trip, thus
>> making the "optional" optimization now de facto required for servers.
>> So I'd really rather drop that from the spec too.  Let's add it only
>> later, once it's shown to be needed.  As is, clients could even fire off
>> two HTTP requests in parallel to reduce latency, one for host-meta and
>> one optimistically for the presumed host-meta location in cases of big
>> hosts that rarely change, or expired cached host-meta documents.
>
> We support both.  RFC 6415 defined the base for 2 round trips.  The curre=
nt WF spec adds that extension to allow for one round trip.
>
> And both are trivially implemented, so simple it can be done via static f=
iles with an Apache server:
> http://www.packetizer.com/webfinger/server.html
>
>> I will continue to fight for Google's WebFinger support, but I'm not the
>> only one losing patience.
>
> You're right there, which is why I'm serving the role of editor.  I'm per=
sonally pretty happy with the way things are currently defined.  Aside from=
 the vast number of comments regarding privacy, I'm not hearing a lot in th=
e way of technical issues.  I'd like to move forward.
>
>> Everybody please hurry up, simplify, then hurry up.  I'll help however I
>> can.  I'm not sure whether this was helpful.
>
> It's doesn't get much simpler than this:
>
>    curl https://packetizer.com/.well-known/host-meta.json?
>         resource=3Dacct:paulej@packetizer.com
>
> Now we need to just move on to agreeing on some useful link relations for=
 WF.
>
> Paul
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From wmills@yahoo-inc.com  Wed Oct 31 19:36:48 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39F721F8545 for ; Wed, 31 Oct 2012 19:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.299
X-Spam-Level: 
X-Spam-Status: No, score=-16.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 XUbIqlUBQslF for ; Wed, 31 Oct 2012 19:36:46 -0700 (PDT)
Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBB321F8B52 for ; Wed, 31 Oct 2012 19:36:44 -0700 (PDT)
Received: from [98.139.215.140] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 02:36:43 -0000
Received: from [98.139.215.249] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 02:36:43 -0000
Received: from [127.0.0.1] by omp1062.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 02:36:43 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 547027.20663.bm@omp1062.mail.bf1.yahoo.com
Received: (qmail 15278 invoked by uid 60001); 1 Nov 2012 02:36:42 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1351737402; bh=hPb7Z7ONTDnR63zfu1ut58oLZTQkP4TIPbbqwMD996Q=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FY+M9X3G9y6pX1kFpSKLnEoNxPFRC4Z+F3jjlEcWKBUXcBs6Uv8oHgoUGF6ru+WyJS2keKfI/8wugHHNROC/DUEOu5MAtKDmpLZsHnn855pFm7XGqSKc5sLD5ADSaGKCekjtqKABLGyBb0/cOr2h0RF5esErqFicPO+HEa4RFbA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tDBAGrSoIIdqZQd5SIDdVOltotJ7nChwlx5SSG4zf5fbzBwU7Mxai1ASRgRn8ueiaaQRpXXQ49YfIdF5MhScWAo/rLhcnFV+tAmdGdNlcanpOaT8yNnEY3VZbA+CGkwSFKNTwwOCfTV5HO+ZI1I7LR1GzDScJSt9cpt3LSCtwzo=;
X-YMail-OSG: EmgCKTwVM1kMJtnnqjJ1ZqR_86ywvlVWCofrHMw2wXEi_85 qwpAO_tnCGhaMMhvpy8b7baoB3.dLQhB7V7QEVoMQ3ItjAYwJfuQQwldTCeM tWdvo8EaPFlMzJinzCCD2Qc0wVBS1tcf_CnbVY5mb6gUPWBRBpF4Pc8lm7xC 94CC_Np2bKsew_o.S3HZ1zBmipDRX0uOZ_3OJxzt_yEARp.BWtRbG5kGWTAY .1JwgZps1qJ36Dc4JAknNHSccYzi4JXbtinv8byetTzwdllsOX6gj_f_Nwk8 VVgtldVqu1GsWVJuGYARYUH90UXf9u8FC2sLDqMmzgi.GpVEdJVJsdS1h6s0 2Pss5WWJC5V2Y.tdYFqE5w8cqiUr8RAjatTqr1a9krU52GbM6OFDUkixWxdq .3PYemF5PAm.CtnlKz6W0H7xjJaBPH9X4oU7cYsnceuJUAOK9PTbzuI8f74v uYPR1w_3DRvk-
Received: from [99.31.212.42] by web31809.mail.mud.yahoo.com via HTTP; Wed, 31 Oct 2012 19:36:41 PDT
X-Rocket-MIMEInfo: 001.001, Cj5UaGUgYmVzdCBzZXJ2aWNlcyBsZXQgdXNlcnMgY2hvb3NlIHdoYXQgcHJvZmlsZSBkYXRhIHRvIHNoYXJlIHdpdGgKPndob20gKHNob3cgbXkgcGhvbmUgbnVtYmVyIG9ubHkgdG8gZnJpZW5kcyBhbmQgZmFtaWx5KSBhbmQgbW9zdCBqdXN0Cj5sZXQgdGhlIHVzZXIgY2hvb3NlIHdoZXRoZXIgdG8gc2hhcmUgdGhlIGRhdGEgYXQgYWxsIG9yIG5vdC4KCgpZZXMsIGFsbG93aW5nIHRoZSB1c2VyIHRvIGNvbnRyb2wgd2hhdCBpbmZvcm1hdGlvbiBpcyBzaGFyZWQgaXMga2V5LsKgIE5vdGUgdGhhdCB3ZSBoYXYBMAEBAQE-
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.123.460
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com>  <50917B1E.1040508@status.net>
Message-ID: <1351737401.15190.YahooMailNeo@web31809.mail.mud.yahoo.com>
Date: Wed, 31 Oct 2012 19:36:41 -0700 (PDT)
From: William Mills 
To: Evan Prodromou , IETF Apps Discuss 
In-Reply-To: <50917B1E.1040508@status.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
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, 01 Nov 2012 02:36:48 -0000

=0A>The best services let users choose what profile data to share with=0A>w=
hom (show my phone number only to friends and family) and most just=0A>let =
the user choose whether to share the data at all or not.=0A=0A=0AYes, allow=
ing the user to control what information is shared is key.=A0 Note that we =
have multiple classes of informaiton, so that personal information like a v=
card will be handled differently than service information like what OAuth e=
ndpoint is used ot authenticate the user.=0A=0A=0A=0A=0A>__________________=
______________=0A> From: Evan Prodromou =0A>To: IETF Apps =
Discuss  =0A>Sent: Wednesday, October 31, 2012 12:25=
 PM=0A>Subject: Re: [apps-discuss] webfinger privacy question/suggestion=0A=
> =0A>=0A>On 12-10-31 12:32 PM, James M Snell wrote:=0A>=0A>What is a probl=
em, however, is that you've mentioned a few times that TLS could provide th=
e necessary privacy control but there does not appear to be any mention at =
all of TLS within the specification document. It really should be called ou=
t as a specific recommendation in the text. =0A>I also note that while you =
do cover some of the privacy issues in the security considerations, one poi=
nt could stand to be made clearer: WebFinger should only be used to expose =
information the subject has explicitly opted in to be shared. Or put anothe=
r way, WebFinger MUST NOT be used to provide information to any party the s=
ubject has not explicitly authorized. This is loosely implied by the curren=
t text but, unless I missed it, you never just come out and say it.=0AThat =
seems exceptionally strong. It also doesn't reflect current practice for We=
b services which often provide profile pages or other human-readable endpoi=
nts that include by default at least some of the profile data provided by t=
he user.=0A>=0A>The best services let users choose what profile data to sha=
re with=0A=A0=A0=A0=A0whom (show my phone number only to friends and family=
) and most just=0A=A0=A0=A0=A0let the user choose whether to share the data=
 at all or not.=0A>=0A>For machine-readable endpoints, I think it's untenab=
le. I can say=0A=A0=A0=A0=A0right now that there's no way I'll ever create =
user interfaces to ask that a user explicitly opt in to e.g. publishing the=
ir Salmon protocol endpoint.=0A>=0A>Maybe a better way to say it is: the im=
plementor SHOULD let users=0A=A0=A0=A0=A0opt out of sharing personally-iden=
tifying information, or data that=0A=A0=A0=A0=A0correlates to other account=
s or identities, and SHOULD inform users=0A=A0=A0=A0=A0that the data is bei=
ng shared in e.g. a terms of service agreement.=0A>=0A>2. A cryptographic h=
ashed identifier could help prevent correlation style breaches in privacy i=
f the hash is generated based on a shared secret key tied to the requesters=
 authenticated identity. That is, if a WebFinger server requires authentica=
tion to request data, the requester can generate an hmac, for instance, usi=
ng a shared secret key and specify that within the URI request. Used in com=
bination with TLS, for example, this would provide a reasonable assurance o=
f privacy between the requester and the service provider, keeping prying ey=
es in the middle from knowing whose information is being requested. Again, =
it is possible to do with currently without any changes to the WF protocol =
as defined so no normative changes would be necessary, but it might be wort=
hwhile to draw out as an informative example.=0AJames, could you give an ex=
plicit example of the problem and what the solution is? I see at least two =
or three things here that you're laying out.=0A>=0A>-Evan=0A>=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-514-554-3826=0A=
>_______________________________________________=0A>apps-discuss mailing li=
st=0A>apps-discuss@ietf.org=0A>https://www.ietf.org/mailman/listinfo/apps-d=
iscuss=0A>=0A>=0A>

From wmills@yahoo-inc.com  Wed Oct 31 19:39:58 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E3B21F859B for ; Wed, 31 Oct 2012 19:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.948
X-Spam-Level: 
X-Spam-Status: No, score=-16.948 tagged_above=-999 required=5 tests=[AWL=0.650, 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 NflmARp1DpU1 for ; Wed, 31 Oct 2012 19:39:56 -0700 (PDT)
Received: from nm12.bullet.mail.ac4.yahoo.com (nm12.bullet.mail.ac4.yahoo.com [98.139.52.209]) by ietfa.amsl.com (Postfix) with ESMTP id C03E221F859A for ; Wed, 31 Oct 2012 19:39:55 -0700 (PDT)
Received: from [98.139.52.193] by nm12.bullet.mail.ac4.yahoo.com with NNFMP; 01 Nov 2012 02:39:52 -0000
Received: from [98.139.52.187] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 01 Nov 2012 02:39:52 -0000
Received: from [127.0.0.1] by omp1070.mail.ac4.yahoo.com with NNFMP; 01 Nov 2012 02:39:52 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 781848.74051.bm@omp1070.mail.ac4.yahoo.com
Received: (qmail 67748 invoked by uid 60001); 1 Nov 2012 02:39:52 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1351737592; bh=4AVzaL21YMb0CqEI/o3XiMZilj/iT1vtQoA+K5XRvFw=; 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=IGSEMEXvmLdkoU2PyCllE+l0gFpOmxBq8kgmPecRc20dwxkLUMRxAvvxEqBB6oZU6eZt3CJCwQ6Xjk2l0myupXVYSov1zfABmU8vTXGnSpL4SSfhTjWCGqPVz/5UNIPeCcNNOQ/jWvl7mwmMnrEdVJnnTnfhyUHzEwgVUbzNMLc=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.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=N32Ryg/sOX+mey3u+Z685QJwUj4rARTdLtfuwcG01duF5yWeZvc6hA7g4+AVNYxAoWkceGGTwatZGFnQGADA2cspsx9xYY/JcRT5gopb1no0p+pOgfAmoz8jwDJ1e2psaEgJ62njLtsFPtfC7F96EorqHJs/KNuFrHNbnUfumoU=;
X-YMail-OSG: kZOOoroVM1nVQ__HZEFM9nCD_7K7vnLHvqHxJirQI44D4C6 aMJ4TaauiIY5udIBN38Z_uE0sKW1x6vFXZatWVkhYWvrpgngJ4iLpCCgOnss 5y9iENx5144tMKbUl07e5dKNwZbloKiwdFv8azkDQnaBEBVg6dQsOzupZkt5 OA1JfWCe25wWm.VxOGtPekkFcYGmiQSVvSTF2cxy.SptGX_uVcnU6O2LVU5m sau.3If69PAjcyG_yy.TRzjsYW9GfNJYqd2bHyOr_7jJHza_r3Pby3roZguC 2_f7ebKq4TGuI711LmjKv_bb0wLgjrahMywSTNTAT68R5Vr3MNR4gtYzTTXJ 1L8cE24yCbyttxIi4hsyT9b8ZKivMlCB0PZ1cScxCdNz4szWTsf4.u.ntSrr IhHtxwsaqd1dRnbWDtVIHkL6rbSej38hVjQFF42R9tv9sZK81UjFtL6Qh1sG VfR_iKshddfwSKA--
Received: from [99.31.212.42] by web31807.mail.mud.yahoo.com via HTTP; Wed, 31 Oct 2012 19:39:52 PDT
X-Rocket-MIMEInfo: 001.001, V2hpbGUgSSBhZ3JlZSB3aXRoIHRoZSBwcml2YWN5IGxhbmd1YWdlIGFuZCBkcml2ZSB0b3dhcmQgYmVpbmcgY29tcGxldGVseSBhd2FyZSBvZiB0aGlzIEkgdGhpbmsgaXQncyB1bnJlYWxpc3RpYyB0byBwdXQgdG9vIG11Y2ggdmVyYmlhZ2UgaW4gb24gd2hhdCB3b3VsZCBiZSBhIGNvbXBhbnkgdGVybXMgb2Ygc2VydmljZSBvciBwcml2YWN5IHBvbGljeS4KCgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBKYW1lcyBNIFNuZWxsIDxqYXNuZWxsQGdtYWlsLmNvbT4KPlRvOiABMAEBAQE-
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.123.460
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com>  <005f01cdb7b0$010fc430$032f4c90$@packetizer.com> 
Message-ID: <1351737592.16591.YahooMailNeo@web31807.mail.mud.yahoo.com>
Date: Wed, 31 Oct 2012 19:39:52 -0700 (PDT)
From: William Mills 
To: James M Snell , "Paul E. Jones" 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-125733401-1683710382-1351737592=:16591"
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
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, 01 Nov 2012 02:39:58 -0000

---125733401-1683710382-1351737592=:16591
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

While I agree with the privacy language and drive toward being completely a=
ware of this I think it's unrealistic to put too much verbiage in on what w=
ould be a company terms of service or privacy policy.=0A=0A=0A=0A=0A=0A>___=
_____________________________=0A> From: James M Snell =
=0A>To: Paul E. Jones  =0A>Cc: IETF Apps Discuss  =0A>Sent: Wednesday, October 31, 2012 2:56 PM=0A>Subje=
ct: Re: [apps-discuss] webfinger privacy question/suggestion=0A> =0A>=0A>=
=0A>=0A>On Wed, Oct 31, 2012 at 2:38 PM, Paul E. Jones  wrote:=0A>=0A>James,=0A>>=C2=A0=0A>>HTTPS is recommended and shown thro=
ughout the document.=C2=A0 We do not say TLS, as HTTPS implies that.=0A>=0A=
>=0A>From the security considerations, I see...=0A>=0A>=0A>"Of particular i=
mportance is the recommended use of HTTPS to ensure that information is not=
 modified during transit. Clients should verify that the certificate used o=
n an HTTPS connection is valid."=0A>=0A>=0A>Why not make this a "SHOULD use=
 HTTPS" (note the capitalized SHOULD) and provide a normative reference to =
TLS? Why not make use of TLS the default? Showing it in examples without a =
strong normative recommendation or requirement is a good way to have it ign=
ored or supported as an afterthought.=0A>=C2=A0=0A>=C2=A0=0A>>In the securi=
ty section at the end of =E2=80=9CService providers and users=E2=80=A6=E2=
=80=9D how about this?=0A>>=C2=A0=0A>>Further, WebFinger servers MUST NOT b=
e used to provide any personal information to any party unless authorized b=
y the person whose information is being shared.=0A>>=C2=A0=0A>=0A>=0A>Perha=
ps something along the lines of...=0A>=C2=A0=0A>=C2=A0 "Further, WebFinger =
servers MUST NOT be used to provide any personal information to any party u=
nless explicitly or implicitly authorized by the person whose information i=
s being shared. Implicit authorization can be determined by the users volun=
tary utilization of a service as defined by that service's relevant terms o=
f use or published privacy policy."=0A>=0A>=0A>Would have to fiddle with th=
e wording there but basically... if a user is voluntarily providing their i=
nformation to a service that makes it know in advance what information is g=
oing to be provided via WebFinger (e.g. within a Terms of Service or Privac=
y Policy document) then we're good. Again, to reiterate the point I made in=
 another note, a user should never be surprised what information is being s=
hared and by whom.=0A>=C2=A0=0A>As a final paragraph in that section, how a=
bout this?=0A>>=C2=A0=0A>>Finally, a WebFinger server has no means of ensur=
ing that information provided by a user is accurate.=C2=A0 Likewise, neithe=
r the server nor the client can be absolutely guaranteed that information h=
as not been manipulated either at the server or along the communication pat=
h between the client and server.=C2=A0 Use of HTTPS helps to address some c=
oncerns with manipulation of information along the communication path, but =
it clearly cannot address issues where the server provided incorrect inform=
ation, either due to being provided false information or due to malicious b=
ehavior on the part of the server administrator.=C2=A0 As with any informat=
ion service available on the Internet, users should wary of information rec=
eived from untrusted sources.=0A>>=C2=A0=0A>=0A>=0A>That works.=C2=A0=0A>=
=0A>=0A>- James=0A>=C2=A0=0A>Paul=0A>>=C2=A0=0A>>From:James M Snell [mailto=
:jasnell@gmail.com] =0A>>Sent: Wednesday, October 31, 2012 12:32 PM=0A>>To:=
 Paul E. Jones=0A>>Cc: IETF Apps Discuss; Hannes Tschofenig; SM=0A>>=0A>>Su=
bject: Re: [apps-discuss] webfinger privacy question/suggestion=0A>>=C2=A0=
=0A>>Ordinarily I would provide a suggestion of alternative text but I've b=
een tied up on a few other matters. That said, a few notes...=0A>>The basic=
 protocol itself is fine.. the way that the current resource parameter is d=
efined, I could in theory use a uri scheme that allows me to hash the ident=
ifier without requiring changes to the basic protocol itself. That itself i=
s not so much of a problem. =0A>>What is a problem, however, is that you've=
 mentioned a few times that TLS could provide the necessary privacy control=
 but there does not appear to be any mention at all of TLS within the speci=
fication document. It really should be called out as a specific recommendat=
ion in the text. =0A>>I also note that while you do cover some of the priva=
cy issues in the security considerations, one point could stand to be made =
clearer: WebFinger should only be used to expose information the subject ha=
s explicitly opted in to be shared. Or put another way, WebFinger MUST NOT =
be used to provide information to any party the subject has not explicitly =
authorized. This is loosely implied by the current text but, unless I misse=
d it, you never just come out and say it.=0A>>A couple other points that co=
me to mind when re-reading the security considerations...=0A>>1. There is n=
othing said about the validity and authenticity of the data returned. There=
 does not have to be an exhaustive discussion on this matter, of course, bu=
t currently the protocol makes no guarantees and provides no mechanisms for=
 assuring that the information returned for a given user is authentic, auth=
oritative or valid in any way. It should at least be noted that such mechan=
isms are out of the scope of the WebFinger protocol.=0A>>2. A cryptographic=
 hashed identifier could help prevent correlation style breaches in privacy=
 if the hash is generated based on a shared secret key tied to the requeste=
rs authenticated identity. That is, if a WebFinger server requires authenti=
cation to request data, the requester can generate an hmac, for instance, u=
sing a shared secret key and specify that within the URI request. Used in c=
ombination with TLS, for example, this would provide a reasonable assurance=
 of privacy between the requester and the service provider, keeping prying =
eyes in the middle from knowing whose information is being requested. Again=
, it is possible to do with currently without any changes to the WF protoco=
l as defined so no normative changes would be necessary, but it might be wo=
rthwhile to draw out as an informative example.=0A>>- James=0A>>On Oct 30, =
2012 5:48 PM, "Paul E. Jones"  wrote:=0A>>That's not=
 an entirely true statement. =C2=A0See:=0A>>http://tools.ietf.org/html/draf=
t-ietf-appsawg-webfinger-02#section-11=0A>>=0A>>Question is whether that is=
 sufficient. =C2=A0Thus far, I've not received any=0A>>additional text.=0A>=
>=0A>>Paul=0A>>=0A>>> -----Original Message-----=0A>>> From: apps-discuss-b=
ounces@ietf.org [mailto:apps-discuss-=0A>>> bounces@ietf.org] On Behalf Of =
SM=0A>>> Sent: Tuesday, October 30, 2012 1:19 PM=0A>>> To: Hannes Tschofeni=
g=0A>>> Cc: apps-discuss@ietf.org=0A>>> Subject: Re: [apps-discuss] webfing=
er privacy question/suggestion=0A>>>=0A>>> At 03:16 30-10-2012, Hannes Tsch=
ofenig wrote:=0A>>> >Have a look at: http://tools.ietf.org/html/draft-iab-p=
rivacy-=0A>>> considerations-04=0A>>>=0A>>> Hmm, that draft was mentioned s=
everal months ago [1].=0A>>>=0A>>> >I have raised these privacy issues alre=
ady last year. My comments got=0A>>> ignored.=0A>>>=0A>>> The following que=
stion was asked around 11 months ago [2]:=0A>>>=0A>>> =C2=A0 =C2=A0"What ar=
e you planning to do to ensure the draft properly addresses=0A>>> =C2=A0 =
=C2=A0 security, privacy, and netiquette issues?"=0A>>>=0A>>> The current p=
lan seems to be: do nothing.=0A>>>=0A>>> Regards,=0A>>> -sm=0A>>>=0A>>> 1. =
http://www.ietf.org/mail-archive/web/apps-=0A>>> discuss/current/msg04747.h=
tml=0A>>> 2. http://www.ietf.org/mail-archive/web/apps-=0A>>> discuss/curre=
nt/msg03804.html=0A>>>=0A>>> ______________________________________________=
_=0A>>> apps-discuss mailing list=0A>>> apps-discuss@ietf.org=0A>>> https:/=
/www.ietf.org/mailman/listinfo/apps-discuss=0A>>=0A>>______________________=
_________________________=0A>>apps-discuss mailing list=0A>>apps-discuss@ie=
tf.org=0A>>https://www.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>______=
_________________________________________=0A>apps-discuss mailing list=0A>a=
pps-discuss@ietf.org=0A>https://www.ietf.org/mailman/listinfo/apps-discuss=
=0A>=0A>=0A>
---125733401-1683710382-1351737592=:16591
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


While I a=
gree with the privacy language and drive toward being completely aware of t=
his I think it's unrealistic to put too much verbiage in on what would be a=
 company terms of service or privacy policy.

  
 <=
div style=3D"font-family: times new roman, new york, times, serif; font-siz=
e: 12pt;"> 
  
  From: James M Snell <=
;jasnell@gmail.com>
 To:=
 Paul E. Jones <paulej@packetizer.com> 
Cc: IETF Apps Discuss <apps-discuss@ietf.org> 
=
 Sent: Wednesday, October =
31, 2012 2:56 PM
 Subject:<=
/b> Re: [apps-discuss] webfinger privacy question/suggestion
   

On Wed, Oct 31, 2012 at 2:38 PM, Paul E. Jones <paulej@packetizer.com> wrote:
=0A=0A
James,
=0A=0A<=
u> 
HTTPS is recommended and shown t=
hroughout the document.  We do not say TLS, as HTTPS implies that.<=
/u>
=0A=0A

From the security considerations, I see...=0A=0A

"Of particular importance is the recommended u=
se of HTTPS to ensure that information is not modified during transit. Clie=
nts should verify that the certificate used on an HTTPS connection is valid=
."
=0A=0A

Why not make this a "SHOULD use HTTPS" (n=
ote the capitalized SHOULD) and provide a normative reference to TLS? Why n=
ot make use of TLS the default? Showing it in examples without a strong nor=
mative recommendation or requirement is a good way to have it ignored or su=
pported as an afterthought.
=0A=0A
 
 
=0A=0A
In the security section at the end of =E2=
=80=9CService providers and users=E2=80=A6=E2=80=9D how about this?<=
u>
=0A=0A
 
Further, WebFinger servers MUST NOT be us=
ed to provide any personal information to any party unless authorized by th=
e person whose information is being shared.
=0A=
=0A
 

<=
/div>
Perhaps something along the lines of...
=0A=0A
 
  "Further, WebFinger servers MUST NOT be used to provide any =
personal information to any party unless explicitly or implicitly authorize=
d by the person whose information is being shared. Implicit authorization c=
an be determined by the users voluntary utilization of a service as defined=
 by that service's relevant terms of use or published privacy policy."=0A=0A

Would have to fiddle with the wording there but =
basically... if a user is voluntarily providing their information to a serv=
ice that makes it know in advance what information is going to be provided =
via WebFinger (e.g. within a Terms of Service or Privacy Policy document) t=
hen we're good. Again, to reiterate the point I made in another note, a use=
r should never be surprised what information is being shared and by whom.=0A=0A
 
=0A=0A
As a =
final paragraph in that section, how about this?
=

=0A 
=0A
Finally, a WebFinger server has no means of ensuring that inf=
ormation provided by a user is accurate.  Likewise, neither the server=
 nor the client can be absolutely guaranteed that information has not been =
manipulated either at the server or along the communication path between th=
e client and server.  Use of HTTPS helps to address some concerns with=
 manipulation of information along the communication path, but it clearly c=
annot address issues where the server provided incorrect information, eithe=
r due to being provided false information or due to malicious behavior on t=
he part of the server administrator.  As with any information service =
available on the Internet, users should wary of information received from u=
ntrusted sources.
=0A=0A
 <=
/span>

That works. <=
/div>

=0A=0A- James
 
<=
/span>
=0A=0A
Paul
<=
/u> 
=0A=0A
From:<=
span style=3D"font-size:10.0pt;"> James M Snell [mailto:jasnell@gmail.com] 
=0A=0ASent: Wednesday, Oct=
ober 31, 2012 12:32 PM
To: Paul E. Jones
Cc: IETF Apps =
Discuss; Hannes Tschofenig; SM

Subject: Re: [apps-discuss] webfinger privacy question/sugge=
stion
=0A=0A
 
<=
div>Ordinarily I would provide a suggestion of alternative text but I've be=
en tied up on a few other matters. That said, a few notes...<=
/div>=0A=0A
The basic protocol itself is fine.. the way that the curren=
t resource parameter is defined, I could in theory use a uri scheme that al=
lows me to hash the identifier without requiring changes to the basic proto=
col itself. That itself is not so much of a problem. 
=
=0A=0A
What is a problem, however, is that you've mentioned a few times=
 that TLS could provide the necessary privacy control but there does not ap=
pear to be any mention at all of TLS within the specification document. It =
really should be called out as a specific recommendation in the text. 
=0A=0A
I also note that while you do cover some of the p=
rivacy issues in the security considerations, one point could stand to be m=
ade clearer: WebFinger should only be used to expose information the subjec=
t has explicitly opted in to be shared. Or put another way, WebFinger MUST =
NOT be used to provide information to any party the subject has not explici=
tly authorized. This is loosely implied by the current text but, unless I m=
issed it, you never just come out and say it.
=0A=0AA couple other points that come to mind when re-reading the security consi=
derations...
1. There is nothing said about the val=
idity and authenticity of the data returned. There does not have to be an e=
xhaustive discussion on this matter, of course, but currently the protocol =
makes no guarantees and provides no mechanisms for assuring that the inform=
ation returned for a given user is authentic, authoritative or valid in any=
 way. It should at least be noted that such mechanisms are out of the scope=
 of the WebFinger protocol.
=0A=0A
2. A cryptographi=
c hashed identifier could help prevent correlation style breaches in privac=
y if the hash is generated based on a shared secret key tied to the request=
ers authenticated identity. That is, if a WebFinger server requires authent=
ication to request data, the requester can generate an hmac, for instance, =
using a shared secret key and specify that within the URI request. Used in =
combination with TLS, for example, this would provide a reasonable assuranc=
e of privacy between the requester and the service provider, keeping prying=
 eyes in the middle from knowing whose information is being requested. Agai=
n, it is possible to do with currently without any changes to the WF protoc=
ol as defined so no normative changes would be necessary, but it might be w=
orthwhile to draw out as an informative example.
=0A=0A<=
div>- James
O=
n Oct 30, 2012 5:48 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:
=0A=0AThat's not an entirely true statement. =
 See:
http://tools.ietf.o=
rg/html/draft-ietf-appsawg-webfinger-02#section-11
=0A=0A
Questio=
n is whether that is sufficient.  Thus far, I've not received any
a=
dditional text.

Paul

> -----Original Message-----
> =
From: apps-discus=
s-bounces@ietf.org [mailto:apps-discuss-<=
br>=0A=0A> bounces@ietf.org] On Beha=
lf Of SM
> Sent: Tuesday, October 30, 2012 1:19 PM
> To: Hannes=
 Tschofenig
> Cc: apps-disc=
uss@ietf.org
=0A=0A> Subject: Re: [apps-discuss] webfinger privac=
y question/suggestion
>
> At 03:16 30-10-2012, Hannes Tschofeni=
g wrote:
> >Have a look at: http://tools.ietf.or=
g/html/draft-iab-privacy-
=0A=0A> considerations-04
>
&g=
t; Hmm, that draft was mentioned several months ago [1].
>
> &g=
t;I have raised these privacy issues already last year. My comments got
=
> ignored.
>
> The following question was asked around 11 mo=
nths ago [2]:
=0A=0A>
>    "What are you planning to =
do to ensure the draft properly addresses
>     security, p=
rivacy, and netiquette issues?"
>
> The current plan seems to b=
e: do nothing.
>
> Regards,
=0A=0A> -sm
>
> 1=
. http://www.ietf.org/mail-archive/web/apps-
> dis=
cuss/current/msg04747.html
> 2. http://www.ietf.org/ma=
il-archive/web/apps-
=0A=0A> discuss/current/msg03804.html
>=
;
> _______________________________________________
> apps-disc=
uss mailing list
> apps-dis=
cuss@ietf.org
=0A=0A> https://www.ietf.or=
g/mailman/listinfo/apps-discuss

________________________________=
_______________
apps-discuss mailing list
=0A=0Aapps-discuss@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/apps-discuss
=0A=
=0A

=0A

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


 
 
 
   =


---125733401-1683710382-1351737592=:16591--

From wmills@yahoo-inc.com  Wed Oct 31 19:42:49 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6317F21F847C for ; Wed, 31 Oct 2012 19:42:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.165
X-Spam-Level: 
X-Spam-Status: No, score=-17.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 FdPPNaQluzPs for ; Wed, 31 Oct 2012 19:42:47 -0700 (PDT)
Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by ietfa.amsl.com (Postfix) with ESMTP id EB1A021F84E9 for ; Wed, 31 Oct 2012 19:42:45 -0700 (PDT)
Received: from [98.139.212.148] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 02:42:41 -0000
Received: from [98.139.212.213] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 02:42:41 -0000
Received: from [127.0.0.1] by omp1022.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 02:42:41 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 449334.68344.bm@omp1022.mail.bf1.yahoo.com
Received: (qmail 9694 invoked by uid 60001); 1 Nov 2012 02:42:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1351737760; bh=4udpnwrQnJ0tUxftsSHWFRJUTalBsbzoWHprPYf7XX0=; 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=WosJqau7TKZ5CDQ6tbL3GX9A3P55SQUpeBVUlX8hIuJ+xKYAGxpgDCbzyczWYXfoeHr3iCdWj8/Uv0PQWUq9Buw7e05mtZ2Kuqrc7LC1BjQLgco2QNheWT1sUux29jKtj5x78YQ0cKMRFNWDZcMjZQ1mtllZhn9bx4B1IaOOONQ=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.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=Fc5ZNnzodgO6PkVY8UHsbSdkZL9och10Lt+kHBkf/NYTQgORg4DnwCctH7pjMVZvqCzpZJgQTI5J8XmQPyjCsRLNhrjfRCyD2oQrL5EfyM+Y+PGPpr+LOfIGpYzP0cS9UNc2O2YInxCMGoT1hrS2uqmm7yL28dXtHLJFEkPs2Pc=;
X-YMail-OSG: WTpasjgVM1k0PITQwqk5_SsT6yD7LWfIGEqCnaWVD9iLBUf Tk2DXYbfVFdu12N6lgsjiTva9Ff8Xw9D22IK9lbQYm4dFVQY8lZgGDUZ6EtP oaa2L1sGoBeZOjyCbmybDBOXC2AXqB3bO_MGQ3j9bs41JR77QLaYr8Bihu3O So8TUQymvvEHyzVNA9vO4q4bpxrMOZ0q.83qyPBm73X9AvJiER_n4oWQNuq1 4zuQfDsrO6DXimmlHeXSBPRqOckuJm3NtOomf3qZg_x8RAtzkoUPHxs1tCYX acGD5S0YAuJ7khz4xbMwzxS8gRj807er0frWYgGiVA1xyo7pxqWaJp2PkUut 7C3mSyF0RaHMZSReHdAKlZoCNSBzOlZqzO6mxKTFrlYj1sbLpuw6wPB6ELD9 FIk7EfW7tLrgrgPMicaR32fRI8fu6Xyr56Dx4A6Ruzx4mmMcnowlbFAbz3Od SLGjzI0PFaNsb5g--
Received: from [99.31.212.42] by web31803.mail.mud.yahoo.com via HTTP; Wed, 31 Oct 2012 19:42:40 PDT
X-Rocket-MIMEInfo: 001.001, SXQgaXMgcHJvYmFibHkgdXAgdG8gdGhlIHNlcnZpY2UgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhleSByZXR1cm4gZGlmZmVyZW50IGluZm9ybWF0aW9uIHRvIGFuIGF1dGhlbnRpY2F0ZWQgY29udGV4dC7CoCBBdXRoIG1ldGhvZCBhbmQgYmVoYXZpb3IgaXMgb3V0c2llZCB0aGUgc2NvcGUgb2YgV0YgSSB0aGluay4KCgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBQYXVsIEUuIEpvbmVzIDxwYXVsZWpAcGFja2V0aXplci5jb20.Cj5UbzogJ0hhbm5lcyBUc2Nob2ZlbmlnJyABMAEBAQE-
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.123.460
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net>   <00c201cdb7bb$a0dfc7c0$e29f5740$@packetizer.com>
Message-ID: <1351737760.135.YahooMailNeo@web31803.mail.mud.yahoo.com>
Date: Wed, 31 Oct 2012 19:42:40 -0700 (PDT)
From: William Mills 
To: "Paul E. Jones" , 'Hannes Tschofenig' , 'Phillip Hallam-Baker' 
In-Reply-To: <00c201cdb7bb$a0dfc7c0$e29f5740$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1502656925-1171564928-1351737760=:135"
Cc: 'General discussion of application-layer protocols' 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
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, 01 Nov 2012 02:42:49 -0000

--1502656925-1171564928-1351737760=:135
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

It is probably up to the service to determine whether they return different=
 information to an authenticated context.=A0 Auth method and behavior is ou=
tsied the scope of WF I think.=0A=0A=0A=0A=0A=0A>__________________________=
______=0A> From: Paul E. Jones =0A>To: 'Hannes Tscho=
fenig' ; 'Phillip Hallam-Baker'  =0A>Cc: 'General discussion of application-layer protocols'  =0A>Sent: Wednesday, October 31, 2012 4:01 PM=0A>Subject: Re: [=
apps-discuss] webfinger privacy question/suggestion=0A> =0A>Hannes,=0A>=0A>=
I'm not sure if it is possible to use OAuth with=0A>/.well-known/host-meta.=
json.=0A>=0A>Can OAuth be used to protect any resource on the Internet?=A0 =
If so, it could=0A>be used to control access to /.well-known/host-meta.*.=
=A0 For certain, all of=0A>the link relations provided could be protected w=
ith any authentication=0A>scheme.=A0 Just because my WF server provides the=
 link to my address book does=0A>not mean anyone would have authorization t=
o retrieve it.=0A>=0A>Sometimes I wonder if people have forgotten or not co=
nsidered that fact.=0A>Certain information is revealed just from the JRD do=
cument itself (e.g., the=0A>very fact I have some piece of data published),=
 but the actual referenced=0A>document can be tightly controlled.=0A>=0A>Wi=
thin a corporate environment, I would even expect an internal WF query to=
=0A>return different results than an external one.=A0 That would not requir=
e=0A>OAuth, but would be controlled based on whatever mechanism is used to=
=0A>determine if a person has access rights as an employee.=0A>=0A>Paul=0A>=
=0A>> -----Original Message-----=0A>> From: apps-discuss-bounces@ietf.org [=
mailto:apps-discuss-=0A>> bounces@ietf.org] On Behalf Of Hannes Tschofenig=
=0A>> Sent: Wednesday, October 31, 2012 9:06 AM=0A>> To: Phillip Hallam-Bak=
er=0A>> Cc: General discussion of application-layer protocols=0A>> Subject:=
 Re: [apps-discuss] webfinger privacy question/suggestion=0A>> =0A>> Hi Phi=
llip,=0A>> =0A>> On Oct 31, 2012, at 2:20 PM, Phillip Hallam-Baker wrote:=
=0A>> =0A>> > Javascript which basically was designed by people who only ca=
red about=0A>> goosing their stock options.=0A>> =0A>> I do not disagree wi=
th you here but WebFinger by itself does not=0A>> necessarily need to be im=
plemented in JavaScript(*).=0A>> =0A>> > 'is Web finger helping people to d=
o the sorts of things that users=0A>> want without unexpected privacy side =
effects'=0A>> =0A>> There are use cases where people want to use WebFinger =
as a discovery=0A>> mechanism (such as OAuth) where the current design of W=
ebFinger=0A>> introduces privacy problems (unnecessarily). I raised this is=
sue last=0A>> year in May:=0A>> http://www.ietf.org/mail-archive/web/oauth/=
current/msg08965.html=0A>> =0A>> It seems that WebFinger has become a solut=
ion in search of a problem for=0A>> some people.=0A>> =0A>> Ciao=0A>> Hanne=
s=0A>> =0A>> PS: (*) In the context of the use case I care about (namely id=
entity=0A>> management) implementations of JavaScript tend to have serious =
security=0A>> problems.=0A>> ______________________________________________=
_=0A>> apps-discuss mailing list=0A>> apps-discuss@ietf.org=0A>> https://ww=
w.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>___________________________=
____________________=0A>apps-discuss mailing list=0A>apps-discuss@ietf.org=
=0A>https://www.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A>
--1502656925-1171564928-1351737760=:135
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


It is pro=
bably up to the service to determine whether they return different informat=
ion to an authenticated context.  Auth method and behavior is outsied =
the scope of WF I think.


  
 
 
  
  From: Paul E. Jones <paulej@packetiz=
er.com>
 To: 'Hannes=
 Tschofenig' <hannes.tschofenig@gmx.net>; 'Phillip Hallam-Baker'
 <hallam@gmail.com> 
Cc: 'General discussion of application-layer protocols' <apps-discus=
s@ietf.org> 
 Sent: =
Wednesday, October 31, 2012 4:01 PM
 Subject: Re: [apps-discuss] webfinger privacy question/sugges=
tion
  
 
Hannes,

I'm not sure if it is possible t=
o use OAuth with
/.well-known/host-meta.json.

Can OAuth be used t=
o protect any resource on the Internet?  If so, it could
be used to=
 control access to /.well-known/host-meta.*.  For certain, all of
t=
he link relations provided could be protected with any authentication
sc=
heme.  Just because my WF server provides the link to my address book =
does
not mean anyone would have authorization to retrieve it.

Som=
etimes I wonder if people have forgotten or not considered that
 fact.
Certain information is revealed just from the JRD document itself=
 (e.g., the
very fact I have some piece of data published), but the actu=
al referenced
document can be tightly controlled.

Within a corpor=
ate environment, I would even expect an internal WF query to
return diff=
erent results than an external one.  That would not require
OAuth, =
but would be controlled based on whatever mechanism is used to
determine=
 if a person has access rights as an employee.

Paul

> ----=
-Original Message-----
> From: apps-discuss-bo=
unces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Beha=
lf Of Hannes Tschofenig
> Sent: Wednesday, October 31, 2012 9:06 AM> To: Phillip Hallam-Baker
> Cc: General discussion of
 application-layer protocols
> Subject: Re: [apps-discuss] webfinger =
privacy question/suggestion
> 
> Hi Phillip,
> 
> O=
n Oct 31, 2012, at 2:20 PM, Phillip Hallam-Baker wrote:
> 
> &g=
t; Javascript which basically was designed by people who only cared about> goosing their stock options.
> 
> I do not disagree with=
 you here but WebFinger by itself does not
> necessarily need to be i=
mplemented in JavaScript(*).
> 
> > 'is Web finger helping p=
eople to do the sorts of things that users
> want without unexpected =
privacy side effects'
> 
> There are use cases where people wan=
t to use WebFinger as a discovery
> mechanism (such as OAuth) where t=
he current design of WebFinger
> introduces privacy problems (unneces=
sarily). I raised this issue last
> year in May:
> http://www.ietf.org/mail-archive/web/oauth/current/msg08=
965.html
> 
> It seems that WebFinger has become a solution=
 in search of a problem for
> some people.
> 
> Ciao
&=
gt; Hannes
> 
> PS: (*) In the context of the use case I care a=
bout (namely identity
> management) implementations of JavaScript ten=
d to have serious security
> problems.
> ______________________=
_________________________
> apps-discuss mailing list
> =
apps-discuss@ietf.org
> https://www.ietf.org/mailman/listin=
fo/apps-discuss

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


  
 
   

--1502656925-1171564928-1351737760=:135--

From wmills@yahoo-inc.com  Wed Oct 31 19:45:11 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B9C21F85D3 for ; Wed, 31 Oct 2012 19:45:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.045
X-Spam-Level: 
X-Spam-Status: No, score=-14.045 tagged_above=-999 required=5 tests=[AWL=-2.904, BAYES_50=0.001, FRT_PROFIT1=3.858, 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 uFxF847bRxm6 for ; Wed, 31 Oct 2012 19:45:09 -0700 (PDT)
Received: from nm7-vm0.bullet.mail.bf1.yahoo.com (nm7-vm0.bullet.mail.bf1.yahoo.com [98.139.213.151]) by ietfa.amsl.com (Postfix) with ESMTP id 4352621F85D2 for ; Wed, 31 Oct 2012 19:45:09 -0700 (PDT)
Received: from [98.139.212.145] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 02:45:08 -0000
Received: from [98.139.212.237] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 02:45:08 -0000
Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 01 Nov 2012 02:45:08 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 555634.36139.bm@omp1046.mail.bf1.yahoo.com
Received: (qmail 68542 invoked by uid 60001); 1 Nov 2012 02:45:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1351737907; bh=SOdIoskZWDZgj/ZA3TF+Wr+nX2dlX4RzWYDri93WIu0=; 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:Content-Transfer-Encoding; b=qeH0Q/iMevCQGFmEV0bezA7d1nCNd2fYbmlgwj/0D0WuIEcsFJdjDyfsruLFYyFu3gs+4P36rmhQEFPP8iLoK8Sc/w/PMcWWEP4McgLqV3Y23c4gVsqxN32DmJDtT1vaoF4mHEu8yZpO9D4jodeNy3GhSME8SOxHXQnURa9HghM=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.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:Content-Transfer-Encoding; b=a97fkMvf6nioN7YhltkFhuQharjRtou1Qv5wYmycG+fAefohqDE9fNCJlylQZZ3DDaJoGh1DpM2lZ4GlNXQO8N036GiWXmo/oIvjaIPoUkWTHWKT1te1FtVmq06o1MNn+xOkA/nsUyStqzKm89LlZaCQkrBC0gRM9/zGSdSuvYc=;
X-YMail-OSG: 9t11HNIVM1m580t8X7tv8nHkfEUiKAUUXcyoqJBCMV2EE5J PFF2V7cDxXd6Rf2WvUqftSsUZCbp_JlsekS3vJsOnIIAEb.w7NPZ3dy8Zafv Y4VRhPRWYSawiiCTH2AHEyermX9WqrKbHYvhwH9JNaKP69z2MNXzjJTPVQ.K EemJpMxAbKjai6bWA21gW6AVi6FCaiHoI4xUKpEV9BNKS4P4JasEFCutlHYV YGbOuUQtA4UGWmNbJPc9evC0GFFSyEEdRFoOfEo8cND_yqtIJI8td_nRuGbv gZeiNX5pOYCkK8CwURKP5jJPIm8Tm.Ccbqyb2wHFlvliAigmh1jmIUypTZOZ _enjrAspqZGHMqUSbUicR8t5WH8AhnNRnsb9T70zCPDsTdedVlHB8t6bDOwD pJJwpeifthbbN_lWr59AgN4diVgYDEE4J5J5ScYM0h3VqtFAD8SE2pDeWAfN gCfuvvu0bHITUTapKcK1f207a6k9NXzDZ.2mSDe5qMjPArPJt8kPOylG4zwS o.WphFr1_MTdB96vOXmtYwsvOiGaWOtblSC.2nTVgbaJyKqUHdMtDgebRu2_ dgRqVnou.rJmgSXEoIF1L65VBP3xEuxPhcQw-
Received: from [99.31.212.42] by web31802.mail.mud.yahoo.com via HTTP; Wed, 31 Oct 2012 19:45:07 PDT
X-Rocket-MIMEInfo: 001.001, Cj5Ob3cgd2UgbmVlZCB0byBqdXN0IG1vdmUgb24gdG8gYWdyZWVpbmcgb24gc29tZSB1c2VmdWwgbGluayByZWxhdGlvbnMgZm9yIFdGLgoKRllJIHRoZSBsaW5rIHJlbGF0aW9ucyBmb3IgT0F1dGggYXJlIGRlZmluZWQgYW5kIGhhdmUgYmVlbiBhY2NlcHRlZCBpbiB0aGUgSVNFIHB1YmxpY2F0aW9uIHRyYWNrIGFzIGFuIGluZm9ybWF0aW9uYWwgUkZDLgoKCgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBQYXVsIEUuIEpvbmVzIDxwYXVsZWpAcGFja2V0aXplci5jb20.Cj4BMAEBAQE-
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.123.460
References:  <00c401cdb7c0$55fe5eb0$01fb1c10$@packetizer.com>
Message-ID: <1351737907.30601.YahooMailNeo@web31802.mail.mud.yahoo.com>
Date: Wed, 31 Oct 2012 19:45:07 -0700 (PDT)
From: William Mills 
To: "Paul E. Jones" , "webfinger@googlegroups.com" , "public-fedsocweb@w3.org" 
In-Reply-To: <00c401cdb7c0$55fe5eb0$01fb1c10$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] WebFinger compromises
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, 01 Nov 2012 02:45:11 -0000

=0A>Now we need to just move on to agreeing on some useful link relations f=
or WF.=0A=0AFYI the link relations for OAuth are defined and have been acce=
pted in the ISE publication track as an informational RFC.=0A=0A=0A=0A=0A=
=0A=0A>________________________________=0A> From: Paul E. Jones =0A>To: webfinger@googlegroups.com; public-fedsocweb@w3.org =0A=
>Cc: apps-discuss@ietf.org =0A>Sent: Wednesday, October 31, 2012 4:34 PM=0A=
>Subject: Re: [apps-discuss] WebFinger compromises=0A> =0A>Brad,=0A>=0A>> T=
o everybody who recently saw me rant about WebFinger in person=0A>> recentl=
y, hello again.=0A>=0A>Oh, I wish I was there... ;-)=0A>=0A>> To everybody =
else, a brief summary:=0A>> =0A>> -- I was an early WebFinger evangelist. I=
 remember discussing it at=0A>> conferences for years before it sorta becam=
e a thing. I think I even=0A>> named it?=0A>=0A>Cool! Always wondered where=
 the name came from.=0A>=0A>> -- I added Google's WebFinger support=0A>> (h=
ttps://groups.google.com/group/webfinger/msg/e8df6402708841ea)=0A>=0A>That =
also answers questions kept asking when I mentioned Google had support for =
it.=0A>=0A>> -- I think it's critically important for the Internet to prese=
rve=0A>> user@host.com hierarchical identifiers before email gets too passe=
 and=0A>> we're stuck with single-namespaced walled gardens.=A0 It's on us =
to make=0A>> email-looking identifiers more useful to compete with all the =
latest=0A>> proprietary silo hotness, before the people of the internet no =
longer=0A>> recognize them.=0A>=0A>That WF has done.=0A>=0A>> (trying to es=
tablish that I'm a friend here)=0A>> =0A>> That said,=0A>=0A>(gulp)=0A>=0A>=
> -- this is the slowest moving community ever (I accept part of the blame=
=0A>> here)=0A>=0A>No kidding.=A0 Some I-Ds take 8 or more years in the IET=
F.=A0 By the time we make it perfect, the "opportunity has set sail"... I'v=
e seen that happen several times.=A0 Then people ask why we don't standardi=
ze some things.=A0 It's the process sometimes.=A0 Standardization is not al=
ways worth it.=0A>=0A>> -- can we please stop changing things?=A0 -- JSON, =
XRD, great, whatever.=0A>> But let's just pick one.=A0 If JSON is now the h=
otness, let's pick *only*=0A>> JSON.=A0 Specs that say "X is required but y=
ou can maybe do Y if you want=0A>> to" just reek of political compromise to=
 gain a certain party's favor.=0A>> Look at OpenID 2.0.=A0 (I remember bein=
g sad about those political moves=0A>> too, but I had lost the energy to fi=
ght)=0A>=0A>The current language actually isn't political compromise, but m=
ore my desire to not break backward-compatibility any more than we have to.=
=A0 Current spec recognizes, for example, that Google's WF server serves up=
 XML.=A0 Clients expecting XML will still work.=A0 So long as any WF server=
 wants to support both, those clients will work.=0A>=0A>Going forward, XML =
is optional and JSON is mandatory.=A0 I wanted to mandate both, but lost th=
at argument.=A0 (Still, supporting both is simple.=A0 My server does both a=
nd will honor the Accept header.=A0 It's trivial to do.)=0A>=0A>At some poi=
nt, I will publish my server code.=A0 It's just a simple Perl script, but s=
hows how trivial it is to implement a WF server.=A0 It does both XML and JS=
ON and I do wish we would continue with both.=0A>=0A>Further, I accept the =
preference for JSON and only putting the requirement there.=A0 But the fact=
 is that any web resource can return ANY format.=A0 This is a basic part of=
 HTTP and the reason the Accept header exists.=A0 So we should design the s=
ervice such that we can support whatever the next hot format is.=0A>=0A>So,=
 my position is:=0A>1) Let's not just kill XML because we decided we do not=
 like it this week (killing all hope for backward-compatibility)=0A>2) Let'=
s have a web service that could serve XML or JSON or next-hot-thing (i.e., =
future-proof it)=0A>3) Let's use HTTP the way it is supposed to be used and=
 allow the "Accept" header to work via /.well-known/host-meta.=0A>4) Since =
host-meta.json is already defined (and I would have argued against it, but =
it's there), let's fully embrace it.=0A>=0A>> -- My recommendation: just re=
move all mention of XRD from the latest=0A>> WebFinger spec.=A0 Yes, this i=
s counter to my "please stop changing=0A>> things" bullet earlier.=A0 But W=
ebFinger has a better chance of success if=0A>> it's a simple spec.=A0 And =
you're not breaking compatibility with anybody=0A>> because *nobody uses We=
bFinger*.=0A>=0A>I'd prefer not to for the above-stated reasons.=A0 Note th=
at only JSON is required.=0A>=0A>> -- 1 round trip, 2 round trips. Don't re=
ally care. 2 round trips keeps=0A>> the spec simpler and the 1st will be hi=
ghly cacheable (Expires: weeks),=0A>> so it's 1 round trip in practice, but=
 I won't fight (too much)=0A>> *optional* parameters in the 1st request to =
possibly skip the 2nd=0A>> request.=A0 It worries me, though.=A0 I'd rather=
 see that optimization added=0A>> in a subsequent version of the spec, so a=
ll 1.0 implementations have=0A>> then shown that they're capable of perform=
ing the base algorithm.=A0 I=0A>> worry that too many servers will implemen=
t the optimization and then=0A>> lazy clients will become pervasive which o=
nly do one round trip, thus=0A>> making the "optional" optimization now de =
facto required for servers.=0A>> So I'd really rather drop that from the sp=
ec too.=A0 Let's add it only=0A>> later, once it's shown to be needed.=A0 A=
s is, clients could even fire off=0A>> two HTTP requests in parallel to red=
uce latency, one for host-meta and=0A>> one optimistically for the presumed=
 host-meta location in cases of big=0A>> hosts that rarely change, or expir=
ed cached host-meta documents.=0A>=0A>We support both.=A0 RFC 6415 defined =
the base for 2 round trips.=A0 The current WF spec adds that extension to a=
llow for one round trip.=0A>=0A>And both are trivially implemented, so simp=
le it can be done via static files with an Apache server:=0A>http://www.pac=
ketizer.com/webfinger/server.html=0A>=0A>> I will continue to fight for Goo=
gle's WebFinger support, but I'm not the=0A>> only one losing patience.=0A>=
=0A>You're right there, which is why I'm serving the role of editor.=A0 I'm=
 personally pretty happy with the way things are currently defined.=A0 Asid=
e from the vast number of comments regarding privacy, I'm not hearing a lot=
 in the way of technical issues.=A0 I'd like to move forward.=0A>=0A>> Ever=
ybody please hurry up, simplify, then hurry up.=A0 I'll help however I=0A>>=
 can.=A0 I'm not sure whether this was helpful.=0A>=0A>It's doesn't get muc=
h simpler than this:=0A>=0A>=A0=A0=A0curl https://packetizer.com/.well-know=
n/host-meta.json?=0A>=A0 =A0 =A0 =A0 resource=3Dacct:paulej@packetizer.com=
=0A>=0A>Now we need to just move on to agreeing on some useful link relatio=
ns for WF.=0A>=0A>Paul=0A>=0A>=0A>_________________________________________=
______=0A>apps-discuss mailing list=0A>apps-discuss@ietf.org=0A>https://www=
.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A>

From wmills@yahoo-inc.com  Wed Oct 31 19:45:23 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F1D21F85E1 for ; Wed, 31 Oct 2012 19:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.045
X-Spam-Level: 
X-Spam-Status: No, score=-14.045 tagged_above=-999 required=5 tests=[AWL=-2.904, BAYES_50=0.001, FRT_PROFIT1=3.858, 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 kwqGbaZQqnu7 for ; Wed, 31 Oct 2012 19:45:23 -0700 (PDT)
Received: from nm8-vm0.bullet.mail.ac4.yahoo.com (nm8-vm0.bullet.mail.ac4.yahoo.com [98.139.52.230]) by ietfa.amsl.com (Postfix) with ESMTP id CCCFF21F85E0 for ; Wed, 31 Oct 2012 19:45:22 -0700 (PDT)
Received: from [98.139.52.195] by nm8.bullet.mail.ac4.yahoo.com with NNFMP; 01 Nov 2012 02:45:19 -0000
Received: from [98.139.52.160] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 01 Nov 2012 02:45:19 -0000
Received: from [127.0.0.1] by omp1043.mail.ac4.yahoo.com with NNFMP; 01 Nov 2012 02:45:19 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 918486.17062.bm@omp1043.mail.ac4.yahoo.com
Received: (qmail 93044 invoked by uid 60001); 1 Nov 2012 02:45:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1351737919; bh=SOdIoskZWDZgj/ZA3TF+Wr+nX2dlX4RzWYDri93WIu0=; 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:Content-Transfer-Encoding; b=Pc17J2qm7PrA7OX9bSyHjNEWGxZoMUMFWf29cWi8r8o9iPozrtaecklL8Wk8BhFRLJTjT6zsjIZmVKQn8tYVaNel+H+z/wdiaAmAb45wE/vZ28NQT1xIcWAAS6bALuJj8S6C6vxbuWf53En0RG8tCN4OGrC0FlGEy9amesMGdEc=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.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:Content-Transfer-Encoding; b=WzwwxFPuzSWDIwq30H1Bnmu5ROlgesnBb5A2mrgqg5xTQDuQ3Z4PoLm7iipPuHkvWPFzl/3Fm46g9qyRzH6zmm3Mr7NPjOZgg2sj0Chmv6EqD9dR0zoMw+LO1Mla/JuqGZOdVFl4gcDdMlo+ule6Fu8X2rZdmsf97AHdAum3f2o=;
X-YMail-OSG: lHKyVBkVM1kJTgmvV1zetOXooYhAAp.QvpzittBfhJuVA2c ohU9GpoGwDNrzLUzw__chCE5v0gpv7RC91VioWy2WQ4d_uLv8Mn4cMAknEdv khZSe06uaTlrOqeaZUHTxgmh5.B3It08Md8P9JoGNfy6VFzzOF7cirO4kQm5 CHzDXvGMZj00Gh46Y8VZb35X_ShhFg7R18RVvOMZQuz3rPmRZcTUWeI7ZOSk kjQlYn.QDaQoNi4fh.V8CIt3StDuYLM8ysDua1knVY6KH2KjS2zYqYftWmLC fYFC8f4jlaVljQMD7VR985gvRqv6jE2aUloG6N2XNTzK8Qu4ikwa.panOL0o Q87xWTfg37Xd1jtZNeS3IfjTmTQTjadOCVUqrpen4VxGI8YDGuXKdlreSIBs 2NR6MqQcrzYF3S.bW23GTrTjjnZZOfqo7EvAY.QDA.YaZmzUPeOm_R3Ji6.J 1DHGxoxFi_VOwxHLhNUtYb09KGnbASMRgGqAU64XuUykBVyXE0I53nawrf4C 0Ieq8z3UsKKW58JRNYAHkx.ZoPN9b8x6CskyWTJsoUXxF18r9swIuNBxNDr2 1gE0netaFbuL5QynZGSwF0H2SEVhnyPZQPPI-
Received: from [99.31.212.42] by web31801.mail.mud.yahoo.com via HTTP; Wed, 31 Oct 2012 19:45:19 PDT
X-Rocket-MIMEInfo: 001.001, Cj5Ob3cgd2UgbmVlZCB0byBqdXN0IG1vdmUgb24gdG8gYWdyZWVpbmcgb24gc29tZSB1c2VmdWwgbGluayByZWxhdGlvbnMgZm9yIFdGLgoKRllJIHRoZSBsaW5rIHJlbGF0aW9ucyBmb3IgT0F1dGggYXJlIGRlZmluZWQgYW5kIGhhdmUgYmVlbiBhY2NlcHRlZCBpbiB0aGUgSVNFIHB1YmxpY2F0aW9uIHRyYWNrIGFzIGFuIGluZm9ybWF0aW9uYWwgUkZDLgoKCgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBQYXVsIEUuIEpvbmVzIDxwYXVsZWpAcGFja2V0aXplci5jb20.Cj4BMAEBAQE-
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.123.460
References:  <00c401cdb7c0$55fe5eb0$01fb1c10$@packetizer.com>
Message-ID: <1351737919.91701.YahooMailNeo@web31801.mail.mud.yahoo.com>
Date: Wed, 31 Oct 2012 19:45:19 -0700 (PDT)
From: William Mills 
To: "Paul E. Jones" , "webfinger@googlegroups.com" , "public-fedsocweb@w3.org" 
In-Reply-To: <00c401cdb7c0$55fe5eb0$01fb1c10$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] WebFinger compromises
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, 01 Nov 2012 02:45:23 -0000

=0A>Now we need to just move on to agreeing on some useful link relations f=
or WF.=0A=0AFYI the link relations for OAuth are defined and have been acce=
pted in the ISE publication track as an informational RFC.=0A=0A=0A=0A=0A=
=0A=0A>________________________________=0A> From: Paul E. Jones =0A>To: webfinger@googlegroups.com; public-fedsocweb@w3.org =0A=
>Cc: apps-discuss@ietf.org =0A>Sent: Wednesday, October 31, 2012 4:34 PM=0A=
>Subject: Re: [apps-discuss] WebFinger compromises=0A> =0A>Brad,=0A>=0A>> T=
o everybody who recently saw me rant about WebFinger in person=0A>> recentl=
y, hello again.=0A>=0A>Oh, I wish I was there... ;-)=0A>=0A>> To everybody =
else, a brief summary:=0A>> =0A>> -- I was an early WebFinger evangelist. I=
 remember discussing it at=0A>> conferences for years before it sorta becam=
e a thing. I think I even=0A>> named it?=0A>=0A>Cool! Always wondered where=
 the name came from.=0A>=0A>> -- I added Google's WebFinger support=0A>> (h=
ttps://groups.google.com/group/webfinger/msg/e8df6402708841ea)=0A>=0A>That =
also answers questions kept asking when I mentioned Google had support for =
it.=0A>=0A>> -- I think it's critically important for the Internet to prese=
rve=0A>> user@host.com hierarchical identifiers before email gets too passe=
 and=0A>> we're stuck with single-namespaced walled gardens.=A0 It's on us =
to make=0A>> email-looking identifiers more useful to compete with all the =
latest=0A>> proprietary silo hotness, before the people of the internet no =
longer=0A>> recognize them.=0A>=0A>That WF has done.=0A>=0A>> (trying to es=
tablish that I'm a friend here)=0A>> =0A>> That said,=0A>=0A>(gulp)=0A>=0A>=
> -- this is the slowest moving community ever (I accept part of the blame=
=0A>> here)=0A>=0A>No kidding.=A0 Some I-Ds take 8 or more years in the IET=
F.=A0 By the time we make it perfect, the "opportunity has set sail"... I'v=
e seen that happen several times.=A0 Then people ask why we don't standardi=
ze some things.=A0 It's the process sometimes.=A0 Standardization is not al=
ways worth it.=0A>=0A>> -- can we please stop changing things?=A0 -- JSON, =
XRD, great, whatever.=0A>> But let's just pick one.=A0 If JSON is now the h=
otness, let's pick *only*=0A>> JSON.=A0 Specs that say "X is required but y=
ou can maybe do Y if you want=0A>> to" just reek of political compromise to=
 gain a certain party's favor.=0A>> Look at OpenID 2.0.=A0 (I remember bein=
g sad about those political moves=0A>> too, but I had lost the energy to fi=
ght)=0A>=0A>The current language actually isn't political compromise, but m=
ore my desire to not break backward-compatibility any more than we have to.=
=A0 Current spec recognizes, for example, that Google's WF server serves up=
 XML.=A0 Clients expecting XML will still work.=A0 So long as any WF server=
 wants to support both, those clients will work.=0A>=0A>Going forward, XML =
is optional and JSON is mandatory.=A0 I wanted to mandate both, but lost th=
at argument.=A0 (Still, supporting both is simple.=A0 My server does both a=
nd will honor the Accept header.=A0 It's trivial to do.)=0A>=0A>At some poi=
nt, I will publish my server code.=A0 It's just a simple Perl script, but s=
hows how trivial it is to implement a WF server.=A0 It does both XML and JS=
ON and I do wish we would continue with both.=0A>=0A>Further, I accept the =
preference for JSON and only putting the requirement there.=A0 But the fact=
 is that any web resource can return ANY format.=A0 This is a basic part of=
 HTTP and the reason the Accept header exists.=A0 So we should design the s=
ervice such that we can support whatever the next hot format is.=0A>=0A>So,=
 my position is:=0A>1) Let's not just kill XML because we decided we do not=
 like it this week (killing all hope for backward-compatibility)=0A>2) Let'=
s have a web service that could serve XML or JSON or next-hot-thing (i.e., =
future-proof it)=0A>3) Let's use HTTP the way it is supposed to be used and=
 allow the "Accept" header to work via /.well-known/host-meta.=0A>4) Since =
host-meta.json is already defined (and I would have argued against it, but =
it's there), let's fully embrace it.=0A>=0A>> -- My recommendation: just re=
move all mention of XRD from the latest=0A>> WebFinger spec.=A0 Yes, this i=
s counter to my "please stop changing=0A>> things" bullet earlier.=A0 But W=
ebFinger has a better chance of success if=0A>> it's a simple spec.=A0 And =
you're not breaking compatibility with anybody=0A>> because *nobody uses We=
bFinger*.=0A>=0A>I'd prefer not to for the above-stated reasons.=A0 Note th=
at only JSON is required.=0A>=0A>> -- 1 round trip, 2 round trips. Don't re=
ally care. 2 round trips keeps=0A>> the spec simpler and the 1st will be hi=
ghly cacheable (Expires: weeks),=0A>> so it's 1 round trip in practice, but=
 I won't fight (too much)=0A>> *optional* parameters in the 1st request to =
possibly skip the 2nd=0A>> request.=A0 It worries me, though.=A0 I'd rather=
 see that optimization added=0A>> in a subsequent version of the spec, so a=
ll 1.0 implementations have=0A>> then shown that they're capable of perform=
ing the base algorithm.=A0 I=0A>> worry that too many servers will implemen=
t the optimization and then=0A>> lazy clients will become pervasive which o=
nly do one round trip, thus=0A>> making the "optional" optimization now de =
facto required for servers.=0A>> So I'd really rather drop that from the sp=
ec too.=A0 Let's add it only=0A>> later, once it's shown to be needed.=A0 A=
s is, clients could even fire off=0A>> two HTTP requests in parallel to red=
uce latency, one for host-meta and=0A>> one optimistically for the presumed=
 host-meta location in cases of big=0A>> hosts that rarely change, or expir=
ed cached host-meta documents.=0A>=0A>We support both.=A0 RFC 6415 defined =
the base for 2 round trips.=A0 The current WF spec adds that extension to a=
llow for one round trip.=0A>=0A>And both are trivially implemented, so simp=
le it can be done via static files with an Apache server:=0A>http://www.pac=
ketizer.com/webfinger/server.html=0A>=0A>> I will continue to fight for Goo=
gle's WebFinger support, but I'm not the=0A>> only one losing patience.=0A>=
=0A>You're right there, which is why I'm serving the role of editor.=A0 I'm=
 personally pretty happy with the way things are currently defined.=A0 Asid=
e from the vast number of comments regarding privacy, I'm not hearing a lot=
 in the way of technical issues.=A0 I'd like to move forward.=0A>=0A>> Ever=
ybody please hurry up, simplify, then hurry up.=A0 I'll help however I=0A>>=
 can.=A0 I'm not sure whether this was helpful.=0A>=0A>It's doesn't get muc=
h simpler than this:=0A>=0A>=A0=A0=A0curl https://packetizer.com/.well-know=
n/host-meta.json?=0A>=A0 =A0 =A0 =A0 resource=3Dacct:paulej@packetizer.com=
=0A>=0A>Now we need to just move on to agreeing on some useful link relatio=
ns for WF.=0A>=0A>Paul=0A>=0A>=0A>_________________________________________=
______=0A>apps-discuss mailing list=0A>apps-discuss@ietf.org=0A>https://www=
.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A>

From gsalguei@cisco.com  Wed Oct 31 19:45:45 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036FF21F85E7 for ; Wed, 31 Oct 2012 19:45:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzVxYCd34R9O for ; Wed, 31 Oct 2012 19:45:44 -0700 (PDT)
Received: from av-tac-sj.cisco.com (av-tac-sj.cisco.com [171.68.227.119]) by ietfa.amsl.com (Postfix) with ESMTP id 6722821F85DA for ; Wed, 31 Oct 2012 19:45:44 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA12jgc2002379 for ; Wed, 31 Oct 2012 19:45:43 -0700 (PDT)
Received: from rtp-gsalguei-8914.cisco.com (rtp-gsalguei-8914.cisco.com [10.116.132.53]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA12jakF003854; Wed, 31 Oct 2012 22:45:36 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Gonzalo Salgueiro 
In-Reply-To: <1351737760.135.YahooMailNeo@web31803.mail.mud.yahoo.com>
Date: Wed, 31 Oct 2012 22:45:35 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <4AB2C601-4D03-4D11-9FC3-A930670A14F7@cisco.com>
References: <508E66FB.4070708@cs.tcd.ie> <0b3b01cdb61c$981dc600$c8595200$@packetizer.com> <508F0870.9050402@cs.tcd.ie> <0b9901cdb636$bf951480$3ebf3d80$@packetizer.com> <508F2B78.2000006@cs.tcd.ie> <0be001cdb64b$eb574560$c205d020$@packetizer.com> <508FA55F.5020608@cs.tcd.ie> <5FC89052-EE84-4C80-BEE8-ABAD7C784F5A@gmx.net> <6.2.5.6.2.20121030093556.0a82b130@resistor.net> <00ee01cdb701$7a68ef00$6f3acd00$@packetizer.com> <6.2.5.6.2.20121030230234.0b40f3c8@resistor.net>   <00c201cdb7bb$a0dfc7c0$e29f5740$@packetizer.com> <1351737760.135.YahooMailNeo@web31803.mail.mud.yahoo.com>
To: William Mills 
X-Mailer: Apple Mail (2.1283)
Cc: 'General discussion of application-layer protocols' 
Subject: Re: [apps-discuss] webfinger privacy question/suggestion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 01 Nov 2012 02:45:45 -0000

+1

Not to say it isn't important, I just think it is outside the scope of =
WF and current draft under discussion.

--G

On Oct 31, 2012, at 10:42 PM, William Mills wrote:

> It is probably up to the service to determine whether they return =
different information to an authenticated context.  Auth method and =
behavior is outsied the scope of WF I think.
>=20
>=20
> From: Paul E. Jones 
> To: 'Hannes Tschofenig' ; 'Phillip =
Hallam-Baker' =20
> Cc: 'General discussion of application-layer protocols' =
=20
> Sent: Wednesday, October 31, 2012 4:01 PM
> Subject: Re: [apps-discuss] webfinger privacy question/suggestion
>=20
> Hannes,
>=20
> I'm not sure if it is possible to use OAuth with
> /.well-known/host-meta.json.
>=20
> Can OAuth be used to protect any resource on the Internet?  If so, it =
could
> be used to control access to /.well-known/host-meta.*.  For certain, =
all of
> the link relations provided could be protected with any authentication
> scheme.  Just because my WF server provides the link to my address =
book does
> not mean anyone would have authorization to retrieve it.
>=20
> Sometimes I wonder if people have forgotten or not considered that =
fact.
> Certain information is revealed just from the JRD document itself =
(e.g., the
> very fact I have some piece of data published), but the actual =
referenced
> document can be tightly controlled.
>=20
> Within a corporate environment, I would even expect an internal WF =
query to
> return different results than an external one.  That would not require
> OAuth, but would be controlled based on whatever mechanism is used to
> determine if a person has access rights as an employee.
>=20
> Paul
>=20
> > -----Original Message-----
> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> > bounces@ietf.org] On Behalf Of Hannes Tschofenig
> > Sent: Wednesday, October 31, 2012 9:06 AM
> > To: Phillip Hallam-Baker
> > Cc: General discussion of application-layer protocols
> > Subject: Re: [apps-discuss] webfinger privacy question/suggestion
> >=20
> > Hi Phillip,
> >=20
> > On Oct 31, 2012, at 2:20 PM, Phillip Hallam-Baker wrote:
> >=20
> > > Javascript which basically was designed by people who only cared =
about
> > goosing their stock options.
> >=20
> > I do not disagree with you here but WebFinger by itself does not
> > necessarily need to be implemented in JavaScript(*).
> >=20
> > > 'is Web finger helping people to do the sorts of things that users
> > want without unexpected privacy side effects'
> >=20
> > There are use cases where people want to use WebFinger as a =
discovery
> > mechanism (such as OAuth) where the current design of WebFinger
> > introduces privacy problems (unnecessarily). I raised this issue =
last
> > year in May:
> > http://www.ietf.org/mail-archive/web/oauth/current/msg08965.html
> >=20
> > It seems that WebFinger has become a solution in search of a problem =
for
> > some people.
> >=20
> > Ciao
> > Hannes
> >=20
> > PS: (*) In the context of the use case I care about (namely identity
> > management) implementations of JavaScript tend to have serious =
security
> > problems.
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From paulej@packetizer.com  Wed Oct 31 21:16:18 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2074F21F85C1 for ; Wed, 31 Oct 2012 21:16:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.967
X-Spam-Level: 
X-Spam-Status: No, score=0.967 tagged_above=-999 required=5 tests=[AWL=-2.893,  BAYES_50=0.001, FRT_PROFIT1=3.858, 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 0WoAuIdf7b09 for ; Wed, 31 Oct 2012 21:16:16 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD2721F85BF for ; Wed, 31 Oct 2012 21:16:16 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qA14GDXi012002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Nov 2012 00:16:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351743375; bh=prabpdm81EQgJ6Yq7yaENmaQVT5ehU7CsiKbqxdJbbA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=aPXqdrXQq4MYZMzuzVW9Wko2MiKvmxar4r3EnBn70KOrTPbrRG0PLzjk1nCM+hedI H7VS9VPAF/f/Uul9eVW4qZxAhjrIKzJrP73lykdK7ZBWbBMU9LtIRr0h6Sdbk2CTbT f1zYv/C4DMdEdC8HKMkhDBeghu9BS/uV8D/tuzII=
From: "Paul E. Jones" 
To: 
References: 	<00c401cdb7c0$55fe5eb0$01fb1c10$@packetizer.com> 
In-Reply-To: 
Date: Thu, 1 Nov 2012 00:16:19 -0400
Message-ID: <00e201cdb7e7$a5a67390$f0f35ab0$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E3_01CDB7C6.1E9792B0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGiIkVUmNNt45MdKJ8yW+kdIunFwgE9pthfAYryTFiYFTO64A==
Content-Language: en-us
Cc: public-fedsocweb@w3.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] WebFinger compromises
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 01 Nov 2012 04:16:18 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00E3_01CDB7C6.1E9792B0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Brad,

=20

Comments in green:

=20

=20

The current language actually isn't political compromise, but more my =
desire to not break backward-compatibility any more than we have to.  =
Current spec recognizes, for example, that Google's WF server serves up =
XML.

=20

If I change it to CSV tomorrow, will the spec recognize that?

=20

PEJ: The spec does not say that explicitly, but it says that =
/.well-known/host-meta defaults to XML. If a different format is desired =
(and the only one mentioned is JSON), it must be requested using the =
Accept header.  That=E2=80=99s the way web interfaces are supposed to =
work, after all.  So while I don=E2=80=99t have any expectation of a new =
format being introduced soon, this allows the possibility and I do think =
we should allow for that possibility.  Within an enterprise environment, =
perhaps there is a CSV format preferred and it=E2=80=99s selected using =
Accept.=20

=20

Seriously, don't regard at all what Google does today.  It can change on =
a moment's notice if this thing every shows promise of stabilizing.  The =
only reason it doesn't support JSON today is that I got bored of this =
process.

=20

PEJ: Google is just one implementation.  There are others and =
I=E2=80=99ve been asked to try to not break them.  The way the spec is =
written, what works continues to work.  More importantly, it trivial as =
hell to maintain that backward-compatibility.  One might even view it as =
forward-compatibility, too.  I do think we should definitely design for =
use of other data formats in the future, and that is built in.

=20

 Clients expecting XML will still work.

=20

How?? The spec says only JSON is required?

=20

PEJ: I was referring to existing clients and servers.  Any new JSON-only =
servers will not work with XML-only clients.  That=E2=80=99s to be =
expected and that=E2=80=99s OK. There is no loss of existing =
functionality.=20

=20

=20

 So long as any WF server wants to support both, those clients will =
work.

=20

I might advocate for our webfinger implementation to only return =
XML-as-requested 25% of the time.  That would be more hilarious than the =
0% as required by the spec.

=20

PEJ: Now that would be ugly.  At least consistently work or =
fail=E2=80=A6 ;-)=20

=20

=20

Going forward, XML is optional and JSON is mandatory.  I wanted to =
mandate both, but lost that argument.  (Still, supporting both is =
simple.  My server does both and will honor the Accept header.  It's =
trivial to do.)

At some point, I will publish my server code.  It's just a simple Perl =
script, but shows how trivial it is to implement a WF server.  It does =
both XML and JSON and I do wish we would continue with both.

=20

Do not even talk about implementations.  Implementations are always =
easy.  I made that mistake in the past, trying to convince people how =
easy things are by showing code.

=20

What is harder is winning mindshare, and overly large, schizophrenic =
specs don't instill confidence in would-be supporters.

=20

PEJ: I=E2=80=99ve seen it go both ways.  Sometimes, if you just build it =
people ignore it, because it=E2=80=99s not a standard. Sometimes if you =
write the standard, then people open their eyes.  A useful demo might =
help, such as having Chrome respond to =E2=80=9Cacct=E2=80=9D URIs and =
display a =E2=80=9Cprofile=E2=80=9D page in the browser, pulling info =
from the WF server and following the links.  Such highly visual =
demonstrations work better than code in a server or specs on paper.

=20

Further, I accept the preference for JSON and only putting the =
requirement there.  But the fact is that any web resource can return ANY =
format.  This is a basic part of HTTP and the reason the Accept header =
exists.

=20

So why don't you document the image/gif response type in the spec?  =
(Because it would be noise.)

=20

Just as I can file my own RFC entitled "Recommendations for serving =
image/gif response payloads in Content-Type-negotiated WebFinger =
queries", so can the XRD community.

=20

The WebFinger spec is only required to document the requirements, not =
ponies.

=20

PEJ: The spec does only list the requirements (and procedures). =
There=E2=80=99s no point documenting how to send any other format than =
those that actually exist in practice.  My only point is that I think we =
should try to ensure the protocol aligns with the intent of HTTP and =
support other types should ever a day come.  It may never happen, but we =
should not box ourselves into a corner, either, especially when the HTTP =
spec explains how it should work.

=20

=20

So we should design the service such that we can support whatever the =
next hot format is.

=20

I do not object to you clarifying that "WebFinger MAY return alternate =
response types, if requested by the client with an HTTP Accept header =
blah blah blah in the absence of an such a header, the default is JSON =
etc etc"

=20

PEJ: That=E2=80=99s what is says for host-meta.json. Strictly because =
there are some existing implementations, it says the default for =
host-meta is XML.  I can change that, but I feel like the guy in the =
middle with people on one side yelling =E2=80=9Cto hell with =
XML=E2=80=9D and people on the other side saying =E2=80=9Cwe already =
have that implemented!=E2=80=9D  Leaving the text as it is addresses =
every concern, except for those who hate seeing the word XML or XRD. ;-) =
Because I even uttered the word =E2=80=93 introduced no requirements on =
new servers =E2=80=93 it is said to be complex.  If I change the text, =
it does not change the implementation requirements in the least if one =
only implements JSON.=20

=20


So, my position is:
1) Let's not just kill XML because we decided we do not like it this =
week (killing all hope for backward-compatibility)

=20

Let's kill it because it's not required.  I neither like nor dislike it. =
 I also neither like nor dislike JSON.  I just think it's stupid for a =
spec to not decide.

=20

PEJ: But it is decided.  Requirement is JSON. People writing code =
tomorrow ONLY have to worry about JSON, both client-side and server =
side.  *If* people want to use XML, then the spec explains how that is =
done, but it is not a mandatory feature, thus it will not be universally =
implemented.

=20

I'm entering this mailing list again because it has no deciders.  =
Everybody just keeps saying "yes, sure, we'll add that to" (as far as I =
can tell).

=20

PEJ: We=E2=80=99ve not added any new features in a long time.  We have =
moved XML to the =E2=80=9Coptional=E2=80=9D status, we removed the =
=E2=80=9Cacct=E2=80=9D URI scheme to a separate document, and next on =
the list (IMO) should be the =E2=80=9Cacct=E2=80=9D link relation =
(moving to a separate doc).  It has only gotten simpler, in other words.

=20

2) Let's have a web service that could serve XML or JSON or =
next-hot-thing (i.e., future-proof it)

=20

Don't disagree.

=20

3) Let's use HTTP the way it is supposed to be used and allow the =
"Accept" header to work via /.well-known/host-meta.

=20

Don't disagree.

=20

4) Since host-meta.json is already defined (and I would have argued =
against it, but it's there), let's fully embrace it.

=20

That's fine.  I'm not against supporting that.

=20

[snip]


> -- 1 round trip, 2 round trips. Don't really care. 2 round trips keeps
> the spec simpler and the 1st will be highly cacheable (Expires: =
weeks),
> so it's 1 round trip in practice, but I won't fight (too much)
> *optional* parameters in the 1st request to possibly skip the 2nd
> request.  It worries me, though.  I'd rather see that optimization =
added
> in a subsequent version of the spec, so all 1.0 implementations have
> then shown that they're capable of performing the base algorithm.  I
> worry that too many servers will implement the optimization and then
> lazy clients will become pervasive which only do one round trip, thus
> making the "optional" optimization now de facto required for servers.
> So I'd really rather drop that from the spec too.  Let's add it only
> later, once it's shown to be needed.  As is, clients could even fire =
off
> two HTTP requests in parallel to reduce latency, one for host-meta and
> one optimistically for the presumed host-meta location in cases of big
> hosts that rarely change, or expired cached host-meta documents.

We support both.  RFC 6415 defined the base for 2 round trips.  The =
current WF spec adds that extension to allow for one round trip.

=20

Please acknowledge my argument, even if you don't agree with it.  Do you =
understand my description of how I fear it will become a de-facto =
requirement?

=20

PEJ: The =E2=80=9Cresource=E2=80=9D parameter (allowing one round trip) =
is mandatory in the spec currently.  I originally introduced it (at Eran =
Hammer-Lahav=E2=80=99s request) as =E2=80=9Coptional=E2=80=9D.  The =
group was fairly keen on making that mandatory, pushing for the =
requirement even before the text was adopted as a WG item.  So, the de =
facto standard you fear is the standard (per the current text).  Do you =
not want to mandate the =E2=80=9Cresource=E2=80=9D parameter? It has =
been mandatory since the draft published in May this year.

=20

=20

> I will continue to fight for Google's WebFinger support, but I'm not =
the
> only one losing patience.

You're right there, which is why I'm serving the role of editor.

=20

I thank you for that, because it's a largely thankless job.  I'm coming =
across as aggressive, but I really want this to work, and I view =
everybody on these mailing lists as friends.  I just think we all need a =
reality check.

=20

PEJ: Aggressive?  You=E2=80=99re mild compared to some others. :-)  =
People feel passionate about different things.  I also just want this to =
work.  I see a lot of potential with WF for enriching social networking, =
enterprise applications, etc.

=20

> Everybody please hurry up, simplify, then hurry up.  I'll help however =
I
> can.  I'm not sure whether this was helpful.

It's doesn't get much simpler than this:

   curl https://packetizer.com/.well-known/host-meta.json?
        resource=3Dacct:paulej@packetizer.com =
=20

=20

 Again, implementation.  Everybody on this mailing list can write a =
static webserver.

=20

PEJ: That one isn=E2=80=99t static: it=E2=80=99s pulling data from a =
live database and formatting is per the client=E2=80=99s request. But to =
your point, many people on this list could build that server code, too.  =
The reason I wrote that was to demonstrate its functionality and to help =
those who cannot build one themselves.  I do want to ensure anyone with =
a domain can throw up a WF server.

=20

Now we need to just move on to agreeing on some useful link relations =
for WF.

=20

I will stay out of your way there.  I just want a simple base to build =
upon.

=20

PEJ: Yeah, so how do we get to that thing we can build on?  Current =
requirements =E2=80=A6 bare bone =E2=80=A6 are:

=C2=B7         Servers must support JSON, may support XRD (or TLV or =
whatever)

=C2=B7         Servers must make /.well-known/host-meta and =
/.well-known/host-meta.json resources accessible

=C2=B7         Servers must support the =E2=80=9Cresource=E2=80=9D =
parameter

This means the vanilla client on the Internet will query only for JSON.  =
Client developers have mostly said they want the simplest possible =
solution, which means most will send requests with the =
=E2=80=9Cresource=E2=80=9D parameter.  More than one has expressed a =
desire to be able to cache /.well-known/host-meta to speed processing of =
resource-specific queries.

=20

Personally, I think we have the solution in hand. If I change one thing, =
there is somebody who will not be happy.  As compromises go, I think =
we=E2=80=99ve done pretty well.  I say that, because I know one can =
build both a client and server implementation quite easily and only one =
format they need to consider.

=20

Paul

=20


------=_NextPart_000_00E3_01CDB7C6.1E9792B0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Brad,
 
Comments in green:
 
 
The current =
language actually isn't political compromise, but more my desire to not =
break backward-compatibility any more than we have to.  Current =
spec recognizes, for example, that Google's WF server serves up =
XML.
 
If I change =
it to CSV tomorrow, will the spec recognize =
that?
 
PEJ: The spec does not say that explicitly, but it says that =
/.well-known/host-meta defaults to XML. If a different format is desired =
(and the only one mentioned is JSON), it must be requested using the =
Accept header.=C2=A0 That=E2=80=99s the way web interfaces are supposed =
to work, after all.=C2=A0 So while I don=E2=80=99t have any expectation =
of a new format being introduced soon, this allows the possibility and I =
do think we should allow for that possibility.=C2=A0 Within an =
enterprise environment, perhaps there is a CSV format preferred and =
it=E2=80=99s selected using Accept. 
 
Seriously, =
don't regard at all what Google does today.  It can change on a =
moment's notice if this thing every shows promise of stabilizing. =
 The only reason it doesn't support JSON today is that I got bored =
of this process.
 
PEJ: Google is just one implementation.=C2=A0 There are others and =
I=E2=80=99ve been asked to try to not break them.=C2=A0 The way the spec =
is written, what works continues to work.=C2=A0 More importantly, it =
trivial as hell to maintain that backward-compatibility.=C2=A0 One might =
even view it as forward-compatibility, too.=C2=A0 I do think we should =
definitely design for use of other data formats in the future, and that =
is built in.
 
 Clients=
 expecting XML will still =
work.
 
How?? The =
spec says only JSON is required?
 
PEJ: I was referring to existing clients and servers.=C2=A0 Any new =
JSON-only servers will not work with XML-only clients.=C2=A0 =
That=E2=80=99s to be expected and that=E2=80=99s OK. There is no loss of =
existing functionality. 
 
 
 So =
long as any WF server wants to support both, those clients will =
work.
 
I might =
advocate for our webfinger implementation to only return =
XML-as-requested 25% of the time.  That would be more hilarious =
than the 0% as required by the spec.
 
PEJ: Now that would be ugly.=C2=A0 At least consistently work or =
fail=E2=80=A6 ;-) 
 
 
Going =
forward, XML is optional and JSON is mandatory.  I wanted to =
mandate both, but lost that argument.  (Still, supporting both is =
simple.  My server does both and will honor the Accept header. =
 It's trivial to do.)

At some point, I will publish my =
server code.  It's just a simple Perl script, but shows how trivial =
it is to implement a WF server.  It does both XML and JSON and I do =
wish we would continue with =
both.
 
Do not even =
talk about implementations.  Implementations are always easy. =
 I made that mistake in the past, trying to convince people how =
easy things are by showing code.
 
What is =
harder is winning mindshare, and overly large, schizophrenic specs don't =
instill confidence in would-be supporters.
 
PEJ: I=E2=80=99ve seen it go both ways.=C2=A0 Sometimes, if you just =
build it people ignore it, because it=E2=80=99s not a standard. =
Sometimes if you write the standard, then people open their eyes.=C2=A0 =
A useful demo might help, such as having Chrome respond to =
=E2=80=9Cacct=E2=80=9D URIs and display a =E2=80=9Cprofile=E2=80=9D page =
in the browser, pulling info from the WF server and following the =
links.=C2=A0 Such highly visual demonstrations work better than code in =
a server or specs on paper.
 
Further, I =
accept the preference for JSON and only putting the requirement there. =
 But the fact is that any web resource can return ANY format. =
 This is a basic part of HTTP and the reason the Accept header =
exists.
 
So why don't =
you document the image/gif response type in the spec?  (Because it =
would be noise.)
 
Just as I =
can file my own RFC entitled "Recommendations for serving image/gif =
response payloads in Content-Type-negotiated WebFinger queries", so =
can the XRD community.
 
The =
WebFinger spec is only required to document the requirements, not =
ponies.
 
PEJ: The spec does only list the requirements (and procedures). =
There=E2=80=99s no point documenting how to send any other format than =
those that actually exist in practice.=C2=A0 My only point is that I =
think we should try to ensure the protocol aligns with the intent =
of HTTP and support other types should ever a day come.=C2=A0 It may =
never happen, but we should not box ourselves into a corner, either, =
especially when the HTTP spec explains how it should =
work.
 
 
So we should =
design the service such that we can support whatever the next hot format =
is.
 
I do not =
object to you clarifying that "WebFinger MAY return alternate =
response types, if requested by the client with an HTTP Accept header =
blah blah blah in the absence of an such a header, the default is JSON =
etc etc"
 
PEJ: That=E2=80=99s what is says for host-meta.json. Strictly because =
there are some existing implementations, it says the default for =
host-meta is XML.=C2=A0 I can change that, but I feel like the guy in =
the middle with people on one side yelling =E2=80=9Cto hell with =
XML=E2=80=9D and people on the other side saying =E2=80=9Cwe already =
have that implemented!=E2=80=9D=C2=A0 Leaving the text as it is =
addresses every concern, except for those who hate seeing the word XML =
or XRD. ;-) Because I even uttered the word =E2=80=93 introduced no =
requirements on new servers =E2=80=93 it is said to be complex.=C2=A0 If =
I change the text, it does not change the implementation requirements in =
the least if one only implements JSON. 
 

So, my =
position is:
1) Let's not just kill XML because we decided we do not =
like it this week (killing all hope for =
backward-compatibility)
 
Let's kill =
it because it's not required.  I neither like nor dislike it. =
 I also neither like nor dislike JSON.  I just think it's =
stupid for a spec to not decide.
 
PEJ: But it is decided.=C2=A0 Requirement is JSON. People writing =
code tomorrow ONLY have to worry about JSON, both client-side and server =
side.=C2=A0 *If* people want to use XML, then the spec explains =
how that is done, but it is not a mandatory feature, thus it will not be =
universally implemented.
 
I'm entering =
this mailing list again because it has no deciders.  Everybody just =
keeps saying "yes, sure, we'll add that to" (as far as I can =
tell).
 
PEJ: We=E2=80=99ve not added any new features in a long time.=C2=A0 =
We have moved XML to the =E2=80=9Coptional=E2=80=9D status, we removed =
the =E2=80=9Cacct=E2=80=9D URI scheme to a separate document, and next =
on the list (IMO) should be the =E2=80=9Cacct=E2=80=9D link relation =
(moving to a separate doc).=C2=A0 It has only gotten simpler, in other =
words.
 
2) Let's =
have a web service that could serve XML or JSON or next-hot-thing (i.e., =
future-proof it)
 
Don't =
disagree.
 
3) Let's use =
HTTP the way it is supposed to be used and allow the "Accept" =
header to work via =
/.well-known/host-meta.
 
Don't =
disagree.
 
4) Since =
host-meta.json is already defined (and I would have argued against it, =
but it's there), let's fully embrace =
it.
 
That's fine. =
 I'm not against supporting =
that.
 
[snip]

> -- =
1 round trip, 2 round trips. Don't really care. 2 round trips =
keeps
> the spec simpler and the 1st will be highly cacheable =
(Expires: weeks),
> so it's 1 round trip in practice, but I won't =
fight (too much)
> *optional* parameters in the 1st request to =
possibly skip the 2nd
> request.  It worries me, though. =
 I'd rather see that optimization added
> in a subsequent =
version of the spec, so all 1.0 implementations have
> then shown =
that they're capable of performing the base algorithm.  I
> worry =
that too many servers will implement the optimization and then
> =
lazy clients will become pervasive which only do one round trip, =
thus
> making the "optional" optimization now de facto =
required for servers.
> So I'd really rather drop that from =
the spec too.  Let's add it only
> later, once it's shown to =
be needed.  As is, clients could even fire off
> two HTTP =
requests in parallel to reduce latency, one for host-meta and
> =
one optimistically for the presumed host-meta location in cases of =
big
> hosts that rarely change, or expired cached host-meta =
documents.
We support =
both.  RFC 6415 defined the base for 2 round trips.  The =
current WF spec adds that extension to allow for one round =
trip.
 
Please =
acknowledge my argument, even if you don't agree with it.  Do you =
understand my description of how I fear it will become a de-facto =
requirement?
 
PEJ: The =E2=80=9Cresource=E2=80=9D parameter (allowing one round =
trip) is mandatory in the spec currently.=C2=A0 I originally introduced =
it (at Eran Hammer-Lahav=E2=80=99s request) as =
=E2=80=9Coptional=E2=80=9D.=C2=A0 The group was fairly keen on making =
that mandatory, pushing for the requirement even before the text was =
adopted as a WG item.=C2=A0 So, the de facto standard you fear =
is the standard (per the current text). =C2=A0Do you not want to =
mandate the =E2=80=9Cresource=E2=80=9D parameter? It has been mandatory =
since the draft published in May this year.
 
 
> I will =
continue to fight for Google's WebFinger support, but I'm not =
the
> only one losing patience.
You're right =
there, which is why I'm serving the role of =
editor.
 
I thank you =
for that, because it's a largely thankless job.  I'm coming across =
as aggressive, but I really want this to work, and I view everybody on =
these mailing lists as friends.  I just think we all need a reality =
check.
 
PEJ: Aggressive?=C2=A0 You=E2=80=99re mild compared to some others. =
:-)=C2=A0 People feel passionate about different things.=C2=A0 I also =
just want this to work.=C2=A0 I see a lot of potential with WF for =
enriching social networking, enterprise applications, =
etc.
 
> =
Everybody please hurry up, simplify, then hurry up.  I'll help =
however I
> can.  I'm not sure whether this was =
helpful.
It's doesn't =
get much simpler than this:

   curl https://packetizer.com/.well-known/host-meta.json?<=
br>        resource=3Dacct:paulej@packetizer.com
Now we need =
to just move on to agreeing on some useful link relations for =
WF.
 
PEJ: Yeah, so how do we get to that thing we can build on?=C2=A0 =
Current requirements =E2=80=A6 bare bone =E2=80=A6 =
are:
=C2=B7         =
Servers must support JSON, may support XRD (or TLV or =
whatever)
=C2=B7         =
Servers must make /.well-known/host-meta and =
/.well-known/host-meta.json resources accessible
=C2=B7         =
Servers must support the =E2=80=9Cresource=E2=80=9D =
parameter
This means the vanilla client on the Internet will query only for =
JSON.=C2=A0 Client developers have mostly said they want the simplest =
possible solution, which means most will send requests with the =
=E2=80=9Cresource=E2=80=9D parameter.=C2=A0 More than one has expressed =
a desire to be able to cache /.well-known/host-meta to speed processing =
of resource-specific queries.
 
Personally, I think we have the solution in hand. If I change one =
thing, there is somebody who will not be happy.=C2=A0 As compromises go, =
I think we=E2=80=99ve done pretty well.=C2=A0 I say that, because I know =
one can build both a client and server implementation quite easily and =
only one format they need to consider.
 
Paul
 

------=_NextPart_000_00E3_01CDB7C6.1E9792B0--


From James.H.Manger@team.telstra.com  Wed Oct 31 23:24:35 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E88121F84FF for ; Wed, 31 Oct 2012 23:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.436
X-Spam-Level: 
X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[AWL=0.465,  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 hfaxA95l1jyv for ; Wed, 31 Oct 2012 23:24:34 -0700 (PDT)
Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5417C21F84FE for ; Wed, 31 Oct 2012 23:24:33 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,692,1344175200"; d="scan'208";a="99082675"
Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 01 Nov 2012 17:24:31 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6882"; a="45244131"
Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcani.tcif.telstra.com.au with ESMTP; 01 Nov 2012 17:24:31 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Thu, 1 Nov 2012 17:24:30 +1100
From: "Manger, James H" 
To: IETF Apps Discuss 
Date: Thu, 1 Nov 2012 17:24:28 +1100
Thread-Topic: JSON pointer: disallow leading 0s in array indicies
Thread-Index: Ac23+YwakS2yVF5tTQalZzKadD4nsg==
Message-ID: <255B9BB34FB7D647A506DC292726F6E114FFE16053@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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [apps-discuss] JSON pointer: disallow leading 0s in array indicies
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 01 Nov 2012 06:24:35 -0000

VGhlIEpTT04gcG9pbnRlciBzcGVjIGFsbG93cyAvMDA3IGFzIGEgdmFsaWQgcG9pbnRlciB0byB0
aGUgOHRoIGl0ZW0gaW4gYSBKU09OIGFycmF5LCBpbiBhZGRpdGlvbiB0byAvNywgYW5kIC8wNyBl
dGMuIEkgdGhpbmsgd2Ugc2hvdWxkIGNoYW5nZSB0aGlzIHRvIGRpc2FsbG93IGxlYWRpbmcgemVy
b3MuDQoNCk5vIG9uZSBuZWVkcyB1bm5lY2Vzc2FyeSBsZWFkaW5nIHplcm9zLg0KTm8gb25lIHdp
bGwgaW5zZXJ0IHVubmVjZXNzYXJ5IGxlYWRpbmcgemVyb3MsIGVpdGhlciBtYW51YWxseSBvciBm
cm9tIGEgcHJvZ3JhbS4NCkFkZGluZyBsZWFkaW5nIHplcm9zIHNpbXBseSBpc24ndCBhICJjb21t
b24gbWlzdGFrZSIgYW55b25lIG1ha2VzIGZvciBkZWNpbWFsIGludGVnZXJzIHNvIHRoZXJlIGlz
IG5vIHBvaW50IGluIHN1cHBvcnRpbmcgaXQgaW4gYW4gYXR0ZW1wdCB0byBiZSBsZW5pZW50Lg0K
TGVhZGluZyB6ZXJvcyBqdXN0IGFkZCB0aGUgcmlzayB0aGF0IGEgdmFsdWUgd2lsbCBiZSBtaXNp
bnRlcnByZXRlZCBhcyBvY3RhbCBzb21ld2hlcmUuDQoNCkRpc2FsbG93aW5nIGxlYWRpbmcgemVy
b3MgbWFrZXMgSlNPTiBwb2ludGVycyB1bmlxdWUuIEFueSBpdGVtIGluIGEgSlNPTiBzdHJ1Y3R1
cmUgaGFzIGV4YWN0bHkgMSBKU09OIHBvaW50ZXIgdG8gaWRlbnRpZnkgaXQuIFRoaXMgaXMgYSBu
aWNlIGZlYXR1cmUgdG8gaGF2ZS4NCk1hbnkgYXBwcyB3aWxsIG9ubHkgbmVlZCBhIEpTT04gcG9p
bnRlciB0byBiZSB1bmFtYmlndW91cywgYnV0IHNvbWUgd2lsbCBiZW5lZml0IGZyb20gdGhlbSBi
ZWluZyB1bmlxdWUuDQoNClN1Z2dlc3RlZCBjaGFuZ2UgdG8gc2VjdGlvbiA0ICJFdmFsdWF0aW9u
IiwgMm5kIGRvdCBwb2ludCwgb2YgZHJhZnQtaWV0Zi1hcHBzYXdnLWpzb24tcG9pbnRlci0wNToN
Ck9MRA0KICAqIGNoYXJhY3RlcnMgdGhhdCByZXByZXNlbnQgYW4gdW5zaWduZWQgYmFzZS0xMCBp
bnRlZ2VyIHZhbHVlDQogICAgKHBvc3NpYmx5IHdpdGggbGVhZGluZyB6ZXJvcykNCk5FVw0KICAq
IGNoYXJhY3RlcnMgdGhhdCByZXByZXNlbnQgYW4gdW5zaWduZWQgYmFzZS0xMCBpbnRlZ2VyIHZh
bHVlDQogICAgKHdpdGhvdXQgYW55IHVubmVjZXNzYXJ5IGxlYWRpbmcgemVyb3MpDQoNCg0KLS0N
CkphbWVzIE1hbmdlcg0KDQoNCg==

From paulej@packetizer.com  Wed Oct 31 23:40:10 2012
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3370821F8519 for ; Wed, 31 Oct 2012 23:40:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.155
X-Spam-Level: 
X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.443,  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 aA8zqP4qJyts for ; Wed, 31 Oct 2012 23:40:08 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id CAD9621F8516 for ; Wed, 31 Oct 2012 23:40:05 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qA16e2vi018577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Nov 2012 02:40:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351752003; bh=2VtAS8UXg5rqszksVtJOdNHjZIoTJYVBd0VB8ylQHWE=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=df3MbXhhVBTdKKblSDtXT1Nul6uT7Anz6Dj+k5Ni3i79Yz3r05KXaTFnMQnEaKcI9 JhlTg98332YEo1WXf0lIZM87sxdcROiAZBDky219aBzQRNFOhEjARHkVZ4fECUnor0 IoKrl+Db1C4CZqNsyJVqYi0PXgN0foTIKiG1c74U=
From: "Paul E. Jones" 
To: , 
Date: Thu, 1 Nov 2012 02:40:08 -0400
Message-ID: <011a01cdb7fb$bca72f80$35f58e80$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_011B_01CDB7DA.359652D0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac23+u3YVAhN5wz+SoC7W4GHhl67bg==
Content-Language: en-us
Subject: [apps-discuss] An alteration to the WebFinger Spec
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 01 Nov 2012 06:40:10 -0000

This is a multipart message in MIME format.

------=_NextPart_000_011B_01CDB7DA.359652D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Folks,

 

Here's a proposal that some might find acceptable and others will probably
love.  It's just a proposal, so no bazookas, please, from those who will
find it troubling ;-)

 

http://hive.packetizer.com/users/paulej/internet-drafts/draft-ietf-appsawg-w
ebfinger-03-ALT.txt

 

What I did with this text is the following:

.         Included all of the current -03 text (not yet published, but text
folks proposed on the list)

.         Removed every reference to XML and XRD

.         Stated that the default format for /.well-known/host-meta.json is
JRD

.         Stated that the default format for /.well-known/host-meta is
implementation-dependent, so clients MUST use the Accept header to
explicitly request the desired representation when using that resource (this
is key to backward/forward compatibility and proper use of HTTP and Accept)

.         Removed the "account link relation" section

.         Removed the interop considerations section, since some feel there
is no need and I think requiring use of "Accept" on host-meta will address
any interop concerns

.         Removed the XML appendix that gave some people heartburn

 

This shaved off 6 pages of text, I think will still give us
backward-compatibility for those who have asked for it, but more clearly
positions JSON / JRD as the only format developers need to worry with.

 

Tell me what you think.

 

Paul

 


------=_NextPart_000_011B_01CDB7DA.359652D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Folks,
 
Here’s =
a proposal that some might find acceptable and others will probably =
love.  It’s just a proposal, so no bazookas, please, from =
those who will find it troubling ;-)
 
http://hive.packetizer.com/users/paulej/i=
nternet-drafts/draft-ietf-appsawg-webfinger-03-ALT.txt
=

 
What I =
did with this text is the following:
·         =
Included all of the current -03 text (not =
yet published, but text folks proposed on the list)
·         =
Removed every reference to XML and =
XRD
·         =
Stated that the default format for =
/.well-known/host-meta.json is JRD
·         =
Stated that the default format for =
/.well-known/host-meta is implementation-dependent, so clients MUST use =
the Accept header to explicitly request the desired representation when =
using that resource (this is key to backward/forward compatibility and =
proper use of HTTP and Accept)
·         =
Removed the “account link =
relation” section
·         =
Removed the interop considerations =
section, since some feel there is no need and I think requiring use of =
“Accept” on host-meta will address any interop =
concerns
·         =
Removed the XML appendix that gave some =
people heartburn
 
This shaved =
off 6 pages of text, I think will still give us backward-compatibility =
for those who have asked for it, but more clearly positions JSON / JRD =
as the only format developers need to worry with.
 
Tell me what =
you think.
 
Paul
 

------=_NextPart_000_011B_01CDB7DA.359652D0--