From fgaliegue@gmail.com Fri Feb 1 07:59:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6611221E8064 for ; Fri, 1 Feb 2013 07:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgnNzRxb8fTq for ; Fri, 1 Feb 2013 07:59:46 -0800 (PST) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by ietfa.amsl.com (Postfix) with ESMTP id 72F9921E805D for ; Fri, 1 Feb 2013 07:59:46 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id ef5so4266363obb.11 for ; Fri, 01 Feb 2013 07:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=XALkSGgpElmre5tBVWtNLoo0QGYDHW1Q7P+Ams662vY=; b=A/dtotShhtlii//OT84oKEPAWo9z1ZbgoMSGqqIcSt+t+3NlAD3xAYqZi60X5mx5qI oH5ZaVrYUQ7D+/95Y+4XO/2/zHG21tZra5NnskZASTS40ODpvU28RuvHhwdoak39kbWU uLbEXWBPBhkHIU0kd1bcsPbv3lSwEZALTwbTwy1OyOupaBZLI7v4l6lj5JJ6X3fGR4+c bIP4RBW4jeshyMgCkboGwqlfAeVd7lqOrf5vge8ByeJDOLO+QO37r5C+H6yqh468F/U0 noxluqeReccN/jDh7cuCWrZn08QNXlIH8ZZKu9n9RYQt9skzrk2mh9jEU2kwQ9yfKs/P qH8Q== MIME-Version: 1.0 X-Received: by 10.60.7.67 with SMTP id h3mr10062966oea.31.1359734385912; Fri, 01 Feb 2013 07:59:45 -0800 (PST) Received: by 10.60.13.231 with HTTP; Fri, 1 Feb 2013 07:59:45 -0800 (PST) Date: Fri, 1 Feb 2013 16:59:45 +0100 Message-ID: From: Francis Galiegue To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [apps-discuss] Announce: JSON Schema, I-D version 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2013 15:59:47 -0000 Hello, JSON Schema is now up to version 4. Links to the specifications: * http://tools.ietf.org/html/draft-zyp-json-schema-04 (core specification), * http://tools.ietf.org/html/draft-fge-json-schema-validation-00 (validation specification), * http://tools.ietf.org/html/draft-luff-json-hyper-schema-00 (hyperschema specification). It is dependent on two other I-Ds: * JSON Reference, * JSON Pointer (as a consequence of the first). Reviews appreciated. For the recall, JSON Schema has its Google group: json-schema@googlegroups.com All the best, -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From salvatore.loreto@ericsson.com Fri Feb 1 08:21:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEC221E808E for ; Fri, 1 Feb 2013 08:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCIRCJQSw3ot for ; Fri, 1 Feb 2013 08:21:04 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DDFFF21E8044 for ; Fri, 1 Feb 2013 08:21:03 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-73-510beb6e19df Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B0.58.32353.E6BEB015; Fri, 1 Feb 2013 17:21:03 +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; Fri, 1 Feb 2013 17:21:02 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1627B2AD9 for ; Fri, 1 Feb 2013 18:21:02 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 31BDA54098 for ; Fri, 1 Feb 2013 18:21:00 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D015D53473 for ; Fri, 1 Feb 2013 18:20:59 +0200 (EET) Message-ID: <510BEB6D.9040905@ericsson.com> Date: Fri, 1 Feb 2013 18:21:01 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <5106BFDC.2030706@ericsson.com> <5106C090.8080403@ericsson.com> In-Reply-To: <5106C090.8080403@ericsson.com> Content-Type: multipart/alternative; boundary="------------000907070108080409070200" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+JvrW7+a+5Ag9lHWCxWv1zB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN8rbrEWTDKrmHX+FnMD4271LkZODgkBE4ljy6YwQ9hiEhfu rWfrYuTiEBI4ySjxa2s/K4SznlFix+d2KOcao8TqvUeZ4cre/5wA1XOJUeL6r0Ngw3gFtCUu bd3GAmKzCKhInP62CCzOJmAm8fzhFjBbVCBZ4uOda6wQ9YISJ2c+AasXEZCU2DdrMliNsEC4 xORJP9lAbCEBb4ltW64wgticAjoSE19cBLOZBcIk7l66ywjxhJrE1XObmCHqtSR6z3YyTWAU noVkxSwkLRC2rcSFOdeh4vIS29/OYYawdSUu/J+CIr6AkW0VI3tuYmZOern5JkZg+B/c8ttg B+Om+2KHGKU5WJTEecNdLwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYLT9rxGjtn/bxbdv 9yxnmJG+v/JgqFfNQbeJPiuvTf51y9pkYaREk8aD/95ndGs1Ns1PVvv9PjV/2cukZItLikJ/ V35zrbwYfO/g5EhFk6k1GQvYL3R6Bbor3I8rEn3WL5rhumOXx0Shn51bq3R6a1Z+vsv8gPO5 Yu60H8pWP/6ckwipvJ1yO1yJpTgj0VCLuag4EQDsfn3bTQIAAA== Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-webfinger-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 16:21:05 -0000 --------------000907070108080409070200 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit someone pointed out that the embedded link to WF, in the original announcement, takes you to the acct uri draft. sorry it was a cut and paste error! *here the right one:* http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-09 /Salvatore On 1/28/13 8:16 PM, Salvatore Loreto wrote: > FYI > > the 2 weeks WGLC on draft-ietf-appsawg-webfinger is started. > Please see the mail below and note that the right venue for discussion is > the *webfinger* mailing list > > best regards > Salvatore > > -------- Original Message -------- > Subject: [webfinger] Working Group Last Call for > draft-ietf-appsawg-webfinger-09 > Date: Mon, 28 Jan 2013 20:13:48 +0200 > From: Salvatore Loreto > To: > CC: Murray S. Kucherawy > > > > Dear WG partecipants, > > > I would like to initiate a 2 weeks WG Last Call on > draft-ietf-appsawg-webfinger-09.txt ("WebFinger") > http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt > > > Please send your reviews, as well as expression of support regarding > document readiness for IESG (or not) either to the *webfinger* mailing > list (webfinger@ietf.org), > or directly to the WG chairs (Murray Kucherawy and myself). > > Comments like "I've read the document and it is Ok to publish" or > "I've read the document and it has the following issues" > are useful and would be gratefully accepted by chairs. > > > The WG LC will end on Friday, February 8th. > > > Thank you, > Salvatore as an APPSAWG co-chair. > > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --------------000907070108080409070200 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
someone pointed out that
the embedded link to WF, in the original announcement, takes you to the acct uri draft.

sorry it was a cut and paste error!

*here the right one:*
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-09


/Salvatore

On 1/28/13 8:16 PM, Salvatore Loreto wrote:
FYI

the 2 weeks WGLC on draft-ietf-appsawg-webfinger is started.
Please see the mail below and note that the right venue for discussion is
the *webfinger* mailing list

best regards
Salvatore

-------- Original Message --------
Subject: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09
Date: Mon, 28 Jan 2013 20:13:48 +0200
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
To: <webfinger@ietf.org>
CC: Murray S. Kucherawy <superuser@gmail.com>


Dear WG partecipants,


I would like to initiate a 2 weeks WG Last Call on
draft-ietf-appsawg-webfinger-09.txt ("WebFinger")
http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt


Please send your reviews, as well as expression of support regarding
document readiness for IESG (or not) either to the *webfinger* mailing list (webfinger@ietf.org),
or directly to the WG chairs (Murray Kucherawy and myself).

Comments like "I've read the document and it is Ok to publish" or
"I've read the document and it has the following issues"
are useful and would be gratefully accepted by chairs.


The WG LC will end on Friday, February 8th.


Thank you,
Salvatore as an APPSAWG co-chair. 






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


--------------000907070108080409070200-- From paul.hoffman@vpnc.org Fri Feb 1 08:44:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DD721E8049 for ; Fri, 1 Feb 2013 08:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 3jEnq+KGnV4y for ; Fri, 1 Feb 2013 08:44:08 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACAF21E8030 for ; Fri, 1 Feb 2013 08:44:08 -0800 (PST) Received: from [10.20.30.90] (50-1-98-243.dsl.dynamic.sonic.net [50.1.98.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r11Gi65P051426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Feb 2013 09:44:07 -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: Fri, 1 Feb 2013 08:44:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <70CB0848-00DC-47ED-A9B6-E0353403385F@vpnc.org> References: To: Francis Galiegue X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Announce: JSON Schema, I-D version 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2013 16:44:09 -0000 This is a major reorganization of the long-dead -03 draft. Can you say a = bit about what you foresee for this document? I'm also interested in hearing what others on the list feel about a JSON = Schema. I had a recent discussion with someone who said that this = document was the best of the schema proposals, and it was still not = useful. I know "are schema useful" is a religious discussion, but I = think it might be useful now for this document. --Paul Hoffman= From fgaliegue@gmail.com Fri Feb 1 09:09:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A26721E80BD for ; Fri, 1 Feb 2013 09:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isXlTxjnZPXV for ; Fri, 1 Feb 2013 09:09:57 -0800 (PST) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6EB21E80A9 for ; Fri, 1 Feb 2013 09:09:57 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id dn14so4339852obc.18 for ; Fri, 01 Feb 2013 09:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XvekKJL1ShkHLC8NF9hjjPbr0M3K+UNLJXMwlx+Dccc=; b=jayNWwQfv3t/8EJk7AC2QKVIz6O3jvafPRe5nK0Tp3oYShy2dCHz4z1qBQMGLbcrXI FAKUzN7ZboccBAlgR9z6yK+vyT0o9Bf8jXjSgBc/1SYJpNANsvlYZ31KzkpGur/1rY56 DJc56kcDUqakx5QnuL9ZuYNtUkKKA0SIFGg3ne8fhEYVZWLQEVzfk3eEod4jqYn+T9c9 lt2WqA58TAMlhGFFdcf+Lh5F4WGEVt/AzZGdll/QFbJs5ejbX23sLkXe6LzYjRWoUbEM J9GS/lcmSmx4gP81XelCqdw6JO8l1CqKBfWjMAkvuq+Lo2wwleNrgq8TV7GSTJcPrw1W J6mw== MIME-Version: 1.0 X-Received: by 10.60.25.227 with SMTP id f3mr10556313oeg.17.1359738597041; Fri, 01 Feb 2013 09:09:57 -0800 (PST) Received: by 10.60.13.231 with HTTP; Fri, 1 Feb 2013 09:09:56 -0800 (PST) In-Reply-To: <70CB0848-00DC-47ED-A9B6-E0353403385F@vpnc.org> References: <70CB0848-00DC-47ED-A9B6-E0353403385F@vpnc.org> Date: Fri, 1 Feb 2013 18:09:56 +0100 Message-ID: From: Francis Galiegue To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: geraintluff@gmail.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Announce: JSON Schema, I-D version 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2013 17:09:58 -0000 On Fri, Feb 1, 2013 at 5:44 PM, Paul Hoffman wrote: > This is a major reorganization of the long-dead -03 draft. Can you say a bit about what you foresee for this document? > The major goals were as follows: * split the specification into core, validation, hyper schema -- since draft v3 started to be huge; * be much more explicit about some keywords which were confusing people (the first of them being "extends", which is removed and "replaced" with "allOf"); * add explanations gathered with time on the Google group; be more precise; * use existing specifications (I believe JSON Reference originated from JSON Schema at first -- it only made sense to refer to it), update references to others. I am primarily a validation person, and my initial goal was to clarify this part, along with the core mechanics. The hyper schema aspects are not really my center of interest, but I know this is one "vector" bringing more and more people on the group. If this is the aspect you are mainly interested about, David Geraint (the author of the hyperschema draft, Cc:ed) will be a much more suited interlocutor. But my initial goal was really to make the core and validation aspects "solid". Regards, -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From cyrus@daboo.name Fri Feb 1 09:23:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1DB21E808F for ; Fri, 1 Feb 2013 09:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.599 X-Spam-Level: X-Spam-Status: No, score=-107.599 tagged_above=-999 required=5 tests=[AWL=-5.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 cgUjETHkZiGS for ; Fri, 1 Feb 2013 09:23:14 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEF821E8040 for ; Fri, 1 Feb 2013 09:23:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id D1BEE3C688DE; Fri, 1 Feb 2013 12:23:13 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6Ikg_fjciZh; Fri, 1 Feb 2013 12:23:12 -0500 (EST) Received: from dhcp107-16-139-150.hil-snccaes.sjc.wayport.net (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id D8D6E3C688D3; Fri, 1 Feb 2013 12:23:11 -0500 (EST) Date: Fri, 01 Feb 2013 09:23:10 -0800 From: Cyrus Daboo To: Paul Hoffman , Francis Galiegue Message-ID: <12546069E19E0371DBF0FD27@cyrus.local> In-Reply-To: <70CB0848-00DC-47ED-A9B6-E0353403385F@vpnc.org> References: <70CB0848-00DC-47ED-A9B6-E0353403385F@vpnc.org> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=622 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Announce: JSON Schema, I-D version 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2013 17:23:15 -0000 Hi Paul, --On February 1, 2013 8:44:06 AM -0800 Paul Hoffman wrote: > I'm also interested in hearing what others on the list feel about a JSON > Schema. I had a recent discussion with someone who said that this > document was the best of the schema proposals, and it was still not > useful. I know "are schema useful" is a religious discussion, but I think > it might be useful now for this document. I have used for describing JSON documents in several drafts and have found that sufficient for my needs. -- Cyrus Daboo From fgaliegue@gmail.com Fri Feb 1 09:52:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0310521F8D9A for ; Fri, 1 Feb 2013 09:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQiGNolk9dZL for ; Fri, 1 Feb 2013 09:52:34 -0800 (PST) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6809021F8D67 for ; Fri, 1 Feb 2013 09:52:33 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id dn14so4386046obc.18 for ; Fri, 01 Feb 2013 09:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nDV5LZ1zWMNS+jVpzNV2IE8C+dpINDRRViSB6Y7VI+w=; b=YGAncJN7IXb89aJdg8qq7tt+BWga4RgvxyyK7fJqZpCLPw01gVRJFlky3J6HHZSVNh apbYJRmwzEhmznIlMFh9pYF0oafibi0KbJnLcGzBeijJznkt4Y2IpNo0TNCg8LyLS6zn 23wBfieaqpDf4SCa8j6zQ22g/zLB7n7SsvpxzeE9rdNg8z8Y2gJdeB2X0rzs16dvBqdx pSj5dn5Xsq8w5CmnpOnr0dd8XtAyU1RSygzlRRP88fSlDmR69oPUx5JuaXgTlS1QyOys goxskMlszs0vG3VTFnPmyWb6tuuBzuh0Aph6I9EPjxHS/t7oNSFkgqGGa9TrH58gAVQi WB+A== MIME-Version: 1.0 X-Received: by 10.60.7.67 with SMTP id h3mr10353558oea.31.1359741153018; Fri, 01 Feb 2013 09:52:33 -0800 (PST) Received: by 10.60.13.231 with HTTP; Fri, 1 Feb 2013 09:52:32 -0800 (PST) In-Reply-To: <12546069E19E0371DBF0FD27@cyrus.local> References: <70CB0848-00DC-47ED-A9B6-E0353403385F@vpnc.org> <12546069E19E0371DBF0FD27@cyrus.local> Date: Fri, 1 Feb 2013 18:52:32 +0100 Message-ID: From: Francis Galiegue To: Cyrus Daboo Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] Announce: JSON Schema, I-D version 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2013 17:52:38 -0000 Hello, On Fri, Feb 1, 2013 at 6:23 PM, Cyrus Daboo wrote: [...] > > I have used > for > describing JSON documents in several drafts and have found that sufficient > for my needs. > I didn't know about this specification but imho it has two flaws: * it fails to describe itself; * it requires a dedicated parser, since it is not written in JSON. Those are, to me, two very strong points of JSON Schema. Regards, -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From cyrus@daboo.name Fri Feb 1 10:04:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997F621E80C1 for ; Fri, 1 Feb 2013 10:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=-2.500, 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 D8ZLkDS8mKXc for ; Fri, 1 Feb 2013 10:04:03 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id DFFB321E8041 for ; Fri, 1 Feb 2013 10:04:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 68C993C693D4; Fri, 1 Feb 2013 13:04:02 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fS-PxGLyo3U2; Fri, 1 Feb 2013 13:04:02 -0500 (EST) Received: from dhcp107-16-139-150.hil-snccaes.sjc.wayport.net (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 098483C693C9; Fri, 1 Feb 2013 13:04:00 -0500 (EST) Date: Fri, 01 Feb 2013 10:03:58 -0800 From: Cyrus Daboo To: Francis Galiegue Message-ID: In-Reply-To: References: <70CB0848-00DC-47ED-A9B6-E0353403385F@vpnc.org> <12546069E19E0371DBF0FD27@cyrus.local> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=668 Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] Announce: JSON Schema, I-D version 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2013 18:04:03 -0000 Hi Francis, --On February 1, 2013 6:52:32 PM +0100 Francis Galiegue wrote: > I didn't know about this specification but imho it has two flaws: > > * it fails to describe itself; > * it requires a dedicated parser, since it is not written in JSON. > > Those are, to me, two very strong points of JSON Schema. My primary goal is to have something to describe a JSON document format in a specification in a clear and understandable manner to any implementor. Being able to fully validate a JSON document is a lesser requirement. i.e. I am after something more akin to ABNF or a XML DTD, as opposed to full-blown XML schema. -- Cyrus Daboo From sm@elandsys.com Fri Feb 1 10:08:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1B921E8041 for ; Fri, 1 Feb 2013 10:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8atkfUDS0OL for ; Fri, 1 Feb 2013 10:08:28 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F291721E8048 for ; Fri, 1 Feb 2013 10:08:27 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.156.161]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r11I8F8K002796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Feb 2013 10:08:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359742106; bh=AoWemu9ti+8iUZAznIFnckDxwWt3jhmtWHlqyE7SktI=; h=Date:To:From:Subject; b=dwCek0Chh776ItVKsihULg5Cg0e0P5v0BI4R8gYretpVLxL+qMCmk+1Jrj3+l2g5d Dw7ivfb7R70VRLqjwuSnr7R77Cn6/tVb7rIfcL0EX5FovGf2V6rFEhQuSUthhpq2zM hKp5ArEZiyQRRJwdvXpjfj1lmSRfsS/pvSZRPAVs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1359742106; i=@elandsys.com; bh=AoWemu9ti+8iUZAznIFnckDxwWt3jhmtWHlqyE7SktI=; h=Date:To:From:Subject; b=kXgzXRKxUrAyctOJkoC5Lz0lTVZni+lHLjcxy27T7Asq+nGCPnhHsJhQnPeJ6T/+E OIFNaHf97o0atRFsDBvGTBfMTsG78Gyoc2vynJq8Bhcgij3rWrDqYUk1DCHgEbI2l7 BWnUt1h+Pm3M9JRHmAclThYU6jLIA1AKew99vtps= Message-Id: <6.2.5.6.2.20130201094525.0a04c4a8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 01 Feb 2013 10:05:19 -0800 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Apps Area Directorate report for January 2013 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2013 18:08:29 -0000 The Applications Area Directorate provides semi-formal reviews of Internet-Drafts as a way to improve the quality of IETF specifications. The directorate consists of the Working Group Chairs of the Applications Area and recognized experts in the Applications Area. The following review were performed in January 2013: Reviewer I-D Vijay K. Gurbani draft-ietf-avtcore-srtp-encrypted-header-ext-04 Ted Hardie draft-ietf-6man-ipv6-atomic-fragments-03 Yoshiro Yoneya draft-ietf-radext-radius-extensions-08 Alexey Melnikov draft-ietf-nea-pt-eap-06 Joseph Yee draft-ietf-rmt-fcast-07 Alexey Melnikov draft-laurie-pki-sunlight-05 Salvatore Loreto draft-ietf-rmt-flute-sdp-03 Regards, S. Moonesamy On behalf of the Applications Area Directorate http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate From hallam@gmail.com Fri Feb 1 10:27:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5E221F8BE7 for ; Fri, 1 Feb 2013 10:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=-2.917, 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 GmyTzBTJN0Jx for ; Fri, 1 Feb 2013 10:27:10 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3673821F8BE2 for ; Fri, 1 Feb 2013 10:27:10 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id 12so3182191wgh.7 for ; Fri, 01 Feb 2013 10:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Pl/k4tP+ZhwZYECPcfp16xAkhg2G4+iW+T3WDPqKI7Q=; b=tdR+Uf/wQxSg1DYOVdA0Mi/LTBrgsaJp2cfXmBV+z1n9REvzm5ESEe84P34qgCMWFA 27pUByypjRltx+lD+WkM9Q9MqcIL5uc7xzygVBQ/jh9J63cUia7MBUFQU5Zevhzfmcrk 49H5s1HPxIGyHrG6DTPm9iZpR9t6t1Pwdc52w+7+IX47KzzhXt/renyoohpcT5spStK0 12kzVMkensvm8G4Jdo36yjJsOunDcuBbEeJtAiURzUnZeZrU6/zLvyU3peZbdSi7L96A bR62vDT5GIJELW2GoI/dmj9IIwIpZc0hvFwqjqq1OmxW0GWjZBWF/2oaQu1BJMgQzPes uGaA== MIME-Version: 1.0 X-Received: by 10.180.97.102 with SMTP id dz6mr4575586wib.3.1359743229269; Fri, 01 Feb 2013 10:27:09 -0800 (PST) Received: by 10.194.16.74 with HTTP; Fri, 1 Feb 2013 10:27:09 -0800 (PST) In-Reply-To: References: <70CB0848-00DC-47ED-A9B6-E0353403385F@vpnc.org> <12546069E19E0371DBF0FD27@cyrus.local> Date: Fri, 1 Feb 2013 13:27:09 -0500 Message-ID: From: Phillip Hallam-Baker To: Cyrus Daboo Content-Type: multipart/alternative; boundary=f46d043bdde82a97c104d4ade4c7 Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] Announce: JSON Schema, I-D version 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2013 18:27:11 -0000 --f46d043bdde82a97c104d4ade4c7 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 1, 2013 at 1:03 PM, Cyrus Daboo wrote: > Hi Francis, > > > --On February 1, 2013 6:52:32 PM +0100 Francis Galiegue < > fgaliegue@gmail.com> wrote: > > I didn't know about this specification but imho it has two flaws: >> >> * it fails to describe itself; >> * it requires a dedicated parser, since it is not written in JSON. >> >> Those are, to me, two very strong points of JSON Schema. >> > > My primary goal is to have something to describe a JSON document format in > a specification in a clear and understandable manner to any implementor. > Being able to fully validate a JSON document is a lesser requirement. i.e. > I am after something more akin to ABNF or a XML DTD, as opposed to > full-blown XML schema. +1 I find 90% of the features in XMLSchema to be completely irrelevant to protocol design. They are designed to support document markup, not protocols. I do not know of any widely used language where people write class or structure definitions with constraints on the number of elements etc. that look anything like XML Schema. The only useful values for minOccur are 0 and 1. The only valid values for maxOccur are 1 and infinity. The constraints that are useful for validating input are invariably more complex than XML schema can support. The interesting constraints are constraints that cut across multiple entries in a single structure (X > 3 is not useful, X>Y might be). -- Website: http://hallambaker.com/ --f46d043bdde82a97c104d4ade4c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 1, 2013 at 1:03 PM, Cyrus Da= boo <cyrus@daboo.name> wrote:
Hi Francis,


--On February 1, 2013 6:52:32 PM +0100 Francis Galiegue <fgaliegue@gmail.com> wrote= :

I didn't know about this specification but imho it has two flaws:

* it fails to describe itself;
* it requires a dedicated parser, since it is not written in JSON.

Those are, to me, two very strong points of JSON Schema.

My primary goal is to have something to describe a JSON document format in = a specification in a clear and understandable manner to any implementor. Be= ing able to fully validate a JSON document is a lesser requirement. i.e. I = am after something more akin to ABNF or a XML DTD, as opposed to full-blown= XML schema.

+1

I find 90% of the features = in XMLSchema to be completely irrelevant to protocol design. They are desig= ned to support document markup, not protocols.=A0

I do not know of any widely used language where people write class or struc= ture definitions with constraints on the number of elements etc. that look = anything like XML Schema. The only useful values for minOccur are 0 and 1. = The only valid values for maxOccur are 1 and infinity.

The constraints that are useful for validating in= put are invariably more complex than XML schema can support. The interestin= g constraints are constraints that cut across multiple entries in a single = structure (X > 3 is not useful, X>Y might be).

--
Website: http://h= allambaker.com/
--f46d043bdde82a97c104d4ade4c7-- From fgaliegue@gmail.com Fri Feb 1 10:32:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5770F21E8039 for ; Fri, 1 Feb 2013 10:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo3M4n5jIN4u for ; Fri, 1 Feb 2013 10:32:36 -0800 (PST) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by ietfa.amsl.com (Postfix) with ESMTP id 458C621F87D9 for ; Fri, 1 Feb 2013 10:32:06 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id wc18so4435679obb.36 for ; Fri, 01 Feb 2013 10:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zuoB6tY3WLGLQoI/wKZXLKfMYHeQUw4eiAIuyKQRPTY=; b=QR4BTSyZi105xrn/1ZVwS7ebxb1thEAR8I9Y7Yg6W9AIv39MfiWWoPES/DLgRHB6Xa C8k0NDsujtWbTXe6Zso/enwlkq2KScs3h5NL3d1zhMyPH4RaOdoBJP3cdyl1X2efIQ0v ZCaUhFJFW4bZ0ET+QNAOzpFnhS3f2wx3zJ8IMPVn4H///hyInqeE/gRHY2t2eqcyvLkb 1HsDtm5XurV4CouV+ALgMOyiQP6oBvZ/X/g24ov6spftzyk6e6oGC3DcpQO0+iTJYIqZ +9rrjK2pEsQ2/jMoJY6xW2elCfqqbWS0yrke72HgJJd7g7BNO3G0a+prRpOJ/QBiAJNF B8Hg== MIME-Version: 1.0 X-Received: by 10.182.154.4 with SMTP id vk4mr9261214obb.70.1359743525793; Fri, 01 Feb 2013 10:32:05 -0800 (PST) Received: by 10.60.13.231 with HTTP; Fri, 1 Feb 2013 10:32:05 -0800 (PST) In-Reply-To: References: <70CB0848-00DC-47ED-A9B6-E0353403385F@vpnc.org> <12546069E19E0371DBF0FD27@cyrus.local> Date: Fri, 1 Feb 2013 19:32:05 +0100 Message-ID: From: Francis Galiegue To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] Announce: JSON Schema, I-D version 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2013 18:32:37 -0000 On Fri, Feb 1, 2013 at 7:27 PM, Phillip Hallam-Baker wrote: [...] > > I find 90% of the features in XMLSchema to be completely irrelevant to > protocol design. They are designed to support document markup, not > protocols. > You know, I hate XML Schema with a passion. And one reason why I immediately adopted JSON Schema for my needs is that I didn't see anything remotely as bloated in JSON Schema. It does a very good job at describing the structure of JSON data, whatever it may be. And it is relatively easy to grasp. This is certainly related to the fact that JSON itself is much easier to grasp than XML for mere mortals. -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From fgaliegue@gmail.com Fri Feb 1 10:40:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1EA21E8045 for ; Fri, 1 Feb 2013 10:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwiSPocIWExT for ; Fri, 1 Feb 2013 10:40:12 -0800 (PST) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by ietfa.amsl.com (Postfix) with ESMTP id B247321E8049 for ; Fri, 1 Feb 2013 10:40:12 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id v19so4377416obq.35 for ; Fri, 01 Feb 2013 10:40:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XM9ABh1h/7Fl7R0SJr+mNsVszBtT50LnLvxGRbCRnHU=; b=Lg6hxE3PviiADnUgt4aU9WWx92agwm7bL+01AsdpMSPbWyHoCvFE8eR+q7xWf7jP8G 8j+YWTI5PfYcBew5ivL9SKFZYtApM/HAWHKPA/onchQOfDBpxu8XNmzVu4LsVEwT03h3 JHu2suVAW6K7/R2nja7hOB9j56SVy3ys5g4Mpp6K656J0pgVrXbADp2oP1/tt25LIsbI R0haiIi5+5ZPd5yM1Sy011sdxNk8/8D+X1pug68lCtCsvVpjIBsui4cpHPT3CPSN7cm4 ns7fBMvWwL7wKdkRtS2tPS5EEl19eUJGD5ACiUApeLcpyHXROc+gqobJ5eBkyKRMMuRM dEQw== MIME-Version: 1.0 X-Received: by 10.60.30.168 with SMTP id t8mr10537704oeh.140.1359744012245; Fri, 01 Feb 2013 10:40:12 -0800 (PST) Received: by 10.60.13.231 with HTTP; Fri, 1 Feb 2013 10:40:12 -0800 (PST) In-Reply-To: References: <70CB0848-00DC-47ED-A9B6-E0353403385F@vpnc.org> <12546069E19E0371DBF0FD27@cyrus.local> Date: Fri, 1 Feb 2013 19:40:12 +0100 Message-ID: From: Francis Galiegue To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] Announce: JSON Schema, I-D version 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2013 18:40:13 -0000 On Fri, Feb 1, 2013 at 7:32 PM, Francis Galiegue wrote: [snip] > > [...] It does a very good job > at describing the structure of JSON data, whatever it may be. And it > is relatively easy to grasp. > I might as well include "real life" schemas. Recently, someone on the group asked whether a schema for GeoJSON (http://geojson.org) existed. The answer was no. 30 minutes after, it was yes. These schemas only lack functional checks which cannot be expressed using JSON Schema or, for that matter, anything other than actual programming: https://github.com/fge/json-schema-validator-demo/tree/master/src/main/resources/geojson -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From tbray@textuality.com Fri Feb 1 11:03:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6DB21E8056 for ; Fri, 1 Feb 2013 11:03:36 -0800 (PST) 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 Hv22mT6ZqCbs for ; Fri, 1 Feb 2013 11:03:35 -0800 (PST) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by ietfa.amsl.com (Postfix) with ESMTP id BF33B21E8049 for ; Fri, 1 Feb 2013 11:03:35 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id ta14so4472625obb.14 for ; Fri, 01 Feb 2013 11:03:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=AAd7WFQsSt9wSL9gslHe96Kfzu1cxkS77Q+6NAI7bQY=; b=JKJaKKOSJGh0MgQUZDNyT/b/LcILtiHbIvyzGF3bXMvqkgcXh0j/OCEzuFphOZKFWi apUapZX7qheX3hd3db6/mN9HtCui1j0NyqEdJVqHOq2w9fYcfYP7Dgo1uBbVas8e/Cia 43i5wvb/6atDLlCHV5i86PAZyUDJ8RrmLC+kQMfOb909hyR0sXW9dWE3Ms6FAHCEJGaF PLQuQnyZMIGruRGasoo7iheMRNnf5TA0TvwDVIO03PQZs6f1AMh+thq6ltJNG+lYVfTr Cxdu6m3Pc3+X5ei+GNVbrqB3qoZ6TCyu20Sdr6/RszTJ66bTVrSz1XCfYEER/niQocwe 8EwQ== MIME-Version: 1.0 X-Received: by 10.60.27.199 with SMTP id v7mr10571074oeg.23.1359745415276; Fri, 01 Feb 2013 11:03:35 -0800 (PST) Received: by 10.76.28.66 with HTTP; Fri, 1 Feb 2013 11:03:35 -0800 (PST) X-Originating-IP: [96.49.72.110] In-Reply-To: <70CB0848-00DC-47ED-A9B6-E0353403385F@vpnc.org> References: <70CB0848-00DC-47ED-A9B6-E0353403385F@vpnc.org> Date: Fri, 1 Feb 2013 11:03:35 -0800 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkP2p6Dpw0gQUFm3fwdGEl6tenQxlbGSNkKJFWMjjOTU7hQklvpKDGLx847LielbMiSDnQf Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Announce: JSON Schema, I-D version 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Feb 2013 19:03:36 -0000 Well, wading into the religion... In the XML space, schemas have probably on balance been actively harmful, for two reasons: - XML Schema (XSD) is a turd: Fails to do all sorts of useful stuff while still being hard to understand and use - The existence of schemas tend to distract people into investing a lot of effort into writing them, which usually has poor ROI, for two reasons: First, every Internet protocol imposes constraints that typically cannot be expressed in a declarative schema. And second, clear, understandable English-language prose is much more important, and any time invested in things other than getting that right is questionable. Having said that, RFC4287 (Atom) has a non-normative schema, which is in RelaxNG, an XML schema thingie that is much better than XSD; and people have found that useful. So... if the JSON schema tool were lightweight and easy to understand and covered the important use cases, it might not be actively harmful. But if I were a WG chair doing a JSON-based protocol, I=92d be perfectly happy to ship a schema-less RFC, and I=92d probably be fairly harsh on bikesheddy discussions of schema minutiae. -T On Fri, Feb 1, 2013 at 8:44 AM, Paul Hoffman wrote: > This is a major reorganization of the long-dead -03 draft. Can you say a = bit about what you foresee for this document? > > I'm also interested in hearing what others on the list feel about a JSON = Schema. I had a recent discussion with someone who said that this document = was the best of the schema proposals, and it was still not useful. I know "= are schema useful" is a religious discussion, but I think it might be usefu= l now for this document. > > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From sm@elandsys.com Fri Feb 1 17:19:31 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0238B1F0CF8; Fri, 1 Feb 2013 17:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 6PrYMy436DOf; Fri, 1 Feb 2013 17:19:29 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 996561F0CFB; Fri, 1 Feb 2013 17:19:29 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.156.161]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r121JDnX019440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2013 17:19:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359767966; bh=xkvRjlRvlitDiHdA58OBnt/zt4mHxEkAZTzq3JpdIuU=; h=Date:To:From:Subject:Cc; b=szFRhbrCqhE3CdSnixRqBzhG6I8/RSPpZDHlBqJAkcpoOY2uaHwERxWyp99baeU1R uxtuD/fia/LVhA0gFbtCsd7wkIS2gAkaod0a3KDBfmjytyrAkTikI1zTveu8YbrKAG KLk/NTftN/76oGavDXiEmp7fN99e2LxIGm97StOM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1359767966; i=@elandsys.com; bh=xkvRjlRvlitDiHdA58OBnt/zt4mHxEkAZTzq3JpdIuU=; h=Date:To:From:Subject:Cc; b=hVkfcTzjRdhD4T7BBwYNH/4lyQX21YJsMJWmL9UBTsN6lb1wX6iRF7jcP7NZvu4y0 lZdiZZTl9JBMytPs9NP9qmpJSpjlUkGZmSC+tQ3C50ayuSHMjZzBCl4TVrxInTsxDF 7mARb+NC9LWDXkK0LdU1fLKyHENJrwq7uGzgFFKY= Message-Id: <6.2.5.6.2.20130201161811.0b38bb90@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 01 Feb 2013 17:12:09 -0800 To: apps-discuss@ietf.org, draft-gp-obsolete-icmp-types.all@tools.ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-gp-obsolete-icmp-types-iana-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, 02 Feb 2013 01:19:31 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-gp-obsolete-icmp-types-iana-01 Title: Formally Deprecating Some ICMPv4 Message Types Reviewer: S. Moonesamy Review Date: February 1, 2013 IETF Last Call Date: January 24, 2013 Summary: This document is almost ready for publication. The document deprecates such ICMPv4 message types, thus cleaning up the corresponding IANA registry. There aren't any application-related considerations. The document is well-written. Major issues: none Minor issues: none Nits: Why is the intended status "Standards Track"? Regards, S. Moonesamy From sm@elandsys.com Fri Feb 1 17:24:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED69021E808B; Fri, 1 Feb 2013 17:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 daBze3Jx4sXT; Fri, 1 Feb 2013 17:24:47 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5AD21E8049; Fri, 1 Feb 2013 17:24:47 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.156.161]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r121OVMT026425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2013 17:24:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359768284; bh=xqnK4wOVNoDK573Ls/8negC56NLwqdCfAuKqYDynTLU=; h=Date:To:From:Subject:Cc; b=B1jAr8xsivjZDjgLWexJmocSVbP8shrcKvXUocDrP6+5cTfUYYGec6C7gFKfFaOZZ ckIl0FYBM3QhlfUbPmNfZYFWXgP9S3RAuJFxicv1G83U2I4bYpJLRl4CkRgn/nMC89 h8ox9VtxH3jJc75JkG/AgKB3cxcerMxtllRxMZRg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1359768284; i=@elandsys.com; bh=xqnK4wOVNoDK573Ls/8negC56NLwqdCfAuKqYDynTLU=; h=Date:To:From:Subject:Cc; b=kf3yImSZgAVvv6wv8XvNO0HPGn/StF7Z96ZgCafq2SXO6oqQjqGy7dzKww7Bpnb3Y ID8nTNN9Y7FUGLMlnsscl1sfltQKs4YpCKy4Nf+5NKFjWkt4kRoKx8ntWE6kosfu17 TXToqdBkfk+SdjFdKi+6vQfztB7RU4wH9ihGaiTc= Message-Id: <6.2.5.6.2.20130201172039.0a74d408@elandsys.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 01 Feb 2013 17:24:07 -0800 To: apps-discuss@ietf.org, Fernando Gont , Carlos Pignataro , Joel Halpern From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-gp-obsolete-icmp-types-iana-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, 02 Feb 2013 01:24:48 -0000 I am resending the message as I used an incorrect email alias. 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-gp-obsolete-icmp-types-iana-01 Title: Formally Deprecating Some ICMPv4 Message Types Reviewer: S. Moonesamy Review Date: February 1, 2013 IETF Last Call Date: January 24, 2013 Summary: This document is almost ready for publication. The document deprecates such ICMPv4 message types, thus cleaning up the corresponding IANA registry. There aren't any application-related considerations. The document is well-written. Major issues: none Minor issues: none Nits: Why is the intended status "Standards Track"? Regards, S. Moonesamy From jmh@joelhalpern.com Fri Feb 1 17:28:00 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8F621F8984; Fri, 1 Feb 2013 17:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.259 X-Spam-Level: X-Spam-Status: No, score=-102.259 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE71JrNDIWzf; Fri, 1 Feb 2013 17:28:00 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC3D21F897A; Fri, 1 Feb 2013 17:28:00 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id ECCB3A655C; Fri, 1 Feb 2013 17:27:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id BD88E2A1E0F; Fri, 1 Feb 2013 17:27:59 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-125.clppva.east.verizon.net [70.106.134.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 582EF2A1E09; Fri, 1 Feb 2013 17:27:41 -0800 (PST) Message-ID: <510C6B6C.2020904@joelhalpern.com> Date: Fri, 01 Feb 2013 20:27:08 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20130201172039.0a74d408@elandsys.com> In-Reply-To: <6.2.5.6.2.20130201172039.0a74d408@elandsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Fernando Gont , iesg@ietf.org, apps-discuss@ietf.org, Carlos Pignataro Subject: Re: [apps-discuss] APPSDIR review of draft-gp-obsolete-icmp-types-iana-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, 02 Feb 2013 01:28:00 -0000 It is standards track because of its interaction with other standards track documents. Yours, Joel On 2/1/2013 8:24 PM, S Moonesamy wrote: > I am resending the message as I used an incorrect email alias. > > 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-gp-obsolete-icmp-types-iana-01 > Title: Formally Deprecating Some ICMPv4 Message Types > Reviewer: S. Moonesamy > Review Date: February 1, 2013 > IETF Last Call Date: January 24, 2013 > > Summary: This document is almost ready for publication. > > The document deprecates such ICMPv4 message types, thus cleaning up the > corresponding IANA registry. There aren't any application-related > considerations. The document is well-written. > > Major issues: none > > Minor issues: none > > Nits: > > Why is the intended status "Standards Track"? > > Regards, > S. Moonesamy > From sm@elandsys.com Fri Feb 1 21:50:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C72721F8CCB; Fri, 1 Feb 2013 21:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ganJHrk3JFN; Fri, 1 Feb 2013 21:50:38 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 649B421F8CC8; Fri, 1 Feb 2013 21:50:37 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.156.161]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r125oLrn009128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2013 21:50:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359784235; bh=KOnq9vfaEpwZNgjxecMiqmebGeuaQaNl1EXFfwCy4yI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kI27BIofyRmJxGNiDG+PeXd2odzmW/ZUMX3L8WnFP215lm4GXFEnTbHGBhqcshcAl RiCz4lAfLdHeacGHaWuLkbSeAwF9Hp/ifUgOqwkp1EXHCa9bkOI5rxcHBkXNgw1SWH umN72K9XtnSuBlGLCB9XRJ3HgRLp+2UIcsxm4jWo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1359784235; i=@elandsys.com; bh=KOnq9vfaEpwZNgjxecMiqmebGeuaQaNl1EXFfwCy4yI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Ya5PnZILamPjsYVWiyIaLad6I89idVs5YhOTxTOX8+wRhH5d7+pQC5/bcqmQ74qB4 tNNQRjcHcVRO/55fqhEGyUm+mWmESFKryxlpVzCtIQSRq4MmZt0a84JCzVdy5Sb2pL Pc8sgvD18uuWFUmGBwuOBf41BSfD9lqox5B/dipw= Message-Id: <6.2.5.6.2.20130201211516.08dfcea8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 01 Feb 2013 21:30:59 -0800 To: "Joel M. Halpern" From: S Moonesamy In-Reply-To: <510C6B6C.2020904@joelhalpern.com> References: <6.2.5.6.2.20130201172039.0a74d408@elandsys.com> <510C6B6C.2020904@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Fernando Gont , iesg@ietf.org, apps-discuss@ietf.org, Carlos Pignataro Subject: Re: [apps-discuss] APPSDIR review of draft-gp-obsolete-icmp-types-iana-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, 02 Feb 2013 05:50:40 -0000 Hi Joel, At 17:27 01-02-2013, Joel M. Halpern wrote: >It is standards track because of its interaction with other >standards track documents. Thanks for the quick response. I consider the review as being addressed. I'll leave it to the Application Area ADs to figure out whether the document should be published as Informational or Proposed Standard. :-) Regards, S. Moonesamy From dave@cridland.net Sat Feb 2 02:06:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DFF21F9089 for ; Sat, 2 Feb 2013 02:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eiDCUstwC+a for ; Sat, 2 Feb 2013 02:06:49 -0800 (PST) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id 056CC21F8E1D for ; Sat, 2 Feb 2013 02:06:41 -0800 (PST) Received: by mail-oa0-f51.google.com with SMTP id h2so2994249oag.10 for ; Sat, 02 Feb 2013 02:06:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=topJXyHrI607dn0IbH7LHXkMK9/Fx3pit6uxTV1BiQI=; b=KnScpD2LpG/lZHRJpk1JOJEdGzuCJJPWWgf9UoJlEPVcAX/+ne5+xmWhnKmuXoezet wI9MgXMFcHOlUl4DsD5dMCl0nxpMwP4t1UyUgFGysJD+xA0yc6Bn/2E1E+v1WYX9EKiP P/Bss93djR6y8iLp5TaPHLoUB5saAlAATrjZQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=topJXyHrI607dn0IbH7LHXkMK9/Fx3pit6uxTV1BiQI=; b=NC5RMYzx2c+zkbRQotMD/lSq/dp36e8kxjpDlx89EcxI4+AngXzVH+t4Z2uXkxWh2s DFjoZsJ8Y4hvTEgLQ6jhxpU6Pd/X+zzLysXGxlyH76s99Ug10bJFP1+QuePsB0zw0T7d xa437mmpNgS/sgHiW157BKdibIS+wjK4JJ7LeRnWzFYwv/EA3WpYSITOALUrDhhhuMOv R2S4plDhmvSfbhXjOXRJTkRXGi5w1Q2jSrv+xoYri0k2ORfdi6zcOmtyaaN74jE9ZwyF Rufa6rB3chrULn9o8aJnWD4BrCwaklx5LVZ9mBo1SmM2CzC8ugmOrFO17GiiOMCZwejg 7ang== MIME-Version: 1.0 X-Received: by 10.60.1.73 with SMTP id 9mr11879143oek.130.1359799601571; Sat, 02 Feb 2013 02:06:41 -0800 (PST) Received: by 10.60.164.73 with HTTP; Sat, 2 Feb 2013 02:06:41 -0800 (PST) Received: by 10.60.164.73 with HTTP; Sat, 2 Feb 2013 02:06:41 -0800 (PST) In-Reply-To: References: <70CB0848-00DC-47ED-A9B6-E0353403385F@vpnc.org> Date: Sat, 2 Feb 2013 10:06:41 +0000 Message-ID: From: Dave Cridland To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb2066037a64504d4bb04a2 X-Gm-Message-State: ALoCoQlecXUrZ+RBGtquwgnrD5CQCdN/Kt9v7se8vR2MNcQKlXfhc4XiZw6+ZurWPvJMtO00t7vE Subject: Re: [apps-discuss] Announce: JSON Schema, I-D version 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Feb 2013 10:06:51 -0000 --e89a8fb2066037a64504d4bb04a2 Content-Type: text/plain; charset=ISO-8859-1 I managed to fumble the addressing on this one. I'll blame the tablet. ---------- Forwarded message ---------- From: "Dave Cridland" Date: 2 Feb 2013 10:05 Subject: Re: [apps-discuss] Announce: JSON Schema, I-D version 4 To: "Tim Bray" Cc: "Paul Hoffman" The XSF has a history of non normative agendas in its XEP series, these tend to be largely used as illustrations of particular limits, such as whether a publish can have more than one item or not. As such, I have them about as useful as ABNF. That is, they can imply things which are not true, and fail to express things which are essential, but if the reader is aware of the limitations, they still offer some value. --e89a8fb2066037a64504d4bb04a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I managed to fumble the addressing on this one. I'll bla= me the tablet.

---------- Forwarded message ----------
From:= "Dave Cridland" <dave@cr= idland.net>
Date: 2 Feb 2013 10:05
Subject: Re: [apps-discuss]= Announce: JSON Schema, I-D version 4
To: "Tim Bray" <tbray@= textuality.com>
Cc: "Paul Hoffman" <paul.hoffman@vpnc.org>

The XSF has a history of non normative agendas in its XEP se= ries, these tend to be largely used as illustrations of particular limits, = such as whether a publish can have more than one item or not.

As such, I have them about as useful as ABNF. That is, they = can imply things which are not true, and fail to express things which are e= ssential, but if the reader is aware of the limitations, they still offer s= ome value.

--e89a8fb2066037a64504d4bb04a2-- From algermissen1971@me.com Fri Feb 1 22:50:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADBF21F903E for ; Fri, 1 Feb 2013 22:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ikxsj8WT95fa for ; Fri, 1 Feb 2013 22:50:44 -0800 (PST) Received: from nk11p03mm-asmtp001.mac.com (nk11p03mm-asmtp001.mac.com [17.158.232.236]) by ietfa.amsl.com (Postfix) with ESMTP id 2938221F903D for ; Fri, 1 Feb 2013 22:50:42 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.2.103] ([84.143.211.188]) by nk11p03mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-26.01(7.0.4.26.0) 64bit (built Jul 13 2012)) with ESMTPSA id <0MHK00AX2Z04X440@nk11p03mm-asmtp001.mac.com> for apps-discuss@ietf.org; Sat, 02 Feb 2013 06:50:31 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327,1.0.431,0.0.0000 definitions=2013-02-02_02:2013-02-01, 2013-02-02, 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-1302010280 From: algermissen1971 Message-id: <1E979FC1-5345-4D1E-8CF1-13A6F69D62BB@me.com> Date: Sat, 02 Feb 2013 07:50:28 +0100 To: "apps-discuss@ietf.org" X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Sat, 02 Feb 2013 08:24:31 -0800 Subject: [apps-discuss] application/json-home X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Feb 2013 06:51:15 -0000 Hi Mark, what do you think about renaming application/json-home[1] to application/home+json? I used to dislike +xxx ... but actually, I can see some use in intermediaries and hence changed my mind. Jan [1] http://tools.ietf.org/html/draft-nottingham-json-home-02 From dhc@dcrocker.net Sat Feb 2 10:57:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5088B21F862D; Sat, 2 Feb 2013 10:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFNXqaX3UT0K; Sat, 2 Feb 2013 10:57:58 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2221C21F8A0C; Sat, 2 Feb 2013 10:57:58 -0800 (PST) Received: from [172.17.100.106] (rrcs-24-43-241-82.west.biz.rr.com [24.43.241.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r12Ivtr7011783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 2 Feb 2013 10:57:56 -0800 Message-ID: <510D61AB.5040704@dcrocker.net> Date: Sat, 02 Feb 2013 10:57:47 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: draft-ietf-tsvwg-sctp-udp-encaps.all@tools.ietf.org 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]); Sat, 02 Feb 2013 10:57:58 -0800 (PST) Cc: iesg , Apps Discuss Subject: [apps-discuss] Review of: draft-ietf-tsvwg-sctp-udp-encaps X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Dave Crocker List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 18:57:59 -0000 Howdy. 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-tsvwg-sctp-udp-encaps-09 Title: UDP Encapsulation of SCTP Packets Reviewer: D. Crocker Review Date: 2 Feb 2013 Summary: As a transport-level protocol, SCTP can encounter barriers at the endpoints, through inadequate API or privilege access to raw IP services, or at intermediaries such as NATs that do not support SCTP. Tunneling is the usual solution to these type of barriers. The current draft specifies encapsulation for tunneling SCTP and discusses operational concerns. The specification is usable in its current form. Revision, per the below comments, would improve its clarity, especially for less-knowledgeable readers. Also, a long-standing issue for use of UDP is the upper-layer requirement to provide congestion control and reliability mechanisms, since UDP doesn't. In the case of a tunneled transport service, like SCTP, this is obviously a trivial issue. However given the long-standing UDP concern, I suggest adding a pro-forma sentence to make this explicit. Something like: "SCTP provides the necessary congestion control and reliability service that UDP does not perform." Detailed comments: > Abstract > > This document describes a simple method of encapsulating SCTP Packets > into UDP packets and its limitations. This allows the usage of SCTP > in networks with legacy NAT not supporting SCTP. It can also be used > to implement SCTP on hosts without directly accessing the IP-layer, > for example implementing it as part of the application without > requiring special privileges. > 1. Introduction > > This document describes a simple method of encapsulating SCTP packets > into UDP packets. SCTP as defined in [RFC4960] runs directly over > IPv4 or IPv6. There are two main reasons for encapsulating SCTP > packets: > > o Allow SCTP traffic to pass legacy NATs, which do not provide pass -> pass through > native SCTP support as specified in [I-D.ietf-behave-sctpnat] and > [I-D.ietf-tsvwg-natsupp]. > 3.1. Portable SCTP Implementations ... > A crucial point for implementing SCTP in user space is controlling > the source address of outgoing packets. This is not an issue when > using all available addresses. However, this is not the case when What is meant by "using all available addresses"? > also using the address management required for NAT traversal > described in Section 4.7. > 3.2. Legacy NAT Traversal > > Using UDP encapsulation allows SCTP communication when traversing > legacy NATs (i.e those NATs not supporting SCTP as described in > [I-D.ietf-behave-sctpnat] and [I-D.ietf-tsvwg-natsupp]). It is > important to realize that for single homed associations it is only > necessary that no IP addresses are listed in the INIT and INIT-ACK This seems to be a normative directive, but it does not use normative language. Perhaps: For single-homed associations IP addresses MUST NOT be listed in the INIT and INIT-ACK > chunks. To use multiple addresses, the dynamic address > reconfiguration extension described in [RFC5061] MUST be used with > wildcard addresses in combination with [RFC4895]. wildcard addresses -> wildcard source addresses (?) > For multi-homed SCTP association the address management as described > in Section 4.7 MUST be performed. > > SCTP sends periodically HEARTBEAT chunks on all idle paths. These periodically -> periodic > can be used to keep the NAT state alive. can be used to keep -> can keep > > 4. SCTP over UDP > > 4.1. Architectural Considerations > > An SCTP implementation supporting UDP encapsulation MUST store a > remote UDP encapsulation port number per destination address for each > SCTP association. Must store it /where/? Or perhaps this isn't really a normative specification statement but rather an architectural discussion that provides a basis for the later specification details? If so, remove the normative language here. > > Each SCTP stack uses a single local UDP encapsulation port number as > the destination port for all its incoming SCTP packets. The IANA > assigned value of 9899 (sctp-tunneling) MAY be used as this port > number. If there is only a single SCTP implementation on a host (for > example, a kernel implementation being part of the operating system), > using a single UDP encapsulation port number per host can be > advantageous (e.g., this reduces the number of mappings in firewalls > and NATs, among other things). Using a single UDP encapsulation port > number per host is not possible if the SCTP stack is implemented as > part of an application. > > 4.2. Packet Format > > To encapsulate an SCTP packet, a UDP header as defined in [RFC0768] > is inserted between the IP header as defined in [RFC0791] and the > SCTP common header as defined in [RFC4960]. Interesting perspective. It casts UDP as crating a shim layer. I suppose that's what tunneling actually is... > Figure 1 shows the packet format of an encapsulated SCTP packet when > IPv4 is used. > 4.3. Encapsulation Procedure ... > For IPv4, the UDP checksum SHOULD be computed and the SCTP checksum > MUST be computed, whereas for IPv6, the UDP checksum and the SCTP > checksum MUST be computed. Given the protections provided by the SCTP checksum, why is a UDP checksum needed? (Note the logic of dropping checksum from IPv6...) > 4.4. Decapsulation Procedure > > When an encapsulated packet is received, the UDP header is removed. > Then a lookup is performed to find the association for the received Where is the lookup algorithm specified? In particular, what information is used to perform the lookup. > SCTP packet. After finding the SCTP association (which includes > checking the verification tag), the UDP source port MUST be stored as > the encapsulation port for the destination address the SCTP packet is > received from (see Section 4.1). > > Please note that when a non-encapsulated SCTP packet is received, the > encapsulation of outgoing packets belonging to the same association > and the corresponding destination address MUST be disabled. "Please note" is appropriate for a comment, not a strongly normative statement. That is, I think it undermines the reader's understanding that this is a normative requirement. > 4.6. Path MTU Considerations > > If an SCTP endpoint starts to encapsulate the packets of a path, it > MUST decrease the Path MTU of that path by the size of the UDP > header. If it stops encapsulating them, the Path MTU SHOULD be > increased by the size of the UDP header. How can a user-level SCTP control Path MTU, particularly when it's access to the IP layer (and presumably ICMP) is limited? Perhaps you mean "adjust SCTP's use of the provided Path MTU"? That is, provide a calculation on top of what the infrastucture says is available? > When performing Path MTU discovery as described in [RFC4820] and > [RFC4821] it MUST be taken into account that one cannot rely on the > feedback provided by ICMP or ICMPv6 due to the limitation laid out in > Section 4.5. Normative language in a sentence like this is actually not very helpful, since it does not specify what behaviors are being dictated. Where is the guidance that says what it means for this to "be taken into account"? > If the implementation does not allow to control the dont't fragment does not allow to control the dont't fragment -> does not allow control of the don't fragment > (DF)-bit contained in the IPv4 header, then Path MTU discovery can't > be used. In this case, an implementation specific value should be > used instead. Does this implementation-specific activity require some sort of coordination between the end-points? > > 4.7. Handling of Embedded IP-addresses > > When using UDP encapsulation for legacy NAT traversal, IP addresses > that might require translation MUST NOT be put into any SCTP packet. > > This means that a multi homed SCTP association is setup initially as > a singled homed one and the protocol extension [RFC5061] in > combination with [RFC4895] is used to add the other addresses. Only > wildcard addresses are put into the SCTP packet. This is the second reference to the use of wildcard for this. Since inclusion of actual addresses is needed for correlation/rendezvous functions, it would help to have a pointer or discussion about how the correlation/rendezvous is done when wildcarding is done. > When addresses are changed during the lifetime of an association > [RFC5061] MUST be used with wildcard addresses only. > 5. Socket API Considerations > > This section describes how the socket API defined in [RFC6458] is since the section is informational, rather than normative, I suggest: is -> can be > extended to provide a way for the application to control the UDP > encapsulation. > 7. Security Considerations > > Encapsulating SCTP into UDP does not add any additional security > considerations to the ones given in [RFC4960] and [RFC5061]. > > Firewalls inspecting SCTP packets must also be aware of the > encapsulation and apply corresponding rules to the encapsulated > packets. "must"? normative? The problem with this, whether normative or not, is that the purpose of this encapsulation is to transit intermediaries that don't support SCTP. That's a conflicting goal and probably is worth noting. > An attacker might send a malicious UDP packet towards an SCTP end- > point to change the encapsulation port for a single remote address of d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dave@cridland.net Sat Feb 2 13:09:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB1821F85A4 for ; Sat, 2 Feb 2013 13:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8s2mFBjLCht for ; Sat, 2 Feb 2013 13:09:22 -0800 (PST) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9955C21F8599 for ; Sat, 2 Feb 2013 13:09:21 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id j6so5344498oag.22 for ; Sat, 02 Feb 2013 13:09:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=SZcT+xaWOScGB/NBlkZPHtGDFWZzXZZPjup84JFNIvM=; b=QscEVVTofEJNQBM3abqEeKezBh/n0hQzDhFx0xR1ExSE2mhj9MqY5bBt/i/tIrgwff ZCNAAu4ZqVCd/B5Y/6KU6vl/APEnhEcPmkuSJw727+EhMkXf2GBvFhoABO2g2WypeluU tFZlbdlLJsoBCWczH/xQDoIKbGIPnqA6v6LHw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=SZcT+xaWOScGB/NBlkZPHtGDFWZzXZZPjup84JFNIvM=; b=bJ986/GWUtUeIuo1pj4FFjxM8ZhAAtbKsty7u69oxrnTtBhRz+J+TC27EF7KlnAGst yPgQ29EIVuPFPFzAzkrcYRf77zgvqkCyc1B/8SlK1/fPdJsIroonSoStBE/vJ1ZbJOtn uuecWT1tMoT5zBR36JsZDiV6pwRJc2r0bLONf41mKOuMmJpzhprAaKn8LJI0+nT2M6Mp DAL+2k/Tt8AUCWtTYcgjPGG/ajof6ox8gbUX+B0J6FpFDJchLQmKmrsGFAuFnlGXoB6e U/rFWdpay9wMvuimwl4oEy2uMOQi1PZtVV03PLZpkdY2Qur1UjjxpAYguxwhkat3ee9a EXew== MIME-Version: 1.0 X-Received: by 10.60.30.168 with SMTP id t8mr12983738oeh.140.1359839361340; Sat, 02 Feb 2013 13:09:21 -0800 (PST) Received: by 10.60.164.73 with HTTP; Sat, 2 Feb 2013 13:09:21 -0800 (PST) Date: Sat, 2 Feb 2013 21:09:21 +0000 Message-ID: From: Dave Cridland To: draft-ietf-ospf-rfc3137bis.all@tools.ietf.org, "apps-discuss@ietf.org" , iesg@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff1c58015960b04d4c4462b X-Gm-Message-State: ALoCoQlRO2m9EHknCVAAq2TMA/2i8ZJ2mqGyNJZeTpl+Di5GKWqGRDR9WG1MOUuMVMdWmRyA3Xd3 Subject: [apps-discuss] AppsDir Review of draft-ietf-ospf-rfc3137bis-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 21:09:23 -0000 --e89a8ff1c58015960b04d4c4462b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good Evening, 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-ospf-rfc3137bis-03 Title: OSPF Stub Router Advertisement Reviewer: Dave Cridland Review Date: 2 Feb 2013 TL;DR: This draft discusses ways of having a router visible within OSPF without offering transit. This seems to be desirable when bringing routers on and offline, and if a router is present but overloaded. The document offers a well-defined mechanism suitable for OSPFv2 and OSPFv3, and points out another strategy only suited to OSPFv3. For the most part this draft seems ready for publication, though I'm concerned it offers confusing guidance on which mechanism to use, and some wordsmithing is needed here. Detail: =A72.1 suggests it is a "similar, if not better" solution available to OSPF= v3 networks. It's not clear to me if this means "similar, and potentially better", or "similar, but not better". The second paragraph is also somewhat loose in whether this technique is recommended or not. It's not clear to me if the portion following the semicolon is essentially saying that the R-bit is superior; this is not helped by being unclear if "more granular" means finer or coarser. A quick trip to Wikipedia didn't help me, either, apparently it depends on whether the R-bit is photographic, sugary, or something else. My guess, without looking at the OSPFv3 specification, is that this technique is liable to be better by dint of the R-bit applying to individual prefixes - that is, the technique is "similar, and usually better", because the R-bit provides a "more specific", or possibly "individual" indication of whether a router is active. This may be wrong, in which case it's a perfect illustration of why it's confusing. Dave. --e89a8ff1c58015960b04d4c4462b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Good Evening,

I have been selected= as the Applications Area Directorate reviewer for this draft. =A0(For back= ground on appsdir, please see



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


Document:

= =A0 draft-ietf-ospf-rfc3137bis-03

Titl= e:

=A0=A0OSPF Stub Router Advertisement<= /div>

Reviewer:

=A0 Dave Cridland <d= ave@cridland.net>

Review Date:

=A0 2 Feb 2013=

TL;DR:

This draft discusses ways of having a router visible within = OSPF without offering transit. This seems to be desirable when bringing rou= ters on and offline, and if a router is present but overloaded.

The document offers a well-defined mechanism suitable = for OSPFv2 and OSPFv3, and points out another strategy only suited to OSPFv= 3.

For the most part this draft seems ready for pu= blication, though I'm concerned it offers confusing guidance on which m= echanism to use, and some wordsmithing is needed here.

Detail:
=A72.1 suggests it is a "similar, if no= t better" solution available to OSPFv3 networks. It's not clear to= me if this means "similar, and potentially better", or "sim= ilar, but not better". The second paragraph is also somewhat loose in = whether this technique is recommended or not.

It's not clear to me if the p= ortion following the semicolon is essentially saying that the R-bit is supe= rior; this is not helped by being unclear if "more granular" mean= s finer or coarser. A quick trip to Wikipedia didn't help me, either, a= pparently it depends on whether the R-bit is photographic, sugary, or somet= hing else.

My guess, without looking at the = OSPFv3 specification, is that this technique is liable to be better by dint= of the R-bit applying to individual prefixes - that is, the technique is &= quot;similar, and usually better", because the R-bit provides a "= more specific", or possibly "individual" indication of wheth= er a router is active. This may be wrong, in which case it's a perfect = illustration of why it's confusing.

Dave.
--e89a8ff1c58015960b04d4c4462b-- From andy@hxr.us Sat Feb 2 14:59:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCC821F852B for ; Sat, 2 Feb 2013 14:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rlImV2JX-Ar for ; Sat, 2 Feb 2013 14:59:30 -0800 (PST) Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6A521F8518 for ; Sat, 2 Feb 2013 14:59:29 -0800 (PST) Received: by mail-da0-f42.google.com with SMTP id z17so2180658dal.29 for ; Sat, 02 Feb 2013 14:59:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=O7PoeAG2FjLVvvkVvNO4YY/NxR3k/RjTebAzlSVC8Ok=; b=ZEySacRIo3UElZHY85zQ6gFtbAmO8hS2GRUJD6eBNZ63vEI/M2EhnUd0YMTn9BmEr6 78BiVcRtZ7jVvJFRAoaBOVfL2gjc6UTkWfEneFFXzci6mht6p78dsSNI+zUjpmR51BiA TzUHrRsNwyYTMfwMreNjZZJ6z8KxGh2Gj9xoDOFAC+eka9hP+bDnOlAJNMMjrM9nIHtW vfjOF9C2x5adW5ISunrxlSvxda4sPucdxFWYHjL8vxFZrV+KFyJzFKjpaAEwms98FeaL Sz1+IuXBkEpOaAqkKdIZnoNkB5Ok55rBEBxVbckHtT3TkKlBJjr8UkrfRCOUPO8f/9s8 oUaw== MIME-Version: 1.0 X-Received: by 10.66.84.10 with SMTP id u10mr40988886pay.24.1359845969595; Sat, 02 Feb 2013 14:59:29 -0800 (PST) Received: by 10.66.165.35 with HTTP; Sat, 2 Feb 2013 14:59:29 -0800 (PST) X-Originating-IP: [71.191.219.28] In-Reply-To: References: <70CB0848-00DC-47ED-A9B6-E0353403385F@vpnc.org> <12546069E19E0371DBF0FD27@cyrus.local> Date: Sat, 2 Feb 2013 17:59:29 -0500 Message-ID: From: Andrew Newton To: Francis Galiegue Content-Type: multipart/alternative; boundary=f46d042f96d2f78db504d4c5cfb6 X-Gm-Message-State: ALoCoQnncw5Ayyej/qCn3Vgrp1N6ho78W/SDtkQLk/vhe46fiWhJ20zS1QBk7XEHjRf7A+K9SLvs Cc: Paul Hoffman , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Announce: JSON Schema, I-D version 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Feb 2013 22:59:30 -0000 --f46d042f96d2f78db504d4c5cfb6 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 1, 2013 at 12:52 PM, Francis Galiegue wrote: > * it fails to describe itself; Francis, Can you elaborate more on what you mean by this and why you believe it to be important? -andy --f46d042f96d2f78db504d4c5cfb6 Content-Type: text/html; charset=ISO-8859-1

On Fri, Feb 1, 2013 at 12:52 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:
* it fails to describe itself;

Francis,

Can you elaborate more on what you mean by this and why you believe it to be important?

-andy
--f46d042f96d2f78db504d4c5cfb6-- From fgaliegue@gmail.com Sat Feb 2 15:17:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEEA21F845A for ; Sat, 2 Feb 2013 15:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suSH8j3+WEy7 for ; Sat, 2 Feb 2013 15:17:29 -0800 (PST) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id F2A5821F8459 for ; Sat, 2 Feb 2013 15:17:28 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id k14so5341012oag.25 for ; Sat, 02 Feb 2013 15:17:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5yq4PlCgfCdMvOaSSNiU2LNMB/Nlz2GFk//8Go3pNTc=; b=AibDpF9T8L4cfMkdkEyXSXbTbxRs0gk+MKKC5IsVWiweV6zcQuhQuvkuEJyLgtKtoD lrtnQf2SU/HT0TfPpYrcJ2w7oM4ss0CBnMMczH9Y+nPruOqAR9J8KZM5OSO5gFjGvZvx oBNUgJpZ0ymsg3t7hMGQXUTNkWMx//pZ/Y7xrzIW0YdkqUFz8WHomtonywzLA7LRdk96 boi2eDFlmtjuLX64h7+cHLNtdIXF2XONs7achqTKDP/wecFvB4HQbboUnSUy6DIijLLq Xg5fvQzZqN+IOFbUpFsTn4+Wq+NxJ+xtZ38TjE1nlp6V9VYDM+ABTvbU9A5T8zu43mqH 4Ezg== MIME-Version: 1.0 X-Received: by 10.60.32.243 with SMTP id m19mr8100299oei.13.1359847048207; Sat, 02 Feb 2013 15:17:28 -0800 (PST) Received: by 10.60.13.231 with HTTP; Sat, 2 Feb 2013 15:17:28 -0800 (PST) In-Reply-To: References: <70CB0848-00DC-47ED-A9B6-E0353403385F@vpnc.org> <12546069E19E0371DBF0FD27@cyrus.local> Date: Sun, 3 Feb 2013 00:17:28 +0100 Message-ID: From: Francis Galiegue To: Andrew Newton Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Announce: JSON Schema, I-D version 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Feb 2013 23:17:30 -0000 Hello, On Sat, Feb 2, 2013 at 11:59 PM, Andrew Newton wrote: > > On Fri, Feb 1, 2013 at 12:52 PM, Francis Galiegue > wrote: >> >> * it fails to describe itself; > > > Francis, > > Can you elaborate more on what you mean by this and why you believe it to be > important? > > -andy I mean that you can use JSON Schema (the defined meta schemas to be precise) to validate any other schema, including the meta schema itself, using the same rules as the ones used to validate instances; and if you choose to extend it with your keywords, you can easily grab a copy of the meta schema, modify it, and still use the same rules. This means you can easily check the validity of schemas not under your direct control, and also detect whether you can actually use such schemas (for instance, a schema written for draft v3 will not validate against v4 unless it uses keywords which have not changed definitions inbetween). And as you can use the same code for both syntax checking and instance validation, that leaves less room for errors. Regards, -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From fgaliegue@gmail.com Sun Feb 3 02:14:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25B321F85FC for ; Sun, 3 Feb 2013 02:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXrnA8b-vgU7 for ; Sun, 3 Feb 2013 02:14:26 -0800 (PST) Received: from mail-la0-x232.google.com (la-in-x0232.1e100.net [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8A02C21F85DB for ; Sun, 3 Feb 2013 02:14:26 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id ec20so3746519lab.23 for ; Sun, 03 Feb 2013 02:14:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=g8OJLncZEm5//K7MzmnF1nVAag5TCkc7KY8Svk5d2co=; b=yXHcYRpO45WGTTanaVGRmQAOi0v4KjUeQzFRlYAWIyoN/Qic4PQcciXPWdb/s7Y6p3 z/+e5bTLiD9V379EgLj6Vae0lSjpzd66cjjQ177QUWpLMAuCv3vRTgb7N75RknrshNSM Df5ePaEr99eXXw8RjJUEr6boDwpYKgeAuBOUj0U7CAIt2vRbMVa/7oyLhKttHlXqxhlf U+7yImRSQUf84w18MpwNV65hOGPlllv5c03mAhIeyKmN8VVFcNECcHDXN5C0d5znsdN1 L1eOC+3y83UpM5XJ3/smPKGoffHZ3Y3PF4ph3yQRyqvVZQ7MgLOteqbSHvlbDadtD2Do PutQ== MIME-Version: 1.0 X-Received: by 10.112.41.101 with SMTP id e5mr6519596lbl.120.1359886465132; Sun, 03 Feb 2013 02:14:25 -0800 (PST) Received: by 10.112.54.134 with HTTP; Sun, 3 Feb 2013 02:14:25 -0800 (PST) Date: Sun, 3 Feb 2013 11:14:25 +0100 Message-ID: From: Francis Galiegue To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [apps-discuss] Question about JSON Patch I-D 10, section 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Feb 2013 10:14:27 -0000 Hello, The beginning of this section says: > Operation objects MUST have exactly one "op" member, whose value > indicates the operation to perform. Well, JSON Patch is written in JSON and RFC 4627 says that JSON Objects should have unique member names anyway, so why is this precised here? -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From fgaliegue@gmail.com Sun Feb 3 02:36:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED72721F8620 for ; Sun, 3 Feb 2013 02:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-bwp7tIvb-G for ; Sun, 3 Feb 2013 02:36:29 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id C712521F85FC for ; Sun, 3 Feb 2013 02:36:28 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id n3so5772535lbo.20 for ; Sun, 03 Feb 2013 02:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0QzpbfGf5QtQxyluKl+RHo2jXihufrORTv8wF00tHxI=; b=MN+iuuDtYdGoOET3dw4ZLDgdrKy2KqOkySAidOyG3OmvNHJ/6Kikq27t7HP6uty+Z3 yar1Z+pYSXPBeMBlRvADkNDhKBiIgHoA9WK5XKzmXpG56wdWs8F+64WVGceW4v9qEk3e zEc+1hnFTKSGuopYc/LpNVUSq4tkaCbPHpjskN9xOrfFJPXjU8SNZyQmgGp3EUoRjePt W61LiIBDXPTD+W0Ncon9ScWC5QraSRCrowiuHixtnVPU0wXazttnNwhVrihOF1lhPFwq qr8aH8V5/R+U2r8rD5zVuiAxYzKfZD0Wgc6NAPKS4zPAkAZZ/+mtCipTh6z1ZDvVJ16W YFoQ== MIME-Version: 1.0 X-Received: by 10.112.25.106 with SMTP id b10mr6780209lbg.68.1359887787750; Sun, 03 Feb 2013 02:36:27 -0800 (PST) Received: by 10.112.54.134 with HTTP; Sun, 3 Feb 2013 02:36:27 -0800 (PST) In-Reply-To: References: <70CB0848-00DC-47ED-A9B6-E0353403385F@vpnc.org> <12546069E19E0371DBF0FD27@cyrus.local> Date: Sun, 3 Feb 2013 11:36:27 +0100 Message-ID: From: Francis Galiegue To: Andrew Newton Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Announce: JSON Schema, I-D version 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Feb 2013 10:36:30 -0000 On Sun, Feb 3, 2013 at 12:17 AM, Francis Galiegue wrote: [...] > > This means you can easily check the validity of schemas not under your > direct control, and also detect whether you can actually use such > schemas (for instance, a schema written for draft v3 will not validate > against v4 unless it uses keywords which have not changed definitions > inbetween). And as you can use the same code for both syntax checking > and instance validation, that leaves less room for errors. > And also, it can easily describe other JSON-based formats. For instance, it took me 10 minutes to write this: https://github.com/fge/json-schema-validator/blob/master/src/main/resources/json-patch.json If you receive a patch, you can use JSON Schema to filter out bad patches before even attempting to patch. -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From barryleiba.mailing.lists@gmail.com Sun Feb 3 03:52:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06A621F843D for ; Sun, 3 Feb 2013 03:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.01 X-Spam-Level: X-Spam-Status: No, score=-103.01 tagged_above=-999 required=5 tests=[AWL=-0.034, 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 4-AsTN-Rvi1v for ; Sun, 3 Feb 2013 03:52:28 -0800 (PST) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 58E2721F843C for ; Sun, 3 Feb 2013 03:52:28 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id jx10so3955291veb.25 for ; Sun, 03 Feb 2013 03:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1OsBlMYJ49lmcn3CUHZf4HqgJFX4NGZta+7+Qh0F/kQ=; b=enPSRO6ipLBnmQaXgTbs8y5HN8T0cf6R6PzDMX9aapYNcm5IUZ+l/bLn9av9YmKGjt zwqUitdZUQO9ZVJg1BpG4CsKlThkFuTrUZtp7/uHhRpKGnnYILrs0suBNUnei6QQSSM/ MXNyo3m1wBBr231fFq4YZHQ/G/yXcXtFkRwQDZ/C8bNkOZLlYCZxDhI6RVhzJ6CU8B1t SMmGb/vk29fVsUAwdoF2yN3T0Cu0HKL2LLD+ADCEdL7caIRhvJxQ6pwQe2wu/RQiqzPx rcWi4RwtTBJALhtWW+AENAP9wVd1T+RWObOz4g51ntBpe62azDHLWnmXCDn1zyO+M1gp 9JhQ== MIME-Version: 1.0 X-Received: by 10.58.48.231 with SMTP id p7mr13839534ven.11.1359892347616; Sun, 03 Feb 2013 03:52:27 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Sun, 3 Feb 2013 03:52:27 -0800 (PST) In-Reply-To: References: Date: Sun, 3 Feb 2013 20:52:27 +0900 X-Google-Sender-Auth: -PxRb7WKm6jy83S748D2ejLEGlw Message-ID: From: Barry Leiba To: Francis Galiegue Content-Type: multipart/alternative; boundary=089e01182b264ffbe904d4d09c65 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Question about JSON Patch I-D 10, section 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Feb 2013 11:52:29 -0000 --089e01182b264ffbe904d4d09c65 Content-Type: text/plain; charset=ISO-8859-1 > > > Operation objects MUST have exactly one "op" member, whose value > > indicates the operation to perform. > > Well, JSON Patch is written in JSON and RFC 4627 says that JSON > Objects should have unique member names anyway, so why is this > precised here? > Well, first, there's otherwise no requirement for a member named "op", so this needs to require that. Second, 4627 says, "The names within an object SHOULD be unique," which leaves a possibility that they are not. Here, "MUST have exactly one" more strictly specifies this for "op". Barry --089e01182b264ffbe904d4d09c65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Operation objects MUST have exactly one= "op" member, whose value
> indicates the operation to perform.

Well, JSON Patch is written in JSON and RFC 4627 says that JSON
Objects should have unique member names anyway, so why is this
precised here?

Well, first, there's= otherwise no requirement=A0for a member named "op",=A0=A0so this= needs to require that. =A0Second, 4627 says,=A0"The name= s within an object SHOULD be unique," which leaves a possibility that = they are not. =A0Here, "MUST have exactly one" more strictly spec= ifies this for "op".

Barry
--089e01182b264ffbe904d4d09c65-- From fgaliegue@gmail.com Sun Feb 3 04:01:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD8021F8648 for ; Sun, 3 Feb 2013 04:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBK7tBztV5WP for ; Sun, 3 Feb 2013 04:01:38 -0800 (PST) Received: from mail-la0-x233.google.com (la-in-x0233.1e100.net [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA8821F8512 for ; Sun, 3 Feb 2013 04:01:37 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id fo13so3891546lab.38 for ; Sun, 03 Feb 2013 04:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rhLaB8K9kzmD1gAihC6plmlrr8aWt9U0Y9k9P5xNoJI=; b=iDXNwR5yd7AekYyFec3HurUKBanCkI3x16y84VvtxV9eu9NtRqXyHgr2UNhxQiJ30K SgxPw7iTwjic7YNLgjUogbUFjXuGeO13WlZvSiYkNtD9+RUXjBx3ysqvtvTBgVkge05O SBiDWqONxGTOWBv7x2fj/bpWNP/pjYKJ+j2UESKDjOosRPyLsEey28dl44ns+L2tZKb5 o1IbMDKr/4eJrwKwtNeZjwLTkcJEof3qsxrem7ua4X/T/fEUC1DRxncJTMLm0X1SIi0c tnbbzYdXDkUSQ7eFLSNVjjuuWs7+DoSDwYMKgB7YrP+ASMz1ikfa5RBUSfBwJLkrmvTA 4shA== MIME-Version: 1.0 X-Received: by 10.112.17.3 with SMTP id k3mr7002613lbd.42.1359892897036; Sun, 03 Feb 2013 04:01:37 -0800 (PST) Received: by 10.112.54.134 with HTTP; Sun, 3 Feb 2013 04:01:36 -0800 (PST) In-Reply-To: References: Date: Sun, 3 Feb 2013 13:01:36 +0100 Message-ID: From: Francis Galiegue To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Question about JSON Patch I-D 10, section 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Feb 2013 12:01:39 -0000 On Sun, Feb 3, 2013 at 12:52 PM, Barry Leiba wrote: [...] > > Well, first, there's otherwise no requirement for a member named "op", so > this needs to require that. Second, 4627 says, "The names within an object > SHOULD be unique," which leaves a possibility that they are not. Here, > "MUST have exactly one" more strictly specifies this for "op". > OK, but JSON Patch is a JSON text anyway, and if duplicate member names are found during parsing, JSON Patch cannot do anything about it anyway, right? I mean, it is up to the parser, here, not JSON Patch. For instance, some parsers will "swallow" duplicates and JSON Patch will only ever see the member elected by the parser for inclusion. But basically, the behaviour of the parser in this situation is undefined. To my eyes, it means that JSON Patch imposes requirements on the _parser_ that it shouldn't impose. I think specifying "Operations MUST have a member named 'op'" would be enough. Thoughts? -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From markus.lanthaler@gmx.net Sun Feb 3 04:16:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967A221F8623 for ; Sun, 3 Feb 2013 04:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAthl7fcdBd8 for ; Sun, 3 Feb 2013 04:16:56 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id E297221F8621 for ; Sun, 3 Feb 2013 04:16:55 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LuZpe-1V1ftO2vbM-00zjYa for ; Sun, 03 Feb 2013 13:16:54 +0100 Received: (qmail invoked by alias); 03 Feb 2013 12:16:54 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp010) with SMTP; 03 Feb 2013 13:16:54 +0100 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX18YrEhtDQ8YGAG3DuqSn/NAdRdrwOp/u8/vUFxIBD NiWSU3YtcbYrJY From: "Markus Lanthaler" To: "'Francis Galiegue'" , "'Barry Leiba'" References: In-Reply-To: Date: Sun, 3 Feb 2013 13:16:52 +0100 Message-ID: <008001ce0208$5abb95c0$1032c140$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4CBjrOFO/Iq87/SPiXYUU+7lvsDwAAZvGQ Content-Language: de X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Question about JSON Patch I-D 10, section 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Feb 2013 12:16:56 -0000 On Sunday, February 03, 2013 1:02 PM, Francis Galiegue wrote: > OK, but JSON Patch is a JSON text anyway, and if duplicate member > names are found during parsing, JSON Patch cannot do anything about it > anyway, right? > I mean, it is up to the parser, here, not JSON Patch. For instance, > some parsers will "swallow" duplicates and JSON Patch will only ever > see the member elected by the parser for inclusion. But basically, the > behaviour of the parser in this situation is undefined. Right. That's exactly the reason why you need to specify it at the format level. If you don't, the outcome will be nondeterministic as you outlined above. > To my eyes, it means that JSON Patch imposes requirements on the > _parser_ that it shouldn't impose. I think specifying "Operations MUST > have a member named 'op'" would be enough. Nope. It imposes requirements on the format so that every parser produces the same deterministic output. Cheers, Markus -- Markus Lanthaler @markuslanthaler From dcrocker@bbiw.net Sun Feb 3 07:15:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95E421F8533; Sun, 3 Feb 2013 07:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUKCngUc-LtI; Sun, 3 Feb 2013 07:15:28 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8950E21F84E0; Sun, 3 Feb 2013 07:15:28 -0800 (PST) Received: from [172.17.100.106] (rrcs-24-43-241-82.west.biz.rr.com [24.43.241.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r13FFKTZ004668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 3 Feb 2013 07:15:21 -0800 Message-ID: <510E7EFD.8060109@bbiw.net> Date: Sun, 03 Feb 2013 07:15:09 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Michael Tuexen References: <510D61AB.5040704@dcrocker.net> In-Reply-To: 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, 03 Feb 2013 07:15:21 -0800 (PST) Cc: draft-ietf-tsvwg-sctp-udp-encaps.all@tools.ietf.org, iesg , Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-tsvwg-sctp-udp-encaps X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Feb 2013 15:15:29 -0000 Michael, Thanks for the speedy response. More comments inline. We probably don't need to iterate further. As I said in the review, the doc is workable as is; I'm only suggesting changes that seem to me will improve clarity a bit. d/ On 2/3/2013 5:42 AM, Michael Tuexen wrote: > On Feb 2, 2013, at 7:57 PM, Dave Crocker wrote: >>> 3.1. Portable SCTP Implementations >> ... >>> A crucial point for implementing SCTP in user space is controlling >>> the source address of outgoing packets. This is not an issue when >>> using all available addresses. However, this is not the case when >> >> What is meant by "using all available addresses"? > > If the SCTP endpoint can use all addresses configured at the IP layer. > > In socket terms: You bound the socket to the wildcard address (0.0.0.0 or ::0). I guess I suggest adding this bit of clarification, although it might help to change 'use' to something more specific, possibly like: This is not an issue when the SCTP implementation is able to bind to any possible address configured at the IP layer. I'm not sure I'm interpreting the details correctly; if not, just use my text as an exemplar for the type of clarification I'm suggesting. (In case it isn't obvious, I tend to do review-oriented reading with any eye towards /mis/interpretation by a less-expert reader...) >>> chunks. To use multiple addresses, the dynamic address >>> reconfiguration extension described in [RFC5061] MUST be used with >>> wildcard addresses in combination with [RFC4895]. >> >> wildcard addresses -> wildcard source addresses (?) > > No. The addresses used in the ASCONF/ASCONF-ACK chunks described in RFC 5061 > are wildcard addresses. Ok. Then perhaps: MUST be used with wildcard addressed used in the ASCONF/ASCONF-ACK chunks described in RFC 5061, in combination with [RFC4895]. >>> 4. SCTP over UDP >>> >>> 4.1. Architectural Considerations >>> >>> An SCTP implementation supporting UDP encapsulation MUST store a >>> remote UDP encapsulation port number per destination address for each >>> SCTP association. >> >> Must store it /where/? > > I think different SCTP implementation will have different data structures for > variable which are per remote address. > >>> Or perhaps this isn't really a normative specification statement but rather an architectural discussion that provides a basis for the later specification details? If so, remove the normative language here. > > It is important that this port number is a variable per destination address > for each SCTP association, not just one per association or so. > It make clear how to store the variable. Later in the text it is only described how > you modify and use the variable. So do you want me to change the MUST to a must? OK. Then I suggest moving this away from using normative language, since the issue is higher-level, rather than specific. Something along the lines of: UDP encapsulation for SCTP permits use of different UDP port numbers. Consequently, an implementation's maintenance of tunneling state information requires retention of the port number used by the remote side of the tunneling exchange. >>> 4.3. Encapsulation Procedure >> ... >>> For IPv4, the UDP checksum SHOULD be computed and the SCTP checksum >>> MUST be computed, whereas for IPv6, the UDP checksum and the SCTP >>> checksum MUST be computed. >> >>> Given the protections provided by the SCTP checksum, why is a UDP checksum needed? (Note the logic of dropping checksum from IPv6...) > We don't need any kind of error protection, just being able to interop. > When requiring to disable the UDP checksum for IPv4, at least on FreeBSD, > this is a host wide configuration option. For IPv6 it will delay each > connection setup in case not all nodes involved support disabled > checksums. On FreeBSD at least, disabling UDP checksum for IPv6 is > not supported currently. So you would have the penalty always. The problem with the current language is that it doesn't provide a context for the SHOULD. I'm not sure what language to suggest to clarify this. Something like "SHOULD support UDP checksum to the extent needed for interoperability" seems poor... >>> 4.4. Decapsulation Procedure >>> >>> When an encapsulated packet is received, the UDP header is removed. >>> Then a lookup is performed to find the association for the received >> >> Where is the lookup algorithm specified? In particular, what information is used to perform the lookup. > > This is the generic lookup each SCTP stack perform when a packet is received. > Conceptually, you take the source and destination address and port number to > find the association and path and then verify the v-tag. Ah. The current text looked like it was specifying something new. So I'll suggest: Then the generic lookup is performed, as done by a SCTP stack when a packet is received. >>> SCTP packet. After finding the SCTP association (which includes >>> checking the verification tag), the UDP source port MUST be stored as >>> the encapsulation port for the destination address the SCTP packet is >>> received from (see Section 4.1). >>> >>> Please note that when a non-encapsulated SCTP packet is received, the >>> encapsulation of outgoing packets belonging to the same association >>> and the corresponding destination address MUST be disabled. >> >>> "Please note" is appropriate for a comment, not a strongly normative statement. That is, I think it undermines the reader's understanding that this is a normative requirement. > This comment was already raised. The text has been changed (for the next revision) to > When a non-encapsulated SCTP packet is received by the > SCTP stack, the encapsulation of outgoing packets belonging > to the same association and the corresponding destination > address MUST be disabled. wfm. >> >> >> >>> 4.6. Path MTU Considerations >>> >>> If an SCTP endpoint starts to encapsulate the packets of a path, it >>> MUST decrease the Path MTU of that path by the size of the UDP >>> header. If it stops encapsulating them, the Path MTU SHOULD be >>> increased by the size of the UDP header. >> >>> How can a user-level SCTP control Path MTU, particularly when it's access to the IP layer (and presumably ICMP) is limited? > Some operating systems allow an application to set the DF bit. That is all you need. > Implementing PathMTU discovery should not rely on ICMP or ICMv6. SCTP can send > probe packets consisting of HEARTBEAT and PADDING chunks. If no corresponding > HEARTBEAT-ACK is received, the probe packet was lost. >> >> Perhaps you mean "adjust SCTP's use of the provided Path MTU"? That is, provide a calculation on top of what the infrastucture says is available? > > It depends if the infrastructure can provide it. SCTP does provide this functionality. Well, I'm not sure what to suggest. I think the current language implicitly encourages the kind of confusion I experienced. But the topic isn't straightforward. I think of Path MTU as a mechanism that is independent of other services, such as transport, and that those other services are clients of the Path MTU value. That's why I suggested casting this as "modifying what is produced". Mumble. Sorry I can't offer something more coherent. >>> 4.7. Handling of Embedded IP-addresses >>> >>> When using UDP encapsulation for legacy NAT traversal, IP addresses >>> that might require translation MUST NOT be put into any SCTP packet. >>> >>> This means that a multi homed SCTP association is setup initially as >>> a singled homed one and the protocol extension [RFC5061] in >>> combination with [RFC4895] is used to add the other addresses. Only >>> wildcard addresses are put into the SCTP packet. >> >> This is the second reference to the use of wildcard for this. Since inclusion >> of actual addresses is needed for correlation/rendezvous functions, it would >> help to have a pointer or discussion about how the correlation/rendezvous is >> done when wildcarding is done. > > No, RFC 4895 provides a security mechanism required by RFC 5061. RFC 5061 > requires the use of RFC 4895. > Using wildcard addresses avoids embedding IP addresses in the SCTP packet. > When using wildcard addresses you are referring to the source address > of the SCTP packet. The current language seems to mix references to the two sides of the exchange; use of the passive tense, with "are put", further obscures which side does what. >>> 5. Socket API Considerations >>> >>> This section describes how the socket API defined in [RFC6458] is >> >> since the section is informational, rather than normative, I suggest: >> >> is -> can be > Changed. However, in RFC 6525 we used "needs to be extended". Would that > be acceptable to you? wfm. >> >>> extended to provide a way for the application to control the UDP >>> encapsulation. >> >> >> >>> 7. Security Considerations >>> >>> Encapsulating SCTP into UDP does not add any additional security >>> considerations to the ones given in [RFC4960] and [RFC5061]. >>> >>> Firewalls inspecting SCTP packets must also be aware of the >>> encapsulation and apply corresponding rules to the encapsulated >>> packets. >> >> "must"? normative? > The sentence as above was suggested the the sec review. >> >> The problem with this, whether normative or not, is that the purpose of this encapsulation is to transit intermediaries that don't support SCTP. That's a conflicting goal and probably is worth noting. > As stated above, this sentence was suggested by the sec review. > I don't agree that it is a necessarily a contradiction. Since the > firewall supports SCTP (it can inspect them), you wouldn't use UDP > to get through it. I understand the security orientation that produced the text. But as you note, if the firewall is SCTP aware, then you probably won't be using UDP to transit the firewall. That makes the document irrelevant to the case this text covers... (I'm counting NAT and Firewall as likely to be the same box.) I think the security considerations concern is better served by simply noting that UDP encapsulation can serve to hide the use of SCTP from firewalls along the path, if the firewall is not SCTP aware. A statement like this highlights the issue but does not attempt to dictate how to deal with it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From tuexen@fh-muenster.de Sun Feb 3 05:42:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B90C21F86C1; Sun, 3 Feb 2013 05:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zrNi0zKleze; Sun, 3 Feb 2013 05:42:08 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id CEE1E21F86A1; Sun, 3 Feb 2013 05:42:07 -0800 (PST) Received: from [192.168.1.101] (p508FAAD0.dip.t-dialin.net [80.143.170.208]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0D6F71C0C0BF8; Sun, 3 Feb 2013 14:42:05 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: <510D61AB.5040704@dcrocker.net> Date: Sun, 3 Feb 2013 14:42:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <510D61AB.5040704@dcrocker.net> To: Dave Crocker X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Sun, 03 Feb 2013 08:02:35 -0800 Cc: draft-ietf-tsvwg-sctp-udp-encaps.all@tools.ietf.org, iesg , Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-tsvwg-sctp-udp-encaps X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Feb 2013 13:42:10 -0000 On Feb 2, 2013, at 7:57 PM, Dave Crocker wrote: > Howdy. Hi Dave, thanks a lot for your comments. See my answers in-line. Best regards Michael >=20 > I have been selected as the Applications Area Directorate reviewer for = this draft. (For background on appsdir, please see >=20 > = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate = ). >=20 > 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. >=20 >=20 > Document: >=20 >=20 > draft-ietf-tsvwg-sctp-udp-encaps-09 >=20 > Title: >=20 > UDP Encapsulation of SCTP Packets >=20 > Reviewer: >=20 > D. Crocker >=20 > Review Date: >=20 > 2 Feb 2013 >=20 >=20 > Summary: >=20 > As a transport-level protocol, SCTP can encounter barriers at the = endpoints, through inadequate API or privilege access to raw IP = services, or at intermediaries such as NATs that do not support SCTP. = Tunneling is the usual solution to these type of barriers. The current = draft specifies encapsulation for tunneling SCTP and discusses = operational concerns. >=20 > The specification is usable in its current form. Revision, per = the below comments, would improve its clarity, especially for = less-knowledgeable readers. >=20 > Also, a long-standing issue for use of UDP is the upper-layer = requirement to provide congestion control and reliability mechanisms, = since UDP doesn't. In the case of a tunneled transport service, like = SCTP, this is obviously a trivial issue. However given the = long-standing UDP concern, I suggest adding a pro-forma sentence to make = this explicit. Something like: >=20 > "SCTP provides the necessary congestion control and = reliability service that UDP does not perform." OK, added as the last sentence in the Introduction section. >=20 >=20 > Detailed comments: >=20 >=20 >> Abstract >>=20 >> This document describes a simple method of encapsulating SCTP = Packets >> into UDP packets and its limitations. This allows the usage of = SCTP >> in networks with legacy NAT not supporting SCTP. It can also be = used >> to implement SCTP on hosts without directly accessing the IP-layer, >> for example implementing it as part of the application without >> requiring special privileges. >> 1. Introduction >>=20 >> This document describes a simple method of encapsulating SCTP = packets >> into UDP packets. SCTP as defined in [RFC4960] runs directly over >> IPv4 or IPv6. There are two main reasons for encapsulating SCTP >> packets: >>=20 >> o Allow SCTP traffic to pass legacy NATs, which do not provide >=20 > pass -> pass through Added to the CVS version. I will be included in the next revision. >=20 >=20 >> native SCTP support as specified in [I-D.ietf-behave-sctpnat] = and >> [I-D.ietf-tsvwg-natsupp]. >=20 >=20 >=20 >> 3.1. Portable SCTP Implementations > ... >> A crucial point for implementing SCTP in user space is controlling >> the source address of outgoing packets. This is not an issue when >> using all available addresses. However, this is not the case when >=20 > What is meant by "using all available addresses"? If the SCTP endpoint can use all addresses configured at the IP layer. In socket terms: You bound the socket to the wildcard address (0.0.0.0 = or ::0). >=20 >=20 >> also using the address management required for NAT traversal >> described in Section 4.7. >=20 >=20 >> 3.2. Legacy NAT Traversal >>=20 >> Using UDP encapsulation allows SCTP communication when traversing >> legacy NATs (i.e those NATs not supporting SCTP as described in >> [I-D.ietf-behave-sctpnat] and [I-D.ietf-tsvwg-natsupp]). It is >> important to realize that for single homed associations it is only >> necessary that no IP addresses are listed in the INIT and INIT-ACK >=20 > This seems to be a normative directive, but it does not use normative = language. Perhaps: >=20 > For single-homed associations IP addresses MUST NOT be listed in > the INIT and INIT-ACK OK. >=20 >=20 >> chunks. To use multiple addresses, the dynamic address >> reconfiguration extension described in [RFC5061] MUST be used with >> wildcard addresses in combination with [RFC4895]. >=20 > wildcard addresses -> wildcard source addresses (?) No. The addresses used in the ASCONF/ASCONF-ACK chunks described in RFC = 5061 are wildcard addresses. >=20 >=20 >> For multi-homed SCTP association the address management as = described >> in Section 4.7 MUST be performed. >>=20 >> SCTP sends periodically HEARTBEAT chunks on all idle paths. These >=20 > periodically -> periodic Changed in the CVS version. >=20 >=20 >> can be used to keep the NAT state alive. >=20 > can be used to keep -> can keep Changed in the CVS version. >=20 >=20 >>=20 >> 4. SCTP over UDP >>=20 >> 4.1. Architectural Considerations >>=20 >> An SCTP implementation supporting UDP encapsulation MUST store a >> remote UDP encapsulation port number per destination address for = each >> SCTP association. >=20 > Must store it /where/? I think different SCTP implementation will have different data = structures for variable which are per remote address. >=20 > Or perhaps this isn't really a normative specification statement but = rather an architectural discussion that provides a basis for the later = specification details? If so, remove the normative language here. It is important that this port number is a variable per destination = address for each SCTP association, not just one per association or so. It make clear how to store the variable. Later in the text it is only = described how you modify and use the variable. So do you want me to change the MUST to = a must? >=20 >=20 >>=20 >> Each SCTP stack uses a single local UDP encapsulation port number = as >> the destination port for all its incoming SCTP packets. The IANA >> assigned value of 9899 (sctp-tunneling) MAY be used as this port >> number. If there is only a single SCTP implementation on a host = (for >> example, a kernel implementation being part of the operating = system), >> using a single UDP encapsulation port number per host can be >> advantageous (e.g., this reduces the number of mappings in = firewalls >> and NATs, among other things). Using a single UDP encapsulation = port >> number per host is not possible if the SCTP stack is implemented as >> part of an application. >>=20 >> 4.2. Packet Format >>=20 >> To encapsulate an SCTP packet, a UDP header as defined in [RFC0768] >> is inserted between the IP header as defined in [RFC0791] and the >> SCTP common header as defined in [RFC4960]. >=20 > Interesting perspective. It casts UDP as crating a shim layer. I = suppose that's what tunneling actually is... >=20 >=20 >> Figure 1 shows the packet format of an encapsulated SCTP packet = when >> IPv4 is used. >=20 >=20 >> 4.3. Encapsulation Procedure > ... >> For IPv4, the UDP checksum SHOULD be computed and the SCTP checksum >> MUST be computed, whereas for IPv6, the UDP checksum and the SCTP >> checksum MUST be computed. >=20 > Given the protections provided by the SCTP checksum, why is a UDP = checksum needed? (Note the logic of dropping checksum from IPv6...) We don't need any kind of error protection, just being able to interop. When requiring to disable the UDP checksum for IPv4, at least on = FreeBSD, this is a host wide configuration option. For IPv6 it will delay each connection setup in case not all nodes involved support disabled checksums. On FreeBSD at least, disabling UDP checksum for IPv6 is not supported currently. So you would have the penalty always. >=20 >=20 >> 4.4. Decapsulation Procedure >>=20 >> When an encapsulated packet is received, the UDP header is removed. >> Then a lookup is performed to find the association for the received >=20 > Where is the lookup algorithm specified? In particular, what = information is used to perform the lookup. This is the generic lookup each SCTP stack perform when a packet is = received. Conceptually, you take the source and destination address and port = number to find the association and path and then verify the v-tag. >=20 >=20 >> SCTP packet. After finding the SCTP association (which includes >> checking the verification tag), the UDP source port MUST be stored = as >> the encapsulation port for the destination address the SCTP packet = is >> received from (see Section 4.1). >>=20 >> Please note that when a non-encapsulated SCTP packet is received, = the >> encapsulation of outgoing packets belonging to the same association >> and the corresponding destination address MUST be disabled. >=20 > "Please note" is appropriate for a comment, not a strongly normative = statement. That is, I think it undermines the reader's understanding = that this is a normative requirement. This comment was already raised. The text has been changed (for the next = revision) to When a non-encapsulated SCTP packet is received by the SCTP stack, the encapsulation of outgoing packets belonging to the same association and the corresponding destination address MUST be disabled. >=20 >=20 >=20 >> 4.6. Path MTU Considerations >>=20 >> If an SCTP endpoint starts to encapsulate the packets of a path, it >> MUST decrease the Path MTU of that path by the size of the UDP >> header. If it stops encapsulating them, the Path MTU SHOULD be >> increased by the size of the UDP header. >=20 > How can a user-level SCTP control Path MTU, particularly when it's = access to the IP layer (and presumably ICMP) is limited? Some operating systems allow an application to set the DF bit. That is = all you need. Implementing PathMTU discovery should not rely on ICMP or ICMv6. SCTP = can send probe packets consisting of HEARTBEAT and PADDING chunks. If no = corresponding HEARTBEAT-ACK is received, the probe packet was lost. >=20 > Perhaps you mean "adjust SCTP's use of the provided Path MTU"? That = is, provide a calculation on top of what the infrastucture says is = available? It depends if the infrastructure can provide it. SCTP does provide this = functionality. >=20 >=20 >> When performing Path MTU discovery as described in [RFC4820] and >> [RFC4821] it MUST be taken into account that one cannot rely on the >> feedback provided by ICMP or ICMPv6 due to the limitation laid out = in >> Section 4.5. >=20 > Normative language in a sentence like this is actually not very = helpful, since it does not specify what behaviors are being dictated. = Where is the guidance that says what it means for this to "be taken into = account"? RFC 4821 provides the specification for doing path MTU discovery and RFC = 4820 defines the SCTP probe packets used for implementing path MTU discovery = based on RFC 4821 for SCTP.=20 >=20 >=20 >> If the implementation does not allow to control the dont't fragment >=20 > does not allow to control the dont't fragment > -> > does not allow control of the don't fragment Already changed for next revision. >=20 >=20 >> (DF)-bit contained in the IPv4 header, then Path MTU discovery = can't >> be used. In this case, an implementation specific value should be >> used instead. >=20 > Does this implementation-specific activity require some sort of = coordination between the end-points? No. >=20 >=20 >>=20 >> 4.7. Handling of Embedded IP-addresses >>=20 >> When using UDP encapsulation for legacy NAT traversal, IP addresses >> that might require translation MUST NOT be put into any SCTP = packet. >>=20 >> This means that a multi homed SCTP association is setup initially = as >> a singled homed one and the protocol extension [RFC5061] in >> combination with [RFC4895] is used to add the other addresses. = Only >> wildcard addresses are put into the SCTP packet. >=20 > This is the second reference to the use of wildcard for this. Since = inclusion of actual addresses is needed for correlation/rendezvous = functions, it would help to have a pointer or discussion about how the = correlation/rendezvous is done when wildcarding is done. No, RFC 4895 provides a security mechanism required by RFC 5061. RFC = 5061 requires the use of RFC 4895. Using wildcard addresses avoids embedding IP addresses in the SCTP = packet. When using wildcard addresses you are referring to the source address of the SCTP packet. >=20 >=20 >> When addresses are changed during the lifetime of an association >> [RFC5061] MUST be used with wildcard addresses only. >=20 >> 5. Socket API Considerations >>=20 >> This section describes how the socket API defined in [RFC6458] is >=20 > since the section is informational, rather than normative, I suggest: >=20 > is -> can be Changed. However, in RFC 6525 we used "needs to be extended". Would that be acceptable to you? >=20 >=20 >> extended to provide a way for the application to control the UDP >> encapsulation. >=20 >=20 >=20 >> 7. Security Considerations >>=20 >> Encapsulating SCTP into UDP does not add any additional security >> considerations to the ones given in [RFC4960] and [RFC5061]. >>=20 >> Firewalls inspecting SCTP packets must also be aware of the >> encapsulation and apply corresponding rules to the encapsulated >> packets. >=20 > "must"? normative? The sentence as above was suggested the the sec review. >=20 > The problem with this, whether normative or not, is that the purpose = of this encapsulation is to transit intermediaries that don't support = SCTP. That's a conflicting goal and probably is worth noting. As stated above, this sentence was suggested by the sec review. I don't agree that it is a necessarily a contradiction. Since the firewall supports SCTP (it can inspect them), you wouldn't use UDP to get through it. >=20 >=20 >> An attacker might send a malicious UDP packet towards an SCTP end- >> point to change the encapsulation port for a single remote address = of >=20 >=20 >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 From rbonica@juniper.net Sun Feb 3 12:33:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFF121F8806; Sun, 3 Feb 2013 12:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.312 X-Spam-Level: X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbszldPabrTd; Sun, 3 Feb 2013 12:33:29 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id E4E6721F87EA; Sun, 3 Feb 2013 12:33:28 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUQ7JmIM+esXPVHNZ8wx030Ui+QneMvAx@postini.com; Sun, 03 Feb 2013 12:33:29 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 3 Feb 2013 12:29:13 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Sun, 3 Feb 2013 12:29:12 -0800 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.139) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 3 Feb 2013 12:38:03 -0800 Received: from mail64-db3-R.bigfish.com (10.3.81.240) by DB3EHSOBE009.bigfish.com (10.3.84.29) with Microsoft SMTP Server id 14.1.225.23; Sun, 3 Feb 2013 20:29:09 +0000 Received: from mail64-db3 (localhost [127.0.0.1]) by mail64-db3-R.bigfish.com (Postfix) with ESMTP id 82C17200FA; Sun, 3 Feb 2013 20:29:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -1 X-BigFish: PS-1(zzda00h1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h1155h) Received: from mail64-db3 (localhost.localdomain [127.0.0.1]) by mail64-db3 (MessageSwitch) id 1359923347539459_22897; Sun, 3 Feb 2013 20:29:07 +0000 (UTC) Received: from DB3EHSMHS014.bigfish.com (unknown [10.3.81.233]) by mail64-db3.bigfish.com (Postfix) with ESMTP id 80F932C005C; Sun, 3 Feb 2013 20:29:07 +0000 (UTC) Received: from BY2PRD0512HT002.namprd05.prod.outlook.com (157.56.238.5) by DB3EHSMHS014.bigfish.com (10.3.87.114) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 3 Feb 2013 20:29:07 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.250]) by BY2PRD0512HT002.namprd05.prod.outlook.com ([10.255.243.35]) with mapi id 14.16.0263.000; Sun, 3 Feb 2013 20:29:05 +0000 From: Ronald Bonica To: S Moonesamy , "apps-discuss@ietf.org" , "draft-gp-obsolete-icmp-types.all@tools.ietf.org" Thread-Topic: APPSDIR review of draft-gp-obsolete-icmp-types-iana-01 Thread-Index: AQHOAONfcAZ8wzRYM0eJAPpAO+kgIphol7OQ Date: Sun, 3 Feb 2013 20:29:05 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2501E7D808@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <6.2.5.6.2.20130201161811.0b38bb90@elandnews.com> In-Reply-To: <6.2.5.6.2.20130201161811.0b38bb90@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ELANDSYS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "iesg@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-gp-obsolete-icmp-types-iana-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, 03 Feb 2013 20:33:29 -0000 >=20 > Nits: >=20 > Why is the intended status "Standards Track"? >=20 > Regards, > S. Moonesamy >=20 SM, That's a really good question! I wish I knew the answer! So long as we deprecate the registry items, I am happy with whatever label = people want to put on the document. Ron From sm@elandsys.com Sun Feb 3 15:34:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B8D21F854D; Sun, 3 Feb 2013 15:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24CmDOnV0UU6; Sun, 3 Feb 2013 15:34:26 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E8C21F8414; Sun, 3 Feb 2013 15:34:25 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.148.187]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r13NY99f021679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Feb 2013 15:34:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359934463; bh=geBUmQWYy1TAtEm5vCwE56FMmMed7MTBk7UC1/hSsu0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vWjOCcYs5eObkSirvupJhdaH2ka73zDMAxDMmKDaGWV4foB0yGiQSf/wuDFG6Its5 mxFkCCKr0BPK5uAGRm3FsKQ6bMuVsSlKvFb7qm0sIfZxbwKkAmQjjgyvR94B1jiQzi 7f8JYDZP16cNGY+yrFCNrAHZ/wg8JOO0c1MbJaZE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1359934463; i=@elandsys.com; bh=geBUmQWYy1TAtEm5vCwE56FMmMed7MTBk7UC1/hSsu0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kYBOXwcBue8Sw7y9WmN8+BHtnq4K4F3ZR8Ekgz9U2X1TvBu6UNqoUJTxgIZ506pPy oCwiP++Iql7XDshJH1GTp8rzE9OZQ4ss1/asAC7c9AIWW+hAgJ4kfjwJm/oprElUoa mNtgC8R3Ma6YQFh3OVtRZktdUmslhtOn56MV8vSo= Message-Id: <6.2.5.6.2.20130203143036.0959c2d0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 03 Feb 2013 15:17:24 -0800 To: Ronald Bonica From: S Moonesamy In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501E7D808@BY2PRD0512MB653.n amprd05.prod.outlook.com> References: <6.2.5.6.2.20130201161811.0b38bb90@elandnews.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E7D808@BY2PRD0512MB653.namprd05.prod.outlook.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-gp-obsolete-icmp-types-iana.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-gp-obsolete-icmp-types-iana-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, 03 Feb 2013 23:34:29 -0000 Hi Ron, At 12:29 03-02-2013, Ronald Bonica wrote: >That's a really good question! I wish I knew the answer! It can be argued both ways. >So long as we deprecate the registry items, I am happy with whatever >label people want to put on the document. That's how I read the draft. If the "updates" turns into an issue the authors could add a "receivers must discard" in the draft. The correct fix is more work. Regards, S. Moonesamy From rbonica@juniper.net Sun Feb 3 17:30:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67C221F873C; Sun, 3 Feb 2013 17:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.271 X-Spam-Level: X-Spam-Status: No, score=-102.271 tagged_above=-999 required=5 tests=[AWL=-0.804, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+wGt8XbFGDO; Sun, 3 Feb 2013 17:30:44 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 2634C21F8903; Sun, 3 Feb 2013 17:30:44 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUQ8PQwECzBPFDwQJE+BcKYwTbwC+wGRD@postini.com; Sun, 03 Feb 2013 17:30:44 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 3 Feb 2013 17:30:43 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Sun, 3 Feb 2013 17:30:43 -0800 Received: from CH1EHSOBE020.bigfish.com (216.32.181.182) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 3 Feb 2013 17:32:47 -0800 Received: from mail57-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id 14.1.225.23; Mon, 4 Feb 2013 01:30:41 +0000 Received: from mail57-ch1 (localhost [127.0.0.1]) by mail57-ch1-R.bigfish.com (Postfix) with ESMTP id AE110E01C6; Mon, 4 Feb 2013 01:30:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -25 X-BigFish: PS-25(zz98dI9371I936eI542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h1155h) Received: from mail57-ch1 (localhost.localdomain [127.0.0.1]) by mail57-ch1 (MessageSwitch) id 1359941439470032_24660; Mon, 4 Feb 2013 01:30:39 +0000 (UTC) Received: from CH1EHSMHS006.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail57-ch1.bigfish.com (Postfix) with ESMTP id 662672C005E; Mon, 4 Feb 2013 01:30:39 +0000 (UTC) Received: from BY2PRD0512HT001.namprd05.prod.outlook.com (157.56.238.5) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 4 Feb 2013 01:30:39 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.250]) by BY2PRD0512HT001.namprd05.prod.outlook.com ([10.255.243.34]) with mapi id 14.16.0263.000; Mon, 4 Feb 2013 01:30:38 +0000 From: Ronald Bonica To: S Moonesamy Thread-Topic: APPSDIR review of draft-gp-obsolete-icmp-types-iana-01 Thread-Index: AQHOAONfcAZ8wzRYM0eJAPpAO+kgIphol7OQgAA0k0aAAB+/QA== Date: Mon, 4 Feb 2013 01:30:37 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2501E7DBE3@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <6.2.5.6.2.20130201161811.0b38bb90@elandnews.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E7D808@BY2PRD0512MB653.namprd05.prod.outlook.com> <6.2.5.6.2.20130203143036.0959c2d0@elandnews.com> In-Reply-To: <6.2.5.6.2.20130203143036.0959c2d0@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ELANDSYS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "draft-gp-obsolete-icmp-types-iana.all@tools.ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-gp-obsolete-icmp-types-iana-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, 04 Feb 2013 01:30:44 -0000 SM, Is it really worth splitting hairs over the label? Given Joel's comment abo= ut Standards Track updating Standards Track, we might as will leave it as i= t is. Ron > -----Original Message----- > From: S Moonesamy [mailto:sm+ietf@elandsys.com] > Sent: Sunday, February 03, 2013 6:17 PM > To: Ronald Bonica > Cc: iesg@ietf.org; draft-gp-obsolete-icmp-types- > iana.all@tools.ietf.org; apps-discuss@ietf.org > Subject: RE: APPSDIR review of draft-gp-obsolete-icmp-types-iana-01 >=20 > Hi Ron, > At 12:29 03-02-2013, Ronald Bonica wrote: > >That's a really good question! I wish I knew the answer! >=20 > It can be argued both ways. >=20 > >So long as we deprecate the registry items, I am happy with whatever > >label people want to put on the document. >=20 > That's how I read the draft. If the "updates" turns into an issue the > authors could add a "receivers must discard" in the draft. The correct > fix is more work. >=20 > Regards, > S. Moonesamy >=20 >=20 From sm@elandsys.com Sun Feb 3 22:41:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C180E21F88EE; Sun, 3 Feb 2013 22:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 o8tL73hQ8kIK; Sun, 3 Feb 2013 22:41:42 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D3221F842B; Sun, 3 Feb 2013 22:41:41 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.148.187]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r146fQN7029610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Feb 2013 22:41:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359960099; bh=VxzhT72QLK64/6jZACHM3kK+A7J7DQ8Wdp0+HSEIl8w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sUH7WHXteDE0tJauwKg2f2vYGSFYQ2ej2T090SLCMH155W2kqRYq3xfm2YLPggXtj k9TMGXIIaRWwmsE1ZSg/PoqvWOodagauG1oL/oZGoccY/tlAmpoMoF91BFxwYFcwE6 78RGbUt2A7D5u9M+biYJMjGE8y0JpqCnHmGeOPr8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1359960099; i=@elandsys.com; bh=VxzhT72QLK64/6jZACHM3kK+A7J7DQ8Wdp0+HSEIl8w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JZ8tFIwTof+NqZ3QWupXOaNmq9pCN3/V5iUTFvp2r8kBzAl9GLmI2ehrUeEoeYQAw MktsX9eDKhzMs2DTkzBgFRKxhl4JOy9el8Ok43l61gJxUbyoWubRlFtIm7plndo6u1 CICwIKY9BsvBiCjRopUi2uqThBshbiV58M7+ASI0= Message-Id: <6.2.5.6.2.20130203222946.09d481c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 03 Feb 2013 22:31:07 -0800 To: Ronald Bonica From: S Moonesamy In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501E7DBE3@BY2PRD0512MB653.n amprd05.prod.outlook.com> References: <6.2.5.6.2.20130201161811.0b38bb90@elandnews.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E7D808@BY2PRD0512MB653.namprd05.prod.outlook.com> <6.2.5.6.2.20130203143036.0959c2d0@elandnews.com> <2CF4CB03E2AA464BA0982EC92A02CE2501E7DBE3@BY2PRD0512MB653.namprd05.prod.outlook.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-gp-obsolete-icmp-types-iana.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-gp-obsolete-icmp-types-iana-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, 04 Feb 2013 06:41:43 -0000 Hi Ron, At 17:30 03-02-2013, Ronald Bonica wrote: >Is it really worth splitting hairs over the label? Given Joel's >comment about Standards No. :-) Regards, S. Moonesamy From cpignata@cisco.com Sun Feb 3 17:11:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A06D21F883E; Sun, 3 Feb 2013 17:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vd8KOynZ29ML; Sun, 3 Feb 2013 17:11:11 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C4D1D1F0C4A; Sun, 3 Feb 2013 17:11:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=822; q=dns/txt; s=iport; t=1359940272; x=1361149872; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ev9cxPWvq++q9o8kr88yECy9SXHS/wzHoBS1PQBTgK4=; b=X4GJuft/IBRjJAsTCCdpHALmAcgPnkXWyZEq0Hr2UiYYBiWDw6LIIEY9 CV/1dY/HkFk7V3Bq6eYqlDQL1ucKXoq81u6CJx+/9CWz0uiZKXAGFKydn YExVvsD30Aaz9Rhk3s17vnya8hCWLX30l0ybv9FLxjauX5/wNUoqe95qG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAGIJD1GtJV2Y/2dsb2JhbABEhgG5NBZzgh8BAQEDATo/BQsCAQgYHhAyJQIEDgWICwa+fJBxYQOWH5BRgnw X-IronPort-AV: E=Sophos;i="4.84,596,1355097600"; d="scan'208";a="172654174" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 04 Feb 2013 01:11:11 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r141BBQC031495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Feb 2013 01:11:11 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Sun, 3 Feb 2013 19:11:11 -0600 From: "Carlos Pignataro (cpignata)" To: S Moonesamy Thread-Topic: APPSDIR review of draft-gp-obsolete-icmp-types-iana-01 Thread-Index: AQHOAOQZmAQY5vD710O2P7rITMZxWZhmK6IAgABEIYCAAnd9jg== Date: Mon, 4 Feb 2013 01:10:25 +0000 Message-ID: <8A10209D-287A-49B3-A203-9D0351205F9B@cisco.com> References: <6.2.5.6.2.20130201172039.0a74d408@elandsys.com> <510C6B6C.2020904@joelhalpern.com>, <6.2.5.6.2.20130201211516.08dfcea8@elandnews.com> In-Reply-To: <6.2.5.6.2.20130201211516.08dfcea8@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 04 Feb 2013 09:20:06 -0800 Cc: Fernando Gont , "Joel M. Halpern" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-gp-obsolete-icmp-types-iana-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, 04 Feb 2013 01:11:18 -0000 Hi, Please see inline.=20 Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Feb 2, 2013, at 12:50 AM, "S Moonesamy" wrote: > Hi Joel, > At 17:27 01-02-2013, Joel M. Halpern wrote: >> It is standards track because of its interaction with other standards tr= ack documents. >=20 In addition, also for its interaction with an IANA registry with Standards = Action registration procedures.=20 We could have gone with BCP, but seems PS makes sense.=20 > Thanks for the quick response. I consider the review as being addressed. >=20 Thanks for the review.=20 Carlos.=20 > I'll leave it to the Application Area ADs to figure out whether the docum= ent should be published as Informational or Proposed Standard. :-) >=20 > Regards, > S. Moonesamy=20 From tuexen@fh-muenster.de Sun Feb 3 14:06:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F89021F88E1; Sun, 3 Feb 2013 14:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9GFSJSdyp8H; Sun, 3 Feb 2013 14:06:21 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFFC21F89D5; Sun, 3 Feb 2013 14:06:19 -0800 (PST) Received: from [192.168.1.101] (p508FAAD0.dip.t-dialin.net [80.143.170.208]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4E2901C0C069A; Sun, 3 Feb 2013 23:06:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: <510E7EFD.8060109@bbiw.net> Date: Sun, 3 Feb 2013 23:06:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3D060FD1-45AB-4028-A54D-E550EC1F14C8@fh-muenster.de> References: <510D61AB.5040704@dcrocker.net> <510E7EFD.8060109@bbiw.net> To: Dave Crocker X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Mon, 04 Feb 2013 09:20:16 -0800 Cc: draft-ietf-tsvwg-sctp-udp-encaps.all@tools.ietf.org, iesg , Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-tsvwg-sctp-udp-encaps X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Feb 2013 22:06:22 -0000 On Feb 3, 2013, at 4:15 PM, Dave Crocker wrote: > Michael, >=20 > Thanks for the speedy response. More comments inline. >=20 > We probably don't need to iterate further. As I said in the review, = the doc is workable as is; I'm only suggesting changes that seem to me = will improve clarity a bit. OK, let me go through your comments and let you know what I take... Best regards Michael >=20 > d/ >=20 > On 2/3/2013 5:42 AM, Michael Tuexen wrote: >> On Feb 2, 2013, at 7:57 PM, Dave Crocker wrote: >>>> 3.1. Portable SCTP Implementations >>> ... >>>> A crucial point for implementing SCTP in user space is = controlling >>>> the source address of outgoing packets. This is not an issue = when >>>> using all available addresses. However, this is not the case = when >>>=20 >>> What is meant by "using all available addresses"? > > >> If the SCTP endpoint can use all addresses configured at the IP = layer. > > >> In socket terms: You bound the socket to the wildcard address = (0.0.0.0 or ::0). >=20 >=20 > I guess I suggest adding this bit of clarification, although it might = help to change 'use' to something more specific, possibly like: >=20 > This is not an issue when the SCTP implementation is able to bind = to any possible address configured at the IP layer. >=20 > I'm not sure I'm interpreting the details correctly; if not, just use = my text as an exemplar for the type of clarification I'm suggesting. I think This is not an issue if the SCTP stack can use all addresses configured at the IP-layer as source addresses. makes it clearer. >=20 > (In case it isn't obvious, I tend to do review-oriented reading with = any eye towards /mis/interpretation by a less-expert reader...) >=20 >=20 >>>> chunks. To use multiple addresses, the dynamic address >>>> reconfiguration extension described in [RFC5061] MUST be used = with >>>> wildcard addresses in combination with [RFC4895]. >>>=20 >>> wildcard addresses -> wildcard source addresses (?) > > >> No. The addresses used in the ASCONF/ASCONF-ACK chunks described in = RFC 5061 >> are wildcard addresses. >=20 > Ok. Then perhaps: >=20 > MUST be used with wildcard addressed used in the ASCONF/ASCONF-ACK = chunks described in RFC 5061, in combination with [RFC4895]. The next rev will contain: To use multiple addresses, the dynamic address reconfiguration extension described in MUST be used only with wildcard = addresses in the ASCONF chunks in combination with . >=20 >=20 >>>> 4. SCTP over UDP >>>>=20 >>>> 4.1. Architectural Considerations >>>>=20 >>>> An SCTP implementation supporting UDP encapsulation MUST store a >>>> remote UDP encapsulation port number per destination address for = each >>>> SCTP association. >>>=20 >>> Must store it /where/? > > >> I think different SCTP implementation will have different data = structures for >> variable which are per remote address. > > >>>> Or perhaps this isn't really a normative specification statement = but rather an architectural discussion that provides a basis for the = later specification details? If so, remove the normative language here. > > >> It is important that this port number is a variable per destination = address >> for each SCTP association, not just one per association or so. >> It make clear how to store the variable. Later in the text it is only = described how >> you modify and use the variable. So do you want me to change the MUST = to a must? >=20 > OK. Then I suggest moving this away from using normative language, = since the issue is higher-level, rather than specific. Something along = the lines of: >=20 > UDP encapsulation for SCTP permits use of different UDP port = numbers. Consequently, an implementation's maintenance of tunneling = state information requires retention of the port number used by the = remote side of the tunneling exchange. This would replace a (for me) clear statement with one from which I = don't get what I wanted to say. So I prefer to keep the text as it is. >=20 >=20 >>>> 4.3. Encapsulation Procedure >>> ... >>>> For IPv4, the UDP checksum SHOULD be computed and the SCTP = checksum >>>> MUST be computed, whereas for IPv6, the UDP checksum and the SCTP >>>> checksum MUST be computed. >>>=20 >>>> Given the protections provided by the SCTP checksum, why is a UDP = checksum needed? (Note the logic of dropping checksum from IPv6...) >=20 >> We don't need any kind of error protection, just being able to = interop. >> When requiring to disable the UDP checksum for IPv4, at least on = FreeBSD, >> this is a host wide configuration option. For IPv6 it will delay each >> connection setup in case not all nodes involved support disabled >> checksums. On FreeBSD at least, disabling UDP checksum for IPv6 is >> not supported currently. So you would have the penalty always. >=20 > The problem with the current language is that it doesn't provide a = context for the SHOULD. I'm not sure what language to suggest to = clarify this. Something like "SHOULD support UDP checksum to the extent = needed for interoperability" seems poor... Since this issue is still discussed with Stewart, let's wait for the = outcome of that discussion. >=20 >=20 >>>> 4.4. Decapsulation Procedure >>>>=20 >>>> When an encapsulated packet is received, the UDP header is = removed. >>>> Then a lookup is performed to find the association for the = received >>>=20 >>> Where is the lookup algorithm specified? In particular, what = information is used to perform the lookup. > > >> This is the generic lookup each SCTP stack perform when a packet is = received. >> Conceptually, you take the source and destination address and port = number to >> find the association and path and then verify the v-tag. >=20 > Ah. The current text looked like it was specifying something new. So = I'll suggest: >=20 > Then the generic lookup is performed, as done by a SCTP stack when a = packet is received. Next rev will contain: Then the generic lookup is performed, as done by an SCTP stack whenever a packet is received, to find the association for the received SCTP packet. >=20 >=20 >>>> SCTP packet. After finding the SCTP association (which includes >>>> checking the verification tag), the UDP source port MUST be = stored as >>>> the encapsulation port for the destination address the SCTP = packet is >>>> received from (see Section 4.1). >>>>=20 >>>> Please note that when a non-encapsulated SCTP packet is received, = the >>>> encapsulation of outgoing packets belonging to the same = association >>>> and the corresponding destination address MUST be disabled. >>>=20 >>>> "Please note" is appropriate for a comment, not a strongly = normative statement. That is, I think it undermines the reader's = understanding that this is a normative requirement. >=20 >> This comment was already raised. The text has been changed (for the = next revision) to >> When a non-encapsulated SCTP packet is received by the >> SCTP stack, the encapsulation of outgoing packets belonging >> to the same association and the corresponding destination >> address MUST be disabled. >=20 > wfm. >=20 >=20 >>>=20 >>>=20 >>>=20 >>>> 4.6. Path MTU Considerations >>>>=20 >>>> If an SCTP endpoint starts to encapsulate the packets of a path, = it >>>> MUST decrease the Path MTU of that path by the size of the UDP >>>> header. If it stops encapsulating them, the Path MTU SHOULD be >>>> increased by the size of the UDP header. >>>=20 >>>> How can a user-level SCTP control Path MTU, particularly when it's = access to the IP layer (and presumably ICMP) is limited? >=20 >> Some operating systems allow an application to set the DF bit. That = is all you need. >> Implementing PathMTU discovery should not rely on ICMP or ICMv6. SCTP = can send >> probe packets consisting of HEARTBEAT and PADDING chunks. If no = corresponding >> HEARTBEAT-ACK is received, the probe packet was lost. >>>=20 >>> Perhaps you mean "adjust SCTP's use of the provided Path MTU"? That = is, provide a calculation on top of what the infrastucture says is = available? > > >> It depends if the infrastructure can provide it. SCTP does provide = this functionality. >=20 > Well, I'm not sure what to suggest. I think the current language = implicitly encourages the kind of confusion I experienced. But the = topic isn't straightforward. >=20 > I think of Path MTU as a mechanism that is independent of other = services, such as transport, and that those other services are clients = of the Path MTU value. That's why I suggested casting this as = "modifying what is produced". >=20 > Mumble. Sorry I can't offer something more coherent. For me path MTU discovery is a function provided by the transport = layer... >=20 >=20 >>>> 4.7. Handling of Embedded IP-addresses >>>>=20 >>>> When using UDP encapsulation for legacy NAT traversal, IP = addresses >>>> that might require translation MUST NOT be put into any SCTP = packet. >>>>=20 >>>> This means that a multi homed SCTP association is setup initially = as >>>> a singled homed one and the protocol extension [RFC5061] in >>>> combination with [RFC4895] is used to add the other addresses. = Only >>>> wildcard addresses are put into the SCTP packet. >>>=20 >>> This is the second reference to the use of wildcard for this. Since = inclusion > >> of actual addresses is needed for correlation/rendezvous functions, = it would > >> help to have a pointer or discussion about how the = correlation/rendezvous is > >> done when wildcarding is done. RFC 5061 describes that the source address of the packet is used if a wildcard address is provided in the ASCONF chunk. > > >> No, RFC 4895 provides a security mechanism required by RFC 5061. RFC = 5061 >> requires the use of RFC 4895. >> Using wildcard addresses avoids embedding IP addresses in the SCTP = packet. >> When using wildcard addresses you are referring to the source address >> of the SCTP packet. >=20 > The current language seems to mix references to the two sides of the = exchange; use of the passive tense, with "are put", further obscures = which side does what. >=20 >=20 >>>> 5. Socket API Considerations >>>>=20 >>>> This section describes how the socket API defined in [RFC6458] is >>>=20 >>> since the section is informational, rather than normative, I = suggest: >>>=20 >>> is -> can be >> Changed. However, in RFC 6525 we used "needs to be extended". Would = that >> be acceptable to you? >=20 > wfm. >=20 >=20 >>>=20 >>>> extended to provide a way for the application to control the UDP >>>> encapsulation. >>>=20 >>>=20 >>>=20 >>>> 7. Security Considerations >>>>=20 >>>> Encapsulating SCTP into UDP does not add any additional security >>>> considerations to the ones given in [RFC4960] and [RFC5061]. >>>>=20 >>>> Firewalls inspecting SCTP packets must also be aware of the >>>> encapsulation and apply corresponding rules to the encapsulated >>>> packets. >>>=20 >>> "must"? normative? >> The sentence as above was suggested the the sec review. >>>=20 >>> The problem with this, whether normative or not, is that the purpose = of this encapsulation is to transit intermediaries that don't support = SCTP. That's a conflicting goal and probably is worth noting. >> As stated above, this sentence was suggested by the sec review. >> I don't agree that it is a necessarily a contradiction. Since the >> firewall supports SCTP (it can inspect them), you wouldn't use UDP >> to get through it. >=20 > I understand the security orientation that produced the text. But as = you note, if the firewall is SCTP aware, then you probably won't be = using UDP to transit the firewall. That makes the document irrelevant = to the case this text covers... >=20 > (I'm counting NAT and Firewall as likely to be the same box.) I'm not... I think the sec review wanted to make sure that an attacker = does not circumvent the SCTP rules by encapsulating the packets in UDP. This is = what the text makes sure. >=20 > I think the security considerations concern is better served by simply = noting that UDP encapsulation can serve to hide the use of SCTP from = firewalls along the path, if the firewall is not SCTP aware. A = statement like this highlights the issue but does not attempt to dictate = how to deal with it. I don't this that this is the intention of the text. So I leave it as it = is. >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 From jasnell@gmail.com Mon Feb 4 15:57:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512ED21F8536 for ; Mon, 4 Feb 2013 15:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4wFIutabjRb for ; Mon, 4 Feb 2013 15:57:18 -0800 (PST) Received: from mail-ie0-x233.google.com (ie-in-x0233.1e100.net [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id DB9CE21F848B for ; Mon, 4 Feb 2013 15:57:17 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k11so5245707iea.38 for ; Mon, 04 Feb 2013 15:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=tYpuGwENNShNHYxRfUT8kPDpd9/EhsRxl3faWDWE/vM=; b=N+f5/96+zTOKJjClerd8+5bYrhy+8ELLXQUi4dB8UiA5dW1mn0IShpszKCfKV5M3Jn HQrJyrqLBLfCJfO/rE0VisGlJH/rhgJcNNIttxRW53dmSMgBXU7PGxuo8xhT/Tezmrpw mdRayebDhrjPqzHSi+V+aoaOxP+VqZpgzp7C2aeDwc9B3o/02KgZIgl6qMRMXRXAwLtU ZbvsNDjLn5Y1r/aYkf8a/jEgwYNyfgsWMM1ZP5iCv+JkW1eGyQEXdjRDe0jCeDodI4Yv AIOiZ6oKgqhuAV5f/7nwqEXmsUjiVEOaDjC/ODz9AOSqYV/kaAVkpOuOa/VPbOO4P9G3 k1Tg== MIME-Version: 1.0 X-Received: by 10.50.196.227 with SMTP id ip3mr9563046igc.97.1360022237445; Mon, 04 Feb 2013 15:57:17 -0800 (PST) Received: by 10.64.53.237 with HTTP; Mon, 4 Feb 2013 15:57:17 -0800 (PST) Received: by 10.64.53.237 with HTTP; Mon, 4 Feb 2013 15:57:17 -0800 (PST) In-Reply-To: <20130204232943.26736.90750.idtracker@ietfa.amsl.com> References: <20130204232943.26736.90750.idtracker@ietfa.amsl.com> Date: Mon, 4 Feb 2013 15:57:17 -0800 Message-ID: From: James M Snell To: Apps Discuss Content-Type: multipart/alternative; boundary=14dae934117b597ec404d4eeda90 Subject: [apps-discuss] Fwd: State changed for draft draft-snell-additional-link-relations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Feb 2013 23:57:18 -0000 --14dae934117b597ec404d4eeda90 Content-Type: text/plain; charset=UTF-8 FYI... ---------- Forwarded message ---------- From: "IETF Secretariat" Date: Feb 4, 2013 3:29 PM Subject: State changed for draft draft-snell-additional-link-relations To: "James Snell" Cc: The state of document draft-snell-additional-link-relations has been updated. See more information below. Previous state: Response to Review Needed Current state: Sent to the RFC Editor Transition date: 2013-02-04 15:29 Author of the change: Nevil Brownlee Comment: --14dae934117b597ec404d4eeda90 Content-Type: text/html; charset=UTF-8

FYI...

---------- Forwarded message ----------
From: "IETF Secretariat" <ietf-secretariat-reply@ietf.org>
Date: Feb 4, 2013 3:29 PM
Subject: State changed for draft draft-snell-additional-link-relations
To: "James Snell" <jasnell@gmail.com>
Cc:


The state of document draft-snell-additional-link-relations has been updated. See more information below.

Previous state: Response to Review Needed
Current state: Sent to the RFC Editor
Transition date: 2013-02-04 15:29
Author of the change: Nevil Brownlee

Comment:


--14dae934117b597ec404d4eeda90-- From mnot@mnot.net Mon Feb 4 16:54:31 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0ED21F8AB0 for ; Mon, 4 Feb 2013 16:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.006 X-Spam-Level: X-Spam-Status: No, score=-106.006 tagged_above=-999 required=5 tests=[AWL=-3.407, 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 ZADSFj0rc5wC for ; Mon, 4 Feb 2013 16:54:30 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8D11221F8A8F for ; Mon, 4 Feb 2013 16:54:30 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.138.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 770CA22E253; Mon, 4 Feb 2013 19:54:23 -0500 (EST) 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: Tue, 5 Feb 2013 11:54:22 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Francis Galiegue X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Announce: JSON Schema, I-D version 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Feb 2013 00:54:31 -0000 FWIW, since people are talking about it: I'm about +0.25 on doing this. On the one hand, XML Schema has created a lot of damage (the more so = because many many people still don't understand how harmful it is / can = be). On the other hand, this is not XML Schema. AFAICT it does not try to do = nearly as much as XML Schema did. As has been discussed ad nauseum, the = major use cases for a schema language are doing QA and documentation, = and JSON could use help on both fronts. So, if it were possible to get enough review / input to assure that it = didn't create any of the same problems (in particular, I want to look at = how it supports / fails to support format evolution), it'd probably do = some amount of good without too much risk. However, we'd have to do that = without killing the community around it (i.e., the architects among us = would need to restrain themselves). Just my .02. Cheers, On 02/02/2013, at 2:59 AM, Francis Galiegue wrote: > Hello, >=20 > JSON Schema is now up to version 4. >=20 > Links to the specifications: >=20 > * http://tools.ietf.org/html/draft-zyp-json-schema-04 (core = specification), > * http://tools.ietf.org/html/draft-fge-json-schema-validation-00 > (validation specification), > * http://tools.ietf.org/html/draft-luff-json-hyper-schema-00 > (hyperschema specification). >=20 > It is dependent on two other I-Ds: >=20 > * JSON Reference, > * JSON Pointer (as a consequence of the first). >=20 > Reviews appreciated. For the recall, JSON Schema has its Google group: > json-schema@googlegroups.com >=20 > All the best, > -- > Francis Galiegue, fgaliegue@gmail.com > Try out your JSON Schemas: http://json-schema-validator.herokuapp.com > _______________________________________________ > 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 Mon Feb 4 16:55:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B1621F8B33 for ; Mon, 4 Feb 2013 16:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.851 X-Spam-Level: X-Spam-Status: No, score=-105.851 tagged_above=-999 required=5 tests=[AWL=-3.252, 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 ueCYFy6Ey8Ag for ; Mon, 4 Feb 2013 16:55:02 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 868AD21F8B2E for ; Mon, 4 Feb 2013 16:55:02 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.138.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5A1D522E256; Mon, 4 Feb 2013 19:55:01 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <1E979FC1-5345-4D1E-8CF1-13A6F69D62BB@me.com> Date: Tue, 5 Feb 2013 11:55:02 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <5F783D6E-CB77-4A52-93F8-F0B4F6FD2AD9@mnot.net> References: <1E979FC1-5345-4D1E-8CF1-13A6F69D62BB@me.com> To: algermissen1971 X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] application/json-home X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Feb 2013 00:55:03 -0000 On 02/02/2013, at 5:50 PM, algermissen1971 = wrote: > Hi Mark, >=20 > what do you think about renaming application/json-home[1] to = application/home+json? >=20 > I used to dislike +xxx ... but actually, I can see some use in = intermediaries and hence changed my mind. I cannot bring myself to like it, but I may do it. Cheers, -- Mark Nottingham http://www.mnot.net/ From stpeter@stpeter.im Mon Feb 4 19:27:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADDC21F8A47 for ; Mon, 4 Feb 2013 19:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylV2rIsqC3Sw for ; Mon, 4 Feb 2013 19:27:01 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C4DEE21F8941 for ; Mon, 4 Feb 2013 19:27:01 -0800 (PST) Received: from [192.168.1.5] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5B6D9406D9; Mon, 4 Feb 2013 20:33:38 -0700 (MST) Message-ID: <51103E2B.1080707@stpeter.im> Date: Mon, 04 Feb 2013 16:03:07 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: James M Snell References: <5106BFDC.2030706@ericsson.com> <5106C090.8080403@ericsson.com> <039e01cdfe9a$58f17410$0ad45c30$@packetizer.com> <5108DCA7.5090606@ericsson.com> <4E1F6AAD24975D4BA5B1680429673943673E68F1@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 03:27:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/30/13 10:33 AM, James M Snell wrote: > First off, The ? syntax is already well established practice for > many URI structures, particularly http and mailto, it makes a lot > of sense to reuse that, particularly since many existing URI > parsers will give you support for for free. > > Second, the most I am suggesting for acct uri is the allowance of > optional query parameters. I am not suggesting, right now, that we > ought to change the semantics of WebFinger's resolution... but I do > want to leave the door open for alternative resolution mechanisms > later. I used the ?provider=bar.com as an example > of the basic motivation for the parameters, but there very well > could be other interesting parameters that are worth considering. > > Hypothetically, for instance, in the future we could have something > like: > > Find my > blog! Isn't my blog a lot easier? Why the level of indirection if all you really want to do is link to the blog? > Allowing for optional query parameters gives us more flexibility > long term without introducing significant new complexity now. Flexibility is not necessarily a good thing. The whole idea behind the 'acct' URI scheme (as I understood it) was to provide a mere identifier of an account, not flexible ways of interacting with that account. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEQPisACgkQNL8k5A2w/vyKbwCgpEN2/2hyfzIT/otji3N0SJ2k rs0Anj53QFPG9lZbTEj8+Q0mSimlezfV =1c7Z -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Feb 4 19:27:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5038021F8A48 for ; Mon, 4 Feb 2013 19:27:02 -0800 (PST) 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.016, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqobteVRIxkN for ; Mon, 4 Feb 2013 19:27:01 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 493F121F88F7 for ; Mon, 4 Feb 2013 19:27:00 -0800 (PST) Received: from [192.168.1.5] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E9D8440A5E; Mon, 4 Feb 2013 20:33:36 -0700 (MST) Message-ID: <51103CA0.1080609@stpeter.im> Date: Mon, 04 Feb 2013 15:56:32 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: James M Snell References: <5106BFDC.2030706@ericsson.com> <5106C090.8080403@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] delegation of acct URIs (was: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 03:27:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [ changing both message subject and discssion venue ] On 1/29/13 11:03 AM, James M Snell wrote: > I'm really just now starting to turn my attention to the acct uri > aspect of the WebFinger discussion.. generally speaking I'm +1 on > the current draft. When going through various implementation > scenarios, however, one thought did strike me, although it may be a > bit too late in the game to put this on the table at all. I > apologize for making this late suggestion... > > In some scenarios, such as hosted cloud application environments, > a service provider may wish to host the information about a given > user within a different domain. For instance, suppose Company > Foo.com utilizes services from ISV Bar.com. The user accounts, > however, are drawn from Foo.com, but Bar.com is the provider that > actually hosts the profiles and account information. What I want is > something that identifies the user account AND the service > provider. > > Example: > > acct:john.doe@foo.com?provider=bar.com > > > In a WebFinger type of scenario, resolving this would involve > something like... > > GET /.well-known/webfinger?resource=john.doe@foo.com > Host: bar.com > > Encoding the third party provider into the URL in this way provides > a fairly flexible way of enabling the third party support without > complicated redirects from foo.com to bar.com > . It also gives domains a way of enabling bits of > information to be shared from multiple sources... > acct:john.doe@foo.com?provider=isv1.com > vs. > acct:john.doe@foo.com?provider=isv2.com > > > To enable this kind of thing, it would be helpful if the basic acct > URI syntax allowed for optional parameters like the mailto URI > scheme does (RFC2368). The specific parameters themselves can be > figured out later... Um, isn't that what SRV records are for? Oh, yeah, I forgot, there's no SRV for HTTP. ;-) There are all sorts of security issues with this kind of delegation. In XMPP we have delegation via SRV and it's only recently (with the promise of wider availability for DNSSEC) that we've started to describe best practices for secure delegation. With regard to WebFinger and 'acct' URIs, first of all we're discouraging people from doing things like this: more about John However, people keep assuming they can do that kind of thing, so I really do need to add some strong language to the spec discouraging it, eh? Second, unless such a link (with your suggested "?provider=bar.com" query) is served over HTTPS, the delegation can't be secure. Third, you'd need to ensure that the domainpart of the 'acct' URI matched the domain to which you sent the HTTP request that resulted in the return of an HTML page (say) containing said hyperlink. Fourth, even a match there might not indicate that the author of the HTML page (say) is authorized to say that requests for information about john.doe@foo.com can legitimately be served by bar.com. IMHO this kind of delegation needs to happen at the DNS layer with DNSSEC to be anything close to secure. However, you *might* be able to do something slightly more secure than query parameters on the 'acct' URI using an approach similar to the "PKIX Over Secure HTTP" proposal that Matt Miller and I have been working on for XMPP: http://tools.ietf.org/id/draft-miller-xmpp-posh-prooftype-01.txt In any case, I think this is way beyond the scope of the 'acct' URI scheme and needs to be pursued in other ways. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEQPKAACgkQNL8k5A2w/vxwsgCdEkiU7jiI+2guubPeh6nPOOrC ziIAn0dcRD0dCgspsfEELREbqUUGoi8q =udaO -----END PGP SIGNATURE----- From jasnell@gmail.com Mon Feb 4 19:39:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CA921F87B2 for ; Mon, 4 Feb 2013 19:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRkvg5I1wAw5 for ; Mon, 4 Feb 2013 19:39:39 -0800 (PST) Received: from mail-ie0-x232.google.com (ie-in-x0232.1e100.net [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id A260821F8682 for ; Mon, 4 Feb 2013 19:39:39 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id c13so6857121ieb.9 for ; Mon, 04 Feb 2013 19:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=i3maFM7WbYtOZlBGNscbk1Uqi1yhjZ02Vqlp/1Snluw=; b=SDEVaTmTG5U1GknXxX/N8rELXG/mMtURPt3fNi+RN7ktXzvXB/EmBmJhqy1k1sqW1R Sm2DBj/iEHBBM354nilXgp06o+NlEjo35kVbfOUeLdG1HKB3EfF1AAlUo2yIWc+zmCv5 ohHpdA3yTmXX6Mgm+SGhlaBboN6B871ByxW2PJQ5X/VO+tbgIOyOiLK15RKAYkjr3tp7 knlEvVv1qrqNUfy00ava6NgvF1H9kzJQw3u1PWtVUELX+AhGmvQfRqaZvUdjvZos+LHg Qi2Uhg8bzv5dUoOclU9f6G2t35jEzHBZUDQO5T914zH17ALYq6XDvdD65yC/xiGyvpLn KDmw== X-Received: by 10.50.76.168 with SMTP id l8mr10485192igw.97.1360035579056; Mon, 04 Feb 2013 19:39:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.53.237 with HTTP; Mon, 4 Feb 2013 19:39:18 -0800 (PST) In-Reply-To: <51103CA0.1080609@stpeter.im> References: <5106BFDC.2030706@ericsson.com> <5106C090.8080403@ericsson.com> <51103CA0.1080609@stpeter.im> From: James M Snell Date: Mon, 4 Feb 2013 19:39:18 -0800 Message-ID: To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=e89a8f3bae0f9253c304d4f1f568 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] delegation of acct URIs (was: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 03:39:41 -0000 --e89a8f3bae0f9253c304d4f1f568 Content-Type: text/plain; charset=UTF-8 Certainly not going to argue any of those points... the only thing I will say is that, for now, all I'm advocating is that the acct URI ought to allow for optional query parameters... without defining exactly what those parameters are or what the relevant concerns are about their specific use. - James On Mon, Feb 4, 2013 at 2:56 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > [ changing both message subject and discssion venue ] > > On 1/29/13 11:03 AM, James M Snell wrote: > > I'm really just now starting to turn my attention to the acct uri > > aspect of the WebFinger discussion.. generally speaking I'm +1 on > > the current draft. When going through various implementation > > scenarios, however, one thought did strike me, although it may be a > > bit too late in the game to put this on the table at all. I > > apologize for making this late suggestion... > > > > In some scenarios, such as hosted cloud application environments, > > a service provider may wish to host the information about a given > > user within a different domain. For instance, suppose Company > > Foo.com utilizes services from ISV Bar.com. The user accounts, > > however, are drawn from Foo.com, but Bar.com is the provider that > > actually hosts the profiles and account information. What I want is > > something that identifies the user account AND the service > > provider. > > > > Example: > > > > acct:john.doe@foo.com?provider=bar.com > > > > > > In a WebFinger type of scenario, resolving this would involve > > something like... > > > > GET /.well-known/webfinger?resource=john.doe@foo.com > > Host: bar.com > > > > Encoding the third party provider into the URL in this way provides > > a fairly flexible way of enabling the third party support without > > complicated redirects from foo.com to bar.com > > . It also gives domains a way of enabling bits of > > information to be shared from multiple sources... > > acct:john.doe@foo.com?provider=isv1.com > > vs. > > acct:john.doe@foo.com?provider=isv2.com > > > > > > To enable this kind of thing, it would be helpful if the basic acct > > URI syntax allowed for optional parameters like the mailto URI > > scheme does (RFC2368). The specific parameters themselves can be > > figured out later... > > > Um, isn't that what SRV records are for? Oh, yeah, I forgot, there's > no SRV for HTTP. ;-) > > > There are all sorts of security issues with this kind of delegation. > In XMPP we have delegation via SRV and it's only recently (with the > promise of wider availability for DNSSEC) that we've started to > describe best practices for secure delegation. > > With regard to WebFinger and 'acct' URIs, first of all we're > discouraging people from doing things like this: > > more about John > > However, people keep assuming they can do that kind of thing, so I > really do need to add some strong language to the spec discouraging > it, eh? > > Second, unless such a link (with your suggested "?provider=bar.com" > query) is served over HTTPS, the delegation can't be secure. > > Third, you'd need to ensure that the domainpart of the 'acct' URI > matched the domain to which you sent the HTTP request that resulted in > the return of an HTML page (say) containing said hyperlink. > > Fourth, even a match there might not indicate that the author of the > HTML page (say) is authorized to say that requests for information > about john.doe@foo.com can legitimately be served by bar.com. > > IMHO this kind of delegation needs to happen at the DNS layer with > DNSSEC to be anything close to secure. However, you *might* be able to > do something slightly more secure than query parameters on the 'acct' > URI using an approach similar to the "PKIX Over Secure HTTP" proposal > that Matt Miller and I have been working on for XMPP: > > http://tools.ietf.org/id/draft-miller-xmpp-posh-prooftype-01.txt > > In any case, I think this is way beyond the scope of the 'acct' URI > scheme and needs to be pursued in other ways. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlEQPKAACgkQNL8k5A2w/vxwsgCdEkiU7jiI+2guubPeh6nPOOrC > ziIAn0dcRD0dCgspsfEELREbqUUGoi8q > =udaO > -----END PGP SIGNATURE----- > --e89a8f3bae0f9253c304d4f1f568 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Certainly not going = to argue any of those points... the only thing I will say is that, for now,= all I'm advocating is that the acct URI ought to allow for optional qu= ery parameters... without defining exactly what those parameters are or wha= t the relevant concerns are about their specific use.=C2=A0

- James


On Mon, Feb 4, 2013 at 2:56 PM, P= eter Saint-Andre <stpeter@stpeter.im> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[ changing both message subject and discssion venue ]

On 1/29/13 11:03 AM, James M Snell wrote:
> I'm really just now starting to turn my attention to the acct uri<= br> > aspect of the WebFinger discussion.. generally speaking I'm +1 on<= br> > the current draft. When going through various implementation
> scenarios, however, one thought did strike me, although it may be a > bit too late in the game to put this on the table at all. I
> apologize for making this late suggestion...
>
> In some scenarios, such as hosted cloud application environments,
> a service provider may wish to host the information about a given
> user within a different domain. For instance, suppose Company
> Foo.com utilizes services from ISV Bar.com. The user accounts,
> however, are drawn from Foo.com, but Bar.com is the provider that
> actually hosts the profiles and account information. What I want is > something that identifies the user account AND the service
> provider.
>
> Example:
>
> acct:john.doe@foo.com?provider=3Dbar.com
> <http://acct:john.doe@foo.com?provider=3Dbar.com>
>
> In a WebFinger type of scenario, resolving this would involve
> something like...
>
> GET /.well-known/webfinger?resource=3Djohn.doe@foo.com
> <mailto:john.doe@foo.com>= ; Host: bar.com <http://bar.com>
>
> Encoding the third party provider into the URL in this way provides > a fairly flexible way of enabling the third party support without
> complicated redirects from foo.com <http://foo.c= om> to bar.com
> <http://bar.com>= ;. It also gives domains a way of enabling bits of
> information to be shared from multiple sources...
> acct:john.doe@foo.com?provider=3Disv1.com
> <http://acct:john.doe@foo.com?provider=3Disv1.com> vs. > acct:john.doe@foo.com?provider=3Disv2.com
> <http://acct:john.doe@foo.com?provider=3Disv2.com>
>
> To enable this kind of thing, it would be helpful if the basic acct > URI syntax allowed for optional parameters like the mailto URI
> scheme does (RFC2368). The specific parameters themselves can be
> figured out later...

<snark>
Um, isn't that what SRV records are for? Oh, yeah, I forgot, there'= s
no SRV for HTTP. ;-)
</snark>

There are all sorts of security issues with this kind of delegation.
In XMPP we have delegation via SRV and it's only recently (with the
promise of wider availability for DNSSEC) that we've started to
describe best practices for secure delegation.

With regard to WebFinger and 'acct' URIs, first of all we're discouraging people from doing things like this:

<a href=3D'acct:john.doe@= foo.com'>more about John</a>

However, people keep assuming they can do that kind of thing, so I
really do need to add some strong language to the spec discouraging
it, eh?

Second, unless such a link (with your suggested "?provider=3Dbar.com"
query) is served over HTTPS, the delegation can't be secure.

Third, you'd need to ensure that the domainpart of the 'acct' U= RI
matched the domain to which you sent the HTTP request that resulted in
the return of an HTML page (say) containing said hyperlink.

Fourth, even a match there might not indicate that the author of the
HTML page (say) is authorized to say that requests for information
about john.doe@foo.com can legitima= tely be served by bar.com.=

IMHO this kind of delegation needs to happen at the DNS layer with
DNSSEC to be anything close to secure. However, you *might* be able to
do something slightly more secure than query parameters on the 'acct= 9;
URI using an approach similar to the "PKIX Over Secure HTTP" prop= osal
that Matt Miller and I have been working on for XMPP:

http://tools.ietf.org/id/draft-miller-xmpp-posh-proofty= pe-01.txt

In any case, I think this is way beyond the scope of the 'acct' URI=
scheme and needs to be pursued in other ways.

Peter

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

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

iEYEARECAAYFAlEQPKAACgkQNL8k5A2w/vxwsgCdEkiU7jiI+2guubPeh6nPOOrC
ziIAn0dcRD0dCgspsfEELREbqUUGoi8q
=3DudaO
-----END PGP SIGNATURE-----

--e89a8f3bae0f9253c304d4f1f568-- From mnot@mnot.net Mon Feb 4 22:58:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A315321F898A for ; Mon, 4 Feb 2013 22:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.856 X-Spam-Level: X-Spam-Status: No, score=-105.856 tagged_above=-999 required=5 tests=[AWL=-3.257, 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 GGoKuXVc2hFT for ; Mon, 4 Feb 2013 22:58:00 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4B85B21F8972 for ; Mon, 4 Feb 2013 22:58:00 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.138.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 51AD022E253 for ; Tue, 5 Feb 2013 01:57:53 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 5 Feb 2013 17:58:02 +1100 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] WGLC feedback on webfinger-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 06:58:01 -0000 Had a quick read of this draft. Overall this looks pretty good; the = points I raise are fairly minor. 1) The introduction seems to be missing a vital bit of information: that = the Whole Point -- the Big Trick -- that WebFinger performs is (AIUI) = that you can use an identifier that might not be usable as a locator = (e.g., a mailto: uri, an acct: uri) as a locator. In that sense, it's = really just a more real-world-usable URN lookup facility*. This is really important to include in the abstract as well as the = introduction, because without it, WF just seems like a silly indirection = mechanism on top of HTTP. 2) The examples use unregistered link relations types = ; = specifically, "blog" and "vcard". Naughty. 3) The text in section 4.1 isn't precise enough; consider the "=3D" and = "&" characters, which are NOT required to be percent-encoded by RFC3986 = section 2.1. Also, the things that section is defining are not "URI = parameters" (which is things after a semicolon in a path segment); it's = a query string format. Really, what you want to do is either: a) = reference or re-define = , or b) define a subset of it that's = simple yet precise. 4) Section 4.2 would be a lot clearer if you just said that the = well-known location is ONLY defined for the HTTPS URI scheme. 5) Why not define a media type for JRD? You can instruct clients to also = accept application/json if you're worried about bad server = configurations. 6) What's the motivation for expires, given that HTTP caching = information is already available? Have you considered the interaction = between them? 7) Section 4.4.5 "user's preferred link relation." --> "user's preferred = link relation type." (and likely elsewhere). 8) RFC5988 defines the "target IRI" as what's at the end of the link; = here, "linked resource" is used (e.g., 4.4.5.[2,3]). Suggest "target = resource" as a way to tie them together conceptually. 9) Similarly, an important concept in 5988 is the "context" of the link; = suggest saying that the context of all of these links is the subject(s). 10) What if a target resource supports multiple media types for the same = relation? Suggest allowing multiple values in "type." 11) 4.5 says "WebFinger requests can include a parameter specifying..." = What kind of parameter? Tie it back to what happens in 4.1. 12) 4.5 says "WebFinger is agnostic regarding the scheme of such a = URI..." I think you mean "neutral", unless the protocol really = believes that the scheme is unknowable. Lucky 13) "For resources associated with a user account at a host..." = --> "To perform a webfinger lookup on an account specific to the host = being queried..." 14) In section 7 (and likely elsewhere), you should use the full URL, = not just the path /.well-known/webfinger, to make it clear that this is = just over HTTPS. Cheers, * I'm not INTENTIONALLY trolling here; if it starts a fight, it's not my = fault. -- Mark Nottingham http://www.mnot.net/ From ylafon@w3.org Tue Feb 5 07:27:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6AC21F8503 for ; Tue, 5 Feb 2013 07:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, 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 iDlxW5B6Suik for ; Tue, 5 Feb 2013 07:27:22 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 2E74C21F84C7 for ; Tue, 5 Feb 2013 07:27:20 -0800 (PST) Received: from ylafon by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1U2kQY-00012D-O8; Tue, 05 Feb 2013 10:27:18 -0500 Date: Tue, 5 Feb 2013 10:27:18 -0500 (EST) From: Yves Lafon To: apps-discuss@ietf.org, draft-ietf-geopriv-dhcp-lbyr-uri-option.all@tools.ietf.org Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: [apps-discuss] Review of draft-ietf-geopriv-dhcp-lbyr-uri-option-17 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Feb 2013 15:27:25 -0000 All, I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see [1]). Document: draft-ietf-geopriv-dhcp-lbyr-uri-option-17 Title: Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for= =20 a Location Uniform Resource Identifier (URI) Reviewer: Yves Lafon Review Date: 5 February 2013 Summary: This draft looks good to go, some minor clarification requested=20 on possibly too restrictive URI considerations, see below. Major Issues: none Minor Issues: The premise is that the use of this option will send a URI that needs to be dereferenced to retrieve a Location Object. Based on that, the restriction on data URIs seems too strong, why not restricting its use to only the ones labelled with the=20 'application/pidf+xml' media type (or better, a list specified in a=20 registry)? Also, it is unclear that application/pidf+xml forbid in its format=20 scripting (in fact, looking at the Schema definition in RFC3863, it does=20 not). HTH, [1] --=20 Baroula que barouleras, au ti=E9u toujou t'entourneras. ~~Yves From fgaliegue@gmail.com Tue Feb 5 13:22:33 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE4D21F8506 for ; Tue, 5 Feb 2013 13:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQg1ogZKNkzT for ; Tue, 5 Feb 2013 13:22:32 -0800 (PST) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 78D1D21F84FB for ; Tue, 5 Feb 2013 13:22:32 -0800 (PST) Received: by mail-oa0-f45.google.com with SMTP id o6so756978oag.32 for ; Tue, 05 Feb 2013 13:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5hXBF6DwqphRiJMyBWcG+ANs+Y+eW0fab1JciyTDVis=; b=DZL4TW6Mc3exKEJwT2teLBDc4moDu0fyXmfJpUYfO1aF9YjOsSvgSLpAeyjAI5DLoA 94X7bs5JhGHhY3kdZ39P/lOZOgYrFaABLL69mDsREryKcBp/jBgB9LL4GJ2P5ZUCiuov 9swur0m5xLxVw/yx0hUMnX+lE1+znEVXdpNp1fZ20PQU+L6e52DA86GTplQEiOjfgwSe LOpHHIgbRlMgYc/03srRTdmVx/RYsjNVZEeXPRPtSLCtr0qCCfzvs4dO8g5/ZeynmqOa Ukbm2TjIuuH0I5HMV+1QFNAfnTMI/co+Dn7W3QiZ4qrvdmSlIj9XqgpQUh6GE85X7avd QbBA== MIME-Version: 1.0 X-Received: by 10.182.2.132 with SMTP id 4mr19664816obu.42.1360099352084; Tue, 05 Feb 2013 13:22:32 -0800 (PST) Received: by 10.60.7.105 with HTTP; Tue, 5 Feb 2013 13:22:31 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Feb 2013 22:22:31 +0100 Message-ID: From: Francis Galiegue To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Announce: JSON Schema, I-D version 4 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Feb 2013 21:22:33 -0000 Hello Mark, On Tue, Feb 5, 2013 at 1:54 AM, Mark Nottingham wrote: > FWIW, since people are talking about it: > > I'm about +0.25 on doing this. > > On the one hand, XML Schema has created a lot of damage (the more so because many many people still don't understand how harmful it is / can be). > > On the other hand, this is not XML Schema. AFAICT it does not try to do nearly as much as XML Schema did. As has been discussed ad nauseum, the major use cases for a schema language are doing QA and documentation, and JSON could use help on both fronts. > I am not sure what you mean by QA here. Anyway, this may be of interest. It is a schema fully describing JSON Patch. Note that the "json-pointer" format attribute may be replaced by a regular expression: https://github.com/fge/json-schema-validator/blob/master/src/main/resources/json-patch.json Which means it is possible to map existing JSON representations using JSON Schema. Answering requests on the list, I also wrote schemas for GeoJSON and SMD. Links on demand. I am about to write a JSON Schema for JSON-RPC-2.0 as well. I can write schemas for nearly anything, within the limitations of JSON Schema. If you want me to write a schema for a defined format, I'll happily do it -- within the limitations of what JSON Schema can do. One thing you will notice about the link above is "notes": it is not known to JSON Schema and, as such, it is allowed. The specification explicitly allows for this. The specification asks that keywords unknown by an implementation be ignored by it -- while not explicitly rejecting their use between parties if they agree on it. At least, that was the intent. I thrived to make the wording as precise as possible. And I would certainly appreciate reviews: the earlier they come, the earlier we (I and others) can address comments. Thanks, -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From melvincarvalho@gmail.com Tue Feb 5 16:18:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900BB21F890D for ; Tue, 5 Feb 2013 16:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4ZGZ5k+PxKG for ; Tue, 5 Feb 2013 16:18:11 -0800 (PST) Received: from mail-ia0-x22c.google.com (ia-in-x022c.1e100.net [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8440A21F85E2 for ; Tue, 5 Feb 2013 16:18:11 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id u8so873015iag.3 for ; Tue, 05 Feb 2013 16:18:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aYbISn+UhcYVKb1ldNNfYqo76bLv+JjD7CQCwKuMvkw=; b=0hR3C4DxEGxZgq/hO5ADS8hjTRMl+/0LKGEl9hcUQVcW0JthTEbqRcf9gRNJCGB7I/ oBYx/56VZdDkNE1iRiBhQyMNcLU9unCXD/e688AHeqAuK8VfdmHM0ufeEFLmXM7c6mrb /alWaV9vMgRZ+VA9cG7oSTINMwecFJ6JFO/ptxEPRKJnCN3HFdNpl2TaBBJCA7G5bXMn s/Ty9wXmKqC/RILQyYH/ays5ak1bEtvGkxt/skt/vRVIFsxXg1HtrIRlQcnBahJ95mRS Aji46A9KVCZTuCHYLkWgsaqeP3hbU12IhXGqbANe4u7GHBA/B9k3ml/PuZH6daCIlJWR BKLQ== MIME-Version: 1.0 X-Received: by 10.50.5.239 with SMTP id v15mr1966330igv.41.1360109891115; Tue, 05 Feb 2013 16:18:11 -0800 (PST) Received: by 10.43.101.5 with HTTP; Tue, 5 Feb 2013 16:18:11 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Feb 2013 01:18:11 +0100 Message-ID: From: Melvin Carvalho To: Mark Nottingham Content-Type: multipart/alternative; boundary=e89a8f502cd6ea5ac604d503428b Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] WGLC feedback on webfinger-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 00:18:12 -0000 --e89a8f502cd6ea5ac604d503428b Content-Type: text/plain; charset=ISO-8859-1 On 5 February 2013 07:58, Mark Nottingham wrote: > Had a quick read of this draft. Overall this looks pretty good; the points > I raise are fairly minor. > > 1) The introduction seems to be missing a vital bit of information: that > the Whole Point -- the Big Trick -- that WebFinger performs is (AIUI) that > you can use an identifier that might not be usable as a locator (e.g., a > mailto: uri, an acct: uri) as a locator. In that sense, it's really just > a more real-world-usable URN lookup facility*. > > This is really important to include in the abstract as well as the > introduction, because without it, WF just seems like a silly indirection > mechanism on top of HTTP. > +1 > > 2) The examples use unregistered link relations types < > http://www.iana.org/assignments/link-relations/link-relations.xml>; > specifically, "blog" and "vcard". Naughty. > > 3) The text in section 4.1 isn't precise enough; consider the "=" and "&" > characters, which are NOT required to be percent-encoded by RFC3986 section > 2.1. Also, the things that section is defining are not "URI parameters" > (which is things after a semicolon in a path segment); it's a query string > format. Really, what you want to do is either: a) reference or re-define < > http://www.w3.org/html/wg/drafts/html/master/forms.html#application/x-www-form-urlencoded-encoding-algorithm>, > or b) define a subset of it that's simple yet precise. > > 4) Section 4.2 would be a lot clearer if you just said that the well-known > location is ONLY defined for the HTTPS URI scheme. > > 5) Why not define a media type for JRD? You can instruct clients to also > accept application/json if you're worried about bad server configurations. > Why application/json? I can understand this argument for "informational", but for "proposed standard" I would have thought that the serialization ought to a media type? > > 6) What's the motivation for expires, given that HTTP caching information > is already available? Have you considered the interaction between them? > > 7) Section 4.4.5 "user's preferred link relation." --> "user's preferred > link relation type." (and likely elsewhere). > > 8) RFC5988 defines the "target IRI" as what's at the end of the link; > here, "linked resource" is used (e.g., 4.4.5.[2,3]). Suggest "target > resource" as a way to tie them together conceptually. > > 9) Similarly, an important concept in 5988 is the "context" of the link; > suggest saying that the context of all of these links is the subject(s). > > 10) What if a target resource supports multiple media types for the same > relation? Suggest allowing multiple values in "type." > > 11) 4.5 says "WebFinger requests can include a parameter specifying..." > What kind of parameter? Tie it back to what happens in 4.1. > > 12) 4.5 says "WebFinger is agnostic regarding the scheme of such a URI..." > I think you mean "neutral", unless the protocol really believes that the > scheme is unknowable. > > Lucky 13) "For resources associated with a user account at a host..." --> > "To perform a webfinger lookup on an account specific to the host being > queried..." > > 14) In section 7 (and likely elsewhere), you should use the full URL, not > just the path /.well-known/webfinger, to make it clear that this is just > over HTTPS. > > Cheers, > > > * I'm not INTENTIONALLY trolling here; if it starts a fight, it's not my > fault. > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --e89a8f502cd6ea5ac604d503428b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 5 February 2013 07:58, Mark Nottingha= m <= mnot@mnot.net> wrote:
Had a quick read of this draft. Overall this looks pretty good; the points = I raise are fairly minor.

1) The introduction seems to be missing a vital bit of information: that th= e Whole Point -- the Big Trick -- that WebFinger performs is (AIUI) that yo= u can use an identifier that might not be usable as a locator (e.g., a mail= to: uri, an acct: uri) as a locator. In that sense, it's really just a = more real-world-usable URN lookup facility*.

This is really important to include in the abstract as well as the introduc= tion, because without it, WF just seems like a silly indirection mechanism = on top of HTTP.

+1
=A0

2) The examples use unregistered link relations types <http://www.iana.org/assignments/link-relations/link-relations.xml&g= t;; specifically, "blog" and "vcard". Naughty.

3) The text in section 4.1 isn't precise enough; consider the "=3D= " and "&" characters, which are NOT required to be perce= nt-encoded by RFC3986 section 2.1. Also, the things that section is definin= g are not "URI parameters" (which is things after a semicolon in = a path segment); it's a query string format. Really, what you want to d= o is either: a) reference or re-define <http://www.w3.org/html/wg/drafts/html/maste= r/forms.html#application/x-www-form-urlencoded-encoding-algorithm>, = or b) define a subset of it that's simple yet precise.

4) Section 4.2 would be a lot clearer if you just said that the well-known = location is ONLY defined for the HTTPS URI scheme.

5) Why not define a media type for JRD? You can instruct clients to also ac= cept application/json if you're worried about bad server configurations= .

Why application/json?=A0 I can understand this a= rgument for "informational", but for "proposed standard"= ; I would have thought that the serialization ought to a media type?=A0 =A0

6) What's the motivation for expires, given that HTTP caching informati= on is already available? Have you considered the interaction between them?<= br>
7) Section 4.4.5 "user's preferred link relation." --> &qu= ot;user's preferred link relation type." (and likely elsewhere).
8) RFC5988 defines the "target IRI" as what's at the end of t= he link; here, "linked resource" is used (e.g., 4.4.5.[2,3]). Sug= gest "target resource" as a way to tie them together conceptually= .

9) Similarly, an important concept in 5988 is the "context" of th= e link; suggest saying that the context of all of these links is the subjec= t(s).

10) What if a target resource supports multiple media types for the same re= lation? Suggest allowing multiple values in "type."

11) 4.5 says "WebFinger requests can include a parameter specifying...= " What kind of parameter? Tie it back to what happens in 4.1.

12) 4.5 says "WebFinger is agnostic regarding the scheme of such a URI= ..." =A0 I think you mean "neutral", unless the protocol rea= lly believes that the scheme is unknowable.

Lucky 13) "For resources associated with a user account at a host...&q= uot; --> "To perform a webfinger lookup on an account specific to t= he host being queried..."

14) In section 7 (and likely elsewhere), you should use the full URL, not j= ust the path /.well-known/webfinger, to make it clear that this is just ove= r HTTPS.

Cheers,


* I'm not INTENTIONALLY trolling here; if it starts a fight, it's n= ot my fault.

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



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

--e89a8f502cd6ea5ac604d503428b-- From mnot@mnot.net Tue Feb 5 16:28:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9851021F86F2 for ; Tue, 5 Feb 2013 16:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.516 X-Spam-Level: X-Spam-Status: No, score=-105.516 tagged_above=-999 required=5 tests=[AWL=-2.917, 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 ul7BrNeElwRh for ; Tue, 5 Feb 2013 16:28:44 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED8921F8A61 for ; Tue, 5 Feb 2013 16:28:43 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.138.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 90F9522E1F4; Tue, 5 Feb 2013 19:28:36 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Wed, 6 Feb 2013 11:28:33 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Melvin Carvalho X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] WGLC feedback on webfinger-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 00:28:44 -0000 On 06/02/2013, at 11:18 AM, Melvin Carvalho = wrote: > 5) Why not define a media type for JRD? You can instruct clients to = also accept application/json if you're worried about bad server = configurations. >=20 > Why application/json? I can understand this argument for = "informational", but for "proposed standard" I would have thought that = the serialization ought to a media type? =20 I think it ought to have its own media type, but I could understand if = folks were concerned that strictly requiring clients to expect only it = might lead to deployment problems. Cheers, -- Mark Nottingham http://www.mnot.net/ From barryleiba.mailing.lists@gmail.com Tue Feb 5 18:05:57 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941BC21F8A14; Tue, 5 Feb 2013 18:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.002 X-Spam-Level: X-Spam-Status: No, score=-103.002 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 tv+aZQd+wg0S; Tue, 5 Feb 2013 18:05:57 -0800 (PST) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id D869421F8A33; Tue, 5 Feb 2013 18:05:56 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id ft2so526434vbb.9 for ; Tue, 05 Feb 2013 18:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=S+CDZhyMzwrL8nkHCEvG0z2UkCpWArREDj3GHEvDxdU=; b=Mpd9DD/Mq+StlPB1jh8S3B/SbupLCqs8oBcM94mauMqsjh8Y3r6CejC+wv5f8UT2oB asfnBZfxyNXOAtkb7haP62RNTUMRBkPl4uKu0yhV/G8ONmAs1FBAmifgAmAJqeQm+Sof y3CEyMn4iGFPGETog0YmEPdNGfYQXwYhFSFXvi0SP+MMIkT/lmdKbKcsK0nnDaVUJXQI yYSGZDu1q388JiskI57VBc0OpYIxVYrj14IWu8FLwgNQJeE3BWsiGrJjeqLmSdb3VxyW MPOfP733BlaalkLbbrJf5xMAQNwfCLUuHoHANLyqrmUjef/hR5sxbZGPLDBL1GGgg/tp x5og== MIME-Version: 1.0 X-Received: by 10.52.91.142 with SMTP id ce14mr26780943vdb.84.1360116356151; Tue, 05 Feb 2013 18:05:56 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Tue, 5 Feb 2013 18:05:55 -0800 (PST) In-Reply-To: <20130131141357.26035.79309.idtracker@ietfa.amsl.com> References: <20130131141357.26035.79309.idtracker@ietfa.amsl.com> Date: Wed, 6 Feb 2013 10:05:55 +0800 X-Google-Sender-Auth: ZMtMAC5TKsSFoVinLpJh_yenzpU Message-ID: From: Barry Leiba To: "apps-discuss@ietf.org" , "uri-review@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Fwd: Last Call: (Additional XML Security Uniform Resource Identifiers (URIs)) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 02:05:57 -0000 The subject document is needed by W3C, and is submitted on that basis. The App and URI communities ought to have a look at it, and Sean (who's sponsoring it) and I want to bring it to your attention. It would be great if some of you could review it during the last call period. Please post any comments to , and NOT to these lists. Thanks. Barry, Applications AD ---------- Forwarded message ---------- From: The IESG Date: Thu, Jan 31, 2013 at 10:13 PM Subject: Last Call: (Additional XML Security Uniform Resource Identifiers (URIs)) to Proposed Standard To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'Additional XML Security Uniform Resource Identifiers (URIs)' 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 2013-02-28. 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 This document expands and updates the list of URIs specified in RFC 4051 and intended for use with XML Digital Signatures, Encryption, Canonicalization, and Key Management. These URIs identify algorithms and types of information. This document obsoletes RFC 4051. The file can be obtained via http://datatracker.ietf.org/doc/draft-eastlake-additional-xmlsec-uris/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-eastlake-additional-xmlsec-uris/ballot/ No IPR declarations have been submitted directly on this I-D. Note that this document includes the following downrefs: RFC 2315 RFC 4050 RFC 4269 RFC 6234 From tbray@textuality.com Tue Feb 5 19:20:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CA921F8A33 for ; Tue, 5 Feb 2013 19:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.077 X-Spam-Level: X-Spam-Status: No, score=-4.077 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaSbwrvNefHx for ; Tue, 5 Feb 2013 19:20:03 -0800 (PST) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 61EBB21F8A1C for ; Tue, 5 Feb 2013 19:20:03 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id j1so1020406oag.7 for ; Tue, 05 Feb 2013 19:20:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=lmGxZLg8I4hmnIsA/SlLj5wQhVIp0nlJhdAyLXt2MO0=; b=evoNLNS0Bn/vvNw4GchGRhULpfLvQMchNI1uSxufJ0llfbyHyazRNTkTlSYK/h29xQ URS+pMDhQ+R+K/DtH3OXl0XOApv7OopqvIUYo0Cl9qyQjMWKebaTyZgk68ptOiX3wSfu 22kxNjHKmB53dvRw6j3/pisPwdfCIEVn+Emm0CZR+6Fc2wGuLl5+GrzfYnlCDDqHQk9g SYZxZjDz4g52kmMPigP5L35u/wMfCYU5Dr6PLpS1TS7jBAhfysYldFLyo9f3OEhEXsqi 1T6lbJyA8rZbS7J7Fzz5xkTYI1o7PaI/De/BN90wCkDXfxAfH1cVdGpA5cFNLJ1nxQkr Qppw== MIME-Version: 1.0 X-Received: by 10.182.113.40 with SMTP id iv8mr14174820obb.12.1360120800662; Tue, 05 Feb 2013 19:20:00 -0800 (PST) Received: by 10.76.168.132 with HTTP; Tue, 5 Feb 2013 19:20:00 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Tue, 5 Feb 2013 19:20:00 -0800 Message-ID: From: Tim Bray To: Mark Nottingham Content-Type: multipart/alternative; boundary=f46d04479f952cd35904d505cd14 X-Gm-Message-State: ALoCoQn9UUF57K023+LTyY1y/lwnv5kciPKdaiCe1Uyg67AesQup/9KlqmlPW4m4k8mN3IZALS0E Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] WGLC feedback on webfinger-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 03:20:04 -0000 --f46d04479f952cd35904d505cd14 Content-Type: text/plain; charset=ISO-8859-1 One more voice in favor of a media type but, like Mark, not terribly passionate. -T On Tue, Feb 5, 2013 at 4:28 PM, Mark Nottingham wrote: > > On 06/02/2013, at 11:18 AM, Melvin Carvalho > wrote: > > > 5) Why not define a media type for JRD? You can instruct clients to also > accept application/json if you're worried about bad server configurations. > > > > Why application/json? I can understand this argument for > "informational", but for "proposed standard" I would have thought that the > serialization ought to a media type? > > I think it ought to have its own media type, but I could understand if > folks were concerned that strictly requiring clients to expect only it > might lead to deployment problems. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d04479f952cd35904d505cd14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
One more voice in favor of a media type but, like Mark, no= t terribly passionate. -T


On Tue, Feb 5, 2013 at 4:28 PM, Mark Nottingham <mnot@mn= ot.net> wrote:

On 06/02/2013, at 11:18 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 5) Why not define a media type for JRD? You can instruct clients to al= so accept application/json if you're worried about bad server configura= tions.
>
> Why application/json? =A0I can understand this argument for "info= rmational", but for "proposed standard" I would have thought= that the serialization ought to a media type?

I think it ought to have its own media type, but I could understand if folk= s were concerned that strictly requiring clients to expect only it might le= ad to deployment problems.

Cheers,

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



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

--f46d04479f952cd35904d505cd14-- From yaojk@cnnic.cn Wed Feb 6 00:43:00 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE8721F86B0 for ; Wed, 6 Feb 2013 00:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.049 X-Spam-Level: X-Spam-Status: No, score=-98.049 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.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 nXrg7RdOz44v for ; Wed, 6 Feb 2013 00:42:58 -0800 (PST) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 11E6F21F8691 for ; Wed, 6 Feb 2013 00:42:51 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 06 Feb 2013 16:42:41 +0800 Message-ID: <72266BF4E92D401E9F312898766D6B16@LENOVO47E041CF> From: "Jiankang YAO" To: , Date: Wed, 6 Feb 2013 16:42:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: [apps-discuss] APPSDIR review of draft-shafranovich-mime-sql-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 08:43:00 -0000 DQpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgQXBwbGljYXRpb25zIEFyZWEgRGlyZWN0b3Jh dGUgcmV2aWV3ZXIgZm9yIHRoaXMgDQpkcmFmdCAoZm9yIGJhY2tncm91bmQgb24gYXBwc2Rpciwg cGxlYXNlIHNlZSANCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvYXBwL3RyYWMvd2lr aS9BcHBsaWNhdGlvbnNBcmVhRGlyZWN0b3JhdGUgKS4NCg0KUGxlYXNlIHJlc29sdmUgdGhlc2Ug Y29tbWVudHMgYWxvbmcgd2l0aCBhbnkgb3RoZXIgY29tbWVudHMgeW91IA0KbWF5IHJlY2VpdmUu ICANCkRvY3VtZW50OiBkcmFmdC1zaGFmcmFub3ZpY2gtbWltZS1zcWwtMDMudHh0DQpUaXRsZTog VGhlIGFwcGxpY2F0aW9uL3NxbCBNZWRpYSBUeXBlDQpSZXZpZXdlcjogSmlhbmthbmcgWWFvIA0K UmV2aWV3IERhdGU6IDYgTUFSLiAyMDEzDQpTdW1tYXJ5OiAgVGhpcyBkcmFmdCBpcyBhbG1vc3Qg cmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLg0KDQpNYWpvciBJ c3N1ZXM6IG5vbmUNCk1pbm9yIElzc3Vlczogbm9uZQ0KRGlzY3Vzc2lvbiBJc3N1ZToNCg0KSW4g c2VjdGlvbiAyLCB3aGljaCBzYWlkICJQZXJzb24gJiBlbWFpbCBhZGRyZXNzIHRvIGNvbnRhY3Qg Zm9yIGZ1cnRoZXIgaW5mb3JtYXRpb246DQpZYWtvdiBTaGFmcmFub3ZpY2ggPGlldGZAc2hhZnRl ay5vcmc+Ig0KDQpJcyBpdCBnb29kIHRvIGxpc3QgdGhlIHBlcnNpb25hbCBlbWFpbCBhZGRyZXNz IGlldGZAc2hhZnRlay5vcmcgYXMgdGhlIHBlcm1hbmVudCBjb250YWN0IGFkZHJlc3M/DQoNCg0K Tml0czogDQoNCkluIHNlY3Rpb24gMywgd2hpY2ggc2FpZCAgIkFmdGVyIGFwcHJvdmFsLCBJQU5B IGlzIGFza2VkIHRvIHJlZ2lzdGVyIHRoZSBtZWRpYSB0eXBlIGFwcGxpY2F0aW9uLw0Kc3FsIGlu IHRoZSBTdGFuZGFyZHMgdHJlZSB1c2luZyB0aGUgYXBwbGljYXRpb24gcHJvdmlkZWQgaW4gU2Vj dGlvbiAyDQpvZiB0aGlzIGRvY3VtZW50LiINCg0KSSBzdWdnZXN0IHRvIGltcHJvdmUgdGhlIG1l YW5pbmcgb2YgImFmdGVyIGFwcHJvdmFsIiBvciByZW1vdmUgdGhlICJhZnRlciBhcHByb3ZhbCIu DQpJZiAiYWZ0ZXIgYXBwcm92YWwiIG1lYW5zIFJGQyBwdWJsaWNhdGlvbiwgd2UgZG8gbmVlZCB0 byByZXBlYXQgaXQgaGVyZS4NCklmICJhZnRlciBhcHByb3ZhbCIgbWVhbnMgb3RoZXIga2luZCBv ZiBhcHByb3ZhbCwgcGxzIHNwZWNpZnkgaXQgaGVyZS4NCg0KSmlhbmthbmcgWWFvDQo= From dave@cridland.net Wed Feb 6 02:33:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF61B21F8809 for ; Wed, 6 Feb 2013 02:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skXPUybSCcRW for ; Wed, 6 Feb 2013 02:33:08 -0800 (PST) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id C179921F8808 for ; Wed, 6 Feb 2013 02:33:07 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id cz10so970265veb.7 for ; Wed, 06 Feb 2013 02:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=altmZjsBiXdEQtiYyO8usUjzzAKqyfmUJfdZJb/WGFA=; b=aExTwtXn69GO+iR/CZ/CUmUVvsWkuiDlprj4FgbveWM3huXjfgdEIB7Zt46skrKjSP 5acH9SjbX+0IeaLIr6CRuMsD8aPueNw7ctXwFW/ox1lJxrkMDNz3yJWilGISCGPI3pnE Pqev9DBPxMAOEx7H3iOgTYO/aA1MwRzVlWXs0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=altmZjsBiXdEQtiYyO8usUjzzAKqyfmUJfdZJb/WGFA=; b=cLQx2z4H6Nu0aXwF38GxL+0HCLv3o3JrS/VnYtt5ULXG3CPw1jmLo9yNp2JAhaBxfX Bhd2VMJJbF0+kDcZvBWjAS19Ru9ag/rENMRez7HrTv/6azz/LjCN6ebs8HXmJGPlXQh5 zUQu5kUynO7Wh+VAY0ZhbepKENa6aN0ZZ1ab3+creQOcABlGVQjhiDlKU9I7yB1c5eYj vpDGbdgxKglXKbKP9pC6Z2GGhtRasjmzxr4vh99KGE25EH3AyiIZu+LpAm0WT7sY92i0 vIzEiQUWRJdqy3xZ85yz5Mqg7NgKQo4iNwTZY3ntDmD9wj6HbWgZrVwHB35RdcijMgi4 zZtQ== MIME-Version: 1.0 X-Received: by 10.220.153.69 with SMTP id j5mr31383959vcw.35.1360146787468; Wed, 06 Feb 2013 02:33:07 -0800 (PST) Received: by 10.58.69.99 with HTTP; Wed, 6 Feb 2013 02:33:07 -0800 (PST) Received: by 10.58.69.99 with HTTP; Wed, 6 Feb 2013 02:33:07 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Feb 2013 10:33:07 +0000 Message-ID: From: Dave Cridland To: Mark Nottingham Content-Type: multipart/alternative; boundary=f46d043c7ca61c07b504d50bdafb X-Gm-Message-State: ALoCoQkRxvW73UJaUl2Yjcj+tAF1KrygmyZlKkegF78cJIORNwDWo+ellyIVhSHo2wTqO+qxfLx/ Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC feedback on webfinger-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 10:33:09 -0000 --f46d043c7ca61c07b504d50bdafb Content-Type: text/plain; charset=ISO-8859-1 On 6 Feb 2013 00:28, "Mark Nottingham" wrote: > > > On 06/02/2013, at 11:18 AM, Melvin Carvalho wrote: > > > 5) Why not define a media type for JRD? You can instruct clients to also accept application/json if you're worried about bad server configurations. > > > > Why application/json? I can understand this argument for "informational", but for "proposed standard" I would have thought that the serialization ought to a media type? > > I think it ought to have its own media type, but I could understand if folks were concerned that strictly requiring clients to expect only it might lead to deployment problems. > SHOULD use a media type of X, MUST accept media types of X or Y would satisfy me. --f46d043c7ca61c07b504d50bdafb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On 6 Feb 2013 00:28, "Mark Nottingham" <mnot@mnot.net> wrote:
>
>
> On 06/02/2013, at 11:18 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>
> > 5) Why not define a media type for JRD? You can instruct clients = to also accept application/json if you're worried about bad server conf= igurations.
> >
> > Why application/json? =A0I can understand this argument for "= ;informational", but for "proposed standard" I would have th= ought that the serialization ought to a media type?
>
> I think it ought to have its own media type, but I could understand if= folks were concerned that strictly requiring clients to expect only it mig= ht lead to deployment problems.
>

SHOULD use a media type of X, MUST accept media types of X o= r Y would satisfy me.

--f46d043c7ca61c07b504d50bdafb-- From jyee@afilias.info Wed Feb 6 09:10:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206F221F8523 for ; Wed, 6 Feb 2013 09:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5WOHs0Zir5h for ; Wed, 6 Feb 2013 09:10:39 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id DCABE21F84FC for ; Wed, 6 Feb 2013 09:10:38 -0800 (PST) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1U38W6-0000JX-3t for apps-discuss@ietf.org; Wed, 06 Feb 2013 17:10:38 +0000 Received: from mail-ob0-f198.google.com ([209.85.214.198]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1U38W6-0005xZ-3b for apps-discuss@ietf.org; Wed, 06 Feb 2013 17:10:38 +0000 Received: by mail-ob0-f198.google.com with SMTP id dn14so7422155obc.1 for ; Wed, 06 Feb 2013 09:10:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=hueGcy8AMuSWvc7FlYJaGAUiAdcueQ5AUpI213ACbMY=; b=KUNu30wxqBGq4yU9bnof7mJuDiqoyBo8qCJkBd4VImEdU8UJq6FXBuNDoxDo4dylM0 +hg15MOPH/+vnBp3//6WvEXhdMMi7fW65TJqngCB7A3B4EEpdCej3s1a0+jguUE0V9dN wJleqaBiwjYkAHumeuC8NMJ6St/bLEcAA6FWJ3ae2hch+UZGS6pDB3Aa2U0zV6C188Vy dh2xX5djy9ZxPqWFRw3WxtWXMq2NmtaSsYo4WUYlRLipfy8Sa93aMxDpDZCCzWO48Zh8 KK+XrcaBjN0G6VxPNe+AQRDs7NIkWdHuJBb9+bNLw3uASxYN0LKm3Z2vYFidlf2ypZ7K 93yA== X-Received: by 10.60.7.129 with SMTP id j1mr22624458oea.54.1360170632719; Wed, 06 Feb 2013 09:10:32 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.7.129 with SMTP id j1mr22624449oea.54.1360170632577; Wed, 06 Feb 2013 09:10:32 -0800 (PST) Received: by 10.76.109.39 with HTTP; Wed, 6 Feb 2013 09:10:32 -0800 (PST) Date: Wed, 6 Feb 2013 12:10:32 -0500 Message-ID: From: Joseph Yee To: draft-ietf-mpls-tp-use-cases-and-design.all@tools.ietf.org, apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkdkYpq8Sb68sRx/LQMepTiYoXEHK3MKyJo86u7YIboWEmaI38QAoozGWHYn7GiCR0jj/xOL39QXsU0kLE7WTNQ2tV7y45tt/m/SiQhCfjGjwiv4la3nVM9VS69mzc/IpnNmiNfxruENqF8vLUn81Z9sqscMA== Subject: [apps-discuss] APPSDIR Review of draft-ietf-mpls-tp-use-cases-and-design-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: Wed, 06 Feb 2013 17:10:43 -0000 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). 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-mpls-tp-use-cases-and-design-06 Title: MPLS-TP Applicability; Use Cases and Design Reviewer: Joseph Yee Review Date: Feb 6, 2013 Summary: This draft is ready for publication, would be better if the editorial changes can put into the draft. Major Issues: none Minor Issues: (1) "Applicability" in Abstract and Introduction "This document provides applicability, use case studies and network design considerations for the Multiprotocol Label Switching Transport Profile (MPLS-TP)." Mostly because of how my brain was wired (or how my high school teacher wired my brain). When I see text structured this way, I'm expecting three sections rather than two. Note I have no issues about the discussion of applicability in this draft at all. Then I realized more from how the title was written that it's a draft with two major topic sections rather than three. My suggestion for the text: "This document provides the applicability of Multiprotocol Label Switching Transport Profile (MPLS-TP) with use case studies and network design considerations." (2) Section 1 Introduction 5th paragraph "LSP Ping Extension for on-demand CC-CV [RFC6426], fault allocation, and remote integrity check." "and switch-over triggering with Link Defect Indication (LDI)" Any reference for the 'fault allocation, and remote integrity check" and LDI that could be added to the draft? (3) Section 2 Terminology: 4G "4G 4th Generation Mobile network: LTE" This is close to nits. '4G' is not only LTE right? Do you mean to use 4G to refer only LTE is this draft? If the section title "4G/LTE Mobile Backhaul" and its text at section 3.3.2 does not confuse readers who is more familiar with the topic, I don't think this is an issue. Nits: (1) Terminology through out the draft There are several occasions where acronyms were not logged in the terminology section (ex. PW), and some text don't use terminology consistently (ex. SP vs service provider). These are not the only two, but I think RFC Editors provides the best help in this regard. (2) Section 7 Acknowledgements "... thank Stewart for his text contribution on timing ..." Stewart who? ;) Best Regards, Joseph Yee From aretana@cisco.com Tue Feb 5 10:46:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5134721F890D; Tue, 5 Feb 2013 10:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq3k+k0JPbOI; Tue, 5 Feb 2013 10:46:45 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D365021F86F0; Tue, 5 Feb 2013 10:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15495; q=dns/txt; s=iport; t=1360090005; x=1361299605; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=I5aajqofKa2fiSENwZPezJ/O4g6p36UdXQgvqkY/Vn0=; b=j+9IPuo4jfGWvfQXA50ohQOrMs7zz067wrV1FA38zOuZ8kMJI9fzaTwh fMIzVkwNj+fvZLUCrpKgqWAvBUoZZ2T+4f00yQGBz1+bJff1M2qSXoXp9 i2iVKgdceZdyHG4PR+m7PKn5AHktp7GfKECedwlGYr2qa8uYoEdjnOT0Q Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAChTEVGtJXHA/2dsb2JhbABFgkm9GRZzgiEBBIELAQgiHTkUEQIEARIIE4d2DKpIkCiQemEDiDCPDo81gn6CJA X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; d="scan'208,217";a="173687354" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 05 Feb 2013 18:46:43 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r15IkhT9012032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Feb 2013 18:46:43 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.174]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 12:46:42 -0600 From: "Alvaro Retana (aretana)" To: Dave Cridland , "draft-ietf-ospf-rfc3137bis.all@tools.ietf.org" , "apps-discuss@ietf.org" , "iesg@ietf.org" Thread-Topic: AppsDir Review of draft-ietf-ospf-rfc3137bis-03 Thread-Index: AQHOAYmaPM3+s05c5Eq+gqRbTg9wl5hrr/UA Date: Tue, 5 Feb 2013 18:46:41 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.210.59] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94ED071B5xmbalnx15ciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 06 Feb 2013 10:30:56 -0800 Subject: Re: [apps-discuss] AppsDir Review of draft-ietf-ospf-rfc3137bis-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 18:46:46 -0000 --_000_BBD66FD99311804F80324E8139B3C94ED071B5xmbalnx15ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 2/2/13 9:09 PM, "Dave Cridland" > wrote: Dave: First of all, thanks for the review! .. For the most part this draft seems ready for publication, though I'm concer= ned it offers confusing guidance on which mechanism to use, and some wordsm= ithing is needed here. Detail: =A72.1 suggests it is a "similar, if not better" solution available to OSPF= v3 networks. It's not clear to me if this means "similar, and potentially b= etter", or "similar, but not better". The second paragraph is also somewhat= loose in whether this technique is recommended or not. It's not clear to me if the portion following the semicolon is essentially = saying that the R-bit is superior; this is not helped by being unclear if "= more granular" means finer or coarser. A quick trip to Wikipedia didn't hel= p me, either, apparently it depends on whether the R-bit is photographic, s= ugary, or something else. My guess, without looking at the OSPFv3 specification, is that this techniq= ue is liable to be better by dint of the R-bit applying to individual prefi= xes - that is, the technique is "similar, and usually better", because the = R-bit provides a "more specific", or possibly "individual" indication of wh= ether a router is active. This may be wrong, in which case it's a perfect i= llustration of why it's confusing. We tried not to pass judgement as to which mechanism was better, since it d= epends on what the operator wants to do in the network: allow transit as a = last resort or not at all. We tried to say something about that in the 'De= ployment Consideration' section, but I do agree that we could make it clear= er. The use of 'granular' is specially confusing as the R-bit is used to i= ndicate whether the whole router is active (and should be used for transit)= or not, versus the MaxLinkMetric option which expects all the non-stub lin= ks to use it. I put some proposed text below. In it we're clarifying the text in 2.1 and= added a paragraph at the end of 4. Please let me know if this is still no= t clear. Thanks! Alvaro. 2.1. OSPFv3-only Solution OSPFv3 [RFC5340] introduced additional options to provide similar control of the forwarding topology; the R-bit provides an indication of whether a router is active and should be used for transit traffic. It is left to network operators to decide which technique to use in their network. See Section 4 for more details. .. 4. Deployment Considerations When using MaxLinkMetric, some inconsistency may be seen if the network is constructed of routers that perform intra-area Dijkstra calculation as specified in [RFC1247] (discarding link records in router-LSAs that have a MaxLinkMetric cost value) and routers that perform it as specified in [RFC1583] and higher (do not treat links with MaxLinkMetric cost as unreachable). Note that this inconsistency will not lead to routing loops, because if there are some alternate paths in the network, both types of routers will agree on using them rather than the path through the stub router. If the path through the stub router is the only one, the routers of the first type will not use the stub router for transit (which is the desired behavior), while the routers of the second type will still use this path. On the other hand, clearing the R-bit will consistently result in the router not being used as transit. The use of MaxLinkMetric or the R-bit in a network depends on the objectives of the operator. One of the possible considerations for selecting one or the other is in the desired behavior if the path through the stub router is the only one available. Using MaxLinkMetric allows for that path to be used, while the R-bit doesn't. --_000_BBD66FD99311804F80324E8139B3C94ED071B5xmbalnx15ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <23A8178FA5091C4392D035D8281C93D7@cisco.com> Content-Transfer-Encoding: quoted-printable
On 2/2/13 9:09 PM, "Dave Cridland" <dave@cridland.net> wrote:

Dave:

First of all, thanks for the review!

..
For the most part this draft seems ready for publication, though I'm conce= rned it offers confusing guidance on which mechanism to use, and some words= mithing is needed here.

Detail:

=A72.1 suggests it is a "similar, if not better" solution availa= ble to OSPFv3 networks. It's not clear to me if this means "similar, a= nd potentially better", or "similar, but not better". The second paragraph is also somewhat loose in whether this technique is r= ecommended or not.

It's not clear to me if the portion following the semicolon is essentially= saying that the R-bit is superior; this is not helped by being unclear if = "more granular" means finer or coarser. A quick trip to Wikipedia didn't help me, either, apparently it depends on= whether the R-bit is photographic, sugary, or something else.

My guess, without looking at the OSPFv3 specification, is that this techni= que is liable to be better by dint of the R-bit applying to individual pref= ixes - that is, the technique is "similar, and usually better", because the R-bit provides a "more specific= ", or possibly "individual" indication of whether a router i= s active. This may be wrong, in which case it's a perfect illustration of w= hy it's confusing.

We tried not to pass judgement as to which mechanism was better, since it d= epends on what the operator wants to do in the network: allow transit as a = last resort or not at all.  We tried to say something about that in th= e 'Deployment Consideration' section, but I do agree that we could make it clearer.  The use of 'granular' = is specially confusing as the R-bit is used to indicate whether the whole r= outer is active (and should be used for transit) or not, versus the Ma= xLinkMetric option which expects all the non-stub links to use it.

I put some proposed text below.  In it we're clarifying the text in 2.= 1 and added a paragraph at the end of 4.  Please let me know if this i= s still not clear.

Thanks!

Alvaro.

2.1.  OSPFv3-only Solution

   OSPFv3 [RFC5340] introduced additional options to provide similar=20
   control of the forwarding topology; the R-bit provides an indication=20
   of whether a router is active and should be used for transit traffic.

   It is left to network operators to decide which technique to use in
   their network.  See Section 4 for more details.

..

4.  Deployment Considerations

   When using MaxLinkMetric, some inconsistency may be seen if the
   network is constructed of routers that perform intra-area Dijkstra
   calculation as specified in [RFC1247] (discarding link records in
   router-LSAs that have a MaxLinkMetric cost value) and routers that
   perform it as specified in [RFC1583] and higher (do not treat links
   with MaxLinkMetric cost as unreachable).  Note that this
   inconsistency will not lead to routing loops, because if there are
   some alternate paths in the network, both types of routers will agree
   on using them rather than the path through the stub router.  If the
   path through the stub router is the only one, the routers of the
   first type will not use the stub router for transit (which is the
   desired behavior), while the routers of the second type will still
   use this path.

   On the other hand, clearing the R-bit will consistently result in the
   router not being used as transit.

   The use of MaxLinkMetric or the R-bit in a network depends on the=20
   objectives of the operator.  One of the possible considerations for=20
   selecting one or the other is in the desired behavior if the path=20
   through the stub router is the only one available.  Using MaxLinkMetric=
=20
   allows for that path to be used, while the R-bit doesn't.
--_000_BBD66FD99311804F80324E8139B3C94ED071B5xmbalnx15ciscocom_-- From riwhite@verisign.com Wed Feb 6 12:14:31 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE6C21F88E3; Wed, 6 Feb 2013 12:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 D37-vNadgfGI; Wed, 6 Feb 2013 12:14:30 -0800 (PST) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE3521F897A; Wed, 6 Feb 2013 12:14:22 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKURK5nS8FAd05ZraissJ6xfXFQ/pdNW37@postini.com; Wed, 06 Feb 2013 12:14:29 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r16KEITK008560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Feb 2013 15:14:18 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Wed, 6 Feb 2013 15:13:59 -0500 From: "White, Russell" To: "Alvaro Retana (aretana)" , Dave Cridland , "draft-ietf-ospf-rfc3137bis.all@tools.ietf.org" , "apps-discuss@ietf.org" , "iesg@ietf.org" Thread-Topic: AppsDir Review of draft-ietf-ospf-rfc3137bis-03 Thread-Index: AQHOAYl8PgPHvjBFdUqj6+YNaBUr8phr8wSAgAFWqp4= Date: Wed, 6 Feb 2013 20:13:54 +0000 Message-ID: <3F74C1962631E14292BBF1B1B5F7021E1E2C1092@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_3F74C1962631E14292BBF1B1B5F7021E1E2C1092BRN1WNEXMBX01vc_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 06 Feb 2013 12:54:11 -0800 Subject: Re: [apps-discuss] AppsDir Review of draft-ietf-ospf-rfc3137bis-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 20:14:31 -0000 --_000_3F74C1962631E14292BBF1B1B5F7021E1E2C1092BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I like this text --thanks for putting this together, Alvaro. :-) Russ ________________________________ From: Alvaro Retana (aretana) [aretana@cisco.com] Sent: Tuesday, February 05, 2013 1:46 PM To: Dave Cridland; draft-ietf-ospf-rfc3137bis.all@tools.ietf.org; apps-disc= uss@ietf.org; iesg@ietf.org Subject: Re: AppsDir Review of draft-ietf-ospf-rfc3137bis-03 On 2/2/13 9:09 PM, "Dave Cridland" > wrote: Dave: First of all, thanks for the review! .. For the most part this draft seems ready for publication, though I'm concer= ned it offers confusing guidance on which mechanism to use, and some wordsm= ithing is needed here. Detail: =A72.1 suggests it is a "similar, if not better" solution available to OSPF= v3 networks. It's not clear to me if this means "similar, and potentially b= etter", or "similar, but not better". The second paragraph is also somewhat= loose in whether this technique is recommended or not. It's not clear to me if the portion following the semicolon is essentially = saying that the R-bit is superior; this is not helped by being unclear if "= more granular" means finer or coarser. A quick trip to Wikipedia didn't hel= p me, either, apparently it depends on whether the R-bit is photographic, s= ugary, or something else. My guess, without looking at the OSPFv3 specification, is that this techniq= ue is liable to be better by dint of the R-bit applying to individual prefi= xes - that is, the technique is "similar, and usually better", because the = R-bit provides a "more specific", or possibly "individual" indication of wh= ether a router is active. This may be wrong, in which case it's a perfect i= llustration of why it's confusing. We tried not to pass judgement as to which mechanism was better, since it d= epends on what the operator wants to do in the network: allow transit as a = last resort or not at all. We tried to say something about that in the 'De= ployment Consideration' section, but I do agree that we could make it clear= er. The use of 'granular' is specially confusing as the R-bit is used to i= ndicate whether the whole router is active (and should be used for transit)= or not, versus the MaxLinkMetric option which expects all the non-stub lin= ks to use it. I put some proposed text below. In it we're clarifying the text in 2.1 and= added a paragraph at the end of 4. Please let me know if this is still no= t clear. Thanks! Alvaro. 2.1. OSPFv3-only Solution OSPFv3 [RFC5340] introduced additional options to provide similar control of the forwarding topology; the R-bit provides an indication of whether a router is active and should be used for transit traffic. It is left to network operators to decide which technique to use in their network. See Section 4 for more details. .. 4. Deployment Considerations When using MaxLinkMetric, some inconsistency may be seen if the network is constructed of routers that perform intra-area Dijkstra calculation as specified in [RFC1247] (discarding link records in router-LSAs that have a MaxLinkMetric cost value) and routers that perform it as specified in [RFC1583] and higher (do not treat links with MaxLinkMetric cost as unreachable). Note that this inconsistency will not lead to routing loops, because if there are some alternate paths in the network, both types of routers will agree on using them rather than the path through the stub router. If the path through the stub router is the only one, the routers of the first type will not use the stub router for transit (which is the desired behavior), while the routers of the second type will still use this path. On the other hand, clearing the R-bit will consistently result in the router not being used as transit. The use of MaxLinkMetric or the R-bit in a network depends on the objectives of the operator. One of the possible considerations for selecting one or the other is in the desired behavior if the path through the stub router is the only one available. Using MaxLinkMetric allows for that path to be used, while the R-bit doesn't. --_000_3F74C1962631E14292BBF1B1B5F7021E1E2C1092BRN1WNEXMBX01vc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I like this text --thanks for putting this together, Alvaro.

:-)

Russ

From: Alvaro Retana (aretana) [aretana@ci= sco.com]
Sent: Tuesday, February 05, 2013 1:46 PM
To: Dave Cridland; draft-ietf-ospf-rfc3137bis.all@tools.ietf.org; ap= ps-discuss@ietf.org; iesg@ietf.org
Subject: Re: AppsDir Review of draft-ietf-ospf-rfc3137bis-03

On 2/2/13 9:09 PM, "Dave Cridland" <dave@cridland.net> wrote:

Dave:

First of all, thanks for the review!

..
Fo= r the most part this draft seems ready for publication, though I'm concerne= d it offers confusing guidance on which mechanism to use, and some wordsmit= hing is needed here.
De= tail:
= =A72.1 suggests it is a "similar, if not better" solution availab= le to OSPFv3 networks. It's not clear to me if this means "similar, an= d potentially better", or "similar, but not better". The second paragraph is also somewhat loose in whether this technique is recom= mended or not.
It= 's not clear to me if the portion following the semicolon is essentially sa= ying that the R-bit is superior; this is not helped by being unclear if &qu= ot;more granular" means finer or coarser. A quick trip to Wikipedia didn't help me, either, apparently it depends on= whether the R-bit is photographic, sugary, or something else.
My= guess, without looking at the OSPFv3 specification, is that this technique= is liable to be better by dint of the R-bit applying to individual prefixe= s - that is, the technique is "similar, and usually better", because the R-bit provides a "more specific= ", or possibly "individual" indication of whether a router i= s active. This may be wrong, in which case it's a perfect illustration of w= hy it's confusing.

We tried not to pass judgement as to which mechanism was better, since= it depends on what the operator wants to do in the network: allow transit = as a last resort or not at all.  We tried to say something about that in the 'Deployment Consideration' sectio= n, but I do agree that we could make it clearer.  The use of 'granular= ' is specially confusing as the R-bit is used to indicate whether the whole= router is active (and should be used for transit) or not, versus the MaxLinkMetric option which expects al= l the non-stub links to use it.

I put some proposed text below.  In it we're clarifying the text = in 2.1 and added a paragraph at the end of 4.  Please let me know if t= his is still not clear.

Thanks!

Alvaro.

=
2.1.  OSPFv3-only Solution
=
=0A=
   OSPFv3 [RFC5340] introduced additional options to provide similar =0A=
   control of the forwarding topology; the R-bit provides an indication =0A=
   of whether a router is active and should be used for transit traffic.=0A=
=0A=
   It is left to network operators to decide which technique to use in=0A=
   their network.  See Section 4 for more details.=0A=
=0A=
..=0A=
=0A=
4.  Deployment Considerations
=0A=
   When using MaxLinkMetric, some inconsistency may be seen if the=0A=
   network is constructed of routers that perform intra-area Dijkstra=0A=
   calculation as specified in [RFC1247] (discarding link records in=0A=
   router-LSAs that have a MaxLinkMetric cost value) and routers that=0A=
   perform it as specified in [RFC1583] and higher (do not treat links=0A=
   with MaxLinkMetric cost as unreachable).  Note that this=0A=
   inconsistency will not lead to routing loops, because if there are=0A=
   some alternate paths in the network, both types of routers will agree=0A=
   on using them rather than the path through the stub router.  If the=0A=
   path through the stub router is the only one, the routers of the=0A=
   first type will not use the stub router for transit (which is the=0A=
   desired behavior), while the routers of the second type will still=0A=
   use this path.=0A=
=0A=
   On the other hand, clearing the R-bit will consistently result in the=0A=
   router not being used as transit.=0A=
=0A=
   The use of MaxLinkMetric or the R-bit in a network depends on the =0A=
   objectives of the operator.  One of the possible considerations for =0A=
   selecting one or the other is in the desired behavior if the path =0A=
   through the stub router is the only one available.  Using MaxLinkMetric =
=0A=
   allows for that path to be used, while the R-bit doesn't.
--_000_3F74C1962631E14292BBF1B1B5F7021E1E2C1092BRN1WNEXMBX01vc_-- From sm@elandsys.com Wed Feb 6 15:45:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40AF21F85AE; Wed, 6 Feb 2013 15:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq0yHM+Sv6JK; Wed, 6 Feb 2013 15:45:00 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B5421F85A0; Wed, 6 Feb 2013 15:44:59 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.130.194]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r16Nijcc005892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2013 15:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360194298; bh=VJI6w1dlrApuMo5ay9WvzusnfT6H5uki3pIvtIX9qeY=; h=Date:To:From:Subject:Cc; b=Gv2NN/iSZOIx83yCJh4e56noahfxT0yUwpPTcyJMGZJHEGv/UU1hv+Zr0JQIYnvMT 9kZISqE/j3RLK3xal+o3XE3jMzxl+396855q6Xroja7yFWXOruRX0GVMY/28obbfW3 Srpg2aIpI+tdTp+GzU4eE810rk9ORYpgTXfOsMW8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1360194298; i=@elandsys.com; bh=VJI6w1dlrApuMo5ay9WvzusnfT6H5uki3pIvtIX9qeY=; h=Date:To:From:Subject:Cc; b=AdrdoWkEFkIXz2pnIoLsGt/L8oWjKK7crZYgY4fbU0XR7IfnlwH0nkc14afSkNTsD hRACxkzqCUwtsoborkjQOw85IFO1h3rbJnezKrMK3zKfJPGOBx+pJCh3MEuhtB2Vf3 unXjdp5Wpu2ia8fjhsRRmypI2VE8SnbkUBWVN7Zg= Message-Id: <6.2.5.6.2.20130206143103.0b18b460@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Feb 2013 15:41:35 -0800 To: apps-discuss@ietf.org, draft-harkins-brainpool-ike-groups.all@tools.ietf.org, Johannes Merkle From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-harkins-brainpool-ike-groups-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 23:45:02 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-harkins-brainpool-ike-groups-04 Title: Brainpool Elliptic Curves for the IKE Group Description Registry Reviewer: S. Moonesamy Review Date: February 6, 2013 IETF Last Call Date: January 31, 2013 Summary: This draft is almost ready for publication as an Informational RFC This memo allocates code points for four new elliptic curve domain parameter sets over finite prime fields into a registry that was established by The Internet Key Exchange (IKE) but is used by other protocols. One of the informational references mention that "the 224 bit curve brainpoolP224r1 and the 256 bit curve brainpoolP256r1 described below will be used in the new German machine readable travel documents (MRTDs) that follow ICAO technical reports". I did not verify the test vectors. I did not find any application considerations in the memo. Major issues: None Minor issues: In Section 4: "Implementations that desire to use the twisted curves internally MUST refer to [RFC5639] for the complete domain parameter sets, only the "twist" is defined here." I suggest using "must" and leaving it to RFC 5639 to specify the requirement. In Section 3: "These assigned values SHALL be identical to those being assigned to identical curves that are being added to a similar registry by [BPIKEV2]." I don't see a reason for a "SHALL" in the IANA Considerations Section. I suggest framing this as a request and removing the RFC 2119 boilerplate. The details can easily be worked out with IANA folks. "IANA is further instructed to update the "Group desription" portion of the [IANA-IKE] registry by appending Table 1 to the registry table and replace the words "this memo" (including the quotes) with a reference to the RFC number assigned to this memo." Typo: description. I read http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xml#ipsec-registry-9 I didn't understand the "not for RFC 2409" in Table 1 at first. I gather that this is about the administrative prohibition mentioned in Section 5. I suggest clarifying the note. Nits: These are editorial nits. I would move Section 5 before Section 3 as it makes the memo clearer to me. In Section 1: "[RFC5639] defines new elliptic curve domain parmaeters for curves" Typo: parameters In Section 2: Typo: arithmatical In Section 4: "discrete logarithm cryptography, for example elliptic curve" Typo: cryptography There is a typo for "Californaia". Regards, S. Moonesamy From jyee@afilias.info Thu Feb 7 07:09:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C02521F84C0 for ; Thu, 7 Feb 2013 07:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 3Z-g61sI08cx for ; Thu, 7 Feb 2013 07:09:37 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id E206321F84BB for ; Thu, 7 Feb 2013 07:09:36 -0800 (PST) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1U3T6V-0007w1-6N for apps-discuss@ietf.org; Thu, 07 Feb 2013 15:09:35 +0000 Received: from mail-oa0-f72.google.com ([209.85.219.72]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1U3T6V-0007Ul-5v for apps-discuss@ietf.org; Thu, 07 Feb 2013 15:09:35 +0000 Received: by mail-oa0-f72.google.com with SMTP id j6so13068764oag.3 for ; Thu, 07 Feb 2013 07:09:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=BdyJERAhnipNfOL1gxP5afl9kO+UOUbU31QJR67fTWI=; b=RM788qpGC/8XYmI5Xnden7j+zbAZ9mlFMRPF6sli9mGnw5FO80CCZN16FSaGDMRTH1 FQoHQc19iTZqLJzlq0HIWbCODnvg7bm5CbYgzIQMy5+azKGCMwFQC+RXLVyhmfn6+Ru3 fsURsWgW44q6iYs45qOC7lWV1wWNj5bRMkwt8CkPho69GQATCbfmmLNjimGEoQNGcorc dPhXCasDpZISG1fM7RIIpq/hDfKQ0c6QtFki7uBnM5zco47JKkbkJADft+e5zNP/qS6+ +mA937pZMp25fXkz6h/RFvs+2t+EJBg9WvJXGkBKtzBf/QfL2qCGcsDpjG+p8mFHXNMG LJ8g== X-Received: by 10.60.8.134 with SMTP id r6mr1258138oea.53.1360249770423; Thu, 07 Feb 2013 07:09:30 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.8.134 with SMTP id r6mr1258113oea.53.1360249770092; Thu, 07 Feb 2013 07:09:30 -0800 (PST) Received: by 10.76.109.39 with HTTP; Thu, 7 Feb 2013 07:09:29 -0800 (PST) In-Reply-To: <0DB8F45437AB844CBB5102F807A0AD931027A604@xmb-rcd-x03.cisco.com> References: <0DB8F45437AB844CBB5102F807A0AD931027A604@xmb-rcd-x03.cisco.com> Date: Thu, 7 Feb 2013 10:09:29 -0500 Message-ID: From: Joseph Yee To: "Luyuan Fang (lufang)" Content-Type: multipart/alternative; boundary=e89a8fb2024a5a293f04d523d49b X-Gm-Message-State: ALoCoQnGspPTiSUE+l+BwAhcGrGV4IPRbeo0tPEjYr/9k2+jhUO87x3AOJd/r3sNlegXvs9yWB7aCbRXvFvls8707twgTl05oJHtySgEVCpFY+NTBqDd4RvWWajuQFFmXpHaDT0JdjngUplyZe7Uav8fww1JYly2dg== Cc: "draft-ietf-mpls-tp-use-cases-and-design.all@tools.ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR Review of draft-ietf-mpls-tp-use-cases-and-design-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: Thu, 07 Feb 2013 15:09:38 -0000 --e89a8fb2024a5a293f04d523d49b Content-Type: text/plain; charset=UTF-8 Glad that you find the review helpful. I looked into the attached draft and it addressed all issues from the review. Cheers Joseph On Wed, Feb 6, 2013 at 10:51 PM, Luyuan Fang (lufang) wrote: > Hi Joseph, > > Thank you very much for your review and comments, really appreciate your > help! > I updated the document based on your comments (see in-line for details), > also acknowledged your review and comment in the doc. > > I attached the updated text file here. > > Thanks, > Luyuan > > > -----Original Message----- > From: Joseph Yee > Date: Wednesday, February 6, 2013 9:10 AM > To: "draft-ietf-mpls-tp-use-cases-and-design.all@tools.ietf.org" > , > "apps-discuss@ietf.org" > Subject: APPSDIR Review of draft-ietf-mpls-tp-use-cases-and-design-06.txt > Resent-From: > Resent-To: , , Luyuan Fang > , , Nabil Bitar > , , > , , > > Resent-Date: Wednesday, February 6, 2013 9:11 AM > > >I have been selected as the Applications Area Review Team reviewer for > >this draft (for background on apps-review, please see > >http://www.apps.ietf.org/content/applications-area-review-team). > > > >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-mpls-tp-use-cases-and-design-06 > >Title: MPLS-TP Applicability; Use Cases and Design > >Reviewer: Joseph Yee > >Review Date: Feb 6, 2013 > > > >Summary: This draft is ready for publication, would be better if the > >editorial changes can put into the draft. > > > >Major Issues: > >none > > > >Minor Issues: > >(1) "Applicability" in Abstract and Introduction > >"This document provides applicability, use case studies and network > >design considerations for the Multiprotocol Label Switching Transport > >Profile (MPLS-TP)." > > > >Mostly because of how my brain was wired (or how my high school > >teacher wired my brain). When I see text structured this way, I'm > >expecting three sections rather than two. Note I have no issues about > >the discussion of applicability in this draft at all. Then I realized > >more from how the title was written that it's a draft with two major > >topic sections rather than three. > > > >My suggestion for the text: > >"This document provides the applicability of Multiprotocol Label > >Switching Transport Profile (MPLS-TP) with use case studies and > >network design considerations." > > [luyuan] Yes, this is better, I replaced the old text with your suggested > text. > > > >(2) Section 1 Introduction 5th paragraph > >"LSP Ping Extension for on-demand CC-CV [RFC6426], fault allocation, > >and remote integrity check." > >"and switch-over triggering with Link Defect Indication (LDI)" > >Any reference for the 'fault allocation, and remote integrity check" > >and LDI that could be added to the draft? > > [luyuan] Good point. > > Reading through that paragraph again, I removed "fault allocation, and > remote integrity check." The tools for fault allocation and remote > integrity check are LSP Ping extension and LDI, and they are covered in > the text. > > > For LDI, I added reference [RFC6427]. > > > > >(3) Section 2 Terminology: 4G > >"4G 4th Generation Mobile network: LTE" > >This is close to nits. '4G' is not only LTE right? Do you mean to > >use 4G to refer only LTE is this draft? If the section title "4G/LTE > >Mobile Backhaul" and its text at section 3.3.2 does not confuse > >readers who is more familiar with the topic, I don't think this is an > >issue. > > [luyuan] You are right, 4G includes more than LTE. I removed LTE in the > terminology definition for 4G. > > > > > > >Nits: > >(1) Terminology through out the draft > >There are several occasions where acronyms were not logged in the > >terminology section (ex. PW), and some text don't use terminology > >consistently (ex. SP vs service provider). These are not the only > >two, but I think RFC Editors provides the best help in this regard. > > [luyuan] Added PW in the terminology. > I scanned through the doc, both "SP" and "Service Provider" are used, did > not see any lower case occasions. I think it is OK. Will work with RFC > editor if changes are needed. > > > > >(2) Section 7 Acknowledgements > >"... thank Stewart for his text contribution on timing ..." > >Stewart who? ;) > > [luyuan] Fixed, -> "Stewart Bryant". > > > >Best Regards, > >Joseph Yee > > Thanks, > Luyuan > > --e89a8fb2024a5a293f04d523d49b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Glad that you find the review helpful.=C2=A0 I looked into the attached dra= ft and it addressed all issues from the review.

Cheers
Joseph
=
On Wed, Feb 6, 2013 at 10:51 PM, Luyuan Fang= (lufang) <lufang@cisco.com> wrote:
Hi Joseph,

Thank you very much for your review and comments, really appreciate your help!
I updated the document based on your comments (see in-line for details), also acknowledged your review and comment in the doc.

I attached the updated text file here.

Thanks,
Luyuan


-----Original Message-----
From: Joseph Yee <jyee@afilias.info= >
Date: Wednesday, February 6, 2013 9:10 AM
To: "draft-ietf-mpls-tp-use-cases-and-design.all@tools.ietf.org= "
<draft-ietf-mpls-tp-use-cases-and-design.all@tools.ietf.org>,<= br> "apps-discuss@ietf.org&qu= ot; <apps-discuss@ietf.org&= gt;
Subject: APPSDIR Review of draft-ietf-mpls-tp-use-cases-and-design-06.txt Resent-From: <draf= t-alias-bounces@tools.ietf.org>
Resent-To: <afarrel@juniper.net>, <loa@pi.nu>, Luyuan Fang
<lufang@cisco.com>, <ms-daikoku@kddi.com>, Nabil Bitar<= br> <nabil.bitar@verizon.com&= gt;, <ppan@infinera.com>, <raymond.zhang@alcat= el-lucent.com>, <rcallon@j= uniper.net>,
<swallow@cisco.com>
Resent-Date: Wednesday, February 6, 2013 9:11 AM

>I have been selected as the Applications Area Review Team reviewer for<= br> >this draft (for background on apps-review, please see
>http://www.apps.ietf.org/content/applications-area-re= view-team).
>
>Please resolve these comments along with any other Last Call comments >you may receive. Please wait for direction from your document shepherd<= br> >or AD before posting a new version of the draft.
>
>Document: draft-ietf-mpls-tp-use-cases-and-design-06
>Title: MPLS-TP Applicability; Use Cases and Design
>Reviewer: Joseph Yee
>Review Date: Feb 6, 2013
>
>Summary: This draft is ready for publication, would be better if the >editorial changes can put into the draft.
>
>Major Issues:
>none
>
>Minor Issues:
>(1) "Applicability" in Abstract and Introduction
>"This document provides applicability, use case studies and networ= k
>design considerations for the Multiprotocol Label Switching Transport >Profile (MPLS-TP)."
>
>Mostly because of how my brain was wired (or how my high school
>teacher wired my brain). When I see text structured this way, I'm >expecting three sections rather than two. =C2=A0Note I have no issues a= bout
>the discussion of applicability in this draft at all. =C2=A0Then I real= ized
>more from how the title was written that it's a draft with two majo= r
>topic sections rather than three.
>
>My suggestion for the text:
>"This document provides the applicability of Multiprotocol Label >Switching Transport Profile (MPLS-TP) with use case studies and
>network design considerations."

[luyuan] Yes, this is better, I replaced the old text with your= suggested
text.
>
>(2) Section 1 Introduction 5th paragraph
>"LSP Ping Extension for on-demand CC-CV [RFC6426], fault allocatio= n,
>and remote integrity check."
>"and switch-over triggering with Link Defect Indication (LDI)"= ;
>Any reference for the 'fault allocation, and remote integrity check= "
>and LDI that could be added to the draft?

[luyuan] Good point.

Reading through that paragraph again, I removed "fault allocation, and=
remote integrity check." The tools for fault allocation and remote
integrity check are LSP Ping extension and LDI, and they are covered in
the text.


For LDI, I added reference [RFC6427].

>
>(3) Section 2 Terminology: 4G
>"4G =C2=A0 =C2=A0 =C2=A0 4th Generation Mobile network: LTE"<= br> >This is close to nits. =C2=A0'4G' is not only LTE right? =C2=A0= Do you mean to
>use 4G to refer only LTE is this draft? =C2=A0If the section title &quo= t;4G/LTE
>Mobile Backhaul" and its text at section 3.3.2 does not confuse >readers who is more familiar with the topic, I don't think this is = an
>issue.

[luyuan] You are right, 4G includes more than LTE. I removed LTE in t= he
terminology definition for 4G.

>
>
>Nits:
>(1) Terminology through out the draft
>There are several occasions where acronyms were not logged in the
>terminology section (ex. PW), and some text don't use terminology >consistently (ex. SP vs service provider). =C2=A0These are not the only=
>two, but I think RFC Editors provides the best help in this regard.

[luyuan] Added PW in the terminology.
I scanned through the doc, both "SP" and "Service Provider&q= uot; are used, did
not see any lower case occasions. I think it is OK. Will work with RFC
editor if changes are needed.

>
>(2) Section 7 Acknowledgements
>"... =C2=A0thank Stewart for his text contribution on timing ...&q= uot;
>Stewart who? =C2=A0;)

[luyuan] Fixed, -> "Stewart Bryant".
>
>Best Regards,
>Joseph Yee

Thanks,
Luyuan


--e89a8fb2024a5a293f04d523d49b-- From lufang@cisco.com Wed Feb 6 19:51:31 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F5921F844E for ; Wed, 6 Feb 2013 19:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.589 X-Spam-Level: X-Spam-Status: No, score=-8.589 tagged_above=-999 required=5 tests=[AWL=-1.490, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_24=0.6, MANGLED_MEDS=2.3, 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 Ry6gJ82sGLJA for ; Wed, 6 Feb 2013 19:51:25 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5649E21F844C for ; Wed, 6 Feb 2013 19:51:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53972; q=dns/txt; s=iport; t=1360209080; x=1361418680; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=LzvNQ4/i6ylLAhntccryL6MYURF5PbqlFBRnlJ1zF6w=; b=imxcm6e/E/7LxaL9VGPc6FeZrDE+M7Aq6CanTTUqbS5kqDHejzxImHlz LIXsWeoAcjmNs0q0E60HxM1++n1Aa6Y4MlNKefsfCfW2wNLkXUA9DDy+6 0B3AlZmMpiOETcIvGOVLiFBCCIUyv2udD8eo5ddFVnDKNcIXR0fW6OpHx s=; X-Files: draft-ietf-mpls-tp-use-cases-and-design-07.txt : 35575 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGcjE1GtJXG8/2dsb2JhbABFwFAWc4IfAQEBBBoBDEAFCBEGAQgOAwECAQILJjAXBggCBAEJCQgBBQsCAYdjAw8MvG2MFHILChODSmEDjxODVYRWiiWFEIJ+gWYCBxce X-IronPort-AV: E=Sophos;i="4.84,619,1355097600"; d="txt'?scan'208";a="171295345" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 07 Feb 2013 03:51:19 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r173pJa3011858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Feb 2013 03:51:19 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 6 Feb 2013 21:51:19 -0600 From: "Luyuan Fang (lufang)" To: Joseph Yee , "draft-ietf-mpls-tp-use-cases-and-design.all@tools.ietf.org" , "apps-discuss@ietf.org" Thread-Topic: APPSDIR Review of draft-ietf-mpls-tp-use-cases-and-design-06.txt Thread-Index: AQHOBIz4g7lcjevZhEOi+pLg+lOtVJht1GqA Date: Thu, 7 Feb 2013 03:51:18 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD931027A604@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.82.213.2] Content-Type: multipart/mixed; boundary="_002_0DB8F45437AB844CBB5102F807A0AD931027A604xmbrcdx03ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 07 Feb 2013 15:07:36 -0800 Subject: Re: [apps-discuss] APPSDIR Review of draft-ietf-mpls-tp-use-cases-and-design-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: Thu, 07 Feb 2013 03:51:31 -0000 --_002_0DB8F45437AB844CBB5102F807A0AD931027A604xmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Joseph, Thank you very much for your review and comments, really appreciate your help! I updated the document based on your comments (see in-line for details), also acknowledged your review and comment in the doc. I attached the updated text file here. Thanks, Luyuan -----Original Message----- From: Joseph Yee Date: Wednesday, February 6, 2013 9:10 AM To: "draft-ietf-mpls-tp-use-cases-and-design.all@tools.ietf.org" , "apps-discuss@ietf.org" Subject: APPSDIR Review of draft-ietf-mpls-tp-use-cases-and-design-06.txt Resent-From: Resent-To: , , Luyuan Fang , , Nabil Bitar , , , , Resent-Date: Wednesday, February 6, 2013 9:11 AM >I have been selected as the Applications Area Review Team reviewer for >this draft (for background on apps-review, please see >http://www.apps.ietf.org/content/applications-area-review-team). > >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-mpls-tp-use-cases-and-design-06 >Title: MPLS-TP Applicability; Use Cases and Design >Reviewer: Joseph Yee >Review Date: Feb 6, 2013 > >Summary: This draft is ready for publication, would be better if the >editorial changes can put into the draft. > >Major Issues: >none > >Minor Issues: >(1) "Applicability" in Abstract and Introduction >"This document provides applicability, use case studies and network >design considerations for the Multiprotocol Label Switching Transport >Profile (MPLS-TP)." > >Mostly because of how my brain was wired (or how my high school >teacher wired my brain). When I see text structured this way, I'm >expecting three sections rather than two. Note I have no issues about >the discussion of applicability in this draft at all. Then I realized >more from how the title was written that it's a draft with two major >topic sections rather than three. > >My suggestion for the text: >"This document provides the applicability of Multiprotocol Label >Switching Transport Profile (MPLS-TP) with use case studies and >network design considerations." [luyuan] Yes, this is better, I replaced the old text with your suggested text. > >(2) Section 1 Introduction 5th paragraph >"LSP Ping Extension for on-demand CC-CV [RFC6426], fault allocation, >and remote integrity check." >"and switch-over triggering with Link Defect Indication (LDI)" >Any reference for the 'fault allocation, and remote integrity check" >and LDI that could be added to the draft? [luyuan] Good point. =20 Reading through that paragraph again, I removed "fault allocation, and remote integrity check." The tools for fault allocation and remote integrity check are LSP Ping extension and LDI, and they are covered in the text. =20 For LDI, I added reference [RFC6427]. > >(3) Section 2 Terminology: 4G >"4G 4th Generation Mobile network: LTE" >This is close to nits. '4G' is not only LTE right? Do you mean to >use 4G to refer only LTE is this draft? If the section title "4G/LTE >Mobile Backhaul" and its text at section 3.3.2 does not confuse >readers who is more familiar with the topic, I don't think this is an >issue. [luyuan] You are right, 4G includes more than LTE. I removed LTE in the terminology definition for 4G. > > >Nits: >(1) Terminology through out the draft >There are several occasions where acronyms were not logged in the >terminology section (ex. PW), and some text don't use terminology >consistently (ex. SP vs service provider). These are not the only >two, but I think RFC Editors provides the best help in this regard. [luyuan] Added PW in the terminology. I scanned through the doc, both "SP" and "Service Provider" are used, did not see any lower case occasions. I think it is OK. Will work with RFC editor if changes are needed. > >(2) Section 7 Acknowledgements >"... thank Stewart for his text contribution on timing ..." >Stewart who? ;) [luyuan] Fixed, -> "Stewart Bryant". > >Best Regards, >Joseph Yee Thanks, Luyuan --_002_0DB8F45437AB844CBB5102F807A0AD931027A604xmbrcdx03ciscoc_ Content-Type: text/plain; name="draft-ietf-mpls-tp-use-cases-and-design-07.txt" Content-Description: draft-ietf-mpls-tp-use-cases-and-design-07.txt Content-Disposition: attachment; filename="draft-ietf-mpls-tp-use-cases-and-design-07.txt"; size=35575; creation-date="Thu, 07 Feb 2013 03:51:17 GMT"; modification-date="Thu, 07 Feb 2013 03:51:17 GMT" Content-ID: <0A2C5AFABD7FA24B973BAB0946426E24@cisco.com> Content-Transfer-Encoding: base64 IA0KDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTC4gRmFuZywgRWQuDQpJbnRlbmRlZCBTdGF0dXM6IEluZm9ybWF0aW9uYWwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2lzY28NCkV4cGlyZXM6IEF1Z3Vl c3QgNiwgMjAxMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOLiBCaXRh cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBWZXJpem9uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgUi4gWmhhbmcNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbGNhdGVsIEx1Y2VudA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBNLiBEYWlrb2t1DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEtEREkNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFAuIFBhbg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElu ZmluZXJhDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgRmVicnVhcnkgNiwgMjAxMw0KDQoNCiAgICAgICAgICAgICBNUExTLVRQIEFwcGxp Y2FiaWxpdHk7IFVzZSBDYXNlcyBhbmQgRGVzaWduICANCiAgICAgICAgICAgICBkcmFmdC1pZXRm LW1wbHMtdHAtdXNlLWNhc2VzLWFuZC1kZXNpZ24tMDcudHh0DQoNCkFic3RyYWN0DQoNCiAgIFRo aXMgZG9jdW1lbnQgcHJvdmlkZXMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgTXVsdGlwcm90b2NvbCBM YWJlbA0KICAgU3dpdGNoaW5nIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSB3aXRoIHVzZSBj YXNlIHN0dWRpZXMgYW5kDQogICBuZXR3b3JrIGRlc2lnbiBjb25zaWRlcmF0aW9ucy4gVGhlIHVz ZSBjYXNlcyBpbmNsdWRlIE1ldHJvIEV0aGVybmV0DQogICBhY2Nlc3MgYW5kIGFnZ3JlZ2F0aW9u IHRyYW5zcG9ydCwgTW9iaWxlIGJhY2toYXVsLCBhbmQgcGFja2V0IG9wdGljYWwNCiAgIHRyYW5z cG9ydC4NCg0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQg aXMgc3VibWl0dGVkIHRvIElFVEYgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQ0KICAgcHJv dmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3 b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9y Y2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQN CiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFz DQogICBJbnRlcm5ldC1EcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9j dW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1 cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkN CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMg cmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29y ayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRz IGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy8xaWQtYWJzdHJhY3Rz Lmh0bWwNCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVz IGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0K DQoNCiANCg0KDQpGYW5nIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNiwgMjAx MyAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCklOVEVSTkVUIERSQUZUICAgICAgICBNUExT LVRQIFVzZSBDYXNlcyBhbmQgRGVzaWduICAgICAgRmVicnVhcnkgNiwgMjAxMw0KDQoNCkNvcHly aWdodCBhbmQgTGljZW5zZSBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChjKSAyMDEzIElFVEYgVHJ1 c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDQogICBkb2N1bWVudCBhdXRob3Jz LiBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8g QkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsDQogICBQcm92aXNpb25zIFJlbGF0aW5n IHRvIElFVEYgRG9jdW1lbnRzDQogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1p bmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YNCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9j dW1lbnQuIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQogICBjYXJlZnVsbHksIGFzIHRo ZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QNCiAg IHRvIHRoaXMgZG9jdW1lbnQuIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRv Y3VtZW50IG11c3QNCiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZg0KICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMg YW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzDQogICBkZXNjcmliZWQgaW4gdGhl IFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQoNCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4g SW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAzDQogICAyLiBUZXJtaW5vbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgIDMuIE1QTFMtVFAgVXNlIENhc2VzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgICAzLjEuIE1l dHJvIEFjY2VzcyBhbmQgQWdncmVnYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA1DQogICAgIDMuMi4gUGFja2V0IE9wdGljYWwgVHJhbnNwb3J0ICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgICAgMy4zLiBNb2JpbGUgQmFja2hhdWwgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgICAgIDMuMy4xLiAyRyBh bmQgM0cgTW9iaWxlIEJhY2toYXVsIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQog ICAgICAgMy4zLjIuIDRHL0xURSBNb2JpbGUgQmFja2hhdWwgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDgNCiAgIDQuIE5ldHdvcmsgRGVzaWduIENvbnNpZGVyYXRpb25zIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgICA0LjEuIFRoZSByb2xlIG9mIE1Q TFMtVFAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICAgIDQu Mi4gUHJvdmlzaW9uaW5nIG1vZGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDkNCiAgICAgNC4zLiBTdGFuZGFyZHMgY29tcGxpYW5jZSAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgICA0LjQuIEVuZC10by1lbmQgTVBMUyBPQU0g Y29uc2lzdGVuY3kgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwDQogICAgIDQuNS4gUFcg RGVzaWduIGNvbnNpZGVyYXRpb25zIGluIE1QTFMtVFAgbmV0d29ya3MgIC4gLiAuIC4gLiAuIC4g MTANCiAgICAgNC42LiBQcm9hY3RpdmUgYW5kIG9uLWRlbWFuZCBNUExTLVRQIE9BTSB0b29scyAu IC4gLiAuIC4gLiAuIC4gLiAxMQ0KICAgICA0LjcuIE1QTFMtVFAgYW5kIElQL01QTFMgSW50ZXJ3 b3JraW5nIGNvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIDExDQogICA1LiBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTENCiAg IDYuIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxMg0KICAgNy4gQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyDQogICA4LiBSZWZlcmVuY2VzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTINCiAgICAgOC4x LiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxMg0KICAgICA4LjIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDQogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMNCiAgIENvbnRyaWJ1dG9y cycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx NA0KDQoNCg0KDQoNCg0KIA0KDQoNCkZhbmcgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIEF1 Z3VzdCA2LCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSU5URVJORVQgRFJBRlQg ICAgICAgIE1QTFMtVFAgVXNlIENhc2VzIGFuZCBEZXNpZ24gICAgICBGZWJydWFyeSA2LCAyMDEz DQoNCg0KMS4gSW50cm9kdWN0aW9uDQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYXBwbGlj YWJpbGl0eSwgdXNlIGNhc2Ugc3R1ZGllcyBhbmQgbmV0d29yaw0KICAgZGVzaWduIGNvbnNpZGVy YXRpb25zIGZvciB0aGUgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgVHJhbnNwb3J0DQog ICBQcm9maWxlIChNUExTLVRQKS4gDQoNCiAgIEluIHJlY2VudCB5ZWFycywgdGhlIHVyZ2VuY3kg Zm9yIG1vdmluZyBmcm9tIHRyYWRpdGlvbmFsIHRyYW5zcG9ydA0KICAgdGVjaG5vbG9naWVzLCBz dWNoIGFzIFNPTkVUL1NESCwgVERNLCBhbmQgQVRNLCB0byBuZXcgcGFja2V0DQogICB0ZWNobm9s b2dpZXMgaGFzIGJlZW4gcmlzaW5nLiBUaGlzIGlzIGxhcmdlbHkgZHVlIHRvIHRoZSBmYXN0IGdy b3dpbmcNCiAgIGRlbWFuZCBmb3IgYmFuZHdpZHRoLCB3aGljaCBoYXMgYmVlbiBmdWVsZWQgYnkg dGhlIGZvbGxvd2luZyBmYWN0b3JzOg0KICAgMSkgVGhlIGdyb3d0aCBvZiBuZXcgc2VydmljZXMu IFRoaXMgaW5jbHVkZXM6IHRoZSB0cmVtZW5kb3VzIHN1Y2Nlc3MNCiAgIG9mIGRhdGEgc2Vydmlj ZXMsIHN1Y2ggYXMgSVBUViBhbmQgSVAgVmlkZW8gZm9yIGNvbnRlbnQgZG93bmxvYWRpbmcsDQog ICBzdHJlYW1pbmcsIGFuZCBzaGFyaW5nOyB0aGUgcmFwaWQgZ3Jvd3RoIG9mIG1vYmlsZSBzZXJ2 aWNlcywgYXMgYQ0KICAgY29uc2VxdWVuY2Ugb2YgdGhlIGV4cGxvc2lvbiBvZiBzbWFydCBwaG9u ZSBhcHBsaWNhdGlvbnM7IHRoZQ0KICAgY29udGludWVkIGdyb3d0aCBvZiBidXNpbmVzcyBWUE5z IGFuZCByZXNpZGVudGlhbCBicm9hZGJhbmQgc2VydmljZXMuDQogICAyKSBOZXR3b3JrIGluZnJh c3RydWN0dXJlIGV2b2x1dGlvbi4gQXMgbWFueSBsZWdhY3kgdHJhbnNwb3J0IGRldmljZXMNCiAg IGFyZSBhcHByb2FjaGluZyBlbmQgb2YgbGlmZSwgU2VydmljZSBQcm92aWRlcnMgdHJhbnNpdGlv biB0byBuZXcNCiAgIHBhY2tldCB0ZWNobm9sb2dpZXMgYW5kIGV2b2x2ZSB0aGVpciB0cmFuc3Bv cnQgbmV0d29yayBpbnRvIHRoZSBuZXh0DQogICBnZW5lcmF0aW9uIHBhY2tldCB0cmFuc3BvcnQu IA0KDQogICBBcyBwYXJ0IG9mIE1QTFMgZmFtaWx5LCBNUExTLVRQIGNvbXBsZW1lbnRzIGV4aXN0 aW5nIElQL01QTFMNCiAgIHRlY2hub2xvZ2llczsgaXQgY2xvc2VzIHRoZSBnYXBzIGluIHRoZSB0 cmFkaXRpb25hbCBhY2Nlc3MgYW5kDQogICBhZ2dyZWdhdGlvbiB0cmFuc3BvcnQgdG8gZW5hYmxl IGVuZC10by1lbmQgcGFja2V0IHRlY2hub2xvZ3kNCiAgIHNvbHV0aW9ucyBpbiBhIGNvc3QgZWZm aWNpZW50LCByZWxpYWJsZSwgYW5kIGludGVyb3BlcmFibGUgbWFubmVyLg0KICAgQWZ0ZXIgc2V2 ZXJhbCB5ZWFycyBvZiBpbmR1c3RyeSBkZWJhdGUgb24gd2hpY2ggcGFja2V0IHRlY2hub2xvZ3kg dG8NCiAgIHVzZSwgTVBMUy1UUCBoYXMgZW1lcmdlZCBhcyB0aGUgbmV4dCBnZW5lcmF0aW9uIHRy YW5zcG9ydCB0ZWNobm9sb2d5DQogICBvZiBjaG9pY2UgZm9yIG1hbnkgU2VydmljZSBQcm92aWRl cnMgd29ybGR3aWRlLiANCg0KICAgVGhlIFVuaWZpZWQgTVBMUyBzdHJhdGVneSAtIHVzaW5nIE1Q TFMgZnJvbSBjb3JlIHRvIGFnZ3JlZ2F0aW9uIGFuZA0KICAgYWNjZXNzIChlLmcuIElQL01QTFMg aW4gdGhlIGNvcmUsIElQL01QTFMgb3IgTVBMUy1UUCBpbiBhZ2dyZWdhdGlvbg0KICAgYW5kIGFj Y2VzcykgYXBwZWFyIHRvIGJlIHZlcnkgYXR0cmFjdGl2ZSB0byBtYW55IFNQcy4gSXQgc3RyZWFt bGluZXMNCiAgIHRoZSBvcGVyYXRpb24sIHJlZHVjZXMgdGhlIG92ZXJhbGwgY29tcGxleGl0eSwg YW5kIGltcHJvdmVzIGVuZC10by0NCiAgIGVuZCBjb252ZXJnZW5jZS4gSXQgbGV2ZXJhZ2VzIHRo ZSBNUExTIGV4cGVyaWVuY2UsIGFuZCBlbmhhbmNlcyB0aGUNCiAgIGFiaWxpdHkgdG8gc3VwcG9y dCByZXZlbnVlIGdlbmVyYXRpbmcgc2VydmljZXMuDQoNCiAgIE1QTFMtVFAgaXMgYSBzdWJzZXQg b2YgTVBMUyBmdW5jdGlvbnMgdGhhdCBtZWV0IHRoZSBwYWNrZXQgdHJhbnNwb3J0DQogICByZXF1 aXJlbWVudHMgZGVmaW5lZCBpbiBbUkZDNTY1NF0uIFRoaXMgc3Vic2V0IGluY2x1ZGVzOiBNUExT IGRhdGENCiAgIGZvcndhcmRpbmcsIHBzZXVkby13aXJlIGVuY2Fwc3VsYXRpb24gZm9yIGNpcmN1 aXQgZW11bGF0aW9uLCBhbmQNCiAgIGR5bmFtaWMgY29udHJvbCBwbGFuZSB1c2luZyBHTVBMUyBj b250cm9sIGZvciBMU1AgYW5kIHRMRFAgZm9yDQogICBwc2V1ZG8td2lyZSAoUFcpLiBNUExTLVRQ IGFsc28gZXh0ZW5kcyBwcmV2aW91cyBNUExTIE9BTSBmdW5jdGlvbnMsDQogICBzdWNoIGFzIEJG RCBleHRlbnNpb24gZm9yIHByb2FjdGl2ZSBDb25uZWN0aXZpdHkgQ2hlY2sgYW5kDQogICBDb25u ZWN0aXZpdHkgVmVyaWZpY2F0aW9uIChDQy1DVikgW1JGQzY0MjhdLCBhbmQgUmVtb3RlIERlZmVj dA0KICAgSW5kaWNhdGlvbiAoUkRJKSBbUkZDNjQyOF0sIExTUCBQaW5nIEV4dGVuc2lvbiBmb3Ig b24tZGVtYW5kIENDLUNWDQogICBbUkZDNjQyNl0uIE5ldyB0b29scyBoYXZlIGJlZW4gZGVmaW5l ZCBmb3IgYWxhcm0gc3VwcHJlc3Npb24gd2l0aA0KICAgQWxhcm0gSW5kaWNhdGlvbiBTaWduYWwg KEFJUykgW1JGQzY0MjddLCBhbmQgc3dpdGNoLW92ZXIgdHJpZ2dlcmluZw0KICAgd2l0aCBMaW5r IERlZmVjdCBJbmRpY2F0aW9uIChMREkpIFtSRkM2NDI3XS4gTm90ZSB0aGF0IHNpbmNlIHRoZSBN UExTDQogICBPQU0gZmVhdHVyZSBleHRlbnNpb25zIGRlZmluZWQgdGhyb3VnaCB0aGUgcHJvY2Vz cyBvZiBNUExTLVRQDQogICBkZXZlbG9wbWVudCBhcmUgcGFydCBvZiB0aGUgTVBMUyBmYW1pbHks IHRoZSBhcHBsaWNhYmlsaXR5IGlzIGdlbmVyYWwNCiANCg0KDQpGYW5nIGV0IGFsLiAgICAgICAg ICAgICAgRXhwaXJlcyBBdWd1c3QgNiwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwN CklOVEVSTkVUIERSQUZUICAgICAgICBNUExTLVRQIFVzZSBDYXNlcyBhbmQgRGVzaWduICAgICAg RmVicnVhcnkgNiwgMjAxMw0KDQoNCiAgIHRvIE1QTFMsIGFuZCBub3QgbGltaXRlZCB0byBNUExT LVRQLg0KDQogICBUaGUgcmVxdWlyZW1lbnRzIG9mIE1QTFMtVFAgYXJlIHByb3ZpZGVkIGluIE1Q TFMtVFAgUmVxdWlyZW1lbnRzIFtSRkMNCiAgIDU2NTRdLCBhbmQgdGhlIGFyY2hpdGVjdHVyYWwg ZnJhbWV3b3JrIGlzIGRlZmluZWQgaW4gTVBMUy1UUA0KICAgRnJhbWV3b3JrIFtSRkM1OTIxXS4g VGhpcyBkb2N1bWVudCdzIGludGVudCBpcyB0byBwcm92aWRlIHRoZSB1c2UNCiAgIGNhc2Ugc3R1 ZGllcyBhbmQgZGVzaWduIGNvbnNpZGVyYXRpb25zIGZyb20gYSBwcmFjdGljYWwgcG9pbnQgb2Yg dmlldw0KICAgYmFzZWQgb24gU2VydmljZSBQcm92aWRlcnMgZGVwbG95bWVudHMgcGxhbiBhcyB3 ZWxsIGFzIGFjdHVhbA0KICAgZGVwbG95bWVudHMuDQoNCiAgIFRoZSBtb3N0IGNvbW1vbiB1c2Ug Y2FzZXMgZm9yIE1QTFMtVFAgaW5jbHVkZSBNZXRybyBhY2Nlc3MgYW5kDQogICBhZ2dyZWdhdGlv biwgTW9iaWxlIEJhY2toYXVsLCBhbmQgUGFja2V0IE9wdGljYWwgVHJhbnNwb3J0LiBNUExTLVRQ DQogICBkYXRhIHBsYW5lIGFyY2hpdGVjdHVyZSwgcGF0aCBwcm90ZWN0aW9uIG1lY2hhbmlzbXMs IGFuZCBPQU0NCiAgIGZ1bmN0aW9uYWxpdHkgYXJlIHVzZWQgdG8gc3VwcG9ydCB0aGVzZSBkZXBs b3ltZW50IHNjZW5hcmlvcy4gDQoNCiAgIFRoZSBkZXNpZ24gY29uc2lkZXJhdGlvbnMgZGlzY3Vz c2VkIGluIHRoaXMgZG9jdW1lbnQgaW5jbHVkZTogdGhlDQogICByb2xlIG9mIE1QTFMtVFAgaW4g dGhlIG5ldHdvcms7IHByb3Zpc2lvbmluZyBvcHRpb25zOyBzdGFuZGFyZHMNCiAgIGNvbXBsaWFu Y2U7IGVuZC10by1lbmQgZm9yd2FyZGluZyBhbmQgT0FNIGNvbnNpc3RlbmN5OyBjb21wYXRpYmls aXR5DQogICB3aXRoIGV4aXN0aW5nIElQL01QTFMgbmV0d29ya3M7IGFuZCBvcHRpbWl6YXRpb24g dnMuIHNpbXBsaWNpdHkNCiAgIGRlc2lnbiB0cmFkZS1vZmZzLg0KDQoyLiBUZXJtaW5vbG9neQ0K DQogICAgICBUZXJtICAgICBEZWZpbml0aW9uDQogICAgICAtLS0tLS0gICAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICAgMkcgICAg ICAgMm5kIGdlbmVyYXRpb24gd2lyZWxlc3MgdGVsZXBob25lIHRlY2hub2xvZ3kgDQogICAgICAz RyAgICAgICAzcmQgZ2VuZXJhdGlvbiBvZiBtb2JpbGUgdGVsZWNvbW11bmljYXRpb25zIHRlY2hu b2xvZ3kNCiAgICAgIDRHICAgICAgIDR0aCBHZW5lcmF0aW9uIE1vYmlsZSBuZXR3b3JrIA0KICAg ICAgQURTTCAgICAgQXN5bW1ldHJpYyBEaWdpdGFsIFN1YnNjcmliZXIgTGluZSANCiAgICAgIEFJ UyAgICAgIEFsYXJtIEluZGljYXRpb24gU2lnbmFsDQogICAgICBBU05HVyAgICBBY2Nlc3MgU2Vy dmljZSBOZXR3b3JrIEdhdGV3YXkNCiAgICAgIEFUTSAgICAgIEFzeW5jaHJvbm91cyBUcmFuc2Zl ciBNb2RlDQogICAgICBCRkQgICAgICBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9u DQogICAgICBCVFMgICAgICBCYXNlIFRyYW5zY2VpdmVyIFN0YXRpb24NCiAgICAgIENDLUNWICAg IENvbnRpbnVpdHkgQ2hlY2sgYW5kIENvbm5lY3Rpdml0eSBWZXJpZmljYXRpb24NCiAgICAgIENE TUEgICAgIENvZGUgRGl2aXNpb24gTXVsdGlwbGUgQWNjZXNzDQogICAgICBFLUxJTkUgICBFdGhl cm5ldCBwb2ludC10by1wb2ludCBjb25uZWN0aXZpdHkNCiAgICAgIEUtTEFOICAgIEV0aGVybmV0 IExBTiwgcHJvdmlkZXMgbXVsdGlwb2ludCBjb25uZWN0aXZpdHkNCiAgICAgIGVOQiAgICAgIEV2 b2x2ZWQgTm9kZSBCDQogICAgICBFUEMgICAgICBFdm9sdmVkIFBhY2tldCBDb3JlDQogICAgICBF LVZMQU4gICBFdGhlcm5ldCBWaXJ0dWFsIFByaXZhdGUgTEFODQogICAgICBFVkRPICAgICBFdm9s dXRpb24tRGF0YSBPcHRpbWl6ZWQgDQogICAgICBHLUFDaCAgICBHZW5lcmljIEFzc29jaWF0ZWQg Q2hhbm5lbA0KICAgICAgR0FMICAgICAgRy1BQ2ggTGFiZWwNCiAgICAgIEdNUExTICAgIEdlbmVy YWxpemVkIE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRjaGluZw0KICAgICAgR1NNICAgICAgR2xv YmFsIFN5c3RlbSBmb3IgTW9iaWxlIENvbW11bmljYXRpb25zDQogICAgICBIU1BBICAgICBIaWdo IFNwZWVkIFBhY2tldCBBY2Nlc3MNCiAgICAgIElQVFYgICAgIEludGVybmV0IFByb3RvY29sIHRl bGV2aXNpb24NCiAgICAgIEwyVlBOICAgIExheWVyIDIgVmlydHVhbCBQcml2YXRlIE5ldHdvcmsN CiANCg0KDQpGYW5nIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNiwgMjAxMyAg ICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCklOVEVSTkVUIERSQUZUICAgICAgICBNUExTLVRQ IFVzZSBDYXNlcyBhbmQgRGVzaWduICAgICAgRmVicnVhcnkgNiwgMjAxMw0KDQoNCiAgICAgIEwz VlBOICAgIExheWVyIDMgVmlydHVhbCBQcml2YXRlIE5ldHdvcmsNCiAgICAgIExBTiAgICAgIExv Y2FsIEFjY2VzcyBOZXR3b3JrDQogICAgICBMREkgICAgICBMaW5rIERvd24gSW5kaWNhdGlvbg0K ICAgICAgTERQICAgICAgTGFiZWwgRGlzdHJpYnV0aW9uIFByb3RvY29sDQogICAgICBMU1AgICAg ICBMYWJlbCBTd2l0Y2hlZCBQYXRoDQogICAgICBMVEUgICAgICBMb25nIFRlcm0gRXZvbHV0aW9u DQogICAgICBNRVAgICAgICBNYWludGVuYW5jZSBFbnRpdHkgR3JvdXAgRW5kIFBvaW50DQogICAg ICBNSVAgICAgICBNYWludGVuYW5jZSBFbnRpdHkgR3JvdXAgSW50ZXJtZWRpYXRlIFBvaW50DQog ICAgICBOTVMgICAgICBOZXR3b3JrIE1hbmFnZW1lbnQgU3lzdGVtDQogICAgICBNUExTICAgICBN dWx0aVByb3RvY29sIExhYmVsIFN3aXRjaGluZw0KICAgICAgTVBMUy1UUCAgTXVsdGlQcm90b2Nv bCBMYWJlbCBTd2l0Y2hpbmcgVHJhbnNwb3J0IFByb2ZpbGUNCiAgICAgIE1TLVBXICAgIE11bHRp LVNlZ21lbnQgUHNldWRvd2lyZQ0KICAgICAgT0FNICAgICAgT3BlcmF0aW9ucywgQWRtaW5pc3Ry YXRpb24sIGFuZCBNYWludGVuYW5jZQ0KICAgICAgT1BFWCAgICAgT3BlcmF0aW5nIEV4cGVuc2Vz DQogICAgICBQRSAgICAgICBQcm92aWRlci1FZGdlIGRldmljZQ0KICAgICAgUFNXICAgICAgUGFj a2V0IERhdGEgTmV0d29yayBHYXRld2F5DQogICAgICBQVyAgICAgICBQc2V1ZG93aXJlDQogICAg ICBSQU4gICAgICBSYWRpbyBBY2Nlc3MgTmV0d29yaw0KICAgICAgUkRJICAgICAgUmVtb3RlIERl ZmVjdCBJbmRpY2F0aW9uDQogICAgICBTMSAgICAgICBMVEUgU3RhbmRhcmRpemVkIGludGVyZmFj ZSBiZXR3ZWVuIGVOQiBhbmQgRVBDIA0KICAgICAgU0RIICAgICAgU3luY2hyb25vdXMgRGlnaXRh bCBIaWVyYXJjaHkNCiAgICAgIFNHVyAgICAgIFNlcnZpbmcgR2F0ZXdheQ0KICAgICAgU0xBICAg ICAgU2VydmljZSBMZXZlbCBBZ3JlZW1lbnQNCiAgICAgIFNPTkVUICAgIFN5bmNocm9ub3VzIE9w dGljYWwgTmV0d29yayANCiAgICAgIFMtUEUgICAgIFBXIFN3aXRjaGluZyBQcm92aWRlciBFZGdl ICAgDQogICAgICBTUCAgICAgICBTZXJ2aWNlIFByb3ZpZGVyDQogICAgICBTUkxHICAgICBTaGFy ZWQgUmlzayBMaW5rIEdyb3Vwcw0KICAgICAgU1MtUFcgICAgU2luZ2xlLVNlZ21lbnQgUHNldWRv d2lyZQ0KICAgICAgVERNICAgICAgVGltZSBEaXZpc2lvbiBNdWx0aXBsZXhpbmcNCiAgICAgIFRG UyAgICAgIFRpbWUgYW5kIEZyZXF1ZW5jeSBTeW5jaHJvbml6YXRpb24NCiAgICAgIHRMRFAgICAg IFRhcmdldGVkIExhYmVsIERpc3RyaWJ1dGlvbiBQcm90b2NvbA0KICAgICAgVlBOICAgICAgVmly dHVhbCBQcml2YXRlIE5ldHdvcmsNCiAgICAgIFVNVFMgICAgIFVuaXZlcnNhbCBNb2JpbGUgVGVs ZWNvbW11bmljYXRpb25zIFN5c3RlbSANCiAgICAgIFgyICAgICAgIExURSBTdGFuZGFyZGl6ZWQg aW50ZXJmYWNlIGJldHdlZW4gZU5CcyBmb3IgaGFuZG92ZXINCg0KDQozLiBNUExTLVRQIFVzZSBD YXNlcw0KDQozLjEuIE1ldHJvIEFjY2VzcyBhbmQgQWdncmVnYXRpb24gDQoNCiAgIFRoZSB1c2Ug b2YgTVBMUy1UUCBmb3IgTWV0cm8gYWNjZXNzIGFuZCBhZ2dyZWdhdGlvbiB0cmFuc3BvcnQgaXMg dGhlDQogICBtb3N0IGNvbW1vbiBkZXBsb3ltZW50IHNjZW5hcmlvIG9ic2VydmVkIGluIHRoZSBm aWVsZC4gDQoNCiAgIFNvbWUgb3BlcmF0b3JzIGFyZSBidWlsZGluZyBncmVlbi1maWVsZCBhY2Nl c3MgYW5kIGFnZ3JlZ2F0aW9uDQogICB0cmFuc3BvcnQgaW5mcmFzdHJ1Y3R1cmUsIHdoaWxlIG90 aGVycyBhcmUgdXBncmFkaW5nL3JlcGxhY2luZyB0aGVpcg0KICAgZXhpc3RpbmcgdHJhbnNwb3J0 IGluZnJhc3RydWN0dXJlIHdpdGggbmV3IHBhY2tldCB0ZWNobm9sb2dpZXMuIFRoZQ0KICAgZXhp c3RpbmcgbGVnYWN5IGFjY2VzcyBhbmQgYWdncmVnYXRpb24gbmV0d29ya3MgYXJlIHVzdWFsbHkg YmFzZWQgb24NCiAgIFRETSBvciBBVE0gdGVjaG5vbG9naWVzLiBTb21lIG9wZXJhdG9ycyBhcmUg cmVwbGFjaW5nIHRoZXNlIG5ldHdvcmtzDQogDQoNCg0KRmFuZyBldCBhbC4gICAgICAgICAgICAg IEV4cGlyZXMgQXVndXN0IDYsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJTlRF Uk5FVCBEUkFGVCAgICAgICAgTVBMUy1UUCBVc2UgQ2FzZXMgYW5kIERlc2lnbiAgICAgIEZlYnJ1 YXJ5IDYsIDIwMTMNCg0KDQogICB3aXRoIE1QTFMtVFAgdGVjaG5vbG9naWVzLCBzaW5jZSBsZWdh Y3kgQVRNL1RETSBhZ2dyZWdhdGlvbiBhbmQNCiAgIGFjY2VzcyBhcmUgYmVjb21pbmcgaW5hZGVx dWF0ZSB0byBzdXBwb3J0IHRoZSByYXBpZCBidXNpbmVzcyBncm93dGgNCiAgIGFuZCB0b28gZXhw ZW5zaXZlIHRvIG1haW50YWluLiBJbiBhZGRpdGlvbiwgaW4gbWFueSBjYXNlcyB0aGUgbGVnYWN5 DQogICBkZXZpY2VzIGFyZSBmYWNpbmcgRW5kIG9mIFNhbGUgYW5kIEVuZCBvZiBMaWZlIGlzc3Vl cy4gQXMgb3BlcmF0b3JzDQogICBtdXN0IG1vdmUgZm9yd2FyZCB3aXRoIHRoZSBuZXh0IGdlbmVy YXRpb24gcGFja2V0IHRlY2hub2xvZ3ksIHRoZQ0KICAgYWRvcHRpb24gb2YgTVBMUy1UUCBpbiBh Y2Nlc3MgYW5kIGFnZ3JlZ2F0aW9uIGJlY29tZXMgYSBuYXR1cmFsDQogICBjaG9pY2UuIFRoZSBz dGF0aXN0aWNhbCBtdWx0aXBsZXhpbmcgaW4gTVBMUy1UUCBoZWxwcyB0byBhY2hpZXZlDQogICBo aWdoZXIgZWZmaWNpZW5jeSBjb21wYXJlZCB3aXRoIHRoZSB0aW1lIGRpdmlzaW9uIHNjaGVtZSBp biB0aGUNCiAgIGxlZ2FjeSB0ZWNobm9sb2dpZXMuIE1QTFMtVFAgT0FNIHRvb2xzIGFuZCBwcm90 ZWN0aW9uIG1lY2hhbmlzbXMgaGVscA0KICAgdG8gbWFpbnRhaW4gaGlnaCByZWxpYWJpbGl0eSBv ZiB0cmFuc3BvcnQgbmV0d29ya3MgYW5kIGFjaGlldmUgZmFzdA0KICAgcmVjb3ZlcnkuDQoNCiAg IEFzIG1vc3QgU2VydmljZSBQcm92aWRlcnMnIGNvcmUgbmV0d29ya3MgYXJlIE1QTFMgZW5hYmxl ZCwgZXh0ZW5kaW5nDQogICB0aGUgTVBMUyB0ZWNobm9sb2d5IHRvIHRoZSBhZ2dyZWdhdGlvbiBh bmQgYWNjZXNzIHRyYW5zcG9ydCBuZXR3b3Jrcw0KICAgd2l0aCBhIFVuaWZpZWQgTVBMUyBzdHJh dGVneSBpcyB2ZXJ5IGF0dHJhY3RpdmUgdG8gbWFueSBTZXJ2aWNlDQogICBQcm92aWRlcnMuIFVu aWZpZWQgTVBMUyBzdHJhdGVneSBpbiB0aGlzIGRvY3VtZW50IG1lYW5zIGhhdmluZyBlbmQtDQog ICB0by1lbmQgTVBMUyB0ZWNobm9sb2dpZXMgdGhyb3VnaCBjb3JlLCBhZ2dyZWdhdGlvbiwgYW5k IGFjY2Vzcy4gSXQNCiAgIHJlZHVjZXMgT1BFWCBieSBzdHJlYW1saW5pbmcgb3BlcmF0aW9uIGFu ZCBsZXZlcmFnaW5nIHRoZSBvcGVyYXRpb25hbA0KICAgZXhwZXJpZW5jZSBhbHJlYWR5IGdhaW5l ZCB3aXRoIE1QTFMgdGVjaG5vbG9naWVzOyBpdCBhbHNvIGltcHJvdmVzDQogICBuZXR3b3JrIGVm ZmljaWVuY3kgYW5kIHJlZHVjZXMgZW5kLXRvLWVuZCBjb252ZXJnZW5jZSB0aW1lLiANCg0KICAg VGhlIHJlcXVpcmVtZW50cyBmcm9tIHRoZSBTUHMgZm9yIEFUTS9URE0gYWdncmVnYXRpb24gcmVw bGFjZW1lbnQNCiAgIG9mdGVuIGluY2x1ZGU6IGkpIG1haW50YWluaW5nIHRoZSBwcmV2aW91cyBv cGVyYXRpb25hbCBtb2RlbCwgd2hpY2gNCiAgIG1lYW5zIHByb3ZpZGluZyBhIHNpbWlsYXIgdXNl ciBleHBlcmllbmNlIGluIE5NUywgaWkpIHN1cHBvcnRpbmcgdGhlDQogICBleGlzdGluZyBhY2Nl c3MgbmV0d29yaywgKGUuZy4sIEV0aGVybmV0LCBBRFNMLCBBVE0sIFRETSwgZXRjLiksIGFuZA0K ICAgY29ubmVjdGlvbnMgd2l0aCB0aGUgY29yZSBuZXR3b3JrcywgYW5kIGlpaSkgc3VwcG9ydGlu ZyB0aGUgc2FtZQ0KICAgb3BlcmF0aW9uYWwgY2FwYWJpbGl0aWVzIGFuZCBzZXJ2aWNlcyAoTDNW UE4sIEwyVlBOLCBFLUxJTkUvRS1MQU4vRS0NCiAgIFZMQU4sIERlZGljYXRlZCBMaW5lLCBldGMu KS4gTVBMUy1UUCBjYW4gbWVldCB0aGVzZSByZXF1aXJlbWVudHMgYW5kDQogICBpbiBnZW5lcmFs IHRoZSByZXF1aXJlbWVudHMgZGVmaW5lZCBpbiBbUkZDNTY1NF0gdG8gc3VwcG9ydCBhIHNtb290 aA0KICAgdHJhbnNpdGlvbi4gIA0KDQozLjIuIFBhY2tldCBPcHRpY2FsIFRyYW5zcG9ydCANCg0K ICAgTWFueSBTUCdzIHRyYW5zcG9ydCBuZXR3b3JrcyBjb25zaXN0IG9mIGJvdGggcGFja2V0IGFu ZCBvcHRpY2FsDQogICBwb3J0aW9ucy4gVGhlIHRyYW5zcG9ydCBvcGVyYXRvcnMgYXJlIHR5cGlj YWxseSBzZW5zaXRpdmUgdG8gbmV0d29yaw0KICAgZGVwbG95bWVudCBjb3N0IGFuZCBvcGVyYXRp b25hbCBzaW1wbGljaXR5LiBNUExTLVRQIHN1cHBvcnRzIGJvdGgNCiAgIHN0YXRpYyBwcm92aXNp b25pbmcgdGhyb3VnaCBOTVMgYW5kIGR5bmFtaWMgcHJvdmlzaW9uaW5nIHZpYSB0aGUNCiAgIEdN UExTIGNvbnRyb2wgcGxhbmUuIEFzIHN1Y2gsIGl0IGlzIHZpZXdlZCBhcyBhIG5hdHVyYWwgZml0 IGluIHNvbWUNCiAgIG9mIHRoZSB0cmFuc3BvcnQgbmV0d29ya3MsIHdoZXJlIHRoZSBvcGVyYXRv cnMgY2FuIHV0aWxpemUgdGhlIE1QTFMtDQogICBUUCBMU1AncyAoaW5jbHVkaW5nIHRoZSBvbmVz IHN0YXRpY2FsbHkgcHJvdmlzaW9uZWQpIHRvIG1hbmFnZSB1c2VyDQogICB0cmFmZmljIGFzICJj aXJjdWl0cyIgaW4gYm90aCBwYWNrZXQgYW5kIG9wdGljYWwgbmV0d29ya3MsIGFuZCB3aGVuDQog ICB0aGV5IGFyZSByZWFkeSwgbW92ZSB0byBkeW5hbWljIGNvbnRyb2wgcGxhbmUgZm9yIGdyZWF0 ZXIgZWZmaWNpZW5jeS4NCg0KICAgQW1vbmcgb3RoZXIgYXR0cmlidXRlcywgYmFuZHdpZHRoIG1h bmFnZW1lbnQsIHByb3RlY3Rpb24vcmVjb3ZlcnkgYW5kDQogICBPQU0gYXJlIGNyaXRpY2FsIGlu IFBhY2tldC9PcHRpY2FsIHRyYW5zcG9ydCBuZXR3b3Jrcy4gSW4gdGhlIGNvbnRleHQNCiAgIG9m IE1QTFMtVFAsIGVhY2ggTFNQIGlzIGV4cGVjdGVkIHRvIGJlIGFzc29jaWF0ZWQgd2l0aCBhIGZp eGVkIGFtb3VudA0KICAgb2YgYmFuZHdpZHRoIGluIHRlcm1zIG9mIGJpdHMtcGVyLXNlY29uZCBh bmQvb3IgdGltZS1zbG90cy4gT0FNIGlzIHRvDQogICBiZSBwZXJmb3JtZWQgb24gZWFjaCBpbmRp dmlkdWFsIExTUC4gRm9yIHNvbWUgb2YgdGhlIHBlcmZvcm1hbmNlDQogDQoNCg0KRmFuZyBldCBh bC4gICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDYsIDIwMTMgICAgICAgICAgICAgICAgIFtQ YWdlIDZdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgICAgTVBMUy1UUCBVc2UgQ2FzZXMgYW5kIERl c2lnbiAgICAgIEZlYnJ1YXJ5IDYsIDIwMTMNCg0KDQogICBtb25pdG9yaW5nIChQTSkgZnVuY3Rp b25zLCB0aGUgT0FNIG1lY2hhbmlzbXMgbmVlZCB0byBiZSBhYmxlIHRvDQogICB0cmFuc21pdCBh bmQgcHJvY2VzcyBPQU0gcGFja2V0cyBhdCB2ZXJ5IGhpZ2ggZnJlcXVlbmN5LiBBbiBvdmVydmll dw0KICAgb2YgTVBMUy1UUCBPQU0gdG9vbHNldCBpcyBmb3VuZCBpbiBbUkZDNjY2OV0uDQoNCiAg IFByb3RlY3Rpb24gW1JGQzYzNzJdIGlzIGFub3RoZXIgaW1wb3J0YW50IGVsZW1lbnQgaW4gdHJh bnNwb3J0DQogICBuZXR3b3Jrcy4gVHlwaWNhbGx5LCByaW5nIGFuZCBsaW5lYXIgcHJvdGVjdGlv biBjYW4gYmUgcmVhZGlseQ0KICAgYXBwbGllZCBpbiBtZXRybyBuZXR3b3Jrcy4gSG93ZXZlciwg YXMgbG9uZy1oYXVsIG5ldHdvcmtzIGFyZQ0KICAgc2Vuc2l0aXZlIHRvIGJhbmR3aWR0aCBjb3N0 IGFuZCB0ZW5kIHRvIGhhdmUgbWVzaC1saWtlIHRvcG9sb2d5LA0KICAgc2hhcmVkIG1lc2ggcHJv dGVjdGlvbiBpcyBiZWNvbWluZyBpbmNyZWFzaW5nbHkgaW1wb3J0YW50LiANCg0KICAgSW4gc29t ZSBjYXNlcywgU1BzIHBsYW4gdG8gZGVwbG95IE1QTFMtVFAgZnJvbSB0aGVpciBsb25nIGhhdWwN CiAgIG9wdGljYWwgcGFja2V0IHRyYW5zcG9ydCBhbGwgdGhlIHdheSB0byB0aGUgYWdncmVnYXRp b24gYW5kIGFjY2VzcyBpbg0KICAgdGhlaXIgbmV0d29ya3MuIA0KDQozLjMuIE1vYmlsZSBCYWNr aGF1bCANCg0KICAgV2lyZWxlc3MgY29tbXVuaWNhdGlvbiBpcyBvbmUgb2YgdGhlIGZhc3Rlc3Qg Z3Jvd2luZyBhcmVhcyBpbg0KICAgY29tbXVuaWNhdGlvbiB3b3JsZHdpZGUuIEluIHNvbWUgcmVn aW9ucywgdGhlIHRyZW1lbmRvdXMgbW9iaWxlDQogICBncm93dGggaXMgZnVlbGVkIGJ5IHRoZSBs YWNrIG9mIGV4aXN0aW5nIGxhbmQtbGluZSBhbmQgY2FibGUNCiAgIGluZnJhc3RydWN0dXJlLiBJ biBvdGhlciByZWdpb25zLCB0aGUgaW50cm9kdWN0aW9uIG9mIHNtYXJ0IHBob25lcyBpcw0KICAg cXVpY2tseSBkcml2aW5nIG1vYmlsZSBkYXRhIHRyYWZmaWMgdG8gYmVjb21lIHRoZSBwcmltYXJ5 IG1vYmlsZQ0KICAgYmFuZHdpZHRoIGNvbnN1bWVyIChzb21lIFNQcyBoYXZlIGFscmVhZHkgb2Jz ZXJ2ZWQgbW9yZSB0aGFuIDg1JSBvZg0KICAgdG90YWwgbW9iaWxlIHRyYWZmaWMgYXJlIGRhdGEg dHJhZmZpYykuIE1QTFMtVFAgaXMgdmlld2VkIGFzIGENCiAgIHN1aXRhYmxlIHRlY2hub2xvZ3kg Zm9yIE1vYmlsZSBiYWNraGF1bC4gDQoNCjMuMy4xLiAyRyBhbmQgM0cgTW9iaWxlIEJhY2toYXVs IA0KDQogICBNUExTLVRQIGlzIGNvbW1vbmx5IHZpZXdlZCBhcyBhIHZlcnkgZ29vZCBmaXQgZm9y IDJHLzNHIG1vYmlsZQ0KICAgYmFja2hhdWwuIDJHIChHU00vQ0RNQSkgYW5kIDNHIChVTVRTL0hT UEEvMXhFVkRPKSBNb2JpbGUgQmFja2hhdWwNCiAgIE5ldHdvcmtzIGFyZSBzdGlsbCBjdXJyZW50 bHkgZG9taW5hdGluZyB0aGUgbW9iaWxlIGluZnJhc3RydWN0dXJlLiANCg0KICAgVGhlIGNvbm5l Y3Rpdml0eSBmb3IgMkcvM0cgbmV0d29ya3MgaXMgcG9pbnQgdG8gcG9pbnQgKFAyUCkuIFRoZQ0K ICAgbG9naWNhbCBjb25uZWN0aW9ucyBhcmUgaHViLWFuZC1zcG9rZS4gTmV0d29ya3MgYXJlIHBo eXNpY2FsbHkNCiAgIGNvbnN0cnVjdGVkIHVzaW5nIGEgc3RhciBvciByaW5nIHRvcG9sb2d5LiBJ biB0aGUgUmFkaW8gQWNjZXNzDQogICBOZXR3b3JrIChSQU4pLCBlYWNoIG1vYmlsZSBCYXNlIFRy YW5zY2VpdmVyIFN0YXRpb24gKEJUUy9Ob2RlIEIpIGlzDQogICBjb21tdW5pY2F0aW5nIHdpdGgg YSBSYWRpbyBDb250cm9sbGVyIChCU0MvUk5DKS4gVGhlc2UgY29ubmVjdGlvbnMNCiAgIGFyZSBv ZnRlbiBzdGF0aWNhbGx5IHNldCB1cC4gIA0KDQogICBIaWVyYXJjaGljYWwgb3IgY2VudHJhbGl6 ZWQgYXJjaGl0ZWN0dXJlcyBhcmUgb2Z0ZW4gdXNlZCBmb3IgcHJlLQ0KICAgYWdncmVnYXRpb24g YW5kIGFnZ3JlZ2F0aW9uIGxheWVycy4gRWFjaCBhZ2dyZWdhdGlvbiBuZXR3b3JrIGludGVyLQ0K ICAgY29ubmVjdHMgd2l0aCBtdWx0aXBsZSBhY2Nlc3MgbmV0d29ya3MuIEZvciBleGFtcGxlLCBh IHNpbmdsZQ0KICAgYWdncmVnYXRpb24gcmluZyBjb3VsZCBhZ2dyZWdhdGUgdHJhZmZpYyBmb3Ig MTAgYWNjZXNzIHJpbmdzIHdpdGggYQ0KICAgdG90YWwgb2YgMTAwIGJhc2Ugc3RhdGlvbnMuICAg DQoNCiAgIFRoZSB0ZWNobm9sb2d5IHVzZWQgdG9kYXkgaXMgbGFyZ2VseSBBVE0gYmFzZWQuIE1v YmlsZSBwcm92aWRlcnMgYXJlDQogICByZXBsYWNpbmcgdGhlIEFUTSBSQU4gaW5mcmFzdHJ1Y3R1 cmUgd2l0aCBuZXdlciBwYWNrZXQgdGVjaG5vbG9naWVzLg0KICAgSVAgUkFOIG5ldHdvcmtzIHdp dGggSVAvTVBMUyB0ZWNobm9sb2dpZXMgYXJlIGRlcGxveWVkIHRvZGF5IGJ5IG1hbnkNCiAgIFNQ cyB3aXRoIGdyZWF0IHN1Y2Nlc3MuIE1QTFMtVFAgaXMgYW5vdGhlciBzdWl0YWJsZSBjaG9pY2Ug Zm9yIE1vYmlsZQ0KIA0KDQoNCkZhbmcgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3Vz dCA2LCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0KSU5URVJORVQgRFJBRlQgICAg ICAgIE1QTFMtVFAgVXNlIENhc2VzIGFuZCBEZXNpZ24gICAgICBGZWJydWFyeSA2LCAyMDEzDQoN Cg0KICAgUkFOLiBUaGUgUDJQIGNvbm5lY3Rpb25zIGZyb20gYmFzZSBzdGF0aW9uIHRvIFJhZGlv IENvbnRyb2xsZXIgY2FuIGJlDQogICBzZXQgc3RhdGljYWxseSB0byBtaW1pYyB0aGUgb3BlcmF0 aW9uIG9mIHRvZGF5J3MgUkFOIGVudmlyb25tZW50czsNCiAgIGluLWJhbmQgT0FNIGFuZCBkZXRl cm1pbmlzdGljIHBhdGggcHJvdGVjdGlvbiBjYW4gc3VwcG9ydCBmYXN0DQogICBmYWlsdXJlIGRl dGVjdGlvbiBhbmQgc3dpdGNoLW92ZXIgdG8gc2F0aXNmeSB0aGUgU0xBIGFncmVlbWVudHMuDQog ICBCaWRpcmVjdGlvbmFsIExTUHMgbWF5IGhlbHAgdG8gc2ltcGxpZnkgdGhlIHByb3Zpc2lvbmlu ZyBwcm9jZXNzLiBUaGUNCiAgIGRldGVybWluaXN0aWMgbmF0dXJlIG9mIE1QTFMtVFAgTFNQIHNl dCB1cCBjYW4gYWxzbyBzdXBwb3J0IHBhY2tldA0KICAgYmFzZWQgc3luY2hyb25pemF0aW9uIHRv IG1haW50YWluIHByZWRpY3RhYmxlIHBlcmZvcm1hbmNlIHJlZ2FyZGluZw0KICAgcGFja2V0IGRl bGF5IGFuZCBqaXR0ZXJzLiBUaGUgdHJhZmZpYyBlbmdpbmVlcmVkIGFuZCBjby1yb3V0ZWQNCiAg IGJpZGlyZWN0aW9uYWwgcHJvcGVydGllcyBvZiBhbiBNUExTLVRQIExTUCBhcmUgb2YgYmVuZWZp dCBpbg0KICAgdHJhbnNwb3J0aW5nIHBhY2tldCBiYXNlZCBUaW1lIGFuZCBGcmVxdWVuY3kgU3lu Y2hyb25pemF0aW9uIChURlMpDQogICBwcm90b2NvbHMgc3VjaCBhcyBbMTU4OG92ZXJtcGxzXS4g SG93ZXZlciwgdGhlIGNob2ljZSBiZXR3ZWVuIGFuDQogICBleHRlcm5hbCwgcGh5c2ljYWwgbGF5 ZXIgb3IgcGFja2V0IGJhc2VkIFRGUyBtZXRob2QgaXMgbmV0d29yaw0KICAgZGVwZW5kZW50IGFu ZCB0aHVzIGlzIG91dCBvZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQozLjMuMi4gNEcvTFRF IE1vYmlsZSBCYWNraGF1bCANCg0KICAgT25lIGtleSBkaWZmZXJlbmNlIGJldHdlZW4gTFRFIGFu ZCAyRy8zRyBtb2JpbGUgbmV0d29ya3MgaXMgdGhhdCB0aGUNCiAgIGxvZ2ljYWwgY29ubmVjdGlv biBpbiBMVEUgaXMgYSBtZXNoLCB3aGlsZSBpbiAyRy8zRyBpcyBhIFAyUCBzdGFyLiBJbg0KICAg TFRFLCB0aGUgYmFzZSBzdGF0aW9ucyBlTkIvQlRTIGNvbW11bmljYXRlIHdpdGggbXVsdGlwbGUg TmV0d29yaw0KICAgY29udHJvbGxlcnMgKFBTVy9TR1cgb3IgQVNOR1cpLCBhbmQgdGhlIHJhZGlv IGVsZW1lbnRzIGNvbW11bmljYXRlDQogICB3aXRoIG9uZSBhbm90aGVyIGZvciBzaWduYWwgZXhj aGFuZ2UgYW5kIHRyYWZmaWMgb2ZmbG9hZCB0byB3aXJlbGVzcw0KICAgb3Igd2lyZWxpbmUgaW5m cmFzdHJ1Y3R1cmVzLiANCg0KICAgSVAvTVBMUyBoYXMgYSBncmVhdCBhZHZhbnRhZ2UgaW4gYW55 LXRvLWFueSBjb25uZWN0aXZpdHkNCiAgIGVudmlyb25tZW50cy4gVGh1cywgdGhlIHVzZSBvZiBt YXR1cmUgSVAgb3IgTDNWUE4gdGVjaG5vbG9naWVzIGlzDQogICBwYXJ0aWN1bGFybHkgY29tbW9u IGluIHRoZSBkZXNpZ24gb2YgU1AncyBMVEUgZGVwbG95bWVudCBwbGFucy4NCg0KICAgVGhlIGV4 dGVuZGVkIE9BTSBmdW5jdGlvbnMgZGVmaW5lZCBpbiBNUExTLVRQLCBzdWNoIGFzIGluLWJhbmQg T0FNDQogICBhbmQgcGF0aCBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgYnJpbmcgYWRkaXRpb25hbCBh ZHZhbnRhZ2VzIHRvIHN1cHBvcnQNCiAgIFNMQXMuIFRoZSBkeW5hbWljIGNvbnRyb2wtcGxhbmUg d2l0aCBHTVBMUyBzaWduYWxpbmcgaXMgZXNwZWNpYWxseQ0KICAgc3VpdGVkIGZvciB0aGUgbWVz aCBlbnZpcm9ubWVudCwgdG8gc3VwcG9ydCBkeW5hbWljIHRvcG9sb2d5IGNoYW5nZXMNCiAgIGFu ZCBuZXR3b3JrIG9wdGltaXphdGlvbi4NCg0KICAgU29tZSBvcGVyYXRvcnMgYXJlIHVzaW5nIHRo ZSBzYW1lIG1vZGVsIGFzIGluIDJHIGFuZCAzRyBNb2JpbGUNCiAgIEJhY2toYXVsLCB3aGljaCB1 c2VzIElQL01QTFMgaW4gdGhlIGNvcmUsIGFuZCBNUExTLVRQIHdpdGggc3RhdGljDQogICBwcm92 aXNpb25pbmcgKHRocm91Z2ggTk1TKSBpbiBhZ2dyZWdhdGlvbiBhbmQgYWNjZXNzLiBUaGUgcmVh c29uaW5nDQogICBpcyBhcyBmb2xsb3dzOiB0aGUgWDIgdHJhZmZpYyBsb2FkIGluIExURSBuZXR3 b3JrcyBjdXJyZW50bHkgbWF5IGJlIGENCiAgIHZlcnkgc21hbGwgcGVyY2VudGFnZSBvZiB0aGUg dG90YWwgdHJhZmZpYy4gRm9yIGV4YW1wbGUsIG9uZSBsYXJnZQ0KICAgbW9iaWxlIG9wZXJhdG9y IG9ic2VydmVkIHRoYXQgWDIgdHJhZmZpYyB3YXMgbGVzcyB0aGFuIG9uZSBwZXJjZW50IG9mDQog ICB0aGUgdG90YWwgUzEgdHJhZmZpYy4gVGhlcmVmb3JlLCBvcHRpbWl6aW5nIHRoZSBYMiB0cmFm ZmljIG1heSBub3QgYmUNCiAgIHRoZSBkZXNpZ24gb2JqZWN0aXZlIGluIHRoaXMgY2FzZS4gVGhl IFgyIHRyYWZmaWMgY2FuIGJlIGNhcnJpZWQNCiAgIHRocm91Z2ggdGhlIHNhbWUgc3RhdGljIHR1 bm5lbHMgdG9nZXRoZXIgd2l0aCB0aGUgUzEgdHJhZmZpYyBpbiB0aGUNCiAgIGFnZ3JlZ2F0aW9u IGFuZCBhY2Nlc3MgbmV0d29ya3MsIGFuZCBmdXJ0aGVyIGZvcndhcmRlZCBhY3Jvc3MgdGhlDQog ICBJUC9NUExTIGNvcmUuIEluIGFkZGl0aW9uLCBtZXNoIHByb3RlY3Rpb24gbWF5IGJlIG1vcmUg ZWZmaWNpZW50IHdpdGgNCiAgIHJlZ2FyZCB0byBiYW5kd2lkdGggdXRpbGl6YXRpb24sIGJ1dCBs aW5lYXIgcHJvdGVjdGlvbiBhbmQgcmluZw0KICAgcHJvdGVjdGlvbiBhcmUgb2Z0ZW4gY29uc2lk ZXJlZCBzaW1wbGVyIGJ5IHNvbWUgb3BlcmF0b3JzIGZyb20gdGhlDQogICBwb2ludCBvZiB2aWV3 IG9mIG9wZXJhdGlvbiBtYWludGVuYW5jZSBhbmQgdHJvdWJsZSBzaG9vdGluZywgYW5kIHNvDQog ICBhcmUgd2lkZWx5IGRlcGxveWVkLiBJbiBnZW5lcmFsLCB1c2luZyBNUExTLVRQIHdpdGggc3Rh dGljDQogDQoNCg0KRmFuZyBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDYsIDIw MTMgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgICAgTVBM Uy1UUCBVc2UgQ2FzZXMgYW5kIERlc2lnbiAgICAgIEZlYnJ1YXJ5IDYsIDIwMTMNCg0KDQogICBw cm92aXNpb25pbmcgZm9yIExURSBiYWNraGF1bCBpcyBhIHZpYWJsZSBvcHRpb24uIFRoZSBkZXNp Z24NCiAgIG9iamVjdGl2ZSBvZiB1c2luZyB0aGlzIGFwcHJvYWNoIGlzIHRvIGtlZXAgdGhlIG9w ZXJhdGlvbiBzaW1wbGUgYW5kDQogICB1c2UgYSBjb21tb24gbW9kZWwgZm9yIG1vYmlsZSBiYWNr aGF1bCwgZXNwZWNpYWxseSBkdXJpbmcgdGhlDQogICB0cmFuc2l0aW9uIHBlcmlvZC4NCg0KICAg VGhlIFRGUyBjb25zaWRlcmF0aW9ucyBzdGF0ZWQgaW4gU2VjdGlvbiAzLjMuMSBhcHBseSB0byB0 aGUgNEcvTFRFDQogICBNb2JpbGUgQmFja2hhdWwgY2FzZSBhcyB3ZWxsLg0KDQo0LiBOZXR3b3Jr IERlc2lnbiBDb25zaWRlcmF0aW9ucyAgDQoNCjQuMS4gVGhlIHJvbGUgb2YgTVBMUy1UUA0KDQog ICBUaGUgcm9sZSBvZiBNUExTLVRQIGlzIHRvIHByb3ZpZGUgYSBzb2x1dGlvbiB0byBoZWxwIGV2 b2x2ZQ0KICAgdHJhZGl0aW9uYWwgdHJhbnNwb3J0IHRvd2FyZHMgcGFja2V0LiBJdCBpcyBkZXNp Z25lZCB0byBzdXBwb3J0IHRoZQ0KICAgdHJhbnNwb3J0IGNoYXJhY3RlcmlzdGljcy9iZWhhdmlv ciBkZXNjcmliZWQgaW4gW1JGQzU2NTRdLiBUaGUNCiAgIHByaW1hcnkgdXNlIG9mIE1QTFMtVFAg aXMgbGFyZ2VseSB0byByZXBsYWNlIGxlZ2FjeSB0cmFuc3BvcnQNCiAgIHRlY2hub2xvZ2llcywg c3VjaCBhcyBTT05FVC9TREguIE1QTFMtVFAgaXMgbm90IGRlc2lnbmVkIHRvIHJlcGxhY2UNCiAg IHRoZSBzZXJ2aWNlIHN1cHBvcnQgY2FwYWJpbGl0aWVzIG9mIElQL01QTFMsIHN1Y2ggYXMgTDJW UE4sIEwzVlBOLA0KICAgSVBUViwgTW9iaWxlIFJBTiwgZXRjLiANCg0KDQo0LjIuIFByb3Zpc2lv bmluZyBtb2RlDQoNCiAgIE1QTFMtVFAgc3VwcG9ydHMgdHdvIHByb3Zpc2lvbmluZyBtb2Rlczog aSkgYSBtYW5kYXRvcnkgc3RhdGljDQogICBwcm92aXNpb25pbmcgbW9kZSwgd2hpY2ggbXVzdCBi ZSBzdXBwb3J0ZWQgd2l0aG91dCBkZXBlbmRlbmN5IG9uDQogICBkeW5hbWljIHJvdXRpbmcgb3Ig c2lnbmFsaW5nOyBhbmQgaWkpIGFuIG9wdGlvbmFsIGRpc3RyaWJ1dGVkIGR5bmFtaWMNCiAgIGNv bnRyb2wgcGxhbmUsIHdoaWNoIGlzIHVzZWQgdG8gZW5hYmxlIGR5bmFtaWMgc2VydmljZSBwcm92 aXNpb25pbmcuDQoNCiAgIFRoZSBkZWNpc2lvbiBvbiB3aGljaCBtb2RlIHRvIHVzZSBpcyBsYXJn ZWx5IGRlcGVuZGVudCBvbiB0aGUNCiAgIG9wZXJhdGlvbmFsIGZlYXNpYmlsaXR5IGFuZCB0aGUg c3RhZ2Ugb2YgbmV0d29yayB0cmFuc2l0aW9uLg0KICAgT3BlcmF0b3JzIHdobyBhcmUgYWNjdXN0 b21lZCB0byB0aGUgdHJhbnNwb3J0LWNlbnRyaWMgb3BlcmF0aW9uYWwNCiAgIG1vZGVsIChlLmcu LCBOTVMgY29uZmlndXJhdGlvbiB3aXRob3V0IGNvbnRyb2wgcGxhbmUpIHR5cGljYWxseQ0KICAg cHJlZmVyIHRoZSBzdGF0aWMgcHJvdmlzaW9uaW5nIG1vZGUuIFRoaXMgaXMgdGhlIG1vc3QgY29t bW9uIGNob2ljZQ0KICAgaW4gY3VycmVudCBkZXBsb3ltZW50cy4gVGhlIGR5bmFtaWMgcHJvdmlz aW9uaW5nIG1vZGUgY2FuIGJlIG1vcmUNCiAgIHBvd2VyZnVsIGJ1dCBpdCBpcyBtb3JlIHN1aXRl ZCB0byBvcGVyYXRvcnMgd2hvIGFyZSBmYW1pbGlhciB3aXRoIHRoZQ0KICAgb3BlcmF0aW9uIGFu ZCBtYWludGVuYW5jZSBvZiBJUC9NUExTIHRlY2hub2xvZ2llcyBvciBhcmUgcmVhZHkgdG8NCiAg IHN0ZXAgdXAgdGhyb3VnaCB0cmFpbmluZyBhbmQgcGxhbm5lZCB0cmFuc2l0aW9uLiANCg0KICAg VGhlcmUgbWF5IGJlIGFsc28gY2FzZXMgd2hlcmUgb3BlcmF0b3JzIGNob29zZSB0byB1c2UgdGhl IGNvbWJpbmF0aW9uDQogICBvZiBib3RoIG1vZGVzLiBUaGlzIGlzIGFwcHJvcHJpYXRlIHdoZW4g cGFydHMgb2YgdGhlIG5ldHdvcmsgYXJlDQogICBwcm92aXNpb25lZCBpbiBhIHN0YXRpYyBmYXNo aW9uIGFuZCBvdGhlciBwYXJ0cyBhcmUgY29udHJvbGxlZCBieQ0KICAgZHluYW1pYyBzaWduYWxp bmcuIFRoaXMgY29tYmluYXRpb24gbWF5IGFsc28gYmUgdXNlZCB0byB0cmFuc2l0aW9uDQogICBm cm9tIHN0YXRpYyBwcm92aXNpb25pbmcgdG8gZHluYW1pYyBjb250cm9sIHBsYW5lLiAgIA0KDQo0 LjMuIFN0YW5kYXJkcyBjb21wbGlhbmNlIA0KDQogICBJdCBpcyBnZW5lcmFsbHkgcmVjb2duaXpl ZCBieSBTUHMgdGhhdCBzdGFuZGFyZHMgY29tcGxpYW5jZSBpcw0KICAgaW1wb3J0YW50IGZvciBs b3dlcmluZyBjb3N0LCBhY2NlbGVyYXRpbmcgcHJvZHVjdCBtYXR1cml0eSwgYWNoaWV2aW5nDQog DQoNCg0KRmFuZyBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDYsIDIwMTMgICAg ICAgICAgICAgICAgIFtQYWdlIDldDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgICAgTVBMUy1UUCBV c2UgQ2FzZXMgYW5kIERlc2lnbiAgICAgIEZlYnJ1YXJ5IDYsIDIwMTMNCg0KDQogICBtdWx0aS12 ZW5kb3IgaW50ZXJvcGVyYWJpbGl0eSwgYW5kIG1lZXRpbmcgdGhlIGV4cGVjdGF0aW9ucyBvZiB0 aGVpcg0KICAgZW50ZXJwcmlzZSBjdXN0b21lcnMuIA0KDQogICBNUExTLVRQIGlzIGEgam9pbnQg d29yayBiZXR3ZWVuIElFVEYgYW5kIElUVS1ULiBJbiBBcHJpbCAyMDA4LCBJRVRGDQogICBhbmQg SVRVLVQgam9pbnRseSBhZ3JlZWQgdG8gdGVybWluYXRlIFQtTVBMUyBhbmQgcHJvZ3Jlc3MgTVBM Uy1UUCBhcw0KICAgam9pbnQgd29yayBbUkZDNTMxN10uIFRoZSB0cmFuc3BvcnQgcmVxdWlyZW1l bnRzIGFyZSBwcm92aWRlZCBieSBJVFUtDQogICBULCB0aGUgcHJvdG9jb2xzIGFyZSBkZXZlbG9w ZWQgaW4gSUVURi4gIA0KDQo0LjQuIEVuZC10by1lbmQgTVBMUyBPQU0gY29uc2lzdGVuY3kgDQoN CiAgIEVuZC10by1lbmQgTVBMUyBPQU0gY29uc2lzdGVuY3kgaXMgaGlnaGx5IGRlc2lyYWJsZSBp biBvcmRlciB0bw0KICAgZW5hYmxlIFNlcnZpY2UgUHJvdmlkZXJzIHRvIGRlcGxveSBhbiBlbmQt dG8tZW5kIE1QTFMgc29sdXRpb24gd2l0aCBhDQogICBjb21iaW5hdGlvbiBvZiBJUC9NUExTIChm b3IgZXhhbXBsZSwgaW4gdGhlIGNvcmUgaW5jbHVkaW5nIHNlcnZpY2UNCiAgIGVkZ2UpIGFuZCBN UExTLVRQIChmb3IgZXhhbXBsZSwgaW4gdGhlIGFnZ3JlZ2F0aW9uL2FjY2VzcyBuZXR3b3Jrcyku DQogICBVc2luZyBNUExTIGJhc2VkIE9BTSBpbiBNUExTLVRQIGNhbiBoZWxwIGFjaGlldmUgc3Vj aCBhIGdvYWwuIA0KDQo0LjUuIFBXIERlc2lnbiBjb25zaWRlcmF0aW9ucyBpbiBNUExTLVRQIG5l dHdvcmtzIA0KDQogICBJbiBnZW5lcmFsLCBQV3MgaW4gTVBMUy1UUCB3b3JrIHRoZSBzYW1lIGFz IGluIElQL01QTFMgbmV0d29ya3MuIEJvdGgNCiAgIFNpbmdsZS1TZWdtZW50IFBXIChTUy1QVykg YW5kIE11bHRpLVNlZ21lbnQgUFcgKE1TLVBXKSBhcmUgc3VwcG9ydGVkLg0KICAgRm9yIGR5bmFt aWMgY29udHJvbCBwbGFuZSwgVGFyZ2V0ZWQgTERQICh0TERQKSBpcyB1c2VkLiBJbiBzdGF0aWMN CiAgIHByb3Zpc2lvbmluZyBtb2RlLCBQVyBzdGF0dXMgaXMgYSBuZXcgUFcgT0FNIGZlYXR1cmUg Zm9yIGZhaWx1cmUNCiAgIG5vdGlmaWNhdGlvbi4gSW4gYWRkaXRpb24sIGJvdGggZGlyZWN0aW9u cyBvZiBhIFBXIG11c3QgYmUgYm91bmQgdG8NCiAgIHRoZSBzYW1lIHRyYW5zcG9ydCBiaWRpcmVj dGlvbmFsIExTUC4gDQoNCiAgIEluIHRoZSBjb21tb24gbmV0d29yayB0b3BvbG9neSBpbnZvbHZp bmcgbXVsdGktdGllciByaW5ncywgdGhlIGRlc2lnbg0KICAgY2hvaWNlIGlzIGJldHdlZW4gdXNp bmcgU1MtUFcgb3IgTVMtUFcuIFRoaXMgaXMgbm90IGEgZGlzY3Vzc2lvbg0KICAgdW5pcXVlIHRv IE1QTFMtVFAsIGFzIGl0IGFwcGxpZXMgdG8gUFcgZGVzaWduIGluIGdlbmVyYWwsIGJ1dCBpdCBp cw0KICAgcmVsZXZhbnQgaGVyZSwgc2luY2UgTVBMUy1UUCBpcyBtb3JlIHNlbnNpdGl2ZSB0byB0 aGUgb3BlcmF0aW9uYWwNCiAgIGNvbXBsZXhpdGllcywgYXMgbm90ZWQgYnkgb3BlcmF0b3JzLiBJ ZiBNUy1QVyBpcyB1c2VkLCBTd2l0Y2hlZCBQRQ0KICAgKFMtUEUpIG11c3QgYmUgZGVwbG95ZWQg dG8gY29ubmVjdCB0aGUgcmluZ3MuIFRoZSBhZHZhbnRhZ2Ugb2YgdGhpcw0KICAgY2hvaWNlIGlz IHRoYXQgaXQgcHJvdmlkZXMgZG9tYWluIGlzb2xhdGlvbiwgd2hpY2ggaW4gdHVybg0KICAgZmFj aWxpdGF0ZXMgdHJvdWJsZSBzaG9vdGluZyBhbmQgYWxsb3dzIGZvciBmYXN0ZXIgUFcgZmFpbHVy ZQ0KICAgcmVjb3ZlcnkuIE9uIHRoZSBvdGhlciBoYW5kLCB0aGUgZGlzYWR2YW50YWdlIG9mIHVz aW5nIFMtUEUgaXMgdGhhdA0KICAgaXQgYWRkcyBtb3JlIGNvbXBsZXhpdHkuIFVzaW5nIFNTLVBX IGlzIHNpbXBsZXIsIHNpbmNlIGl0IGRvZXMgbm90DQogICByZXF1aXJlIFMtUEVzLCBidXQgbGVz cyBlZmZpY2llbnQgYmVjYXVzZSB0aGUgcGF0aHMgYWNyb3NzIHByaW1hcnkNCiAgIGFuZCBzZWNv bmRhcnkgcmluZ3MgYXJlIGxvbmdlci4gSWYgb3BlcmF0aW9uYWwgc2ltcGxpY2l0eSBpcyBhIGhp Z2hlcg0KICAgcHJpb3JpdHksIHNvbWUgU1BzIGNob29zZSB0aGUgbGF0dGVyLiANCg0KICAgQW5v dGhlciBkZXNpZ24gdHJhZGUtb2ZmIGlzIHdoZXRoZXIgdG8gdXNlIFBXIHByb3RlY3Rpb24gaW4g YWRkaXRpb24NCiAgIHRvIExTUCBwcm90ZWN0aW9uIG9yIHJlbHkgc29sZWx5IG9uIExTUCBwcm90 ZWN0aW9uLiBXaGVuIHRoZSBNUExTLVRQDQogICBMU1BzIGFyZSBwcm90ZWN0ZWQsIGlmIHRoZSB3 b3JraW5nIExTUCBmYWlscywgdGhlIHByb3RlY3QgTFNQIGFzc3VyZXMNCiAgIHRoYXQgdGhlIGNv bm5lY3Rpdml0eSBpcyBtYWludGFpbmVkIGFuZCB0aGUgUFcgaXMgbm90IGltcGFjdGVkLg0KICAg SG93ZXZlciwgaW4gdGhlIGNhc2Ugb2Ygc2ltdWx0YW5lb3VzIGZhaWx1cmUgb2YgYm90aCB3b3Jr aW5nIGFuZA0KICAgcHJvdGVjdCBMU1BzLCB0aGUgYXR0YWNoZWQgUFcgd291bGQgZmFpbC4gQnkg YWRkaW5nIFBXIHByb3RlY3Rpb24sDQogICBhbmQgYXR0YWNoaW5nIHRoZSBwcm90ZWN0IFBXIHRv IGEgZGl2ZXJzZSBMU1Agbm90IGluIHRoZSBzYW1lIFNoYXJlZA0KICAgUmlzayBMaW5rIEdyb3Vw IChTUkxHKSwgdGhlIFBXIGlzIHByb3RlY3RlZCBldmVuIHdoZW4gdGhlIHByaW1hcnkgUFcNCiAg IGZhaWxzLiAgQ2xlYXJseSwgdXNpbmcgUFcgcHJvdGVjdGlvbiBhZGRzIGNvbnNpZGVyYWJseSBt b3JlDQogDQoNCg0KRmFuZyBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDYsIDIw MTMgICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgICAgTVBM Uy1UUCBVc2UgQ2FzZXMgYW5kIERlc2lnbiAgICAgIEZlYnJ1YXJ5IDYsIDIwMTMNCg0KDQogICBj b21wbGV4aXR5IGFuZCByZXNvdXJjZSB1c2FnZSwgYW5kIHRodXMgb3BlcmF0b3JzIG9mdGVuIG1h eSBjaG9vc2UNCiAgIG5vdCB0byB1c2UgaXQsIGFuZCBjb25zaWRlciBwcm90ZWN0aW9uIGFnYWlu c3Qgc2luZ2xlIHBvaW50IG9mDQogICBmYWlsdXJlIGFzIHN1ZmZpY2llbnQuIA0KDQo0LjYuIFBy b2FjdGl2ZSBhbmQgb24tZGVtYW5kIE1QTFMtVFAgT0FNIHRvb2xzIA0KDQogICBNUExTLVRQIHBy b3ZpZGUgYm90aCBwcm9hY3RpdmUgYW5kIG9uLWRlbWFuZCBPQU0gVG9vbHMuIEFzIGENCiAgIHBy b2FjdGl2ZSBPQU0gZmF1bHQgbWFuYWdlbWVudCB0b29sLCBCRkQgQ29ubmVjdGl2aXR5IENoZWNr IChDQykgY2FuDQogICBiZSBzZW50IGF0IHJlZ3VsYXIgaW50ZXJ2YWxzIGZvciBDb25uZWN0aXZp dHkgQ2hlY2s7IHRocmVlIG1pc3NlZCBDQw0KICAgbWVzc2FnZXMgKG9yIGEgY29uZmlndXJhYmxl IG51bWJlcikgY2FuIHRyaWdnZXIgdGhlIGZhaWx1cmUNCiAgIHByb3RlY3Rpb24gc3dpdGNoLW92 ZXIuIEJGRCBzZXNzaW9ucyBhcmUgY29uZmlndXJlZCBmb3IgYm90aCB3b3JraW5nDQogICBhbmQg cHJvdGVjdGluZyBMU1BzLiANCg0KICAgQSBkZXNpZ24gZGVjaXNpb24gaXMgY2hvb3NpbmcgdGhl IHZhbHVlIG9mIHRoZSBCRkQgQ0MgaW50ZXJ2YWwuIFRoZQ0KICAgc2hvcnRlciB0aGUgaW50ZXJ2 YWwsIHRoZSBmYXN0ZXIgdGhlIGRldGVjdGlvbiB0aW1lIGlzLCBidXQgYWxzbyB0aGUNCiAgIGhp Z2hlciB0aGUgcmVzb3VyY2UgdXRpbGl6YXRpb24gaXMuIFRoZSBwcm9wZXIgdmFsdWUgZGVwZW5k cyBvbiB0aGUNCiAgIGFwcGxpY2F0aW9uIGFuZCB0aGUgc2VydmljZSBuZWVkcy4NCg0KICAgQXMg YW4gb24tZGVtYW5kIE9BTSBmYXVsdCBtYW5hZ2VtZW50IG1lY2hhbmlzbSwgZm9yIGV4YW1wbGUg d2hlbg0KICAgdGhlcmUgaXMgYSBmaWJlciBjdXQsIExpbmsgRG93biBJbmRpY2F0aW9uIChMREkp IG1lc3NhZ2UgW1JGQzY0MjddDQogICBjYW4gYmUgZ2VuZXJhdGVkIGZyb20gdGhlIGZhaWx1cmUg cG9pbnQgYW5kIHByb3BhZ2F0ZWQgdG8gdGhlDQogICBNYWludGVuYW5jZSBFbnRpdHkgR3JvdXAg RW5kIFBvaW50cyAoTUVQcykgdG8gdHJpZ2dlciBpbW1lZGlhdGUNCiAgIHN3aXRjaC1vdmVyIGZy b20gd29ya2luZyB0byBwcm90ZWN0IHBhdGguIEFuIEFsYXJtIEluZGljYXRpb24gU2lnbmFsDQog ICAoQUlTKSBjYW4gYmUgcHJvcGFnYXRlZCBmcm9tIHRoZSBNYWludGVuYW5jZSBFbnRpdHkgR3Jv dXANCiAgIEludGVybWVkaWF0ZSBQb2ludCAoTUlQKSB0byB0aGUgTUVQcyBmb3IgYWxhcm0gc3Vw cHJlc3Npb24uIA0KDQogICBJbiBnZW5lcmFsLCBib3RoIHByb2FjdGl2ZSBhbmQgb24tZGVtYW5k IE9BTSB0b29scyBzaG91bGQgYmUgZW5hYmxlZA0KICAgdG8gZ3VhcmFudGVlIHNob3J0IHN3aXRj aC1vdmVyIHRpbWVzLiAgDQoNCjQuNy4gTVBMUy1UUCBhbmQgSVAvTVBMUyBJbnRlcndvcmtpbmcg Y29uc2lkZXJhdGlvbnMgIA0KDQogICBTaW5jZSBJUC9NUExTIGlzIGxhcmdlbHkgZGVwbG95ZWQg aW4gbW9zdCBTUHMnIG5ldHdvcmtzLCBNUExTLVRQIGFuZA0KICAgSVAvTVBMUyBJbnRlcndvcmtp bmcgaXMgaW5ldml0YWJsZSBpZiBub3QgYSByZWFsaXR5LiBIb3dldmVyLA0KICAgSW50ZXJ3b3Jr aW5nIGRpc2N1c3Npb24gaXMgb3V0IG9mIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LCBpdCBp cw0KICAgZm9yIGZ1cnRoZXIgc3R1ZHkuDQoNCjUuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIA0K DQogICBVbmRlciB0aGUgdXNlIGNhc2Ugb2YgTWV0cm8gYWNjZXNzIGFuZCBhZ2dyZWdhdGlvbiwg aW4gdGhlIHNjZW5hcmlvDQogICB3aGVyZSBzb21lIG9mIHRoZSBhY2Nlc3MgZXF1aXBtZW50IGlz IHBsYWNlZCBpbiBmYWNpbGl0aWVzIG5vdCBvd25lZA0KICAgYnkgdGhlIFNQLCB0aGUgc3RhdGlj IHByb3Zpc2lvbmluZyBtb2RlIG9mIE1QTFMtVFAgaXMgb2Z0ZW4gcHJlZmVycmVkDQogICBvdmVy IHRoZSBjb250cm9sIHBsYW5lIG9wdGlvbiBiZWNhdXNlIGl0IGVsaW1pbmF0ZXMgdGhlIHBvc3Np YmlsaXR5DQogICBvZiBhIGNvbnRyb2wgcGxhbmUgYXR0YWNrIHdoaWNoIG1heSBwb3RlbnRpYWxs eSBpbXBhY3QgdGhlIHdob2xlDQogICBuZXR3b3JrLiBUaGlzIHNjZW5hcmlvIGZhbGxzIGludG8g dGhlIFNlY3VyaXR5IFJlZmVyZW5jZSBNb2RlbCAyIGFzDQogICBkZXNjcmliZWQgaW4gW01QTFMt VFAgU2VjIEZXXS4NCg0KICAgU2ltaWxhciBsb2NhdGlvbiBpc3N1ZXMgYXBwbHkgdG8gdGhlIG1v YmlsZSB1c2UgY2FzZXMsIHNpbmNlDQogICBlcXVpcG1lbnQgaXMgb2Z0ZW4gcGxhY2VkIGluIHJl bW90ZSBhbmQgb3V0ZG9vciBlbnZpcm9ubWVudCwgd2hpY2gNCiANCg0KDQpGYW5nIGV0IGFsLiAg ICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNiwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSAx MV0NCgwNCklOVEVSTkVUIERSQUZUICAgICAgICBNUExTLVRQIFVzZSBDYXNlcyBhbmQgRGVzaWdu ICAgICAgRmVicnVhcnkgNiwgMjAxMw0KDQoNCiAgIGNhbiBpbmNyZWFzZSB0aGUgcmlzayBvZiB1 bi1hdXRob3JpemVkIGFjY2VzcyB0byB0aGUgZXF1aXBtZW50LiANCg0KICAgSW4gZ2VuZXJhbCwg Tk1TIGFjY2VzcyBjYW4gYmUgYSBjb21tb24gcG9pbnQgb2YgYXR0YWNrIGluIGFsbCBNUExTLVRQ DQogICB1c2UgY2FzZXMsIGFuZCBhdHRhY2tzIHRvIEdBTCBvciBHLUFDaCBhcmUgdW5pcXVlIHNl Y3VyaXR5IHRyZWF0cyB0bw0KICAgTVBMUy1UUC4gVGhlIE1QTFMtVFAgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgYXJlIGRpc2N1c3NlZCBpbiBNUExTLVRQDQogICBTZWN1cml0eSBGcmFtZXdvcmsg W01QTFMtVFAgU2VjIEZXXS4gR2VuZXJhbCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KICAgZm9y IE1QTFMgYW5kIEdNUExTIG5ldHdvcmtzIGFyZSBhZGRyZXNzZWQgaW4gU2VjdXJpdHkgRnJhbWV3 b3JrIGZvcg0KICAgTVBMUyBhbmQgR01QTFMgTmV0d29ya3MgW1JGQzU5MjBdLiAgDQoNCjYuIElB TkEgQ29uc2lkZXJhdGlvbnMgDQoNCiAgIFRoaXMgZG9jdW1lbnQgY29udGFpbnMgbm8gbmV3IElB TkEgY29uc2lkZXJhdGlvbnMuIA0KDQo3LiBBY2tub3dsZWRnZW1lbnRzDQoNCiAgIFRoZSBhdXRo b3JzIHdpc2ggdG8gdGhhbmsgQWRyaWFuIEZhcnJlbCBmb3IgaGlzIHJldmlldyBhcyBSb3V0aW5n DQogICBBcmVhIERpcmVjdG9yLCBBZHJpYW4ncyBkZXRhaWxlZCBjb21tZW50cyB3ZXJlIG9mIGdy ZWF0IGhlbHAgZm9yDQogICBpbXByb3ZpbmcgdGhlIHF1YWxpdHkgb2YgdGhpcyBkb2N1bWVudCwg YW5kIHRoYW5rIExvYSBBbmRlcnNzb24gYW5kDQogICBBZHJpYW4gRmFycmVsIGZvciB0aGVpciBj b250aW51ZWQgc3VwcG9ydCBhbmQgZ3VpZGFuY2UuIFRoZSBhdXRob3JzDQogICB3b3VsZCBhbHNv IGxpa2UgdG8gdGhhbmsgV2VpcWlhbmcgQ2hlbmcgZm9yIGhpcyBoZWxwZnVsIGlucHV0IG9uIExU RQ0KICAgTW9iaWxlIGJhY2toYXVsIGJhc2VkIG9uIGhpcyBrbm93bGVkZ2UgYW5kIGV4cGVyaWVu Y2UgaW4gcmVhbCB3b3JsZA0KICAgZGVwbG95bWVudCwgdGhhbmsgU3Rld2FydCBCcnlhbnQgZm9y IGhpcyB0ZXh0IGNvbnRyaWJ1dGlvbiBvbiB0aW1pbmcsDQogICB0aGFuayBBbmRyZXcgTWFsaXMg Zm9yIGhpcyBzdXBwb3J0IGFuZCB1c2UgY2FzZSBkaXNjdXNzaW9uLCB0aGFuaw0KICAgUGFibG8g RnJhbmssIEx1Y3kgWW9uZywgSHV1YiB2YW4gSGVsdm9vcnQsIFRvbSBQZXRjaCwgYW5kIEN1cnRp cw0KICAgVmlsbGFtaXphciBmb3IgdGhlaXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLCB0aGFu ayBKb3NlcGggWWVlIGZvcg0KICAgaGlzIEFQUFNESVIgcmV2aWV3IGFuZCBjb21tZW50cy4gDQoN CjguIFJlZmVyZW5jZXMNCg0KOC4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDNTY1 NF0gIE5pdmVuLUplbmtpbnMsIEIuLCBFZC4sIEJydW5nYXJkLCBELiwgRWQuLCBCZXR0cywgTS4s IEVkLiwNCiAgICAgICAgICAgICAgU3ByZWNoZXIsIE4uLCBhbmQgUy4gVWVubywgIlJlcXVpcmVt ZW50cyBvZiBhbiBNUExTDQogICAgICAgICAgICAgIFRyYW5zcG9ydCBQcm9maWxlIiwgUkZDIDU2 NTQsIFNlcHRlbWJlciAyMDA5Lg0KDQogICBbUkZDNTkyMF0gIEZhbmcsIEwuLCBFZC4sICJTZWN1 cml0eSBGcmFtZXdvcmsgZm9yIE1QTFMgYW5kIEdNUExTDQogICAgICAgICAgICAgIE5ldHdvcmtz IiwgUkZDIDU5MjAsIEp1bHkgMjAxMC4NCg0KICAgW1JGQzU5MjFdICBCb2NjaSwgTS4sIEVkLiwg QnJ5YW50LCBTLiwgRWQuLCBGcm9zdCwgRC4sIEVkLiwgTGV2cmF1LA0KICAgICAgICAgICAgICBM LiwgYW5kIEwuIEJlcmdlciwgIkEgRnJhbWV3b3JrIGZvciBNUExTIGluIFRyYW5zcG9ydA0KICAg ICAgICAgICAgICBOZXR3b3JrcyIsIFJGQyA1OTIxLCBKdWx5IDIwMTAuDQoNCiAgIFtSRkM2NDI2 XSAgR3JheSwgRS4sIEJhaGFkdXIsIE4uLCBCb3V0cm9zLCBTLiwgYW5kIFIuIEFnZ2Fyd2FsLCAi TVBMUw0KICAgICAgICAgICAgICBPbi1EZW1hbmQgQ29ubmVjdGl2aXR5IFZlcmlmaWNhdGlvbiBh bmQgUm91dGUgVHJhY2luZyIsDQogICAgICAgICAgICAgIFJGQyA2NDI2LCBOb3ZlbWJlciAyMDEx Lg0KDQogICBbUkZDNjQyN10gIFN3YWxsb3csIEcuLCBFZC4sIEZ1bGlnbm9saSwgQS4sIEVkLiwg Vmlnb3VyZXV4LCBNLiwgRWQuLA0KICAgICAgICAgICAgICBCb3V0cm9zLCBTLiwgYW5kIEQuIFdh cmQsICJNUExTIEZhdWx0IE1hbmFnZW1lbnQNCiANCg0KDQpGYW5nIGV0IGFsLiAgICAgICAgICAg ICAgRXhwaXJlcyBBdWd1c3QgNiwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwNCklO VEVSTkVUIERSQUZUICAgICAgICBNUExTLVRQIFVzZSBDYXNlcyBhbmQgRGVzaWduICAgICAgRmVi cnVhcnkgNiwgMjAxMw0KDQoNCiAgICAgICAgICAgICAgT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRp b24sIGFuZCBNYWludGVuYW5jZSAoT0FNKSIsDQogICAgICAgICAgICAgIFJGQyA2NDI3LCBOb3Zl bWJlciAyMDExLg0KDQogICBbUkZDNjQyOF0gIEFsbGFuLCBELiwgRWQuLCBTd2FsbG93IEVkLiwg Ry4sIGFuZCBKLiBEcmFrZSBFZC4sDQogICAgICAgICAgICAgICJQcm9hY3RpdmUgQ29ubmVjdGl2 aXR5IFZlcmlmaWNhdGlvbiwgQ29udGludWl0eSBDaGVjaywNCiAgICAgICAgICAgICAgYW5kIFJl bW90ZSBEZWZlY3QgSW5kaWNhdGlvbiBmb3IgdGhlIE1QTFMgVHJhbnNwb3J0DQogICAgICAgICAg ICAgIFByb2ZpbGUiLCBSRkMgNjQyOCwgTm92ZW1iZXIgMjAxMS4NCg0KDQo4LjIuIEluZm9ybWF0 aXZlIFJlZmVyZW5jZXMNCg0KICAgW1JGQzUzMTddICBCcnlhbnQsIFMuLCBFZC4sIGFuZCBMLiBB bmRlcnNzb24sIEVkLiwgIkpvaW50IFdvcmtpbmcNCiAgICAgICAgICAgICAgVGVhbSAoSldUKSBS ZXBvcnQgb24gTVBMUyBBcmNoaXRlY3R1cmFsIENvbnNpZGVyYXRpb25zIGZvcg0KICAgICAgICAg ICAgICBhIFRyYW5zcG9ydCBQcm9maWxlIiwgUkZDIDUzMTcsIEZlYnJ1YXJ5IDIwMDkuDQoNCiAg IFtSRkM2MzcyXSAgU3ByZWNoZXIsIE4uLCBFZC4sIGFuZCBBLiBGYXJyZWwsIEVkLiwgIk1QTFMg VHJhbnNwb3J0DQogICAgICAgICAgICAgIFByb2ZpbGUgKE1QTFMtVFApIFN1cnZpdmFiaWxpdHkg RnJhbWV3b3JrIiwgUkZDIDYzNzIsDQogICAgICAgICAgICAgIFNlcHRlbWJlciAyMDExLg0KDQog ICBbUkZDNjY2OV0gIFNwcmVjaGVyLCBOLiBhbmQgTC4gRmFuZywgIkFuIE92ZXJ2aWV3IG9mIHRo ZSBPcGVyYXRpb25zLA0KICAgICAgICAgICAgICBBZG1pbmlzdHJhdGlvbiwgYW5kIE1haW50ZW5h bmNlIChPQU0pIFRvb2xzZXQgZm9yIE1QTFMtDQogICAgICAgICAgICAgIEJhc2VkIFRyYW5zcG9y dCBOZXR3b3JrcyIsIFJGQyA2NjY5LCBKdWx5IDIwMTIuDQoNCg0KICAgW01QTFMtVFAgU2VjIEZX XSBGYW5nLCBMLiBFZC4sIE5pdmVuLUplbmtpbnMsIEIuLCBFZC4sIE1hbnNmaWVsZCwgIA0KICAg ICAgICAgICAgICBTLiwgRWQuLCBhbmQgUi4gR3JhdmVtYW4sIEVkLiwgIk1QTFMtVFAgU2VjdXJp dHkNCiAgICAgICAgICAgICAgRnJhbWV3b3JrLCIgIGRyYWZ0LWlldGYtbXBscy10cC1zZWN1cml0 eS1mcmFtZXdvcmstMDcudHh0LA0KICAgICAgICAgICAgICBKYW51YXJ5IDIwMTMuDQoNCiAgIFsx NTg4b3Zlcm1wbHNdLCBEYXZhcmksIFMuLCBPcmVuLCBBLiwgQmhhdGlhLCBNLiwgUm9iZXJ0cywg UC4sIGFuZCAgDQogICAgICAgICAgICAgIEwuIE1vbnRpbmksICJUcmFuc3BvcnRpbmcgVGltaW5n IG1lc3NhZ2VzIG92ZXIgTVBMUw0KICAgICAgICAgICAgICBOZXR3b3JrcywiIGRyYWZ0LWlldGYt dGljdG9jLTE1ODhvdmVybXBscy0wMy50eHQsIE9jdG9iZXINCiAgICAgICAgICAgICAgMjAxMi4N Cg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAgICAgTHV5dWFuIEZhbmcgDQogICAgICBDaXNj byBTeXN0ZW1zLCBJbmMuIA0KICAgICAgMTExIFdvb2QgQXZlLiBTb3V0aCANCiAgICAgIElzZWxp biwgTkogMDg4MzANCiAgICAgIFVuaXRlZCBTdGF0ZXMNCiAgICAgIEVtYWlsOiBsdWZhbmdAY2lz Y28uY29tDQoNCiAgICAgIE5hYmlsIEJpdGFyIA0KICAgICAgVmVyaXpvbiANCiAgICAgIDQwIFN5 bHZhbiBSb2FkIA0KICAgICAgV2FsdGhhbSwgTUEgMDIxNDUNCiANCg0KDQpGYW5nIGV0IGFsLiAg ICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNiwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSAx M10NCgwNCklOVEVSTkVUIERSQUZUICAgICAgICBNUExTLVRQIFVzZSBDYXNlcyBhbmQgRGVzaWdu ICAgICAgRmVicnVhcnkgNiwgMjAxMw0KDQoNCiAgICAgIFVuaXRlZCBTdGF0ZXMgDQogICAgICBF bWFpbDogbmFiaWwuYml0YXJAdmVyaXpvbi5jb20NCg0KICAgICAgUmF5bW9uZCBaaGFuZyANCiAg ICAgIEFsY2F0ZWwtTHVjZW50ICANCiAgICAgIDcwMSBNaWRkbGVmaWVsZCBSb2FkIA0KICAgICAg TW91bnRhaW4gVmlldywgQ0EgOTQwNDMNCiAgICAgIFVuaXRlZCBTdGF0ZXMgDQogICAgICBFbWFp bDogcmF5bW9uZC56aGFuZ0BhbGNhdGVsLWx1Y2VudC5jb20NCg0KICAgICAgTWFzYWhpcm8gRGFp a29rdQ0KICAgICAgS0RESSBjb3Jwb3JhdGlvbiANCiAgICAgIDMtMTEtMTEuSWlkYWJhc2hpLCBD aGl5b2Rha3UsIFRva3lvDQogICAgICBKYXBhbiAgICANCiAgICAgIEVtYWlsOiBtcy1kYWlrb2t1 QGtkZGkuY29tIA0KDQogICAgICBQaW5nIFBhbg0KICAgICAgSW5maW5lcmENCiAgICAgIFVuaXRl ZCBTdGF0ZXMNCiAgICAgIEVtYWlsOiBwcGFuQGluZmluZXJhLmNvbQ0KDQpDb250cmlidXRvcnMn IEFkZHJlc3Nlcw0KDQogICAgICBLYW0gTGVlIFlhcCANCiAgICAgIFhPIENvbW11bmljYXRpb25z IA0KICAgICAgMTM4NjUgU3VucmlzZSBWYWxsZXkgRHJpdmUsIA0KICAgICAgSGVybmRvbiwgVkEg MjAxNzENCiAgICAgIFVuaXRlZCBTdGF0ZXMgDQogICAgICBFbWFpbDoga2x5YXBAeG8uY29tIA0K DQogICAgICBEYW4gRnJvc3QgDQogICAgICBDaXNjbyBTeXN0ZW1zLCBJbmMuDQogICAgICBVbml0 ZWQgS2luZ2RvbSANCiAgICAgIEVtYWlsOmRhbmZyb3N0QGNpc2NvLmNvbSANCg0KICAgICAgSGVu cnkgWXUgDQogICAgICBUVyBUZWxlY29tIA0KICAgICAgMTA0NzUgUGFyayBNZWFkb3cgRHIuIA0K ICAgICAgTGl0dGxldG9uLCBDTyA4MDEyNA0KICAgICAgVW5pdGVkIFN0YXRlcw0KICAgICAgRW1h aWw6IGhlbnJ5Lnl1QHR3dGVsZWNvbS5jb20gDQoNCiAgICAgIEppYW4gUGluZyBaaGFuZyAgIA0K ICAgICAgQ2hpbmEgVGVsZWNvbSwgU2hhbmdoYWkgICAgDQogICAgICBSb29tIDM0MDIsIDIxMSBT aGkgSmkgRGEgRGFvIA0KICAgICAgUHUgRG9uZyBEaXN0cmljdCwgU2hhbmdoYWkNCiAgICAgIENo aW5hIA0KICAgICAgRW1haWw6IHpoYW5nanBAc2h0ZWwuY29tLmNuIA0KIA0KDQoNCkZhbmcgZXQg YWwuICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA2LCAyMDEzICAgICAgICAgICAgICAgIFtQ YWdlIDE0XQ0KDA0KSU5URVJORVQgRFJBRlQgICAgICAgIE1QTFMtVFAgVXNlIENhc2VzIGFuZCBE ZXNpZ24gICAgICBGZWJydWFyeSA2LCAyMDEzDQoNCg0KICAgICAgTGVpIFdhbmcgIA0KICAgICAg TGltZSBOZXR3b3Jrcw0KICAgICAgU3RyYW5kdmVpZW4gMzAsIDEzNjYgTHlzYWtlcg0KICAgICAg Tm9yd2F5DQogICAgICBFbWFpbDogbGVpLndhbmdAbGltZW5ldHdvcmtzLm5vDQoNCiAgICAgIE1h Y2goR3VveWkpIENoZW4gDQogICAgICBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLiANCiAg ICAgIE5vLiAzIFhpbnhpIFJvYWQgDQogICAgICBTaGFuZ2RpIEluZm9ybWF0aW9uIEluZHVzdHJ5 IEJhc2UgDQogICAgICBIYWktRGlhbiBEaXN0cmljdCwgQmVpamluZyAxMDAwODUgDQogICAgICBD aGluYSANCiAgICAgIEVtYWlsOiBtYWNoQGh1YXdlaS5jb20gDQoNCiAgICAgIE51cml0IFNwcmVj aGVyICANCiAgICAgIE5va2lhIFNpZW1lbnMgTmV0d29ya3MgDQogICAgICAzIEhhbmFnYXIgU3Qu IE5ldmUgTmUnZW1hbiBCIA0KICAgICAgSG9kIEhhc2hhcm9uLCA0NTI0MSANCiAgICAgIElzcmFl bCANCiAgICAgIEVtYWlsOiBudXJpdC5zcHJlY2hlckBuc24uY29tIA0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpGYW5nIGV0IGFs LiAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNiwgMjAxMyAgICAgICAgICAgICAgICBbUGFn ZSAxNV0NCg== --_002_0DB8F45437AB844CBB5102F807A0AD931027A604xmbrcdx03ciscoc_-- From lufang@cisco.com Thu Feb 7 07:28:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262FE21F862A for ; Thu, 7 Feb 2013 07:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.09 X-Spam-Level: X-Spam-Status: No, score=-10.09 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ1iiImYYixw for ; Thu, 7 Feb 2013 07:28:11 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E254621F8530 for ; Thu, 7 Feb 2013 07:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15235; q=dns/txt; s=iport; t=1360250891; x=1361460491; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Fk5aMtPOoe8xe6EQRKs0KF3adN6E4dg3dAEYG8Z0Fkk=; b=lLwZttfiIDFzC5t4u8xT/yELBJrfEcV1kLH1ijKadwW+oJ4cTEpRtr9m VbV1rwbeOG7yY0TavGWNMW5IV+5UVmVSEs6fqbIp9CW62B1Ldqn0tZgWh hGXwXaqeRyUt54xgFlozqzcPLTUbbrSaKl7UWoj5vGHrH4oyMzIeWWGrU E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAK7GE1GtJXHA/2dsb2JhbABFgkm+HRZzgh8BAQEEJ1IMBgEIDgMDAQILHTkUCQgCBA4FCId3Aw8MvwiMFoRlYQOmc4MAgiQ X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; d="scan'208,217";a="174540092" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 07 Feb 2013 15:28:10 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r17FSARS014934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Feb 2013 15:28:10 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 09:28:09 -0600 From: "Luyuan Fang (lufang)" To: Joseph Yee Thread-Topic: APPSDIR Review of draft-ietf-mpls-tp-use-cases-and-design-06.txt Thread-Index: AQHOBIz4g7lcjevZhEOi+pLg+lOtVJht1GqAgAERUYD//7FjgA== Date: Thu, 7 Feb 2013 15:28:09 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD931027ABF3@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.82.228.80] Content-Type: multipart/alternative; boundary="_000_0DB8F45437AB844CBB5102F807A0AD931027ABF3xmbrcdx03ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 07 Feb 2013 15:07:50 -0800 Cc: "draft-ietf-mpls-tp-use-cases-and-design.all@tools.ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR Review of draft-ietf-mpls-tp-use-cases-and-design-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: Thu, 07 Feb 2013 15:28:12 -0000 --_000_0DB8F45437AB844CBB5102F807A0AD931027ABF3xmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Great, thank you again, Joseph! Luyuan From: Joseph Yee > Date: Thursday, February 7, 2013 7:09 AM To: Luyuan Fang > Cc: "draft-ietf-mpls-tp-use-cases-and-design.all@tools.ietf.org" >, "apps-discuss@ietf.org" > Subject: Re: APPSDIR Review of draft-ietf-mpls-tp-use-cases-and-design-06.t= xt Glad that you find the review helpful. I looked into the attached draft an= d it addressed all issues from the review. Cheers Joseph On Wed, Feb 6, 2013 at 10:51 PM, Luyuan Fang (lufang) > wrote: Hi Joseph, Thank you very much for your review and comments, really appreciate your help! I updated the document based on your comments (see in-line for details), also acknowledged your review and comment in the doc. I attached the updated text file here. Thanks, Luyuan -----Original Message----- From: Joseph Yee > Date: Wednesday, February 6, 2013 9:10 AM To: "draft-ietf-mpls-tp-use-cases-and-design.all@tools.ietf.org" >, "apps-discuss@ietf.org" > Subject: APPSDIR Review of draft-ietf-mpls-tp-use-cases-and-design-06.txt Resent-From: > Resent-To: >, >, Luyuan Fang >, >, Nabil Bitar >, >, >= , >, > Resent-Date: Wednesday, February 6, 2013 9:11 AM >I have been selected as the Applications Area Review Team reviewer for >this draft (for background on apps-review, please see >http://www.apps.ietf.org/content/applications-area-review-team). > >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-mpls-tp-use-cases-and-design-06 >Title: MPLS-TP Applicability; Use Cases and Design >Reviewer: Joseph Yee >Review Date: Feb 6, 2013 > >Summary: This draft is ready for publication, would be better if the >editorial changes can put into the draft. > >Major Issues: >none > >Minor Issues: >(1) "Applicability" in Abstract and Introduction >"This document provides applicability, use case studies and network >design considerations for the Multiprotocol Label Switching Transport >Profile (MPLS-TP)." > >Mostly because of how my brain was wired (or how my high school >teacher wired my brain). When I see text structured this way, I'm >expecting three sections rather than two. Note I have no issues about >the discussion of applicability in this draft at all. Then I realized >more from how the title was written that it's a draft with two major >topic sections rather than three. > >My suggestion for the text: >"This document provides the applicability of Multiprotocol Label >Switching Transport Profile (MPLS-TP) with use case studies and >network design considerations." [luyuan] Yes, this is better, I replaced the old text with your suggested text. > >(2) Section 1 Introduction 5th paragraph >"LSP Ping Extension for on-demand CC-CV [RFC6426], fault allocation, >and remote integrity check." >"and switch-over triggering with Link Defect Indication (LDI)" >Any reference for the 'fault allocation, and remote integrity check" >and LDI that could be added to the draft? [luyuan] Good point. Reading through that paragraph again, I removed "fault allocation, and remote integrity check." The tools for fault allocation and remote integrity check are LSP Ping extension and LDI, and they are covered in the text. For LDI, I added reference [RFC6427]. > >(3) Section 2 Terminology: 4G >"4G 4th Generation Mobile network: LTE" >This is close to nits. '4G' is not only LTE right? Do you mean to >use 4G to refer only LTE is this draft? If the section title "4G/LTE >Mobile Backhaul" and its text at section 3.3.2 does not confuse >readers who is more familiar with the topic, I don't think this is an >issue. [luyuan] You are right, 4G includes more than LTE. I removed LTE in the terminology definition for 4G. > > >Nits: >(1) Terminology through out the draft >There are several occasions where acronyms were not logged in the >terminology section (ex. PW), and some text don't use terminology >consistently (ex. SP vs service provider). These are not the only >two, but I think RFC Editors provides the best help in this regard. [luyuan] Added PW in the terminology. I scanned through the doc, both "SP" and "Service Provider" are used, did not see any lower case occasions. I think it is OK. Will work with RFC editor if changes are needed. > >(2) Section 7 Acknowledgements >"... thank Stewart for his text contribution on timing ..." >Stewart who? ;) [luyuan] Fixed, -> "Stewart Bryant". > >Best Regards, >Joseph Yee Thanks, Luyuan --_000_0DB8F45437AB844CBB5102F807A0AD931027ABF3xmbrcdx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Great, thank you again, Joseph!
Luyuan

From: Joseph Yee <jyee@afilias.info>
Date: Thursday, February 7, 2013 7:= 09 AM
To: Luyuan Fang <lufang@cisco.com>
Cc: "draft-ietf-mpls-tp-use= -cases-and-design.all@tools.ietf.org" <draft-ietf-mpls-tp-us= e-cases-and-design.all@tools.ietf.org>, "apps-discuss@ietf.org&q= uot; <apps-discuss@ietf.org= >
Subject: Re: APPSDIR Review of draf= t-ietf-mpls-tp-use-cases-and-design-06.txt

Glad that you find the review helpful.  I looked into the attache= d draft and it addressed all issues from the review.

Cheers
Joseph

On Wed, Feb 6, 2013 at 10:51 PM, Luyuan Fang (lu= fang) <lufang@cisco.com<= /a>> wrote:
Hi Joseph,

Thank you very much for your review and comments, really appreciate your help!
I updated the document based on your comments (see in-line for details), also acknowledged your review and comment in the doc.

I attached the updated text file here.

Thanks,
Luyuan


-----Original Message-----
From: Joseph Yee <jyee@afilias.info= >
Date: Wednesday, February 6, 2013 9:10 AM
To: "draft-ietf-mpls-tp-use-cases-and-design.all@tools.ietf.org= "
<draft-ietf-mpls-tp-use-cases-and-design.all@tools.ietf.org>,<= br> "apps-discuss@ietf.org&qu= ot; <apps-discuss@ietf.org&= gt;
Subject: APPSDIR Review of draft-ietf-mpls-tp-use-cases-and-design-06.txt Resent-From: <draf= t-alias-bounces@tools.ietf.org>
Resent-To: <afarrel@juniper.net>, <loa@pi.nu>, Luyuan Fang
<lufang@cisco.com>, <ms-daikoku@kddi.com>, Nabil Bitar<= br> <nabil.bitar@verizon.com&= gt;, <ppan@infinera.com>, <raymond.zhang@alcat= el-lucent.com>, <rcallon@j= uniper.net>,
<swallow@cisco.com>
Resent-Date: Wednesday, February 6, 2013 9:11 AM

>I have been selected as the Applications Area Review Team reviewer for<= br> >this draft (for background on apps-review, please see
>http://www.apps.ietf.org/content/applications-area-re= view-team).
>
>Please resolve these comments along with any other Last Call comments >you may receive. Please wait for direction from your document shepherd<= br> >or AD before posting a new version of the draft.
>
>Document: draft-ietf-mpls-tp-use-cases-and-design-06
>Title: MPLS-TP Applicability; Use Cases and Design
>Reviewer: Joseph Yee
>Review Date: Feb 6, 2013
>
>Summary: This draft is ready for publication, would be better if the >editorial changes can put into the draft.
>
>Major Issues:
>none
>
>Minor Issues:
>(1) "Applicability" in Abstract and Introduction
>"This document provides applicability, use case studies and networ= k
>design considerations for the Multiprotocol Label Switching Transport >Profile (MPLS-TP)."
>
>Mostly because of how my brain was wired (or how my high school
>teacher wired my brain). When I see text structured this way, I'm
>expecting three sections rather than two.  Note I have no issues a= bout
>the discussion of applicability in this draft at all.  Then I real= ized
>more from how the title was written that it's a draft with two major >topic sections rather than three.
>
>My suggestion for the text:
>"This document provides the applicability of Multiprotocol Label >Switching Transport Profile (MPLS-TP) with use case studies and
>network design considerations."

[luyuan] Yes, this is better, I replaced the old text with your suggested text.
>
>(2) Section 1 Introduction 5th paragraph
>"LSP Ping Extension for on-demand CC-CV [RFC6426], fault allocatio= n,
>and remote integrity check."
>"and switch-over triggering with Link Defect Indication (LDI)"= ;
>Any reference for the 'fault allocation, and remote integrity check&quo= t;
>and LDI that could be added to the draft?

[luyuan] Good point.

Reading through that paragraph again, I removed "fault allocation, and=
remote integrity check." The tools for fault allocation and remote
integrity check are LSP Ping extension and LDI, and they are covered in
the text.


For LDI, I added reference [RFC6427].

>
>(3) Section 2 Terminology: 4G
>"4G       4th Generation Mobile network: LTE"<= br> >This is close to nits.  '4G' is not only LTE right?  Do you m= ean to
>use 4G to refer only LTE is this draft?  If the section title &quo= t;4G/LTE
>Mobile Backhaul" and its text at section 3.3.2 does not confuse >readers who is more familiar with the topic, I don't think this is an >issue.

[luyuan] You are right, 4G includes more than LTE. I removed LTE in the
terminology definition for 4G.

>
>
>Nits:
>(1) Terminology through out the draft
>There are several occasions where acronyms were not logged in the
>terminology section (ex. PW), and some text don't use terminology
>consistently (ex. SP vs service provider).  These are not the only=
>two, but I think RFC Editors provides the best help in this regard.

[luyuan] Added PW in the terminology.
I scanned through the doc, both "SP" and "Service Provider&q= uot; are used, did
not see any lower case occasions. I think it is OK. Will work with RFC
editor if changes are needed.

>
>(2) Section 7 Acknowledgements
>"...  thank Stewart for his text contribution on timing ...&q= uot;
>Stewart who?  ;)

[luyuan] Fixed, -> "Stewart Bryant".
>
>Best Regards,
>Joseph Yee

Thanks,
Luyuan


 --_000_0DB8F45437AB844CBB5102F807A0AD931027ABF3xmbrcdx03ciscoc_-- From yoshiro.yoneya@jprs.co.jp Thu Feb 7 22:58:54 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48EE21F8814; Thu, 7 Feb 2013 22:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HctdFz5ou3hg; Thu, 7 Feb 2013 22:58:54 -0800 (PST) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 0B83521F880F; Thu, 7 Feb 2013 22:58:53 -0800 (PST) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id r186wqGm017179; Fri, 8 Feb 2013 15:58:52 +0900 X-AuditID: ac120820-b7fec6d000005acc-6f-5114a22ce759 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 48.29.23244.B22A4115; Fri, 8 Feb 2013 15:58:52 +0900 (JST) Date: Fri, 8 Feb 2013 15:58:51 +0900 From: Yoshiro YONEYA To: apps-discuss@ietf.org, draft-ietf-mpls-tp-security-framework.all@tools.ietf.org Message-Id: <20130208155851.85ff829da0b5e2348cc39037@jprs.co.jp> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsWyRoiFT1dnkUigweY2JovVL1ewWdx738Fk MePPRGYHZo8lS34yeXy5/JktgCmKyyYlNSezLLVI3y6BK2PF6eusBac4Kma/W8/SwPiVrYuR g0NCwETi26mcLkZOIFNM4sK99UBhLg4hgeOMErc3/WEESbAIqEgsPjQFzGYTMJD4tew3E4gt IhAq8fxXM5jNLCAo0fT+FQuILSzgLHF4zR9WEJtXwEFi16HVLBALLCQuNHWwg+zlBar/u0MY xGQWUJdYP08IYoq8RPPW2cwTGHlnIRTNQiiahaRoASPzKkaZ/LQ03eLUvJTi3HQDQ72Syny9 rIKiYr1kEL2JERxcHAo7GGecMjjEKMDBqMTD23NNOFCINbGsuDL3EKMkB5OSKK/2PJFAIb6k /JTKjMTijPii0pzU4kOMEhzMSiK8ojOBcrwpiZVVqUX5MClpDhYlcd7jZ3f4CQmkJ5akZqem FqQWwWRlODiUJHiPLwBqFCxKTU+tSMvMKUFIM3FwggznARrOuRBkeHFBYm5xZjpE/hSjpJQ4 70uQZgGQREZpHlzvK0ZxoBeEeb+CZHmAiQKu6xXQQCaggeszhUEGliQipKQaGLOzDe+q/jX7 puC6uinl/kdm/+Cgfc1Fi9nM9y1cKmOQ2VOl463/vVrAXeGTj+R/L8XHsV/s2Jf0zda95zNX U/u78JotOvsV25k9DE64f5u89N8xyXMhGUk7pXVuNerZb9STY9kqbLz8iNbKq0JHctn5NRPq JvQw/Obd4LSYofK6w9LpPtwKSizFGYmGWsxFxYkAPKFoZdECAAA= Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR Review of draft-ietf-mpls-tp-security-framework-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 06:58:54 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​ http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mpls-tp-security-framework-08 Title: MPLS-TP Security Framework Reviewer: Yoshiro Yoneya Review Date: 2013-02-08 IETF Last Call Date: 2013-02-06 IESG Telechat Date: 2013-02-21 Summary: This draft is almost ready for publication as an Informational RFC. Major Issues: none Minor Issues: - If target reader of this document described in Abstract and Introduction section, it would be better and much clear. Such as: "This document is intended to be a guideline especially for MPLS-TP protocol designers, service providers and equipment vendors.". Nits: none Regards, -- Yoshiro YONEYA From anthonybryan@gmail.com Thu Feb 7 23:12:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AF221F8901 for ; Thu, 7 Feb 2013 23:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.236 X-Spam-Level: X-Spam-Status: No, score=-3.236 tagged_above=-999 required=5 tests=[AWL=0.363, 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 Frj2CSnHOLHt for ; Thu, 7 Feb 2013 23:12:46 -0800 (PST) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 44CE621F88DB for ; Thu, 7 Feb 2013 23:12:46 -0800 (PST) Received: by mail-qe0-f47.google.com with SMTP id 2so1542224qea.6 for ; Thu, 07 Feb 2013 23:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=+QH6mzQFqhZ6EEfW6uu7kthaBjqRcQOSUhZafAdooWs=; b=JdfbCyXMoNr90B1xoFsFsRy1ua7Y6iEXtRxE3ntG3/icy7b469dR7JT0aAwlePFpdQ 8piQweDhAbyFPy+jpkMpyJOv63Yu+nU6z6dSjmVFzGDACFhk0ytmhNZV6If7ZxHDaiQ3 n0VQoy55wMRxSyA788EHRCkUqRQYodDHV0/K8nLaAuRigKT753m2NjrxcvQ3SuazIufM de/L0en6rUP3bbx9L+DPCjtjCPGMUeFp/MAyHI1jZ5uiXTftgDtwOgyok1DoS9Rw3eyp axRAlQn9GIEJldUjFIxyfa4aDrgu9S62lc4UOwm9m3MUXdVHeRTIca46Kgj0P2JvrbRv Xu7Q== MIME-Version: 1.0 X-Received: by 10.229.172.162 with SMTP id l34mr378878qcz.81.1360307565743; Thu, 07 Feb 2013 23:12:45 -0800 (PST) Received: by 10.49.12.36 with HTTP; Thu, 7 Feb 2013 23:12:45 -0800 (PST) Date: Fri, 8 Feb 2013 02:12:45 -0500 Message-ID: From: Anthony Bryan To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Metalink Clients, Publishers, and Caches / FTP HASH, RANG, & LOCK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Feb 2013 07:12:47 -0000 so, we're working on a draft on Metalink/XML Clients, Publishers, and Caches. Metalinks list mirrors, hashes, & digital signatures to automatically improve downloads. RFC 5854 describes the Metalink/XML format but it has a few normative requirements for clients - but not all, hence this new draft. we welcome comments. my question is, do we reference the client requirements or just copy them into the new draft? and we are working on an ID of the earlier Metalink community/pre-IETF version, which I suppose will be Informational (like the OAuth 1.0 RFC) or maybe Historic? http://tools.ietf.org/html/draft-bryan-metalink-client also, Tatsuhiro, Daniel, Tim, (the authors of FTP & more clients aria2, curl, & FileZilla) & I have been working on a few FTP drafts, which should be discussed on ftpext@ietf.org if anyone is interested. HASH FTP command to be used by clients to request cryptographic hashes of files. http://tools.ietf.org/html/draft-bryan-ftpext-hash RANG command to be used by clients to designate a start and end point to permit restarts and repairs of interrupted data transfers in STREAM mode. http://tools.ietf.org/html/draft-bryan-ftp-range LOCK command to be used by clients to request the server to use the control connection for data transfers, using a single port instead of two. http://tools.ietf.org/html/draft-bryan-ftp-lock issues, etc are at https://github.com/antbryan/internetdraft thanks, -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From dret@berkeley.edu Fri Feb 8 02:59:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F2321F86AA for ; Fri, 8 Feb 2013 02:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-OmH5ro-kur for ; Fri, 8 Feb 2013 02:59:14 -0800 (PST) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id C895221F86B3 for ; Fri, 8 Feb 2013 02:59:14 -0800 (PST) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretpro.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1U3lfk-0003tN-G2; Fri, 08 Feb 2013 02:59:14 -0800 Message-ID: <5114DA7C.3060500@berkeley.edu> Date: Fri, 08 Feb 2013 11:59:08 +0100 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: REST-Discuss , "apps-discuss@ietf.org application-layer protocols" References: <20130208102023.19499.12441.idtracker@ietfa.amsl.com> In-Reply-To: <20130208102023.19499.12441.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130208102023.19499.12441.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Fwd: New Version Notification for draft-wilde-xml-patch-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: Fri, 08 Feb 2013 10:59:15 -0000 A new version of I-D, draft-wilde-xml-patch-02.txt has been successfully submitted by Erik Wilde and posted to the IETF repository. Filename: draft-wilde-xml-patch Revision: 02 Title: A Media Type for XML Patch Operations Creation date: 2013-02-08 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-wilde-xml-patch-02.txt Status: http://datatracker.ietf.org/doc/draft-wilde-xml-patch Htmlized: http://tools.ietf.org/html/draft-wilde-xml-patch-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-wilde-xml-patch-02 Abstract: The XML Patch media type "application/xml-patch+xml" defines an XML document structure for expressing a sequence of patch operations that are applied to an XML document. The XML Patch document format's foundations are defined in RFC 5261, this specification defines a document format and a media type registration, so that XML Patch documents can be labeled with a media type, for example in HTTP conversations. Note to Readers This draft should be discussed on the apps-discuss mailing list [13]. Online access to all versions and files is available at github [14]. From dave@cridland.net Fri Feb 8 12:18:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB7721F8B77 for ; Fri, 8 Feb 2013 12:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56X+0MQcU9ex for ; Fri, 8 Feb 2013 12:18:46 -0800 (PST) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF5F21F8B70 for ; Fri, 8 Feb 2013 12:18:46 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id un3so4275896obb.24 for ; Fri, 08 Feb 2013 12:18:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Jzy1AI084bhVlbrJgpQVgaeWQyWtuy6hjdaQO1zZae0=; b=R02EYh82MQHUX2/1uaXjPdEMP8DXTH+y5sOmNPdzvFhGZCdJ3qm/VuhFMaRY9anagh O2XwnRCzqoLxl+3YxdVimGb1mV8Xsm/v/f4sniesllVGJydq1HB0E+YkCBqFnrrUZcLE guWaH4+jZeOL7Md+ryweiG72cTPnTM9HpOWdM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Jzy1AI084bhVlbrJgpQVgaeWQyWtuy6hjdaQO1zZae0=; b=HmyP9r176w9geb4QMyP+T5qYm8WUutbJUtq3Khp4sGGzwbQAekAHqJWCtff5NrpAcr 4NUca84MWcN2QyRFCxeuiy2miyNITgtnDDu242EAVX+TnEugHhIW32XK1py4vyTKTmHA NE3AqstHUAlLcj3kQtKkHkUdv0CCc2hzxVm7iN7DeChYy4vYcj2Uo3doq0M5ZjH2B4Et sE6KSgs59JKKC4A5xYSPaKnlNmFmHTPmr/2xZAILWhxoiJ7uQSPuSQiTPklS6tUfh+sl ve6aUGLCLxxaZAgMIPRstJPNsUsIsXXZbeWAb0x/mj49SFZ7gplRl/K0Y1lTJ+etpMPJ l+aQ== MIME-Version: 1.0 X-Received: by 10.182.250.109 with SMTP id zb13mr5218716obc.38.1360354725571; Fri, 08 Feb 2013 12:18:45 -0800 (PST) Received: by 10.60.27.74 with HTTP; Fri, 8 Feb 2013 12:18:45 -0800 (PST) Received: by 10.60.27.74 with HTTP; Fri, 8 Feb 2013 12:18:45 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Feb 2013 20:18:45 +0000 Message-ID: From: Dave Cridland To: "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary=14dae93b58902fade704d53c44c9 X-Gm-Message-State: ALoCoQkiLcn4Jrks6eqO18Zv/aXU/EYEva5pmA/+K0wFRi2C/EiyxJEHFoSNKLCGXM3O6OjuJYKF Cc: "draft-ietf-ospf-rfc3137bis.all@tools.ietf.org" , iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] AppsDir Review of draft-ietf-ospf-rfc3137bis-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 20:18:47 -0000 --14dae93b58902fade704d53c44c9 Content-Type: text/plain; charset=ISO-8859-1 This looks substantially clearer, thanks. --14dae93b58902fade704d53c44c9 Content-Type: text/html; charset=ISO-8859-1

This looks substantially clearer, thanks.

--14dae93b58902fade704d53c44c9-- From derhoermi@gmx.net Fri Feb 8 13:59:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB9F21F8B73 for ; Fri, 8 Feb 2013 13:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=-1.950, 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 OGWSsDQWLk1m for ; Fri, 8 Feb 2013 13:59:05 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4A70621F8B6D for ; Fri, 8 Feb 2013 13:59:05 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MgJFg-1UGUmc1C4s-00NfyC for ; Fri, 08 Feb 2013 22:59:04 +0100 Received: (qmail invoked by alias); 08 Feb 2013 21:59:03 -0000 Received: from pD9539135.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [217.83.145.53] by mail.gmx.net (mp024) with SMTP; 08 Feb 2013 22:59:03 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19DQesvcqBDcTKHTlWqezAGC/zDxed4QNeTaWpNM+ QnGs0Rcv514tVa From: Bjoern Hoehrmann To: apps-discuss@ietf.org Date: Fri, 08 Feb 2013 22:59:06 +0100 Message-ID: <50tah89cmijfqd0bdd2be9grl46uveivgd@hive.bjoern.hoehrmann.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Subject: [apps-discuss] RFC 6839 (media type suffixes) formatting error? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Feb 2013 21:59:06 -0000 Hi, In http://tools.ietf.org/html/rfc6839#section-3.1 there seems to be a formatting error (also present in the ordinary plain text version): The syntax and semantics for fragment identifiers for a specific "xxx/yyy+json" SHOULD be processed as follows: For cases defined in +json, where the fragment identifier resolves per the +json rules, then process as specified in +json. For cases defined in +json, where the fragment identifier does not resolve per the +json rules, then process as specified in "xxx/yyy+json". For cases not defined in +json, then process as specified in "xxx/yyy+json". The second paragraph apparently should be indented like the following ones. Am I missing something? Should I file this as errata item? regards, -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From sm@resistor.net Fri Feb 8 15:44:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A170121F8A77 for ; Fri, 8 Feb 2013 15:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 t6xPkBe1QmjB for ; Fri, 8 Feb 2013 15:44:16 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA72721F8A4F for ; Fri, 8 Feb 2013 15:44:15 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r18Ni24J013513; Fri, 8 Feb 2013 15:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360367048; bh=BLLrxHj/EUx5yEz2JYJruRmNCELN7fWXxoiepqNosIo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=upRcunB/6R4w4YpRlhu/q/cIO14DptbWTxp2ccDU6HfasQeRmb3YY/3yMrizW4Q8p PT59R3towq+SEa6gcAWW/137+Gn1iYA0V+o1PtD++xNc6JIPSK/3ITU5CEYcuTMT85 UkA3mM4fQupCS6YwP8va3doBgviBMm73wPVK5Tfs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1360367048; i=@resistor.net; bh=BLLrxHj/EUx5yEz2JYJruRmNCELN7fWXxoiepqNosIo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ABWe97CBT+OT4KPCypJlfi3ETVysWcurAwjXjbETSW3YdjHPQsXhHuUr+h9/JYpNw h2huDqXY+elm9ewmMwyTQ7dQ0TG3m+bytS61vBKiDW8MXyzO3wUhgMwGBxKTnGXYDk aE2ddrtUf7X6yhR/62Uj28bWgmkauqERj8sjwdNs= Message-Id: <6.2.5.6.2.20130208153641.0b1bb938@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 08 Feb 2013 15:43:53 -0800 To: Bjoern Hoehrmann From: SM In-Reply-To: <50tah89cmijfqd0bdd2be9grl46uveivgd@hive.bjoern.hoehrmann.d e> References: <50tah89cmijfqd0bdd2be9grl46uveivgd@hive.bjoern.hoehrmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Tony Hansen , apps-discuss@ietf.org Subject: Re: [apps-discuss] RFC 6839 (media type suffixes) formatting error? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Feb 2013 23:44:17 -0000 Hi Bjoern, At 13:59 08-02-2013, Bjoern Hoehrmann wrote: > In http://tools.ietf.org/html/rfc6839#section-3.1 there seems to be a >formatting error (also present in the ordinary plain text version): [snip] >The second paragraph apparently should be indented like the following >ones. Am I missing something? Should I file this as errata item? It's a formatting issue. The bug was introduced during RFC Editor processing. I am copying the message to the authors as they can decide what to do about this. Regards, -sm From barryleiba.mailing.lists@gmail.com Fri Feb 8 16:21:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B393B21F8C45 for ; Fri, 8 Feb 2013 16:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.939 X-Spam-Level: X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=0.038, 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 zhwG+MSD5Z1P for ; Fri, 8 Feb 2013 16:21:04 -0800 (PST) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6E221F8A77 for ; Fri, 8 Feb 2013 16:21:04 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id ox1so3847920veb.41 for ; Fri, 08 Feb 2013 16:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/rkpmUvdEiLOPfLgd2MDf+/QGBJc156DBZM2t1PavNM=; b=V7cWnG8KUOnzo2Vl7AhGQ5pwMmblam7g+I/MCwWxTWDf6HnMO1CwJeR09WW4kac/YW BSeOPM1xkyD4Ebz/w82HmfdzDX5pmcSdHYxhajkqqzbI3vBkMBscKYAmw93uKTq7qBma zjxAOVorLhA17JMVhXjZ4q7OVbvy7RLHaYfvEsAGGdonW7M5scT+fPY/PdxhW2gg8P4P sn90S5I6K3n2vFYPUf0kr5MPNJ30E4TF/8G8EgZ24mlg8yTpLyep2oHt1+k0VitbF29O Gzhygye2JMVqQfmW7Fp9YaECVdB+deNcDFKYpI+CmDrBG7WDNH/+8NuiGmdv8octbgib sRYw== MIME-Version: 1.0 X-Received: by 10.58.15.227 with SMTP id a3mr9316779ved.38.1360369263256; Fri, 08 Feb 2013 16:21:03 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Fri, 8 Feb 2013 16:21:02 -0800 (PST) In-Reply-To: <72266BF4E92D401E9F312898766D6B16@LENOVO47E041CF> References: <72266BF4E92D401E9F312898766D6B16@LENOVO47E041CF> Date: Fri, 8 Feb 2013 19:21:02 -0500 X-Google-Sender-Auth: Kd0zexEbWqulv-yKoPCFX6iExkk Message-ID: From: Barry Leiba To: Jiankang YAO Content-Type: text/plain; charset=ISO-8859-1 Cc: Yakov Shafranovich , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-shafranovich-mime-sql-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: Sat, 09 Feb 2013 00:21:04 -0000 Thanks for the review, Jiankang. > Is it good to list the persional email address ietf@shaftek.org as the permanent > contact address? It's done all the time. I always prefer to list an organization or mailing list, but for individual submissions it's often the case that the individual is really the sensible contact point. I have no issue with it for this document. > In section 3, which said "After approval, IANA is asked to register the media type application/ > sql in the Standards tree using the application provided in Section 2 > of this document." > > I suggest to improve the meaning of "after approval" or remove the "after approval". Nah, there's no issue here either. While this is technically ungrammatical, it really is perfectly fine as worded, and IANA knows what to do: they will make the registration when the IESG approves the document. The RFC Editor will change it to say, "IANA has registered [...]" when they publish the RFC. Barry From barryleiba.mailing.lists@gmail.com Fri Feb 8 16:29:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA3021F8C49 for ; Fri, 8 Feb 2013 16:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.941 X-Spam-Level: X-Spam-Status: No, score=-102.941 tagged_above=-999 required=5 tests=[AWL=0.036, 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 j03RK6q5HkYr for ; Fri, 8 Feb 2013 16:29:12 -0800 (PST) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3113921F8C3B for ; Fri, 8 Feb 2013 16:29:12 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id 14so3886046vea.29 for ; Fri, 08 Feb 2013 16:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=C8kvLaPSqnr+1dfVL8WZT3kTsUPz8sKguQQWGEJll6Y=; b=HLGLA5cYlW94NExl5/PzKuuxC36vLKfyqvJEfCA7VGPSHjWUr2AEgbUyZWnIZzY7ri HP7UuVb6ZHq4MiS9lBY+1Wf8ETTNg3BR+QMLGr82Jmlsb95dSdBEEx4oBn5C1I5egkpe nl2V6uj8sywVMQjHwWhUCdf0UzdtB65t8fJt8lrbx3SiGSTzSlLvgbhOEo51iHACyA+T BqRXttzJTkVKePW60WGf1RQ1IArM5b9KZz7ccHdbnje8MBsXF28izp9EN4o0CSL3+EA/ wM5hK38X/wLRfadqie7y5QNbnJ8zakrjajYbvZOMFMK06HrOm/2kHluBVo1DZ9oPfnx2 yUAw== MIME-Version: 1.0 X-Received: by 10.220.116.5 with SMTP id k5mr9175090vcq.55.1360369751633; Fri, 08 Feb 2013 16:29:11 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Fri, 8 Feb 2013 16:29:11 -0800 (PST) In-Reply-To: <50tah89cmijfqd0bdd2be9grl46uveivgd@hive.bjoern.hoehrmann.de> References: <50tah89cmijfqd0bdd2be9grl46uveivgd@hive.bjoern.hoehrmann.de> Date: Fri, 8 Feb 2013 19:29:11 -0500 X-Google-Sender-Auth: 2x76HFZ-aNLCuIMnHfxcXOjs5pY Message-ID: From: Barry Leiba To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 6839 (media type suffixes) formatting error? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2013 00:29:12 -0000 > The second paragraph apparently should be indented like the following > ones. Am I missing something? Should I file this as errata item? Most definitely not. This isn't something we (your ADs) would judge as an error that could cause confusion and incorrect implementations. That would mean we'd have to deal with the erratum report and mark it "held for document update". If the document is ever updated, it will certainly be fixed anyway, without the report. Might as well save us the time. Please limit errata reports to things that might actually confuse someone, and not to obvious typos or minor formatting glitches. If someone leaves out a "not", that's probably going to be a valid report that you should file. If someone spells "not" as "noy" by accident, chuckle and don't worry about it. Barry (And thanks for asking.) From derhoermi@gmx.net Fri Feb 8 17:56:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BE621F8C8C for ; Fri, 8 Feb 2013 17:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.12 X-Spam-Level: X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[AWL=-2.821, BAYES_00=-2.599, MANGLED_REGSTR=2.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 BlV5mTVQA5SK for ; Fri, 8 Feb 2013 17:56:10 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6583121F8C4B for ; Fri, 8 Feb 2013 17:56:06 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lmxbm-1UZl3B1z6y-00h7vt for ; Sat, 09 Feb 2013 02:56:05 +0100 Received: (qmail invoked by alias); 09 Feb 2013 01:56:04 -0000 Received: from pD9539135.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [217.83.145.53] by mail.gmx.net (mp010) with SMTP; 09 Feb 2013 02:56:04 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18PMhYBI3MPOsifWE0OsAHEuVMZ10HhuodbRmp8fI eXxqCg2TLYH8W5 From: Bjoern Hoehrmann To: Barry Leiba Date: Sat, 09 Feb 2013 02:56:06 +0100 Message-ID: References: <50tah89cmijfqd0bdd2be9grl46uveivgd@hive.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 6839 (media type suffixes) formatting error? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2013 01:56:11 -0000 * Barry Leiba wrote: >Most definitely not. This isn't something we (your ADs) would judge >as an error that could cause confusion and incorrect implementations. >That would mean we'd have to deal with the erratum report and mark it >"held for document update". If the document is ever updated, it will >certainly be fixed anyway, without the report. Might as well save us >the time. > >Please limit errata reports to things that might actually confuse >someone, and not to obvious typos or minor formatting glitches. If >someone leaves out a "not", that's probably going to be a valid report >that you should file. If someone spells "not" as "noy" by accident, >chuckle and don't worry about it. The "Fragment identifier considerations" are fairly indigestable and the formatting error on top of that certainly confused me enough to spend a couple of minutes to read through other parts of the document to guess what might be going on. The text for some of the other suffixes follows the same schema, so one can reasonably conclude it is a formatting error after some research, and people who do get confused by this as I have are unlikely to be helped much by an entry in the errata tracker, but as this is text people are likely to read out of context because they only want to know what to put in their registration template for +json types, I do not think your ridicule is justified. That aside, I think "errata" ought to list all known errors, and it's not clear to me that there is a net gain in omitting errors that people bother to mention for reasons other than making a point. A practical problem for me, as someone who has provided feedback on many dozens of media type proposals over the last decade, and I encountered this problem doing just that, is that I don't like pointing people try- ing to register a +json media type but getting their Fragment Identifier field wrong to the relevant section in this RFC, knowing that the error has confused me in the past, without pointing the problem out. But I also do not like telling people something is a "known error" when there is no proper documentation that this is in fact a "known" "error". A good solution here might be to make a "quick guide to media type re- gistration", perhaps on the Applications Area Working Group wiki, and pointing people to that instead of the RFCs. One reason I have not made one in the past is that reviewers are reluctant to assert "everything okay", so when registrations are too good, there would be no feedback, but people would not know why there was no feedback... -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From barryleiba@gmail.com Fri Feb 8 18:20:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB4A21F8C8C for ; Fri, 8 Feb 2013 18:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.794 X-Spam-Level: X-Spam-Status: No, score=-101.794 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_REGSTR=2.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 DBU2TL7CBN-g for ; Fri, 8 Feb 2013 18:20:27 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id D3FC621F8C7A for ; Fri, 8 Feb 2013 18:20:19 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id m4so3452021lbo.14 for ; Fri, 08 Feb 2013 18:20:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DmnlPxR3LV66r6WmNuQgYLqQZg9na7EpLe4ZytpZl+c=; b=Zu/aZrT5KIkggJFzWjvpdw5H0/kGqdKePiWdHnm15Egyj103HQvodl1ZNEPAXUnIXl M3+8w95zeovTvoH1uDGydFunDfDaSebdncVHDvcy2AFZrQ1O2vCnuyxzXYFJ9ZD/XRMj Ju7Wyh4ymB36akDIzeB9YABU6T7QCadd2yxgJeLUY/IZygvT5sb1jth1GPbVfj70nx4T 8Ttqy8u5mhMa76CO4dmedQhqwQ1ur4/Vxy4d6eDfIastuNPy+ORq5XkuVmUkp0vdUU7T PvuwVjY4r6aeEu3CSk7rMvdevtCD7Netrkr9rGTI4FZGNz9wMiuSgBMEpsWHvuMb6ssB mZtw== MIME-Version: 1.0 X-Received: by 10.152.121.212 with SMTP id lm20mr6609436lab.42.1360376418683; Fri, 08 Feb 2013 18:20:18 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.112.47.168 with HTTP; Fri, 8 Feb 2013 18:20:18 -0800 (PST) In-Reply-To: References: <50tah89cmijfqd0bdd2be9grl46uveivgd@hive.bjoern.hoehrmann.de> Date: Fri, 8 Feb 2013 21:20:18 -0500 X-Google-Sender-Auth: q_lbMnEsI4A_6xYFzXiA5P1rUC8 Message-ID: From: Barry Leiba To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 6839 (media type suffixes) formatting error? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2013 02:20:28 -0000 > but as > this is text people are likely to read out of context because they only > want to know what to put in their registration template for +json types, > I do not think your ridicule is justified. Oh, my! Please accept my fullest apology; I never meant what I said to be ridicule, and I'm truly sorry it came out that way. No, of course ridicule is not justified, nor was it intended. > That aside, I think "errata" > ought to list all known errors, and it's not clear to me that there is a > net gain in omitting errors that people bother to mention I'm of a mixed mind on this -- many errata reports really are unnecessary to record, though they were made with the best of intentions, but I understand that the dividing line is a matter of judgment. The direction I described comes from the 2008 IESG and is recorded here: http://www.ietf.org/iesg/statement/errata-processing.html If the community thinks the current IESG should revisit this, we can certainly do that; if you'd like to start a discussion of that, please do, and please take it to . We will pay attention to the conversation. > A good solution here might be to make a "quick guide to media type re- > gistration", perhaps on the Applications Area Working Group wiki, and > pointing people to that instead of the RFCs. One reason I have not made > one in the past is that reviewers are reluctant to assert "everything > okay", so when registrations are too good, there would be no feedback, > but people would not know why there was no feedback... We can certainly encourage active reviewers to make sure that at least one "looks good, and thanks for posting it for review" message is always made in those cases. But I think your idea of having a good summary of what's needed, with a pointer to the formal documentation (and a note about the formatting error) is an excellent one. I encourage you and your fellow reviewers to craft such a wiki page, please. Barry From internet-drafts@ietf.org Fri Feb 8 19:31:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6016E21F8C3E; Fri, 8 Feb 2013 19:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2P1GTp9XRHL; Fri, 8 Feb 2013 19:31:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEB221F8C83; Fri, 8 Feb 2013 19:31:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130209033118.8995.1805.idtracker@ietfa.amsl.com> Date: Fri, 08 Feb 2013 19:31:18 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-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: Sat, 09 Feb 2013 03:31:19 -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-10.txt Pages : 22 Date : 2013-02-08 Abstract: This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eburger@standardstrack.com Sat Feb 9 04:50:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7653221F8B7D for ; Sat, 9 Feb 2013 04:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_REGSTR=2.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 b24Vz16KMZTu for ; Sat, 9 Feb 2013 04:50:39 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id DA5D521F872D for ; Sat, 9 Feb 2013 04:50:38 -0800 (PST) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:53485 helo=[192.168.15.177]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U49sw-0000z6-Ro for apps-discuss@ietf.org; Sat, 09 Feb 2013 04:50:27 -0800 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_5F936319-2DE3-45A3-967D-F4320C484777"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <40AD61F6-9841-4B7E-95D6-FA3D89472BDC@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Sat, 9 Feb 2013 07:50:36 -0500 References: <50tah89cmijfqd0bdd2be9grl46uveivgd@hive.bjoern.hoehrmann.de> <7E56DE05-7FA8-4B1F-9C34-B50AF6D4DB8A@standardstrack.com> To: "apps-discuss@ietf.org" In-Reply-To: <7E56DE05-7FA8-4B1F-9C34-B50AF6D4DB8A@standardstrack.com> X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [apps-discuss] RFC 6839 (media type suffixes) formatting error? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2013 12:50:39 -0000 --Apple-Mail=_5F936319-2DE3-45A3-967D-F4320C484777 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The errata system is just fine. One can enter formatting errors as an = editorial error. Presuming the error is valid, the responsible reviewer = should mark the error as Hold for Update. I am a bit worried about this particular case. If the document, for = whatever reason, is so unclear that we are compelled to create a wiki to = document how something really works so people can build interoperable = implementations, then we have prima face evidence the RFC is not clear = enough and should be updated. What is situational is whether the update = is via an errata, refresh of the document, or perhaps an Informational = RFC. On Feb 8, 2013, at 9:20 PM, Barry Leiba wrote: >> but as >> this is text people are likely to read out of context because they = only >> want to know what to put in their registration template for +json = types, >> I do not think your ridicule is justified. >=20 > Oh, my! > Please accept my fullest apology; I never meant what I said to be > ridicule, and I'm truly sorry it came out that way. No, of course > ridicule is not justified, nor was it intended. >=20 >> That aside, I think "errata" >> ought to list all known errors, and it's not clear to me that there = is a >> net gain in omitting errors that people bother to mention >=20 > I'm of a mixed mind on this -- many errata reports really are > unnecessary to record, though they were made with the best of > intentions, but I understand that the dividing line is a matter of > judgment. The direction I described comes from the 2008 IESG and is > recorded here: = http://www.ietf.org/iesg/statement/errata-processing.html >=20 > If the community thinks the current IESG should revisit this, we can > certainly do that; if you'd like to start a discussion of that, please > do, and please take it to . We will pay attention to > the conversation. >=20 >> A good solution here might be to make a "quick guide to media type = re- >> gistration", perhaps on the Applications Area Working Group wiki, and >> pointing people to that instead of the RFCs. One reason I have not = made >> one in the past is that reviewers are reluctant to assert "everything >> okay", so when registrations are too good, there would be no = feedback, >> but people would not know why there was no feedback... >=20 > We can certainly encourage active reviewers to make sure that at least > one "looks good, and thanks for posting it for review" message is > always made in those cases. >=20 > But I think your idea of having a good summary of what's needed, with > a pointer to the formal documentation (and a note about the formatting > error) is an excellent one. I encourage you and your fellow reviewers > to craft such a wiki page, please. >=20 > Barry > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_5F936319-2DE3-45A3-967D-F4320C484777 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJRFkYdAAoJEDY/T2tCIPW3eHEP/3R8hbB45X30YFRPW1h4HzLL wUrO/Hki2X6PZ7dNCG8XDIwwuPkx53ekBMQY5AzWyHjJtmX3f/PFpeZvKm3Hklph 6OOgCfboKY9eDSIl/G9sHF+nX83aFVvhpLL602FIf/BU0Vr09haU1SGvGBOAsfIs nMJ3Ub81nR+KavEs0VuDMMNb0KR8nrGv1B1xqv/BZwOHgBqc1g/2YSk1X3cr9hrV 8v86LSsaraU5QunUpV7WOAnXzmWJnaebOjNHPP8W7Dil1Ff5prbS0fQTvuokxHFP PYbImvKsCEBmX2pmtHNwWxmo3BbPK13zEl/BKWw/sTpl55YbqSll5vI3GZiJF1Ok HXAhrYc0Q3OTvpYW5ed93UqBWx33Bcht1cTSyY1yVzwfdneY3tibTNaZroc1c8jc gj5IJmI3ciGckBfXC8sYIfZgzKp8X0KE2D6pv3TrG5XfRJGOo71mTLWOcd3FyncY Nzk8u93RRFOqWVbzqlen+hoZRioqjlR8BTg7MSmG9WgRYNMgXLh7TNG+UvG2diCZ j+7q7eue3D0N796Qzw5ihYTLuu/dsX2MF+AI0XhAY2sW6JSTehs9CZcVxH6EbEhz KcETUr3UbmcbrJmuWt/2IzdqTaE4xG7lm5p8reAySWfvuJWyfSvw9DjipjEPylc6 SD+eNYy7imSs0gPXBLwN =i3u7 -----END PGP SIGNATURE----- --Apple-Mail=_5F936319-2DE3-45A3-967D-F4320C484777-- From tony@att.com Sat Feb 9 10:42:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B0621F87BB for ; Sat, 9 Feb 2013 10:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.228 X-Spam-Level: X-Spam-Status: No, score=-107.228 tagged_above=-999 required=5 tests=[AWL=-0.629, 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 qd0whucD8Ggt for ; Sat, 9 Feb 2013 10:42:19 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4D60821F87AA for ; Sat, 9 Feb 2013 10:42:19 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id a8896115.0.1018305.00-291.2800441.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 09 Feb 2013 18:42:19 +0000 (UTC) X-MXL-Hash: 5116988b11e19e82-f828d1d01988538d6623e4c35a8086ba209d8d34 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r19IgI00032720 for ; Sat, 9 Feb 2013 10:42:18 -0800 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r19Ig9to032563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 9 Feb 2013 10:42:15 -0800 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint03.pst.cso.att.com (RSA Interceptor) for ; Sat, 9 Feb 2013 10:40:52 -0800 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id r19IeoZ7026310 for ; Sat, 9 Feb 2013 13:40:50 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id r19Ieijh026259 for ; Sat, 9 Feb 2013 13:40:45 -0500 Received: from [135.70.112.237] (vpn-135-70-112-237.vpn.swst.att.com[135.70.112.237]) by maillennium.att.com (mailgw1) with ESMTP id <20130209183943gw100632foe> (Authid: tony); Sat, 9 Feb 2013 18:39:44 +0000 X-Originating-IP: [135.70.112.237] Message-ID: <5116982A.5060605@att.com> Date: Sat, 09 Feb 2013 13:40:42 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <50tah89cmijfqd0bdd2be9grl46uveivgd@hive.bjoern.hoehrmann.de> In-Reply-To: <50tah89cmijfqd0bdd2be9grl46uveivgd@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=AttZKpBP c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=phlekcV8r4MA:10 a=qvxnG7FKX0EA:10 a=AdmyTklyCT0A:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=28ENv-4CHxgA:10 a=48vgC7mUAAAA:8 a=ft5iT9OQOi8J1] X-AnalysisOut: [4rSVmQA:9 a=wPNLvfGTeEIA:10] Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] RFC 6839 (media type suffixes) formatting error? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2013 18:42:20 -0000 A list like that could be formatted as: ___The syntax ... ___For cases ... ___For cases ... ___For cases ... or ___The syntax ... ______For cases ... ______For cases ... ______For cases ... or ___The syntax ... ___For cases ... ______For cases ... _________For cases ... or ___The syntax ... ______For cases ... _________For cases ... ____________For cases ... or, as in the RFC, ___The syntax ... ___For cases ... ______For cases ... ______For cases ... None of these change the meaning of the text For consistency with the other sections, it would have been better if they all used the same indentation. But there's no technical issue with the document. The indentation glitch happened extremely late in the editing process and was overlooked. The reason for it happening is a story itself, but it should be discussed on the RFC Editor Interest list, or the xml2rfc interest list. (In short, there's an issue with the xml2rfc nroff-writing code.) As for writing an erratum, since the registrations in this RFC are meant to be held up as examples for other people to copy in the future, I think writing a non-technical erratum is perfectly reasonable to capture the issue. But it's only because other people might copy it and for no other reason. If they copy it and keep the bad indentation, and defend themselves with pointing at RFC 6839, we can point at the erratum as a counter argument. Which is sort of a tenuous reason to do so. HOWEVER, the current review process for non-technical errata is exceedingly heavy weight. For example, it invokes AD responsibility to ensure that the non-technical erratum is reviewed. I feel that that level of AD involvement is totally inappropriate for non-technical issues, and the errata processing guidelines need to be updated. But that, again, is an argument for another list. Tony Hansen On 2/8/2013 4:59 PM, Bjoern Hoehrmann wrote: > Hi, > > In http://tools.ietf.org/html/rfc6839#section-3.1 there seems to be a > formatting error (also present in the ordinary plain text version): > > The syntax and semantics for fragment identifiers for a specific > "xxx/yyy+json" SHOULD be processed as follows: > > For cases defined in +json, where the fragment identifier resolves > per the +json rules, then process as specified in +json. > > For cases defined in +json, where the fragment identifier does > not resolve per the +json rules, then process as specified in > "xxx/yyy+json". > > For cases not defined in +json, then process as specified in > "xxx/yyy+json". > > The second paragraph apparently should be indented like the following > ones. Am I missing something? Should I file this as errata item? > > regards, From yakov@shaftek.org Sat Feb 9 20:03:34 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0333621F857C for ; Sat, 9 Feb 2013 20:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.064 X-Spam-Level: X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaSdBnCjbZFj for ; Sat, 9 Feb 2013 20:03:33 -0800 (PST) Received: from mail-ia0-x22a.google.com (ia-in-x022a.1e100.net [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8A35721F8558 for ; Sat, 9 Feb 2013 20:03:33 -0800 (PST) Received: by mail-ia0-f170.google.com with SMTP id k20so5633107iak.29 for ; Sat, 09 Feb 2013 20:03:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:x-originating-ip:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:x-gm-message-state; bh=46K/ioNkbjFdqzTsTOvwF8asTie8uD4gNI9rXy11kEo=; b=dWwxcJlBqaQbOksMW2ZS8cV5t27g+835tLVW9+tERyVOCgtSTQkR/118YTWXuWZfdq a3C0WTdCawoIfdlEvjo5WORh5T0oDsos2XX+QVdlfV8rrNmcibt9J6aO8y4QpUWTJyyD SjE8DvfWa9hQDb3IetSM7mfVsjxpMvo47UmYk6qBkJ2sfHpRrlbhoPQgqnuKWgmUupNo VnGQpoc7uu1R6av906ZWb6H619NvCwSN/qnLOPggJ1+Oz0WcAx+yuK/Ly4J3dcn0m+Xi 4sDbPX29QEofniWqSM3zQ3rvctIRLPYwbp6Z5X7tO+RIBSqBqEUJp2rk572lLHDfauzQ tGsg== X-Received: by 10.50.161.135 with SMTP id xs7mr8887458igb.3.1360469012964; Sat, 09 Feb 2013 20:03:32 -0800 (PST) MIME-Version: 1.0 Sender: yakov@shaftek.org Received: by 10.64.126.232 with HTTP; Sat, 9 Feb 2013 20:03:02 -0800 (PST) X-Originating-IP: [98.140.248.199] In-Reply-To: References: <72266BF4E92D401E9F312898766D6B16@LENOVO47E041CF> From: Yakov Shafranovich Date: Sat, 9 Feb 2013 23:03:02 -0500 X-Google-Sender-Auth: c7Tu_vQiCJDoVDSPnmDHiw0KLZY Message-ID: To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmTInzDDpByxGXY/fg2AvygGwl4p64S8oXgmzaqsGKNzKVvqoV8JZ6mVF0mFp/furU0KY2r X-Mailman-Approved-At: Mon, 11 Feb 2013 10:25:26 -0800 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-shafranovich-mime-sql-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: Sun, 10 Feb 2013 04:03:34 -0000 Thanks for the review On Fri, Feb 8, 2013 at 7:21 PM, Barry Leiba wrote: > Thanks for the review, Jiankang. > >> Is it good to list the persional email address ietf@shaftek.org as the permanent >> contact address? > > It's done all the time. I always prefer to list an organization or > mailing list, but for individual submissions it's often the case that > the individual is really the sensible contact point. I have no issue > with it for this document. > >> In section 3, which said "After approval, IANA is asked to register the media type application/ >> sql in the Standards tree using the application provided in Section 2 >> of this document." >> >> I suggest to improve the meaning of "after approval" or remove the "after approval". > > Nah, there's no issue here either. While this is technically > ungrammatical, it really is perfectly fine as worded, and IANA knows > what to do: they will make the registration when the IESG approves the > document. The RFC Editor will change it to say, "IANA has registered > [...]" when they publish the RFC. > > Barry From vkg@bell-labs.com Mon Feb 11 15:02:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8C721F8AB0; Mon, 11 Feb 2013 15:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYhjwRp8BY3G; Mon, 11 Feb 2013 15:02:12 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id BFB2721F8AAD; Mon, 11 Feb 2013 15:02:12 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r1BN28sh008740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Feb 2013 17:02:09 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r1BN28IJ005853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Feb 2013 17:02:08 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r1BN27Z9003683; Mon, 11 Feb 2013 17:02:07 -0600 (CST) Message-ID: <511978FD.2080306@bell-labs.com> Date: Mon, 11 Feb 2013 17:04:29 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: draft-ietf-mmusic-sdp-cs@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "fandreas@cisco.com" , IESG IESG , "apps-discuss@ietf.org" Subject: [apps-discuss] APPSDIR review of draft-ietf-mmusic-sdp-cs-17 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Feb 2013 23:02:13 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​ http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mmusic-sdp-cs-17 Title: Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN) Reviewer: Vijay K. Gurbani Review Date: Feb-11-2013 IETF Last Call Date: Not known IESG Telechat Date: Not known Summary: This draft is ready for publication as a Proposed Standard. A few issues that should be looked at before publication are listed below. Major Issues: 0 Minor Issues: 3 Nits: 2 Minor: ----- - S5.2.1: SDP syntax is c= . Towards the bottom of S5.2.1, it is said that "When the is PSTN ...". Should it not be "When the is PSTN ..."? - S5.2.1, towards the end it says that when the is "-", the may be "any syntactically valid value, which is to be ignored". A couple of points on this: one, I am left puzzling what is the syntactically correct value here, and secondly, if the value is to be ignored, why bother that it is syntactically correct? My advice would be to reword the bullet item as follows: any value resulting from the production rule of connection-address in RFC4566 [RFC4566], but in all cases any value encountered will be ignored. - S5.2.3.1, second paragraph: there appears to be a spurious ">" in "Section 5.7> defined the formal syntax.". Plus, you probably want to say "Section 5.7 defines the formal syntax." The last sentence of the sub-section is redundant to this one. Perhaps you can take this sentence out and let the last one remain. Nits: ----- - S6.1, Figure 3 and 4: In Figure 4, better to s/o=jdoe/o=alice/ to make the intent conform better to Figure 3. Alice is the originator of the call. Ditto for Figures 6 and 7. - S7, second paragraph: s/wellknown/well known/ Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From mikekelly321@gmail.com Mon Feb 11 23:53:31 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB5A21F8C4C for ; Mon, 11 Feb 2013 23:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7Sb5Eq-O7mB for ; Mon, 11 Feb 2013 23:53:31 -0800 (PST) Received: from mail-ea0-f177.google.com (mail-ea0-f177.google.com [209.85.215.177]) by ietfa.amsl.com (Postfix) with ESMTP id A620B21F8C4B for ; Mon, 11 Feb 2013 23:53:30 -0800 (PST) Received: by mail-ea0-f177.google.com with SMTP id n13so17833eaa.8 for ; Mon, 11 Feb 2013 23:53:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=V1TXT/lPuui246IjXVTxr1m6hPhLNbT9n7cVSqzdPYM=; b=JCAsD4PCykqKlnpZT8CdTM0BjXsxs1AdyMLKKl43clCBsmdFac2Rv/bhWw91GIOxSq 39wvrVgZzbF4wE/KKPhdaSKfEZGlKuIMNNpZ4Q+NQ5JkCdnXmtygvnFel5qRfQPenwHU XeqjLKq4yKx/KyNct2rO/WIFqWIlV9NRWSnbZRHg1tFqvkJboXJguorOHxBqtlfRKxeM 5U5y+9WlLCsy5oC6LlLgXWawpkjsOoUmjkg8tqHrPBn4tovXVh8QiNhgkhSRUcIgfvMs NGWU7IYKDWo79QzzTpGUSW5DksT9z5F5rAlMFKQmeBjhzoRs4Ug00hccnrF1C8zju+xo rvkw== MIME-Version: 1.0 X-Received: by 10.14.200.137 with SMTP id z9mr59272259een.20.1360655609810; Mon, 11 Feb 2013 23:53:29 -0800 (PST) Received: by 10.223.168.10 with HTTP; Mon, 11 Feb 2013 23:53:29 -0800 (PST) Date: Tue, 12 Feb 2013 07:53:29 +0000 Message-ID: From: Mike Kelly To: "hal-discuss@googlegroups.com" , "api-craft@googlegroups.com" , REST-Discuss Discussion Group , IETF Apps Discuss , "hypermedia@librelist.com" , "hypermedia-web@googlegroups.com" Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] New Internet-Draft: JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Feb 2013 07:53:31 -0000 Hello all, fyi, I have updated the following internet draft: http://www.ietf.org/id/draft-kelly-json-hal-04.txt All thoughts, comments, suggestions, etc welcome Cheers, Mike From salvatore.loreto@ericsson.com Tue Feb 12 08:54:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D44C21F8F96; Tue, 12 Feb 2013 08:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 937zmbT8WEfR; Tue, 12 Feb 2013 08:54:35 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6D83421F8F95; Tue, 12 Feb 2013 08:54:33 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-60-511a73b84231 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 70.E4.32353.8B37A115; Tue, 12 Feb 2013 17:54:16 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 12 Feb 2013 17:54:10 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5C65224C0; Tue, 12 Feb 2013 18:54:10 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 03283543CC; Tue, 12 Feb 2013 18:54:08 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9920754170; Tue, 12 Feb 2013 18:54:07 +0200 (EET) Message-ID: <511A73B0.7080902@ericsson.com> Date: Tue, 12 Feb 2013 18:54:08 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: draft-ietf-simple-simple@tools.ietf.org, "apps-discuss@ietf.org" , The IESG Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvje6OYqlAg0NXrS1Wv1zBZnHy0ytG ixl/JjI7MHssWfKTyePL5c9sAUxRXDYpqTmZZalF+nYJXBnzH59lLejlqjj6bhV7A+Mcji5G Tg4JAROJk+t72SFsMYkL99azdTFycQgJnGSUOP5qBSOEs4FRYt3BC1DOLkaJPw9vQJWtZZSY s28lVGYbo8TSOU/YQIbxCmhLfHpykAXEZhFQlXi+/QkjiM0mYCbx/OEWZhBbVCBZ4uOda6wQ 9YISJ2c+AasXEaiWmH7gPFhcGKh+3ecrYHFmAQuJxW8OskPY8hLNW2czQxyuJnH13CYwW0hA S6L3bCfTBEahWUjGzkLSPgtJ+wJG5lWM7LmJmTnp5eabGIHBe3DLb4MdjJvuix1ilOZgURLn DXe9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUXnbtGPcbUpsL9IiNj1wD9ns0bh4biNj Sm5t0xXVuQ8CBJneHsqXerXq4aYH369kfcjqYuU8+YLFICD0+2FTpe1X086se3n/xCx/ofu5 Bk79J+8+jvKM8Rd6dcYtpbXB/PjP8Oc8kcYbH95IfOyZcUXUY4Z8jEhxptd0Fzm2ltS+fF27 77suK7EUZyQaajEXFScCANGdk68sAgAA Subject: [apps-discuss] APPSDIR review of draft-ietf-simple-simple-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 16:54:36 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​ http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-simple-simple-08 Title: Simple made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence using the Session Initiation Protocol (SIP) Reviewer: Salvatore Loreto Review Date: Feb-12-2013 IETF Last Call Date: Not known IESG Telechat Date: Feb-21-2013 Summary: This draft is ready for publication as Informational. Two editorial updates that should be looked at before publication are listed below. Major Issues: 0 Minor Issues: 2 Nits: 0 Minor: ----- Section 2.1 Core Protocol Machinery - RFC 3265 has been updated by RFC 6665, why the document still mention 3265? Section 2.6 Optimization - RFC 6446 "Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control" should be also listed in this section. best regards -- Salvatore Loreto, PhD www.sloreto.com From mikekelly321@gmail.com Tue Feb 12 13:52:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C59E21F8B97 for ; Tue, 12 Feb 2013 13:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZXLS38SPjYJ for ; Tue, 12 Feb 2013 13:52:08 -0800 (PST) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9062A21F8B73 for ; Tue, 12 Feb 2013 13:52:04 -0800 (PST) Received: by mail-ee0-f52.google.com with SMTP id b15so274255eek.25 for ; Tue, 12 Feb 2013 13:52:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=nEOYiIcVG9crJOrXT9+Vr2yvjk3Sqjjwpgcyj6Ec8t4=; b=h5EJAwvsx2bYksEYTK3EPHgtrx6nXcnAsF7EOpoh3cUlCf/DcRgZqPsexWDeTzY1JT 4XVZDqA2TijXudH7bzXkWQZ8PyxhBXohRlB9o4rmvz78sSTCCdBULfx6AtxBUxnzVzSp pVLW7DDuK2pfcB3ar/zbxwH9jF4I+WoE/XVZovFujs8/bhcgSp0tquI2i9CGBqoeDYNu vQZ3wMTSuCd07snn08CmR6nbQ2McZ6ry4ZKP/1pvkRA1doLogpv/oYN8nFaYkjpWZGC1 WFsK3brMzIotURYip0fM8fILSvuqZLzdYvzkxDbuPrDSKBKOQs92XDj6zbSZR88exZI4 Mezw== MIME-Version: 1.0 X-Received: by 10.14.0.135 with SMTP id 7mr43517327eeb.5.1360705924132; Tue, 12 Feb 2013 13:52:04 -0800 (PST) Received: by 10.223.168.10 with HTTP; Tue, 12 Feb 2013 13:52:03 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Feb 2013 21:52:03 +0000 Message-ID: From: Mike Kelly To: "hal-discuss@googlegroups.com" , "api-craft@googlegroups.com" , REST-Discuss Discussion Group , IETF Apps Discuss , "hypermedia@librelist.com" , "hypermedia-web@googlegroups.com" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [apps-discuss] New Internet-Draft: JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Feb 2013 21:52:09 -0000 Here's a slightly more useful link than the previous one! http://tools.ietf.org/html/draft-kelly-json-hal-05 On Tue, Feb 12, 2013 at 7:53 AM, Mike Kelly wrote: > Hello all, > > fyi, I have updated the following internet draft: > > http://www.ietf.org/id/draft-kelly-json-hal-04.txt > > All thoughts, comments, suggestions, etc welcome > > Cheers, > Mike -- Mike http://twitter.com/mikekelly85 http://github.com/mikekelly http://linkedin.com/in/mikekelly123 From cyrus@daboo.name Tue Feb 12 14:11:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E54021F8AB7; Tue, 12 Feb 2013 14:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx5Qzqu9Qbq4; Tue, 12 Feb 2013 14:11:23 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 64B3D21F8AA6; Tue, 12 Feb 2013 14:11:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 04F433D44279; Tue, 12 Feb 2013 17:11:20 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzfr350__rQ6; Tue, 12 Feb 2013 17:11:19 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 47E5E3D4426A; Tue, 12 Feb 2013 17:11:18 -0500 (EST) Date: Tue, 12 Feb 2013 17:11:15 -0500 From: Cyrus Daboo To: IETF Apps Discuss Message-ID: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1133 Cc: calsify@ietf.org, vcarddav@ietf.org Subject: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Feb 2013 22:11:24 -0000 Hi folks, At the prompting of the Weirds WG there is a need to move more quickly on developing specifications for JSON-based data formats for iCalendar and vCard data, without necessarily waiting on other (proposed) JSON working group work to proceed. A proposed charter for a "fast-track" Working Group is posted at for feedback. The charter defines aggressive milestones and attempts to limit the objectives such that those are achievable. Please review and post comments back to the apps-discuss list. Whilst initial focus will be on the draft charter, some drafts have already been published describing possible (different) approaches. One for iCalendar: , and one for vCard: . We also hope to have an alternative jCard draft published in the next day or two that uses the same approach as draft-kewisch-et-al-icalendar-in-json. These should provide a good basis for initial input into the working group. -- Cyrus Daboo From barryleiba.mailing.lists@gmail.com Tue Feb 12 16:02:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB0521F88FD; Tue, 12 Feb 2013 16:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.918 X-Spam-Level: X-Spam-Status: No, score=-102.918 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNJ8IlDaErKM; Tue, 12 Feb 2013 16:02:54 -0800 (PST) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6AD21F88CF; Tue, 12 Feb 2013 16:02:53 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id b10so628104vea.2 for ; Tue, 12 Feb 2013 16:02:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OJXwuYH7Bgl9b6520+uUo2NyWrF3PkPNMtscJjM+mLA=; b=g9GDDzBEZizcYMpshVjoOZROSk22HRSEh70Qd+g2Lt8dy6+rm6TMBESLSaGI2vGqla NKaih1rBFAyvicQKh0fapq2snQBOh9AaAL9hjT9gtak1rT/2/52219FhvgSRfbDrsJED 2X4589ZX5Ofrd6/kVNkFlCyrdoYAgLQaCUU3qAzRKRtwACP1Vtt9of+W3Z8mjhoQ9WO3 6vOcNc29PZTDqQ7vl09Mus6wNlmrws0KK0IVNaf2/4kRW/3HbuzBdZJrjL5gfjqQONtL +Z/9a6Pf4wHsTXYGAta8bid7pn7tykDgKGnqaobQv00CegtKi1sLDtYykwc/dSBprkzH 3MqA== MIME-Version: 1.0 X-Received: by 10.58.188.48 with SMTP id fx16mr26497199vec.22.1360713772535; Tue, 12 Feb 2013 16:02:52 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Tue, 12 Feb 2013 16:02:52 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Feb 2013 19:02:52 -0500 X-Google-Sender-Auth: Y7CviMKJb1SV_A7uA7pbszEu6TU Message-ID: From: Barry Leiba To: Cyrus Daboo Content-Type: text/plain; charset=ISO-8859-1 Cc: CardDAV , calsify@ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 00:02:55 -0000 This is going to be Pete's working group, but let me add one thing to what Cyrus said about the aggressive schedule and the "fast track": A while ago, we chartered the imapmove working group on a very fast chartering schedule, and we're looking to do even more here. The idea that "it takes too long to create a working group" is something we need to dispel. In this case, we have an opportunity, with two back-to-back IESG telechats a week apart, so we are looking for *this Friday* (15 Feb) to put this on the telechat agenda for next week (21 Feb), and to have it get final approval on the 28th. That's three weeks from charter proposal to approval. That means that we need to hear any *major* objections to this now -- please have a look at this quickly and call out anything we've really goofed on before Friday. We then have until next Thursday (21st) to get the details of the charter in shape for broad review. Barry, Applications AD On Tue, Feb 12, 2013 at 5:11 PM, Cyrus Daboo wrote: > Hi folks, > At the prompting of the Weirds WG there is a need to move more quickly on > developing specifications for JSON-based data formats for iCalendar and > vCard data, without necessarily waiting on other (proposed) JSON working > group work to proceed. > > A proposed charter for a "fast-track" Working Group is posted at > for feedback. The > charter defines aggressive milestones and attempts to limit the objectives > such that those are achievable. Please review and post comments back to the > apps-discuss list. > > Whilst initial focus will be on the draft charter, some drafts have already > been published describing possible (different) approaches. One for > iCalendar: > , > and one for vCard: > . We also hope to > have an alternative jCard draft published in the next day or two that uses > the same approach as draft-kewisch-et-al-icalendar-in-json. These should > provide a good basis for initial input into the working group. > > -- > Cyrus Daboo From markus.lanthaler@gmx.net Wed Feb 13 02:06:33 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9907A21F8828 for ; Wed, 13 Feb 2013 02:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcvXsAi61AjZ for ; Wed, 13 Feb 2013 02:06:31 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 60B6521F8581 for ; Wed, 13 Feb 2013 02:06:31 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.16]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lmxbm-1UZQLK2VPY-00h4tH for ; Wed, 13 Feb 2013 11:06:30 +0100 Received: (qmail invoked by alias); 13 Feb 2013 10:06:30 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp016) with SMTP; 13 Feb 2013 11:06:30 +0100 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX18WKHlgPe4WwI+teu8z8/FomojHfDb5QKoX5RnDOm rAH2FqY6++txdr From: "Markus Lanthaler" To: "'Barry Leiba'" , "'Cyrus Daboo'" References: In-Reply-To: Date: Wed, 13 Feb 2013 11:06:23 +0100 Message-ID: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: de Thread-Index: Ac4JfX4C/ziK9i0dRgmHvgerKuLVAAAUI6Lw X-Y-GMX-Trusted: 0 Cc: 'IETF Apps Discuss' , calsify@ietf.org, 'CardDAV' Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 10:06:33 -0000 Even though I don't have any *major* objections I still wanted to raise some concerns about the consequences of such highly specialized formats, all similar but nevertheless not truly interoperable/compatible. As a developer you basically have to write specific code for each of those formats. I was wondering if it was ever considered to use, e.g., something like JSON-LD [1] as the base for formats like these and limit the standardization to a shared vocabulary (i.e., URLs for the required properties) and a set of constraints and conventions captured in a profile (see [2] for details). The advantage would be that much more code could be reused and data-integration would become much simpler. It might look complicated at first sight, but in reality most of what's needed is already there. For example, the work to define URLs for the various properties for both iCalendar [3] and vCard [4] has already been done at W3C (not as a REC though). So, a simple vCard represented in JSON-LD would look as follows: { "@context": { "@vocab": "http://www.w3.org/2001/vcard-rdf/3.0#" }, "FN": "John Doe", "ROLE": "Mr. Anonymous" } You would have to define a number of constraints in the form of a profile if you also want clients that process this as JSON instead of JSON-LD to be able to interpret the data. The reason is that in JSON-LD you can serialize the exactly the same data in a number of different ways (e.g., you could use different field names that still expand to the same URLs; the context defines those mappings). JSON-only clients are less flexible and thus need to know the exact structure and field names. The question I thus would like to ask is: Is there a compelling reason why this can't be based on a format as JSON-LD? Taking out the potential complexity by requiring a profile defining a number of constraints on how the data is serialized, I only see advantages of doing so. Cheers, Markus Disclaimer: I'm one of the authors of JSON-LD. [1] http://json-ld.org/spec/latest/json-ld-syntax/ (JSON-LD will become a W3C REC soon; it will enter last call by the end of the month) [2] http://tools.ietf.org/html/draft-wilde-profile-link [3] http://www.w3.org/TR/rdfcal/ [4] http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ -- Markus Lanthaler @markuslanthaler > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Barry Leiba > Sent: Wednesday, February 13, 2013 1:03 AM > To: Cyrus Daboo > Cc: CardDAV; calsify@ietf.org; IETF Apps Discuss > Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft > charter > > This is going to be Pete's working group, but let me add one thing to > what Cyrus said about the aggressive schedule and the "fast track": > > A while ago, we chartered the imapmove working group on a very fast > chartering schedule, and we're looking to do even more here. The idea > that "it takes too long to create a working group" is something we > need to dispel. In this case, we have an opportunity, with two > back-to-back IESG telechats a week apart, so we are looking for *this > Friday* (15 Feb) to put this on the telechat agenda for next week (21 > Feb), and to have it get final approval on the 28th. That's three > weeks from charter proposal to approval. > > That means that we need to hear any *major* objections to this now -- > please have a look at this quickly and call out anything we've really > goofed on before Friday. We then have until next Thursday (21st) to > get the details of the charter in shape for broad review. > > Barry, Applications AD > > On Tue, Feb 12, 2013 at 5:11 PM, Cyrus Daboo wrote: > > Hi folks, > > At the prompting of the Weirds WG there is a need to move more > quickly on > > developing specifications for JSON-based data formats for iCalendar > and > > vCard data, without necessarily waiting on other (proposed) JSON > working > > group work to proceed. > > > > A proposed charter for a "fast-track" Working Group is posted at > > for > feedback. The > > charter defines aggressive milestones and attempts to limit the > objectives > > such that those are achievable. Please review and post comments back > to the > > apps-discuss list. > > > > Whilst initial focus will be on the draft charter, some drafts have > already > > been published describing possible (different) approaches. One for > > iCalendar: > > json/>, > > and one for vCard: > > . We also > hope to > > have an alternative jCard draft published in the next day or two that > uses > > the same approach as draft-kewisch-et-al-icalendar-in-json. These > should > > provide a good basis for initial input into the working group. > > > > -- > > Cyrus Daboo > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From simon.perreault@viagenie.ca Wed Feb 13 02:15:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9B421F8848 for ; Wed, 13 Feb 2013 02:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP4gOJpD9M2V for ; Wed, 13 Feb 2013 02:15:38 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 091C721F8838 for ; Wed, 13 Feb 2013 02:15:37 -0800 (PST) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:94ca:6350:6b64:b858]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 43DEF4043F for ; Wed, 13 Feb 2013 05:15:37 -0500 (EST) Message-ID: <511B67FB.8010500@viagenie.ca> Date: Wed, 13 Feb 2013 11:16:27 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> In-Reply-To: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 10:15:38 -0000 Le 2013-02-13 11:06, Markus Lanthaler a écrit : > I was wondering if it was ever considered to use, e.g., something like > JSON-LD Good input for an eventual WG IMHO. Although I would expect the answer to be something along the lines of: "Where's the draft?" ;) > The advantage would be that much more code could be reused and > data-integration would become much simpler. It might look complicated at > first sight, but in reality most of what's needed is already there. For > example, the work to define URLs for the various properties for both > iCalendar [3] and vCard [4] has already been done at W3C (not as a REC > though). IIRC, vCard RDF does not support vCard 4.0. This is a must IMHO. Simon From simon.perreault@viagenie.ca Wed Feb 13 02:19:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAA421F8865 for ; Wed, 13 Feb 2013 02:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bd2oFnX62Piv for ; Wed, 13 Feb 2013 02:19:50 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0261921F885B for ; Wed, 13 Feb 2013 02:19:50 -0800 (PST) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:94ca:6350:6b64:b858]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3AB414043F for ; Wed, 13 Feb 2013 05:19:19 -0500 (EST) Message-ID: <511B68DA.9050002@viagenie.ca> Date: Wed, 13 Feb 2013 11:20:10 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> <511B67FB.8010500@viagenie.ca> In-Reply-To: <511B67FB.8010500@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 10:19:53 -0000 Le 2013-02-13 11:16, Simon Perreault a écrit : > IIRC, vCard RDF does not support vCard 4.0. This is a must IMHO. ...which makes me think: should we say it explicitly in the charter? For example: The jCard and jCal formats to be developed by the working group MUST support the latest versions of vCard (4.0) and iCalendar (2.0). Full or limited support for previous versions is OPTIONAL. Simon From julian.reschke@gmx.de Wed Feb 13 02:23:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB43921F886D for ; Wed, 13 Feb 2013 02:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.946 X-Spam-Level: X-Spam-Status: No, score=-104.946 tagged_above=-999 required=5 tests=[AWL=-2.347, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdrAMnPAzCW8 for ; Wed, 13 Feb 2013 02:23:37 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id CA80321F886E for ; Wed, 13 Feb 2013 02:23:36 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.33]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M0vpJ-1UuVaq3esp-00vBVc for ; Wed, 13 Feb 2013 11:23:35 +0100 Received: (qmail invoked by alias); 13 Feb 2013 10:23:35 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.102]) [217.91.35.233] by mail.gmx.net (mp033) with SMTP; 13 Feb 2013 11:23:35 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+HW30Q8n6HN0esbdcGihx3K5DTD6aN5opMpMepQ9 BhH0dUo9RpXLet Message-ID: <511B69A6.9050509@gmx.de> Date: Wed, 13 Feb 2013 11:23:34 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Simon Perreault References: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> <511B67FB.8010500@viagenie.ca> In-Reply-To: <511B67FB.8010500@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 10:23:38 -0000 On 2013-02-13 11:16, Simon Perreault wrote: > Le 2013-02-13 11:06, Markus Lanthaler a écrit : >> I was wondering if it was ever considered to use, e.g., something like >> JSON-LD > > Good input for an eventual WG IMHO. Although I would expect the answer > to be something along the lines of: "Where's the draft?" ;) > >> The advantage would be that much more code could be reused and >> data-integration would become much simpler. It might look complicated at >> first sight, but in reality most of what's needed is already there. For >> example, the work to define URLs for the various properties for both >> iCalendar [3] and vCard [4] has already been done at W3C (not as a REC >> though). > > IIRC, vCard RDF does not support vCard 4.0. This is a must IMHO. > ... But it could easily be updated to support it, no? Best regards, Julian From simon.perreault@viagenie.ca Wed Feb 13 02:28:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611A721F8842 for ; Wed, 13 Feb 2013 02:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWwTGUrc0w0m for ; Wed, 13 Feb 2013 02:28:37 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0A63E21F882C for ; Wed, 13 Feb 2013 02:28:31 -0800 (PST) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:94ca:6350:6b64:b858]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 489924043F; Wed, 13 Feb 2013 05:28:30 -0500 (EST) Message-ID: <511B6B01.5020504@viagenie.ca> Date: Wed, 13 Feb 2013 11:29:21 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Julian Reschke References: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> <511B67FB.8010500@viagenie.ca> <511B69A6.9050509@gmx.de> In-Reply-To: <511B69A6.9050509@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 10:28:37 -0000 Le 2013-02-13 11:23, Julian Reschke a écrit : >> IIRC, vCard RDF does not support vCard 4.0. This is a must IMHO. >> ... > > But it could easily be updated to support it, no? Sure, but until it is actually updated I expect it would be hard to write a draft using RDF and claiming support for vCard 4. Which would make it hard for the eventual WG to adopt that draft, given the tight deadlines. Simon From julian.reschke@gmx.de Wed Feb 13 02:36:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFFC21F87E4 for ; Wed, 13 Feb 2013 02:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.868 X-Spam-Level: X-Spam-Status: No, score=-104.868 tagged_above=-999 required=5 tests=[AWL=-2.269, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CU6C1JXx+8hs for ; Wed, 13 Feb 2013 02:36:47 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id D8A6821F87A4 for ; Wed, 13 Feb 2013 02:36:33 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MW5VH-1UP0O12wm1-00XLiF for ; Wed, 13 Feb 2013 11:36:32 +0100 Received: (qmail invoked by alias); 13 Feb 2013 10:36:32 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.102]) [217.91.35.233] by mail.gmx.net (mp002) with SMTP; 13 Feb 2013 11:36:32 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18pdbs+T0ApNVDC9LnaeuYpSwKc9imE+LjPWpHcjx rrvGjYHnKShqa3 Message-ID: <511B6CB0.9010606@gmx.de> Date: Wed, 13 Feb 2013 11:36:32 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Simon Perreault References: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> <511B67FB.8010500@viagenie.ca> <511B69A6.9050509@gmx.de> <511B6B01.5020504@viagenie.ca> In-Reply-To: <511B6B01.5020504@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 10:36:47 -0000 On 2013-02-13 11:29, Simon Perreault wrote: > Le 2013-02-13 11:23, Julian Reschke a écrit : >>> IIRC, vCard RDF does not support vCard 4.0. This is a must IMHO. >>> ... >> >> But it could easily be updated to support it, no? > > Sure, but until it is actually updated I expect it would be hard to > write a draft using RDF and claiming support for vCard 4. Which would > make it hard for the eventual WG to adopt that draft, given the tight > deadlines. > > Simon :-) I just wanted to point out that *if* the problem was that vCard-RDF does not support vCard 4, then the obvious fix for that is to update *that* spec, not invent something new. Best regards, Julian From simon.perreault@viagenie.ca Wed Feb 13 02:40:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19C721F888E for ; Wed, 13 Feb 2013 02:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kj7OlsIv-Os6 for ; Wed, 13 Feb 2013 02:40:58 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4C01521F888B for ; Wed, 13 Feb 2013 02:40:58 -0800 (PST) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:94ca:6350:6b64:b858]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 893A54043F; Wed, 13 Feb 2013 05:40:57 -0500 (EST) Message-ID: <511B6DEC.7070500@viagenie.ca> Date: Wed, 13 Feb 2013 11:41:48 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Julian Reschke References: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> <511B67FB.8010500@viagenie.ca> <511B69A6.9050509@gmx.de> <511B6B01.5020504@viagenie.ca> <511B6CB0.9010606@gmx.de> In-Reply-To: <511B6CB0.9010606@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 10:40:58 -0000 Le 2013-02-13 11:36, Julian Reschke a écrit : > I just wanted to point out that *if* the problem was that vCard-RDF does > not support vCard 4, then the obvious fix for that is to update *that* > spec, not invent something new. It may be *a* problem, but I don't think it is *the* problem. :) Simon From markus.lanthaler@gmx.net Wed Feb 13 03:08:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C792121F8923 for ; Wed, 13 Feb 2013 03:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.064 X-Spam-Level: X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kXvL+6BoR+v for ; Wed, 13 Feb 2013 03:08:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id B0AED21F88BC for ; Wed, 13 Feb 2013 03:08:50 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Mfl5W-1UJn8v1ttk-00NDLr for ; Wed, 13 Feb 2013 12:08:49 +0100 Received: (qmail invoked by alias); 13 Feb 2013 11:08:49 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp034) with SMTP; 13 Feb 2013 12:08:49 +0100 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1+KvCwW1BWKbChDhM+bSc2Qm35IN0BwYOGvCNUxNX 9IYRiukLq2GNQA From: "Markus Lanthaler" To: "'Simon Perreault'" , "'Julian Reschke'" References: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> <511B67FB.8010500@viagenie.ca> <511B69A6.9050509@gmx.de> <511B6B01.5020504@viagenie.ca> <511B6CB0.9010606@gmx.de> <511B6DEC.7070500@viagenie.ca> In-Reply-To: <511B6DEC.7070500@viagenie.ca> Date: Wed, 13 Feb 2013 12:08:47 +0100 Message-ID: <00bc01ce09da$7fa6c740$7ef455c0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-Language: de Thread-Index: Ac4J1p4SFzpdWMs4RAudHXgLC/evRgAAjcKQ X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 11:08:51 -0000 On Wednesday, February 13, 2013 11:42 AM, Simon Perreault wrote: > > Le 2013-02-13 11:06, Markus Lanthaler a =E9crit : > > I was wondering if it was ever considered to use, e.g., something = like > > JSON-LD >=20 > Good input for an eventual WG IMHO. Although I would expect the answer = > to be something along the lines of: "Where's the draft?" ;) Which draft? I included links to all the drafts: [1] http://json-ld.org/spec/latest/json-ld-syntax/ (JSON-LD will become = a W3C REC soon; it will enter last call by the end of the month) [2] http://tools.ietf.org/html/draft-wilde-profile-link [3] http://www.w3.org/TR/rdfcal/ [4] http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Or are you talking about the draft describing how to put those pieces together? Consider my previous mail as a draft :-P The (eventual) WG will have to decide how to serialize the data anyway = (how to name fields, how to structure the data, etc.). could be used more or = less directly with JSON-LD. draft-kewisch-et-al-icalendar-in-json would = require more changes - but, honestly, I expect (hope) that format to change = quite a bit since it really doesn't look at all how JSON is typically used. Just look at the example on page 7: ["vevent", [ ["summary", {}, "text", "Meeting with Fred"], ["categories", {}, "text", "Meetings", "Work"] ... ], [ /* sub-components */ ] ] > Le 2013-02-13 11:36, Julian Reschke a =E9crit : > > I just wanted to point out that *if* the problem was that vCard-RDF > does > > not support vCard 4, then the obvious fix for that is to update > *that* > > spec, not invent something new. >=20 > It may be *a* problem, but I don't think it is *the* problem. :) So, what's *the* problem? :-) -- Markus Lanthaler @markuslanthaler From laurentwalter.goix@telecomitalia.it Wed Feb 13 03:17:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0573A21F87EA for ; Wed, 13 Feb 2013 03:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2r+KgesX0Mf for ; Wed, 13 Feb 2013 03:17:07 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0FF21F87D2 for ; Wed, 13 Feb 2013 03:17:05 -0800 (PST) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 13 Feb 2013 12:17:04 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Wed, 13 Feb 2013 12:17:03 +0100 From: Goix Laurent Walter To: Markus Lanthaler , 'Simon Perreault' , 'Julian Reschke' Date: Wed, 13 Feb 2013 12:17:02 +0100 Thread-Topic: [apps-discuss] iCalendar and vCard in JSON: WG draft charter Thread-Index: Ac4J1p4SFzpdWMs4RAudHXgLC/evRgAAjcKQAACIaaA= Message-ID: References: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> <511B67FB.8010500@viagenie.ca> <511B69A6.9050509@gmx.de> <511B6B01.5020504@viagenie.ca> <511B6CB0.9010606@gmx.de> <511B6DEC.7070500@viagenie.ca> <00bc01ce09da$7fa6c740$7ef455c0$@lanthaler@gmx.net> In-Reply-To: <00bc01ce09da$7fa6c740$7ef455c0$@lanthaler@gmx.net> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] R: iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 11:17:08 -0000 The portable contacts initiative somehow addressed vcard in json format a w= hile go [1] and could be also considered if not yet as it is widely used in= social networks specifications already (ostatus, opensocial). walter [1] http://portablecontacts.net/draft-spec.html#schema > -----Messaggio originale----- > Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = Per > conto di Markus Lanthaler > Inviato: mercoled=EC 13 febbraio 2013 12.09 > A: 'Simon Perreault'; 'Julian Reschke' > Cc: apps-discuss@ietf.org > Oggetto: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter > > On Wednesday, February 13, 2013 11:42 AM, Simon Perreault wrote: > > > Le 2013-02-13 11:06, Markus Lanthaler a =E9crit : > > > I was wondering if it was ever considered to use, e.g., something lik= e > > > JSON-LD > > > > Good input for an eventual WG IMHO. Although I would expect the answer > > to be something along the lines of: "Where's the draft?" ;) > > Which draft? I included links to all the drafts: > > [1] http://json-ld.org/spec/latest/json-ld-syntax/ (JSON-LD will become a > W3C REC soon; it will enter last call by the end of the month) > [2] http://tools.ietf.org/html/draft-wilde-profile-link > [3] http://www.w3.org/TR/rdfcal/ > [4] http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ > > Or are you talking about the draft describing how to put those pieces > together? Consider my previous mail as a draft :-P > > The (eventual) WG will have to decide how to serialize the data anyway (h= ow > to name fields, how to structure the data, etc.). could be used more or l= ess > directly with JSON-LD. draft-kewisch-et-al-icalendar-in-json would requir= e > more changes - but, honestly, I expect (hope) that format to change quite= a > bit since it really doesn't look at all how JSON is typically used. Just > look at the example on page 7: > > ["vevent", > [ > ["summary", {}, "text", "Meeting with Fred"], > ["categories", {}, "text", "Meetings", "Work"] > ... > ], > [ /* sub-components */ ] > ] > > > > Le 2013-02-13 11:36, Julian Reschke a =E9crit : > > > I just wanted to point out that *if* the problem was that vCard-RDF > > does > > > not support vCard 4, then the obvious fix for that is to update > > *that* > > > spec, not invent something new. > > > > It may be *a* problem, but I don't think it is *the* problem. :) > > So, what's *the* problem? :-) > > > -- > Markus Lanthaler > @markuslanthaler > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From cyrus@daboo.name Wed Feb 13 07:09:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC2321F87F6 for ; Wed, 13 Feb 2013 07:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Oakvp4t2v1x for ; Wed, 13 Feb 2013 07:09:37 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 962CC21F87CE for ; Wed, 13 Feb 2013 07:09:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 577A83D4ED3B; Wed, 13 Feb 2013 10:09:34 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOItnoIyZncA; Wed, 13 Feb 2013 10:09:33 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 18EF13D4ED31; Wed, 13 Feb 2013 10:09:32 -0500 (EST) Date: Wed, 13 Feb 2013 10:09:29 -0500 From: Cyrus Daboo To: Simon Perreault , apps-discuss@ietf.org Message-ID: In-Reply-To: <511B68DA.9050002@viagenie.ca> References: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> <511B67FB.8010500@viagenie.ca> <511B68DA.9050002@viagenie.ca> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=829 Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 15:09:38 -0000 Hi Simon, --On February 13, 2013 at 11:20:10 AM +0100 Simon Perreault=20 wrote: > Le 2013-02-13 11:16, Simon Perreault a =C3=A9crit : >> IIRC, vCard RDF does not support vCard 4.0. This is a must IMHO. > > ...which makes me think: should we say it explicitly in the charter? > > For example: > > The jCard and jCal formats to be developed by the working group MUST > support the latest versions of vCard (4.0) and iCalendar (2.0). Full or > limited support for previous versions is OPTIONAL. The current charter does reference the latest versions of each data type.=20 At this point I would rather not add anything about support for older=20 versions - even if optional - there really isn't a viable older version of=20 iCalendar, and we really need to encourage adoption of vCard v4 vs v3. --=20 Cyrus Daboo From cyrus@daboo.name Wed Feb 13 07:24:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE70521F8871 for ; Wed, 13 Feb 2013 07:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99eoclDNwI0L for ; Wed, 13 Feb 2013 07:23:58 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id AA20521F8842 for ; Wed, 13 Feb 2013 07:23:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 433F83D4F001; Wed, 13 Feb 2013 10:23:55 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYrxawA_7WBq; Wed, 13 Feb 2013 10:23:53 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 461593D4EFF5; Wed, 13 Feb 2013 10:23:51 -0500 (EST) Date: Wed, 13 Feb 2013 10:23:49 -0500 From: Cyrus Daboo To: Markus Lanthaler , 'Simon Perreault' , 'Julian Reschke' Message-ID: <478D1C5E9971B36097325279@caldav.corp.apple.com> In-Reply-To: <00bc01ce09da$7fa6c740$7ef455c0$@lanthaler@gmx.net> References: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> <511B67FB.8010500@viagenie.ca> <511B69A6.9050509@gmx.de> <511B6B01.5020504@viagenie.ca> <511B6CB0.9010606@gmx.de> <511B6DEC.7070500@viagenie.ca> <00bc01ce09da$7fa6c740$7ef455c0$@lanthaler@gmx.net> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1321 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 15:24:03 -0000 Hi Markus, --On February 13, 2013 at 12:08:47 PM +0100 Markus Lanthaler wrote: >> Good input for an eventual WG IMHO. Although I would expect the answer >> to be something along the lines of: "Where's the draft?" ;) > > Which draft? I included links to all the drafts: > > [1] http://json-ld.org/spec/latest/json-ld-syntax/ (JSON-LD will become a > W3C REC soon; it will enter last call by the end of the month) > [2] http://tools.ietf.org/html/draft-wilde-profile-link > [3] http://www.w3.org/TR/rdfcal/ > [4] http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ > > Or are you talking about the draft describing how to put those pieces > together? Consider my previous mail as a draft :-P There are already several working groups developing JSON-based data formats (jose, scim, weirds, apps-discuss (webfinger), etc). Since jCard is expected to be used by at least some of those (with weirds being the immediate driving force) one would expect your request to use JSON-LD should extend to those as well. That is perhaps a more general discussion that should take place under the auspices of the proposed JSON working group (BoF to be held at the IETF meeting in March: ) rather than being specific to jcardcal. -- Cyrus Daboo From markus.lanthaler@gmx.net Wed Feb 13 07:55:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDBD21F8788 for ; Wed, 13 Feb 2013 07:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.075 X-Spam-Level: X-Spam-Status: No, score=-1.075 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xz7Ro92eBda6 for ; Wed, 13 Feb 2013 07:55:08 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 05C8421F8783 for ; Wed, 13 Feb 2013 07:55:04 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LmxXe-1UZCf53nf2-00h6uk for ; Wed, 13 Feb 2013 16:55:03 +0100 Received: (qmail invoked by alias); 13 Feb 2013 15:55:03 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp004) with SMTP; 13 Feb 2013 16:55:03 +0100 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1+7Sz5vYqy7X+iYegRDjCgnru4VANtqXD60ZCUWIz xIOh8gp3nzNY8u From: "Markus Lanthaler" To: "'Cyrus Daboo'" , "'Simon Perreault'" , "'Julian Reschke'" References: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> <511B67FB.8010500@viagenie.ca> <511B69A6.9050509@gmx.de> <511B6B01.5020504@viagenie.ca> <511B6CB0.9010606@gmx.de> <511B6DEC.7070500@viagenie.ca> <00bc01ce09da$7fa6c740$7ef455c0$@lanthaler@gmx.net> <478D1C5E9971B36097325279@caldav.corp.apple.com> In-Reply-To: <478D1C5E9971B36097325279@caldav.corp.apple.com> Date: Wed, 13 Feb 2013 16:54:58 +0100 Message-ID: <018c01ce0a02$7c571fe0$75055fa0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: de Thread-Index: Ac4J/iUn0Mc3tTPlTLGCDawDfdEnHgAAN8KA X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 15:55:08 -0000 On Wednesday, February 13, 2013 4:24 PM, Cyrus Daboo wrote: > There are already several working groups developing JSON-based data > formats > (jose, scim, weirds, apps-discuss (webfinger), etc). Since jCard is > expected to be used by at least some of those (with weirds being the > immediate driving force) one would expect your request to use JSON-LD > should extend to those as well. That is perhaps a more general > discussion > that should take place under the auspices of the proposed JSON working > group (BoF to be held at the IETF meeting in March: > ) rather than > being specific to jcardcal. Maybe. The difference between jcardcal and the other formats you list above is that most of them go well beyond just defining some serialization conventions (in the lack of a better term). JOSE, e.g., defines how crypto operations and how their result can be serialized (sure, the serialization could also be based on JSON-LD). Furthermore those efforts have been started quite some time ago. In most cases I think it wouldn't be fair to request such a change at this point. jcardcal is quite different in that regard. AFAICT the work on it is just about to start and, as I see it, it does nothing else than standardizing some conventions to serialize vCard/iCalendar in JSON. In fact it actually re-invents a lot of things that would come for free by basing the work on JSON-LD (for example the whole data typing section in draft-kewisch-et-al-icalendar-in-json). As already said in my initial e-mail, this is not a *major* concern at the moment and should perhaps be discussed at a later point in time. I just wanted to raise my concerns early enough. I also wanted to hear some objective and compelling reasons against basing the work on JSON-LD and other existing work. Given the strict timeline, I'm afraid that all future discussions will be shut down purely due to the limited time available. Thanks, Markus -- Markus Lanthaler @markuslanthaler From hallam@gmail.com Wed Feb 13 08:28:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7087821F891C for ; Wed, 13 Feb 2013 08:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.746 X-Spam-Level: X-Spam-Status: No, score=-5.746 tagged_above=-999 required=5 tests=[AWL=-2.748, BAYES_00=-2.599, 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 iNzfcXBPjWu2 for ; Wed, 13 Feb 2013 08:28:35 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id E06E021F8911 for ; Wed, 13 Feb 2013 08:28:31 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hm6so1635708wib.2 for ; Wed, 13 Feb 2013 08:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=t41Ntmmlr+cuQQrLpkqiW4mrSduoxzjHo/Bu5E6YWUA=; b=XdfX8tN0ndDuC2noUwcFYI0IaVeCUZMisaV1SOU3xSv42lg+6j5nobmVvRGxc9j4h+ aW4SHViCfzacwXoKki6nFGMN/R08Qw/aikROq7W9d3+gHTcMjXWE2oiLO5N8gy9CjcNI 2sdcIgPoC5f74jK28Lrem8T9vZQVIxerU5b1/7zNhYv5GAMoUEBqnh4chJOgVd0qjiha fQB0karzu1M8esWTkW7uTBD07gHZULA6n9Rf0qFZD7Oq9YP+9InqGlaZXppXeYa9MNTk TjD6tsjnfErxA+7n+so5G98k3hBGEF05hwvGc5LBtdQWHxMFQwPTOmo03GL5s4QwFO1S 9vWA== MIME-Version: 1.0 X-Received: by 10.180.105.232 with SMTP id gp8mr11089402wib.33.1360772908737; Wed, 13 Feb 2013 08:28:28 -0800 (PST) Received: by 10.194.19.226 with HTTP; Wed, 13 Feb 2013 08:28:28 -0800 (PST) Date: Wed, 13 Feb 2013 11:28:28 -0500 Message-ID: From: Phillip Hallam-Baker To: General discussion of application-layer protocols Content-Type: multipart/alternative; boundary=f46d044402d0d865a404d59da108 Subject: [apps-discuss] .well-known as a one stop shopping location for Web Services 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: Wed, 13 Feb 2013 16:28:37 -0000 --f46d044402d0d865a404d59da108 Content-Type: text/plain; charset=ISO-8859-1 I would like to set up a 'one stop shopping service' for protocol identifiers. The idea being that registration of application layer protocols is an application layer concern alone. It should not be necessary to have multiple levels of review to register a single protocol. That is wasteful of time for both the applicant and the reviewers. In particular, we would like to encourage applications to have a consistent approach to discovery and to use of URIs. This is best achieved if using facilities like application specific URIs to identify end points and SRV prefixes are the easiest path rather than the hardest. Looking through the existing infrastructure, I believe this can be achieved as follows: *1) Reuse the existing .well-known registry to assign the unique token.* This registry is specification required which might be a bug. But could be changed if necessary. While many consider the .well-known approach to specify the URI path as something of a 'hack' (as I do actually), having a default path is actually quite useful even if we eventually end up with a discovery protocol that makes the .well-known prefix redundant. The main use for a non default port configuration is to facilitate deployment and debugging. HTTP has supported ports other than 80 from the start. But the fact that port 80 traffic is almost certainly some sort of Web traffic is still useful to know. Example: Registered service identifier is 'foo' Default service path is /.well-known/foo/ *2) Register the _wk or _well-known SRV prefix as a service* RFC 6335 does not really describe the definition of service schemes that are not in _tcp or _udp but the original need for the identifiers came from the fact that SRV was re-using the existing well known port list and some services allowed either transport. If we are going to re-use the .well-known registry in the same way, the logical approach would be to do the same thing and reserve a label for the purpose. Example: Foo service prefix is _foo._wk, service at example.com is advertised thus: _foo._wk.example.com SRV 1 1 80 foo1.example.com *3) Register the wk: URI scheme* When the entities being referenced are entities that are constructed by a protocol, the most natural means of identifying them is a protocol specific URI. Exchanging http:// format URIs to identify protocol specific information is pulls us down to the wrong level of abstraction. A http URI is not very useful in protocol negotiation as we don't know what the type of service it is unless we try to Example: Reserved URI space is wk:foo: The uri for the service endpoint at example.com would be wk:foo:example.com So now imagine that we had a service offering geographic information that specified the following as service endpoints: wk:foo:example.com wk:bar:example.com wk:fooplus:example.com I think it is pretty clear that trying to deal with this type of endpoint in a mashup would be rather easier than the traditional http variety. Note that since the registration for .well known is already a URI registration (of sorts) this automatic registration should not entail different considerations. Note also that the default mapping of the wk:foo:example.com/xxx URI would be to http://example.com/.well-known/foo/xxx but we might define a discovery mechanism that would change this default in the future. *4: Register the wk= Content Type parameter* One of the perennial arguments in Web Services is how to label the content in MIME. I don't think there is a good answer. We already have application/json and application/xml. And it is entirely possible that people will continue to write protocols that are coding agnostic between JSON and XML. My Protogen compiler supports either encoding without any extra effort beyond setting a flag. So it seems like any information to indicate which protocol the messages are encoding has to be relegated to a parameter. Example: XML protocol messages: application/xml; wk=foo JSON protocol messages: application/json; wk=foo Next steps: 1) Request reservation of the code points specified above 2) RFC to describe implications for .well-known registrations 3) RFC with informative 'how to guide' describing acceptable precedents The idea in 3 is not to be unnecessarily restrictive. Applying a design template from the guide should be a sufficient but not a necessary criteria. A requirement for expert review of an application protocol specification is in a sense a failure. If the Internet protocols are not sufficiently robust that they can be used without risk to the Internet then we should be fixing the lower Internet protocol layers. If there are subtleties that are not immediately apparent, well that's a documentation failure. If the developer is a clod who doesn't care about getting it right they are going to ignore the expert review anyway. -- Website: http://hallambaker.com/ --f46d044402d0d865a404d59da108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would like to set up a 'one stop shopping service' for protocol i= dentifiers. The idea being that registration of application layer protocols= is an application layer concern alone. It should not be necessary to have = multiple levels of review to register a single protocol. That is wasteful o= f time for both the applicant and the reviewers.

In particular, we would like to encourage applications to ha= ve a consistent approach to discovery and to use of URIs. This is best achi= eved if using facilities like application specific URIs to identify end poi= nts and SRV prefixes are the easiest path rather than the hardest.

Looking through the existing infrastructure, I believe = this can be achieved as follows:

1) Reuse the e= xisting .well-known registry to assign the unique token.

This registry is specification required which might be a bug= . But could be changed if necessary. While many consider the .well-known ap= proach to specify the URI path as something of a 'hack' (as I do ac= tually), having a default path is actually quite useful even if we eventual= ly end up with a discovery protocol that makes the .well-known prefix redun= dant.

The main use for a non default port configuration is to= facilitate deployment and debugging. HTTP has supported ports other than 8= 0 from the start. But the fact that port 80 traffic is almost certainly som= e sort of Web traffic is still useful to know.

Example: Registered service identifier is 'foo'=
Default service path is /.well-known/foo/


2) Register the _wk or _well-known SRV prefix as a ser= vice

RFC 6335 does not really describe the definition of ser= vice schemes that are not in _tcp or _udp but the original need for the ide= ntifiers came from the fact that SRV was re-using the existing well known p= ort list and some services allowed either transport.

If we are going to re-use the .well-known registry in t= he same way, the logical approach would be to do the same thing and reserve= a label for the purpose.

Example: Foo servic= e prefix is _foo._wk, service at example.com= is advertised thus:

_foo._wk.example.com<= /a> SRV 1 1 80 foo1.example.com


3) Register the wk: URI scheme<= /div>

When the entities being referenced are entities that ar= e constructed by a protocol, the most natural means of identifying them is = a protocol specific URI.=A0

Exchanging http:// for= mat URIs to identify protocol specific information is pulls us down to the = wrong level of abstraction. A http URI is not very useful in protocol negot= iation as we don't know what the type of service it is unless we try to= =A0

Example: Reserved URI space is wk:foo:=A0
The uri for the service endpoint at example.com would be wk:foo:example.= com

So now imagine that we had a service offering geographi= c information that specified the following as service endpoints:
=
wk:foo= plus:example.com

I think it is pretty clear that trying to deal with this type of endpoint= in a mashup would be rather easier than the traditional http variety.=A0

Note that since the registration for .well known is alr= eady a URI registration (of sorts) this automatic registration should not e= ntail different considerations.

Note also that the= default mapping of the wk:foo:example.c= om/xxx URI would be to http://example.com/.well-known/foo/xxx but we might define a discove= ry mechanism that would change this default in the future.


4: Register the wk=3D Content Type pa= rameter

One of the perennial arguments in Web = Services is how to label the content in MIME. I don't think there is a = good answer.

We already have application/json and application/xml. A= nd it is entirely possible that people will continue to write protocols tha= t are coding agnostic between JSON and XML. My Protogen compiler supports e= ither encoding without any extra effort beyond setting a flag.

So it seems like any information to indicate which prot= ocol the messages are encoding has to be relegated to a parameter.=A0
=

Example:=A0

XML protocol messa= ges: =A0application/xml; wk=3Dfoo
JSON protocol messages: =A0application/json; wk=3Dfoo


Next steps:

1) Request res= ervation of the code points specified above
2) RFC to describe im= plications for .well-known registrations
3) RFC with informative 'how to guide' describing acceptable p= recedents

The idea in 3 is not to be unnecessarily= restrictive. Applying a design template from the guide should be a suffici= ent but not a necessary criteria.=A0

A requirement for expert review of an application proto= col specification is in a sense a failure. If the Internet protocols are no= t sufficiently robust that they can be used without risk to the Internet th= en we should be fixing the lower Internet protocol layers. If there are sub= tleties that are not immediately apparent, well that's a documentation = failure. If the developer is a clod who doesn't care about getting it r= ight they are going to ignore the expert review anyway.

--
Website: http://h= allambaker.com/
--f46d044402d0d865a404d59da108-- From mikekelly321@gmail.com Wed Feb 13 09:59:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081C621F89EF for ; Wed, 13 Feb 2013 09:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 fUkCgV5MBczv for ; Wed, 13 Feb 2013 09:59:39 -0800 (PST) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by ietfa.amsl.com (Postfix) with ESMTP id 74C5621F892D for ; Wed, 13 Feb 2013 09:59:39 -0800 (PST) Received: by mail-ea0-f178.google.com with SMTP id a14so584281eaa.23 for ; Wed, 13 Feb 2013 09:59:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tHPNQLASSZR3fvDF96u+MVxNt6/BGTFN4mGGW4sgj4w=; b=n2U+l/RoWqTWdou+1Cl0VZDj/tVEAGtTb1E4vTqQIn41YVXC+PfmB2MNZ9rTXFuA67 HmfJQb7T/xGL7UeAV10S1wtz5ClbxHwPiRKd3pS48VTG1R0CLr/dPpiCxKWbyPwZCDGQ WztSoV8/oneYf5lVjti5vFAAgiONLJ84Iy5sOdZ6g8HWLstHIbgJucT9tiPzXHqQbQNg 9Omaz38qLheX0/azObsDUJ45m5NH4xupE0jaSm/EWhywTTPNj8errmYi3Hy6grVeoOVS MRfkiON/RuzZd9H2cCDnGAe0WafOl6DOegE/jdiE+smeeMLfeSmL9viTS+b2clYE4l2G MqwA== MIME-Version: 1.0 X-Received: by 10.14.3.70 with SMTP id 46mr7259465eeg.2.1360778378383; Wed, 13 Feb 2013 09:59:38 -0800 (PST) Received: by 10.223.168.10 with HTTP; Wed, 13 Feb 2013 09:59:38 -0800 (PST) Received: by 10.223.168.10 with HTTP; Wed, 13 Feb 2013 09:59:38 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Feb 2013 17:59:38 +0000 Message-ID: From: Mike Kelly To: craigmcc@gmail.com Content-Type: multipart/alternative; boundary=047d7b66f619dc915b04d59ee7bb Cc: REST-Discuss Discussion Group , IETF Apps Discuss , "api-craft@googlegroups.com" , "hypermedia@librelist.com" , hal-discuss@googlegroups.com, hypermedia-web@googlegroups.com Subject: Re: [apps-discuss] [rest-discuss] Re: New Internet-Draft: JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 17:59:41 -0000 --047d7b66f619dc915b04d59ee7bb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Craig, Thanks for your response. The problem with that approach is you have to force your access model around the HTTP verbs. So if you have different transitions possible for a PUT or POST request on a given resource, and each have different access rules, then you're out of options (no pun intended). Another approach is to create permission resources that represent the roles the requesting user has for particular activities. The roles can be more descriptive, flexible, and intuitive to clients that way. Are there some compelling reasons to work around HTTP that i'm missing. Along the same lines, I'm a bit concerned about absorbing HTTP stuff into the media type. Which I think this technique is guilty of. A while back I considered adding etag info for embedded resources but canned it because of the same concern.. Out of interest how would you feel about that etag approach? Cheers, M On 13 Feb 2013 17:35, "Craig McClanahan" wrote: > > I've written several APIs lately that contain a similar concept to the "links" abstraction with a useful extension -- we also include an "allowed" field that contains an array of the HTTP verbs that this user is allowed to perform against the URL specified by "href". Essentially, we're saving the client the need to do an OPTIONS call to determine what verbs are supported for that user. > > A use case for this is when displaying content that may or may not be editable (or can be deleted) by the requesting user. If so, the "allowed" field would say '[ "GET", "PUT", "DELETE" ]'. If not, it would just say '[ "GET" ]'. A client UI can use this information to decide whether or not to display enabled "Edit" or "Delete" buttons. > > Craig McClanahan > > On Tue, Feb 12, 2013 at 1:52 PM, Mike Kelly wrote: >> >> >> >> Here's a slightly more useful link than the previous one! >> >> http://tools.ietf.org/html/draft-kelly-json-hal-05 >> >> On Tue, Feb 12, 2013 at 7:53 AM, Mike Kelly mikekelly321@gmail.com> wrote: >> > Hello all, >> > >> > fyi, I have updated the following internet draft: >> > >> > http://www.ietf.org/id/draft-kelly-json-hal-04.txt >> > >> > All thoughts, comments, suggestions, etc welcome >> > >> > Cheers, >> > Mike >> >> -- >> Mike >> >> http://twitter.com/mikekelly85 >> http://github.com/mikekelly >> http://linkedin.com/in/mikekelly123 >> >> __._,_.___ >> Reply via web post >> Reply to sender >> Reply to group >> Start a New Topic >> Messages in this topic (2) >> Recent Activity: >> New Members 5 >> Visit Your Group >> Switch to: Text-Only, Daily Digest =95 Unsubscribe =95 Terms of Use =95 = Send us Feedback >> . >> >> __,_._,___ > > --047d7b66f619dc915b04d59ee7bb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi Craig,

Thanks for your response.

The problem with that approach is you have to force your acc= ess model around the HTTP verbs. So if you have different transitions possi= ble for a PUT or POST request on a given resource, and each have different = access rules, then you're out of options (no pun intended).

Another approach is to create permission resources that repr= esent the roles the requesting user has for particular activities. The role= s can be more descriptive, flexible, and intuitive to clients that way.

Are there some compelling reasons to work around HTTP that i= 'm missing.

Along the same lines, I'm a bit concerned about absorbin= g HTTP stuff into the media type. Which I think this technique is guilty of= . A while back I considered adding etag info for embedded resources but can= ned it because of the same concern.. Out of interest how would you feel abo= ut that etag approach?

Cheers,
M

On 13 Feb 2013 17:35, "Craig McClanahan" <craigmcc@gmail.com> wrote:
>
> I've written several APIs lately that contain a similar concept to= the "links" abstraction with a useful extension -- we also inclu= de an "allowed" field that contains an array of the HTTP verbs th= at this user is allowed to perform against the URL specified by "href&= quot;. =A0Essentially, we're saving the client the need to do an OPTION= S call to determine what verbs are supported for that user.
>
> A use case for this is when displaying content that may or may not be = editable (or can be deleted) by the requesting user. =A0If so, the "al= lowed" field would say '[ "GET", "PUT", "= DELETE" ]'. =A0If not, it would just say '[ "GET" ]&= #39;. =A0A client UI can use this information to decide whether or not to d= isplay enabled "Edit" or "Delete" buttons.
>
> Craig McClanahan
>
> On Tue, Feb 12, 2013 at 1:52 PM, Mike Kelly <mikekelly321@gmail.com> wrote:
>>
>> =A0
>>
>> Here's a slightly more useful link than the previous one!
>>
>> htt= p://tools.ietf.org/html/draft-kelly-json-hal-05
>>
>> On Tue, Feb 12, 2013 at 7:53 AM, Mike Kelly mikekelly321@gmail.com> wrote:
>> > Hello all,
>> >
>> > fyi, I have updated the following internet draft:
>> >
>> > http://www.ietf.org/id/draft-kelly-json-hal-04.txt
>> >
>> > All thoughts, comments, suggestions, etc welcome
>> >
>> > Cheers,
>> > Mike
>>
>> --
>> Mike
>>
>> http://twitter.com/mike= kelly85
>> http://github.com/mikekell= y
>> http://linkedin.co= m/in/mikekelly123
>>
>> __._,_.___
>> Reply via web post
>> Reply to sender
>> Reply to group
>> Start a New Topic
>> Messages in this topic (2)
>> Recent Activity:
>> New Members 5
>> Visit Your Group
>> Switch to: Text-Only, Daily Digest =95 Unsubscribe =95 Terms of Us= e =95 Send us Feedback
>> .
>>
>> __,_._,___
>
>

--047d7b66f619dc915b04d59ee7bb-- From paulej@packetizer.com Wed Feb 13 11:21:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAFB1F0D0A; Wed, 13 Feb 2013 11:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 FoY8HBo-tepl; Wed, 13 Feb 2013 11:21:40 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 405501F0D08; Wed, 13 Feb 2013 11:21:37 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r1DJLJJ3022532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2013 14:21:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360783280; bh=nwNsfy8UoJ0Iqs67I7DrVtsLuNJhijSnhJCTXs9FyGE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ptb5LEQElB1mFvnmw/nkd/eO2CwnFwjGJxBrKiYDMkGEOCohcJr5OqlQao+0gH8+I QOamaJ8X1Ce+hpqiIjbPSAOlOpGP+x4jXFo2LL09h9igiICj7FbfAsFoF/ryq96E0w 7IAPKkaIFVEa2SacoNAZzHvDlL1PsUl3aBuoQVno= From: "Paul E. Jones" To: "'Markus Lanthaler'" , "'Barry Leiba'" , "'Cyrus Daboo'" References: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> In-Reply-To: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> Date: Wed, 13 Feb 2013 14:21:31 -0500 Message-ID: <038501ce0a1f$54d3e580$fe7bb080$@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: AQJthQtURgZvEpJmuy3rVEOM8bQN4AJzqE8uAwde2pSXDTQe4A== Content-Language: en-us Cc: 'CardDAV' , calsify@ietf.org, 'IETF Apps Discuss' Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 19:21:42 -0000 Markus, While my opinion is just one, I personally don't see the point of adding JSON-LD to the mix. Use of JSON-LD just means there is another 50+ page specification to go read and more work to ensure data is properly formatted. Whether JSON-LD is used or not, the jCard spec would have to describe the name/value pairs, arrays, or objects inside the JSON object specific to the jCard. Just using JSON the same example might be: { "FN": "John Doe", "ROLE": "Mr. Anonymous" } The common underlying syntax is JSON and that's what all devices can parse. JSON-LD seems like an unnecessary layer to me. Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Markus Lanthaler > Sent: Wednesday, February 13, 2013 5:06 AM > To: 'Barry Leiba'; 'Cyrus Daboo' > Cc: 'IETF Apps Discuss'; calsify@ietf.org; 'CardDAV' > Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft > charter > > Even though I don't have any *major* objections I still wanted to raise > some concerns about the consequences of such highly specialized formats, > all similar but nevertheless not truly interoperable/compatible. As a > developer you basically have to write specific code for each of those > formats. > > I was wondering if it was ever considered to use, e.g., something like > JSON-LD [1] as the base for formats like these and limit the > standardization to a shared vocabulary (i.e., URLs for the required > properties) and a set of constraints and conventions captured in a > profile (see [2] for details). > > The advantage would be that much more code could be reused and data- > integration would become much simpler. It might look complicated at > first sight, but in reality most of what's needed is already there. For > example, the work to define URLs for the various properties for both > iCalendar [3] and vCard [4] has already been done at W3C (not as a REC > though). > > So, a simple vCard represented in JSON-LD would look as follows: > > { > "@context": { > "@vocab": "http://www.w3.org/2001/vcard-rdf/3.0#" > }, > "FN": "John Doe", > "ROLE": "Mr. Anonymous" > } > > You would have to define a number of constraints in the form of a > profile if you also want clients that process this as JSON instead of > JSON-LD to be able to interpret the data. The reason is that in JSON-LD > you can serialize the exactly the same data in a number of different > ways (e.g., you could use different field names that still expand to the > same URLs; the context defines those mappings). JSON-only clients are > less flexible and thus need to know the exact structure and field names. > > The question I thus would like to ask is: Is there a compelling reason > why this can't be based on a format as JSON-LD? Taking out the potential > complexity by requiring a profile defining a number of constraints on > how the data is serialized, I only see advantages of doing so. > > > Cheers, > Markus > > > Disclaimer: I'm one of the authors of JSON-LD. > > > [1] http://json-ld.org/spec/latest/json-ld-syntax/ (JSON-LD will become > a W3C REC soon; it will enter last call by the end of the month) [2] > http://tools.ietf.org/html/draft-wilde-profile-link > [3] http://www.w3.org/TR/rdfcal/ > [4] http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ > > > > -- > Markus Lanthaler > @markuslanthaler > > > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of Barry Leiba > > Sent: Wednesday, February 13, 2013 1:03 AM > > To: Cyrus Daboo > > Cc: CardDAV; calsify@ietf.org; IETF Apps Discuss > > Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft > > charter > > > > This is going to be Pete's working group, but let me add one thing to > > what Cyrus said about the aggressive schedule and the "fast track": > > > > A while ago, we chartered the imapmove working group on a very fast > > chartering schedule, and we're looking to do even more here. The idea > > that "it takes too long to create a working group" is something we > > need to dispel. In this case, we have an opportunity, with two > > back-to-back IESG telechats a week apart, so we are looking for *this > > Friday* (15 Feb) to put this on the telechat agenda for next week (21 > > Feb), and to have it get final approval on the 28th. That's three > > weeks from charter proposal to approval. > > > > That means that we need to hear any *major* objections to this now -- > > please have a look at this quickly and call out anything we've really > > goofed on before Friday. We then have until next Thursday (21st) to > > get the details of the charter in shape for broad review. > > > > Barry, Applications AD > > > > On Tue, Feb 12, 2013 at 5:11 PM, Cyrus Daboo wrote: > > > Hi folks, > > > At the prompting of the Weirds WG there is a need to move more > > quickly on > > > developing specifications for JSON-based data formats for iCalendar > > and > > > vCard data, without necessarily waiting on other (proposed) JSON > > working > > > group work to proceed. > > > > > > A proposed charter for a "fast-track" Working Group is posted at > > > for > > feedback. The > > > charter defines aggressive milestones and attempts to limit the > > objectives > > > such that those are achievable. Please review and post comments back > > to the > > > apps-discuss list. > > > > > > Whilst initial focus will be on the draft charter, some drafts have > > already > > > been published describing possible (different) approaches. One for > > > iCalendar: > > > > json/>, > > > and one for vCard: > > > . We also > > hope to > > > have an alternative jCard draft published in the next day or two > > > that > > uses > > > the same approach as draft-kewisch-et-al-icalendar-in-json. These > > should > > > provide a good basis for initial input into the working group. > > > > > > -- > > > Cyrus Daboo > > _______________________________________________ > > 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 kewisch@gmail.com Wed Feb 13 12:52:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6189C21E8054; Wed, 13 Feb 2013 12:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixe8wlGzbA58; Wed, 13 Feb 2013 12:52:06 -0800 (PST) Received: from mail-bk0-f51.google.com (mail-bk0-f51.google.com [209.85.214.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1E621E803D; Wed, 13 Feb 2013 12:52:05 -0800 (PST) Received: by mail-bk0-f51.google.com with SMTP id ik5so757948bkc.10 for ; Wed, 13 Feb 2013 12:52:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-forwarded-message-id:content-type; bh=Aa951Efl2pF1RHcVlQQQPPWxwhdtxz8z7KjSJo2uvk4=; b=zg2RtzsAk7gJpcLsCASTzhMij5/tJQnUQoZk0SIXD9U6zsLFQH0q3GKc8HrjrkGlUS XfK8SFKfx4t6GTJ5mVcLH0418NQG1jBoqBooAjq/HysEs2cyY6K3Wh0i3gFelm6h2T7y XXDo2srCVoed6w03TVRXLAOQuZkt5hn44xQFEEDczQeGUHfneN7XhA9BxPWVMyjtNcKE oNyuwcNSxoK4lU1GhteTTwZxo0OrVel438kPE74tzSttytp7hpOOA2Wtp5ThccvbJO8o 8Nhifh9D+1oenEDmptH6CXqS35Tyt9SfGJEmrcCs8Hh8blMD8iZBJzTnijQloZ/NKQQJ 3UUw== X-Received: by 10.204.157.150 with SMTP id b22mr7024088bkx.121.1360788724711; Wed, 13 Feb 2013 12:52:04 -0800 (PST) Received: from oskar.fritz.box (e177139085.adsl.alicedsl.de. [85.177.139.85]) by mx.google.com with ESMTPS id o9sm15986019bko.15.2013.02.13.12.52.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 12:52:04 -0800 (PST) Message-ID: <511BFCF4.6080606@gmail.com> Date: Wed, 13 Feb 2013 21:52:04 +0100 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20130213200324.11419.75605.idtracker@ietfa.amsl.com> In-Reply-To: <20130213200324.11419.75605.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130213200324.11419.75605.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090902060206030403080102" Cc: calsify@ietf.org, vcarddav@ietf.org Subject: [apps-discuss] New Internet-Draft: jCard: The JSON format for vCard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 20:52:07 -0000 This is a multi-part message in MIME format. --------------090902060206030403080102 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello apps-discuss, as you might know, the calconnect group has been working on a draft for a JSON based data format for iCalendar, which you can find here [1]. This draft comes with a fully functional javascript parser/converter that you can find at [2]. The library can also process recurrence data and timezone conversion and is being used in the latest version of Firefox OS and is also targeted at the Lightning extension to Thunderbird. The data format we chose has gone through various iterations. Although it may not be the common object-as-root type JSON, I think its suited best for its task: bidirectional, semantically lossless conversion between iCalendar and JSON. It has been discussed on the vcarddav and calsify lists. Consequently, I have created a draft for vCard in JSON using a similar notation [3]. There are of course some slight differences between vCard and iCalendar causing some open issues ready for discussion in a WG. You can find them at the end of the draft, any input is appreciated. For additional reading, check out some related discussion on the calsify [4] and vcarddav [5] lists. I have not yet adapted my ical.js parser to also read data as in this draft, but the changes are so minimal that it should not be a big deal. I'll be happy to take part in any WG calls or discussion related to moving vCard in JSON forward, so let me know what you think. Philipp [1] http://www.ietf.org/id/draft-kewisch-et-al-icalendar-in-json-01.txt [2] https://github.com/kewisch/ical.js/ [3] http://www.ietf.org/id/draft-kewisch-vcard-in-json-00.txt [4] http://www.ietf.org/mail-archive/web/calsify/current/maillist.html [5] http://www.ietf.org/mail-archive/web/vcarddav/current/maillist.html -------- Original Message -------- Subject: New Version Notification for draft-kewisch-vcard-in-json-00.txt Date: Wed, 13 Feb 2013 12:03:24 -0800 From: internet-drafts@ietf.org To: mozilla@kewis.ch A new version of I-D, draft-kewisch-vcard-in-json-00.txt has been successfully submitted by Philipp Kewisch and posted to the IETF repository. Filename: draft-kewisch-vcard-in-json Revision: 00 Title: jCard: The JSON format for vCard Creation date: 2013-02-13 Group: Individual Submission Number of pages: 25 URL: http://www.ietf.org/internet-drafts/draft-kewisch-vcard-in-json-00.txt Status: http://datatracker.ietf.org/doc/draft-kewisch-vcard-in-json Htmlized: http://tools.ietf.org/html/draft-kewisch-vcard-in-json-00 Abstract: This specification defines "jCard", a JSON format for vCard data. The IETF Secretariat --------------090902060206030403080102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello apps-discuss,

as you might know, the calconnect group has been working on a draft for a JSON based data format for iCalendar, which you can find here [1]. This draft comes with a fully functional javascript parser/converter that you can find at [2]. The library can also process recurrence data and timezone conversion and is being used in the latest version of Firefox OS and is also targeted at the Lightning extension to Thunderbird.

The data format we chose has gone through various iterations. Although it may not be the common object-as-root type JSON, I think its suited best for its task: bidirectional, semantically lossless conversion between iCalendar and JSON. It has been discussed on the vcarddav and calsify lists.

Consequently, I have created a draft for vCard in JSON using a similar notation [3]. There are of course some slight differences between vCard and iCalendar causing some open issues ready for discussion in a WG. You can find them at the end of the draft, any input is appreciated. For additional reading, check out some related discussion on the calsify [4] and vcarddav [5] lists. I have not yet adapted my ical.js parser to also read data as in this draft, but the changes are so minimal that it should not be a big deal.

I'll be happy to take part in any WG calls or discussion related to moving vCard in JSON forward, so let me know what you think.

Philipp

[1] http://www.ietf.org/id/draft-kewisch-et-al-icalendar-in-json-01.txt
[2] https://github.com/kewisch/ical.js/
[3] http://www.ietf.org/id/draft-kewisch-vcard-in-json-00.txt
[4] http://www.ietf.org/mail-archive/web/calsify/current/maillist.html
[5] http://www.ietf.org/mail-archive/web/vcarddav/current/maillist.html


-------- Original Message --------
Subject: New Version Notification for draft-kewisch-vcard-in-json-00.txt
Date: Wed, 13 Feb 2013 12:03:24 -0800
From: internet-drafts@ietf.org
To: mozilla@kewis.ch 


A new version of I-D, draft-kewisch-vcard-in-json-00.txt
has been successfully submitted by Philipp Kewisch and posted to the
IETF repository.

Filename:	 draft-kewisch-vcard-in-json
Revision:	 00
Title:		 jCard: The JSON format for vCard
Creation date:	 2013-02-13
Group:		 Individual Submission
Number of pages: 25
URL:             http://www.ietf.org/internet-drafts/draft-kewisch-vcard-in-json-00.txt
Status:          http://datatracker.ietf.org/doc/draft-kewisch-vcard-in-json
Htmlized:        http://tools.ietf.org/html/draft-kewisch-vcard-in-json-00


Abstract:
   This specification defines "jCard", a JSON format for vCard data.

                                                                                  


The IETF Secretariat


--------------090902060206030403080102-- From barryleiba.mailing.lists@gmail.com Wed Feb 13 13:02:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604231F0D0F for ; Wed, 13 Feb 2013 13:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.924 X-Spam-Level: X-Spam-Status: No, score=-102.924 tagged_above=-999 required=5 tests=[AWL=0.053, 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 uztBhyQFix6u for ; Wed, 13 Feb 2013 13:02:00 -0800 (PST) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 65EBC1F0D09 for ; Wed, 13 Feb 2013 13:02:00 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id b10so1511096vea.2 for ; Wed, 13 Feb 2013 13:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LY68pGQi6fmyZIcUK1BIRDOshoz66e7UeacksOm7W7k=; b=MHlq8QOtACHdMa4ztmK5xJysSGvx/UDb+aPxufYGjZGONT8MJ1jva1TOYWRRpP9c4E 52X97Bte7UQ2XtX6jMl2yANYWS3u2pj33FX/qmxW71AC66yxzsWuKdUAYYsVTzQOxkHy HMwsDIMVD8auVk8LVTVM8fSf1+8XcCYlccrfFqpfN+bm/xThzGXzocSABlqr3Dh0lfrq vxpw2T9w9TVyVtN/LNy9tcsu7ckaDoJn2Kia5T9NbEffCvhNv2iohYLveImM4CnEUk0C t0MEnm2k3UqIzXNlLyHcl65BG14bm0oNLmVWKLG73Go1pYzdUxV+Q6SMqONFe4BXwJSg c6Iw== MIME-Version: 1.0 X-Received: by 10.58.106.161 with SMTP id gv1mr31146547veb.35.1360789319869; Wed, 13 Feb 2013 13:01:59 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Wed, 13 Feb 2013 13:01:59 -0800 (PST) In-Reply-To: <511BFCF4.6080606@gmail.com> References: <20130213200324.11419.75605.idtracker@ietfa.amsl.com> <511BFCF4.6080606@gmail.com> Date: Wed, 13 Feb 2013 16:01:59 -0500 X-Google-Sender-Auth: SUbpvi-9FoPVyjO-czNW81i-RQE Message-ID: From: Barry Leiba To: Philipp Kewisch Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] New Internet-Draft: jCard: The JSON format for vCard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 21:02:05 -0000 (Trimming the distribution list to just apps-discuss for this.) > as you might know, the calconnect group has been working on a draft for a JSON > based data format for iCalendar, which you can find here [1]. This draft comes with > a fully functional javascript parser/converter that you can find at [2]. The library can > also process recurrence data and timezone conversion and is being used in the > latest version of Firefox OS and is also targeted at the Lightning extension to > Thunderbird. On that point, I suggest that for the next update to draft-kewisch-et-al-icalendar-in-json, you take a look at draft-sheffer-running-code and consider adding an "Implementation Status" section to the icalendar-in-json draft. Barry From kewisch@gmail.com Wed Feb 13 13:19:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C896C21F8891; Wed, 13 Feb 2013 13:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01hON03AYYE6; Wed, 13 Feb 2013 13:19:04 -0800 (PST) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by ietfa.amsl.com (Postfix) with ESMTP id CCDB621F8890; Wed, 13 Feb 2013 13:19:03 -0800 (PST) Received: by mail-bk0-f42.google.com with SMTP id jk7so768886bkc.1 for ; Wed, 13 Feb 2013 13:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=5J6ZgONjpSLPGFMyvZxrRz/iH6FtpyqnG60PWH7f+To=; b=QtqOLraW+lL7JxfJ31oHv8zk8vHE+esTc8rUSdPenc7hNuSRvhiJDqrGDw/k8IVfbD K1NR+f+SJKXjD4vmcZy3wa2L7VO2YFHwwwntHMcGanJLjmwMpcSqH11CqtCXGwsbmnjM xVLGbQ5RxHjYQApHTwBuSMZCB6DdWnxKTFskJnx19DMuO7GwSiGa+2j2gLJ9ghTecRhE ubMTQ8D8O6hCv2KQXQHYcOEIFLAqZyi3lMCLRiZrmETXPsrb3sJOV3QGLjc4gQSI0hO1 2QwTfj3GQDpNq/0TmjT3gIEhV2IJN5wcNhgC3kxvvdZluNW98TvQ2MQyNnXkzDcSzvSL K3YQ== X-Received: by 10.204.5.211 with SMTP id 19mr7123845bkw.29.1360790342562; Wed, 13 Feb 2013 13:19:02 -0800 (PST) Received: from oskar.fritz.box (e177139085.adsl.alicedsl.de. [85.177.139.85]) by mx.google.com with ESMTPS id v2sm3541824bkw.5.2013.02.13.13.18.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 13:19:01 -0800 (PST) Message-ID: <511C0342.1030302@gmail.com> Date: Wed, 13 Feb 2013 22:18:58 +0100 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "Paul E. Jones" , 'Markus Lanthaler' References: <00ac01ce09d1$cb1774d0$61465e70$@lanthaler@gmx.net> <038501ce0a1f$54d3e580$fe7bb080$@packetizer.com> In-Reply-To: <038501ce0a1f$54d3e580$fe7bb080$@packetizer.com> Content-Type: multipart/alternative; boundary="------------070704070201080706070504" Cc: 'IETF Apps Discuss' , calsify@ietf.org, 'CardDAV' Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 21:19:05 -0000 This is a multi-part message in MIME format. --------------070704070201080706070504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Markus, while I agree that re-using formats is often a good idea, I'm with Paul in this case. The amount of data in a vcard object is not that high, so adding the overhead of JSON-LD doesn't bring much advantage to my mind. Also, property parameters and structured values make the key-value based approach quickly come to its limits. For vCard, the amount of processing needed is fairly low. Accessing object members is most of the deal. This does warrant considering JSON-LD since as I've read, the goal is a lightweight data format. If the amount of processing is considerably higher (as for iCalendar in JSON, for example: timezones, recurrence expansion, ...) a dedicated library for processing is needed. To my mind I think the format for vCard in JSON and iCalendar in JSON should be similar, since the format for vCard and iCalendar is also similar. Given there is a need for a dedicated library for iCalendar in JSON anyway, I wouldn't go with JSON-LD. This is of course just my personal opinion, I don't object putting JSON-LD on the table for discussion in the WG. Philipp On 2/13/13 8:21 PM, Paul E. Jones wrote: > Markus, > > While my opinion is just one, I personally don't see the point of adding > JSON-LD to the mix. Use of JSON-LD just means there is another 50+ page > specification to go read and more work to ensure data is properly formatted. > > Whether JSON-LD is used or not, the jCard spec would have to describe the > name/value pairs, arrays, or objects inside the JSON object specific to the > jCard. Just using JSON the same example might be: > > { > "FN": "John Doe", > "ROLE": "Mr. Anonymous" > } > > The common underlying syntax is JSON and that's what all devices can parse. > JSON-LD seems like an unnecessary layer to me. > > Paul > >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of Markus Lanthaler >> Sent: Wednesday, February 13, 2013 5:06 AM >> To: 'Barry Leiba'; 'Cyrus Daboo' >> Cc: 'IETF Apps Discuss'; calsify@ietf.org; 'CardDAV' >> Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft >> charter >> >> Even though I don't have any *major* objections I still wanted to raise >> some concerns about the consequences of such highly specialized formats, >> all similar but nevertheless not truly interoperable/compatible. As a >> developer you basically have to write specific code for each of those >> formats. >> >> I was wondering if it was ever considered to use, e.g., something like >> JSON-LD [1] as the base for formats like these and limit the >> standardization to a shared vocabulary (i.e., URLs for the required >> properties) and a set of constraints and conventions captured in a >> profile (see [2] for details). >> >> The advantage would be that much more code could be reused and data- >> integration would become much simpler. It might look complicated at >> first sight, but in reality most of what's needed is already there. For >> example, the work to define URLs for the various properties for both >> iCalendar [3] and vCard [4] has already been done at W3C (not as a REC >> though). >> >> So, a simple vCard represented in JSON-LD would look as follows: >> >> { >> "@context": { >> "@vocab": "http://www.w3.org/2001/vcard-rdf/3.0#" >> }, >> "FN": "John Doe", >> "ROLE": "Mr. Anonymous" >> } >> >> You would have to define a number of constraints in the form of a >> profile if you also want clients that process this as JSON instead of >> JSON-LD to be able to interpret the data. The reason is that in JSON-LD >> you can serialize the exactly the same data in a number of different >> ways (e.g., you could use different field names that still expand to the >> same URLs; the context defines those mappings). JSON-only clients are >> less flexible and thus need to know the exact structure and field names. >> >> The question I thus would like to ask is: Is there a compelling reason >> why this can't be based on a format as JSON-LD? Taking out the potential >> complexity by requiring a profile defining a number of constraints on >> how the data is serialized, I only see advantages of doing so. >> >> >> Cheers, >> Markus >> >> --------------070704070201080706070504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Markus,

while I agree that re-using formats is often a good idea, I'm with Paul in this case. The amount of data in a vcard object is not that high, so adding the overhead of JSON-LD doesn't bring much advantage to my mind. Also, property parameters and structured values make the key-value based approach quickly come to its limits.

For vCard, the amount of processing needed is fairly low. Accessing object members is most of the deal. This does warrant considering JSON-LD since as I've read, the goal is a lightweight data format. If the amount of processing is considerably higher (as for iCalendar in JSON, for example: timezones, recurrence expansion, ...) a dedicated library for processing is needed.

To my mind I think the format for vCard in JSON and iCalendar in JSON should be similar, since the format for vCard and iCalendar is also similar. Given there is a need for a dedicated library for iCalendar in JSON anyway, I wouldn't go with JSON-LD.

This is of course just my personal opinion, I don't object putting JSON-LD on the table for discussion in the WG.

Philipp


On 2/13/13 8:21 PM, Paul E. Jones wrote:
Markus,

While my opinion is just one, I personally don't see the point of adding
JSON-LD to the mix.  Use of JSON-LD just means there is another 50+ page
specification to go read and more work to ensure data is properly formatted.

Whether JSON-LD is used or not, the jCard spec would have to describe the
name/value pairs, arrays, or objects inside the JSON object specific to the
jCard.  Just using JSON the same example might be:

 {
   "FN": "John Doe",
   "ROLE": "Mr. Anonymous"
 }

The common underlying syntax is JSON and that's what all devices can parse.
JSON-LD seems like an unnecessary layer to me.

Paul


-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
bounces@ietf.org] On Behalf Of Markus Lanthaler
Sent: Wednesday, February 13, 2013 5:06 AM
To: 'Barry Leiba'; 'Cyrus Daboo'
Cc: 'IETF Apps Discuss'; calsify@ietf.org; 'CardDAV'
Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft
charter

Even though I don't have any *major* objections I still wanted to raise
some concerns about the consequences of such highly specialized formats,
all similar but nevertheless not truly interoperable/compatible. As a
developer you basically have to write specific code for each of those
formats.

I was wondering if it was ever considered to use, e.g., something like
JSON-LD [1] as the base for formats like these and limit the
standardization to a shared vocabulary (i.e., URLs for the required
properties) and a set of constraints and conventions captured in a
profile (see [2] for details).

The advantage would be that much more code could be reused and data-
integration would become much simpler. It might look complicated at
first sight, but in reality most of what's needed is already there. For
example, the work to define URLs for the various properties for both
iCalendar [3] and vCard [4] has already been done at W3C (not as a REC
though).

So, a simple vCard represented in JSON-LD would look as follows:

{
  "@context": {
    "@vocab": "http://www.w3.org/2001/vcard-rdf/3.0#"
  },
  "FN": "John Doe",
  "ROLE": "Mr. Anonymous"
}

You would have to define a number of constraints in the form of a
profile if you also want clients that process this as JSON instead of
JSON-LD to be able to interpret the data. The reason is that in JSON-LD
you can serialize the exactly the same data in a number of different
ways (e.g., you could use different field names that still expand to the
same URLs; the context defines those mappings). JSON-only clients are
less flexible and thus need to know the exact structure and field names.

The question I thus would like to ask is: Is there a compelling reason
why this can't be based on a format as JSON-LD? Taking out the potential
complexity by requiring a profile defining a number of constraints on
how the data is serialized, I only see advantages of doing so.


Cheers,
Markus

--------------070704070201080706070504-- From kewisch@gmail.com Wed Feb 13 13:20:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C5321E8084 for ; Wed, 13 Feb 2013 13:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 BpuymxRdEWZz for ; Wed, 13 Feb 2013 13:20:52 -0800 (PST) Received: from mail-bk0-f46.google.com (mail-bk0-f46.google.com [209.85.214.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8513121E8051 for ; Wed, 13 Feb 2013 13:20:52 -0800 (PST) Received: by mail-bk0-f46.google.com with SMTP id j5so771414bkw.19 for ; Wed, 13 Feb 2013 13:20:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uxVky/dZn6TRKz4n2H15Td2q2giIxNXqBAMfW0DRNP4=; b=JM8bNcSBvBxV+WQHfFIiDsl5JBfajAw9FNY3MwoBXm5/qlX3Vq6WTecfw0f7siIuaA 5d7n9kSXa6RgR5l4mm2XtK7yspaHTnX1vYNhXbAwjRstV/QIPrWnATzjAsSFv1W9kPCz MggNTGDkUoe3+lG/pVKnqBFCuDYHfQvVfRa+ln3ZekX689Rn/P2XqfttN0pZEr5RKCI5 7Pr7DO027XjptHHNkXbblRi7x/HSSyW03UOUMjqezhos+cVDHbjZKXMrOWebxY9q6f7/ WERqkpdHwK/njHtI0XFz1MU7su4JMRMeA98+Ghv1SgeGn84QNuK3KFSHKIXoWvl63G3Q kslA== X-Received: by 10.204.151.9 with SMTP id a9mr7062071bkw.90.1360790451449; Wed, 13 Feb 2013 13:20:51 -0800 (PST) Received: from oskar.fritz.box (e177139085.adsl.alicedsl.de. [85.177.139.85]) by mx.google.com with ESMTPS id r17sm16009289bkw.21.2013.02.13.13.20.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 13:20:50 -0800 (PST) Message-ID: <511C03B1.1080807@gmail.com> Date: Wed, 13 Feb 2013 22:20:49 +0100 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Barry Leiba References: <20130213200324.11419.75605.idtracker@ietfa.amsl.com> <511BFCF4.6080606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] New Internet-Draft: jCard: The JSON format for vCard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 21:20:53 -0000 On 2/13/13 10:01 PM, Barry Leiba wrote: > draft-sheffer-running-code and Thanks for the link, I will take a look. One thing that is (almost) in place, we have linked to calconnect-artifacts in both drafts. The linked site will soon contain more resources, like my library. Philipp From mikekelly321@gmail.com Wed Feb 13 14:12:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607F221F86F0; Wed, 13 Feb 2013 14:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=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 oREWxii7AklW; Wed, 13 Feb 2013 14:12:41 -0800 (PST) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id 932A421F86AF; Wed, 13 Feb 2013 14:12:40 -0800 (PST) Received: by mail-ee0-f51.google.com with SMTP id d17so860583eek.38 for ; Wed, 13 Feb 2013 14:12:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OSRPbIHdBJJ+VXrthZ5729+nNbt6yVkAckGs2jbb/8g=; b=s/TGmh9eIqLC/ScsSN8xKY5kfZmQprXDyIA2X00W/1kZBffIRk0CYlfpa5F7KzS3K0 UVQ527JFiL285KgeBpe7+h2RN7b+z6UYdCgIPtZyj/G7Hyaoy8S65tGiDlWEZvo6hnw8 Ed/DPCeMg+TknzKN7hBOg+1J3ndVmyN+XBhWW3f6zHEC2/1aWc7ZRTCjA72uN3+mPTre lu3ebC81Sl1Rl+XAF4OZtLKK4IyZEYezUThlSbifISRpMvwBZEX+B0u3/IqFncjKd+8Y /7r37zT3PPMsDhBvy0ddNdkbBsCFDFFEPaFfdV6wmpC4j73s9PZt74TFHOHb5MKKyiO0 OAcw== MIME-Version: 1.0 X-Received: by 10.14.194.198 with SMTP id m46mr9413179een.8.1360793559621; Wed, 13 Feb 2013 14:12:39 -0800 (PST) Received: by 10.223.168.10 with HTTP; Wed, 13 Feb 2013 14:12:39 -0800 (PST) In-Reply-To: <511C0342.1030302@gmail.com> References: <038501ce0a1f$54d3e580$fe7bb080$@packetizer.com> <511C0342.1030302@gmail.com> Date: Wed, 13 Feb 2013 22:12:39 +0000 Message-ID: From: Mike Kelly To: Philipp Kewisch Content-Type: text/plain; charset=ISO-8859-1 Cc: CardDAV , IETF Apps Discuss , calsify@ietf.org Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 22:12:42 -0000 Fwiw, there are other alternatives to JSON-LD. e.g. I authored hal+json [1] which is a relatively small spec and may be better suited to your needs here. [1] http://tools.ietf.org/html/draft-kelly-json-hal-05 Cheers, M On Wed, Feb 13, 2013 at 9:18 PM, Philipp Kewisch wrote: > Hi Markus, > > while I agree that re-using formats is often a good idea, I'm with Paul in > this case. The amount of data in a vcard object is not that high, so adding > the overhead of JSON-LD doesn't bring much advantage to my mind. Also, > property parameters and structured values make the key-value based approach > quickly come to its limits. > > For vCard, the amount of processing needed is fairly low. Accessing object > members is most of the deal. This does warrant considering JSON-LD since as > I've read, the goal is a lightweight data format. If the amount of > processing is considerably higher (as for iCalendar in JSON, for example: > timezones, recurrence expansion, ...) a dedicated library for processing is > needed. > > To my mind I think the format for vCard in JSON and iCalendar in JSON should > be similar, since the format for vCard and iCalendar is also similar. Given > there is a need for a dedicated library for iCalendar in JSON anyway, I > wouldn't go with JSON-LD. > > This is of course just my personal opinion, I don't object putting JSON-LD > on the table for discussion in the WG. > > Philipp > > > > On 2/13/13 8:21 PM, Paul E. Jones wrote: > > Markus, > > While my opinion is just one, I personally don't see the point of adding > JSON-LD to the mix. Use of JSON-LD just means there is another 50+ page > specification to go read and more work to ensure data is properly formatted. > > Whether JSON-LD is used or not, the jCard spec would have to describe the > name/value pairs, arrays, or objects inside the JSON object specific to the > jCard. Just using JSON the same example might be: > > { > "FN": "John Doe", > "ROLE": "Mr. Anonymous" > } > > The common underlying syntax is JSON and that's what all devices can parse. > JSON-LD seems like an unnecessary layer to me. > > Paul > > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Markus Lanthaler > Sent: Wednesday, February 13, 2013 5:06 AM > To: 'Barry Leiba'; 'Cyrus Daboo' > Cc: 'IETF Apps Discuss'; calsify@ietf.org; 'CardDAV' > Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft > charter > > Even though I don't have any *major* objections I still wanted to raise > some concerns about the consequences of such highly specialized formats, > all similar but nevertheless not truly interoperable/compatible. As a > developer you basically have to write specific code for each of those > formats. > > I was wondering if it was ever considered to use, e.g., something like > JSON-LD [1] as the base for formats like these and limit the > standardization to a shared vocabulary (i.e., URLs for the required > properties) and a set of constraints and conventions captured in a > profile (see [2] for details). > > The advantage would be that much more code could be reused and data- > integration would become much simpler. It might look complicated at > first sight, but in reality most of what's needed is already there. For > example, the work to define URLs for the various properties for both > iCalendar [3] and vCard [4] has already been done at W3C (not as a REC > though). > > So, a simple vCard represented in JSON-LD would look as follows: > > { > "@context": { > "@vocab": "http://www.w3.org/2001/vcard-rdf/3.0#" > }, > "FN": "John Doe", > "ROLE": "Mr. Anonymous" > } > > You would have to define a number of constraints in the form of a > profile if you also want clients that process this as JSON instead of > JSON-LD to be able to interpret the data. The reason is that in JSON-LD > you can serialize the exactly the same data in a number of different > ways (e.g., you could use different field names that still expand to the > same URLs; the context defines those mappings). JSON-only clients are > less flexible and thus need to know the exact structure and field names. > > The question I thus would like to ask is: Is there a compelling reason > why this can't be based on a format as JSON-LD? Taking out the potential > complexity by requiring a profile defining a number of constraints on > how the data is serialized, I only see advantages of doing so. > > > Cheers, > Markus > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Mike http://twitter.com/mikekelly85 http://github.com/mikekelly http://linkedin.com/in/mikekelly123 From andy@hxr.us Wed Feb 13 17:02:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB50521E80C1 for ; Wed, 13 Feb 2013 17:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kdqLfBDv3Sj for ; Wed, 13 Feb 2013 17:02:50 -0800 (PST) Received: from mail-da0-f53.google.com (mail-da0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4245321E80C0 for ; Wed, 13 Feb 2013 17:02:42 -0800 (PST) Received: by mail-da0-f53.google.com with SMTP id w3so816795dad.40 for ; Wed, 13 Feb 2013 17:02:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:content-type:x-gm-message-state; bh=Caf/YnTvelSFWpJ1S/8aB/HJOyZukQArLT7Ohb2Mmng=; b=UW+ndqj5PgnxNl5QZy1TQyAzW/D2B6hRc6zEyg8OTWUbe3UCYvGj4tGFjM04bEqs15 NG4Gv4IEzlvlNy/V4PL4vUWwkpLYPeX6ZRHcCI9K3qBiaFvW+uz38wcymiPk8Gy2GyhZ Ygdw/wMBftrsEQAfiqKo0/NybzuMVBoqHBNbINebQu70/fClolXPqBLg55D/Aw2Zzx11 7yRiVsatpbS+gOsexsbiZyvDJIPUKPFeZruZP3ZOgAFMQYt0xU+BFk+Ge3oMc1vNt9mo brhds3qeu2dmJJzSj1HEtFvhFFbxxfjryBQDQ/vdbfIeP+Y1EkNlRrt4eP7fkZyTwCGI GhjA== MIME-Version: 1.0 X-Received: by 10.66.187.204 with SMTP id fu12mr2756264pac.43.1360803762220; Wed, 13 Feb 2013 17:02:42 -0800 (PST) Received: by 10.66.252.72 with HTTP; Wed, 13 Feb 2013 17:02:42 -0800 (PST) X-Originating-IP: [71.191.219.28] In-Reply-To: <511BFCF4.6080606@gmail.com> References: <20130213200324.11419.75605.idtracker@ietfa.amsl.com> <511BFCF4.6080606@gmail.com> Date: Wed, 13 Feb 2013 20:02:42 -0500 Message-ID: From: Andrew Newton To: Philipp Kewisch , "apps-discuss@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf0eaecdb2d7404d5a4d0be X-Gm-Message-State: ALoCoQlAIwx7ywa70LeKtgFKEUCKBzCgtKxAMNekW/nPFFVm/A26BukK4lwgLs5xc8xHYm12X652 Subject: Re: [apps-discuss] New Internet-Draft: jCard: The JSON format for vCard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2013 01:02:50 -0000 --047d7bf0eaecdb2d7404d5a4d0be Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 13, 2013 at 3:52 PM, Philipp Kewisch wrote: > Consequently, I have created a draft for vCard in JSON using a similar > notation [3]. I believe this is the second vCard in JSON draft (the first being the now expired draft-bhat-vcarddav-json-00). Is the plan to have one input document as a starting point or a bake-off between various proposals? -andy --047d7bf0eaecdb2d7404d5a4d0be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Wed, Feb 13, 2013 at 3:52 PM, Philipp Kewisch <kewisch@gmail.com>= ; wrote:
Consequently, I have created a draft for vCard in JSON usi= ng a similar notation [3].

I believe this is the secon= d vCard in JSON draft (the first being the now expired=A0draft-bhat-vcardda= v-json-00). Is the plan to have one input document as a starting point or a= bake-off between various proposals?

-andy
=
--047d7bf0eaecdb2d7404d5a4d0be-- From stpeter@stpeter.im Wed Feb 13 17:32:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FB621E80C0 for ; Wed, 13 Feb 2013 17:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 54j4WGxMFcTL for ; Wed, 13 Feb 2013 17:32:02 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B9B5721E80B5 for ; Wed, 13 Feb 2013 17:32:02 -0800 (PST) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 81BC440564; Wed, 13 Feb 2013 18:39:08 -0700 (MST) Message-ID: <511C3E91.5090707@stpeter.im> Date: Wed, 13 Feb 2013 18:32:01 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andrew Newton References: <20130213200324.11419.75605.idtracker@ietfa.amsl.com> <511BFCF4.6080606@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] New Internet-Draft: jCard: The JSON format for vCard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2013 01:32:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/13/13 6:02 PM, Andrew Newton wrote: > On Wed, Feb 13, 2013 at 3:52 PM, Philipp Kewisch > wrote: > >> Consequently, I have created a draft for vCard in JSON using a >> similar notation [3]. > > > I believe this is the second vCard in JSON draft (the first being > the now expired draft-bhat-vcarddav-json-00). Is the plan to have > one input document as a starting point or a bake-off between > various proposals? Hi Andy, The approach that Raghu and I took in draft-bhat-vcarddav-json-00 is quite different from that of draft-kewisch-vcard-in-json-00 (or draft-kewisch-et-al-icalendar-in-json-00). IMHO it will be a point of discussion during the BoF or its equivalent to determine the most desirable approach. The "bake-off", if any, will be between the higher-level approaches to representing iCalendar/vCard data in JSON. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHD6RAAoJEOoGpJErxa2p+lsP/20Bo4fQo4r7jfm17J8tb1ni X6jbdPyIc8hTmm7MuDuxk7jvsuGH/RDwNJVt9mmwBIUNqhsM4qj9DqHgkdEw/QsJ Gtje9lneenUIrMDdJaFnrsuKPVTEFFonQoM6gMpHPOmnwv0ZIyCi3aN1KjVG2N8J fO45sQEDSRcy15dKNCixxPGh3E1BUigxWmz4PKZIHQpT+BhF+HC0vMeUj5MAiT1K 8njoyqrcWS7q8fGSJB4WIys+mH/FEroal2l9FwSErQambWV7YfN25BabtvWPDkhQ cWvF8kZHTn92VPnAx0yRL2Wnl0sFEHh2svQfyHVjFjYWRqEyLyikef6YwgnBm3jx +guUgbLUeS+5N4F+YOtGNhaBVZ3UiNepCBHztMiirxEXZU+P658TA9H7Q1twwzkh r49C2cFAGxg6zmfR7YOA1MRc0SeW+GkIBbgJO3aJ9rWKPBoGqrJSP1B8SOpSPp3z IQ6/QTvV1cGslajH4+0s1gLFUxxgsHBLWgTBFtsoqaXzBdxgw/K2SI6yXR7wewmJ 0LjYiyEP3C+lyQN5P80NQCSxvm5WFkKqUEAk1OljjSAkoDu1leYAj/ZMttxaTYfr 39FCbb6n5a1JEZGYqQVieDUdFvhCkvUUWSFcsZ/dYoTmR+2Uh32vRa4b2px6vn7p +xncl/r48pLD6LJzVIJ+ =CDqP -----END PGP SIGNATURE----- From Claudio.Allocchio@garr.it Thu Feb 14 06:20:34 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BCB21F87FA; Thu, 14 Feb 2013 06:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ss9jhey3ECe; Thu, 14 Feb 2013 06:20:33 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD0F21F87DF; Thu, 14 Feb 2013 06:20:31 -0800 (PST) Received: internal info suppressed Date: Thu, 14 Feb 2013 15:20:29 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.dir.garr.it To: apps-discuss@ietf.org, draft-ietf-xrblock-rtcp-xr-summary-stat.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1785603695-1360751290=:2448" Content-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1360851630; bh=t3Wv2CHeVEGWgO8GvhKn9vsxWV2OdnCcR8ldSMJTYfM=; h=Date:From:To:cc:Subject; b=M0XJq5itoLdJFFSrKbY9Yaq3rBgGPTlvQXgHT84pn2bdEh60bf/G7jdw/yQKEOTxt 0BKh93/HKYvp057CLf8tp1FmEueXlGquvPeVwalzicr8I3eHYwuBHuMUX3WK9K5Vtr 8bS7jjYSxdWiGtunZerMEwN8bJNWXwKo3WSmvhns= Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-xrblock-rtcp-xr-summary-stat-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 14:20:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1785603695-1360751290=:2448 Content-Type: TEXT/PLAIN; FORMAT=flowed; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: Hello all, 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-xrblock-rtcp-xr-summary-stat-08 Title: RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting Reviewer: Claudio Allocchio Review Date: Feb 13th 2013 IETF Last Call Date: n/a IESG Telechat Date: Feb 21st 2013 Summary: There is one recurring Major Issue which I think requires a better wording to avoid the risk of different incompatible implementations. After this is fixed, the work is ready for publication. Major Issues: 3.1.2 Burst Loss Rate: 16 bits the whole paragraph is the "verbal description of a formula", which however is not present after the paragraph itself... worst... the formula which is presented Packets Loss in Bursts / Total Packets expected in Bursts is just a part of the missing complete formula. Please add the complete formula after the paragraph, or people will have to read it many times, and invent themselves the formula: math books can be written without a single "word" and everyone understand them the same way. The risk is here that many will write a different formula after reading the text. I also had a need for multiple reading of the "expressed as a fixed point number with the binary point at the left edge of the field"... maybe you can rewrite this better, too. Gap Loss Rate: 16 bits same problem as above: please add the explicit formula. 3.2.2 Burst Discard Rate: 16 bits same problem as in 3.1.2 above: please add the explicit formula. Gap Discard Rate: 16 bits same as above: please add the explicit formula. Minor Issues: 2.1 Terminology the sentence "A video frame is compressed using different algorithms" gives an absolute affirmation wich is not 100% true. Not all applications compress video frames, there are a few which send uncompressed video, thus all frames are "Key Frames" according to this definition and there are no "Derived Frames". In other cases frame compression is applied to color encoding, and not to image content itself, etc. I just suggest a more relaxed "In many cases, a video frame is compressed using different algotithms", and later, the addition of ..."Derived frames are predicatively coded and derived from a Key frame using a prediction algorithm. If there is no video image compression, all frames are Key Frames". 3.1.2 Reserved: 6 bits if the sender MUST put all zeroes, because the field it not yet in use, the receiver MUST ignore its content. Why there is a SHOULD? what the recipient could do with an all zeroes field of no use? Is there someting I do not get correctly? if so, then we should explain this ... I might be an implementer and do it wrong. 3.2.2 Reserved: 6 bits same as above for 3.1.2 4.1.2. Reserved: 7 bits same as above for 3.1.2 Nits: 4.1.2 full_lost_frames vs full_lost-frames later in the text... maybe other variants... choose 1, and use it all the time. Authors' Addresses in RFCs all "authors" are just "editors" when the work is coming out of a WG. :-) why adding "(editor)" aside just one of them? ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca --0-1785603695-1360751290=:2448-- From barryleiba@gmail.com Thu Feb 14 06:55:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F6621F8632; Thu, 14 Feb 2013 06:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.925 X-Spam-Level: X-Spam-Status: No, score=-102.925 tagged_above=-999 required=5 tests=[AWL=0.052, 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 wFcuvOYRvy6k; Thu, 14 Feb 2013 06:55:17 -0800 (PST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7532321F8629; Thu, 14 Feb 2013 06:55:16 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id ge1so1861162lbb.15 for ; Thu, 14 Feb 2013 06:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RPJfhay2UDT9x8otGII9KPSEDKRyJkPW/bv1tOoYMjs=; b=iE3/ILFTVsgXaYLxlw7BAn/OSncoJa5I73qoxJmbINm7fGHiAuYhMs/u4wxuGzrnwz hpn4BYg+k5MF5TPj53hifnId4IMnD2Ln6GT7Op4Y6a04pQNH7Oz/kgjrRYInTmo2nGX/ 60ML2i/UdJKHOzCGL2hz00nNBuARgspV1BE58DHcKWDc07t7gwOXZ+dq7EBdl5SdUW8g VdBgsF8F2l06CUKn8hp6S24CVTwDv6eUdjbLNyBnzeoqyKdjf+JaBxkvusmlomRdm3AL Lyklmuc4UvgO9eZwF1splv5rZrnwlJd3ERv3LR/Atw0TyE84Sm5DMKrEYg9mpk7ieDwm CllA== MIME-Version: 1.0 X-Received: by 10.152.125.237 with SMTP id mt13mr24160324lab.45.1360853715396; Thu, 14 Feb 2013 06:55:15 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.112.47.168 with HTTP; Thu, 14 Feb 2013 06:55:15 -0800 (PST) In-Reply-To: References: Date: Thu, 14 Feb 2013 09:55:15 -0500 X-Google-Sender-Auth: BKxRdoB6h47keSfAsHHHyFiwqhI Message-ID: From: Barry Leiba To: Claudio Allocchio Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-xrblock-rtcp-xr-summary-stat.all@tools.ietf.org, Apps Discuss , IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-xrblock-rtcp-xr-summary-stat-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 14:55:17 -0000 Thanks for the appsdir review, Claudio. > the whole paragraph is the "verbal description of a formula", which however > is not present after the paragraph itself... worst... the formula > which is presented ... > multiple reading of the "expressed as a fixed point number with the binary > point at the left edge of the field"... maybe you can rewrite this better, Yes, I picked both of these up in my DISCUSS position the other day as well, and Glen has agreed to change the text and the formula. > Authors' Addresses > > in RFCs all "authors" are just "editors" when the work is coming out of a > WG. :-) > > why adding "(editor)" aside just one of them? The usual reason for this is to note the one or ones, in particular, who "held the pen". Sometimes it's someone who took over after other authors were re-assigned or changed jobs, and that sort of thing. Barry From Claudio.Allocchio@garr.it Thu Feb 14 07:08:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AC321F88D6; Thu, 14 Feb 2013 07:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F34l1Tp6NWSX; Thu, 14 Feb 2013 07:08:10 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id CFC5F21F886F; Thu, 14 Feb 2013 07:08:09 -0800 (PST) Received: internal info suppressed Date: Thu, 14 Feb 2013 16:07:42 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.dir.garr.it To: Barry Leiba In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1360854463; bh=qlsKDXsH681rQNudY52JHJXMApHHdSW918tofxJaG7I=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Tx7xFs44tjtEV92FlZMKK4ip70BgFBApmXQz2Z39tRkovB+14VYe8Jl0NoAXwuIFs 9QHmi3oZcdYv6dOwyQxwm8ZmSwy545HWKzXZJ7r+NKK0KAJLVghhw0b8p5puqav6+C h+37GUh5hKSUufafE4HEpTH+mTCKVDP2yLoDmYnA= Cc: IESG , Apps Discuss , draft-ietf-xrblock-rtcp-xr-summary-stat.all@tools.ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-xrblock-rtcp-xr-summary-stat-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 15:08:10 -0000 > Yes, I picked both of these up in my DISCUSS position the other day as > well, and Glen has agreed to change the text and the formula. good to know that's it not just me: I was suspecting "I'm getting old, I need to read more than twice to understand it..." :-) >> Authors' Addresses > The usual reason for this is to note the one or ones, in particular, > who "held the pen". Sometimes it's someone who took over after other > authors were re-assigned or changed jobs, and that sort of thing. its really really an insignificant "curiosity" ;-) > > Barry > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From paul.hoffman@vpnc.org Thu Feb 14 09:28:54 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B1F21F868B for ; Thu, 14 Feb 2013 09:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kd6AsMoFMqSa for ; Thu, 14 Feb 2013 09:28:54 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9984721F8682 for ; Thu, 14 Feb 2013 09:28:53 -0800 (PST) Received: from [10.20.30.90] (50-1-98-243.dsl.dynamic.sonic.net [50.1.98.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1EHSpEU039300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 14 Feb 2013 10:28:51 -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: <2F426CCF-319E-4561-94ED-5F3320112F81@vpnc.org> Date: Thu, 14 Feb 2013 09:28:50 -0800 To: "apps-discuss@ietf.org Discuss" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [apps-discuss] Revised proposal for a DNS API X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 17:28:55 -0000 Greetings again. After my message a few weeks ago, a couple applications = developers were interested enough in the DNS API proposal I am working = on to subscribe to the mailing list and send in some really good ideas. = I have acted on those, and am soliciting for more. Please see http://www.vpnc.org/getdns-api/ for the current API proposal = and description of the design principles I used to put it together; = subscribe to the mailing list at = http://www.vpnc.org/mailman/listinfo/getdns-api I am still seeking input from application developers to say what they = would really want to see in an API. I based the design on input from an = informal gang of application developers, but I'm sure that other = application developers have thought "what I really want from the DNS is = X and I want to be able to ask in with an API that does Y"; early = discussion on the mailing list has shown that to be true. At some point = in the not-distant-future, I will call the design "finished" and = hopefully someone will want to implement it. Please don't discuss the design on the Application Area mailing list; it = is really not appropriate here given that this is not IETF work. I just = wanted to alert folks of this work. --Paul Hoffman= From craigmcc@gmail.com Wed Feb 13 09:35:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B345F21F882E for ; Wed, 13 Feb 2013 09:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.406 X-Spam-Level: X-Spam-Status: No, score=0.406 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_UNI=0.591] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1i0yNOn6BlI for ; Wed, 13 Feb 2013 09:35:55 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2D98121F886A for ; Wed, 13 Feb 2013 09:35:54 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id gw10so1440235lab.27 for ; Wed, 13 Feb 2013 09:35:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4x2lXG9d3JMHTp7d4+Coq8RCbwjkeU4d7IBz2ksvWNQ=; b=Ld6Svyt/GszgrRMKcz96rkPFV2kP5D88Kc9MR7dFXaD4Xai8QH8/QjSYJ5Ou1r5GTH O2dp8cTzqANGjHTTxeL10QA5vcgVQcSw6+9JZpNVdmROvuHQi1z9EMU6VeKR/TTvT31x YCyrfpYt/ar3aJSbeQB1wj+6tSfcDBFcAPZa0EmKQR2q4wF6cfC7p+T5r2pEnQGDS4hh hZl/L7FUG/EK4F5zRxKHW1ifZb7LtqpI4UfiSScbKYkPARNsKIKbQPLG+pfGeJ7IkSZ2 TAnQPGSADtBEzQOhPq+CTAHDFk8eWOpcM/5ywBJe21M9/3HUfhNRL9CVrg7YCcgfQrXX QoXg== MIME-Version: 1.0 X-Received: by 10.112.16.137 with SMTP id g9mr9060271lbd.119.1360776953685; Wed, 13 Feb 2013 09:35:53 -0800 (PST) Received: by 10.114.99.72 with HTTP; Wed, 13 Feb 2013 09:35:53 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Feb 2013 09:35:53 -0800 Message-ID: From: Craig McClanahan To: Mike Kelly Content-Type: multipart/alternative; boundary=f46d04016fa1f1688c04d59e9263 X-Mailman-Approved-At: Thu, 14 Feb 2013 09:53:52 -0800 Cc: REST-Discuss Discussion Group , IETF Apps Discuss , "hypermedia@librelist.com" , "api-craft@googlegroups.com" , "hal-discuss@googlegroups.com" , "hypermedia-web@googlegroups.com" Subject: Re: [apps-discuss] [rest-discuss] Re: New Internet-Draft: JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: craigmcc@gmail.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 17:35:56 -0000 --f46d04016fa1f1688c04d59e9263 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I've written several APIs lately that contain a similar concept to the "links" abstraction with a useful extension -- we also include an "allowed" field that contains an array of the HTTP verbs that this user is allowed to perform against the URL specified by "href". Essentially, we're saving the client the need to do an OPTIONS call to determine what verbs are supported for that user. A use case for this is when displaying content that may or may not be editable (or can be deleted) by the requesting user. If so, the "allowed" field would say '[ "GET", "PUT", "DELETE" ]'. If not, it would just say '[ "GET" ]'. A client UI can use this information to decide whether or not to display enabled "Edit" or "Delete" buttons. Craig McClanahan On Tue, Feb 12, 2013 at 1:52 PM, Mike Kelly wrote: > ** > > > Here's a slightly more useful link than the previous one! > > http://tools.ietf.org/html/draft-kelly-json-hal-05 > > On Tue, Feb 12, 2013 at 7:53 AM, Mike Kelly mikekelly321@gmail.com> wrote= : > > Hello all, > > > > fyi, I have updated the following internet draft: > > > > http://www.ietf.org/id/draft-kelly-json-hal-04.txt > > > > All thoughts, comments, suggestions, etc welcome > > > > Cheers, > > Mike > > -- > Mike > > http://twitter.com/mikekelly85 > http://github.com/mikekelly > http://linkedin.com/in/mikekelly123 > __._,_.___ > Reply via web post Reply > to sender > Reply > to group > Start > a New Topic Messages > in this topic(2) > Recent Activity: > > - New Members > 5 > > Visit Your Group > [image: Yahoo! Groups] > Switch to: Text-Only, > Daily Digest=95 > Unsubscribe =95 Terms > of Use =95 Send us Feedback > > . > > __,_._,___ > --f46d04016fa1f1688c04d59e9263 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I've written several APIs lately that contain a similar concept to the = "links" abstraction with a useful extension -- we also include an= "allowed" field that contains an array of the HTTP verbs that th= is user is allowed to perform against the URL specified by "href"= . =A0Essentially, we're saving the client the need to do an OPTIONS cal= l to determine what verbs are supported for that user.

A use case for this is when displaying content that may or m= ay not be editable (or can be deleted) by the requesting user. =A0If so, th= e "allowed" field would say '[ "GET", "PUT&quo= t;, "DELETE" ]'. =A0If not, it would just say '[ "GE= T" ]'. =A0A client UI can use this information to decide whether o= r not to display enabled "Edit" or "Delete" buttons.

Craig McClanahan

On T= ue, Feb 12, 2013 at 1:52 PM, Mike Kelly <mikekelly321@gmail.com&g= t; wrote:
=A0
=20 =20

Here's a slightly more useful link than the previous one!

http://tools.ietf.org/html/draft-kelly-json-hal-05

On Tue, Feb 12, 2013 at 7:53 AM, Mike Kelly mikekelly321@gmail.com> wrote:
> Hello all,
>
> fyi, I have updated the following internet draft:
>
> http://www.ietf.org/id/draft-kelly-json-hal-04.txt
>
> All thoughts, comments, suggestions, etc welcome
>
> Cheers,
> Mike

--
Mike

http://twitter= .com/mikekelly85
http://github.com= /mikekelly
http://li= nkedin.com/in/mikekelly123

=20 =20
__._,_.___
=20 =20 =20
Reply via web post Reply to sender =20 Reply to group =20 Start a New Topic Messages in this topic (2)
=20
= Recent Activity: =20
=20
3D"Yahoo!=
Switch to: Text-Only, <= a href=3D"mailto:rest-discuss-digest@yahoogroups.com?subject=3DEmail+Delive= ry:+Digest" style=3D"text-decoration:none" target=3D"_blank">Daily Digest =95 Unsubscrib= e =95 Terms of Use =95 Send us Feedb= ack
=20 =20 =20
=20
.

__,_._,___
=20

--f46d04016fa1f1688c04d59e9263-- From craigmcc@gmail.com Wed Feb 13 13:42:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA10211E80A4 for ; Wed, 13 Feb 2013 13:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5mYDYd0v+Nu for ; Wed, 13 Feb 2013 13:42:22 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 12FB411E80A5 for ; Wed, 13 Feb 2013 13:42:21 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id s4so1311023lbc.35 for ; Wed, 13 Feb 2013 13:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IwoQnSUbFP/QJYtZWUTeszorZoXY0VnbDgIXsVL8VEw=; b=DuSjGvcf4DrECDd8a3MFVznHUUj/IiuslGXNeg/NfHGsQI0OKDQWvkA92w8OraGaH0 G7M96RqJFFYkdg1mEWLq3wuIi0hywm81ycVyvzjt53RH3+ryG9cydTLQbFAO0oBVf6OS +R0JHM5yKgE2dDu7F8TKbiWYk5xTR8UuXuTVkcaE2vlKDQYPCdVF4Kkzu6bdFdACvsPz 0HtEys+z3VtEVkwJakRDmt9Rw2QcaqpE5XYX1Ch39/4t6jrNCOKHSCXwppio+adH1LMJ FpIPGL6bXwxB9QrEi4N/8erclZcMA5A7pmZqkxuktdYgQSFPWEQNsJugNlv5F5UFWwFa xyNw== MIME-Version: 1.0 X-Received: by 10.112.27.33 with SMTP id q1mr9608532lbg.78.1360791740859; Wed, 13 Feb 2013 13:42:20 -0800 (PST) Received: by 10.114.99.72 with HTTP; Wed, 13 Feb 2013 13:42:20 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Feb 2013 13:42:20 -0800 Message-ID: From: Craig McClanahan To: Mike Kelly Content-Type: multipart/alternative; boundary=bcaec554da7253c4d504d5a204b0 X-Mailman-Approved-At: Thu, 14 Feb 2013 09:54:13 -0800 Cc: REST-Discuss Discussion Group , IETF Apps Discuss , "api-craft@googlegroups.com" , "hypermedia@librelist.com" , hal-discuss@googlegroups.com, hypermedia-web@googlegroups.com Subject: Re: [apps-discuss] [rest-discuss] Re: New Internet-Draft: JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: craigmcc@gmail.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 21:42:24 -0000 --bcaec554da7253c4d504d5a204b0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2013 at 9:59 AM, Mike Kelly wrote: > Hi Craig, > > Thanks for your response. > > The problem with that approach is you have to force your access model > around the HTTP verbs. So if you have different transitions possible for = a > PUT or POST request on a given resource, and each have different access > rules, then you're out of options (no pun intended). > Well, my task was to define public HTTP APIs for our resources, so binding to HTTP semantics didn't really bother me :-). > Another approach is to create permission resources that represent the > roles the requesting user has for particular activities. The roles can be > more descriptive, flexible, and intuitive to clients that way. > > Are there some compelling reasons to work around HTTP that i'm missing. > > Along the same lines, I'm a bit concerned about absorbing HTTP stuff into > the media type. Which I think this technique is guilty of. A while back I > considered adding etag info for embedded resources but canned it because = of > the same concern.. Out of interest how would you feel about that etag > approach? > I think there are (at least) two things to consider: * Syntax/semantics for defining permissions * In band (that is, part of the resource representation) or out of band (in an HTTP case, typically transmitted via headers). For the 'permissions' concern, a trivial extension to what I suggested would be to allow arbitrary values for the "allowed" field, which could be role names with semantics that are agreed upon between client and server. For a client that *is* using HTTP, that would then require some understanding of how to map roles to HTTP verbs. For our use case, we use the verbs consistently and conventionally across all of our endpoints (POST to a collection URI =3D=3D create, PUT to an individual endpoint =3D=3D upd= ate, and so on), so we're relying on the client to understand that convention -- but it seems easier to understand, at least for simple CRUD type operations. On the topic of in band versus out of band, the latter would probably be more "pure" -- but in band is much easier for client developers to deal with. They have to access the JSON or XML or whatever content of the response body anyway. Requiring them to deal with HTTP headers or whatever as well is extra work. I know of at least one effort[1] to formalize out of band link relationships with better semantic information ("rel") -- but this still doesn't address the issue of "what can this particular client do with this URI"? Craig [1] http://tools.ietf.org/html/draft-snell-link-method-01 > Cheers, > M > > On 13 Feb 2013 17:35, "Craig McClanahan" wrote: > > > > I've written several APIs lately that contain a similar concept to the > "links" abstraction with a useful extension -- we also include an "allowe= d" > field that contains an array of the HTTP verbs that this user is allowed = to > perform against the URL specified by "href". Essentially, we're saving t= he > client the need to do an OPTIONS call to determine what verbs are support= ed > for that user. > > > > A use case for this is when displaying content that may or may not be > editable (or can be deleted) by the requesting user. If so, the "allowed= " > field would say '[ "GET", "PUT", "DELETE" ]'. If not, it would just say = '[ > "GET" ]'. A client UI can use this information to decide whether or not = to > display enabled "Edit" or "Delete" buttons. > > > > Craig McClanahan > > > > On Tue, Feb 12, 2013 at 1:52 PM, Mike Kelly > wrote: > >> > >> > >> > >> Here's a slightly more useful link than the previous one! > >> > >> http://tools.ietf.org/html/draft-kelly-json-hal-05 > >> > >> On Tue, Feb 12, 2013 at 7:53 AM, Mike Kelly mikekelly321@gmail.com> > wrote: > >> > Hello all, > >> > > >> > fyi, I have updated the following internet draft: > >> > > >> > http://www.ietf.org/id/draft-kelly-json-hal-04.txt > >> > > >> > All thoughts, comments, suggestions, etc welcome > >> > > >> > Cheers, > >> > Mike > >> > >> -- > >> Mike > >> > >> http://twitter.com/mikekelly85 > >> http://github.com/mikekelly > >> http://linkedin.com/in/mikekelly123 > >> > >> __._,_.___ > >> Reply via web post > >> Reply to sender > >> Reply to group > >> Start a New Topic > >> Messages in this topic (2) > >> Recent Activity: > >> New Members 5 > >> Visit Your Group > >> Switch to: Text-Only, Daily Digest =95 Unsubscribe =95 Terms of Use = =95 Send > us Feedback > >> . > >> > >> __,_._,___ > > > > > > --bcaec554da7253c4d504d5a204b0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 13, 2013 at 9:59 AM, Mike Ke= lly <mikekelly321@gmail.com> wrote:

Hi Craig,

Thanks for your response.

The problem with that approach is you have to force your acc= ess model around the HTTP verbs. So if you have different transitions possi= ble for a PUT or POST request on a given resource, and each have different = access rules, then you're out of options (no pun intended).

Well, my task was to define public HTTP APIs for our reso= urces, so binding to HTTP semantics didn't really bother me :-).
<= div>=A0

Another approach is to create permission resources that repr= esent the roles the requesting user has for particular activities. The role= s can be more descriptive, flexible, and intuitive to clients that way.

Are there some compelling reasons to work around HTTP that i= 'm missing.

Along the same lines, I'm a bit concerned about absorbin= g HTTP stuff into the media type. Which I think this technique is guilty of= . A while back I considered adding etag info for embedded resources but can= ned it because of the same concern.. Out of interest how would you feel abo= ut that etag approach?

I think there are (at least) two things to consider:<= /div>

* Syntax/semantics for defining permissions
<= div>
* In band (that is, part of the resource representation)=
=A0 or out of band (in an HTTP case, typically transmitted
= =A0 via headers).

For the 'permissions' co= ncern, a trivial extension to what I suggested would be to allow arbitrary = values for the "allowed" field, which could be role names with se= mantics that are agreed upon between client and server. =A0For a client tha= t *is* using HTTP, that would then require some understanding of how to map= roles to HTTP verbs. =A0For our use case, we use the verbs consistently an= d conventionally across all of our endpoints (POST to a collection URI =3D= =3D create, PUT to an individual endpoint =3D=3D update, and so on), so we&= #39;re relying on the client to understand that convention -- but it seems = easier to understand, at least for simple CRUD type operations.

On the topic of in band versus out of band, the latter = would probably be more "pure" -- but in band is much easier for c= lient developers to deal with. =A0They have to access the JSON or XML or wh= atever content of the response body anyway. =A0Requiring them to deal with = HTTP headers or whatever as well is extra work.

I know of at least one effort[1] to formalize out of ba= nd link relationships with better semantic information ("rel") --= but this still doesn't address the issue of "what can this partic= ular client do with this URI"?

Craig

=A0

Cheers,
M

On 13 Feb 2013 17:35, "Craig= McClanahan" <craigmcc@gmail.com> wrote:
>
> I've written several APIs lately that contain a similar concept to= the "links" abstraction with a useful extension -- we also inclu= de an "allowed" field that contains an array of the HTTP verbs th= at this user is allowed to perform against the URL specified by "href&= quot;. =A0Essentially, we're saving the client the need to do an OPTION= S call to determine what verbs are supported for that user.
>
> A use case for this is when displaying content that may or may not be = editable (or can be deleted) by the requesting user. =A0If so, the "al= lowed" field would say '[ "GET", "PUT", "= DELETE" ]'. =A0If not, it would just say '[ "GET" ]&= #39;. =A0A client UI can use this information to decide whether or not to d= isplay enabled "Edit" or "Delete" buttons.
>
> Craig McClanahan
>
> On Tue, Feb 12, 2013 at 1:52 PM, Mike Kelly <mikekelly321@gmail.com> wrote:=
>>
>> =A0
>>
>> Here's a slightly more useful link than the previous one!
>>
>> http://tools.ietf.org/html/draft-kelly-json-hal-05
>>
>> On Tue, Feb 12, 2013 at 7:53 AM, Mike Kelly mikekelly321@gmail.com> wrote:=
>> > Hello all,
>> >
>> > fyi, I have updated the following internet draft:
>> >
>> > http://www.ietf.org/id/draft-kelly-json-hal-04.txt<= br> >> >
>> > All thoughts, comments, suggestions, etc welcome
>> >
>> > Cheers,
>> > Mike
>>
>> --
>> Mike
>>
>> http:= //twitter.com/mikekelly85
>> http://g= ithub.com/mikekelly
>> = http://linkedin.com/in/mikekelly123
>>
>> __._,_.___
>> Reply via web post
>> Reply to sender
>> Reply to group
>> Start a New Topic
>> Messages in this topic (2)
>> Recent Activity:
>> New Members 5
>> Visit Your Group
>> Switch to: Text-Only, Daily Digest =95 Unsubscribe =95 Terms of Us= e =95 Send us Feedback
>> .
>>
>> __,_._,___
>
>


--bcaec554da7253c4d504d5a204b0-- From vincent.roca@inria.fr Wed Feb 13 09:08:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8AB21F89EF; Wed, 13 Feb 2013 09:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.028 X-Spam-Level: X-Spam-Status: No, score=-110.028 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXr6bJ43aq3i; Wed, 13 Feb 2013 09:08:26 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8F84F21F88A3; Wed, 13 Feb 2013 09:08:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,658,1355094000"; d="scan'208";a="2110088" Received: from unknown (HELO [10.2.29.151]) ([78.250.189.3]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 13 Feb 2013 17:56:45 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Vincent Roca In-Reply-To: Date: Wed, 13 Feb 2013 18:08:23 +0100 Content-Transfer-Encoding: 7bit Message-Id: <3684C634-B7B4-4DE2-82B4-CC97F00F6BB8@inria.fr> References: To: Joseph Yee X-Mailer: Apple Mail (2.1085) X-Mailman-Approved-At: Thu, 14 Feb 2013 09:54:31 -0800 Cc: Vincent Roca , The IESG , apps-discuss@ietf.org, draft-ietf-rmt-fcast.all@tools.ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-rmt-fcast-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 17:08:26 -0000 Hello, > Document: draft-ietf-rmt-fcast-07 > Title: FCAST: Scalable Object Delivery for the ALC and NORM Protocols > Reviewer: Joseph Yee > Review Date: 2013-01-20 > IETF Last Call Date: 2013-01-22 > IESG Telechat Date: 2013-01-24 > > Summary: This draft is almost ready for publication as Proposed Standard > > > Major Issues: > None > > Minor Issues: > > It takes me awhile to understand the document, partly I think the > information flow is broken (another part is that I'm not familiar with > the subject). If the principle section (Section 3) was followed by > Implementation section (Section 5) instead, I think it will be better > to reader. IMHO, the order of FCAST Principles -> Requirement for > Compliant Implementation -> Security Consideration would be a better > flow. This order has been changed as proposed. > Nits: > None, maybe a little xml comment to ask RFC Editors to help > reordering references based on RFC numbers :) Yes, using does the job. Cheers, Vincent From stpeter@stpeter.im Thu Feb 14 19:32:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D7821F8550 for ; Thu, 14 Feb 2013 19:32:39 -0800 (PST) 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 DUG1R65SfCgl for ; Thu, 14 Feb 2013 19:32:38 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2E95121F854E for ; Thu, 14 Feb 2013 19:32:38 -0800 (PST) Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 86ED9406D9 for ; Thu, 14 Feb 2013 20:39:47 -0700 (MST) Message-ID: <511DAC57.3010809@stpeter.im> Date: Thu, 14 Feb 2013 20:32:39 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [apps-discuss] APPSDIR review of draft-leiba-urnbis-ietf-namespace-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 03:32:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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-leiba-urnbis-ietf-namespace-02 Title: Registration of Second-Level URN Namespaces Under "ietf" Reviewer: Peter Saint-Andre Review Date: 2013-02-14 IETF Last Call Date: Not known IESG Telechat Date: 2013-02-21 Summary: This draft is ready for publication as Informational. One issue that should be investigated before publication is listed below. Major Issues: 0 Minor Issues: 1 Nits: 0 Does the specification truly and substantively update RFC 2648 and RFC 3553? It appears to clarify the names and organization of the relevant IANA registrations, but not to modify the substance of those earlier RFCs. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHaxWAAoJEOoGpJErxa2p82sQAJWvkSjqt9TGPcmAMtOBTSB9 gL7fb8hh5mGHpK7WVLtqk90Eer1blIqP+eCwlhcmoFhPnqAgPpU0jG27fMPPONOE UiVWkawGWmzcHxq2apFj3BlK0kycnX9eFl+wLVuqehFoAAyhm4+8kSP4q5hqBmaq 9awyxGA2u7KqoYyV/wgOmuFZHYcQ6rBUiBIG9qCPf/l047me9LfiMfmHySj5gdvp azf9Y4HwCeHE3ca/bMUFwIEAqtetMvHJ87OqgOupMYmNjdbM1QkjzHH0gnn9b0/S urcduUOGYjXp1SX1d5FrNuyT4iw4OJ2/mE8mfBki6UimFsH/FzFC+mgojrEgnk/9 OyMRWNRvAW34WcEY3C4jfQWZrKr5MnvzakkyGSZSuMjc1ZgnHzAWbU+Hi67A29X1 ua6UGtPw2Gb23TIJk9OVwMasAgCahC9LspT47HlOg2QiTaC4pfhfjSdbTbqZbeI8 7BtkVpEST/qEhRokASUQAS1I8kDARbGAh0H657o4L/2xJZwPTP5mptL5Da9aa2gq gIOEsDmpPhHlx6GuOUTBrKWtKw9bdzdmuHwiLEcWKEzdJV1q4sGlIbBwcCwivs3E S+cFsYrHp/iXYNWO/dnH16apBp9g4o3T8vvlyy5pf88VUgvj/V8Ff6iQ9bxfbGEn zebqYQgg0IHBh39oVAJ4 =V0uO -----END PGP SIGNATURE----- From barryleiba.mailing.lists@gmail.com Fri Feb 15 08:56:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0869B21F8777 for ; Fri, 15 Feb 2013 08:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=0.045, 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 Kw4o8FIUjMKq for ; Fri, 15 Feb 2013 08:56:49 -0800 (PST) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id 78D7021F8770 for ; Fri, 15 Feb 2013 08:56:49 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id s24so2249331vbi.8 for ; Fri, 15 Feb 2013 08:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2OpD0CJ4afFQ2Yu1UWg5hNRXdw8Ys0VeIMlLbNDm7N8=; b=RUfVvaU/PLFS0TwQqqvRlr7OVBvA6Km/41ODnZY4Zri2NB0ABXjseNDjpM9Em7smiY D1MrTZWzRFclwLMkvPpWtcOsfNa3vSdJ+cASgdN2Idfceq4dmHcG1uL42QM0LSfYQ/a6 9JocIBcuw2UZ6n0hC2goQTDNlPgj8viG36sg0SUP2divxf+91ausTq6jpAe0ZZP4c9lb BPfAHoa2v1YdH2cixUEB1iouusbsbK+q4SuaSbNETN/gsxVmzPTHskF0s/8dyql3G2Fu ZKoafrbqkz3gBRZSJ4uf8zC8xocvQfhFzsI/jYmTsNbrK6gEGuNbAXCUWn3y/omEcO0+ m6aw== MIME-Version: 1.0 X-Received: by 10.220.151.5 with SMTP id a5mr4183849vcw.22.1360947408716; Fri, 15 Feb 2013 08:56:48 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Fri, 15 Feb 2013 08:56:48 -0800 (PST) In-Reply-To: <511DAC57.3010809@stpeter.im> References: <511DAC57.3010809@stpeter.im> Date: Fri, 15 Feb 2013 11:56:48 -0500 X-Google-Sender-Auth: MAwC9s6bEn-xzKbZrpKUh_Rq6Ww Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-leiba-urnbis-ietf-namespace-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 16:56:50 -0000 > Does the specification truly and substantively update RFC 2648 and RFC > 3553? It appears to clarify the names and organization of the relevant > IANA registrations, but not to modify the substance of those earlier RFCs. Robert Sparks has filed a DISCUSS ballot on the same issue. I believe it does, though the IESG is not clear about what "updates" means (something we're working on). I'll reply in more detail on Robert's DISCUSS, and include apps-discuss in my reply. Barry From barryleiba@gmail.com Fri Feb 15 09:08:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4192021F8862; Fri, 15 Feb 2013 09:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.032 X-Spam-Level: X-Spam-Status: No, score=-102.032 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C0wVnFp2zMY; Fri, 15 Feb 2013 09:08:07 -0800 (PST) Received: from mail-la0-x235.google.com (la-in-x0235.1e100.net [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3715521F8853; Fri, 15 Feb 2013 09:08:06 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id fr10so3621820lab.40 for ; Fri, 15 Feb 2013 09:08:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xR+oE9djTIaAv5CkUkn9rC6L0Zwruww5gDhGgdfnIyQ=; b=HCH21MTSq6VlrKnQ5XrNJBZqhIWgpeemXx/C200KEuWtUBk5QqWRrEGmqMExXb5pen Ty522VyuwtoA+4G7OSfTR0S8/BlBxkdOgPlFQ+FnWqURaLQnRUuNQ/WbJmDj/Nt4wTGB vcrgTYkFOYc0+5eRTCio9wkBc3Q1DgNmzZESghrIPqkWJz0rJQmg8T2ge3gVWY20vmG+ FH5qD+H4x9mCG3q6R/yun2wdBSXgu1N42d5Wuno2GiLu+4C9VL/p6kzNapB0zTL1YQti 6NulhJ4nnVAR24gdwEauxM1l4ej8Vw8DjCpeFscK9M9gwG7dPOFJydAu5Xu4KCyIc1Ql w0Aw== MIME-Version: 1.0 X-Received: by 10.112.42.197 with SMTP id q5mr2433002lbl.9.1360948085959; Fri, 15 Feb 2013 09:08:05 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.112.47.168 with HTTP; Fri, 15 Feb 2013 09:08:05 -0800 (PST) In-Reply-To: <20130214204502.15948.3350.idtracker@ietfa.amsl.com> References: <20130214204502.15948.3350.idtracker@ietfa.amsl.com> Date: Fri, 15 Feb 2013 12:08:05 -0500 X-Google-Sender-Auth: SZEcLVrVS7wxHoIrNX0jVQITF18 Message-ID: From: Barry Leiba To: Robert Sparks , Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: The IESG , Apps Discuss , draft-leiba-urnbis-ietf-namespace@tools.ietf.org Subject: Re: [apps-discuss] Robert Sparks' Discuss on draft-leiba-urnbis-ietf-namespace-02: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Feb 2013 17:08:08 -0000 [Adding Peter Saint-Andre and apps-discuss, to include Peter's AppsDir review, which raised the same issue.] > As far as I can tell, this document doesn't Update the two RFCs it points > to. These look like the "See Also" use of Updates we've agreed not to > use. Am I missing something it changes in the earlier RFCs? If so, could > that be written more clearly? I believe that the IESG hasn't decided what "updates" means (and I know I owe the IESG a draft proposal for this). I also believe this document qualifies, by criteria we have chatted about, though it's all still up in the air. The reason here matches what we've done in Apps in the past: when a document creates a new registry that people reading the old document will need to know about, we use "updates" to create that forward reference. Otherwise, people reading the old document will not be aware that a registry exists, which they have to pay attention to. In this case, RFC 2648 says this: If the IESG (or it successor) adds a new document series, this ABNF specification will need to be updated. We aren't adding "a new document series," but we did, in RFC 3553, add a new value ("params") for the "NSS" production in that ABNF, and 3553 should have updated the ABNF in 2648... but it didn't. In the case of RFC 3553, it defined "params" but didn't register it anywhere. This document creates the registry and registers all the items from 2648 and 3553. I'm quite certain that this is valid use of "updates" for 2648, and strongly suggest keeping that. I will happily remove the "updates" for 3553, because readers of that document probably don't need to know that "params" is now registered anywhere. Barry From dave@cridland.net Sat Feb 16 00:35:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C693121F84CA for ; Sat, 16 Feb 2013 00:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.053 X-Spam-Level: X-Spam-Status: No, score=-3.053 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqBYLc73M+3P for ; Sat, 16 Feb 2013 00:35:41 -0800 (PST) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 91B3D21F8475 for ; Sat, 16 Feb 2013 00:35:41 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id l10so4533952oag.30 for ; Sat, 16 Feb 2013 00:35:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zcOKCbX+vatymuE72SkMuwxlozIGZ8vOpHj1aHN74R8=; b=UZtCoX7FtfB78fKYEhZbZkoouW/ldxRDfgXJ2xZYSfyuMQWOFKfDF94V0LDkBA2yzh Q5529Ph7dgegrv5XJh0d7crpAFRdfvcnfNZa6ernoyq5UESpeUUTm2kE5GRhOllqoy9O 6A3/reSEp7KHMnXufSIfepiaOkZ4i8Xvu7W+4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=zcOKCbX+vatymuE72SkMuwxlozIGZ8vOpHj1aHN74R8=; b=JPGISU5dmZJFUQrKPLsMsATIugzNDxfL2LoAmW9NEJ5nPiiWDy3o6nk9cLgvdZKIVJ E01LVcH/fnwSAcsBkHQWtbPVbvBbL6MpOG6wJeO8ar4KYhioB8fzWx8e3qYyJIYOvPPL ExKAGAt3qJxHg0LcuGEen2oRK37lx/fe2etE6yuTmPdBdC9/1Ui4pkd+lg56YoEfDrBd XMAB15Onc2sjY8Fyn9Eai9j6MGDoPbeLmyK3qDMndhMq87I2dNhjJ3LjnWc1th7NKxkZ zu+/mXrjQpa0W6f/DILHTSBaneWAtj9JXl5BSVS6dRpg0G9HihjHNDHv+4CFNyhxxp7W EVcg== MIME-Version: 1.0 X-Received: by 10.60.172.237 with SMTP id bf13mr3496524oec.83.1361003741043; Sat, 16 Feb 2013 00:35:41 -0800 (PST) Received: by 10.60.59.74 with HTTP; Sat, 16 Feb 2013 00:35:40 -0800 (PST) Received: by 10.60.59.74 with HTTP; Sat, 16 Feb 2013 00:35:40 -0800 (PST) In-Reply-To: References: Date: Sat, 16 Feb 2013 08:35:40 +0000 Message-ID: From: Dave Cridland To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=bcaec54b4aa285dd5e04d5d36063 X-Gm-Message-State: ALoCoQn5pyiIE7eLTNRReMlrtT9kGZhdL0FRxT5prEK31GVeAfI/6BZ4V9sZ0LJJ7uY7HCUYsp8A Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] .well-known as a one stop shopping location for Web Services 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: Sat, 16 Feb 2013 08:35:42 -0000 --bcaec54b4aa285dd5e04d5d36063 Content-Type: text/plain; charset=ISO-8859-1 Can I just check I understand your idea correctly? You're suggesting a device (or other consumer) is fed a URI of the form wk:foo:example.com, and resolves this by: 1) Performing a SRV lookup on _foo._wk.example.com to find a hostname (eg, server.example.com). 2) Forming an HTTP URI from this to the .well-known space formed from the service name on that host (eg, http://server.example.com/.well-known/foo) 3) Performing requests on that, expecting to obtain a Content-Type header reading "application/json; wk=foo" and processing accordingly. If all this is correct, I think the basic mechanism is solid and should work, and would give strong benefits if widely deployed. At the risk of sounding frivolous, though, I suspect "wk" is not going to gain as much traction as, say "api". I appreciate that the moment I send this mail, there'll be a concurrent spluttering of morning coffee across the world, but please bear in mind that a protocol mechanism designed for a wide appeal needs some effort putting into its name. It doesn't matter if ".well-known" exists behind the scenes, but I don't think it'll resonate with the bulk of web developers we'd be targetting. Dave. --bcaec54b4aa285dd5e04d5d36063 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Can I just check I understand your idea correctly?

You're suggesting a device (or other consumer) is fed a = URI of the form wk:foo:example.com, and = resolves this by:

1) Performing a SRV lookup on _foo._wk.example.com to find a hostname (eg, server.example.com).

2) Forming an HTTP URI from this to the .well-known space fo= rmed from the service name on that host (eg, http://server.example.com/.well-known/foo)

3) Performing requests on that, expecting to obtain a Conten= t-Type header reading "application/json; wk=3Dfoo" and processing= accordingly.

If all this is correct, I think the basic mechanism is solid= and should work, and would give strong benefits if widely deployed.

At the risk of sounding frivolous, though, I suspect "w= k" is not going to gain as much traction as, say "api". I ap= preciate that the moment I send this mail, there'll be a concurrent spl= uttering of morning coffee across the world, but please bear in mind that a= protocol mechanism designed for a wide appeal needs some effort putting in= to its name. It doesn't matter if ".well-known" exists behind= the scenes, but I don't think it'll resonate with the bulk of web = developers we'd be targetting.

Dave.

--bcaec54b4aa285dd5e04d5d36063-- From bill.wu@huawei.com Fri Feb 15 22:30:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C13121F8678; Fri, 15 Feb 2013 22:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.759 X-Spam-Level: X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[AWL=0.840, 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 GoP50kLTWN91; Fri, 15 Feb 2013 22:30:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 42A3921F865B; Fri, 15 Feb 2013 22:30:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APT85345; Sat, 16 Feb 2013 06:30:01 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 16 Feb 2013 06:29:38 +0000 Received: from SZXEML456-HUB.china.huawei.com (10.82.67.199) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 16 Feb 2013 06:30:00 +0000 Received: from w53375 (10.138.41.149) by szxeml456-hub.china.huawei.com (10.82.67.199) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 16 Feb 2013 14:29:57 +0800 Message-ID: From: Qin Wu To: Claudio Allocchio , , References: Date: Sat, 16 Feb 2013 14:29:57 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected X-Mailman-Approved-At: Sat, 16 Feb 2013 08:18:13 -0800 Cc: iesg@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-xrblock-rtcp-xr-summary-stat-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 06:30:05 -0000 SGksQ2xhdWRpbzoNClRoYW5rIGZvciB5b3VyIHZhbHVhYmxlIHJldmlldy4gV2Ugd2lsbCBmaXgg dGhlIGlzc3VlcyB5b3UgcmFpc2VkIGJlbG93IGluIHRoZSB1cGRhdGUuDQoNClJlZ2FyZHMhDQot UWluDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNsYXVkaW8gQWxsb2Nj aGlvIiA8Q2xhdWRpby5BbGxvY2NoaW9AZ2Fyci5pdD4NClRvOiA8YXBwcy1kaXNjdXNzQGlldGYu b3JnPjsgPGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXN1bW1hcnktc3RhdC5hbGxAdG9vbHMu aWV0Zi5vcmc+DQpDYzogPGllc2dAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkg MTQsIDIwMTMgMTA6MjAgUE0NClN1YmplY3Q6IEFQUFNESVIgcmV2aWV3IG9mIGRyYWZ0LWlldGYt eHJibG9jay1ydGNwLXhyLXN1bW1hcnktc3RhdC0wOA0KDQoNCj4gDQo+IEhlbGxvIGFsbCwNCj4g DQo+IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBBcHBsaWNhdGlvbnMgQXJlYSBEaXJlY3Rv cmF0ZSByZXZpZXdlciBmb3IgDQo+IHRoaXMgZHJhZnQ7IGZvciBiYWNrZ3JvdW5kIG9uIGFwcHNk aXIsIHBsZWFzZSBzZWUgDQo+IOKAiw0KPiAgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJl YS9hcHAvdHJhYy93aWtpL0FwcGxpY2F0aW9uc0FyZWFEaXJlY3RvcmF0ZQ0KPiANCj4gUGxlYXNl IHJlc29sdmUgdGhlc2UgY29tbWVudHMgYWxvbmcgd2l0aCBhbnkgb3RoZXIgTGFzdCBDYWxsIGNv bW1lbnRzIHlvdSANCj4gbWF5IHJlY2VpdmUuIFBsZWFzZSB3YWl0IGZvciBkaXJlY3Rpb24gZnJv bSB5b3VyIGRvY3VtZW50IHNoZXBoZXJkIG9yIEFEIA0KPiBiZWZvcmUgcG9zdGluZyBhIG5ldyB2 ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCj4gDQo+IERvY3VtZW50OiBkcmFmdC1pZXRmLXhyYmxvY2st cnRjcC14ci1zdW1tYXJ5LXN0YXQtMDgNCj4gVGl0bGU6ICBSVFAgQ29udHJvbCBQcm90b2NvbCAo UlRDUCkgRXh0ZW5kZWQgUmVwb3J0IChYUikgQmxvY2tzIGZvcg0KPiAgICAgICAgIFN1bW1hcnkg U3RhdGlzdGljcyBNZXRyaWNzIFJlcG9ydGluZw0KPiBSZXZpZXdlcjogQ2xhdWRpbyBBbGxvY2No aW8NCj4gUmV2aWV3IERhdGU6IEZlYiAxM3RoIDIwMTMNCj4gSUVURiBMYXN0IENhbGwgRGF0ZTog bi9hDQo+IElFU0cgVGVsZWNoYXQgRGF0ZTogRmViIDIxc3QgMjAxMw0KPiANCj4gU3VtbWFyeToN Cj4gDQo+IFRoZXJlIGlzIG9uZSByZWN1cnJpbmcgTWFqb3IgSXNzdWUgd2hpY2ggSSB0aGluayBy ZXF1aXJlcyBhIGJldHRlciB3b3JkaW5nIA0KPiB0byBhdm9pZCB0aGUgcmlzayBvZiBkaWZmZXJl bnQgaW5jb21wYXRpYmxlIGltcGxlbWVudGF0aW9ucy4gQWZ0ZXIgdGhpcyBpcyANCj4gZml4ZWQs IHRoZSB3b3JrIGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi4NCj4gDQo+IE1ham9yIElzc3VlczoN Cj4gDQo+IA0KPiAzLjEuMg0KPiANCj4gQnVyc3QgTG9zcyBSYXRlOiAxNiBiaXRzDQo+IA0KPiB0 aGUgd2hvbGUgcGFyYWdyYXBoIGlzIHRoZSAidmVyYmFsIGRlc2NyaXB0aW9uIG9mIGEgZm9ybXVs YSIsIHdoaWNoIA0KPiBob3dldmVyIGlzIG5vdCBwcmVzZW50IGFmdGVyIHRoZSBwYXJhZ3JhcGgg aXRzZWxmLi4uIHdvcnN0Li4uIHRoZSBmb3JtdWxhDQo+IHdoaWNoIGlzIHByZXNlbnRlZA0KPiAN Cj4gICAgUGFja2V0cyBMb3NzIGluIEJ1cnN0cyAvIFRvdGFsIFBhY2tldHMgZXhwZWN0ZWQgaW4g QnVyc3RzDQo+IA0KPiBpcyBqdXN0IGEgcGFydCBvZiB0aGUgbWlzc2luZyBjb21wbGV0ZSBmb3Jt dWxhLiBQbGVhc2UgYWRkIHRoZSBjb21wbGV0ZSANCj4gZm9ybXVsYSBhZnRlciB0aGUgcGFyYWdy YXBoLCBvciBwZW9wbGUgd2lsbCBoYXZlIHRvIHJlYWQgaXQgbWFueSB0aW1lcywgDQo+IGFuZCBp bnZlbnQgdGhlbXNlbHZlcyB0aGUgZm9ybXVsYTogbWF0aCBib29rcyBjYW4gYmUgd3JpdHRlbiB3 aXRob3V0IGEgDQo+IHNpbmdsZSAid29yZCIgYW5kIGV2ZXJ5b25lIHVuZGVyc3RhbmQgdGhlbSB0 aGUgc2FtZSB3YXkuIFRoZSByaXNrIGlzIGhlcmUgDQo+IHRoYXQgbWFueSB3aWxsIHdyaXRlIGEg ZGlmZmVyZW50IGZvcm11bGEgYWZ0ZXIgcmVhZGluZyB0aGUgdGV4dC4gSSBhbHNvIA0KPiBoYWQg YSBuZWVkIGZvciBtdWx0aXBsZSByZWFkaW5nIG9mIHRoZSAiZXhwcmVzc2VkIGFzIGEgZml4ZWQg cG9pbnQgbnVtYmVyIA0KPiB3aXRoIHRoZSBiaW5hcnkgcG9pbnQgYXQgdGhlIGxlZnQgZWRnZSBv ZiB0aGUgZmllbGQiLi4uIG1heWJlIHlvdSBjYW4gDQo+IHJld3JpdGUgdGhpcyBiZXR0ZXIsIHRv by4NCg0KW1Fpbl06IE9rYXksIEJhcnJ5IHJhaXNlZCB0aGlzIGlzc3VlIGFzIHdlbGwuIFdlIHdp bGwgZml4IHRoaXMgYXMgaGUgcHJvcG9zZWQuDQo+IA0KPiBHYXAgTG9zcyBSYXRlOiAxNiBiaXRz DQo+IA0KPiBzYW1lIHByb2JsZW0gYXMgYWJvdmU6IHBsZWFzZSBhZGQgdGhlIGV4cGxpY2l0IGZv cm11bGEuDQoNCltRaW5dOiBPa2F5Lg0KPiANCj4gMy4yLjINCj4gDQo+IEJ1cnN0IERpc2NhcmQg UmF0ZTogMTYgYml0cw0KPiANCj4gc2FtZSBwcm9ibGVtIGFzIGluIDMuMS4yIGFib3ZlOiBwbGVh c2UgYWRkIHRoZSBleHBsaWNpdCBmb3JtdWxhLg0KDQpbUWluXTogT2theS4NCg0KPiANCj4gR2Fw IERpc2NhcmQgUmF0ZTogMTYgYml0cw0KPiANCj4gc2FtZSBhcyBhYm92ZTogcGxlYXNlIGFkZCB0 aGUgZXhwbGljaXQgZm9ybXVsYS4NCg0KW1Fpbl06IE9rYXkuDQoNCj4gDQo+IE1pbm9yIElzc3Vl czoNCj4gDQo+IDIuMSBUZXJtaW5vbG9neQ0KPiANCj4gdGhlIHNlbnRlbmNlICJBIHZpZGVvIGZy YW1lIGlzIGNvbXByZXNzZWQgdXNpbmcgZGlmZmVyZW50IGFsZ29yaXRobXMiIA0KPiBnaXZlcyBh biBhYnNvbHV0ZSBhZmZpcm1hdGlvbiB3aWNoIGlzIG5vdCAxMDAlIHRydWUuIE5vdCBhbGwgYXBw bGljYXRpb25zIA0KPiBjb21wcmVzcyB2aWRlbyBmcmFtZXMsIHRoZXJlIGFyZSBhIGZldyB3aGlj aCBzZW5kIHVuY29tcHJlc3NlZCB2aWRlbywgdGh1cyANCj4gYWxsIGZyYW1lcyBhcmUgIktleSBG cmFtZXMiIGFjY29yZGluZyB0byB0aGlzIGRlZmluaXRpb24gYW5kIHRoZXJlIGFyZSBubyANCj4g IkRlcml2ZWQgRnJhbWVzIi4gSW4gb3RoZXIgY2FzZXMgZnJhbWUgY29tcHJlc3Npb24gaXMgYXBw bGllZCB0byBjb2xvciANCj4gZW5jb2RpbmcsIGFuZCBub3QgdG8gaW1hZ2UgY29udGVudCBpdHNl bGYsIGV0Yy4NCj4gDQo+IEkganVzdCBzdWdnZXN0IGEgbW9yZSByZWxheGVkICJJbiBtYW55IGNh c2VzLCBhIHZpZGVvIGZyYW1lIGlzIGNvbXByZXNzZWQgDQo+IHVzaW5nIGRpZmZlcmVudCBhbGdv dGl0aG1zIiwgYW5kIGxhdGVyLCB0aGUgYWRkaXRpb24gb2YgLi4uIkRlcml2ZWQgZnJhbWVzIA0K PiBhcmUgcHJlZGljYXRpdmVseSBjb2RlZCBhbmQgZGVyaXZlZCBmcm9tIGEgS2V5IGZyYW1lIHVz aW5nIGEgcHJlZGljdGlvbiANCj4gYWxnb3JpdGhtLiBJZiB0aGVyZSBpcyBubyB2aWRlbyBpbWFn ZSBjb21wcmVzc2lvbiwgYWxsIGZyYW1lcyBhcmUgS2V5IA0KPiBGcmFtZXMiLg0KPiANCg0KW1Fp bl06IFlvdSBhcmUgcmlnaHQgYW5kIGdvb2Qgc3VnZ2VzdGlvbi4gVGhhbmtzLg0KDQo+IDMuMS4y DQo+IA0KPiBSZXNlcnZlZDogNiBiaXRzDQo+IA0KPiBpZiB0aGUgc2VuZGVyIE1VU1QgcHV0IGFs bCB6ZXJvZXMsIGJlY2F1c2UgdGhlIGZpZWxkIGl0IG5vdCB5ZXQgaW4gdXNlLCANCj4gdGhlIHJl Y2VpdmVyIE1VU1QgaWdub3JlIGl0cyBjb250ZW50LiBXaHkgdGhlcmUgaXMgYSBTSE9VTEQ/IHdo YXQgdGhlIA0KPiByZWNpcGllbnQgY291bGQgZG8gd2l0aCBhbiBhbGwgemVyb2VzIGZpZWxkIG9m IG5vIHVzZT8gSXMgdGhlcmUgc29tZXRpbmcgSSANCj4gZG8gbm90IGdldCBjb3JyZWN0bHk/IGlm IHNvLCB0aGVuIHdlIHNob3VsZCBleHBsYWluIHRoaXMgLi4uIEkgbWlnaHQgYmUgYW4gDQo+IGlt cGxlbWVudGVyIGFuZCBkbyBpdCB3cm9uZy4NCg0KW1Fpbl06IFlvdSBhcmUgcmlnaHQsIHdlIHNo b3VsZCB1c2UgIk1VU1QiIGluc3RlYWQuDQo+IA0KPiAzLjIuMg0KPiANCj4gUmVzZXJ2ZWQ6IDYg Yml0cw0KPiANCj4gc2FtZSBhcyBhYm92ZSBmb3IgMy4xLjINCg0KW1Fpbl06IE9rYXksIHdpbGwg Zml4IHRoaXMuDQo+IA0KPiA0LjEuMi4NCj4gDQo+IFJlc2VydmVkOiA3IGJpdHMNCj4gDQo+IHNh bWUgYXMgYWJvdmUgZm9yIDMuMS4yDQoNCltRaW5dOiBPa2F5LCB3aWxsIGZpeCB0aGlzLg0KDQo+ IA0KPiBOaXRzOg0KPiANCj4gNC4xLjINCj4gDQo+IGZ1bGxfbG9zdF9mcmFtZXMgIHZzICBmdWxs X2xvc3QtZnJhbWVzIGxhdGVyIGluIHRoZSB0ZXh0Li4uIG1heWJlIG90aGVyIA0KPiB2YXJpYW50 cy4uLiBjaG9vc2UgMSwgYW5kIHVzZSBpdCBhbGwgdGhlIHRpbWUuDQoNCltRaW5dOiBPa2F5LCB3 aWxsIGZpeCB0aGlzLg0KPiBBdXRob3JzJyBBZGRyZXNzZXMNCj4gDQo+IGluIFJGQ3MgYWxsICJh dXRob3JzIiBhcmUganVzdCAiZWRpdG9ycyIgd2hlbiB0aGUgd29yayBpcyBjb21pbmcgb3V0IG9m IGEgDQo+IFdHLiA6LSkNCj4gDQo+IHdoeSBhZGRpbmcgIihlZGl0b3IpIiBhc2lkZSBqdXN0IG9u ZSBvZiB0aGVtPw0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENsYXVkaW8gQWxsb2Nj aGlvICAgICAgICAgICAgIEcgICBBICAgUiAgIFIgICAgICAgICAgQ2xhdWRpby5BbGxvY2NoaW9A Z2Fyci5pdA0KPiAgICAgICAgICAgICAgICAgICAgICAgICBTZW5pb3IgVGVjaG5pY2FsIE9mZmlj ZXINCj4gdGVsOiArMzkgMDQwIDM3NTg1MjMgICAgICBJdGFsaWFuIEFjYWRlbWljIGFuZCAgICAg ICBHPUNsYXVkaW87IFM9QWxsb2NjaGlvOw0KPiBmYXg6ICszOSAwNDAgMzc1ODU2NSAgICAgICAg UmVzZWFyY2ggTmV0d29yayAgICAgICAgIFA9Z2FycjsgQT1nYXJyOyBDPWl0Ow0KPiANCj4gICAg ICAgICAgICBQR1AgS2V5OiBodHRwOi8vd3d3LmNlcnQuZ2Fyci5pdC9QR1Ava2V5cy5waHAzI2Nh From jdrosen@jdrosen.net Sat Feb 16 04:27:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58AC21F8432; Sat, 16 Feb 2013 04:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQxEY5Y7LSB7; Sat, 16 Feb 2013 04:27:54 -0800 (PST) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.100]) by ietfa.amsl.com (Postfix) with ESMTP id C0E9521F842E; Sat, 16 Feb 2013 04:27:54 -0800 (PST) Received: from mail-wi0-f169.google.com ([209.85.212.169]:52357) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1U6grx-0007Qq-RO; Sat, 16 Feb 2013 07:27:53 -0500 Received: by mail-wi0-f169.google.com with SMTP id l13so2262305wie.0 for ; Sat, 16 Feb 2013 04:27:53 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.76.7 with SMTP id g7mr9443745wjw.50.1361017673203; Sat, 16 Feb 2013 04:27:53 -0800 (PST) Received: by 10.194.165.230 with HTTP; Sat, 16 Feb 2013 04:27:53 -0800 (PST) In-Reply-To: <511A73B0.7080902@ericsson.com> References: <511A73B0.7080902@ericsson.com> Date: Sat, 16 Feb 2013 07:27:53 -0500 Message-ID: From: Jonathan Rosenberg To: Salvatore Loreto Content-Type: multipart/alternative; boundary=047d7beba202f1c10404d5d69ef7 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Sat, 16 Feb 2013 08:18:24 -0800 Cc: "apps-discuss@ietf.org" , draft-ietf-simple-simple@tools.ietf.org, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-simple-simple-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 12:27:55 -0000 --047d7beba202f1c10404d5d69ef7 Content-Type: text/plain; charset=ISO-8859-1 Thanks Salvatore for the comments. Responses below: On Tue, Feb 12, 2013 at 11:54 AM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > http://trac.tools.ietf.org/**area/app/trac/wiki/** > ApplicationsAreaDirectorate). > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-simple-simple-08 > Title: Simple made Simple: An Overview of the IETF Specifications for > Instant > Messaging and Presence using the Session Initiation Protocol (SIP) > Reviewer: Salvatore Loreto > Review Date: Feb-12-2013 > IETF Last Call Date: Not known > IESG Telechat Date: Feb-21-2013 > > Summary: This draft is ready for publication as Informational. > Two editorial updates that should be looked at before publication are > listed below. > > Major Issues: 0 > Minor Issues: 2 > Nits: 0 > > Minor: > ----- > Section 2.1 Core Protocol Machinery > > - RFC 3265 has been updated by RFC 6665, why the document still mention > 3265? > References changed to RFC6665. > > Section 2.6 Optimization > > - RFC 6446 "Session Initiation Protocol (SIP) Event Notification Extension > for Notification Rate Control" > should be also listed in this section. > Added. Thanks! -Jonathan R. -- Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net --047d7beba202f1c10404d5d69ef7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Salvatore for the comments. Responses below:


On Tue, Feb 12, = 2013 at 11:54 AM, Salvatore Loreto <salvatore.loreto@ericsson.= com> wrote:
I have been selected as the Applications Are= a Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/tra= c/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-simple-simple-08
Title: Simple made Simple: An Overview of the IETF Specifications for Insta= nt
Messaging and Presence using the Session Initiation Protocol (SIP)
Reviewer: Salvatore Loreto
Review Date: Feb-12-2013
IETF Last Call Date: Not known
IESG Telechat Date: Feb-21-2013

Summary: This draft is ready for publication as Informational.
Two editorial updates that should be looked at before publication are liste= d below.

Major Issues: 0
Minor Issues: 2
Nits: 0

Minor:
-----
Section 2.1 Core Protocol Machinery

- RFC 3265 has been updated by RFC 6665, why the document still mention 326= 5?

References changed to RFC6665.=
=A0

Section 2.6 Optimization

- RFC 6446 "Session Initiation Protocol (SIP) Event Notification Exten= sion for Notification Rate Control"
should be also listed in this section.

Added.

Thanks!
-= Jonathan R.

=A0


--
--047d7beba202f1c10404d5d69ef7-- From masinter@adobe.com Sat Feb 16 19:33:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0F221F865B for ; Sat, 16 Feb 2013 19:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 BF7ZcFPSK5SU for ; Sat, 16 Feb 2013 19:33:16 -0800 (PST) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 6806021F8503 for ; Sat, 16 Feb 2013 19:33:15 -0800 (PST) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUSBPeuAz6LrZ5uY3dvJhIYjjnzE1VRyg@postini.com; Sat, 16 Feb 2013 19:33:16 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r1H3XDnT001700; Sat, 16 Feb 2013 19:33:13 -0800 (PST) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id r1H3WhXt009203; Sat, 16 Feb 2013 19:33:12 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Sat, 16 Feb 2013 19:33:02 -0800 From: Larry Masinter To: Ian Hickson Date: Sat, 16 Feb 2013 19:33:00 -0800 Thread-Topic: RFC 2388 (multipart/form-data) Thread-Index: Ac4JeAL1hHMiHz3lSkyglffUHTyaKwAlcQPw Message-ID: References: In-Reply-To: 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: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 2388 (multipart/form-data) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Feb 2013 03:33:20 -0000 I'm not aware of anyone who could be talked into updating multipart/form-da= ta to fix flaws, such as to specify how non-ASCII field-names can/should be= encoded (bug 16909). I suggest asking the IETF Applications Area (list apps-discuss@ietf.org) as= the closest to a group monitoring the health of IETF-sponsored application= specifications. > -----Original Message----- > From: Ian Hickson [mailto:ian@hixie.ch] > Sent: Tuesday, February 12, 2013 3:18 PM > To: Larry Masinter > Subject: RFC 2388 (multipart/form-data) >=20 >=20 > Hey Larry, >=20 > Do you know if there is anyone working on fixing RFC2388? People keep > asking me to update the HTML spec to just define it all inline rather tha= n > deferring to the RFC since the RFC leaves a lot of stuff underdefined, bu= t > I don't have the bandwidth to spec all that myself at this point. >=20 > e.g.: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D16909 > https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D19879 >=20 > Other feedback: > http://lists.w3.org/Archives/Public/public-whatwg- > archive/2012Oct/0204.html > http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0037= .html > http://lists.w3.org/Archives/Public/public-whatwg- > archive/2012May/0003.html >=20 > Cheers, > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From mnot@mnot.net Sun Feb 17 16:15:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D02521E8055 for ; Sun, 17 Feb 2013 16:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.475 X-Spam-Level: X-Spam-Status: No, score=-105.475 tagged_above=-999 required=5 tests=[AWL=-2.876, 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 2IKCIC+5DRDT for ; Sun, 17 Feb 2013 16:15:44 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id A25E821E8051 for ; Sun, 17 Feb 2013 16:15:44 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.197.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id ECC63509B6; Sun, 17 Feb 2013 19:15:42 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Mon, 18 Feb 2013 11:15:39 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dave Cridland X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] .well-known as a one stop shopping location for Web Services 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, 18 Feb 2013 00:15:45 -0000 ... and furthermore, you actually get some evidence that such web = developers would actually use and like such a mechanism before squatting = on such valuable namespace. Cheers, On 16/02/2013, at 7:35 PM, Dave Cridland wrote: > Can I just check I understand your idea correctly? >=20 > You're suggesting a device (or other consumer) is fed a URI of the = form wk:foo:example.com, and resolves this by: >=20 > 1) Performing a SRV lookup on _foo._wk.example.com to find a hostname = (eg, server.example.com). >=20 > 2) Forming an HTTP URI from this to the .well-known space formed from = the service name on that host (eg, = http://server.example.com/.well-known/foo) >=20 > 3) Performing requests on that, expecting to obtain a Content-Type = header reading "application/json; wk=3Dfoo" and processing accordingly. >=20 > If all this is correct, I think the basic mechanism is solid and = should work, and would give strong benefits if widely deployed. >=20 > At the risk of sounding frivolous, though, I suspect "wk" is not going = to gain as much traction as, say "api". I appreciate that the moment I = send this mail, there'll be a concurrent spluttering of morning coffee = across the world, but please bear in mind that a protocol mechanism = designed for a wide appeal needs some effort putting into its name. It = doesn't matter if ".well-known" exists behind the scenes, but I don't = think it'll resonate with the bulk of web developers we'd be targetting. >=20 > Dave. >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From hallam@gmail.com Sun Feb 17 16:32:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A822521F8B35 for ; Sun, 17 Feb 2013 16:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=-2.530, 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 AL5U+Vm0Fh37 for ; Sun, 17 Feb 2013 16:32:14 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4BED821F8B36 for ; Sun, 17 Feb 2013 16:32:14 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id fn15so4088172wgb.8 for ; Sun, 17 Feb 2013 16:32:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ByXM10/tGOvNv3lce4LGsGpULaS4CO67H1djN6n46c0=; b=Rf+vXmbIjIogzlV1XPsj02FtTJIgk1LkgvRSIotxPcNxblVrcIDzFOaUjNr0VtX7pY 3OsqH/MgTsFOUkKOHnOITpo/jpMi+HQBrtQmnyZjsX0juxcPFvcDW7nze+Xa6H+pd3NX pXfmhkVIy4rICFRRkIBqsxLRuT/mhMQGu3V92G3BsEMVX3FrR4vyyrRyLqagwN9wy+VB PswMxtgNcWaw9HQBTBJ828uvbnWv6SLOdHc4nCaDHxpMZhj+7JgiUx36n3+CLH17ykNm 3iuL+ZVUHfsQTmAazEPX7CmJ5SEZoypNq+zuX0alyXMJOah4SzRGDRKW3PWalAzy0MFD V/oA== MIME-Version: 1.0 X-Received: by 10.180.82.9 with SMTP id e9mr17814813wiy.1.1361147531727; Sun, 17 Feb 2013 16:32:11 -0800 (PST) Received: by 10.194.176.169 with HTTP; Sun, 17 Feb 2013 16:32:11 -0800 (PST) In-Reply-To: References: Date: Sun, 17 Feb 2013 19:32:11 -0500 Message-ID: From: Phillip Hallam-Baker To: Mark Nottingham Content-Type: multipart/alternative; boundary=f46d044304761d935004d5f4dbfb Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] .well-known as a one stop shopping location for Web Services 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, 18 Feb 2013 00:32:15 -0000 --f46d044304761d935004d5f4dbfb Content-Type: text/plain; charset=ISO-8859-1 On Sun, Feb 17, 2013 at 7:15 PM, Mark Nottingham wrote: > ... and furthermore, you actually get some evidence that such web > developers would actually use and like such a mechanism before squatting on > such valuable namespace. > > Cheers, I don't think that should be a problem. There are two separate ideas here 1) One stop shopping for identifiers 2) Better discovery via SRV/URI/New RR The two are orthogonal. If you get /.well-known/foo then you might or might not want to use _foo._wk for SRV discovery but you certainly would not want it to be used for anything else. Now the argument for the API: or WS: (Web Service) method is a lot harder, I agree. But given that it is prime real estate, doesn't it make best sense to share it equitably? > > On 16/02/2013, at 7:35 PM, Dave Cridland wrote: > > > Can I just check I understand your idea correctly? > > > > You're suggesting a device (or other consumer) is fed a URI of the form > wk:foo:example.com, and resolves this by: > > > > 1) Performing a SRV lookup on _foo._wk.example.com to find a hostname > (eg, server.example.com). > > > > 2) Forming an HTTP URI from this to the .well-known space formed from > the service name on that host (eg, > http://server.example.com/.well-known/foo) > > > > 3) Performing requests on that, expecting to obtain a Content-Type > header reading "application/json; wk=foo" and processing accordingly. > > > > If all this is correct, I think the basic mechanism is solid and should > work, and would give strong benefits if widely deployed. > > > > At the risk of sounding frivolous, though, I suspect "wk" is not going > to gain as much traction as, say "api". I appreciate that the moment I send > this mail, there'll be a concurrent spluttering of morning coffee across > the world, but please bear in mind that a protocol mechanism designed for a > wide appeal needs some effort putting into its name. It doesn't matter if > ".well-known" exists behind the scenes, but I don't think it'll resonate > with the bulk of web developers we'd be targetting. > > > > Dave. > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Mark Nottingham http://www.mnot.net/ > > > > -- Website: http://hallambaker.com/ --f46d044304761d935004d5f4dbfb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Feb 17, 2013 at 7:15 PM, Mark Nottingham <mnot@mnot.net>= wrote:
... and furthermore, you actually get some evidence that such web developer= s would actually use and like such a mechanism before squatting on such val= uable namespace.

Cheers,

I don't think that should be a = problem.

There are two separate ideas here

1) One stop shopping for identifiers
2) Better = discovery via SRV/URI/New RR

The two are orthogonal. If you get /.well-known/foo the= n you might or might not want to use _foo._wk for SRV discovery but you cer= tainly would not want it to be used for anything else.

Now the argument for the API: or WS: (Web Service) method is a lot har= der, I agree. But given that it is prime real estate, doesn't it make b= est sense to share it equitably?


=A0

On 16/02/2013, at 7:35 PM, Dave Cridland <dave@cridland.net> wrote:

> Can I just check I understand your idea correctly?
>
> You're suggesting a device (or other consumer) is fed a URI of the= form wk:foo:example.com, and resolves this by:
>
> 1) Performing a SRV lookup on _foo._wk.example.com to find a hostname (eg, server.example.com).
>
> 2) Forming an HTTP URI from this to the .well-known space formed from = the service name on that host (eg, http://server.example.com/.well-known/foo)
>
> 3) Performing requests on that, expecting to obtain a Content-Type hea= der reading "application/json; wk=3Dfoo" and processing according= ly.
>
> If all this is correct, I think the basic mechanism is solid and shoul= d work, and would give strong benefits if widely deployed.
>
> At the risk of sounding frivolous, though, I suspect "wk" is= not going to gain as much traction as, say "api". I appreciate t= hat the moment I send this mail, there'll be a concurrent spluttering o= f morning coffee across the world, but please bear in mind that a protocol = mechanism designed for a wide appeal needs some effort putting into its nam= e. It doesn't matter if ".well-known" exists behind the scene= s, but I don't think it'll resonate with the bulk of web developers= we'd be targetting.
>
> Dave.
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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






--
Website: http://hallambaker.com/
--f46d044304761d935004d5f4dbfb-- From mnot@mnot.net Sun Feb 17 17:07:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F8421F8658 for ; Sun, 17 Feb 2013 17:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.427 X-Spam-Level: X-Spam-Status: No, score=-105.427 tagged_above=-999 required=5 tests=[AWL=-2.828, 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 jHhs+gC5u+aA for ; Sun, 17 Feb 2013 17:07:28 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 510B921F863F for ; Sun, 17 Feb 2013 17:07:28 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.197.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 042CE509B6; Sun, 17 Feb 2013 20:07:26 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Mon, 18 Feb 2013 12:07:23 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] .well-known as a one stop shopping location for Web Services 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, 18 Feb 2013 01:07:29 -0000 On 18/02/2013, at 11:32 AM, Phillip Hallam-Baker = wrote: > Now the argument for the API: or WS: (Web Service) method is a lot = harder, I agree. But given that it is prime real estate, doesn't it make = best sense to share it equitably? *If* your proposal for how to use it is, as I said, actually useful and = attractive to web developers.=20 Cheers, -- Mark Nottingham http://www.mnot.net/ From jhildebr@cisco.com Mon Feb 18 12:01:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1830D21F8C86; Mon, 18 Feb 2013 12:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRqDlBztQ3IG; Mon, 18 Feb 2013 12:01:22 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 21E9421F8C84; Mon, 18 Feb 2013 12:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1004; q=dns/txt; s=iport; t=1361217676; x=1362427276; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=+8QzgxuCG7XPxuwv+GslP8WOuKbsW+QVuHuqrS7jd54=; b=HLTIdDA+CoDtbi4NQwO1e3KCsWCrmmoPrDODeCFK5DBfluIYoQLNgJyu mhhluZxqMhoznv2ceKna9dJ6ESH1QCIoYAS6fZJFGVgY1VZVWbjQh4mRP FRCwa3PgdyKI7Y6rsrL9cLczj0miId/UacVxbd6AS4UVS2TqJdYe9CKdy k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFABOIIlGtJXG+/2dsb2JhbABEhgK6IIEEFnOCIQEEAQEBNy0EAx0BKhQ3CycEARIIiAoMwQ6PBoMXYQOXSY87gweCJw X-IronPort-AV: E=Sophos;i="4.84,690,1355097600"; d="scan'208";a="178465579" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 18 Feb 2013 20:01:08 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1IK17YM024703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Feb 2013 20:01:07 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 14:01:07 -0600 From: "Joe Hildebrand (jhildebr)" To: "apps-discuss@ietf.org" , "json@ietf.org" Thread-Topic: JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3g== Date: Mon, 18 Feb 2013 20:01:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [apps-discuss] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Feb 2013 20:01:23 -0000 We're planning on doing a BoF in Orlando to discuss starting up a JSON working group. The BoF is currently planned for Monday afternoon at 1300 in Carribean 6. A very preliminary version of a charter can be found here: http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON But obviously we'll need to build consensus on what it should actually contain. Please discuss on the json@ietf.org mailing list: https://www.ietf.org/mailman/listinfo/json As a start, we know there are a couple of things we'd like to fix about RFC 4627: - move to standards track - an ABNF indentation typo in section 2.2 - change SHOULD to MUST for the uniqueness of names in an object A *very* important goal would be to minimize change, and to ensure strict backward-compatibility. There are likely adjunct JSON topics that would make sense to tackle once we've got the experts together, but the goal would be to keep that list short, focused, and general-purpose. --=20 Joe Hildebrand From fgaliegue@gmail.com Mon Feb 18 13:02:33 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAD221F8688; Mon, 18 Feb 2013 13:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPDe10UsB9YX; Mon, 18 Feb 2013 13:02:33 -0800 (PST) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0896021F8CA2; Mon, 18 Feb 2013 13:02:22 -0800 (PST) Received: by mail-ea0-f176.google.com with SMTP id a13so2698002eaa.35 for ; Mon, 18 Feb 2013 13:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0r2YvWqWOyJerBQtXZ0emtEwIxgSNei6/ON5VHv07Jw=; b=YJIJDmb1KH5bz4S0TkpkqxpHO9moB1Grpjmm4ZfNfMja1r6hegr/FK42Spnl6Jr+wb 5PtHtBYUiMMGY0mIt4hy/WEs8ChzoKJIRsACrh5RhPxploZ67sXIl6HQt0DAy1YfmWM6 8+t1xyeBxB6Cz2KFLUDc2LL0HicuxkKR7BFi/3XI0JHvZzlwOhjZxRGLDNkVBiq4ticS 0xJhHlcY7W7jAiEoQRzMj6AtWpRdclF2A70yYQ9V7rMEaaaS2S18lfCzU11ALET8xnAB lOf7TuvCHeqSCKKM45ynt8AgrJ8aLam4NpSLd6V7ePB6mpjfq+1i0IPg1NC6ylFcNfgY ytXw== MIME-Version: 1.0 X-Received: by 10.14.183.67 with SMTP id p43mr48602495eem.10.1361221342154; Mon, 18 Feb 2013 13:02:22 -0800 (PST) Received: by 10.14.1.7 with HTTP; Mon, 18 Feb 2013 13:02:21 -0800 (PST) In-Reply-To: References: Date: Mon, 18 Feb 2013 22:02:21 +0100 Message-ID: From: Francis Galiegue To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Feb 2013 21:02:33 -0000 Hello, On Mon, Feb 18, 2013 at 9:01 PM, Joe Hildebrand (jhildebr) wrote: > We're planning on doing a BoF in Orlando to discuss starting up a JSON > working group. The BoF is currently planned for Monday afternoon at 1300 > in Carribean 6. A very preliminary version of a charter can be found here: > > http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON > JSON Schema is missing from this page (it has been updated recently and is now three specifications). -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From cabo@tzi.org Mon Feb 18 13:35:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63E821F8C74; Mon, 18 Feb 2013 13:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.237 X-Spam-Level: X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=0.012, 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 NPBONTWnHWbH; Mon, 18 Feb 2013 13:35:32 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E3A9B21F8C68; Mon, 18 Feb 2013 13:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r1ILZAhc017789; Mon, 18 Feb 2013 22:35:10 +0100 (CET) Received: from [192.168.217.105] (p548937E4.dip.t-dialin.net [84.137.55.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AD9873BB6; Mon, 18 Feb 2013 22:35:09 +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, 18 Feb 2013 22:35:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <338D1DA7-AEB4-4731-8BC0-B8D2602396F6@tzi.org> References: To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Feb 2013 21:35:32 -0000 On Feb 18, 2013, at 21:01, "Joe Hildebrand (jhildebr)" = wrote: > adjunct JSON topics One such topic might be roundtripping to/from some simple binary format = for JSON-structured values. draft-bormann-apparea-bpack-00.txt Gr=FC=DFe, Carsten From jhildebr@cisco.com Mon Feb 18 15:47:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3608B21E8094; Mon, 18 Feb 2013 15:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4QY5LkDOyFl; Mon, 18 Feb 2013 15:47:18 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D24C021E808F; Mon, 18 Feb 2013 15:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=532; q=dns/txt; s=iport; t=1361231235; x=1362440835; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SEi9fFDhnLwDNdg8A3WfntM7JU9VROXkRPCzBs/cVmc=; b=bjoRSuY+zuYShkbOsdw/8x3yLqUR0lRsmB684Jge87707GUb6zXhk9Rh meg3RyA6HNupmi7ul7UW+fIIPeyp0RRN4UsmOH3GncVRTJW7ZrqdVgVXl /4Mibnt3BTfU0vrXAMy6oKdfY5qgo4peZ/oyAk8Ra7J0XPkOd0e5Eq/4r A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAIq8IlGtJXG8/2dsb2JhbABEhgK6IoEFFnOCHwEBAQQ6NAsSAQgOCgoUQiUCBA4FCIgKwTuOfTEHY4F8YQOnBIJ6DYIn X-IronPort-AV: E=Sophos;i="4.84,691,1355097600"; d="scan'208";a="178466262" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 18 Feb 2013 23:47:13 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1INlDOi000667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Feb 2013 23:47:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 17:47:13 -0600 From: "Joe Hildebrand (jhildebr)" To: Carsten Bormann Thread-Topic: [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piAiBQA//+vjYA= Date: Mon, 18 Feb 2013 23:47:13 +0000 Message-ID: In-Reply-To: <338D1DA7-AEB4-4731-8BC0-B8D2602396F6@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Feb 2013 23:47:19 -0000 On 2/18/13 2:35 PM, "Carsten Bormann" wrote: >On Feb 18, 2013, at 21:01, "Joe Hildebrand (jhildebr)" > wrote: > >> adjunct JSON topics > >One such topic might be roundtripping to/from some simple binary format >for JSON-structured values. > >draft-bormann-apparea-bpack-00.txt As an individual, I'm +1 on that. I love msgpack, and don't mind the addition of UTF8 as a separate type. Was frsyuki involved in the draft, or at least know that it happened? --=20 Joe Hildebrand From jhildebr@cisco.com Mon Feb 18 15:52:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357AF21E8087; Mon, 18 Feb 2013 15:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dHQjGgR4UVs; Mon, 18 Feb 2013 15:52:28 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9A521F8D39; Mon, 18 Feb 2013 15:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=666; q=dns/txt; s=iport; t=1361231545; x=1362441145; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NFjddzjdNZf/54qUItK/GMPZ2PxAJg7Eu1G/juh59E8=; b=b4IWH4m0yPMAsdH/kB2mOJOeDfFfqQUSt7XcMrM5zt66wpL6mxU2bCzp hroiy5G7Eo9EqAKlgVXvGQA03bQhBp26oIGojm6PR/T4nAfHxme8GCtqD a9fdR/Eo31+rptmS9ELYHpZKHMUmv+tEhffMj6KjdffwtgtcR3W/w8U7S 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAJu9IlGtJXG+/2dsb2JhbABEhgK6IoEFFnOCIQEEOjQLEgEIDhQUMRElAgQOBQiHeAMPDLdJDYlajFCCLTEHY4F8YQOUUYJ4iiaFFYJ6DYIn X-IronPort-AV: E=Sophos;i="4.84,691,1355097600"; d="scan'208";a="178521988" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 18 Feb 2013 23:52:25 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1INqOTV018930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Feb 2013 23:52:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 17:52:24 -0600 From: "Joe Hildebrand (jhildebr)" To: Francis Galiegue Thread-Topic: [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piAfuyA//+6JQA= Date: Mon, 18 Feb 2013 23:52:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Feb 2013 23:52:29 -0000 On 2/18/13 2:02 PM, "Francis Galiegue" wrote: >>http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON > >JSON Schema is missing from this page (it has been updated recently >and is now three specifications). As an individual. I'd say that a way to unambiguously specify further standards that use JSON seems reasonable. Whether it's json-schema or json-content-rules, or something else seems like a fertile ground for discussion. I like Cyrus's argument that all we need is the ABNF of the JSON world, and that any attempt to get more complicated than that will likely lead us down the XSD rathole. --=20 Joe Hildebrand From fgaliegue@gmail.com Mon Feb 18 16:13:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D30321E8094; Mon, 18 Feb 2013 16:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 S9ZQdXlYEN3L; Mon, 18 Feb 2013 16:13:34 -0800 (PST) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBBF21E8051; Mon, 18 Feb 2013 16:13:34 -0800 (PST) Received: by mail-ea0-f182.google.com with SMTP id a12so2532395eaa.27 for ; Mon, 18 Feb 2013 16:13:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6cpnPVgFhd4i//EpE/2sC4Rv15kVPHoz7gX9qYLpndU=; b=Xy7S8JFVZBivQ9V+8n/wPwJaiqvfbla4mpQpEKFDrS7ZlbPhhvXuPDGhLQLHEaKE9i aTToa1oUD8hH77R4xe/19pqds1jOYsBBtzDDPDem/EvkW/47Dltan0pp7hMHoGXAGhQR p4yWdbIRZOUaQiupOh/b+kIy0HocrbGIrUEwpCjvV7f6MNYeEa5aHjXlQgPu//oGviK9 LWOc4T3S7Wviu+JH7ye91/p0VG+yVXWqszthTbaNsaCbyZth7EVstcRGnD9dAEV5C63i tQB4SP/wbw3Loi/37Rvopf8HRGjrCLKCWaGhBCbyFVXI8pkEj34NeiV7o66dJ9I+Oh5e 3e8w== MIME-Version: 1.0 X-Received: by 10.14.183.67 with SMTP id p43mr50201198eem.10.1361232811387; Mon, 18 Feb 2013 16:13:31 -0800 (PST) Received: by 10.14.1.7 with HTTP; Mon, 18 Feb 2013 16:13:31 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Feb 2013 01:13:31 +0100 Message-ID: From: Francis Galiegue To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 00:13:35 -0000 On Tue, Feb 19, 2013 at 12:52 AM, Joe Hildebrand (jhildebr) wrote: > On 2/18/13 2:02 PM, "Francis Galiegue" wrote: > >>>http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON >> >>JSON Schema is missing from this page (it has been updated recently >>and is now three specifications). > > As an individual. > > I'd say that a way to unambiguously specify further standards that use > JSON seems reasonable. Whether it's json-schema or json-content-rules, or > something else seems like a fertile ground for discussion. > > I like Cyrus's argument that all we need is the ABNF of the JSON world, > and that any attempt to get more complicated than that will likely lead us > down the XSD rathole. > Well, I'd like to hear the reasoning behind this argument ;) I have really struggled to make this specification useful, and witnessing the users of my library alone, it looks like the pure validation part of JSON Schema already has quite a few users... I also make the best efforts not to repeat XSD's mistakes, and right now JSON Schema is young enough that it cannot have made such mistakes (I _think_). But in order not to repeat such mistakes, advice from external people is of course needed. Which is why reviews are always welcome! -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From jhildebr@cisco.com Mon Feb 18 17:07:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B663A21E8063; Mon, 18 Feb 2013 17:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8pb5SJy13hb; Mon, 18 Feb 2013 17:07:38 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 27BC321E8044; Mon, 18 Feb 2013 17:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1160; q=dns/txt; s=iport; t=1361236058; x=1362445658; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0Ydq1sRzavbAoylHxitDzc666BHZbUMPpfAW+bX6b+k=; b=R8stN0XRA3kTzytfWM2BnMvTezEF2BlIG0WDR2zXRHwHTEKFrHsSh/eF 1M229qR4sVSijbIRdTBhVWToeoW5WcLcxL4+JT0cTEmZ0Cm4LORG4TQkN 7HvflvylNUYEslM/oTEY1ARwdHX3tBHDHPoEe0NqpzNMHZjw4L35QTqSN s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANTPIlGtJXG+/2dsb2JhbABEwCmBBRZzgh8BAQEDATo0CwUNAQgOFBQxESUCBA4FCId4AwkGsUCGDw2JWoxQgi0xB4JfYQOSbYFkjR6FFYMHgWskGA X-IronPort-AV: E=Sophos;i="4.84,692,1355097600"; d="scan'208";a="178504137" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 19 Feb 2013 01:07:37 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1J17bI8031648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 01:07:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 19:07:37 -0600 From: "Joe Hildebrand (jhildebr)" To: Francis Galiegue Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piAfuyA//+6JQCAAHtEgP//mcEA Date: Tue, 19 Feb 2013 01:07:36 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] [Json] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 01:07:38 -0000 On 2/18/13 5:13 PM, "Francis Galiegue" wrote: >I have really struggled to make this specification useful, and >witnessing the users of my library alone, it looks like the pure >validation part of JSON Schema already has quite a few users... > >I also make the best efforts not to repeat XSD's mistakes, and right >now JSON Schema is young enough that it cannot have made such mistakes >(I _think_). But in order not to repeat such mistakes, advice from >external people is of course needed. Oh! Sorry, I didn't mean to imply that I didn't like json-schema, just that there are several different approaches that have been proposed, and it makes sense to have a conversation about what our requirements are and if we think we're meeting them with one of those proposals. Charter-wise, setting the requirement to be "as simple as possible, but no simpler" is probably something we can all agree on; agreeing on what constitutes "simple" is likely to be more complex. :) > Which is why reviews are always welcome! I certainly need to review the latest versions before having an opinion. --=20 Joe Hildebrand From fgaliegue@gmail.com Mon Feb 18 17:15:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5A121E8053; Mon, 18 Feb 2013 17:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmFcGqIZ-YXG; Mon, 18 Feb 2013 17:15:16 -0800 (PST) Received: from mail-ea0-f171.google.com (mail-ea0-f171.google.com [209.85.215.171]) by ietfa.amsl.com (Postfix) with ESMTP id C646021E8044; Mon, 18 Feb 2013 17:15:15 -0800 (PST) Received: by mail-ea0-f171.google.com with SMTP id c13so2547101eaa.30 for ; Mon, 18 Feb 2013 17:15:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=R7I2vmOLFVliJAyFE4XM5zSP8/0Tqha4+mVIivB2+UQ=; b=gHYJeMoO1A0utRhUTleOUrEvywikxfjgE03/nFRbQX3hvDPSux/XyiIU+Pd59ovo2U NTIlSKqqyIOgwFv5fVcYnSwc0gMt4vQcAUr3Z4P9D1LvggMueGZUR+bfASjaYeanXIsg BfoyIG9zuO6anm0SJt8cmpygXNEpI77ZP5bixp+mUD4wYdeZqLExutfOsek1N9qurWrl 4R0vZjWYCNmWTgq+I7ZJ7TcyLTljvOkNsHRfPD7HTJZ7a/EKallJobem2Lua+FScePBx 1EnyHgCctEAWrCiH9nKhb/9xlgPDLfTy9bZFme8qkSIO6TiRbc/Ja15JYvtzduVa2sg1 RDPQ== MIME-Version: 1.0 X-Received: by 10.14.183.67 with SMTP id p43mr50721333eem.10.1361236514813; Mon, 18 Feb 2013 17:15:14 -0800 (PST) Received: by 10.14.1.7 with HTTP; Mon, 18 Feb 2013 17:15:14 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Feb 2013 02:15:14 +0100 Message-ID: From: Francis Galiegue To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] [Json] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 01:15:17 -0000 On Tue, Feb 19, 2013 at 2:07 AM, Joe Hildebrand (jhildebr) wrote: [...] > > Oh! Sorry, I didn't mean to imply that I didn't like json-schema, just > that there are several different approaches that have been proposed, and > it makes sense to have a conversation about what our requirements are and > if we think we're meeting them with one of those proposals. > I'd certainly like to have a digest of this discussion! I have my own needs, and even my own implementation, so I cannot be partial here -- just be a witness on my use case. > Charter-wise, setting the requirement to be "as simple as possible, but no > simpler" is probably something we can all agree on; agreeing on what > constitutes "simple" is likely to be more complex. :) > >> Which is why reviews are always welcome! > > I certainly need to review the latest versions before having an opinion. > Looking forward to this! Have fun, -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From stpeter@stpeter.im Mon Feb 18 19:46:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D713F21E804B for ; Mon, 18 Feb 2013 19:46:29 -0800 (PST) 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 ejv9QeDr081P for ; Mon, 18 Feb 2013 19:46:28 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6597121E8047 for ; Mon, 18 Feb 2013 19:46:28 -0800 (PST) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 02E10403CD; Mon, 18 Feb 2013 20:53:50 -0700 (MST) Message-ID: <5122F593.3050400@stpeter.im> Date: Mon, 18 Feb 2013 20:46:27 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dave Cridland References: <51067C1C.2050509@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 03:46:30 -0000 (Apologies for the slow response time...) On 1/29/13 1:21 PM, Dave Cridland wrote: > What about: > > Because an 'acct' URI enables abstract identification only and not > interaction, this specification provides no method for deferencing > an 'acct' URI on its own, e.g., as the value of the 'href' attribute of > an HTML anchor element. For example, there is no behaviour > specified in this document for an 'acct' URI used as follows: > > find out more > > Instead, an 'acct' URI is employed indirectly and typically is passed > around as a parameter in the background within a protocol flow so > that an entity can interact with a resource related to that identified > by the 'acct' URI in a particular way or for a particular purpose. [... > continues ...] Thanks, that is helpful; I'll incorporate that into the spec. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Feb 18 19:58:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908A421F8D0A for ; Mon, 18 Feb 2013 19:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.295 X-Spam-Level: X-Spam-Status: No, score=-102.295 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, J_CHICKENPOX_83=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 9WmVDLiapTm5 for ; Mon, 18 Feb 2013 19:58:29 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5137221F8D09 for ; Mon, 18 Feb 2013 19:58:25 -0800 (PST) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2318D403CD; Mon, 18 Feb 2013 21:05:48 -0700 (MST) Message-ID: <5122F860.4000507@stpeter.im> Date: Mon, 18 Feb 2013 20:58:24 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: James M Snell References: <5106BFDC.2030706@ericsson.com> <5106C090.8080403@ericsson.com> <51103CA0.1080609@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] delegation of acct URIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 03:58:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/4/13 8:39 PM, James M Snell wrote: > Certainly not going to argue any of those points... the only thing > I will say is that, for now, all I'm advocating is that the acct > URI ought to allow for optional query parameters... without > defining exactly what those parameters are or what the relevant > concerns are about their specific use. To date I haven't seen anyone mention uses for query parameters on 'acct' URIs, so I'd prefer not to introduce them at this point. If indeed there are use cases in which a query component is needed in order to identify or retrieve resources associated with an 'acct' URI, I'd love to hear about them. At present my limited imagination does not envision a compelling need for the query component here (and as far as I can see, a query component of provider=foo does not identify a resource associated with an account, but a method for interacting with the account). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIvhgAAoJEOoGpJErxa2plU8QAJwdEOz+YNyRdBv0B02/IB4H E2PRJp+fFDKMR/KzVfiyoCtkbVjvNmkmQzFMKeXtDPZOL9gCDdn1fuzhM7CSv1G9 cT5ellc2oDAPYCkyn98xd2irQNuXOlaYZC1a1UA5wxGIsCoS3cyBNg4T7O+eAx9e CpcmBfqOBsM3CPzgMoY/Wr1vvOy5Hv6akg4aSx5Pr+9pRySYRpBtkFbIjpOuAxBO yprWbqetHZ2ogHKpBdIv14hV+N18bYBZDKcnCSK8F18dWGimfx92P6zXqoUT36VH +dw1XTAhgD3iZFxfUl8IReEkRWScqcrtbpRLR/liOy/Gv/43+m31UBRwDpctfAyn QxzBcdTPCJZKMVnFV4ycduie+vj/1lbRObCcqmhqLAYp1nyc+45BNrWsT5b3p0v8 43L2xAu7qHgaZTyXH7PELbbF+xNQxOcK7dckmOADqC27jSEtEbRniXCqxxJgCZ/Q LGNBpPb+JgCkg1+BSZ0UVDqCCer6NQZT10wN3l+cr6e+GxLZhUFzkc2Iud9YRlTK QEpWTJYh8lRclSCazUt3HrPL2Yvz7yxBjHGZLIRg1fqp8OEWjHHkYbNxeF55tNNr jQKfwGi2IMTsNSR2jmX1y45Sw5EtLy0M3SL2nTnWMQnbnMsO3A17cOXSEE5R5HbG gEZ9pLjJT4AN5U2C5tZa =mcsh -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Feb 18 20:02:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3373E21F8D0B for ; Mon, 18 Feb 2013 20:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 HdhPnVBksE25 for ; Mon, 18 Feb 2013 20:02:13 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2085821F8B88 for ; Mon, 18 Feb 2013 20:02:12 -0800 (PST) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6BC19403CD; Mon, 18 Feb 2013 21:09:35 -0700 (MST) Message-ID: <5122F944.8020803@stpeter.im> Date: Mon, 18 Feb 2013 21:02:12 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bill Mills References: <51067C1C.2050509@ericsson.com> <51073032.1080202@e14n.com> <5107FCB0.4010402@status.net> <1359478505.19372.YahooMailNeo@web125604.mail.ne1.yahoo.com> In-Reply-To: <1359478505.19372.YahooMailNeo@web125604.mail.ne1.yahoo.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 04:02:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/29/13 9:55 AM, Bill Mills wrote: > I believe an argument against making it a urn is that urns > supposed ot be globally unique? acct: supports locka identifiers > so won't be globally unique. There was discussion about allowing local identifiers (acct:bob rather than acct:bob@example.com) but I recall no consensus to support them. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIvlDAAoJEOoGpJErxa2pt78QAK/O8JIw8NsQSBMTdigoe+O8 oq30oIyaEGcKVq74rGHWoxuFCCFuDksHLY+aFLTkhqhjPGt84ZyLQQ35eNSD6xNV qwuCPV02aQ2qtg4drtu6FkFFqXR+OGuxtsB+G1Ks2XjSpj7ZSsUrqlPq6tP0QWsQ TjqWOuXSVV3fTabs/EE2UVQ6CluOGcdH7shb6Y9M7781oFY00xWgZ8fNQS3sJ6Ja cNd/lO9Gv1yJdD88fGQupIxnLojaxgiJQ8y3/54ylMAdVI0AY0saQFwslXfJsJ2Q s4Vl8hvrQYPReYv+EG45r7capVWr2scaBHaYCJF75Kjop9jQ3pTGSLmyf/d8LF7f veA8Q1nc6S2IeKPYcLmmBCsi+AvzhF7pN/LvckxZ06Rps5EBqaCHEMepUbQy3Ii9 fe/rV8D4IL6Lw5FHK7BCVk3E2ARPq1Cu7xNZv6hg0Xj0Yq+NYM6uaS/EydmiXlaw QzkJvLcJ1LRt695jpRLTy2VVNhGm1qBto8T79oKWvNYiMQ1di6HNBK5CMmStekZQ qCcF/rdgsYNA7+CAwT5dCg9DsFY5pIoQLoOdtAGt7IIcyYzQnrHJPBA5N37+102o 0h7q397fCHryFkgJZwxd4H2h9zNmAXITmTxzcRJzVmaBJnPrknnrAo7ulSoYyWbI vNqi/U2o0JbhOD5BGZjP =2xlW -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Feb 18 20:15:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD6B21E8086 for ; Mon, 18 Feb 2013 20:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 Lxt-PYJrZUiG for ; Mon, 18 Feb 2013 20:15:31 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8483721E803A for ; Mon, 18 Feb 2013 20:15:31 -0800 (PST) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5A66A403CD; Mon, 18 Feb 2013 21:22:54 -0700 (MST) Message-ID: <5122FC63.6030801@stpeter.im> Date: Mon, 18 Feb 2013 21:15:31 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Melvin Carvalho References: <51067C1C.2050509@ericsson.com> <51073032.1080202@e14n.com> <5107FCB0.4010402@status.net> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 04:15:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/29/13 9:49 AM, Melvin Carvalho wrote: > On 29 January 2013 17:45, Evan Prodromou wrote: > >> On 13-01-28 09:13 PM, Evan Prodromou wrote: >> >> Section 3 says, in part, >> >> For example, an 'acct' URI would not be used as follows: >> >> find out more >> >> For many kinds of accounts, there are reasonable ways to resolve >> that URI and show a representation of the account in the >> browser. >> >> I believe there's been some experimental work on this with >> Webfinger in particular: >> >> http://www.open-mike.org/entry/people-in-the-address-bar-with-webfinger >> >> >> For accounts that don't support Webfinger, it's possible to do one-off >> resolution, e.g. changing a well-known domain like >> acct:evan.prodromou@facebook.com into an HTTP URL like >> https://www.facebook.com/evan.prodromou is a simple >> transformation. >> >> Given that it's *possible* to do this, and that it might even be >> *useful*, is there a reason we need to explicitly disavow it? >> >> If acct: URIs are supposed to be URN-like, maybe it would make >> more sense for "acct" to be an URN namespace, per RFC 2141. >> >> urn:acct:bob@example.com >> > > I think this question has come up a few times, without a strong > consensus, imho. > > It strikes me that acct: is slightly more appropriate as a urn than > as a 'top level' URI scheme. Well, using urn:acct:bob@example.com instead of acct:bob@example.com would pretty much discourage people from putting them in HREFs, eh? ;-) It strikes me that accounts are not good candidates for URNs, since domains can change hands, accounts can be disabled or reassigned, etc. Thus urn:acct:bob@example.com might not always identify the same Bob or the same provider of account-related services at the example.com domain. For this reason, I think that defining a URI scheme is the right way to go. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIvxiAAoJEOoGpJErxa2p10cP/2uFmnGl7LL2LNuSQ8ioc1Wa pMNBRlw/Yyas8NWAvdfZYMPQ9Bm/x0C8uiVeoaJx2inaNYa3NTGdpdROtWEHOeW9 nvYJ3kcsdY4dj/4F74xZfIy71snOjEd7ntC4pVJIDHv43/pVWNHDrrlqowUrxJ7E N5b8ka3XJH53dSBTIsV51PgvbW5epxsFNJ9qNohGWAbT39QZYlnKV2cNkyPcmVVN ImoihYDFdzzQiHnl4aXctQcNt33tHFJdQeurrKbIrK/uEy6LI7HFXRFozQ6D/Qw4 /lKC79w4nuMvGJWDw3Aso58NxnWifycCX1ChptH8/19eNG2DFm1eufohEOn0NOIj sOqH/s/dsoKx5YfSw0nqB4Lj0ND/WzLIPjtoo1UltQSE2Bq+vLdgNEBliebqOslw KBXmvp1+9+wXiPptERs8IIEESgNdb+ThLRFSEMrLSIzgBd1TW8pcg0pKvaIPDD8c eq/+kMimGv/feecq4GK6DYSupnljLoA1Py7DRle2vBnVofsB1zebxs212IObIXC/ /ViVNfz25SFQDCYPXSsnaVSJ5Lk99olvaKBhuof/Tkb3ORiSQDKNyXYdO70w5CN8 KdKxfBs4RwTWebsjnIJ62VYFn4d36akI2jO6RPXLKMd0HwyOL0c4DXNbQ5bMm4pk 5ztJev3h52FQGxLNR2EF =chF5 -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Feb 18 20:22:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB7E21E8047 for ; Mon, 18 Feb 2013 20:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 GxIL0BKFez+I for ; Mon, 18 Feb 2013 20:22:49 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8044E21E803A for ; Mon, 18 Feb 2013 20:22:49 -0800 (PST) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A5AD9403CD; Mon, 18 Feb 2013 21:30:11 -0700 (MST) Message-ID: <5122FE18.10005@stpeter.im> Date: Mon, 18 Feb 2013 21:22:48 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Evan Prodromou References: <51067C1C.2050509@ericsson.com> <51073032.1080202@e14n.com> In-Reply-To: <51073032.1080202@e14n.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 04:22:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Evan! On 1/28/13 7:13 PM, Evan Prodromou wrote: > Section 3 says, in part, > > For example, an 'acct' URI would not be used as follows: > > find out more > > For many kinds of accounts, there are reasonable ways to resolve > that URI and show a representation of the account in the browser. > > I believe there's been some experimental work on this with > Webfinger in particular: > > http://www.open-mike.org/entry/people-in-the-address-bar-with-webfinger > > For accounts that don't support Webfinger, it's possible to do > one-off resolution, e.g. changing a well-known domain like > acct:evan.prodromou@facebook.com into an HTTP URL like > https://www.facebook.com/evan.prodromou is a simple > transformation. > > Given that it's /possible/ to do this, and that it might even be > /useful/, is there a reason we need to explicitly disavow it? In the text that Dave Cridland proposed, the construction is not disavowed, but this specification does not define such behavior. If the authors of another specification wishes to do so, there's nothing to stop them. :-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIv4XAAoJEOoGpJErxa2pmEYP/RqxAHjTmebxTLPSF8ZGGkhk yHX5VhQElYNuZoLpBCohwOZfNw8KAWwOnSDua+oUFejnwbqaAdzIwzJTM1AoAZoS 0vVW0qUk925JcqHwzUj6R56DeFuGUUEPtiMxaYyCGZ5XFrNomvVBtw+HPdj/cbHP ZAnVlDIwKQwadn+07SYxQVJPDcHtvGPfRvVHZjJmSlfWWnDNVjbrE0uu0Cplj8Sc A3lzLrw5ZHSQ0eaQa6RChqn+JsJtJguFRpBhYIbpwTOpLDmAuVdoQ41shCXROAjx RXNR88bMcY6NzPrtW1CxAzU2DboknpHhyfYrIaLbULfC7p38KL9UwwdYTwLvxNzf kpStm96qqV2HDUOvggYbm5NSPWAh+VD9hMpX7i9fbaH4isTC6l5v7MdHtyG24r0L i5muNLbMp/P6jc9vH5cI4M44arzZNnO6Rm/B9YmOu9A/dSoYBs1vG5LcNdJ4vray 4XqbNjBlOToN5i9B1ZTvyMDRks4rfxcaAp7p+Zk0TrnErNBDC0DgeHoiSo+/ffvG bAuTBjnPJbaW+tKlp/dGbfGFJoZTuTEXL/cHx4gBqPldeMyMB00gWXAGeegwuxP3 fO+eurj2gGFYHgKUmkRGov6hZ7EHnKC0IAq9KqlBtjrdKvIN9Bg5uUJ+8ph3TUdf 8Ii9BF1fRte4NUsu2qKi =5Ss9 -----END PGP SIGNATURE----- From internet-drafts@ietf.org Mon Feb 18 20:38:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B35221F8D64; Mon, 18 Feb 2013 20:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 sAIXNmixB6I9; Mon, 18 Feb 2013 20:38:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9A321E804B; Mon, 18 Feb 2013 20:38:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130219043827.5142.77941.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2013 20:38:27 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-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, 19 Feb 2013 04:38:28 -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-03.txt Pages : 7 Date : 2013-02-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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-acct-uri-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jyee@afilias.info Mon Feb 18 20:40:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D93021F8D66 for ; Mon, 18 Feb 2013 20:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg5n04-ovxOk for ; Mon, 18 Feb 2013 20:40:29 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 81ED921F8D63 for ; Mon, 18 Feb 2013 20:40:28 -0800 (PST) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1U7f0E-0002fX-69 for apps-discuss@ietf.org; Tue, 19 Feb 2013 04:40:26 +0000 Received: from mail-we0-f199.google.com ([74.125.82.199]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1U7f0E-0002ZH-5h for apps-discuss@ietf.org; Tue, 19 Feb 2013 04:40:26 +0000 Received: by mail-we0-f199.google.com with SMTP id t11so7482367wey.10 for ; Mon, 18 Feb 2013 20:40:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=3SKuhKRYVdI0bOVkghqqmTvo4xMrrvWsR1VdjdiTIjo=; b=D0Ksl1RRcJKlGwoxHWitEy+5vWR78x7JjlBU2ND4GC6mFzUrYgKWnaxn2LQVZOpnJr dYvB+c4b1mxqC+v4FO9+/mYOP+3VQfs2divVQjbU4naN5KlXIPUjQ41ospo0mfoYRMjY RePHanchSqjPFqcmzYiX08kXGDJZtKkJTMA5VQbQVveH1kaSX5iAWaFK4JNI3p6uVc9h B7br0K0zSbwTWXMjtERVJvtJW4LRmrloqodlilvMZhrW+K4OW6I6mprU3X4laKw/LoPJ ILFuyhpwMKVRZmcMIuhRkWmhe4NdLQbq4i7DixapTM2WqyBKYNKCEhPmZPDqzp7xs3BW 0ZXw== X-Received: by 10.180.8.4 with SMTP id n4mr22499089wia.13.1361248820773; Mon, 18 Feb 2013 20:40:20 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.8.4 with SMTP id n4mr22499081wia.13.1361248820644; Mon, 18 Feb 2013 20:40:20 -0800 (PST) Received: by 10.216.244.13 with HTTP; Mon, 18 Feb 2013 20:40:20 -0800 (PST) In-Reply-To: <3684C634-B7B4-4DE2-82B4-CC97F00F6BB8@inria.fr> References: <3684C634-B7B4-4DE2-82B4-CC97F00F6BB8@inria.fr> Date: Mon, 18 Feb 2013 23:40:20 -0500 Message-ID: From: Joseph Yee To: Vincent Roca Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmYNFMFO9mnCXTTCeUbgZVAtIctXEFAV2AVnPlmwJ2VpxMnWwJa5wj2C71VbMmRn2yIDJKrCCWuK3lmFwFd07XVXkdakNqwgvL1QLc0afAK/wA7JwKznv5gmgUqBD/1NMFbdDF/MI07qv1jCIIWxAL1QBBY0Q== Cc: The IESG , apps-discuss@ietf.org, draft-ietf-rmt-fcast.all@tools.ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-rmt-fcast-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 04:40:30 -0000 On Wed, Feb 13, 2013 at 12:08 PM, Vincent Roca wrote: > Hello, > >> Document: draft-ietf-rmt-fcast-07 >> Title: FCAST: Scalable Object Delivery for the ALC and NORM Protocols >> Reviewer: Joseph Yee >> Review Date: 2013-01-20 >> IETF Last Call Date: 2013-01-22 >> IESG Telechat Date: 2013-01-24 >> >> Summary: This draft is almost ready for publication as Proposed Standard >> >> >> Major Issues: >> None >> >> Minor Issues: >> >> It takes me awhile to understand the document, partly I think the >> information flow is broken (another part is that I'm not familiar with >> the subject). If the principle section (Section 3) was followed by >> Implementation section (Section 5) instead, I think it will be better >> to reader. IMHO, the order of FCAST Principles -> Requirement for >> Compliant Implementation -> Security Consideration would be a better >> flow. > > This order has been changed as proposed. > >> Nits: >> None, maybe a little xml comment to ask RFC Editors to help >> reordering references based on RFC numbers :) > > Yes, using does the job. > > Cheers, > > Vincent > Nice! Joseph From cabo@tzi.org Tue Feb 19 08:39:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B7421F8DF4; Tue, 19 Feb 2013 08:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OElAZYuL1P5X; Tue, 19 Feb 2013 08:39:21 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7C121F8C17; Tue, 19 Feb 2013 08:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r1JGdCKB020547; Tue, 19 Feb 2013 17:39:12 +0100 (CET) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E31BE317C; Tue, 19 Feb 2013 17:39:11 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 19 Feb 2013 17:39:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7EB82E7A-F664-46F8-8137-83DF0C3F5536@tzi.org> References: To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] [Json] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 16:39:21 -0000 On Feb 19, 2013, at 00:47, "Joe Hildebrand (jhildebr)" = wrote: > As an individual, I'm +1 on that. I love msgpack, and don't mind the > addition of UTF8 as a separate type. Was frsyuki involved in the = draft, > or at least know that it happened? I tried to involve him. Frsyuki doesn't like what I did with the binary strings vs. UTF-8, = though. I didn't quite catch whether he is just focusing on maintaining = compatibility with what's out there (today's msgpack) or whether he = really doesn't see why that is a good idea. (For me, maintaining 100 % compatibility won't work anyway, because in = the end that won't be the only change we'll want to make. =20 If we look a bit outside the space that msgpack is being applied to = today, we might want to support, say, 16-bit floating point.) Gr=FC=DFe, Carsten From jhildebr@cisco.com Tue Feb 19 09:31:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2471C21F8E71; Tue, 19 Feb 2013 09:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7B0QLag1y+a; Tue, 19 Feb 2013 09:31:43 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3EF21F8E6E; Tue, 19 Feb 2013 09:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=330; q=dns/txt; s=iport; t=1361295103; x=1362504703; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=oAyK8c+oCDHveRYPtbpizypGerFHk5PIvI8zf+4bFzg=; b=ZSdv/hgjwJai1iJO/FTjR1Ehl6YhPZsobUYpmoZplTI+8xkhyEzIEbbl cC7G0tdJwkWkn0EEoc9WkLodFF33sSck0VvQshdGtTowJDm8v0QNKUDwk JiKRp8UV4jNvF1VP2AAcNS8ud3VP2VD4yOmSY+XAz/0fElnc+f2ch2Bcx s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAD62I1GtJV2c/2dsb2JhbABEhgK6OoEMFnOCIQEEOjQLEgEIDhQUQiUCBA4FCIgKsE2QHo5dMQeCX2EDpwODB4In X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; d="scan'208";a="178841480" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 19 Feb 2013 17:31:43 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1JHVhZn019920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 17:31:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 11:31:43 -0600 From: "Joe Hildebrand (jhildebr)" To: Carsten Bormann Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piAiBQA//+vjYCAAZAYgP//mVEA Date: Tue, 19 Feb 2013 17:31:42 +0000 Message-ID: In-Reply-To: <7EB82E7A-F664-46F8-8137-83DF0C3F5536@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.82] Content-Type: text/plain; charset="us-ascii" Content-ID: <4062FD20F3656645BBBE52B51F1407D1@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] [Json] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 17:31:44 -0000 On 2/19/13 9:39 AM, "Carsten Bormann" wrote: >If we look a bit outside the space that msgpack is being applied to >today, we might want to support, say, 16-bit floating point.) and potentially Date. If we were going to standardize this, the IETF would need full change control. --=20 Joe Hildebrand From fgaliegue@gmail.com Tue Feb 19 09:37:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCDE21F8DF2; Tue, 19 Feb 2013 09:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Ub0I6Zom5Z-O; Tue, 19 Feb 2013 09:37:24 -0800 (PST) Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id C434121F8B83; Tue, 19 Feb 2013 09:37:23 -0800 (PST) Received: by mail-ea0-f174.google.com with SMTP id 1so2937644eaa.33 for ; Tue, 19 Feb 2013 09:37:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/1050v0OHHVI6tl9cznJfv0TC0TpoWImcQlCarHffps=; b=lUTAUvaZP7EZPNVZLBnGbuqyAJhtL4Sg6/NcEqJ5NB5ESOnWLiIg37ZsqiPt1Lv9Vh 4i+B6cbSYLMFggURSO4J/u7OoX1UNdF+fvLqjulfU002iUlcNyL6qv9hy8TyDD6lOIgj zdlgsFcrP+v+3rkpiAvvsLeXrD6zL5yqXqwv+kKGYqNoCBN/YQARgxi+r31FKS2dLhUd ivzct2YUmJgAK4K14srnfy0P4BlAvs+A1zQZcpQwCdwl2WEjxoRIYH7M3+Ud565YVMwi p6JdCqa18xl+YIYhW1NzaCyrDiPewmraBVOh6NMdjO5nQgcWvZxGzzDo2pRGN5Hh0TvV lJcg== MIME-Version: 1.0 X-Received: by 10.14.183.198 with SMTP id q46mr59595060eem.1.1361295443003; Tue, 19 Feb 2013 09:37:23 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 09:37:22 -0800 (PST) In-Reply-To: References: <7EB82E7A-F664-46F8-8137-83DF0C3F5536@tzi.org> Date: Tue, 19 Feb 2013 18:37:22 +0100 Message-ID: From: Francis Galiegue To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] [Json] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 17:37:36 -0000 On Tue, Feb 19, 2013 at 6:31 PM, Joe Hildebrand (jhildebr) wrote: [...] > > and potentially Date. > > If we were going to standardize this, the IETF would need full change > control. > Another unrelated point: I see no reason why a transmitted JSON document (called a "JSON text") has to be a "container" and not any JSON value. What was the motivation behind this in the RFC in the first place? -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From mamille2@cisco.com Tue Feb 19 12:33:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E718A21F8658; Tue, 19 Feb 2013 12:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.528 X-Spam-Level: X-Spam-Status: No, score=-10.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 0QdebbXIlXkL; Tue, 19 Feb 2013 12:33:17 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E8C1621F84E9; Tue, 19 Feb 2013 12:33:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1788; q=dns/txt; s=iport; t=1361305991; x=1362515591; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Drd6s5ZvuG2mgNKfIq+jcA+UtF3Ak3ObPUOmLYvOkx0=; b=ZHqOFsC4hw26j0oog65VRrkNjEy5PvCbQgOHeULcTWK9O2d+Ww+qxgd7 3++/y7nfxdgEpq//YGw0WtKSBzoJrLasa7KoM50oHCF4OdvTcaYcOQlMq 4Ne3uuxghZyiq4fYlThs6eCi2EP0f8unMiRcA6rdf1x74wv746vNeKHjT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJ/gI1GtJXHB/2dsb2JhbABFwDuBDRZzgh8BAQEDAQEBATctBAMLBQsCAQgiFBAnCyUCBA4FCAGIAwYMsDOQJ41NgQ4CMQIFgl9hA5dIjzuDB4FyNQ X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178900590" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 19 Feb 2013 20:33:10 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1JKXAGM011800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 20:33:10 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 14:33:10 -0600 From: "Matt Miller (mamille2)" To: "Joe Hildebrand (jhildebr)" Thread-Topic: [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piCCRiA Date: Tue, 19 Feb 2013 20:33:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.55] Content-Type: text/plain; charset="us-ascii" Content-ID: <2350A2168A8B494C9EAD3849DB8EB7D6@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 20:33:19 -0000 Another topic that might worth discussing is canonicalization. It's come u= p in JOSE a couple of times[1], and it would be helpful to standardize an a= pproach. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. [1] The most recent discussing starts at < http://www.ietf.org/mail-archive= /web/jose/current/msg01575.html >, instigated by < http://www.ietf.org/mail= -archive/web/jose/current/msg01553.html > On Feb 18, 2013, at 1:01 PM, Joe Hildebrand (jhildebr) = wrote: > We're planning on doing a BoF in Orlando to discuss starting up a JSON > working group. The BoF is currently planned for Monday afternoon at 1300 > in Carribean 6. A very preliminary version of a charter can be found her= e: >=20 > http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON >=20 >=20 > But obviously we'll need to build consensus on what it should actually > contain. Please discuss on the json@ietf.org mailing list: >=20 > https://www.ietf.org/mailman/listinfo/json >=20 >=20 > As a start, we know there are a couple of things we'd like to fix about > RFC 4627: >=20 > - move to standards track > - an ABNF indentation typo in section 2.2 > - change SHOULD to MUST for the uniqueness of names in an object >=20 > A *very* important goal would be to minimize change, and to ensure strict > backward-compatibility. >=20 > There are likely adjunct JSON topics that would make sense to tackle once > we've got the experts together, but the goal would be to keep that list > short, focused, and general-purpose. >=20 > --=20 > Joe Hildebrand >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From jhildebr@cisco.com Tue Feb 19 12:47:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58A721F87E1; Tue, 19 Feb 2013 12:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU3CjMYjPTQi; Tue, 19 Feb 2013 12:47:11 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3936721F87CD; Tue, 19 Feb 2013 12:47:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=490; q=dns/txt; s=iport; t=1361306831; x=1362516431; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=4HPDbE1USdcalLQJb+v6YopTd4bfAaeS69d+gnK5vcs=; b=XIcNtLdACd1AsImR/TXVocw6RxXOekXF7aAdiCoVQLARc7CA8yYp+/n2 +PoHu7AHaUEoFx6iRH2bfN4YMm8ttPJU/MoYfLnsvk/TUigOFA4XW99Di o7N/6LqC4cdBUgCkpS+XP+obHGm0MmhMd/PyMunOjfUs8uCD942j8FooD w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAE3jI1GtJV2c/2dsb2JhbABEhgK6OYENFnOCIQEEOj8SASoUQiUCBA4FCIgKsDCQKI5dMQeCX2EDpwODB4In X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178874370" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 19 Feb 2013 20:47:10 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1JKlA4d001373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 20:47:10 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 14:47:10 -0600 From: "Joe Hildebrand (jhildebr)" To: "Matt Miller (mamille2)" Thread-Topic: Canonicalization Thread-Index: AQHODuJJD2QYqWyDNUmeQU+v/Kxthg== Date: Tue, 19 Feb 2013 20:47:09 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.82] Content-Type: text/plain; charset="us-ascii" Content-ID: <766D6830FEA94B45A46B821B238A5CF2@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: [apps-discuss] Canonicalization X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 20:47:12 -0000 On 2/19/13 1:33 PM, "Matt Miller (mamille2)" wrote: >Another topic that might worth discussing is canonicalization. It's come >up in JOSE a couple of times[1], and it would be helpful to standardize >an approach. (individual) Do you think draft-staykov-hu-json-canonical-form is a valid starting point? My biggest beef with it is that the number syntax uses capital E and JavaScript's toExponential() generates a lowercase e. --=20 Joe Hildebrand From Michael.Jones@microsoft.com Tue Feb 19 12:47:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5871D21F8806; Tue, 19 Feb 2013 12:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 hmiLsFIsQ5iy; Tue, 19 Feb 2013 12:47:34 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.26]) by ietfa.amsl.com (Postfix) with ESMTP id 860E421F87E1; Tue, 19 Feb 2013 12:47:34 -0800 (PST) Received: from BL2FFO11FD015.protection.gbl (10.173.161.202) by BL2FFO11HUB029.protection.gbl (10.173.161.53) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 19 Feb 2013 20:47:32 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD015.mail.protection.outlook.com (10.173.160.223) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 19 Feb 2013 20:47:31 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Tue, 19 Feb 2013 20:47:03 +0000 From: Mike Jones To: "Matt Miller (mamille2)" , "Joe Hildebrand (jhildebr)" Thread-Topic: [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piCCRiA//+eqLA= Date: Tue, 19 Feb 2013 20:47:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.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.74] 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:(377454001)(51704002)(13464002)(189002)(199002)(24454001)(65816001)(79102001)(53806001)(80022001)(16406001)(54316002)(56776001)(46406002)(76482001)(51856001)(50986001)(46102001)(55846006)(56816002)(4396001)(47736001)(47976001)(50466001)(49866001)(31966008)(74662001)(63696002)(54356001)(5343655001)(47446002)(15202345001)(5343635001)(66066001)(74502001)(77982001)(23726001)(44976002)(59766001)(20776003)(33656001)(47776003); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB029; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0762FFD075 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 20:47:35 -0000 I'm strongly against canonicalization. The XML canonicalization experience= was horrible and resulted in more interop bugs than any other aspect of XM= L DSIG, XML ENC, etc. Let's not repeat the mistakes of our elders. ;-) I also haven't seen a clear use case that canonicalization solves that can'= t be more easily solved another way. -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Matt Miller (mamille2) Sent: Tuesday, February 19, 2013 12:33 PM To: Joe Hildebrand (jhildebr) Cc: apps-discuss@ietf.org; json@ietf.org Subject: Re: [apps-discuss] JSON mailing list and BoF Another topic that might worth discussing is canonicalization. It's come u= p in JOSE a couple of times[1], and it would be helpful to standardize an a= pproach. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. [1] The most recent discussing starts at < http://www.ietf.org/mail-archive= /web/jose/current/msg01575.html >, instigated by < http://www.ietf.org/mail= -archive/web/jose/current/msg01553.html > On Feb 18, 2013, at 1:01 PM, Joe Hildebrand (jhildebr) = wrote: > We're planning on doing a BoF in Orlando to discuss starting up a JSON=20 > working group. The BoF is currently planned for Monday afternoon at=20 > 1300 in Carribean 6. A very preliminary version of a charter can be foun= d here: >=20 > http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON >=20 >=20 > But obviously we'll need to build consensus on what it should actually=20 > contain. Please discuss on the json@ietf.org mailing list: >=20 > https://www.ietf.org/mailman/listinfo/json >=20 >=20 > As a start, we know there are a couple of things we'd like to fix=20 > about RFC 4627: >=20 > - move to standards track > - an ABNF indentation typo in section 2.2 > - change SHOULD to MUST for the uniqueness of names in an object >=20 > A *very* important goal would be to minimize change, and to ensure=20 > strict backward-compatibility. >=20 > There are likely adjunct JSON topics that would make sense to tackle=20 > once we've got the experts together, but the goal would be to keep=20 > that list short, focused, and general-purpose. >=20 > -- > Joe Hildebrand >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From nico@cryptonector.com Tue Feb 19 12:59:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7147E21F8A4F; Tue, 19 Feb 2013 12:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.844 X-Spam-Level: X-Spam-Status: No, score=-3.844 tagged_above=-999 required=5 tests=[AWL=-1.867, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAjWqP2uaCKh; Tue, 19 Feb 2013 12:59:17 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6E65521F8A3F; Tue, 19 Feb 2013 12:59:17 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 4A439678058; Tue, 19 Feb 2013 12:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=MCPVJH1MmHDSGvrkCgbq Nklxv+s=; b=iNnOq4CKkUkrpdg3YWkaxlByFfbeTV3S7dOkCbOAWNeaElXdmAeO JPXSsWpUFN4CB57Daf2a1bCdMf1BoT7DUCo1pnc1BgGsc2DmNSTu7c4rQtWNKE3c TfAQb0eQFId+w0FNm6s9FarMeU8r6sCTRWsMSo8jqFxodFPEKNvwq6Y= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id B858267803E; Tue, 19 Feb 2013 12:59:16 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id o1so5388346wic.17 for ; Tue, 19 Feb 2013 12:59:14 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.91.106 with SMTP id cd10mr11273471wib.6.1361307554320; Tue, 19 Feb 2013 12:59:14 -0800 (PST) Received: by 10.216.254.217 with HTTP; Tue, 19 Feb 2013 12:59:14 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 14:59:14 -0600 Message-ID: From: Nico Williams To: Mike Jones Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 20:59:18 -0000 On Tue, Feb 19, 2013 at 2:47 PM, Mike Jones wrote: > I'm strongly against canonicalization. The XML canonicalization experience was horrible and resulted in more interop bugs than any other aspect of XML DSIG, XML ENC, etc. Let's not repeat the mistakes of our elders. ;-) > > I also haven't seen a clear use case that canonicalization solves that can't be more easily solved another way. But what were the mistakes? Is canonicalization in and of itself a mistake? Or were the mistakes about how to do it? I personally think that standards should avoid having to canonicalize JSON (and XML) wherever possible. The simplest way to do this is never re-encode in the process of validating signatures, for example. However, I'm not sure that we can always avoid canonicalization, or that even if we can it has no value; I could be convinced. Nico -- From jhildebr@cisco.com Tue Feb 19 13:27:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E35821F8A85; Tue, 19 Feb 2013 13:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BR3EpGrBtgKX; Tue, 19 Feb 2013 13:27:49 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 07B1B21F88D8; Tue, 19 Feb 2013 13:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=602; q=dns/txt; s=iport; t=1361309261; x=1362518861; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=yri0lOJk7ruFBiWtO6P0Us5YGh4IPZr17yp12sVTNCc=; b=SLiPXwNQPlmSInk2u3NYZ2UEEXz4Xu1Tgyb/xHLJJL3RjaKH+oux4GuA 8SHILUY9mHptowbAF6hQQsbA//FcRUq/p++oK1QjQvrxxeCfIOjuyJ9pp h/FJEaKh6jvP2xp3q2yKYQ3roaDUmL5ESdl2vdY667gqkHBpK1UnFW+L8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAOvtI1GtJV2a/2dsb2JhbABEhgK6OoENFnOCIQEEOjQLEgEIDhQUQiUCBAENBQiICrAzkCqOXTEHgl9hA6cDgweCJw X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178889060" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 19 Feb 2013 21:27:39 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1JLRdte017405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 21:27:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 15:27:38 -0600 From: "Joe Hildebrand (jhildebr)" To: Mike Jones , "Matt Miller (mamille2)" Thread-Topic: [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piCCRiA//+eqLD///s2AA== Date: Tue, 19 Feb 2013 21:27:38 +0000 Message-ID: In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.82] Content-Type: text/plain; charset="us-ascii" Content-ID: <02496F7EBBA94347B4FBD3E8780A9AC0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 21:27:59 -0000 X-List-Received-Date: Tue, 19 Feb 2013 21:27:59 -0000 On 2/19/13 1:47 PM, "Mike Jones" wrote: >I'm strongly against canonicalization. The XML canonicalization >experience was horrible and resulted in more interop bugs than any other >aspect of XML DSIG, XML ENC, etc. Let's not repeat the mistakes of our >elders. ;-) > >I also haven't seen a clear use case that canonicalization solves that >can't be more easily solved another way. I somewhat agree, but have you at least read draft-staykov-hu-json-canonical-form? It's pretty straightforward, and nowhere near as scary as xmlenc. --=20 Joe Hildebrand From jhildebr@cisco.com Tue Feb 19 13:29:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0743C21F888A; Tue, 19 Feb 2013 13:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2ONUP5TJQMl; Tue, 19 Feb 2013 13:29:02 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3AED321F8441; Tue, 19 Feb 2013 13:29:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=321; q=dns/txt; s=iport; t=1361309342; x=1362518942; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=U/u/cCmLvJA/1XnJsMcN/XlpveLxUpgCUJhZZXoVy/8=; b=la7i9cYZ1rqTUtUP88DNhPkVThwgCS2R320pO2WAI/CLeoB1W14F+u6+ yxns0uWjFiEzDVhzCzI4r42ejXFJYXXhHqL0jD+iH8SVyv7gLD0yw8MkO D+lFF/J0JlLVWNa6wCjXY2o5wkeFrRM2xXowKR1tVdNTCv9lRsVqbF2l5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAEbtI1GtJV2b/2dsb2JhbABEhgK6OoENFnOCIQEEOjQLEgEIDhQUQiUCBAENBQiICrAwkCqOXTEHgl9hA6cDgweCJw X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178893679" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 19 Feb 2013 21:29:00 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1JLT0fL014844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 21:29:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 15:29:00 -0600 From: "Joe Hildebrand (jhildebr)" To: Mike Jones , "Matt Miller (mamille2)" Thread-Topic: [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piCCRiA//+eqLD///uWgA== Date: Tue, 19 Feb 2013 21:28:59 +0000 Message-ID: In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.82] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 21:29:03 -0000 On 2/19/13 1:47 PM, "Mike Jones" wrote: >I also haven't seen a clear use case that canonicalization solves that >can't be more easily solved another way. I needed it for a light use case recently; I wanted to use a serialized object as the key into a hash. --=20 Joe Hildebrand From tbray@textuality.com Tue Feb 19 13:34:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E5421F89DC for ; Tue, 19 Feb 2013 13:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGGpYSO8P+rI for ; Tue, 19 Feb 2013 13:34:51 -0800 (PST) Received: from mail-da0-f49.google.com (mail-da0-f49.google.com [209.85.210.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0A921F89A3 for ; Tue, 19 Feb 2013 13:34:51 -0800 (PST) Received: by mail-da0-f49.google.com with SMTP id t11so3181709daj.36 for ; Tue, 19 Feb 2013 13:34:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=2lul2OGJK1NbLp9hsfqPqs21/ZvW9XphqB2bJw5K9MQ=; b=Qq56NyUBgZrD5DXRwS6jIPtYeY2iKPs+0sny2zA+On7bMwMX3hlgjwi7QCaiDSLBd4 r3QyctOQ725RoTjht16Y9spXRyvKVSr2wW05Hen+rgH9XBTrOgNKYBdX3qz3vAeON1i5 6eN6Cj6f3C4WcQ8b8qQEQcfiO4ikbhPIRFX3ezLhAU5CEHu2+5+TdizWOQg2RFAFltLm Vbt7uM2U0GdFThQ9OgyRt8pUDMKAQat+zl2QljbBrrEsOXx0CxpSvnfTBIpIjTKIbHL3 KlM0nb5gJK0juGQq4BeCeT/Ugjm+DpC3/Jh9bY+XVlMTa/DMiUyaTdDL0ts9K38AYn7F 96ag== MIME-Version: 1.0 X-Received: by 10.69.2.133 with SMTP id bo5mr44155031pbd.70.1361309691004; Tue, 19 Feb 2013 13:34:51 -0800 (PST) Received: by 10.66.249.129 with HTTP; Tue, 19 Feb 2013 13:34:50 -0800 (PST) X-Originating-IP: [172.29.161.33] In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 13:34:50 -0800 Message-ID: From: Tim Bray To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=047d7b5d8de78fc5bd04d61a9c6f X-Gm-Message-State: ALoCoQlDVIJzIyZoPCfAIKzOrUCcJ5W7yqjdIggwxh/Co9MZF/9ehBrHIB2OQo8LfJmdydlcBlpM Cc: "json@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Json] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 21:34:52 -0000 --047d7b5d8de78fc5bd04d61a9c6f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable re draft-staykov-hu-json-canonical-form: Looks sensible. One gripe: Why can=92t you sign NaN and INF? They do in fact occur in the field, and it=92s not as though a noncanonical representation is possible. -T (who still hasn=92t decided if this is actually a good idea) On Tue, Feb 19, 2013 at 1:27 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 2/19/13 1:47 PM, "Mike Jones" wrote: > > >I'm strongly against canonicalization. The XML canonicalization > >experience was horrible and resulted in more interop bugs than any other > >aspect of XML DSIG, XML ENC, etc. Let's not repeat the mistakes of our > >elders. ;-) > > > >I also haven't seen a clear use case that canonicalization solves that > >can't be more easily solved another way. > > I somewhat agree, but have you at least read > draft-staykov-hu-json-canonical-form? It's pretty straightforward, and > nowhere near as scary as xmlenc. > > -- > Joe Hildebrand > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b5d8de78fc5bd04d61a9c6f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
re draft-staykov-hu-json-canonical-form:
Looks sensibl= e. One gripe:=A0 Why can=92t you sign NaN and INF?=A0 They do in fact=A0 oc= cur in the field, and it=92s not as though a noncanonical representation is= possible.=A0

-T (who still hasn=92t decided if this is actually a good idea)


On Tue, Feb= 19, 2013 at 1:27 PM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com&g= t; wrote:
On 2/19/13 1:47 PM, "= Mike Jones" <Michael= .Jones@microsoft.com> wrote:

>I'm strongly against canonicalization. =A0The XML canonicalization<= br> >experience was horrible and resulted in more interop bugs than any othe= r
>aspect of XML DSIG, XML ENC, etc. =A0Let's not repeat the mistakes = of our
>elders. ;-)
>
>I also haven't seen a clear use case that canonicalization solves t= hat
>can't be more easily solved another way.

I somewhat agree, but have you at least read
draft-staykov-hu-json-canonical-form? =A0It's pretty straightforward, a= nd
nowhere near as scary as xmlenc.

--
Joe Hildebrand



_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--047d7b5d8de78fc5bd04d61a9c6f-- From nico@cryptonector.com Tue Feb 19 13:41:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A078E21F8A33; Tue, 19 Feb 2013 13:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.608 X-Spam-Level: X-Spam-Status: No, score=-3.608 tagged_above=-999 required=5 tests=[AWL=-1.631, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0fhK0a3fdfz; Tue, 19 Feb 2013 13:41:41 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD7621F8A0D; Tue, 19 Feb 2013 13:41:41 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 891A4594074; Tue, 19 Feb 2013 13:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=fzASUCRbln4lHgmbPZv+S3pcksA=; b=Uw6EkdwQ/Ha F6wWwzbzN78ydMFZwg/o5YYMKji+OaCG8QaolmycQox67fsf2URlnQzWFZUlXkCW WE+99QY1eX791ZwFqCbYyh+eipeDeMfmWV9i85m+QewwBZerHkcByp8L2Fn7FJax hBGICOFMPMWvkw10aqnEEmD1aHjptWuI= Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id B67DB594058; Tue, 19 Feb 2013 13:41:29 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id k14so5914958wer.25 for ; Tue, 19 Feb 2013 13:41:28 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.84.165 with SMTP id a5mr30482493wiz.6.1361310087977; Tue, 19 Feb 2013 13:41:27 -0800 (PST) Received: by 10.216.254.217 with HTTP; Tue, 19 Feb 2013 13:41:27 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 15:41:27 -0600 Message-ID: From: Nico Williams To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "json@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Json] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 21:41:41 -0000 On Tue, Feb 19, 2013 at 3:27 PM, Joe Hildebrand (jhildebr) wrote: > I somewhat agree, but have you at least read > draft-staykov-hu-json-canonical-form? It's pretty straightforward, and > nowhere near as scary as xmlenc. Indeed. Lexicographic sorting... makes me wonder about Unicode normalization. Before your heads explode, what is the ECMAScript rule regarding normalization of object keys? Are the two normalization forms of 'fo=C3=B3' allowed as distinct keys in an object? Nico -- From mamille2@cisco.com Tue Feb 19 13:42:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C9A21E8050; Tue, 19 Feb 2013 13:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.543 X-Spam-Level: X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 5TyRTKBxiZeo; Tue, 19 Feb 2013 13:42:17 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 799D321E803A; Tue, 19 Feb 2013 13:42:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1273; q=dns/txt; s=iport; t=1361310137; x=1362519737; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BDdK+KgOT9Z79uRebWEnsYWeE+8o15OnEUMNb5MPu+Y=; b=R9HqbXlx94NZNdmObehROXY22r3Z3aAgz0Hbd48ltvY6m4xMMw+bM/VS aogikTGdF6xA4jWZ11eU6S/0lsEnI9hytoBRw1Uu3/DPTQ41K2qGK8yiF Uc51SXWRqxBsDXt39GSM71JFTy4PU63bm713ufsWjYKMCmgm9msF9dw6A U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKPwI1GtJXG+/2dsb2JhbABEwDyBDRZzgh8BAQEDATo/BQsCAQgYChQQMiUCBA4FCIgEBrA0kCiOWwIxB4JfYQOnA4MHgic X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="175901333" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 19 Feb 2013 21:42:17 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1JLgGld007668 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 21:42:16 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 15:42:16 -0600 From: "Matt Miller (mamille2)" To: "Joe Hildebrand (jhildebr)" Thread-Topic: Canonicalization Thread-Index: AQHODuJJdWjMn+WyCECfYKD2BiK4E5iCGsgA Date: Tue, 19 Feb 2013 21:42:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.55] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] Canonicalization X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 21:42:18 -0000 On Feb 19, 2013, at 1:47 PM, Joe Hildebrand (jhildebr) = wrote: > On 2/19/13 1:33 PM, "Matt Miller (mamille2)" wrote: >=20 >> Another topic that might worth discussing is canonicalization. It's com= e >> up in JOSE a couple of times[1], and it would be helpful to standardize >> an approach. >=20 > (individual) >=20 > Do you think draft-staykov-hu-json-canonical-form is a valid starting > point? My biggest beef with it is that the number syntax uses capital E > and JavaScript's toExponential() generates a lowercase e. >=20 Assuming I think canonicalization is something that ought to be done, I thi= nk it is a decent start that needs to be expanded. The first thing that ca= me to my mind is string normalization, and how that relates to escape seque= nces. However, while not as violently opposed as some, I am hesitant. XML canoni= calization has bitten me hard in the past, so I am carrying a bias into thi= s conversation. Maybe a starting point can be "don't rely on canonicalizat= ion unless you really really really have to," and we can come up with a set= of those "really really really have to" scenarios. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. From tbray@textuality.com Tue Feb 19 13:53:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F28421E8050 for ; Tue, 19 Feb 2013 13:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDzGSr3aSZvk for ; Tue, 19 Feb 2013 13:53:07 -0800 (PST) Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7D47021F87E4 for ; Tue, 19 Feb 2013 13:53:07 -0800 (PST) Received: by mail-da0-f50.google.com with SMTP id h15so3162343dan.23 for ; Tue, 19 Feb 2013 13:53:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=si8j9K6NlZL9nwEaXz0myQj409qMk750tzLqXnyISi8=; b=nQ+q+6XYIuViwtRoa0VN+LqAQYJDnfTI/if96YD0I2f2SdwvB6Q10Z2Kmkp49wigwm lPRn9jWlo/K16nhKRRqlVU65xkNV4Pp2es/Xy/RU0H2bhJOGDCbm843GkirY+REjFSKk kIqSbeXaGDuAj/LvlaF89whFlZle8xtSIstBZvl1qhuH/8LVG77a7yf7bciYJVFTi746 iCVRfPss9VwCzhh6ckrETmRKkytu2Owj0MjW9Cw5ugn3aLWUj4lIHOHyq4vQKw7RKYoa ODHeG+n0o7xCXwijQ8wUnKpaux9d+qMSHnf30A+BAY62jTmJaXWSYeuYV8wyRdYFSD0i YtoA== MIME-Version: 1.0 X-Received: by 10.68.129.41 with SMTP id nt9mr13469815pbb.20.1361310787196; Tue, 19 Feb 2013 13:53:07 -0800 (PST) Received: by 10.66.249.129 with HTTP; Tue, 19 Feb 2013 13:53:07 -0800 (PST) X-Originating-IP: [172.29.161.33] In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 13:53:07 -0800 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=047d7b10cfe9e6585b04d61add00 X-Gm-Message-State: ALoCoQk5yOezSRrXEkt+lKhlGTSDTvAEIkLzSLwBigYRQZn+YIAwmVZld2m5LXYsaFYlCqfGkfOe Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] [Json] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 21:53:09 -0000 --047d7b10cfe9e6585b04d61add00 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would argue that normalization should be out of scope. I.e. the two forms of =93fo=F3=94 are different strings, that=92s all. =93Doctor! It hurts when I do this!=94 =93So, don=92t do that!=94 -T On Tue, Feb 19, 2013 at 1:41 PM, Nico Williams wrote= : > On Tue, Feb 19, 2013 at 3:27 PM, Joe Hildebrand (jhildebr) > wrote: > > I somewhat agree, but have you at least read > > draft-staykov-hu-json-canonical-form? It's pretty straightforward, and > > nowhere near as scary as xmlenc. > > Indeed. > > Lexicographic sorting... makes me wonder about Unicode normalization. > Before your heads explode, what is the ECMAScript rule regarding > normalization of object keys? Are the two normalization forms of > 'fo=F3' allowed as distinct keys in an object? > > Nico > -- > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b10cfe9e6585b04d61add00 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I would argue that normalization should be out o= f scope.=A0 I.e. the two forms of =93fo=F3=94 are different strings, that= =92s all.=A0
=93Doctor! It hurts when I do this!=94
=93S= o, don=92t do that!=94

-T


On Tue, Feb 19, 2013 at 1:41 PM, Nico Williams <nico@cryptonector.c= om> wrote:
On Tue, Feb 19, 2013 at 3:= 27 PM, Joe Hildebrand (jhildebr)
<jhildebr@cisco.com> wrote:=
> I somewhat agree, but have you at least read
> draft-staykov-hu-json-canonical-form? =A0It's pretty straightforwa= rd, and
> nowhere near as scary as xmlenc.

Indeed.

Lexicographic sorting... makes me wonder about Unicode normalization.
Before your heads explode, what is the ECMAScript rule regarding
normalization of object keys? =A0Are the two normalization forms of
'fo=F3' allowed as distinct keys in an object?

Nico
--
___________________________________= ____________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--047d7b10cfe9e6585b04d61add00-- From jhildebr@cisco.com Tue Feb 19 13:55:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C0F21E80AF; Tue, 19 Feb 2013 13:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOCyfdSDp2ay; Tue, 19 Feb 2013 13:55:38 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EE3D821E80A7; Tue, 19 Feb 2013 13:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=375; q=dns/txt; s=iport; t=1361310938; x=1362520538; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=i1QO1aOHT6ABx280Phy+T5AmEQcoZMG8wUAl+to5p68=; b=Uuo5kUUKGz6doF5VK47mG9+ZGG0ZtnJqC3LIL/THVIE7fIbH85goYwl/ gwfeljOOFVUlRC6Ff4RfeGpXeoLXCUsnZ3Y4LqzRV02aI1lKYNjB+nScC iXfBFfEIE27soZCUIBLeehilrlgMjU8JnHHH3FXbsLnYn6rT8colN1wpu U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAOjzI1GtJXG8/2dsb2JhbABFhgK6P4ENFnOCIQEEbgsSAQgOFFYlAgQOBQiICrAlkCuOXTEHgl9hA4gwnlODB4In X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178877746" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 19 Feb 2013 21:55:37 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1JLtbxT022768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 21:55:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 15:55:37 -0600 From: "Joe Hildebrand (jhildebr)" To: Tim Bray Thread-Topic: [Json] [apps-discuss] JSON mailing list and BoF Thread-Index: AQHODhKwsPxTte9Ry0KhDmvQvHsA3piCCRiA//+eqLD///s2AIAAd14A//+Qc4A= Date: Tue, 19 Feb 2013 21:55:37 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Json] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 21:55:40 -0000 On 2/19/13 2:34 PM, "Tim Bray" wrote: >re draft-staykov-hu-json-canonical-form: >Looks sensible. One gripe: Why can=B9t you sign NaN and INF? They do in >fact occur in the field, and it=B9s not as though a noncanonical >representation is possible. I can figure out how to generate a -INF, but how do I get a -NaN? --=20 Joe Hildebrand From paul.hoffman@vpnc.org Tue Feb 19 13:59:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D23E21F886A; Tue, 19 Feb 2013 13:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 vnLruYV3TKq9; Tue, 19 Feb 2013 13:59:53 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id ECB4021F8815; Tue, 19 Feb 2013 13:59:52 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1JLxgKi050999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Feb 2013 14:59:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Tue, 19 Feb 2013 13:59:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "apps-discuss@ietf.org Discuss" X-Mailer: Apple Mail (2.1499) Cc: json@ietf.org Subject: [apps-discuss] Two lists? [ Was: JSON mailing list and BoF ] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 21:59:53 -0000 The JSON list seems active already. Do we need to have this thread on = both lists? --Paul Hoffman= From nico@cryptonector.com Tue Feb 19 13:59:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F40321F8860; Tue, 19 Feb 2013 13:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=-1.599, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJ1zhNtUAwFv; Tue, 19 Feb 2013 13:59:58 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id B01D821F86D9; Tue, 19 Feb 2013 13:59:58 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 87FFA264070; Tue, 19 Feb 2013 13:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=mUVBvabPMNh0eWa04xPiffKWJoU=; b=yVroJ6bZHpA iP9oicyRqIAnMLMc0Lbbktg3BESq+5VdEh20jZCJTqXpwAUXXyHG+Iqz84gBjIaf zDMMkBVtZic7M597HbFgBjw6XYBpaiYfDXrCwR8agD8OqIbdnjm/m1WuI4ATrSxa U4KrPiFS7fFBz+9iHbpunXi+NfJHALIM= Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 0A36B26406C; Tue, 19 Feb 2013 13:59:57 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id e12so5775892wge.34 for ; Tue, 19 Feb 2013 13:59:56 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.108.229 with SMTP id hn5mr26777017wib.28.1361311196718; Tue, 19 Feb 2013 13:59:56 -0800 (PST) Received: by 10.216.254.217 with HTTP; Tue, 19 Feb 2013 13:59:56 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 15:59:56 -0600 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] [Json] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 21:59:59 -0000 On Tue, Feb 19, 2013 at 3:53 PM, Tim Bray wrote: > I would argue that normalization should be out of scope. I.e. the two fo= rms > of =E2=80=9Cfo=C3=B3=E2=80=9D are different strings, that=E2=80=99s all. > =E2=80=9CDoctor! It hurts when I do this!=E2=80=9D > =E2=80=9CSo, don=E2=80=99t do that!=E2=80=9D That's fair. In that case this I-D looks simple enough that I can't really oppose it. I do think we should give advice as to how to avoid the need for canonicalization (c14n?) in the first place. From fgaliegue@gmail.com Tue Feb 19 14:01:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D8721F886E; Tue, 19 Feb 2013 14:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWKEIfthpcY3; Tue, 19 Feb 2013 14:01:02 -0800 (PST) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id D4CEF21F8815; Tue, 19 Feb 2013 14:01:00 -0800 (PST) Received: by mail-ee0-f52.google.com with SMTP id b15so3553970eek.39 for ; Tue, 19 Feb 2013 14:00:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=zGELp6lsnoCSPuD8g287CwcwiFLU02sMbgnW3NuRK1s=; b=B7NtJQCf+VmqwsDqUEa4BMSoVF5L3PSQ+iqY7Mr6BX2JY8XY5H3YpJdPqPqS6ZYC50 0KLQSWMXNQ8R0L0so1kkKIiQV/qpd0Hbu+CI6p7Oxq1bOrEr7gt+oz3JwThByiXIBQ5h J3M+sc03GOP9b4zHOaA+Nv3JE1lNsBbVSQ74CVK6GP348F5KHj8dBS2wanV+1od+9Q45 7TNQEd5+OyuQthmKCm9Sxm2BVWxLCOKWX6ZT25NTMFTRNaiG2uS6grSOGTxPVKNJ4Pan VEMmSVTKytWB5Vr0S86UiNIOmsDh0ZHzaSl3jgxrTtwFFP4g4jB/EYkgwzYa8C2wwdk9 pLuw== MIME-Version: 1.0 X-Received: by 10.14.193.134 with SMTP id k6mr61462837een.37.1361311259738; Tue, 19 Feb 2013 14:00:59 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 14:00:59 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 23:00:59 +0100 Message-ID: From: Francis Galiegue To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] [Json] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 22:01:04 -0000 On Tue, Feb 19, 2013 at 10:53 PM, Tim Bray wrote: > I would argue that normalization should be out of scope. I.e. the two fo= rms > of =E2=80=9Cfo=C3=B3=E2=80=9D are different strings, that=E2=80=99s all. > =E2=80=9CDoctor! It hurts when I do this!=E2=80=9D > =E2=80=9CSo, don=E2=80=99t do that!=E2=80=9D > (as a not very well educated individual on this matter...) If _that_ is what normalization is about, then I strongly condemn it being even a subject at all. The current RFC does a pretty good job at defining what a JSON String can be, fabricating some sort of injective function so that one JSON value is equal to another is sick. OK, I say that, but on the other hand, JSON Schema mandates that JSON values "1.0" and "1" be considered equal for numeric validation. This could also be viewed as a form of normalization... --=20 Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From nico@cryptonector.com Tue Feb 19 14:01:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0559721E808F; Tue, 19 Feb 2013 14:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=-1.569, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQOVUxPXY-Cq; Tue, 19 Feb 2013 14:01:16 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 00B0121E80B2; Tue, 19 Feb 2013 14:01:11 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 4A4AF2F4060; Tue, 19 Feb 2013 14:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=UYXt5Qle53zlHLK4EABgUfQ5BkI=; b=r7xHOVGz1da E1tNcbJ3bh1NK3AaypAmwhaBbCQay4pNaeee8//fyPLqffihrwq56/hefBlSu2rX D9j6oMSR8uuprMDpUgUdgD0J2H/YTAcKiUUluwzcVR/yQZmoyicWPTQdd90nT2gm phurjTwnHU7CTmbEH2w0m5YQp3mFD0Lg= Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id A3DB12F406A; Tue, 19 Feb 2013 14:01:10 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fm10so5803688wgb.21 for ; Tue, 19 Feb 2013 14:01:09 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.81.42 with SMTP id w10mr18986262wix.28.1361311269349; Tue, 19 Feb 2013 14:01:09 -0800 (PST) Received: by 10.216.254.217 with HTTP; Tue, 19 Feb 2013 14:01:09 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Feb 2013 16:01:09 -0600 Message-ID: From: Nico Williams To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] [Json] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 22:01:20 -0000 On Tue, Feb 19, 2013 at 3:55 PM, Joe Hildebrand (jhildebr) wrote: > On 2/19/13 2:34 PM, "Tim Bray" wrote: > >>re draft-staykov-hu-json-canonical-form: >>Looks sensible. One gripe: Why can=C2=B9t you sign NaN and INF? They do= in >>fact occur in the field, and it=C2=B9s not as though a noncanonical >>representation is possible. > > I can figure out how to generate a -INF, but how do I get a -NaN? In JS? 1/0 -> INF, 0/0 -> NaN. From stpeter@stpeter.im Tue Feb 19 14:02:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B37B21F8855 for ; Tue, 19 Feb 2013 14:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 Z4ceA+paryJL for ; Tue, 19 Feb 2013 14:02:15 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5395D21E80C4 for ; Tue, 19 Feb 2013 14:02:02 -0800 (PST) Received: from [10.0.0.2] (unknown [24.9.182.250]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8484D4004E; Tue, 19 Feb 2013 15:09:27 -0700 (MST) Message-ID: <5123F653.5010905@stpeter.im> Date: Tue, 19 Feb 2013 15:01:55 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Two lists? [ Was: JSON mailing list and BoF ] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 22:02:19 -0000 On 2/19/13 2:59 PM, Paul Hoffman wrote: > The JSON list seems active already. Do we need to have this thread on both lists? Please not. Let's just chat on the json@ list. See you there! ;-) /psa From fgaliegue@gmail.com Tue Feb 19 14:05:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046FD21F89A3; Tue, 19 Feb 2013 14:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTH1PPTN1j-Z; Tue, 19 Feb 2013 14:05:14 -0800 (PST) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 825AB21F8815; Tue, 19 Feb 2013 14:05:09 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id b47so3660830eek.15 for ; Tue, 19 Feb 2013 14:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VmMPrUWxsrfSadz5WAqK0wpjSPpMA1JMlS81TlqR5/A=; b=fDrsKXz9oJ6kgjsOzt6/REW23pppl50TbMhVExO19b3WLqNEFHFWy2fNQuatJnR/yo hlFmwS2+rDWxU2Dg2kC2LQA0dANtn9tDgPynSq/I2/hMQdAlsCv+65Hidhi16nGxE0Hz AHO/VxsI7jUpDsmkZsveeM4AKrE9ZEv0b7D5NxK5Bu3wdc9zaO+jJzwjcXJRbjK8Oxfo h5AhIEzXsYlbeSgFJrdCZfOxOaCMCL+aTOwhWkDipn9gd8sr9iC8OVBA1b+eGyyFKF/i 5SLgcSafZj6epDiw3XZvqWK7TqFvQ/K9pwr7+QdNa5BUtpz7yiQSmcQjDMnVrZR4KRJh x6Hg== MIME-Version: 1.0 X-Received: by 10.14.183.198 with SMTP id q46mr61937203eem.1.1361311508874; Tue, 19 Feb 2013 14:05:08 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 14:05:08 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Feb 2013 23:05:08 +0100 Message-ID: From: Francis Galiegue To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] [Json] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 22:05:15 -0000 On Tue, Feb 19, 2013 at 10:55 PM, Joe Hildebrand (jhildebr) wrote: [...] > > I can figure out how to generate a -INF, but how do I get a -NaN? > The current JSON specification doesn't mandate any limit to the precision and/or scale of numeric instances, and I was particularly attentive to this aspect of JSON when writing the JSON Schema specs, since my first use case for using JSON Schema was the ability to use keywords such as "minimum", "maximum", "multipleOf" to validate arbitrary numerical JSON instances. The JSON Schema validation specs (OK, these are my words) says this: http://tools.ietf.org/html/draft-fge-json-schema-validation-00#section-3.2 I _do believe that JSON itself should not define NaN. JSON can express arbitrary data and should not care about the capabilities of language A or B in a transacation. Only recommendations and/or warnings can be given at that point. -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From nico@cryptonector.com Tue Feb 19 14:07:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE9121F886E; Tue, 19 Feb 2013 14:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.81 X-Spam-Level: X-Spam-Status: No, score=-3.81 tagged_above=-999 required=5 tests=[AWL=-1.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zL6eSlkm8CUU; Tue, 19 Feb 2013 14:07:28 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id A38F421F8815; Tue, 19 Feb 2013 14:07:28 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id A6CB56B007B; Tue, 19 Feb 2013 14:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=bEdPwENzm+I+yWoAWYFXxwU1Sf4=; b=jKM0ic5cuQb iZWEKRHjsGtw6JeyTJiZ8AgmT6JQcfH8Z4MqTnb754XKo68f8Fsatr+QGcd6mOVo b6lsiyqWcdumSj/Kxg1BOtdW6PCgbJ5QlD4atajWNn5JQJas59p0M7vu+Sesaoou oWBPvvQNHJAdRr0/jnvf7ZB8ZHGS0gAo= Received: from mail-ia0-f174.google.com (mail-ia0-f174.google.com [209.85.210.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 780F86B0059; Tue, 19 Feb 2013 14:07:27 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id u20so2453537iag.33 for ; Tue, 19 Feb 2013 14:07:26 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.43.62.12 with SMTP id wy12mr8278870icb.19.1361311646933; Tue, 19 Feb 2013 14:07:26 -0800 (PST) Received: by 10.64.102.201 with HTTP; Tue, 19 Feb 2013 14:07:26 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 16:07:26 -0600 Message-ID: From: Nico Williams To: Francis Galiegue Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] [Json] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 22:07:29 -0000 On Tue, Feb 19, 2013 at 4:00 PM, Francis Galiegue wro= te: > On Tue, Feb 19, 2013 at 10:53 PM, Tim Bray wrote: >> I would argue that normalization should be out of scope. I.e. the two f= orms >> of =E2=80=9Cfo=C3=B3=E2=80=9D are different strings, that=E2=80=99s all. >> =E2=80=9CDoctor! It hurts when I do this!=E2=80=9D >> =E2=80=9CSo, don=E2=80=99t do that!=E2=80=9D >> > > (as a not very well educated individual on this matter...) > > If _that_ is what normalization is about, then I strongly condemn it > being even a subject at all. > > The current RFC does a pretty good job at defining what a JSON String > can be, fabricating some sort of injective function so that one JSON > value is equal to another is sick. Oh, well, the RFC (4627) says nothing about normalization. And if you think the notion is sick wait till you hear the details! But as you read what you find when you search for "Unicode normalization" you should keep one thing in mind: this sickness isn't Unicode's fault -- it's our (humans', that is) fault. > OK, I say that, but on the other hand, JSON Schema mandates that JSON > values "1.0" and "1" be considered equal for numeric validation. This > could also be viewed as a form of normalization... Indeed. Nico -- From jhildebr@cisco.com Tue Feb 19 14:18:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBF221F87B9; Tue, 19 Feb 2013 14:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhdtVEGIKWxK; Tue, 19 Feb 2013 14:18:18 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DCD0621F86EC; Tue, 19 Feb 2013 14:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=299; q=dns/txt; s=iport; t=1361312298; x=1362521898; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=zA1IV8T/1lkeyUo/0P189ZZHkbTZD/2Bp0xJCYbBoy8=; b=lcZvml3RHf8NN6vmBdwOcTEm5a/9xZckSEiT4cortLtTOFQw47ePr2XU j7+EenLTIvIFjegr8oAZlOCrvD5PizQkxzg7wCZ2oJYn8mwJ3pEAMuxRo FpCiCurTbLDv+FHErNFiNUG7Ixu3MYvdKoEH6fEUlvOqaGx2/iHXiiQ41 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAFL4I1GtJXG9/2dsb2JhbABFhgK6QIENFnOCIQEEOjQLEgEIIhRCJQIEAQ0FCIgKsDGQJY5dMQeCX2EDpwODB4In X-IronPort-AV: E=Sophos;i="4.84,697,1355097600"; d="scan'208";a="178907984" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 19 Feb 2013 22:18:15 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1JMIFgE028055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 22:18:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 16:18:15 -0600 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman , "apps-discuss@ietf.org Discuss" Thread-Topic: [apps-discuss] Two lists? [ Was: JSON mailing list and BoF ] Thread-Index: AQHODux01Q87ih+JTEmWhe6ECK8cy5iBr2eA Date: Tue, 19 Feb 2013 22:18:14 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <43ABB84C2B6F5D42A04219BF79E0AB90@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [apps-discuss] Two lists? [ Was: JSON mailing list and BoF ] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 22:18:19 -0000 On 2/19/13 2:59 PM, "Paul Hoffman" wrote: >The JSON list seems active already. Do we need to have this thread on >both lists? Nope. After this message, I'll start pruning and re-directing, since I think we've got a quorum on the json list. --=20 Joe Hildebrand From fgaliegue@gmail.com Tue Feb 19 14:20:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE8321F88BC; Tue, 19 Feb 2013 14:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuaCHwbuNoEl; Tue, 19 Feb 2013 14:20:11 -0800 (PST) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB2821F8860; Tue, 19 Feb 2013 14:20:11 -0800 (PST) Received: by mail-ea0-f176.google.com with SMTP id a13so3072123eaa.7 for ; Tue, 19 Feb 2013 14:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=biFVXEYynVlzkyxybflbdPYzP34rC82Vi0NBWr/vygo=; b=eaueSO40OasDQC+3svhOVHv1kayOq3jWQmRe3zahF8XSFxz/o6k1UgQ5ERBTfpzuAl bhBGCjjszWWtlGVpYfbXLFRecn7ATclQgBBxojFm2tvyn5bji1ZlNOHpq5+TfjopOXHf zzGZeA52RtC80uiLfH49f61hlBA/R8Zd6xohC6Q9fXCLdg8XNzHoBzgZ2u/DgyvUHkaA W0XhlMMl9tLXJ8xiWr+8qZeZqvK1TOK02PckTgmLorA1k/TtKq/ara3rXfOh2vaUuPRR /ngyYWZeNSwDa/VAGh2MAOCKOGylZTVH7W3yxIQc/1AYpP69cD7ijVdJnB2UPR7CD9KJ Szfw== MIME-Version: 1.0 X-Received: by 10.14.209.131 with SMTP id s3mr61292462eeo.26.1361312410625; Tue, 19 Feb 2013 14:20:10 -0800 (PST) Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 14:20:10 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 19 Feb 2013 23:20:10 +0100 Message-ID: From: Francis Galiegue To: Nico Williams Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [apps-discuss] [Json] JSON mailing list and BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 22:20:12 -0000 On Tue, Feb 19, 2013 at 11:07 PM, Nico Williams wrote: [...] > >> OK, I say that, but on the other hand, JSON Schema mandates that JSON >> values "1.0" and "1" be considered equal for numeric validation. This >> could also be viewed as a form of normalization... > > Indeed. > Note however that JSON Schema is not the only I-D in that case. JSON Patch says this too (http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10#section-4.6). -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From sm@elandsys.com Tue Feb 19 14:24:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C3521F8ABA for ; Tue, 19 Feb 2013 14:24:23 -0800 (PST) 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 Xka647ik-XEG for ; Tue, 19 Feb 2013 14:24:22 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD6721F8A99 for ; Tue, 19 Feb 2013 14:24:21 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.137.73]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1JMO2BR023492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2013 14:24:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1361312654; bh=4IRT4Ep0DW3gxbVD/7Sk8/Xb73KOIyvjv3+o4Y6aoGQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jrKUieFtssIgsq5EE2d/upH3Mcxm0arPJ2iiEvbEhJZokAt+fWcF0oe3xU7UQ1dho AOvhFvqcnNontuVJiFmPwQAlDdRs0QINTD/2tlgD3zjzkVt8rYYuxhYcET6hAVxaiE RV6xExxFPiUgsd8oqf6+F3LI9ghA641/Vxh9UlEE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1361312654; i=@elandsys.com; bh=4IRT4Ep0DW3gxbVD/7Sk8/Xb73KOIyvjv3+o4Y6aoGQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=32CsrSprHdd1utomVRh+yobu/8o2jzOKW5ERoGTH/J/NYwWi09G0vBC02m6zH0YRO xRFEQerO2CVHfz1U04x4uJJfNOib86kUUDwFzXp6k2rzGSgXIYf7OFnvqmy7L2LDga 2pjlPMrgFsZMtQ11Z6TlpA2QwAdkgZu6S8rY8v4M= Message-Id: <6.2.5.6.2.20130219141323.09e8bbf0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 19 Feb 2013 14:23:34 -0800 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367477490@TK5EX14MBXC284.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] JSON mailing list and BoF (off-topic) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 22:24:23 -0000 Hello, There is a mailing list at https://www.ietf.org/mailman/listinfo/json to discuss about the JSON BoF. I suggest moving the discussion about JSON to the JSON mailing list. Please do not copy the messages to apps-discuss@ietf.org. Thanks, S. Moonesamy From dret@berkeley.edu Wed Feb 20 06:09:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEED721F8810 for ; Wed, 20 Feb 2013 06:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOPueUJuCZIa for ; Wed, 20 Feb 2013 06:09:03 -0800 (PST) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA3421F872C for ; Wed, 20 Feb 2013 06:09:03 -0800 (PST) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretpro.local) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1U8AM0-0001da-5b; Wed, 20 Feb 2013 06:09:02 -0800 Message-ID: <5124D8F7.5080408@berkeley.edu> Date: Wed, 20 Feb 2013 15:08:55 +0100 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" References: <20130220134257.14795.68954.idtracker@ietfa.amsl.com> In-Reply-To: <20130220134257.14795.68954.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130220134257.14795.68954.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: REST-Discuss Subject: [apps-discuss] Fwd: New Version Notification for draft-wilde-xml-patch-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 14:09:03 -0000 hello. draft-wilde-xml-patch is ready for last call by now, apart from questions about how to best deal with dependencies with an underlying RFC (5261) and errata for it, which i will address in a separate email. since i believe this draft is ready for publication, and this is an independent submission, if i recall correctly the next step is to find a sponsor for this draft. i'd be grateful if somebody would be willing to take on this role. thanks and cheers, dret. -------- Original Message -------- Subject: New Version Notification for draft-wilde-xml-patch-03.txt Date: Wed, 20 Feb 2013 05:42:57 -0800 From: internet-drafts@ietf.org A new version of I-D, draft-wilde-xml-patch-03.txt has been successfully submitted by Erik Wilde and posted to the IETF repository. Filename: draft-wilde-xml-patch Revision: 03 Title: A Media Type for XML Patch Operations Creation date: 2013-02-20 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-wilde-xml-patch-03.txt Status: http://datatracker.ietf.org/doc/draft-wilde-xml-patch Htmlized: http://tools.ietf.org/html/draft-wilde-xml-patch-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-wilde-xml-patch-03 Abstract: The XML Patch media type "application/xml-patch+xml" defines an XML document structure for expressing a sequence of patch operations that are applied to an XML document. The XML Patch document format's foundations are defined in RFC 5261, this specification defines a document format and a media type registration, so that XML Patch documents can be labeled with a media type, for example in HTTP conversations. Note to Readers This draft should be discussed on the apps-discuss mailing list [14]. Online access to all versions and files is available on github [15]. From dret@berkeley.edu Wed Feb 20 06:09:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E20C21F8833 for ; Wed, 20 Feb 2013 06:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgZpvM0+i0NI for ; Wed, 20 Feb 2013 06:09:39 -0800 (PST) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id C439021F883A for ; Wed, 20 Feb 2013 06:09:38 -0800 (PST) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretpro.local) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1U8AMb-0000Sk-Ha; Wed, 20 Feb 2013 06:09:38 -0800 Message-ID: <5124D91C.1000703@berkeley.edu> Date: Wed, 20 Feb 2013 15:09:32 +0100 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] process and editing questions: RFC errata X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Feb 2013 14:09:42 -0000 hello. i have two process and editing questions: http://tools.ietf.org/html/draft-wilde-xml-patch-03#section-6 specifically links to errata i have filed regarding RFC 5261. it seems to me that these errata are legitimate, and that they simply weren't caught earlier. draft-wilde-xml-patch is almost complete, and i am wondering about the following things: - how to best sync draft development, and the submitted errata. there seems to be no way to predict when and how errata are processed, in particular for RFC 5261 because the author seems to be unreachable. - if the errata are accepted, how to reference them in the draft. it would be important that people following references to RFC 5261 from the draft do not just read the RFC, but also take the errata into account when implementing the spec. thanks a lot 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 stpeter@stpeter.im Wed Feb 20 12:01:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD7421F87E4 for ; Wed, 20 Feb 2013 12:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 A9ycpUyBEwuo for ; Wed, 20 Feb 2013 12:01:50 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2D55921F8798 for ; Wed, 20 Feb 2013 12:01:50 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2A7024067B for ; Wed, 20 Feb 2013 13:09:18 -0700 (MST) Message-ID: <51252BAC.9010805@stpeter.im> Date: Wed, 20 Feb 2013 13:01:48 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <51252B7E.1010108@stpeter.im> In-Reply-To: <51252B7E.1010108@stpeter.im> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <51252B7E.1010108@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Fwd: [Aggsrv] Aggregated Service Discovery BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Feb 2013 20:01:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. Please provide feedback on the aggsrv@ietf.org list. Peter - -------- Original Message -------- Subject: [Aggsrv] Aggregated Service Discovery BoF Date: Wed, 20 Feb 2013 13:01:02 -0700 From: Peter Saint-Andre To: aggsrv@ietf.org Folks, There will be a BoF in Orlando on the topic of aggregated service discovery, focusing on the problem of how clients can discover both application servers and configuration information for multiple protocols at once. The intent is to form a relatively short-lived, single-purpose working group. You can read more here: http://trac.tools.ietf.org/wg/appsawg/trac/wiki/AggSrv https://datatracker.ietf.org/doc/draft-daboo-aggregated-service-discovery/ A dedicated email list has been established: https://www.ietf.org/mailman/listinfo/aggsrv Your feedback is welcome! Peter _______________________________________________ aggsrv mailing list aggsrv@ietf.org https://www.ietf.org/mailman/listinfo/aggsrv -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJSusAAoJEOoGpJErxa2pxaQQAJeCfoIh8Hoazrh8LdlBXe3J SV8MeZeJFkQADOS5EydDgQ8hvP4qKmwlxmLlWyHUSW61O7lKllMDee7jeReNOdGH UVRdtgU9HxNz4FSzdm706xJBNoqvr5Hcc8w2vic6SLJ71msosv0rX/PmGavB3nQ+ gRolqTB+x4xsdddqW8i+DSxRGEwwlj0j/TH2QDYiobEuktvA1aLhtcop7P1RxYgV Uc7RDjNGNNRFwDH9hwrgaA0Gxg65gUkEQqlARoAvMZv354XS7JbFE16KLppdARL2 Ka9RDDmPJ3gX28xYoJ+jOrIqJUXRPPXjKwA3WX/c2e1Um0g9h3qTSDxoc8AchSdX 9sPFPvZ3Pl1jQ08dYwVPQcAPVy/P/txNfUSfB9kD49oCSGg4yaPM55h/SppaeokL N/N87nB9FdlBj8U3CQW3+K596WnMh0UMOBpS5e9fUFV32fz/HDMM11n2ej5DgpVO X5BPPVDvCdOzPJQKiTRoRZ5+r4vdMQO1Up5sjnG9TdN8Ngk4ESe4Fp/Topw9Cfk7 JD6ynrNox8hXzgmn0C3C86V8NzXD73qB5amcektG+IaywaU2KkTbdYhY1ZWbV8+7 1Xv1N7mgF13JOdr/Pk0xk5GFFqQWXQCghEFh7CHPOsWGTvhGunyk2KOnZqCbt42I RUYG4J8rPFjxnvCjiBFD =xNLe -----END PGP SIGNATURE----- From iesg-secretary@ietf.org Wed Feb 20 14:10:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD3321E8054; Wed, 20 Feb 2013 14:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 MXpsvizSjSrD; Wed, 20 Feb 2013 14:10:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5275521E8030; Wed, 20 Feb 2013 14:10:40 -0800 (PST) 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.40 Message-ID: <20130220221040.25795.37304.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2013 14:10:40 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (The 'acct' URI Scheme) 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: Wed, 20 Feb 2013 22:10:41 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'The 'acct' URI Scheme' 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 2013-03-06. 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 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Wed Feb 20 14:10:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3F921E8044 for ; Wed, 20 Feb 2013 14:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 m2qDGDTp9DcN; Wed, 20 Feb 2013 14:10:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7E621E8041; Wed, 20 Feb 2013 14:10:40 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.40 X-IETF-Draft-string: draft-ietf-appsawg-acct-uri X-IETF-Draft-revision: 03 Message-ID: <20130220221040.25795.82511.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2013 14:10:40 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (The 'acct' URI Scheme) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:10:41 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'The 'acct' URI Scheme' 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 2013-03-06. 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 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri/ballot/ No IPR declarations have been submitted directly on this I-D. From sm@elandsys.com Wed Feb 20 16:44:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B2E21F8C69 for ; Wed, 20 Feb 2013 16:44:32 -0800 (PST) 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 gW16a4bVWuOg for ; Wed, 20 Feb 2013 16:44:31 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6194F21F8C68 for ; Wed, 20 Feb 2013 16:44:31 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.145.35]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1L0iIl6003817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Feb 2013 16:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1361407469; bh=hBVP1i707R5Hc15vYPJGKdWIpLOhKKstJa6wFml0ZXw=; h=Date:To:From:Subject; b=YCHhuA92FzpqOHfpXMth5yZeulLnI2wM3SSOobLRAt96Wsm4yHRMMa1nL3IcBGCxZ 6oY55mEnUEYKQrmN2l2YDOKvMDY+etIKVOq9SjX/eyT0BtjoPbAGxnWqvVDG2xUKy1 EeYm7WtWBjMMg3nUtdtayvsmvWl/wUz0pKtwOE8Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1361407469; i=@elandsys.com; bh=hBVP1i707R5Hc15vYPJGKdWIpLOhKKstJa6wFml0ZXw=; h=Date:To:From:Subject; b=m05tlQlJFjCsloKMvd5pIlRX2JxOC1JHmXoYKsntQflnk2FIPpP4Ft1yFy03jGj6Z 49dY2QGyux79vvgnqGXfoh1twfgdjyEPZnVeQiIgGBE102JBHzAUKmkNd0RVfqWpWg FjNuvdoOfD2g3G1qIAEB9WvYObcUEHzT4w6/yjjo= Message-Id: <6.2.5.6.2.20130220155517.09bdf828@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 20 Feb 2013 16:43:40 -0800 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Applications Area Directorate Questions & Answers for IETF 86 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Feb 2013 00:44:32 -0000 Hello, The Applications Area Directorate ( http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ) has been performing reviews since over a year. I would like to request some time at IETF 86 for individuals who are not part of the directorate to ask questions. My individual preference is for a very short session. I see this as an opportunity for you to: (i) Ask questions about the directorate (ii) Say what you did not like about the reviews (iii) Suggest what could be done to make the interaction with reviewers easier Feel free to email me off-list if you think that the session would be useful. Regards, S. Moonesamy From msk@blackops.org Thu Feb 21 00:35:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BE121F87E1; Thu, 21 Feb 2013 00:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 vnRMOcceDPJw; Thu, 21 Feb 2013 00:35:17 -0800 (PST) Received: from medusa.blackops.org (medusa.blackops.org [208.69.40.157]) by ietfa.amsl.com (Postfix) with ESMTP id D757D21F8E1A; Thu, 21 Feb 2013 00:35:17 -0800 (PST) Received: from medusa.blackops.org (msk@localhost.blackops.org [127.0.0.1]) by medusa.blackops.org (8.14.5/8.14.5) with ESMTP id r1L8ZD0g078687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 00:35:14 -0800 (PST) (envelope-from msk@medusa.blackops.org) DKIM-Filter: OpenDKIM Filter v2.8.0 medusa.blackops.org r1L8ZD0g078687 X-SenderID: Sendmail Sender-ID Filter v1.0.0 medusa.blackops.org r1L8ZD0g078687 Authentication-Results: medusa.blackops.org; sender-id=permerror header.from=superuser@gmail.com; spf=none smtp.mfrom=msk@medusa.blackops.org Received: (from msk@localhost) by medusa.blackops.org (8.14.5/8.14.5/Submit) id r1L8ZCpP078686; Thu, 21 Feb 2013 00:35:12 -0800 (PST) (envelope-from msk) Date: Thu, 21 Feb 2013 00:35:12 -0800 (PST) Message-Id: <201302210835.r1L8ZCpP078686@medusa.blackops.org> From: "Murray S. Kucherawy" To: apps-discuss@ietf.org, draft-templin-ironbis.all@tools.ietf.org Cc: iesg@ietf.org Subject: [apps-discuss] AppsDir reivew of draft-templin-ironbis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Feb 2013 08:35:24 -0000 I have been selected as the Applications Area Directorate (appsdir) 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-templin-ironbis-12 Title: The Intradomain Routing Overlay Network (IRON) Reviewer: Murray S. Kucherawy Review Date: February 20, 2013 IETF Last Call Date: January 30, 2013 IESG Telechat Date: February 21, 2013 Summary: This document appears to be ready for evaluation and approval. However, most of the content exceeds my areas of expertise, so I have focused only on trying to find those parts that appear likely to affect applications in a direct way, or on IETF procedural points. Apologies for the tardiness of the review. Major Issues: None. This appears like interesting work, but I infer from the document's content that most of the work here concerns operations well below and thus not visible to the application layer. Minor Issues: The [RO-CR] and [SAMPLE] references don't appear to point to I-Ds, though they say "Work in Progress". If they are I-Ds, they should be named; if not, I don't believe those references are complete. Where are they published? Nits: I couldn't parse the last sentence of Section 10: IRON does not otherwise introduce any new issues to complications raised for NAT traversal or for applications embedding address referrals in their payload. "issues to complications raised"? From ietfc@btconnect.com Thu Feb 21 03:08:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21D621F8E65 for ; Thu, 21 Feb 2013 03:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[AWL=1.238, 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 CHX4hecrrigu for ; Thu, 21 Feb 2013 03:08:11 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id E166421F8E5E for ; Thu, 21 Feb 2013 03:08:10 -0800 (PST) Received: from mail18-co9-R.bigfish.com (10.236.132.235) by CO9EHSOBE003.bigfish.com (10.236.130.66) with Microsoft SMTP Server id 14.1.225.23; Thu, 21 Feb 2013 11:08:05 +0000 Received: from mail18-co9 (localhost [127.0.0.1]) by mail18-co9-R.bigfish.com (Postfix) with ESMTP id ED26C3A013F; Thu, 21 Feb 2013 11:08:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz9371I542I1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL177df4h17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh304l1155h) Received: from mail18-co9 (localhost.localdomain [127.0.0.1]) by mail18-co9 (MessageSwitch) id 136144488393228_15075; Thu, 21 Feb 2013 11:08:03 +0000 (UTC) Received: from CO9EHSMHS023.bigfish.com (unknown [10.236.132.235]) by mail18-co9.bigfish.com (Postfix) with ESMTP id 13E7634006A; Thu, 21 Feb 2013 11:08:03 +0000 (UTC) Received: from AM2PRD0710HT001.eurprd07.prod.outlook.com (157.56.249.213) by CO9EHSMHS023.bigfish.com (10.236.130.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 21 Feb 2013 11:08:02 +0000 Received: from DB3PRD0511HT002.eurprd05.prod.outlook.com (157.56.254.213) by pod51017.outlook.com (10.255.165.36) with Microsoft SMTP Server (TLS) id 14.16.263.1; Thu, 21 Feb 2013 11:07:57 +0000 Message-ID: <000901ce1023$3c4b7140$4001a8c0@gateway.2wire.net> From: t.petch To: Erik Wilde , References: <5124D91C.1000703@berkeley.edu> Date: Thu, 21 Feb 2013 11:04:28 +0000 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.254.213] X-OriginatorOrg: btconnect.com Subject: Re: [apps-discuss] process and editing questions: RFC errata X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Feb 2013 11:08:12 -0000 ----- Original Message ----- From: "Erik Wilde" To: Sent: Wednesday, February 20, 2013 2:09 PM > hello. > > i have two process and editing questions: > http://tools.ietf.org/html/draft-wilde-xml-patch-03#section-6 > specifically links to errata i have filed regarding RFC 5261. it seems > to me that these errata are legitimate, and that they simply weren't > caught earlier. draft-wilde-xml-patch is almost complete, and i am > wondering about the following things: > > - how to best sync draft development, and the submitted errata. there > seems to be no way to predict when and how errata are processed, in > particular for RFC 5261 because the author seems to be unreachable. Indeed! Bear in mind that the text of an RFC is available for further processing within the IETF so while it is desirable that the original author is involved in any updates thereto, that is not a requirement thereof so if you cannot get any response from them, then submitting an RFC5261-bis yourself is quite in order; but quite a lot of work. A simpler approach is to include the relevant changes in draft-wilde-xml-patch and state that this is an update to the relevant sections of RFC5261. These should give more context than the errata do but need not be much longer. Or you can include sections that clarify the issues you have identified in RFC5261 and state in your I-D that your I-D is based on this interpretation ie you are not updating RFC5261 for the world at large but are modifiying the content thereof for the purposes of your I-D. Or you can make normative references to errata by URL once they are approved. I think this the most fraught approach and so the least desirable. Tom Petch > - if the errata are accepted, how to reference them in the draft. it > would be important that people following references to RFC 5261 from the > draft do not just read the RFC, but also take the errata into account > when implementing the spec. > > thanks a lot 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 GK@ninebynine.org Thu Feb 21 04:20:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F07921F8C48; Thu, 21 Feb 2013 04:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 n2F9WFxloaic; Thu, 21 Feb 2013 04:20:05 -0800 (PST) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id D391321F8CA7; Thu, 21 Feb 2013 04:20:04 -0800 (PST) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1U8V83-0001RO-iX; Thu, 21 Feb 2013 12:19:59 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1U8V83-0003AX-7m; Thu, 21 Feb 2013 12:19:59 +0000 Message-ID: <51260FB9.8000105@ninebynine.org> Date: Thu, 21 Feb 2013 12:14:49 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Fredrik Ullner References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: uri-review@ietf.org, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] URI scheme registration request - dchub X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Feb 2013 12:20:08 -0000 Fredrik, [I'm cc'ing apps-discuss@ietf.org on this response, as I feel there may be application protocol issues that list-members there may be able to comment upon with regard to specification, interoperability and security considerations issues.] On 20/02/2013 20:26, Fredrik Ullner wrote: > Hi, > > This is a request for registration of an URI scheme, dchub. The scheme can > be viewed at . > > The URI scheme should meet the necessary requirements for a Permanent URI > scheme, as indicating in RFC 4395. The scheme specifies encoding, > interoperability and security aspects (and more). If the scheme should not > provide enough information for a Permanent scheme, please specify what is > lacking or at least consider a Provisional request instead. NOTE: I am IANA's designated reviewer for URI scheme registrations, but this is a personal response, and does not represent any formal position at this time. You'll need to send your request to IANA (cf. RFC 4395, section 5.2, item 5) for it to be considered for registration. Requesting review here is the appropriate first step - the Right Thing to do :) I would allow that the scheme is appropriate for provisional registration. But the lack of a public specification (according to http://en.wikipedia.org/wiki/Direct_Connect_(file_sharing), which is cited by your registration template) causes me to question whether it's appropriate for permanent registration at this time. On the other hand, the diversity of implementations suggests permanent registration may be appropriate. I see that there is a specification at http://nmdc.sourceforge.net/Versions/NMDC-1.1.html, linked via the other reference in your registration template. The question, then, is the extent to which this can be regarded as definitive for the protocol. Of the criteria for permanent registration given in RFC4395: 2.1. Demonstratable, New, Long-Lived Utility . . . . . . . . . 4 2.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 5 2.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Definition of Operations . . . . . . . . . . . . . . . . . 6 2.5. Context of Use . . . . . . . . . . . . . . . . . . . . . . 6 2.6. Internationalization and Character Encoding . . . . . . . 7 2.7. Clear Security Considerations . . . . . . . . . . . . . . 7 2.8. Scheme Name Considerations . . . . . . . . . . . . . . . . 7 I would judge that requirements 2.1, 2.2 (not checked in detail), 2.5, 2.6 and 2.8 are satisfied. My comments noted above are concerns with respect to 2.3 and 2.4. I would also be concerned that 2.7 security concerns have not been given sufficient consideration and review for permanent registration. To recommend permanent registration, I would like to see: (a) some clear indication that there is good consensus in the relevant developer community about what constitutes a suitable specification of the protocol (preferably with indications that implementations conforming to aid specification are interoperable, but I wouldn't see that as a must-have requirement here). (b) some review within the IETF, or a community with corresponding security expertise, of the security considerations. As they stand, they look very thin to me. I hope this helps. #g -- From dret@berkeley.edu Thu Feb 21 06:59:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6178A21F873C for ; Thu, 21 Feb 2013 06:59:19 -0800 (PST) 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, J_CHICKENPOX_15=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 0KDP4ZoswwZP for ; Thu, 21 Feb 2013 06:59:18 -0800 (PST) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2869721F85C0 for ; Thu, 21 Feb 2013 06:59:18 -0800 (PST) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretair.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1U8Xc5-0002Gy-Ds; Thu, 21 Feb 2013 06:59:16 -0800 Message-ID: <51263634.7040906@berkeley.edu> Date: Thu, 21 Feb 2013 15:59:00 +0100 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "t.petch" , apps-discuss@ietf.org References: <5124D91C.1000703@berkeley.edu> <000901ce1023$3c4b7140$4001a8c0@gateway.2wire.net> In-Reply-To: <000901ce1023$3c4b7140$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: REST Discuss Subject: Re: [apps-discuss] process and editing questions: RFC errata X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Feb 2013 14:59:19 -0000 hello tom. thanks a lot for your response! it was very useful to get a menu of options how to proceed. On 2013-02-21 12:04 , t.petch wrote: >> - how to best sync draft development, and the submitted errata. there >> seems to be no way to predict when and how errata are processed, in >> particular for RFC 5261 because the author seems to be unreachable. > > Indeed! Bear in mind that the text of an RFC is available for further > processing within the IETF so while it is desirable that the original > author is involved in any updates thereto, that is not a requirement > thereof so if you cannot get any response from them, then submitting an > RFC5261-bis yourself is quite in order; but quite a lot of work. > > A simpler approach is to include the relevant changes in > draft-wilde-xml-patch > and state that this is an update to the relevant sections of RFC5261. > These should give more context than the errata do but need not be much > longer. > > Or you can include sections that clarify the issues you have identified > in RFC5261 and state in your I-D that your I-D is based on this > interpretation ie you are not updating RFC5261 for the world at large > but are modifiying the content thereof for the purposes of your I-D. > > Or you can make normative references to errata by URL once they are > approved. I think this the most fraught approach and so the least > desirable. after thinking about these options for a while, i decided to go with the second option. http://tools.ietf.org/html/draft-wilde-xml-patch-04 is the updated draft and now officially updates RFC 5261. http://tools.ietf.org/html/draft-wilde-xml-patch-04#appendix-A lists all the changes to that RFC, and i have based this appendix mostly on the errata i had filed before. this approach seems to be much less work than republishing RFC 5261, and since the changes are rather small, the updates aren't that hard to read and apply, when you have to read them in addition to RFC 5261. thanks again 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 presnick@qti.qualcomm.com Thu Feb 21 07:51:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B98021F8E97; Thu, 21 Feb 2013 07:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 pvAc9xcofxMi; Thu, 21 Feb 2013 07:51:14 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2C59321F8EA6; Thu, 21 Feb 2013 07:51:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1361461874; x=1392997874; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=e8OOow56bP3F6ciXW+ymkmRPYfqd1FUhy9fkVhrrKoU=; b=WG94oTpZz4MeA3Vnzc0C4APW8fTiATAADMJwlrtYht5aM98dgHHH2YUM b0pxTpYhYzZo/nl5UCFrtSyt+jcRTbZJW0aZM6jQYxOR5fLrU/IAKoE04 hbm2u6T02D/h2aU+9H/wc5mxeQVMU6awEb5EMEYJOKOX62zfpaY92dJm/ s=; X-IronPort-AV: E=Sophos;i="4.84,710,1355126400"; d="scan'208";a="24662883" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 21 Feb 2013 07:51:13 -0800 X-IronPort-AV: E=Sophos;i="4.84,710,1355126400"; d="scan'208";a="402965853" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Feb 2013 07:51:13 -0800 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 21 Feb 2013 07:51:13 -0800 Message-ID: <51264270.4050205@qti.qualcomm.com> Date: Thu, 21 Feb 2013 09:51:12 -0600 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: Cyrus Daboo 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] Cc: vcarddav@ietf.org, calsify@ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Feb 2013 15:51:15 -0000 During IESG review, the following change was proposed: OLD Requirements from other working groups looking to adopt the jCard or jCal data formats will be considered. Requirements that are not explicitly mentioned in this charter will be considered so long as they do not conflict with the other stated objectives. Specific requirements for consideration are: NEW Syntactic requirements from other working groups looking to adopt the jCard or jCal data formats will be considered. However, changes to the semantics of vCard and iCalendar are out of scope. Requirements that are not explicitly mentioned in this charter will be considered so long as they do not conflict with the other stated objectives. Specific requirements for consideration are: Any objections? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From Claudio.Allocchio@garr.it Thu Feb 21 07:55:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3E121F8E89; Thu, 21 Feb 2013 07:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYAOsug7zOFL; Thu, 21 Feb 2013 07:55:26 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 422DA21F8EB7; Thu, 21 Feb 2013 07:55:22 -0800 (PST) Received: internal info suppressed Date: Thu, 21 Feb 2013 16:55:09 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.local To: Pete Resnick In-Reply-To: <51264270.4050205@qti.qualcomm.com> Message-ID: References: <51264270.4050205@qti.qualcomm.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1361462111; bh=wjwhAH5rl0GeaAwL9zkIrsk1G+iJj9wfC2Ul/Rkta0E=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KTwwbjtgsxmsgJmuGTUZhK0Y62Km1DomfwRH1OBdUGcr0um8I2/DsgKNrXKWOXyLy j7O+FaYYxghzHa98NK2Sov+jdcfrlea/2yX+7MRCz2BqhlSD4vzQ14kCDBskoT/DIZ +qYVkxjqKDFt6F1mPjs0ll15JIMeZfjDSSOgj4s4= Cc: IETF Apps Discuss , calsify@ietf.org, vcarddav@ietf.org Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Feb 2013 15:55:27 -0000 On Thu, 21 Feb 2013, Pete Resnick wrote: > During IESG review, the following change was proposed: > > OLD > Requirements from other working groups looking to adopt the jCard or > jCal data formats will be considered. Requirements that are not > explicitly mentioned in this charter will be considered so long as > they do not conflict with the other stated objectives. Specific > requirements for consideration are: > > NEW > Syntactic requirements from other working groups looking to adopt > the jCard or jCal data formats will be considered. However, changes > to the semantics of vCard and iCalendar are out of scope. > Requirements that are not explicitly mentioned in this charter will > be considered so long as they do not conflict with the other stated > objectives. Specific requirements for consideration are: > > Any objections? Fine! a very careful statement, given the many implementations using vCard and iCalendar semantics out there. ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From marc.blanchet@viagenie.ca Thu Feb 21 07:56:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA8B21F8E70; Thu, 21 Feb 2013 07:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 Oe18+OGJrqJI; Thu, 21 Feb 2013 07:56:46 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id B6DBD21F8E6B; Thu, 21 Feb 2013 07:56:44 -0800 (PST) Received: from [10.102.29.112] (bas13-quebec14-1279341847.dsl.bell.ca [76.65.53.23]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0FB914039E; Thu, 21 Feb 2013 10:56:14 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Marc Blanchet In-Reply-To: <51264270.4050205@qti.qualcomm.com> Date: Thu, 21 Feb 2013 10:56:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51264270.4050205@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1499) Cc: IETF Apps Discuss , calsify@ietf.org, vcarddav@ietf.org Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Feb 2013 15:56:46 -0000 Le 2013-02-21 =E0 10:51, Pete Resnick a = =E9crit : > During IESG review, the following change was proposed: >=20 > OLD > Requirements from other working groups looking to adopt the jCard = or > jCal data formats will be considered. Requirements that are not > explicitly mentioned in this charter will be considered so long as > they do not conflict with the other stated objectives. Specific > requirements for consideration are: >=20 > NEW > Syntactic requirements from other working groups looking to adopt > the jCard or jCal data formats will be considered. However, changes > to the semantics of vCard and iCalendar are out of scope. > Requirements that are not explicitly mentioned in this charter will > be considered so long as they do not conflict with the other stated > objectives. Specific requirements for consideration are: >=20 > Any objections? none. ship it! marc. >=20 > pr >=20 > --=20 > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From dret@berkeley.edu Thu Feb 21 08:35:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413D921F8E82 for ; Thu, 21 Feb 2013 08:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 nSkkr5gh5ja8 for ; Thu, 21 Feb 2013 08:35:46 -0800 (PST) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id D5BAF21F8EA5 for ; Thu, 21 Feb 2013 08:35:43 -0800 (PST) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretair.local) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1U8Z7R-0003uq-Ka; Thu, 21 Feb 2013 08:35:38 -0800 Message-ID: <51264CD4.3080208@berkeley.edu> Date: Thu, 21 Feb 2013 17:35:32 +0100 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" References: <20130221145404.6108.74590.idtracker@ietfa.amsl.com> In-Reply-To: <20130221145404.6108.74590.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130221145404.6108.74590.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: REST Discuss Subject: [apps-discuss] Fwd: New Version Notification for draft-wilde-xml-patch-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:35:49 -0000 hello. this version is almost identical with the previous one, but instead of linking to errata, the draft now is written as an update of RFC 5261. http://tools.ietf.org/html/draft-wilde-xml-patch-04#appendix-A lists all the updates to the RFC, and the XML Patch draft then refers to these updates where it needs to. this should make the draft more self-contained, so that it can progress without any dependencies on errata. it also makes it easier for implementers, all they need to do is read the spec, and RFC 5261. as usual, feedback is very welcome. cheers, dret. -------- Original Message -------- Subject: New Version Notification for draft-wilde-xml-patch-04.txt Date: Thu, 21 Feb 2013 06:54:04 -0800 From: internet-drafts@ietf.org A new version of I-D, draft-wilde-xml-patch-04.txt has been successfully submitted by Erik Wilde and posted to the IETF repository. Filename: draft-wilde-xml-patch Revision: 04 Title: A Media Type for XML Patch Operations Creation date: 2013-02-21 Group: Individual Submission Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-wilde-xml-patch-04.txt Status: http://datatracker.ietf.org/doc/draft-wilde-xml-patch Htmlized: http://tools.ietf.org/html/draft-wilde-xml-patch-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-wilde-xml-patch-04 Abstract: The XML Patch media type "application/xml-patch+xml" defines an XML document structure for expressing a sequence of patch operations that are applied to an XML document. The XML Patch document format's foundations are defined in RFC 5261, this specification defines a document format and a media type registration, so that XML Patch documents can be labeled with a media type, for example in HTTP conversations. In addition to the media type registration, this specification also updates RFC 5261 in some aspects, limiting these updates to cases where RFC 5261 needed to be fixed, or was hard to understand. From ietfc@btconnect.com Thu Feb 21 08:44:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8AD21F8E56 for ; Thu, 21 Feb 2013 08:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.786 X-Spam-Level: X-Spam-Status: No, score=-3.786 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_00=-2.599, J_CHICKENPOX_15=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 moNhR+cuKgAv for ; Thu, 21 Feb 2013 08:44:23 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 524BC21F865D for ; Thu, 21 Feb 2013 08:44:23 -0800 (PST) Received: from mail186-co1-R.bigfish.com (10.243.78.200) by CO1EHSOBE027.bigfish.com (10.243.66.90) with Microsoft SMTP Server id 14.1.225.23; Thu, 21 Feb 2013 16:44:22 +0000 Received: from mail186-co1 (localhost [127.0.0.1]) by mail186-co1-R.bigfish.com (Postfix) with ESMTP id 96133800274; Thu, 21 Feb 2013 16:44:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz98dI9371I936eI1be0I542I1432I111aIzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL177df4h17326ah8275bh8275dhz2dh2a8h5a9h668h839h93fhd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh304l1155h) Received: from mail186-co1 (localhost.localdomain [127.0.0.1]) by mail186-co1 (MessageSwitch) id 136146506192181_17307; Thu, 21 Feb 2013 16:44:21 +0000 (UTC) Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.211]) by mail186-co1.bigfish.com (Postfix) with ESMTP id 140BD3000A6; Thu, 21 Feb 2013 16:44:21 +0000 (UTC) Received: from AMSPRD0710HT002.eurprd07.prod.outlook.com (157.56.249.85) by CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 21 Feb 2013 16:44:18 +0000 Received: from DB3PRD0511HT003.eurprd05.prod.outlook.com (157.56.254.213) by pod51017.outlook.com (10.255.160.165) with Microsoft SMTP Server (TLS) id 14.16.263.1; Thu, 21 Feb 2013 16:44:04 +0000 Message-ID: <015e01ce1052$3098b540$4001a8c0@gateway.2wire.net> From: t.petch To: Erik Wilde , References: <5124D91C.1000703@berkeley.edu> <000901ce1023$3c4b7140$4001a8c0@gateway.2wire.net> <51263634.7040906@berkeley.edu> Date: Thu, 21 Feb 2013 16:40:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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.254.213] X-OriginatorOrg: btconnect.com Cc: REST Discuss Subject: Re: [apps-discuss] process and editing questions: RFC errata X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Feb 2013 16:44:24 -0000 ----- Original Message ----- From: "Erik Wilde" To: "t.petch" ; Cc: "REST Discuss" Sent: Thursday, February 21, 2013 2:59 PM > hello tom. > > thanks a lot for your response! it was very useful to get a menu of > options how to proceed. > > On 2013-02-21 12:04 , t.petch wrote: > >> - how to best sync draft development, and the submitted errata. there > >> seems to be no way to predict when and how errata are processed, in > >> particular for RFC 5261 because the author seems to be unreachable. > > > > Indeed! Bear in mind that the text of an RFC is available for further > > processing within the IETF so while it is desirable that the original > > author is involved in any updates thereto, that is not a requirement > > thereof so if you cannot get any response from them, then submitting an > > RFC5261-bis yourself is quite in order; but quite a lot of work. > > > > A simpler approach is to include the relevant changes in > > draft-wilde-xml-patch > > and state that this is an update to the relevant sections of RFC5261. > > These should give more context than the errata do but need not be much > > longer. > > > > Or you can include sections that clarify the issues you have identified > > in RFC5261 and state in your I-D that your I-D is based on this > > interpretation ie you are not updating RFC5261 for the world at large > > but are modifiying the content thereof for the purposes of your I-D. > > > > Or you can make normative references to errata by URL once they are > > approved. I think this the most fraught approach and so the least > > desirable. > > after thinking about these options for a while, i decided to go with the > second option. http://tools.ietf.org/html/draft-wilde-xml-patch-04 is > the updated draft and now officially updates RFC 5261. > http://tools.ietf.org/html/draft-wilde-xml-patch-04#appendix-A lists all > the changes to that RFC, and i have based this appendix mostly on the > errata i had filed before. this approach seems to be much less work than > republishing RFC 5261, and since the changes are rather small, the > updates aren't that hard to read and apply, when you have to read them > in addition to RFC 5261. Yup, that is what I would have done. In passing, some lines of formal definition exceed the permitted length for an RFC line so a little reorganising will be needed, probably best sooner rather than later as they will need validating before the I-D can advance and reorganising can introduce syntax errors. I may have missed the errata but I cannot recall a reference to them on the apps-discuss list. If they are modified and then approved, which usually happens, then your I-D should follow suit so the sooner they are processed the better. Which might mean you requesting the AD to set the wheels in motion, explaining why timeliness matters. And, out of curiosity, do you expect people to use XPath 1.0 or 2.0? I ask because in Netconf, I was keen to specify 2.0 and not 1.0, the handling of namespaces in 2.0 seemed superior, but was told we could not because there were no implementations for people to use, that 2.0 was a great idea that had not happened (mmm IPv6?). The Normative reference for Yang remains the 1999 version. Tom Petch > thanks again 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 cyrus@daboo.name Thu Feb 21 09:00:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0292F21F8501; Thu, 21 Feb 2013 09:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Fw41Q2Q0Wij; Thu, 21 Feb 2013 09:00:08 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 308E621F87D5; Thu, 21 Feb 2013 09:00:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 5C67B3DCC0E3; Thu, 21 Feb 2013 12:00:01 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xN9fErwSgnLm; Thu, 21 Feb 2013 12:00:00 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id DCEF93DCC0AA; Thu, 21 Feb 2013 11:59:58 -0500 (EST) Date: Thu, 21 Feb 2013 11:59:54 -0500 From: Cyrus Daboo To: Pete Resnick Message-ID: <06C4C4FFECBE39C5BF6300AE@caldav.corp.apple.com> In-Reply-To: <51264270.4050205@qti.qualcomm.com> References: <51264270.4050205@qti.qualcomm.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=921 Cc: vcarddav@ietf.org, calsify@ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] iCalendar and vCard in JSON: WG draft charter X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Feb 2013 17:00:13 -0000 Hi Pete, --On February 21, 2013 at 9:51:12 AM -0600 Pete Resnick wrote: > OLD > Requirements from other working groups looking to adopt the jCard or > jCal data formats will be considered. Requirements that are not > explicitly mentioned in this charter will be considered so long as > they do not conflict with the other stated objectives. Specific > requirements for consideration are: > > NEW > Syntactic requirements from other working groups looking to adopt > the jCard or jCal data formats will be considered. However, changes > to the semantics of vCard and iCalendar are out of scope. > Requirements that are not explicitly mentioned in this charter will > be considered so long as they do not conflict with the other stated > objectives. Specific requirements for consideration are: > > Any objections? No. -- Cyrus Daboo From GK@ninebynine.org Fri Feb 22 07:30:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97B121F8E53; Fri, 22 Feb 2013 07:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, WEIRD_PORT=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 DpK1k4QnlPHj; Fri, 22 Feb 2013 07:30:43 -0800 (PST) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id BC1E921F8E2E; Fri, 22 Feb 2013 07:30:43 -0800 (PST) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1U8ua7-0005Hc-pr; Fri, 22 Feb 2013 15:30:39 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1U8ua6-0008Lp-9C; Fri, 22 Feb 2013 15:30:39 +0000 Message-ID: <51278B10.10200@ninebynine.org> Date: Fri, 22 Feb 2013 15:13:20 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Fredrik Ullner References: <512663B2.20809@tibco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: uri-review@ietf.org, Bjoern Hoehrmann , Eric Johnson , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] URI scheme registration request - dchub X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2013 15:30:44 -0000 On 21/02/2013 21:07, Fredrik Ullner wrote: > On Thu, Feb 21, 2013 at 7:13 PM, Eric Johnson wrote: >> > >> >The protocol itself ought to be filed as an RFC. That would pretty much >> >guarantee permanence of the reference. > It has actually been discussed previously. I have a semi-complete document > written, but it's far from complete. I am also unsure of how one would > manage messages that are now not used by any implementation. If people > would feel that that would be the best approach, then I'm all for it. "Ought to be" maybe too strong, but if dchub is widely used and supported that's an option to consider. But if you go down that route, be aware that in can be a lot of work preparing and herding a spec through full IETF review. As Eric says, that would almost certainly justify making the URI scheme registration permanent. > I would like to invite people for discussion to the DC community. There is > a development forum athttp://dcbase.org as well as the development talk > hub at adcs://hub.dcbase.org:16591 (note that this is another URI scheme > that is intended to be registered in the future). (Download the application > DC++, press Ctrl+Q and enter the adcs:// address to join.) Is there perhaps > an IRC channel otherwise where one can discuss these things? I took a quick look. It appears to be a vibrant developer community there, but I got a bit lost looking, e.g., for possible clues about interoperability of different implementations. The adcs: reference wasn't useful to me, as my browser doesn't know what to do with it - this is a perennial problem with new URI schemes, and is one reason why there is some reluctance to allow new permanent schemes - it's extremely difficult and expensive to get new schemes widely deployed. #g -- From ullner@gmail.com Thu Feb 21 13:08:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9787521F8E65; Thu, 21 Feb 2013 13:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, WEIRD_PORT=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 4Dnt6F3SOhCe; Thu, 21 Feb 2013 13:07:56 -0800 (PST) Received: from mail-ia0-x236.google.com (ia-in-x0236.1e100.net [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 27C3221F8E57; Thu, 21 Feb 2013 13:07:56 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id k38so1954374iah.13 for ; Thu, 21 Feb 2013 13:07:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=j3dugbjpn8cWUHWBYRkxcMEw6NdYS7UdBJ9eJMMlFsE=; b=iM83ExojPslgsIXB2BSnIj5LX6hFw2lhY8ndb6EjQh/03Z6u0Y5DcFwuzuP7KqNG/a LLgD7cTiUlA66Dw+aS0YpHNHuggFbzt46y/9oQzrNVIJl1lCtoFZFHwlrr0YGSs08wRM ckddF7AHSRvUi6O2lfmocl1mXvUx9iJuSo2ZyGRDVdpQgD0XzKQve5ueUHtuEdcOlFNd uCdXonJadD3n2ifoZpAEV7Muk6GuLeEfFoaoLxhlfvvRGcjNJqnAK1qpw5cyT7p1awYb brhCpGaNZKeUbhJnId+srsU7GMWSRPdEbJ+3aF2f5snBjicxokeKc11YOR7E/krOZcQx 846g== MIME-Version: 1.0 X-Received: by 10.42.150.131 with SMTP id a3mr7310562icw.8.1361480875640; Thu, 21 Feb 2013 13:07:55 -0800 (PST) Received: by 10.42.78.131 with HTTP; Thu, 21 Feb 2013 13:07:55 -0800 (PST) In-Reply-To: <512663B2.20809@tibco.com> References: <512663B2.20809@tibco.com> Date: Thu, 21 Feb 2013 22:07:55 +0100 Message-ID: From: Fredrik Ullner To: Graham Klyne , Eric Johnson , Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=90e6ba6e8358f6098504d6427779 X-Mailman-Approved-At: Fri, 22 Feb 2013 08:06:49 -0800 Cc: uri-review@ietf.org, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] URI scheme registration request - dchub X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Feb 2013 21:08:01 -0000 --90e6ba6e8358f6098504d6427779 Content-Type: text/plain; charset=ISO-8859-1 I have uploaded the document to the SVN, so people can track changes that are made to the document. See it here; < http://nmdc.svn.sourceforge.net/viewvc/nmdc/trunk/nmdc-uri-scheme.txt?view=log >. The index page of nmdc.sf.net was incorrect, it did not have a news item for 1.2, which contain more content. Note that the document is descriptive of the protocol and its implementations and not prescriptive. The protocol was built in 1999 (i.e., shortly after Napster and before BitTorrent) but it has been expanded upon many times, but the original version was never made public, hence reverse engineering efforts. The protocol is very much still used today as it has been used in the past. There are still many users using the protocol daily. Note that the URI was constructed by Jonathan Hess for the original NMDC client and this is an attempt at a formalization of that scheme. The phrasing of the scheme is such that some current implementations only support a partial of the syntax listed. There haven't been any innovation (to the best of my knowledge) in the URI scheme in the past years. I appreciate all suggestions and criticism. I didn't expect responses so quickly. :) On Thu, Feb 21, 2013 at 12:09 PM, Bjoern Hoehrmann wrote: > > Link "http://en.wikipedia.org/wiki/Direct_Connect(file_sharing)" should > be "http://en.wikipedia.org/wiki/Direct_Connect_(file_sharing)". Ah, yeah, of course. On Thu, Feb 21, 2013 at 1:14 PM, Graham Klyne wrote: > > (a) some clear indication that there is good consensus in the relevant > developer community about what constitutes a suitable specification of the > protocol (preferably with indications that implementations conforming to > aid specification are interoperable, but I wouldn't see that as a must-have > requirement here). > I understand the concern, but I am unsure of the type of necessary explicit consensus here. There are multiple implementations that are interoperable - isn't that a de facto concensus? The protocol document does not specify what implementations support what, but I'm not sure if that'd be applicable in that type of document. (Another document perhaps that could be interesting.) It wouldn't be difficult to construct such an implementation matrix, it would simply require some time. (But obviously if that's necessary to be considered, then that is something that must be done.) On Thu, Feb 21, 2013 at 1:14 PM, Graham Klyne wrote: > (b) some review within the IETF, or a community with corresponding > security expertise, of the security considerations. As they stand, they > look very thin to me. > Noted, and I will discuss with others on potential reviews and revising of this section (see also below). On Thu, Feb 21, 2013 at 7:13 PM, Eric Johnson wrote: > > The syntax section: > > * [a] discusses semantics. For example: "The client should download the > user's file list if path is omitted". > * [b] doesn't actually reference the syntax components of RFC 3986. It > doesn't explicitly exclude possible portions of the syntax, such as > fragment identifiers and queries. Am I to assume that those are > allowed, but not specified in their use, or disallowed? > * [c] seems to allow "dchub://" as a valid URI, however, if I follow RFC > 3986 properly, that is not a valid URI, and at least a "host" is > required. > * [d] Is RFC 3986 "userinfo" allowed in the URI? If so, how does that > interact with the protocol? a) Ah, ok. It could definitely move to the 'scheme' semantics section. b/d) The syntax presented is what implementations support today. Anything else apart from the explicit syntax listed should be considered as 'not allowed' (save for an extension, which there hasn't been any). c) Ah, "dchub://" would indeed be wrong; a host is required. Doesn't the current syntax require it? "dchub://" As far as I can tell, that makes the host required. On Thu, Feb 21, 2013 at 7:13 PM, Eric Johnson wrote: > > The semantics section: > > * [e] should steal the portions from the syntax section that address the > meaning of a particular form, and further ought to tie that to > specific portions of the spec. As in "download the user's file list" > - which NMDC messages does this correspond to? > * [f] doesn't discuss at all how one might compare two of these URIs. Is > the user name case-sensitive? If characters occur that require > encoding via %xx, should those be normalized first before comparison? > * [g] Since the URI contains a path, does the path need to be normalized > before comparison? e) Regarding protocol message correspondence: I wasn't aware that that was required/desirable. Wouldn't the protocol specification specify what commands were necessary for that? I mean, in the event that the download command changes (a portion of it has actually done that), one wouldn't want the URI scheme to be too narrow. (Admittedly, there haven't been changes in this aspect in years, so there wouldn't be that much of a problem. I just find it strange to have this type of information in an URI scheme.) f/g) Nicks are not case-sensitive, as it is up to the hub to enforce this, although this is not specified anywhere in the spec. I'll make sure to add that as a note. Addresses should be treated likewise as case-insensitive, and I'd say that any such normalization should be done before comparison. How do other URI schemes specify this in a more succinct manner? On Thu, Feb 21, 2013 at 7:13 PM, Eric Johnson wrote: > > Under the "use" section: > > * [h] An interoperability point is raised here that should be in the > "interoperability" section. h) I presume you mean "Not all implementations support the user and path syntax". All right. On Thu, Feb 21, 2013 at 7:13 PM, Eric Johnson wrote: > > The security section: > * [i] Future implementations may care about using TLS to secure > communications. Will that need the use of "dchubs://", or is the > intent that the "dchub:" scheme can serve both purposes? > * [j] Might one want to actually include some sort of indicator (such as a > hash) in the URI (as part of a query) so that a client can request a > file, and if the user or path has changed, and now points to a > completely different file, that the provider and consumer of said > URI will be able to detect the discrepancy? > * [k] What of using weird constructs like "../../../foo/bar", as in > "dc-hub://host/myname/../../..**/foo" - does this need to make sure > that cannot be used to retrieve a file that wasn't shared, or wasn't > intended to be shared with the specific user. > * [l] DOS attacks, or DDOS attacks? > * [m] Homographs? > i) There are indeed implementations that support TLS, and they use the syntax "nmdcs" (nmdcs://example.com). There is, as far as I'm aware, an identical syntax and management otherwise. Should that be part of this URI scheme or should it be filed as a completely separate URI scheme? j) NMDC uses tiger Tiger Tree Hashes (TTHs), so in theory your suggestion would be fine. However, no implementation currently supports that type of syntax. k) Most (all) implementations have safe guards for the ../ behaviour. I suppose including a note about in the scheme is fine, although isn't it more general to have it in the protocol specification ("implementations should safe guard against relative paths when downloading")? l) Ah, yes, this was identified (and to some extent managed) years ago. Clients connecting to a hub will now send a "referrer" during protocol negotiation (search for 'ref' in the spec) (similar to an HTTP referrer). A note in the URI scheme sounds good. m) I wasn't aware that that was a security concern here? On Thu, Feb 21, 2013 at 7:13 PM, Eric Johnson wrote: > > The protocol itself ought to be filed as an RFC. That would pretty much > guarantee permanence of the reference. It has actually been discussed previously. I have a semi-complete document written, but it's far from complete. I am also unsure of how one would manage messages that are now not used by any implementation. If people would feel that that would be the best approach, then I'm all for it. I would like to invite people for discussion to the DC community. There is a development forum at http://dcbase.org as well as the development talk hub at adcs://hub.dcbase.org:16591 (note that this is another URI scheme that is intended to be registered in the future). (Download the application DC++, press Ctrl+Q and enter the adcs:// address to join.) Is there perhaps an IRC channel otherwise where one can discuss these things? -- Fredrik Ullner --90e6ba6e8358f6098504d6427779 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have uploaded the document to the SVN, so people can track changes t= hat are made to the document. See it here; <http://nmd= c.svn.sourceforge.net/viewvc/nmdc/trunk/nmdc-uri-scheme.txt?view=3Dlog&= gt;.

The index page of nmdc.s= f.net was incorrect, it did not have a news item for 1.2, which contain= more content. Note that the document is descriptive of the protocol and it= s implementations and not prescriptive. The protocol was built in 1999 (i.e= ., shortly after Napster and before BitTorrent) but it has been expanded up= on many times, but the original version was never made public, hence revers= e engineering efforts.

The protocol is very much still used today as it has be= en used in the past. There are still many users using the protocol daily.

Note that the URI was constructed by Jonathan Hess = for the original NMDC client and this is an attempt at a formalization of t= hat scheme. The phrasing of the scheme is such that some current implementa= tions only support a partial of the syntax listed. There haven't been a= ny innovation (to the best of my knowledge) in the URI scheme in the past y= ears.

I appreciate all suggestions and criticism. I didn'= t expect responses so quickly. :)

Ah, yeah, of course.

On Thu,= Feb 21, 2013 at 1:14 PM, Graham Klyne=A0<GK@ninebynine.org>= =A0wrote:
(a) some clear indication that there is good consensus in the relevant deve= loper community about what constitutes a suitable specification of the prot= ocol (preferably with indications that implementations conforming to aid sp= ecification are interoperable, but I wouldn't see that as a must-have r= equirement here).
I understand the concern, but I am unsure of the type of = necessary explicit consensus here. There are multiple implementations that = are interoperable - isn't that a de facto concensus? The protocol docum= ent does not specify what implementations support what, but I'm not sur= e if that'd be applicable in that type of document. (Another document p= erhaps that could be interesting.) It wouldn't be difficult to construc= t such an implementation matrix, it would simply require some time. (But ob= viously if that's necessary to be considered, then that is something th= at must be done.)
=A0
On Thu, Feb 21, 2013 at 1:14 PM, Graham Klyne=A0<GK@nin= ebynine.org>=A0wrote:
(b) some review within the IETF, or a community with corresponding security= expertise, of the security considerations. =A0As they stand, they look ver= y thin to me.
Noted, and I will discuss with others o= n potential reviews and revising of this section (see also below).

On Thu, Feb 21, 2013 at 7:13 PM, Eric Johnson=A0<eric@= tibco.com>=A0wrote:
The syntax section:

=A0* [a] discusses semantics. For example: "= ;The client should download the
=A0 =A0user's file list if path is o= mitted".
=A0* [b] doesn't actually reference the syntax compone= nts of RFC 3986. It
=A0 =A0doesn't explicitly exclude possible portions of the syntax, such= as
=A0 =A0fragment identifiers and queries. Am I to assume that those a= re
=A0 =A0allowed, but not specified in their use, or disallowed?
=A0= * [c] seems to allow "dchub://" as a valid URI, however, if I fol= low RFC
=A0 =A03986 properly, that is not a valid URI, and at least a "host&qu= ot; is
=A0 =A0required.
=A0* [d] Is RFC 3986 "userinfo" all= owed in the URI? If so, how does that
=A0 =A0interact with the protocol?=
a) Ah, ok. It could definitely move to the 'scheme' sema= ntics section.=A0
b/d) The syntax presented is what implementatio= ns support today. Anything else apart from the explicit syntax listed shoul= d be considered as 'not allowed' (save for an extension, which ther= e hasn't been any).
c) Ah, "dchub://" would indeed be wrong; a host is required.= Doesn't the current syntax require it? "dchub://<host>" As far as I can tell, that makes the= host required.

On Thu, Feb= 21, 2013 at 7:13 PM, Eric Johnson=A0<eric@tibco.com>=A0wrote:<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> The semantics section:

=A0* [e] should steal the portions from the s= yntax section that address the
=A0 =A0meaning of a particular form, and = further ought to tie that to
=A0 =A0specific portions of the spec. As in= "download the user's file list"
=A0 =A0- which NMDC messages does this correspond to?
=A0* [f] doesn'= ;t discuss at all how one might compare two of these URIs. Is
=A0 =A0the= user name case-sensitive? If characters occur that require
=A0 =A0encod= ing via %xx, should those be normalized first before comparison?
=A0* [g] Since the URI contains a path, does the path need to be normalized=
=A0 =A0before comparison?
e) Regarding protocol = message=A0correspondence: I wasn't aware that that was required/desirab= le. Wouldn't the protocol specification specify what commands were nece= ssary for that? I mean, in the event that the download command changes (a p= ortion of it has actually done that), one wouldn't want the URI scheme = to be too narrow. (Admittedly, there haven't been changes in this aspec= t in years, so there wouldn't be that much of a problem. I just find it= strange to have this type of information in an URI scheme.)
f/g) Nicks are not case-sensitive, as it is up to the hub to enforce t= his, although this is not specified anywhere in the spec. I'll make sur= e to add that as a note. =A0 Addresses should be treated likewise as case-i= nsensitive, and I'd say that any such normalization should be done befo= re comparison. How do other URI schemes specify this in a more=A0succinct= =A0manner?

On Thu, Feb 21, 2013 at 7:13 PM, Eric Johnson=A0<eric@tib= co.com>=A0wrote:
Under the "use" section:

=A0 * [h] An interoperability poi= nt is raised here that should be in the "interoperability" sectio= n.
h) I presume you mean "Not all implementations sup= port the user and path syntax". All right.

On Thu, Feb 21, 2013 at 7:13 PM, Eric Johnson=A0<eric@tibco.co= m>=A0wrote:
The security section:
* [i] Future implementations may care about using = TLS to secure
=A0 =A0communications. Will that need the use of "dch= ubs://", or is the
=A0 =A0intent that the "dchub:" scheme= can serve both purposes?
=A0* [j] Might one want to actually include some sort of indicator (such as= a
=A0 =A0hash) in the URI (as part of a query) so that a client can req= uest a
=A0 =A0file, and if the user or path has changed, and now points = to a
=A0 =A0completely different file, that the provider and consumer of said=A0 =A0URI will be able to detect the discrepancy?
=A0* [k] What of usi= ng weird constructs like "../../../foo/bar", as in
=A0 =A0&quo= t;dc-hub://host/myname/../../../foo" - does this need to make s= ure
=A0 =A0that cannot be used to retrieve a file that wasn't shared, or wa= sn't
=A0 =A0intended to be shared with the specific user.
=A0* [l= ] DOS attacks, or DDOS attacks?
=A0* [m] Homographs?
i) There are indeed implementations that support TLS, and they use the sy= ntax "nmdcs" (nmdcs://example.com<= /a>). There is, as far as I'm aware, an identical syntax and management= otherwise. Should that be part of this URI scheme or should it be filed as= a completely separate URI scheme?
j) NMDC uses tiger Tiger Tree Hashes (TTHs), so in theory your suggestion w= ould be fine. However, no implementation currently supports that type of sy= ntax.
k) Most (all) implementations have safe guards for the ../ behavio= ur. I suppose including a note about in the scheme is fine, although isn= 9;t it more general to have it in the protocol specification ("impleme= ntations should safe guard against relative paths when downloading")?<= /div>
l) Ah, yes, this was identified (and to some extent managed) years ago= . Clients connecting to a hub will now send a "referrer" during p= rotocol negotiation (search for 'ref' in the spec) (similar to an H= TTP referrer). A note in the URI scheme sounds good.
m) I wasn't aware that that was a security concern here?
=A0
On Thu, Feb 21, 2013 at 7:13 PM, Eric Johnson=A0&= lt;eric@tibco.com&g= t;=A0wrote:
The protocol itself ought to be filed as an RFC. That would pretty much gua= rantee permanence of the reference.
It has actually been discus= sed previously. I have a semi-complete document written, but it's far f= rom complete. I am also unsure of how one would manage messages that are no= w not used by any implementation. If people would feel that that would be t= he best approach, then I'm all for it.


I would like to invite people for discus= sion to the DC community. There is a development forum at http://dcbase.org as well as the development talk hub at= =A0adcs://hub.dcbase.org:16591 = (note that this is another URI scheme that is intended to be registered in = the future). (Download the application DC++, press Ctrl+Q and enter the adc= s:// address to join.) Is there perhaps an IRC channel otherwise where one = can discuss these things?

--=A0
Fredrik Ullner --90e6ba6e8358f6098504d6427779-- From cyrus@daboo.name Fri Feb 22 08:14:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A50321F8F58 for ; Fri, 22 Feb 2013 08:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 Wp8ZNCVdVewf for ; Fri, 22 Feb 2013 08:14:54 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id B9DB121F8F52 for ; Fri, 22 Feb 2013 08:14:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 573433DDB450 for ; Fri, 22 Feb 2013 11:14:54 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yy9v632nHNf for ; Fri, 22 Feb 2013 11:14:53 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 437F93DDB444 for ; Fri, 22 Feb 2013 11:14:53 -0500 (EST) Date: Fri, 22 Feb 2013 11:14:50 -0500 From: Cyrus Daboo To: apps-discuss@ietf.org Message-ID: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2270 Subject: [apps-discuss] iSchedule X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2013 16:14:55 -0000 Hi, For a while now a group of calendaring implementors (primarily within the Calendaring and Schedule Consortium - CalConnect) have been working on the iSchedule specification: . This specification aims to define a cross-domain calendaring and scheduling protocol based on existing IETF iCalendar (RFC 5545) and iTIP (RFC 5546) standards, using HTTP as the transport. We already have several experimental implementations of the protocol working interoperably (at the recent CalConnect event earlier this month we had four different implementations being tested). We are now at a point where we want broader IETF review (in particular apps and security areas) with the ultimate goal of developing this specification into a standard. Having consulted with Barry Leiba, we are initially bringing this for discussion within the Apps Area WG - and I would like to request time at the Orlando meeting to discuss the draft. There are two key pieces to this specification: iTIP over HTTP, and domain-level security. The first piece is pretty straight forward. The security piece is more complex. In our own discussions we determined that a domain-level security model was the important use case to tackle (at least at first). Given that, we settled on using DKIM (RFC 6376) - mostly because we did not want to invent anything new and DKIM is a somewhat well understood, deployed, interopable solution. Of course, up until now, DKIM has been used solely for email. However, the original intent of that work was to allow it to be extended to other protocols as the need might arise. To that end, some initial work was done on defining a more generic version: DOSETA - , though the current iSchedule spec is couched in terms of DKIM rather than DOSETA right now, mostly because work on DOSETA stalled. That is where we stand right now. We want to see a cross-domain scheduling standard produced by the IETF and believe our initial work on iSchedule is a good starting point. So this is a call to gauge interest in such work with the aim of perhaps having a BoF at the July meeting, or even a working group. -- Cyrus Daboo From eburger@standardstrack.com Sat Feb 23 05:10:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B394121F8FAC for ; Sat, 23 Feb 2013 05:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.216 X-Spam-Level: X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 puGq3OGjcVwy for ; Sat, 23 Feb 2013 05:10:09 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8B13321F8FAA for ; Sat, 23 Feb 2013 05:10:09 -0800 (PST) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:50498 helo=[192.168.15.177]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U9Ere-0006yq-8i; Sat, 23 Feb 2013 05:10:06 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric Burger In-Reply-To: Date: Sat, 23 Feb 2013 08:10:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <814AF276-FB5F-4553-95ED-DA011412D477@standardstrack.com> References: To: Cyrus Daboo X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] iSchedule X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2013 13:10:10 -0000 Cross post to the security directorate? On Feb 22, 2013, at 11:14 AM, Cyrus Daboo wrote: > Hi, > For a while now a group of calendaring implementors (primarily within = the Calendaring and Schedule Consortium - CalConnect) have been working = on the iSchedule specification: = . This = specification aims to define a cross-domain calendaring and scheduling = protocol based on existing IETF iCalendar (RFC 5545) and iTIP (RFC 5546) = standards, using HTTP as the transport. >=20 > We already have several experimental implementations of the protocol = working interoperably (at the recent CalConnect event earlier this month = we had four different implementations being tested). >=20 > We are now at a point where we want broader IETF review (in particular = apps and security areas) with the ultimate goal of developing this = specification into a standard. Having consulted with Barry Leiba, we are = initially bringing this for discussion within the Apps Area WG - and I = would like to request time at the Orlando meeting to discuss the draft. >=20 > There are two key pieces to this specification: iTIP over HTTP, and = domain-level security. The first piece is pretty straight forward. The = security piece is more complex. >=20 > In our own discussions we determined that a domain-level security = model was the important use case to tackle (at least at first). Given = that, we settled on using DKIM (RFC 6376) - mostly because we did not = want to invent anything new and DKIM is a somewhat well understood, = deployed, interopable solution. Of course, up until now, DKIM has been = used solely for email. However, the original intent of that work was to = allow it to be extended to other protocols as the need might arise. To = that end, some initial work was done on defining a more generic version: = DOSETA - , = though the current iSchedule spec is couched in terms of DKIM rather = than DOSETA right now, mostly because work on DOSETA stalled. >=20 > That is where we stand right now. We want to see a cross-domain = scheduling standard produced by the IETF and believe our initial work on = iSchedule is a good starting point. So this is a call to gauge interest = in such work with the aim of perhaps having a BoF at the July meeting, = or even a working group. >=20 > --=20 > Cyrus Daboo >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From Claudio.Allocchio@garr.it Sat Feb 23 05:41:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E2E21F8F35 for ; Sat, 23 Feb 2013 05:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTlYRDXya3MT for ; Sat, 23 Feb 2013 05:41:05 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9790F21F8F33 for ; Sat, 23 Feb 2013 05:41:05 -0800 (PST) Received: internal info suppressed Date: Sat, 23 Feb 2013 14:40:54 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.local To: Eric Burger In-Reply-To: <814AF276-FB5F-4553-95ED-DA011412D477@standardstrack.com> Message-ID: References: <814AF276-FB5F-4553-95ED-DA011412D477@standardstrack.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1361626855; bh=dXiQx4T2UG3qQlzzUieoSlzDJIjhTZbtBoZeev4VQps=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Eiy5nVhv7vXm2colBn4nc7ZztTh1n0ETHmXYYDzQ6WXI0pnPDz3Bpr/6C84plMu9M QyRifq7iYMagwl6rTyenv715ojlY0mOHFgO/sxRQt9yWTYvdGcJo39dSpDL3dRypsW 1MKUuJahYx793FTMGnyrXgIgEniVR/RssSku4uBk= Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] iSchedule X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2013 13:41:07 -0000 On Sat, 23 Feb 2013, Eric Burger wrote: > Cross post to the security directorate? I would do... yes. ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From dret@berkeley.edu Sat Feb 23 08:24:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EA421F8FAE for ; Sat, 23 Feb 2013 08:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.262 X-Spam-Level: X-Spam-Status: No, score=-6.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_15=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 3iORwDbNA8e0 for ; Sat, 23 Feb 2013 08:24:10 -0800 (PST) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 0C64921F8FCF for ; Sat, 23 Feb 2013 08:24:10 -0800 (PST) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretpro.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1U9HtL-0005qo-C8; Sat, 23 Feb 2013 08:24:09 -0800 Message-ID: <5128ED20.6030502@berkeley.edu> Date: Sat, 23 Feb 2013 17:24:00 +0100 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "t.petch" References: <5124D91C.1000703@berkeley.edu> <000901ce1023$3c4b7140$4001a8c0@gateway.2wire.net> <51263634.7040906@berkeley.edu> <015e01ce1052$3098b540$4001a8c0@gateway.2wire.net> In-Reply-To: <015e01ce1052$3098b540$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: REST Discuss , apps-discuss@ietf.org Subject: Re: [apps-discuss] process and editing questions: RFC errata X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2013 16:24:10 -0000 hello tom. On 2013-02-21 17:40 , t.petch wrote: > In passing, some lines of formal definition exceed the permitted length > for an RFC line so a little reorganising will be needed, probably best > sooner rather than later as they will need validating before the I-D can > advance and reorganising can introduce syntax errors. thanks for noting, https://raw.github.com/dret/I-D/master/xml-patch/draft-wilde-xml-patch-05.txt should look better (not yet submitted). > I may have missed the errata but I cannot recall a reference to them on > the apps-discuss list. If they are modified and then approved, which > usually happens, then your I-D should follow suit so the sooner they are > processed the better. Which might mean you requesting the AD to set the > wheels in motion, explaining why timeliness matters. the errata are still just in the "reported" state, http://www.rfc-editor.org/errata_search.php?rfc=5261 lists the 4 i have submitted. 3 of those now are actually part of the updates to RFC 5261 in the draft, so i am wondering whether these errata are needed anymore? ideally, my draft would update RFC 5261, and then the errata would be redundant, right? > And, out of curiosity, do you expect people to use XPath 1.0 or 2.0? I > ask because in Netconf, I was keen to specify 2.0 and not 1.0, the > handling of namespaces in 2.0 seemed superior, but was told we could not > because there were no implementations for people to use, that 2.0 was a > great idea that had not happened (mmm IPv6?). The Normative reference > for Yang remains the 1999 version. 2.0 is a vast improvement over 1.0, but it also is much more complex to implement. when 1.0 was released, XML was all the rage and there were a lot of people implementing specs. when 2.0 was released, the XML hyper curve already trended downward, plus it's just harder to implement. as a result it's true that it's surprisingly hard to find implementations of 2.0. so while personally, i always use 2.0 because you can write better code, it's true that in specs, if you can get away with 1.0, it may be a good idea to stick to it. 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 cabo@tzi.org Sun Feb 24 05:11:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B20A21F8FFA; Sun, 24 Feb 2013 05:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.237 X-Spam-Level: X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=0.012, 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 jbWoEu1jJfeN; Sun, 24 Feb 2013 05:11:22 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF5721F8FF7; Sun, 24 Feb 2013 05:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r1ODB9Z9020863; Sun, 24 Feb 2013 14:11:09 +0100 (CET) Received: from [192.168.217.135] (p54893FCD.dip.t-dialin.net [84.137.63.205]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8D9AE3156; Sun, 24 Feb 2013 14:11:08 +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: <7EB82E7A-F664-46F8-8137-83DF0C3F5536@tzi.org> Date: Sun, 24 Feb 2013 14:11:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85CB7BA1-2C92-4C52-A1C3-7FD430396725@tzi.org> References: <7EB82E7A-F664-46F8-8137-83DF0C3F5536@tzi.org> To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: [apps-discuss] msgpack/binarypack (Re: [Json] JSON mailing list and BoF) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 Feb 2013 13:11:29 -0000 On Feb 19, 2013, at 17:39, Carsten Bormann wrote: > On Feb 19, 2013, at 00:47, "Joe Hildebrand (jhildebr)" = wrote: >=20 >> As an individual, I'm +1 on that. I love msgpack, and don't mind the >> addition of UTF8 as a separate type. Was frsyuki involved in the = draft, >> or at least know that it happened? >=20 > I tried to involve him. Well, I did engage the msgpack community some more. You can find a transcript of some 275 messages about separating byte and = UTF-8 strings at: https://github.com/msgpack/msgpack/issues/121 Summary: Some members of the msgpack community are very enraged that this change = hasn't happened earlier. Of course, some have gone off and done their own incompatible forks. Others are very enraged that any change is happening at all, and that = new people are intruding on their turf. (And some probably feel guilty that it took a ****storm from outside to = finally make this change.) frsyuki is now working on a proposal that solves the problem: https://gist.github.com/frsyuki/5022569 The proposal is technically complete (and has already been implemented). It already is pretty good at the details, too, but this whole thing is = being done in a process that is closer to Japanese consensus processes = than to IETF culture. My -01 will be fully aligned with whatever the state of frsyuki's = proposal will be on Monday's I-D deadline (find today's snapshot at = http://www.tzi.de/~cabo/draft-bormann-apparea-bpack-01pre2.txt). (frsyuki's proposal may change some more, but those will in all = likelihood be minor details.) I think his overall thinking is fine, but it is much more dominated by a = requirement for backwards compatibility than an IETF process would be. So, the larger question on whether the msgpack community is ready to = take part (or just endure) in an IETF-style consensus process (including = handing over change control) still looms. That doesn't diminish from the requirement for a msgpack-like format, = and I think we should use Hallway Time in Orlando to discuss potential = ways forward. I any case, I definitely don't want to disturb the constructive = discussion about chartering a very narrow JSON fixup WG with this work. (I do want to find a home for it, soon, though: I want to build other = specs on top of it.) Gr=FC=DFe, Carsten From jan.algermissen@nordsc.com Mon Feb 25 00:04:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC5921F9223 for ; Mon, 25 Feb 2013 00:04:51 -0800 (PST) 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 rvyIYStQ2cio for ; Mon, 25 Feb 2013 00:04:50 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7670921F9221 for ; Mon, 25 Feb 2013 00:04:50 -0800 (PST) Received: from [172.20.10.2] (tmo-106-152.customers.d1-online.com [80.187.106.152]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Lla8x-1UjUzH42hr-00acCP; Mon, 25 Feb 2013 09:04:49 +0100 From: Jan Algermissen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 25 Feb 2013 09:04:45 +0100 To: "apps-discuss@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:3xLW/wbv5Ua76M1WBzlldo7pGFszXDSZ9lBBnLS6/BE fyI3E/306cA9FN2oebW3fTwXFv2eex3jzuN4bl2ISLMNeMaaOb 6ZxCtk936xj2VN/UDdrsmufoWIbMN9iLbgVFHTqY/j4bTyO1mW cqFpRrPj7fDL5WaCIrHmLCRDMj+JABs9qPqU2h5ezAjqydoW+S HgBvjUzVYYIlawXlUZSityJecP8pODPK7GXr24ANgQhMZoc5Cj L/N1hOlWlRcTu8Xn/2zYzTpaCe9W/63t9fOoZ31BgefVZrOaYc ZVfdoQlfTsT7SUd1HgYhRyM7pGCsQUgBZs7+q7Ar64ygFhDXL9 M5tz7W2hLDzNIe3Yg4e4Nq1m+z9pNtKyvUQY6InskFur4hRYHT G0pVZvc8WKYkA== Subject: [apps-discuss] Deprecation mechanism in JSON HOme Documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 25 Feb 2013 08:04:51 -0000 Hi Mark, in your latest draft of JSON Homep[1] you define a deprecation mechanism = that allows a provider to provide a hint to a consumer that a certain = described resource is in a deprecation period. As designed now, this mechanism cannot be used to hint the deprecation = of a certain provided media type: Suppose I have=20 "http://example.org/rel/widgets": { "href": "/widgets/", "hints": { "representations": ["application/widgetlist"] } } and at some point, I have to evolve the media type in an incompatible = way, yielding a new media type 'application/special-new-widgetlist'. To = support both, new and old clients, I'd let the types coexist: "http://example.org/rel/widgets": { "href": "/widgets/", "hints": { "representations": = ["application/widgetlist","application/special-new-widgetlist"], } } As time passes and clients pick up the shiny new media type, a point is = reached where I want to hint older clients that an upgrade is in order. = I'd like to deprecate the availability of the older media type = 'application/widgetlist'. However ... that is impossible right now since 'deprecated' only applies = to the resource as a whole - which I deliberately do *not* want to = change or remove. What are your thoughts? Is there a certain design decision behind your = approach that I am not seeing?=20 What do you think of augmenting the deprecation mechanism to something = like: "http://example.org/rel/widgets": { "href": "/widgets/", "hints": { "representations": = ["application/widgetlist","application/special-new-widgetlist"], "deprecated-representations" : ["application/widgetlist"] } } Jan [1] http://tools.ietf.org/html/draft-nottingham-json-home-02= From fgaliegue@gmail.com Mon Feb 25 05:42:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA21D21F9302 for ; Mon, 25 Feb 2013 05:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 Ykvx8Sf78gSZ for ; Mon, 25 Feb 2013 05:42:03 -0800 (PST) Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4154321F92F7 for ; Mon, 25 Feb 2013 05:42:03 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id i1so1198450eaa.18 for ; Mon, 25 Feb 2013 05:42:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=pmdzpXcyJSNBksG59W6uKTiAOCnMAfsHdZJzenK89J0=; b=WnI2my4dpOBTM4NOXISoirdySu9OJPP/xwFjDZjTiQsdoxlxMdC3mYHu8dQwvGV5vc eaRlFXvoGTG9ApF0eW1RdVKShAAwgbpARhfy70mZpmjn60jmf/rlevA5TEDHknKDnri6 Ww7kkM/0KTY1z01/puG5+6/Yqi5fKjpnkYU3JmzbqpVzY+t/T+iAFweAlwcmcuLB13/v VgMJWGz8toFpAucMfrjQZhuvQjmlVAOA8e+izRlyqgKZ1O491J8PSoNDVWH7+YHJgCYM 5gjy4OgAH0wYj+7ypwXxyofUMQvUr0l5p6rTFV4QeegyOXYgU9IgaU65kGacn+Ls6JNT T7Yw== MIME-Version: 1.0 X-Received: by 10.14.194.198 with SMTP id m46mr39008083een.8.1361799722324; Mon, 25 Feb 2013 05:42:02 -0800 (PST) Received: by 10.14.1.7 with HTTP; Mon, 25 Feb 2013 05:42:02 -0800 (PST) Date: Mon, 25 Feb 2013 14:42:02 +0100 Message-ID: From: Francis Galiegue To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [apps-discuss] JSON Schema for JSON Home X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 25 Feb 2013 13:42:05 -0000 Hello, I have written a JSON Schema for JSON Home, you can see the result here: https://github.com/fge/sample-json-schemas/blob/master/json-home/json-home.json -- Francis Galiegue, fgaliegue@gmail.com Try out your JSON Schemas: http://json-schema-validator.herokuapp.com From ietfc@btconnect.com Tue Feb 26 07:49:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B9C21F887F for ; Tue, 26 Feb 2013 07:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.688 X-Spam-Level: X-Spam-Status: No, score=-3.688 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_00=-2.599, J_CHICKENPOX_15=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 OHckBskLEwxz for ; Tue, 26 Feb 2013 07:49:54 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0DB21F883A for ; Tue, 26 Feb 2013 07:49:53 -0800 (PST) Received: from mail75-db3-R.bigfish.com (10.3.81.240) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Feb 2013 15:49:52 +0000 Received: from mail75-db3 (localhost [127.0.0.1]) by mail75-db3-R.bigfish.com (Postfix) with ESMTP id 17C1A2A0155; Tue, 26 Feb 2013 15:49:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz98dI9371I936eI148cI542I1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL177df4h17326ah8275bh8275dh19a27bh172cdfhz2dh2a8h5a9h668h839h93fhd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh304l1155h) Received: from mail75-db3 (localhost.localdomain [127.0.0.1]) by mail75-db3 (MessageSwitch) id 1361893789974594_16853; Tue, 26 Feb 2013 15:49:49 +0000 (UTC) Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.233]) by mail75-db3.bigfish.com (Postfix) with ESMTP id E1CC140018A; Tue, 26 Feb 2013 15:49:49 +0000 (UTC) Received: from AMSPRD0711HT004.eurprd07.prod.outlook.com (157.56.250.181) by DB3EHSMHS001.bigfish.com (10.3.87.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Feb 2013 15:49:46 +0000 Received: from AMXPRD0111HT004.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.242.14.165) with Microsoft SMTP Server (TLS) id 14.16.263.1; Tue, 26 Feb 2013 15:49:45 +0000 Message-ID: <03d401ce1438$69b95200$4001a8c0@gateway.2wire.net> From: t.petch To: Erik Wilde References: <5124D91C.1000703@berkeley.edu> <000901ce1023$3c4b7140$4001a8c0@gateway.2wire.net> <51263634.7040906@berkeley.edu> <015e01ce1052$3098b540$4001a8c0@gateway.2wire.net> <5128ED20.6030502@berkeley.edu> Date: Tue, 26 Feb 2013 15:16:57 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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.250.117] X-OriginatorOrg: btconnect.com Cc: REST Discuss , apps-discuss@ietf.org Subject: Re: [apps-discuss] process and editing questions: RFC errata X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Feb 2013 15:49:55 -0000 ----- Original Message ----- From: "Erik Wilde" To: "t.petch" Cc: ; "REST Discuss" Sent: Saturday, February 23, 2013 4:24 PM > hello tom. > > On 2013-02-21 17:40 , t.petch wrote: > > In passing, some lines of formal definition exceed the permitted length > > for an RFC line so a little reorganising will be needed, probably best > > sooner rather than later as they will need validating before the I-D can > > advance and reorganising can introduce syntax errors. > > thanks for noting, > https://raw.github.com/dret/I-D/master/xml-patch/draft-wilde-xml-patch-0 5.txt > should look better (not yet submitted). > > > I may have missed the errata but I cannot recall a reference to them on > > the apps-discuss list. If they are modified and then approved, which > > usually happens, then your I-D should follow suit so the sooner they are > > processed the better. Which might mean you requesting the AD to set the > > wheels in motion, explaining why timeliness matters. > > the errata are still just in the "reported" state, > http://www.rfc-editor.org/errata_search.php?rfc=5261 lists the 4 i have > submitted. 3 of those now are actually part of the updates to RFC 5261 > in the draft, so i am wondering whether these errata are needed anymore? > ideally, my draft would update RFC 5261, and then the errata would be > redundant, right? Yes, the errata would be redundant but my instinct would still be to go forward with them. They are simple, tightly defined, and so easier to discuss than a whole I-D (even if yours is pleasantly short). You would get a clearer outcome from a discussion of an erratum than from an I-D. Tom Petch > > > And, out of curiosity, do you expect people to use XPath 1.0 or 2.0? I > > ask because in Netconf, I was keen to specify 2.0 and not 1.0, the > > handling of namespaces in 2.0 seemed superior, but was told we could not > > because there were no implementations for people to use, that 2.0 was a > > great idea that had not happened (mmm IPv6?). The Normative reference > > for Yang remains the 1999 version. > > 2.0 is a vast improvement over 1.0, but it also is much more complex to > implement. when 1.0 was released, XML was all the rage and there were a > lot of people implementing specs. when 2.0 was released, the XML hyper > curve already trended downward, plus it's just harder to implement. as a > result it's true that it's surprisingly hard to find implementations of > 2.0. so while personally, i always use 2.0 because you can write better > code, it's true that in specs, if you can get away with 1.0, it may be a > good idea to stick to it. > > 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 Feb 27 06:17:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C6F21F8722 for ; Wed, 27 Feb 2013 06:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_15=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 Tif0SsLikh5K for ; Wed, 27 Feb 2013 06:17:32 -0800 (PST) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 18C0421F8628 for ; Wed, 27 Feb 2013 06:17:32 -0800 (PST) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] 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 1UAhp3-0000YW-GX; Wed, 27 Feb 2013 06:17:31 -0800 Message-ID: <512E1574.50504@berkeley.edu> Date: Wed, 27 Feb 2013 15:17:24 +0100 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "t.petch" , apps-discuss@ietf.org References: <5124D91C.1000703@berkeley.edu> <000901ce1023$3c4b7140$4001a8c0@gateway.2wire.net> <51263634.7040906@berkeley.edu> <015e01ce1052$3098b540$4001a8c0@gateway.2wire.net> <5128ED20.6030502@berkeley.edu> <03d401ce1438$69b95200$4001a8c0@gateway.2wire.net> In-Reply-To: <03d401ce1438$69b95200$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] draft-wilde-xml-patch and updates to RFC 5261 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Feb 2013 14:17:32 -0000 hello tom. On 2013-02-26 16:16 , t.petch wrote: >> the errata are still just in the "reported" state, >> http://www.rfc-editor.org/errata_search.php?rfc=5261 lists the 4 i have >> submitted. 3 of those now are actually part of the updates to RFC 5261 >> in the draft, so i am wondering whether these errata are needed anymore? >> ideally, my draft would update RFC 5261, and then the errata would be >> redundant, right? > Yes, the errata would be redundant but my instinct would still be to go > forward with them. They are simple, tightly defined, and so easier to > discuss than a whole I-D (even if yours is pleasantly short). You would > get a clearer outcome from a discussion of an erratum than from an I-D. the issue with the errata is that there doesn't seem to be a process around them. i have submitted them, and now they are just sitting there in "reported" state. i'd rather encourage people to look at http://tools.ietf.org/html/draft-wilde-xml-patch#appendix-A and then we can have a discussion and maybe updated versions of the draft. this way there's a process for how to fix the most pressing issues with RFC 5261. but one way or the other, feedback so far has been minimal. 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 presnick@qti.qualcomm.com Wed Feb 27 11:21:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7402F21F8AE2; Wed, 27 Feb 2013 11:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 XGdSiBlq0Dxb; Wed, 27 Feb 2013 11:21:56 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8C421F8A11; Wed, 27 Feb 2013 11:21:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1361992914; x=1393528914; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=G1NJol9yvE8xUdo7IWekj5pWas+M/X0Q1yqPAzTZpEc=; b=qxsc1Ivt9wnPiXdjCZIKtt2Be2fp5HzHqk7OlHk2MbK3TknHB88VHIYO M7K6Pp2V1kqQxVAsT+2RJHdlz7qfH8yr+CajeEy0ZGlyKRvcWPVHqmTQE a1e5QoM/+KnmabjsXakurTtmYTrxbeDRv/K3LMzlGDJj0Fb8D0Rh+z29H o=; X-IronPort-AV: E=Sophos;i="4.84,750,1355126400"; d="scan'208";a="26569703" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 27 Feb 2013 11:21:50 -0800 Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 27 Feb 2013 11:21:50 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 27 Feb 2013 11:21:49 -0800 Message-ID: <512E5CCC.2060407@qti.qualcomm.com> Date: Wed, 27 Feb 2013 13:21:48 -0600 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 , CardDAV , , Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: [apps-discuss] New mailing list: jcardcal X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Feb 2013 19:21:59 -0000 The mailing list for jcardcal is set up. Please subscribe if you're interested in this work. The charter is on the agenda of tomorrow's IESG telechat for approval, and I'd like to hit the ground running. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From algermissen1971@me.com Mon Feb 25 00:04:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B2D21F920D for ; Mon, 25 Feb 2013 00:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qxsiVWLvId2 for ; Mon, 25 Feb 2013 00:04:21 -0800 (PST) Received: from nk11p03mm-asmtp002.mac.com (nk11p03mm-asmtpout002.mac.com [17.158.232.237]) by ietfa.amsl.com (Postfix) with ESMTP id C5B6621F9221 for ; Mon, 25 Feb 2013 00:04:20 -0800 (PST) Received: from [172.20.10.2] ([80.187.106.152]) by nk11p03mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-26.01(7.0.4.26.0) 64bit (built Jul 13 2012)) with ESMTPSA id <0MIR00JJWNQTYE60@nk11p03mm-asmtp002.mac.com> for apps-discuss@ietf.org; Mon, 25 Feb 2013 08:04:13 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327,1.0.431,0.0.0000 definitions=2013-02-25_02:2013-02-22, 2013-02-25, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=41 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1302250000 From: algermissen1971 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Message-id: <1AD639E1-35D3-4F17-8C4C-FFD2CC2CAE5C@me.com> Date: Mon, 25 Feb 2013 09:04:06 +0100 To: "apps-discuss@ietf.org" MIME-version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Thu, 28 Feb 2013 00:31:44 -0800 Subject: [apps-discuss] Deprecation mechanism in JSON HOme Documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 25 Feb 2013 08:04:22 -0000 Hi Mark, in your latest draft of JSON Homep[1] you define a deprecation mechanism = that allows a provider to provide a hint to a consumer that a certain = described resource is in a deprecation period. As designed now, this mechanism cannot be used to hint the deprecation = of a certain provided media type: Suppose I have=20 "http://example.org/rel/widgets": { "href": "/widgets/", "hints": { "representations": ["application/widgetlist"] } } and at some point, I have to evolve the media type in an incompatible = way, yielding a new media type 'application/special-new-widgetlist'. To = support both, new and old clients, I'd let the types coexist: "http://example.org/rel/widgets": { "href": "/widgets/", "hints": { "representations": = ["application/widgetlist","application/special-new-widgetlist"], } } As time passes and clients pick up the shiny new media type, a point is = reached where I want to hint older clients that an upgrade is in order. = I'd like to deprecate the availability of the older media type = 'application/widgetlist'. However ... that is impossible right now since 'deprecated' only applies = to the resource as a whole - which I deliberately do *not* want to = change or remove. What are your thoughts? Is there a certain design decision behind your = approach that I am not seeing?=20 What do you think of augmenting the deprecation mechanism to something = like: "http://example.org/rel/widgets": { "href": "/widgets/", "hints": { "representations": = ["application/widgetlist","application/special-new-widgetlist"], "deprecated-representations" : ["application/widgetlist"] } } Jan [1] http://tools.ietf.org/html/draft-nottingham-json-home-02= From fltemplin@yahoo.com Mon Feb 25 10:46:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458BF21F9064 for ; Mon, 25 Feb 2013 10:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRf1ow5LhYE2 for ; Mon, 25 Feb 2013 10:46:04 -0800 (PST) Received: from nm14.bullet.mail.bf1.yahoo.com (nm14.bullet.mail.bf1.yahoo.com [98.139.212.173]) by ietfa.amsl.com (Postfix) with SMTP id 3D1F521F8FA6 for ; Mon, 25 Feb 2013 10:46:04 -0800 (PST) Received: from [98.139.214.32] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 25 Feb 2013 18:46:03 -0000 Received: from [98.139.212.226] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 25 Feb 2013 18:46:03 -0000 Received: from [127.0.0.1] by omp1035.mail.bf1.yahoo.com with NNFMP; 25 Feb 2013 18:46:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 568530.89918.bm@omp1035.mail.bf1.yahoo.com Received: (qmail 57094 invoked by uid 60001); 25 Feb 2013 18:46:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361817963; bh=rPuAQklq5Y4HNvj9cP0OEC3fhBaiHo/PI9C57KqD2uM=; 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=52NjmZBOVbQMiFnEFMt7I1H4Fp2CZz94zfsunLsq27fB0VQXMQgM9IArm4gSxZrkNNba2TIJaCHsf63j2wgbUTVv72oIcOE5eE/Oz/f2oMUBhFlrsEpr076/gtnhWuzQ/QsjViiyhuKdy5uLH8mLvxClt2+hdHNBWy1G2BrNXS8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zJfapotqo4GSL8mUIuWyKFIOhoCQbD6z4JcUtzKLA37RXbSGWWlVKXxP2heU9Vg5QK1xQlkHW987MdD9DOBEEXBvS1OBeEcDjYy5OeTuaB8tEneXzh0HIRK2XG0NNe13T7oCfphfeqgCAwL7IS24zh+LBWbzGooHJFnM0qRTMMc=; X-YMail-OSG: AY.5gykVM1kJ9GQhqU0NuiJedGc5q5MIU17OTC_1TcDs.7o YcZXmEeP9L6ZysW0NPtJy_KFpUxpa0Z.TqOfslTXeQYZYfH5b0qtOjCNK5Vj PFRAwsxX4EJjCc945UL8UtNjJ2.z_bwngQv.5RNUORK4pzZDu3ZJDwUE98eQ KhxuF8MRijOXUKK6Tlam8pQiRzyQj1faqMb_nyIhi5kOozdLoyTGprVRapZW mVCTCSnTFlw0y_rbHEf8hEgngraXbggcbDMEi8Bf3sIZPuvm7Ug8PpUYM7vZ 5pdFgvNXb_7qKaJpfYSkacdNOOsC6xlR6DeW1Xzw_hunGsMJ6lKfNPHu20uP YnyKcgwlCfdT45CtknueR78qGG2bNKfIvSb4JE2jF3acSzWHg_06DVPY.S2Y Gq97diNgeCGhT7TE4_FMbXDQJDN6WX4Q74Yc765At1kQ5dZWzg7Oz2UQ8Xf0 FmHi6V_pEVeuU9UdHRTwpvxHtUovYcIbtwSMmHRhuiYJJFycnwnKtUWDrrJQ 9cGweye7eIqyzXv0v Received: from [130.76.32.50] by web161903.mail.bf1.yahoo.com via HTTP; Mon, 25 Feb 2013 10:46:03 PST X-Rocket-MIMEInfo: 001.001, SGVsbG8gTXVycmF5LAoKVGhhbmsgeW91IGZvciB0aGVzZSBjb21tZW50cywgYW5kIGFwb2xvZ2llcyBmb3IgdGhlIGRlbGF5LiBJbiB0aGUgaW50ZXJlc3Qgb2Ygc2Vla2luZwpjbG9zdXJlLCBwbGVhc2Ugc2VlIGJlbG93IGZvciBwcm9wb3NlZCByZXNvbHV0aW9ucy4KCkZyZWQKZmx0ZW1wbGluQGFjbS5vcmcKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBNdXJyYXkgUy4gS3VjaGVyYXd5IDxzdXBlcnVzZXJAZ21haWwuY29tPgo.VG86IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzsBMAEBAQE- X-RocketYMMF: fltemplin X-Mailer: YahooMailWebService/0.8.135.514 References: <201302210835.r1L8ZCpP078686@medusa.blackops.org> Message-ID: <1361817963.46040.YahooMailNeo@web161903.mail.bf1.yahoo.com> Date: Mon, 25 Feb 2013 10:46:03 -0800 (PST) From: "Fred L. Templin" To: "Murray S. Kucherawy" , "apps-discuss@ietf.org" , "draft-templin-ironbis.all@tools.ietf.org" In-Reply-To: <201302210835.r1L8ZCpP078686@medusa.blackops.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 28 Feb 2013 00:31:54 -0800 Cc: "iesg@ietf.org" Subject: Re: [apps-discuss] AppsDir reivew of draft-templin-ironbis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Fred L. Templin" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 18:46:06 -0000 Hello Murray,=0A=0AThank you for these comments, and apologies for the dela= y. In the interest of seeking=0Aclosure, please see below for proposed reso= lutions.=0A=0AFred=0Afltemplin@acm.org=0A=0A=0A>___________________________= _____=0A> From: Murray S. Kucherawy =0A>To: apps-discu= ss@ietf.org; draft-templin-ironbis.all@tools.ietf.org =0A>Cc: iesg@ietf.org= =0A>Sent: Thursday, February 21, 2013 12:35 AM=0A>Subject: AppsDir reivew = of draft-templin-ironbis=0A> =0A>I have been selected as the Applications A= rea Directorate (appsdir) reviewer=0A>for this draft.=A0 (For background on= appsdir, please see=0A>http://trac.tools.ietf.org/area/app/trac/wiki/Appli= cationsAreaDirectorate).=0A>=0A>Please resolve these comments along with an= y other Last Call comments you may=0A>receive.=A0 Please wait for direction= from your document shepherd or AD before=0A>posting a new version of the d= raft.=0A>=0A>Document: draft-templin-ironbis-12=0A>Title: The Intradomain R= outing Overlay Network (IRON)=0A>Reviewer: Murray S. Kucherawy=0A>Review Da= te: February 20, 2013=0A>IETF Last Call Date: January 30, 2013=0A>IESG Tele= chat Date: February 21, 2013=0A>=0A>Summary: This document appears to be re= ady for evaluation and approval.=0A>However, most of the content exceeds my= areas of expertise, so I have=0A>focused only on trying to find those part= s that appear likely to affect=0A>applications in a direct way, or on IETF = procedural points.=0A>=0A>Apologies for the tardiness of the review.=0A>=0A= >Major Issues: None.=A0 This appears like interesting work, but I infer=0A>= from the document's content that most of the work here concerns operations= =0A>well below and thus not visible to the application layer.=0A>=0A>Minor = Issues: The [RO-CR] and [SAMPLE] references don't appear to point to=0A>I-D= s, though they say "Work in Progress".=A0 If they are I-Ds, they should be= =0A>named; if not, I don't believe those references are complete.=A0 Where = are=0A>they published?=0A=0AThese references do have corresponding I-Ds. Th= e I-Ds will be identified=0Ain the next document version.=0A=0A>Nits: I cou= ldn't parse the last sentence of Section 10:=0A>=0A>=A0=A0=A0IRON does not = otherwise introduce any new issues to complications raised=0A>=A0=A0=A0for = NAT traversal or for applications embedding address referrals=0A>=A0=A0=A0i= n their payload.=0A>=0A>"issues to complications raised"?=0A=0AHere is a pr= oposed rewrite:=0A=0A=A0 " IRON does not otherwise introduce any new compli= cations for NAT traversal or=0A=A0=A0=A0 for applications embedding address= referrals in their payload."=0A=0A>=0A>=0A> From Simo.Veikkolainen@nokia.com Wed Feb 27 23:17:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360FA21F8ABC; Wed, 27 Feb 2013 23:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 meal8X5rJQtA; Wed, 27 Feb 2013 23:17:51 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E3DF721F8AB4; Wed, 27 Feb 2013 23:17:50 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r1S7HQ0q015351; Thu, 28 Feb 2013 09:17:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Feb 2013 09:17:47 +0200 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.248]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0318.003; Thu, 28 Feb 2013 07:18:18 +0000 From: To: , Thread-Topic: APPSDIR review of draft-ietf-mmusic-sdp-cs-17 Thread-Index: AQHOCKvcBLMX2ekxO025FTQwjWe2YpiO8XjQ Date: Thu, 28 Feb 2013 07:22:33 +0000 Message-ID: References: <511978FD.2080306@bell-labs.com> In-Reply-To: <511978FD.2080306@bell-labs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.5.9.3 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7ImSeTXTf0E37UgezLnVIyyXBU17OgCQCs0NCX56XXCUbDGW0CT8BFtUJKU+lbdNfhnTnlNI4whBMY6wAhhu1X9P2KXVVID+xVanyMWOuqflcAx3QCBgHYzsgRQZFJaf7e2uoZmtQNktq5uXBPbb0BnshI0T3WqAxV1CGZ+HbpNX/CJFnBcHhgfbhxhBzdLhAtHP+Kb99b6V+d2OHhGBIk4rSKeOWjh7XDTgnBxPhkBWetjOhZ7LidZtECSUcHC5WwA== x-originating-ip: [10.236.10.80] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2013 07:17:48.0040 (UTC) FILETIME=[B61A5080:01CE1583] X-Nokia-AV: Clean X-Mailman-Approved-At: Thu, 28 Feb 2013 00:32:08 -0800 Cc: fandreas@cisco.com, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-mmusic-sdp-cs-17 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2013 07:17:52 -0000 SGVsbG8gVmlqYXksDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcuIFBsZWFzZSBmaW5kIG15 IHJlc3BvbnNlcyBpbmxpbmUgW1NWXS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGV4dCBWaWpheSBLLiBHdXJiYW5pIFttYWlsdG86dmtnQGJlbGwtbGFicy5jb21dIA0KU2Vu dDogMTIuIGhlbG1pa3V1dGEgMjAxMyAxOjA0DQpUbzogZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLWNz QHRvb2xzLmlldGYub3JnDQpDYzogYXBwcy1kaXNjdXNzQGlldGYub3JnOyBJRVNHIElFU0c7IGZh bmRyZWFzQGNpc2NvLmNvbQ0KU3ViamVjdDogQVBQU0RJUiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1t bXVzaWMtc2RwLWNzLTE3DQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBBcHBsaWNhdGlv bnMgQXJlYSBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdCAoZm9yIGJhY2tncm91 bmQgb24gYXBwc2RpciwgcGxlYXNlIHNlZSDigIsgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcv YXJlYS9hcHAvdHJhYy93aWtpL0FwcGxpY2F0aW9uc0FyZWFEaXJlY3RvcmF0ZSApLg0KDQpQbGVh c2UgcmVzb2x2ZSB0aGVzZSBjb21tZW50cyBhbG9uZyB3aXRoIGFueSBvdGhlciBMYXN0IENhbGwg Y29tbWVudHMgeW91IG1heSByZWNlaXZlLiBQbGVhc2Ugd2FpdCBmb3IgZGlyZWN0aW9uIGZyb20g eW91ciBkb2N1bWVudCBzaGVwaGVyZCBvciBBRCBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9u IG9mIHRoZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1jcy0xNw0K VGl0bGU6IFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkgRXh0ZW5zaW9uIEZvciBT ZXR0aW5nIFVwDQogIEF1ZGlvIGFuZCBWaWRlbyBNZWRpYSBTdHJlYW1zIE92ZXIgQ2lyY3VpdC1T d2l0Y2hlZCBCZWFyZXJzIEluIFRoZQ0KICBQdWJsaWMgU3dpdGNoZWQgVGVsZXBob25lIE5ldHdv cmsgKFBTVE4pDQpSZXZpZXdlcjogVmlqYXkgSy4gR3VyYmFuaQ0KUmV2aWV3IERhdGU6IEZlYi0x MS0yMDEzDQpJRVRGIExhc3QgQ2FsbCBEYXRlOiBOb3Qga25vd24NCklFU0cgVGVsZWNoYXQgRGF0 ZTogTm90IGtub3duDQoNClN1bW1hcnk6IFRoaXMgZHJhZnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0 aW9uIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQuDQpBIGZldyBpc3N1ZXMgdGhhdCBzaG91bGQgYmUg bG9va2VkIGF0IGJlZm9yZSBwdWJsaWNhdGlvbiBhcmUgbGlzdGVkIGJlbG93Lg0KDQpNYWpvciBJ c3N1ZXM6IDANCg0KTWlub3IgSXNzdWVzOiAzDQoNCk5pdHM6IDINCg0KTWlub3I6DQotLS0tLQ0K LSBTNS4yLjE6IFNEUCBzeW50YXggaXMgYz08bmV0dHlwZT4gPGFkZHJ0eXBlPiA8Y29ubmVjdGlv bi1hZGRyZXNzPi4NCiAgVG93YXJkcyB0aGUgYm90dG9tIG9mIFM1LjIuMSwgaXQgaXMgc2FpZCB0 aGF0ICJXaGVuIHRoZSA8YWRkcnR5cGU+IGlzDQogIFBTVE4gLi4uIi4gIFNob3VsZCBpdCBub3Qg YmUgIldoZW4gdGhlIDxuZXR0eXBlPiBpcyBQU1ROIC4uLiI/DQoNCltTVl0gQWN0dWFsbHksIGl0 IHNob3VsZCByZWFkICJXaGVuIHRoZSA8YWRkcnR5cGU+IGlzIEUxNjQuLi4iDQoNCi0gUzUuMi4x LCB0b3dhcmRzIHRoZSBlbmQgaXQgc2F5cyB0aGF0IHdoZW4gdGhlIDxhZGRydHlwZT4gaXMgIi0i LCB0aGUNCiAgPGNvbm5lY3Rpb24tYWRkcmVzcz4gbWF5IGJlICJhbnkgc3ludGFjdGljYWxseSB2 YWxpZCB2YWx1ZSwgd2hpY2ggaXMNCiAgdG8gIGJlIGlnbm9yZWQiLiAgQSBjb3VwbGUgb2YgcG9p bnRzIG9uIHRoaXM6IG9uZSwgSSBhbSBsZWZ0IHB1enpsaW5nDQogIHdoYXQgaXMgdGhlIHN5bnRh Y3RpY2FsbHkgY29ycmVjdCB2YWx1ZSBoZXJlLCBhbmQgc2Vjb25kbHksIGlmIHRoZQ0KICB2YWx1 ZSBpcyAgdG8gYmUgaWdub3JlZCwgd2h5IGJvdGhlciB0aGF0IGl0IGlzIHN5bnRhY3RpY2FsbHkg Y29ycmVjdD8NCiAgTXkgYWR2aWNlIHdvdWxkIGJlIHRvIHJld29yZCB0aGUgYnVsbGV0IGl0ZW0g YXMgZm9sbG93czoNCg0KICAgIGFueSB2YWx1ZSByZXN1bHRpbmcgZnJvbSB0aGUgcHJvZHVjdGlv biBydWxlIG9mIGNvbm5lY3Rpb24tYWRkcmVzcw0KICAgIGluIFJGQzQ1NjYgW1JGQzQ1NjZdLCBi dXQgaW4gYWxsIGNhc2VzIGFueSB2YWx1ZSBlbmNvdW50ZXJlZCB3aWxsDQogICAgYmUgaWdub3Jl ZC4NCg0KW1NWXSBUaGUgcHVycG9zZSBpcyB0aGF0IHBhcnNlcnMgd2lsbCBhY2NlcHQgdGhlIHZh bHVlIHBhc3NlZCBpbiB0aGUgPGNvbm5lY3Rpb24tYWRkcmVzcz4gZmllbGQsIGJ1dCB0aGF0IHZh bHVlIGlzIGFjdHVhbGx5IG5vdCB1c2VkIGZvciBhbnl0aGluZyBieSB0aGUgYXBwbGljYXRpb24u IEhvdyBhYm91dCBtb2RpZnlpbmcgdGhlIHByb3Bvc2VkIHRleHQgYSBiaXQgdG8gcmVhZDoNCg0K ICAgIGFueSB2YWx1ZSByZXN1bHRpbmcgZnJvbSB0aGUgcHJvZHVjdGlvbiBydWxlIG9mIGNvbm5l Y3Rpb24tYWRkcmVzcw0KICAgIGluIFJGQzQ1NjYgW1JGQzQ1NjZdLCBidXQgaW4gYWxsIGNhc2Vz IHRoaXMgdmFsdWUgd2lsbCBiZSBpZ25vcmVkLg0KDQotIFM1LjIuMy4xLCBzZWNvbmQgcGFyYWdy YXBoOiB0aGVyZSBhcHBlYXJzIHRvIGJlIGEgc3B1cmlvdXMgIj4iIGluDQogICJTZWN0aW9uIDUu Nz4gZGVmaW5lZCB0aGUgZm9ybWFsIHN5bnRheC4iLiAgUGx1cywgeW91IHByb2JhYmx5IHdhbnQg dG8NCiAgc2F5ICJTZWN0aW9uIDUuNyBkZWZpbmVzIHRoZSBmb3JtYWwgc3ludGF4LiIgIFRoZSBs YXN0IHNlbnRlbmNlIG9mIHRoZQ0KICBzdWItc2VjdGlvbiBpcyByZWR1bmRhbnQgdG8gdGhpcyBv bmUuICBQZXJoYXBzIHlvdSBjYW4gdGFrZSB0aGlzDQogIHNlbnRlbmNlIG91dCBhbmQgbGV0IHRo ZSBsYXN0IG9uZSByZW1haW4uDQoNCltTVl0gQWdyZWVkLCBkZWxldGVkIHRoZSBmaXJzdCBzZW50 ZW5jZS4NCg0KTml0czoNCi0tLS0tDQotIFM2LjEsIEZpZ3VyZSAzIGFuZCA0OiBJbiBGaWd1cmUg NCwgYmV0dGVyIHRvDQogIHMvbz1qZG9lL289YWxpY2UvIHRvIG1ha2UgdGhlIGludGVudCBjb25m b3JtIGJldHRlciB0byBGaWd1cmUgMy4NCiAgQWxpY2UgaXMgdGhlIG9yaWdpbmF0b3Igb2YgdGhl IGNhbGwuDQoNCiAgRGl0dG8gZm9yIEZpZ3VyZXMgNiBhbmQgNy4NCg0KW1NWXSBEb25lLg0KDQot IFM3LCBzZWNvbmQgcGFyYWdyYXBoOiBzL3dlbGxrbm93bi93ZWxsIGtub3duLw0KDQpbU1ZdIERv bmUuDQoNClJlZ2FyZHMsDQpTaW1vDQoNClRoYW5rcywNCg0KLSB2aWpheQ0KLS0NClZpamF5IEsu IEd1cmJhbmksIEJlbGwgTGFib3JhdG9yaWVzLCBBbGNhdGVsLUx1Y2VudA0KMTk2MCBMdWNlbnQg TGFuZSwgUm0uIDlDLTUzMywgTmFwZXJ2aWxsZSwgSWxsaW5vaXMgNjA1NjMgKFVTQSkNCkVtYWls OiB2a2dAe2JlbGwtbGFicy5jb20sYWNtLm9yZ30gLyB2aWpheS5ndXJiYW5pQGFsY2F0ZWwtbHVj ZW50LmNvbQ0KV2ViOiAgIGh0dHA6Ly9lY3QuYmVsbC1sYWJzLmNvbS93aG8vdmtnLw0K From superuser@gmail.com Thu Feb 28 06:21:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C4721F8B33 for ; Thu, 28 Feb 2013 06:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfupLwc+f8xD for ; Thu, 28 Feb 2013 06:21:54 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4F46421F86F4 for ; Thu, 28 Feb 2013 06:21:39 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id z53so1571670wey.29 for ; Thu, 28 Feb 2013 06:21:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=s6QTdVdHxQcIkIPK5XBITI3QAurZELqz6KnoeBgFgPc=; b=zgqGpXzus6YwLy+IMZhaG9vjqqPbYuF82821hvz7yokBmdOXdQYfrM53kFtdbN1oOa 46tzq20UNdDg+8RgImnjLAFsRaSZ3rgwkJ61rqh9GrEROgXzlFmJj5An3ECU4Lrhkf7U IPdohdP47Ps+DKo+8WfJblsCPjQR9DslMZirSh5SL9kbuBmZy0vitVc4IdV9WgE5wKmh rmtLoiYZix1LI7VVK6/gQ2cSQ1ou1loWee2VHPnqu7jI6xXDC0IlBgQWXCQ3+PBTY7m/ eDHb0HZsO6J8TQUFYJBl/U06ls4uFTjjP6sEByDiU+NHEG2K6rP3Ze14D/lwrs61ABJz JSwQ== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr11221992wjc.35.1362061299215; Thu, 28 Feb 2013 06:21:39 -0800 (PST) Received: by 10.180.163.70 with HTTP; Thu, 28 Feb 2013 06:21:38 -0800 (PST) Date: Thu, 28 Feb 2013 06:21:38 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e013d1da8e6f35804d6c99bdc Subject: [apps-discuss] Preliminary agenda available X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 14:21:58 -0000 --089e013d1da8e6f35804d6c99bdc Content-Type: text/plain; charset=ISO-8859-1 Hello all, The preliminary agenda for our session at IETF 86 in Orlando is now visible at https://datatracker.ietf.org/meeting/86/agenda/appsawg/. We have room in our agenda for people who wish to present to this working group suggestions for new work that's within our charter to consider, and for other topics that might be of interest to our specific audience. Please email your requests to appsawg-chairs@tools.ietf.org, including the subject of the requested presentation and a requested amount of time. The final agenda needs to be submitted by mid-day (my time) Monday, so please get your requests in ASAP. If you have previously submitted a request, please send it again to ensure we don't miss it. -MSK, APPSAWG co-chair --089e013d1da8e6f35804d6c99bdc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all,

The preliminary agenda for our= session at IETF 86 in Orlando is now visible at https://datatracker.ietf.org/meet= ing/86/agenda/appsawg/.

We have room in our agenda for people who wish to present to this worki= ng group suggestions for new work that's within our charter to consider= , and for other topics that might be of interest to our specific audience.= =A0 Please email your requests to appsawg-chairs@tools.ietf.org, including the subject of the req= uested presentation and a requested amount of time.

The final agenda needs to be submitted by mid-day (my time) Monda= y, so please get your requests in ASAP.=A0 If you have previously submitted= a request, please send it again to ensure we don't miss it.

-MSK, APPSAWG co-chair
--089e013d1da8e6f35804d6c99bdc-- From ietfc@btconnect.com Thu Feb 28 07:38:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395EB21F8BA7 for ; Thu, 28 Feb 2013 07:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, J_CHICKENPOX_15=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 hT9vSuqlFY4j for ; Thu, 28 Feb 2013 07:38:07 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7C621F8BAB for ; Thu, 28 Feb 2013 07:38:07 -0800 (PST) Received: from mail85-db3-R.bigfish.com (10.3.81.226) by DB3EHSOBE008.bigfish.com (10.3.84.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Feb 2013 15:38:05 +0000 Received: from mail85-db3 (localhost [127.0.0.1]) by mail85-db3-R.bigfish.com (Postfix) with ESMTP id D5792800FB; Thu, 28 Feb 2013 15:38:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz98dI9371I936eI542I1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL177df4h17326ah8275dh19a27bh172cdfh8275bhz2dh2a8h5a9h668h839h93fhd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h304l1155h) Received: from mail85-db3 (localhost.localdomain [127.0.0.1]) by mail85-db3 (MessageSwitch) id 1362065883978675_7568; Thu, 28 Feb 2013 15:38:03 +0000 (UTC) Received: from DB3EHSMHS014.bigfish.com (unknown [10.3.81.243]) by mail85-db3.bigfish.com (Postfix) with ESMTP id E2A6C2004B; Thu, 28 Feb 2013 15:38:03 +0000 (UTC) Received: from DBXPRD0710HT005.eurprd07.prod.outlook.com (157.56.253.197) by DB3EHSMHS014.bigfish.com (10.3.87.114) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Feb 2013 15:37:59 +0000 Received: from DBXPRD0411HT001.eurprd04.prod.outlook.com (157.56.253.165) by pod51017.outlook.com (10.255.79.168) with Microsoft SMTP Server (TLS) id 14.16.263.1; Thu, 28 Feb 2013 15:37:58 +0000 Message-ID: <015c01ce15c9$17585dc0$4001a8c0@gateway.2wire.net> From: t.petch To: Erik Wilde , References: <5124D91C.1000703@berkeley.edu> <000901ce1023$3c4b7140$4001a8c0@gateway.2wire.net> <51263634.7040906@berkeley.edu> <015e01ce1052$3098b540$4001a8c0@gateway.2wire.net> <5128ED20.6030502@berkeley.edu> <03d401ce1438$69b95200$4001a8c0@gateway.2wire <512E1574.50504@berkeley.edu> Date: Thu, 28 Feb 2013 15:33:40 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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.253.165] X-OriginatorOrg: btconnect.com Subject: Re: [apps-discuss] draft-wilde-xml-patch and updates to RFC 5261 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2013 15:38:08 -0000 Erik Errata have a process and it works:-) You posted errata against RFC5261, an RFC which was produced by simple. Therefore notification of the errata went to the simple WG mailing list which was shut down two days ago so your good work has found a very effective black hole. How about forwarding the messages that the RFC-Editor produced to the apps-discuss list, for further discussion? Normally, the AD picks up an erratum and runs with it but since the WG has shut down, doubtless the ADs have as well, so you will need to find a friendly AD elsewhere, or you might want to start with a friendly WG chair. As you are doubtless aware, there will soon be an IETF meeting in Orlando, so chairs and ADs are rather busy right now. If you plan to be there, you could even ask the chairs for a slot on the agenda. Tom Petch ----- Original Message ----- From: "Erik Wilde" To: "t.petch" ; Sent: Wednesday, February 27, 2013 2:17 PM Subject: draft-wilde-xml-patch and updates to RFC 5261 > hello tom. > > On 2013-02-26 16:16 , t.petch wrote: > >> the errata are still just in the "reported" state, > >> http://www.rfc-editor.org/errata_search.php?rfc=5261 lists the 4 i have > >> submitted. 3 of those now are actually part of the updates to RFC 5261 > >> in the draft, so i am wondering whether these errata are needed anymore? > >> ideally, my draft would update RFC 5261, and then the errata would be > >> redundant, right? > > Yes, the errata would be redundant but my instinct would still be to go > > forward with them. They are simple, tightly defined, and so easier to > > discuss than a whole I-D (even if yours is pleasantly short). You would > > get a clearer outcome from a discussion of an erratum than from an I-D. > > the issue with the errata is that there doesn't seem to be a process > around them. i have submitted them, and now they are just sitting there > in "reported" state. i'd rather encourage people to look at > http://tools.ietf.org/html/draft-wilde-xml-patch#appendix-A and then we > can have a discussion and maybe updated versions of the draft. this way > there's a process for how to fix the most pressing issues with RFC 5261. > but one way or the other, feedback so far has been minimal. > > 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 barryleiba.mailing.lists@gmail.com Thu Feb 28 07:51:34 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0857F21F8B70 for ; Thu, 28 Feb 2013 07:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.959 X-Spam-Level: X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=0.018, 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 8KhGLD636E2k for ; Thu, 28 Feb 2013 07:51:07 -0800 (PST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id CEFE621F87C3 for ; Thu, 28 Feb 2013 07:51:06 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id n11so1306937vch.33 for ; Thu, 28 Feb 2013 07:51:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9bAhE8drnGC1kxl4UTOH89fsCHZSSRreR+2+v+aOUM4=; b=HJxm4VG4HgrcTMIzc8mW7IeZJCN3G7ar64XZx0V/MZ9pMdlci0BIddYLRcq+7RtzEi 1Ui/L9++YnDcoNbltLqWxjZVQM6OMbuL0o+8kpmke9WFnkTW4bmCooysb+yil4nZ/2zB HB0qIjca1H13373dcWZd5pR9jOUMewSqdrKMAgvsfZM8JV/7BsIaBLHUzQ14Z7a1Cg94 1oF62Z3RrP6y/KDfAOczoYjA1uMeDe2X7/+LckdkpGcn6E/+ykvn/1Fx75KutSiqHD5e rNlQloyng/q9B5Kd3F9xaXcNOrov695evn0vPq6ETa0FKvBwv0Dw1S05HD3OFY9kCW7/ BiTQ== MIME-Version: 1.0 X-Received: by 10.220.116.5 with SMTP id k5mr2684196vcq.55.1362066660762; Thu, 28 Feb 2013 07:51:00 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Thu, 28 Feb 2013 07:51:00 -0800 (PST) In-Reply-To: <015c01ce15c9$17585dc0$4001a8c0@gateway.2wire.net> References: <5124D91C.1000703@berkeley.edu> <000901ce1023$3c4b7140$4001a8c0@gateway.2wire.net> <51263634.7040906@berkeley.edu> <015e01ce1052$3098b540$4001a8c0@gateway.2wire.net> <5128ED20.6030502@berkeley.edu> <512E1574.50504@berkeley.edu> <015c01ce15c9$17585dc0$4001a8c0@gateway.2wire.net> Date: Thu, 28 Feb 2013 10:51:00 -0500 X-Google-Sender-Auth: 9yijXyvbynydjWRQM6692DI6J-s Message-ID: From: Barry Leiba To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-wilde-xml-patch and updates to RFC 5261 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2013 15:51:35 -0000 > You posted errata against RFC5261, an RFC which was produced by simple. > Therefore notification of the errata went to the simple WG mailing list > which was shut down two days ago so your good work has found a very > effective black hole. ... > Normally, the AD picks up an erratum and runs with it but since the WG > has shut down, doubtless the ADs have as well, so you will need to find > a friendly AD elsewhere This is nonsensical. Errata are associated with the area that the document was produced in.[1] Even if the RFC came from an individual submission (no WG) or from a WG that has closed (recently, or years ago), the ADs for the area the report is assigned to will see it, and will eventually deal with it. The IESG has been putting more emphasis, over the past couple of years, on handling errata and keeping the number left at "Reported" to an absolute minimum. The RAI ADs will deal with this one, I'm sure. Barry [1] Errata against very old RFCs can get into a sort of "black hole" situation if they are not assigned to an area. That's not an issue in this case. From vkg@bell-labs.com Thu Feb 28 10:24:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A2A21F8BF1; Thu, 28 Feb 2013 10:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tfe9MjhQtiya; Thu, 28 Feb 2013 10:24:28 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id C6EAE21F8BD4; Thu, 28 Feb 2013 10:24:27 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r1SIOPkW022033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Feb 2013 12:24:26 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r1SIOPjU021151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Feb 2013 12:24:25 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r1SIOO8a010622; Thu, 28 Feb 2013 12:24:24 -0600 (CST) Message-ID: <512FA171.2040505@bell-labs.com> Date: Thu, 28 Feb 2013 12:26:57 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: <511978FD.2080306@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: fandreas@cisco.com, apps-discuss@ietf.org, draft-ietf-mmusic-sdp-cs@tools.ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-mmusic-sdp-cs-17 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2013 18:24:28 -0000 On 02/28/2013 01:22 AM, Simo.Veikkolainen@nokia.com wrote: > Hello Vijay, > > Thank you for your review. Please find my responses inline [SV]. [...] Simo: Thank you for addressing my review comments; I do not have any further comments on the draft. Have a nice day! - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/