Re: [Jcardcal] Stephen Farrell's No Objection on draft-ietf-jcardcal-jcal-09: (with COMMENT)

Philipp Kewisch <kewisch@gmail.com> Mon, 24 March 2014 22:15 UTC

Return-Path: <kewisch@gmail.com>
X-Original-To: jcardcal@ietfa.amsl.com
Delivered-To: jcardcal@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F621A02ED; Mon, 24 Mar 2014 15:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgzxl7IKp9CJ; Mon, 24 Mar 2014 15:15:30 -0700 (PDT)
Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 174E21A02A2; Mon, 24 Mar 2014 15:15:29 -0700 (PDT)
Received: by mail-bk0-f51.google.com with SMTP id 6so3106bkj.10 for <multiple recipients>; Mon, 24 Mar 2014 15:15:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=J3oMT/YD5XjLxiB502U/DlbKoa4wTYe20qLmWm9Vxxs=; b=XLEHVBfxGbegNCdA2T3cOuHDjz7aTWv9PcOXi9aO1nUgjUFfwnZ+YzYNgwx6dISS9H cOcXb9nKPnJz3Qi04FX8TCJr3DiapEDBV3viOZnf+5BPWaJMOEUUX+C7v+53Vk8T8E0D lzTWEXcT8BMk5Wj3jGPl7nMsfGJiF6PZp+iOilQJNzBCm8uW1Kpn+8cKQBjF/H2tBfCa bIZJw6EZnA3UfbGzlMSy4GlWfMdCRWC0iNyNmbN4tof5+E7rIHzbCXy+38LR+EyLPk1L 1cHemux3OeUuiRLJPsxzeUgRiC5zlnfgOhz+ctAoK7j2lnnjiOIpw3LUiIvJsarlVvRf x6NA==
X-Received: by 10.204.65.72 with SMTP id h8mr46782bki.39.1395699328651; Mon, 24 Mar 2014 15:15:28 -0700 (PDT)
Received: from [192.168.2.104] (p5DC1549E.dip0.t-ipconnect.de. [93.193.84.158]) by mx.google.com with ESMTPSA id z3sm16001510bkn.3.2014.03.24.15.15.27 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Mar 2014 15:15:27 -0700 (PDT)
Message-ID: <5330AE7E.30509@gmail.com>
Date: Mon, 24 Mar 2014 23:15:26 +0100
From: Philipp Kewisch <kewisch@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Barry Leiba <barryleiba@computer.org>
References: <20140324210114.12842.55998.idtracker@ietfa.amsl.com> <CALaySJLf14Mvjkqmb46DyPq5jhORiq_X_p4T28fxhHhKOcLRdw@mail.gmail.com> <5330A6C9.7040103@cs.tcd.ie>
In-Reply-To: <5330A6C9.7040103@cs.tcd.ie>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/jcardcal/CxQI6HM0bFBspN0WW8c7XGNNwfs
Cc: draft-ietf-jcardcal-jcal@tools.ietf.org, The IESG <iesg@ietf.org>, jcardcal-chairs@tools.ietf.org, "jcardcal@ietf.org" <jcardcal@ietf.org>
Subject: Re: [Jcardcal] Stephen Farrell's No Objection on draft-ietf-jcardcal-jcal-09: (with COMMENT)
X-BeenThere: jcardcal@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: JSON data formats for vCard and iCalendar WG <jcardcal.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jcardcal>, <mailto:jcardcal-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jcardcal/>
List-Post: <mailto:jcardcal@ietf.org>
List-Help: <mailto:jcardcal-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jcardcal>, <mailto:jcardcal-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Mar 2014 22:15:32 -0000

On 3/24/14, 10:42 PM, Stephen Farrell wrote:
>> What it's saying is that jCal is
>> designed to accommodate extensions to iCalendar, without requiring
>> changes to jCal.  It's not talking about changes that might show up in
>> a new major iCalendar version... just changes that use the normal
>> iCalendar extension mechanisms.
> Yep. My comment is really that it'd be better to say
> what to avoid doing in any future such RFCs instead of
> just saying "You're not allowed to be naughty." But
> just a comment, if you think its fine that's ok too.
>
>
I personally think its fine, the introduction to that list says its
merely a design consideration, i.e "we designed jCal so that extensions
to iCalendar won't require changes to this document". There is nothing
in particular to avoid in an extension to iCalendar, as long as the
extension has backwards compatibility to iCalendar in mind, which will
certainly be the case.

Thank you for the comment though, if this weren't a design consideration
I'd agree that we could change the wording and make it more clear what
needs to be done.

Philipp