From nobody Mon Aug 4 08:19:31 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862061B2B5C for ; Mon, 4 Aug 2014 08:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-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 meUQ2m9dfoWc for ; Mon, 4 Aug 2014 08:19:19 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C101B2B50 for ; Mon, 4 Aug 2014 08:19:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 0C4454B1307; Mon, 4 Aug 2014 11:17:36 -0400 (EDT) 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 cIWcKCx2Qe0P; Mon, 4 Aug 2014 11:17:34 -0400 (EDT) Received: from [10.0.1.22] (unknown [17.45.162.184]) by daboo.name (Postfix) with ESMTPSA id 1924E4B12F9; Mon, 4 Aug 2014 11:17:32 -0400 (EDT) Date: Mon, 04 Aug 2014 11:19:11 -0400 From: Cyrus Daboo To: alfiej@fastmail.fm, Ken Murchison , calsify@ietf.org Message-ID: <094FA782153195D4F06BAEAA@cyrus.local> In-Reply-To: <1406764838.1326199.147492586.2D4C6DB5@webmail.messagingengine.com> References: <1406763267.1318305.147484602.1D689093@webmail.messagingengine.com> <53D984E3.9090409@andrew.cmu.edu> <1406764838.1326199.147492586.2D4C6DB5@webmail.messagingengine.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2205 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/bna4gFbnIAOczyBZQlLcSEKEa4A Subject: Re: [calsify] PROPOSAL: TZID = Olson database Zone name X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 15:19:25 -0000 Hi Alfie, --On July 30, 2014 at 8:00:38 PM -0400 Alfie John wrote: > On Wed, Jul 30, 2014, at 07:50 PM, Ken Murchison wrote: >> Are you proposing something like this: >> http://tools.ietf.org/html/draft-daboo-caldav-timezone-ref-01 > > Almost, but not quite. That RFC talks about applying to CalDAV but not > for the actual payload e.g this RFC would have no affect on an iCalendar > object within email attachments (e.g. iMIP). That would be problematic because the Olson DB is one of several in common use right now. The other major one is, of course, the Microsoft Windows timezone DB. I don't think we can legitimately favor one over the other. Note that the IETF is in the process of chartering a working group to define a timezone data distribution service (). One thing that is explicitly out of scope for that work is the "naming process for timezone identifiers". That statement was added precisely because it is a hard topic to get consensus on (e.g., there are a lot of people that feel that the "region/city" style Olson naming is wrong, and instead there should be "opaque" identifiers etc). Now it may well be that once the WG completes the work it is chartered to do, it could revisit your issue - basically generalizing the CalDAV "timezones-by-reference" approach to be applicable to iCalendar as a whole. I think if we are going to do that, one option is to setup a new registry for timezone names (ones that do not use the "/" prefix). Provided there is no overlap between Olson DB and MS Windows DB names, we could register both sets and clients would be able to rely on those as "stable" identifiers - perhaps in conjunction with timezone data distribution services. Of course that is going to require buy-in by the entire community of timezone DB publishers as they will need to agree on using the registration service to avoid conflicts with others - or the registration process will need some way to disambiguate new TZ ids. In any case, I suggest you participate in the new WG and bring this issue to its attention as a potential area that may need more work. -- Cyrus Daboo From nobody Wed Aug 6 10:34:11 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE3D1A0B14; Wed, 6 Aug 2014 10:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 ojndlqJ5C-bv; Wed, 6 Aug 2014 10:34:04 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E415E1A0444; Wed, 6 Aug 2014 10:33:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id BBBDF4E6E78; Wed, 6 Aug 2014 13:32:00 -0400 (EDT) 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 eRZoU16EqrWO; Wed, 6 Aug 2014 13:31:59 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id A87BD4E6E6D; Wed, 6 Aug 2014 13:31:57 -0400 (EDT) Date: Wed, 06 Aug 2014 13:33:48 -0400 From: Cyrus Daboo To: Alissa Cooper , The IESG Message-ID: <533B5C82F8E3D0DF3060BD9A@caldav.corp.apple.com> In-Reply-To: <20140806171554.6093.39339.idtracker@ietfa.amsl.com> References: <20140806171554.6093.39339.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1853 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/8XDglv6gDJzPcPE_1W1-Id8Nhow Cc: calsify@ietf.org Subject: Re: [calsify] Alissa Cooper's Yes on charter-ietf-calext-00-00: (with COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 17:34:08 -0000 Hi Alissa, --On August 6, 2014 at 10:15:54 AM -0700 Alissa Cooper wrote: > "Define a set of new iCalendar properties and parameters to standardise > some existing experimental X- properties. This will include a new set of > "top-level" properties for the "CALENDAR" component, as well as an new > "IMAGE" property to allow users more control of the visual appearance of > events and tasks within their calendars." > > Are there specific X- properties the group intends to standardize besides > the IMAGE property (assuming "IMAGE" is an example of such a property, > which I'm not sure about)? The use of "some" in the first sentence makes > it sound like there is some expected subset of existing properties that > will be in scope, but they're not listed. > A set of properties have already been identified in draft-daboo-icalendar-extensions as initial input to this WG. Some of those in that draft come from the Wikipedia list (), others (like IMAGE and CONFERENCE) are entirely new. It may be better to rephrase the above point in the charter to two separate ones, one covering standardizing X- properties, and one for completely new properties: - Define a set of new iCalendar properties and parameters to standardise some existing experimental X- properties in common use, based on a survey of existing implementations. - Define a set of new iCalendar properties and parameters to cover key uses cases that implementers have identified, including, but not limited to, a new "IMAGE" property (to allow embedding/linking of images tied to a specific event), and a "CONFERENCE" property (to allow embedding information about dial-in numbers and similar multi-party communication options for an event). -- Cyrus Daboo From nobody Fri Aug 8 09:12:45 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3801B28AF; Fri, 8 Aug 2014 09:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 YM-5lqzJT4Wp; Fri, 8 Aug 2014 09:12:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7A91B2B91; Fri, 8 Aug 2014 09:12:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140808161239.23444.52437.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 09:12:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/O6L5njuy5_3zVw7ZtrA3MRWs0J4 Cc: calext WG Subject: [calsify] WG Review: Calendaring Extensions (calext) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 16:12:42 -0000 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-08-18. Calendaring Extensions (calext) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Barry Leiba Mailing list Address: calsify@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/calsify Archive: http://www.ietf.org/mail-archive/web/calsify/ Charter: Calendaring Extensions (calext) ----------------------------------------------------------- The Calendaring Extensions working group is chartered to develop extensions to the iCalendar (RFC 5545), iTIP (RFC 5546), and CalDAV (RFC 4791) standards. This working group will do the following: - Develop an extension to iCalendar to support non-Gregorian recurrence rules, without the need to support new calendar scale values in iCalendar as a whole. This will allow for easy implementation of the primary use case for non-Gregorian support in calendar systems, without the need for significant changes to the iCalendar format. The non-Gregorian calendar system should be based on the International Components for Unicode work by the Unicode Consortium (http://site.icu-project.org). - Develop an extension to iCalendar to support a new component type that allows users to express arbitrary, possibly repeating, periods of "available" time. The primary use case for this is for users to express their "office hours" (e.g., Monday-Friday, 9am-5pm) in a standard way to ensure free busy lookups show the correct periods of availability. - Define a set of new iCalendar properties and parameters to standardise some existing experimental X- properties. This will include a new set of "top-level" properties for the "CALENDAR" component, as well as an new "IMAGE" property to allow users more control of the visual appearance of events and tasks within their calendars. The working group will work under the following parameters: - The extensions developed are expected to be backwards-compatible with the existing calendar standards. Incompatibilities must be identified, minimized, and justified. - For each set of extensions, examine their impact on the iTIP protocol (RFC 5546), and define any necessary extensions to iTIP to accommodate such impact. - For each set of extensions, examine their impact on the CalDAV protocol (RFC 4791), and define any necessary extensions to CalDAV to accommodate such impact. The working group will use the following drafts as initial input for its work: draft-daboo-icalendar-rscale-03 draft-daboo-calendar-availability-05 draft-daboo-icalendar-extensions-08 The following are out of scope for the working group: - Any change that significantly impacts backwards compatibility with existing deployed iCalendar/iTIP/CalDAV clients and servers. - Any attempt to develop non-Gregorian calendar systems/calculations. Milestones: TBD From nobody Mon Aug 18 07:46:01 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBCF1A047B; Mon, 18 Aug 2014 07:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 hdO2_cTVu67m; Mon, 18 Aug 2014 07:45:58 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069FE1A0476; Mon, 18 Aug 2014 07:45:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 3804E5FE21D; Mon, 18 Aug 2014 10:42:37 -0400 (EDT) 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 sJfJfgS37VCc; Mon, 18 Aug 2014 10:42:35 -0400 (EDT) Received: from [17.45.162.252] (unknown [17.45.162.252]) by daboo.name (Postfix) with ESMTPSA id 068FD5FE212; Mon, 18 Aug 2014 10:42:33 -0400 (EDT) Date: Mon, 18 Aug 2014 10:45:51 -0400 From: Cyrus Daboo To: Bradley White , tzdist@ietf.org, calsify@ietf.org Message-ID: <618B0C114A25A593E80BD07B@cyrus.local> In-Reply-To: References: X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1729 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/ARxWos7EnEXCsMX61QrC2JDTGro Subject: Re: [calsify] [Tzdist] Time Zone Distribution Protocol X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 14:45:59 -0000 Hi Bradley, --On August 14, 2014 at 5:45:41 PM -0400 Bradley White wrote: > A long time ago there was a proposal on the "tz" mailing list to return > zoneinfo data in a DNS TXT record in response to a query for a domain name > like New_York.America.zoneinfo.tz. As far as I know nothing ever came of > it. As Daniel pointed out there are a bunch of reasons why DNS might not be appropriate - but it is definitely worth hearing from everyone else on that issue to make sure there is good consensus one way or the other. Now, as for zoneinfo itself: one thing discussed by Mike and I (and others at CalConnect who helped with our draft), was the possibility of allowing actual zoneinfo files to be distributed via the tzdist protocol. We tried to build in extensibility that would allow that. The key thing we would need is a MIME content-type to be defined for the zoneinfo format - e.g. something like "application/timezone+zoneinfo". With that, a tzdist server could advertise that it can return data in that format (in addition to the iCalendar format we currently support). If we did that, then operating systems that used the zoneinfo format could become tzdist clients, and update their data directly from a tzdist server rather than relying on regular operating system update processes to do so. Any other timezone data format could be treated in a similar way (e.g., someone could come up with an interchange format for the Windows time zone data stored in the Windows registry and arrange for that to be distributed via tzdist). I think all of that is out of scope for this WG right now, beyond making sure we have proper extensibility in the tzdist protocol itself. -- Cyrus Daboo From nobody Mon Aug 18 07:59:34 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CCC1A04AC; Mon, 18 Aug 2014 07:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 bn1RC4i3HBpd; Mon, 18 Aug 2014 07:59:32 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5F51A0460; Mon, 18 Aug 2014 07:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1524; q=dns/txt; s=iport; t=1408373972; x=1409583572; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=lHK2BSxHMsMEZP8hucwvtSmkKOSwJIhXbKGpWl+PatQ=; b=XpXDRvpjKkF1AnT4QcPJUePP/icye+a+/laE8FXUDWaFmFGcmxZTWiRq XmULukblpGNtMu+L6Frox3JYFkUalmzlwlLo6E2HmHm8KQ8IvhTvV3YOQ d3p3zQddy5bI9SvMKQCkgXsba1bNArc3znmCmQPeeKQT4V4t0xD2+81UI 4=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAG4T8lOtJssW/2dsb2JhbABZhzPRVgGBM3eEBAEBBCNVARALDgoJFgsCAgkDAgECAUUGAQwBBwEBiD6sD5UBF49MB4J5gVMBBJMlgUqHU4cqjVmDXzuCfgEBAQ X-IronPort-AV: E=Sophos;i="5.01,886,1400025600"; d="asc'?scan'208";a="146185261" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 18 Aug 2014 14:59:29 +0000 Received: from [10.61.111.204] (dhcp-10-61-111-204.cisco.com [10.61.111.204]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s7IExTnu021187; Mon, 18 Aug 2014 14:59:29 GMT Message-ID: <53F214D1.1090004@cisco.com> Date: Mon, 18 Aug 2014 16:59:29 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tobias Conradi , Cyrus Daboo References: <618B0C114A25A593E80BD07B@cyrus.local> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qvkuTMwPjsT7fEH5F6WA6KhIopUsCx7Jx" Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/zSISMWvBjJhXsl6qyoYQBYwZfGQ Cc: tzdist@ietf.org, Bradley White , calsify@ietf.org Subject: Re: [calsify] [Tzdist] Time Zone Distribution Protocol X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 14:59:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qvkuTMwPjsT7fEH5F6WA6KhIopUsCx7Jx Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/18/14, 4:55 PM, Tobias Conradi wrote: > > These are governed by Paul Eggert. He can change the format at any > point he likes. Specifying in a RFC a format that itself is not > governed by any formal standard looks weird to me. But I am new to > IETF. Is there any current RFC that does this? Happens all the time. In essence the IETF builds containers for lots of content, and that is what MIME itself provides the means to move; whether it is standardized or not. It just has to be properly identified. That's what an IANA registration is for. Eliot --qvkuTMwPjsT7fEH5F6WA6KhIopUsCx7Jx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJT8hTRAAoJEIe2a0bZ0noztwYIAJywxhg6GFyuegzyxc2hfjUd j08AqY/sT1/92qG8u739+Rjb04tJGwXitwchKuPBT03njkwnKm8Homwg2nWVSjY4 cZljmF3MRo+0104nRYRC+kJGLLvF8qjuz8K3Q0BbOCE6Bc50nF5YdJPZQ6bFueUQ jGhBaC8s6U9Ms98VjyLIk/Ndv4OjxcFX7mhRo3TreZD+t6FOAO12eWuBlVDCH8aF oU9bjGhpxUV+Vomvt/9p+J7aTsEVS03pAqFf7vHi4yZdvdn7z4rar4OJ32iuZF3N 3S41N5PrBk30fXSTRNiX0OarBg5x1wR6K8tZJZO4iQaxQBjhSYYdGqWWw6JWkB8= =z+lw -----END PGP SIGNATURE----- --qvkuTMwPjsT7fEH5F6WA6KhIopUsCx7Jx-- From nobody Mon Aug 18 15:03:05 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9B71A86E2; Mon, 18 Aug 2014 15:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 UHp95jSQpycR; Mon, 18 Aug 2014 15:02:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E6A1A86DF; Mon, 18 Aug 2014 15:02:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140818220257.21065.98944.idtracker@ietfa.amsl.com> Date: Mon, 18 Aug 2014 15:02:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/Lmx3R3nMkTj9nP94nGBXD1SB5MI Cc: calsify@ietf.org Subject: [calsify] Spencer Dawkins' No Objection on charter-ietf-calext-00-02: (with COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 22:03:00 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-calext-00-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-calext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This all looks fine. One question for my benefit. "- Define a set of new iCalendar properties and parameters to standardise some existing experimental X- properties in common use, based on a survey of existing implementations." I wasn't quite sure whether this meant standardizing an "X-Foo" experimental property, or standardizing a renamed "Foo:". It's unlikely that needs to be stated in a charter, either way, but just in case it does ... if the deliverable was "standardise some existing experimental properties", I wouldn't have thought to ask, but given the existence of http://tools.ietf.org/html/rfc6648, I wondered. From nobody Tue Aug 19 07:22:40 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548D51A0376; Tue, 19 Aug 2014 07:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 hUA1gjeeERbX; Tue, 19 Aug 2014 07:22:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFCA1A02E6; Tue, 19 Aug 2014 07:22:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140819142236.3740.57137.idtracker@ietfa.amsl.com> Date: Tue, 19 Aug 2014 07:22:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/peZas6APWCYkBhPzNXdGu7qngJA Cc: calsify@ietf.org Subject: [calsify] Adrian Farrel's No Objection on charter-ietf-calext-00-02: (with COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:22:38 -0000 Adrian Farrel has entered the following ballot position for charter-ietf-calext-00-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-calext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection, but... > out of scope for the working group: > > - Any change that significantly impacts backwards compatibility with > existing deployed iCalendar/iTIP/CalDAV clients and servers. I wonder whether what you consider as significant is the same as what I would call significant. From nobody Tue Aug 19 07:25:19 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5471C1A02F4; Tue, 19 Aug 2014 07:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 bSVQPO_dHKwT; Tue, 19 Aug 2014 07:25:16 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09BAB1A02E6; Tue, 19 Aug 2014 07:25:15 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id ty20so5974180lab.4 for ; Tue, 19 Aug 2014 07:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=u5ZdZxLffHKjDAn8kPtlXfst7Ivj2LaHZDjLgAIxQIM=; b=u1RG5s2xLDCN8rBDvMficLyOY2rcrwoauJrGzQyaR9GPmRDZvFZT9OjsPhalFm9Zv7 1C+BsdhHQWrnbXq7UTYxNoslR2IG53zJrQh4bo2zCXYw2Mz1mt2gCMDx3IMw7hM52Fhm MfZiWBmt98QRrKuJu8w548lcFQjAGhZDGDLddTre8hGIMkDPfL6mgM+JNHcu6L+bC93l KgJlSTspzRzPWq452J0evWVu+djxdUAcXHgTV+LSWU18aC6dBpz9oeFa1Uj4JnPl+e0T 2crTyODj+WPEDElRejRbpVVcawl/i7lNHucVb7R1yIxX+BhN8fY7UT1pTW3ZwEBmUxD+ XV0w== MIME-Version: 1.0 X-Received: by 10.112.53.137 with SMTP id b9mr34999677lbp.16.1408458314360; Tue, 19 Aug 2014 07:25:14 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Tue, 19 Aug 2014 07:25:14 -0700 (PDT) In-Reply-To: <20140819142236.3740.57137.idtracker@ietfa.amsl.com> References: <20140819142236.3740.57137.idtracker@ietfa.amsl.com> Date: Tue, 19 Aug 2014 10:25:14 -0400 X-Google-Sender-Auth: 3_G8AB4ZiKaiOViIGINl_dKKnhc Message-ID: From: Barry Leiba To: Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/aPSLZT65Ssy6mYbqOG2WhyjyMkM Cc: The IESG , calsify@ietf.org Subject: Re: [calsify] Adrian Farrel's No Objection on charter-ietf-calext-00-02: (with COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:25:17 -0000 >> - Any change that significantly impacts backwards compatibility with >> existing deployed iCalendar/iTIP/CalDAV clients and servers. > > I wonder whether what you consider as significant is the same as what I > would call significant. We want to be able to leave that to the judgment of the working group, consulting with the AD. It's meant to be relatively soft, while still allowing the chairs to push back when they have to. Barry From nobody Tue Aug 19 07:31:38 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337901A033C; Tue, 19 Aug 2014 07:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 vowaYiBCe6VV; Tue, 19 Aug 2014 07:31:34 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DDF1A0376; Tue, 19 Aug 2014 07:31:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 583B8618795; Tue, 19 Aug 2014 10:28:06 -0400 (EDT) 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 c6zIihk8KqAM; Tue, 19 Aug 2014 10:28:04 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 4B5D4618787; Tue, 19 Aug 2014 10:28:03 -0400 (EDT) Date: Tue, 19 Aug 2014 10:31:27 -0400 From: Cyrus Daboo To: Spencer Dawkins , The IESG Message-ID: <880A81601093BB14EF07B96D@caldav.corp.apple.com> In-Reply-To: <20140818220257.21065.98944.idtracker@ietfa.amsl.com> References: <20140818220257.21065.98944.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1438 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/vmgdm02bul9SdejMZTBfb24e6jE Cc: calsify@ietf.org Subject: Re: [calsify] Spencer Dawkins' No Objection on charter-ietf-calext-00-02: (with COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:31:37 -0000 Hi Spencer, --On August 18, 2014 at 3:02:57 PM -0700 Spencer Dawkins wrote: > This all looks fine. One question for my benefit. > > "- Define a set of new iCalendar properties and parameters to > standardise > some existing experimental X- properties in common use, based on a > survey of existing implementations." > > I wasn't quite sure whether this meant standardizing an "X-Foo" > experimental property, or standardizing a renamed "Foo:". It's unlikely > that needs to be stated in a charter, either way, but just in case it > does ... if the deliverable was "standardise some existing experimental > properties", I wouldn't have thought to ask, but given the existence of > http://tools.ietf.org/html/rfc6648, I wondered. > My personal goal is to try and get rid of X- usage as per RFC6648 and encourage use of properly registered names, and that is what the current draft I wrote tries to do (replace various X- items with non X- registered equivalents). The original iCalendar spec, RFC 2445, did not have a formal registration process for names and many of the existing X- items we want to deal with here are from that era. When we updated iCalendar via RFC5545 we added IANA registries and a fairly lightweight process for new properties that do not impact any standards track behaviors. So the hope is that all new names will be registered and avoid the X- prefix. -- Cyrus Daboo From nobody Tue Aug 19 07:39:25 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A25A1A8917; Tue, 19 Aug 2014 07:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 A59jtWUi-TQv; Tue, 19 Aug 2014 07:39:18 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FF11A8913; Tue, 19 Aug 2014 07:39:17 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7JEcunL015163; Tue, 19 Aug 2014 15:38:56 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7JEcrLD015133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Aug 2014 15:38:54 +0100 From: "Adrian Farrel" To: "'Barry Leiba'" References: <20140819142236.3740.57137.idtracker@ietfa.amsl.com> In-Reply-To: Date: Tue, 19 Aug 2014 15:38:51 +0100 Message-ID: <029201cfbbbb$4ceb9620$e6c2c260$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKNxLD/6nYwBDqohzbwi/L0Y7olJwMDpMUYmkPO3TA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20892.005 X-TM-AS-Result: No--8.928-10.0-31-10 X-imss-scan-details: No--8.928-10.0-31-10 X-TMASE-MatchedRID: csPTYAMX1+ErQ4Lf8bCdwQPZZctd3P4BIaLR+2xKRDK0RBo5DN7B/2d8 NQw82eCfFehwRSdLR+VkKf5GiWmg41PhD3wYqtxvVZ54ioe2Ewu3dp6DuD+6wCIWzbRXGr/CFEc adR8cJwaqaCNIMhjCUFxXPCDgqHlYkht40vkDXQ2aVoAi2I40/btW9LeKKGvbxSZxKZrfThMWEf EhzALUXqDSVQtz/XwU8lwAlZiM6/dNfs8n85Te8v7E6GNqs6ce3QfwsVk0UbuGrPnef/I+eplvK FvsxtiyERzKbxDmusvlqIqzKarOqZ92d5eB71urw2tMTSg0x74= Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/4FDaD7riTIm9clteVCER7yYQZKk Cc: 'The IESG' , calsify@ietf.org Subject: Re: [calsify] Adrian Farrel's No Objection on charter-ietf-calext-00-02: (with COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:39:21 -0000 Perfect. Suppose we say so? Something like... - Any change that impacts backwards compatibility with existing deployed iCalendar/iTIP/CalDAV clients and servers will be discussed by the working group with a view to minimizing disruption to deployed implementations without compromising desirable new function. Adrian > -----Original Message----- > From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry > Leiba > Sent: 19 August 2014 15:25 > To: Adrian Farrel > Cc: The IESG; Cyrus Daboo; calsify@ietf.org > Subject: Re: Adrian Farrel's No Objection on charter-ietf-calext-00-02: (with > COMMENT) > > >> - Any change that significantly impacts backwards compatibility with > >> existing deployed iCalendar/iTIP/CalDAV clients and servers. > > > > I wonder whether what you consider as significant is the same as what I > > would call significant. > > We want to be able to leave that to the judgment of the working group, > consulting with the AD. It's meant to be relatively soft, while still > allowing the chairs to push back when they have to. > > Barry From nobody Tue Aug 19 07:41:55 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C781A8917; Tue, 19 Aug 2014 07:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 JJSXfzduoGMy; Tue, 19 Aug 2014 07:41:49 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BC351A891B; Tue, 19 Aug 2014 07:41:49 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id hz20so5798045lab.8 for ; Tue, 19 Aug 2014 07:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=PxCUtkboHCUGDMvDdkMnJRj8+V4CHcFVahR+6qZxka0=; b=HUQaLq6YZ6ruuwgEwcp5i9FcElX46fpyODITadiLp+UpEOGDSZ+6s1NshaS4nr+/P3 6EES658Jlbp2A8b8lyItXAlNF+SqVg3ItPZSDGFA5MXnjdYrJIBvcOSI48OCabnHnFh/ /1Ui0S4MJRi8lN0lRzVCNPO/S90mfsYYb+MRm+9UimcUWBa4Ueko6OpL6lzl2vdccFHc uG/pcXstWCMboeGm4mi+SYV2S7nJgY9ru5tUIwX21NyzVfnfDeHzewIT/b1hYI7Qjhao nxPdZ4cYPG1qa2NxoCRHq4skkA+MfCLCoGeFu6/JPKodsD0Ma7oOautW+/C4Zl0Z5SSy KKLw== MIME-Version: 1.0 X-Received: by 10.112.189.97 with SMTP id gh1mr16064933lbc.40.1408459307221; Tue, 19 Aug 2014 07:41:47 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Tue, 19 Aug 2014 07:41:47 -0700 (PDT) In-Reply-To: <029201cfbbbb$4ceb9620$e6c2c260$@olddog.co.uk> References: <20140819142236.3740.57137.idtracker@ietfa.amsl.com> <029201cfbbbb$4ceb9620$e6c2c260$@olddog.co.uk> Date: Tue, 19 Aug 2014 10:41:47 -0400 X-Google-Sender-Auth: YIB4uOYCs_ZCok5-JpFYicWNfug Message-ID: From: Barry Leiba To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/YmwoXxah6mxMUWk0ylYCWYOuRlA Cc: The IESG , calsify@ietf.org Subject: Re: [calsify] Adrian Farrel's No Objection on charter-ietf-calext-00-02: (with COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:41:52 -0000 > Something like... > > - Any change that impacts backwards compatibility with existing > deployed iCalendar/iTIP/CalDAV clients and servers will be discussed > by the working group with a view to minimizing disruption to deployed > implementations without compromising desirable new function. Cela me pla=EEt beaucoups. Cyrus? Barry >> -----Original Message----- >> From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Ba= rry >> Leiba >> Sent: 19 August 2014 15:25 >> To: Adrian Farrel >> Cc: The IESG; Cyrus Daboo; calsify@ietf.org >> Subject: Re: Adrian Farrel's No Objection on charter-ietf-calext-00-02: = (with >> COMMENT) >> >> >> - Any change that significantly impacts backwards compatibility with >> >> existing deployed iCalendar/iTIP/CalDAV clients and servers. >> > >> > I wonder whether what you consider as significant is the same as what = I >> > would call significant. >> >> We want to be able to leave that to the judgment of the working group, >> consulting with the AD. It's meant to be relatively soft, while still >> allowing the chairs to push back when they have to. >> >> Barry > From nobody Tue Aug 19 07:43:08 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D59A1A890A; Tue, 19 Aug 2014 07:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 n2o5URW0IEMt; Tue, 19 Aug 2014 07:43:00 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14DC11A892A; Tue, 19 Aug 2014 07:42:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 4BF6B6190BC; Tue, 19 Aug 2014 10:39:28 -0400 (EDT) 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 QKJmk2V-h41N; Tue, 19 Aug 2014 10:39:26 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 128D96190AD; Tue, 19 Aug 2014 10:39:24 -0400 (EDT) Date: Tue, 19 Aug 2014 10:42:48 -0400 From: Cyrus Daboo To: Barry Leiba , adrian@olddog.co.uk Message-ID: <9594512EFE7FB27FF8D36C00@caldav.corp.apple.com> In-Reply-To: References: <20140819142236.3740.57137.idtracker@ietfa.amsl.com> <029201cfbbbb$4ceb9620$e6c2c260$@olddog.co.uk> X-Mailer: Mulberry/4.1.0b1 (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=464 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/Y9sohijLr9cCW-h-CqSAdN6tIEI Cc: The IESG , calsify@ietf.org Subject: Re: [calsify] Adrian Farrel's No Objection on charter-ietf-calext-00-02: (with COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:43:04 -0000 Hi Barry, --On August 19, 2014 at 10:41:47 AM -0400 Barry Leiba=20 wrote: >> - Any change that impacts backwards compatibility with existing >> deployed iCalendar/iTIP/CalDAV clients and servers will be discussed >> by the working group with a view to minimizing disruption to = deployed >> implementations without compromising desirable new function. > > Cela me pla=C3=AEt beaucoups. Cyrus? > Looks OK to me. --=20 Cyrus Daboo From nobody Tue Aug 19 07:46:56 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C471A8906; Tue, 19 Aug 2014 07:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 cX8FYLqJaWC5; Tue, 19 Aug 2014 07:46:54 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8FC1A03C8; Tue, 19 Aug 2014 07:46:53 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id u10so5538476lbd.18 for ; Tue, 19 Aug 2014 07:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=5JsH3/pOXMX1i7Ksy5rqfoFSC79a82cN/WCVc/CxteU=; b=cz6rAlVtjwQz4EDkJPD1CAoTRDYUe9OdaT8ysqKwchMvzoGMaTqTjncPU+SDtUZP4m +VKTSH3tVRDnVX92lHmjlABBiEO7a8t71lv8hxgeOvAGWk+OCwe9o9JvscAsh7KDeKDT OELRTH7bJDo2MsY6qJ+F9vwpAcDESXYZkzebI10EiCNloQCXDOxWag1nbhwWcHThLUIs 8MoQRYa612hGx13cRM0eij8E31Sn0xkbbWFWjFsRzCfEu+1Dr3h5fUEptSSUY1GQWT0d CkpLvvhCZoJzcMJOgHLOsUuEdCkvxr8zg9quodhv/At8ohngX6CrU2CVGC60fz0rtGxq 61eQ== MIME-Version: 1.0 X-Received: by 10.112.219.234 with SMTP id pr10mr33782503lbc.59.1408459612217; Tue, 19 Aug 2014 07:46:52 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Tue, 19 Aug 2014 07:46:52 -0700 (PDT) In-Reply-To: <9594512EFE7FB27FF8D36C00@caldav.corp.apple.com> References: <20140819142236.3740.57137.idtracker@ietfa.amsl.com> <029201cfbbbb$4ceb9620$e6c2c260$@olddog.co.uk> <9594512EFE7FB27FF8D36C00@caldav.corp.apple.com> Date: Tue, 19 Aug 2014 10:46:52 -0400 X-Google-Sender-Auth: e1W70NRopMX80yf8yRvqmfkyR4c Message-ID: From: Barry Leiba To: Cyrus Daboo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/GyQYAoZLG37oT0R4Vv19oxYYsog Cc: adrian@olddog.co.uk, The IESG , calsify@ietf.org Subject: Re: [calsify] Adrian Farrel's No Objection on charter-ietf-calext-00-02: (with COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:46:55 -0000 >>> - Any change that impacts backwards compatibility with existing >>> deployed iCalendar/iTIP/CalDAV clients and servers will be discusse= d >>> by the working group with a view to minimizing disruption to deploy= ed >>> implementations without compromising desirable new function. >> >> Cela me pla=EEt beaucoups. Cyrus? > > Looks OK to me. So let it be written; so let it be done! b From nobody Tue Aug 19 15:43:10 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A451A6F2A; Tue, 19 Aug 2014 15:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 NuaRxTdpqGbU; Tue, 19 Aug 2014 15:43:07 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62BC1A6F03; Tue, 19 Aug 2014 15:43:06 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id v6so5994828lbi.39 for ; Tue, 19 Aug 2014 15:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YMIq+EZd4aY8fLNWbPJAJdoeRhcxJ7MquQaE7pp6Eo0=; b=Cq/GzIDntbOJ4heIlosHHQ+IiKYB3J/V+eHlmCXahHQu7Hld9ICVQa2W/vBvA/Plx0 OQWs0dRfjzKxsu22HEGd+A/Z4MqX25/x2IMpJh28v3ieCQRYklxNDOLZsH72AYjK37WM upgGwo2fA/m6NYUtB2NFHBsQVPILXc5rr3yUnmytBGTjdK70/tTb+CcUJtR6qohEJWoY 5btIuicyTZnJfYpzB/DnOu/aT2civycu+xN3ZjLyNBqy2Re5CdGHGjAlnf0NYe3NlxXh isw1rmhOOboMd/ST9bOkDsPnPWO9F0roRQI4p8UW8MQ/X4/0Ma7UR67gBWUxjhnMTBOo Tr9Q== MIME-Version: 1.0 X-Received: by 10.112.2.167 with SMTP id 7mr5579012lbv.103.1408488184837; Tue, 19 Aug 2014 15:43:04 -0700 (PDT) Received: by 10.152.206.36 with HTTP; Tue, 19 Aug 2014 15:43:04 -0700 (PDT) In-Reply-To: <880A81601093BB14EF07B96D@caldav.corp.apple.com> References: <20140818220257.21065.98944.idtracker@ietfa.amsl.com> <880A81601093BB14EF07B96D@caldav.corp.apple.com> Date: Tue, 19 Aug 2014 17:43:04 -0500 Message-ID: From: Spencer Dawkins at IETF To: Cyrus Daboo Content-Type: multipart/alternative; boundary=14dae94ee019ed7c440501033524 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/3Q05Ita-c5VgllHR-K-eKYwrMhM Cc: The IESG , "calsify@ietf.org" Subject: Re: [calsify] Spencer Dawkins' No Objection on charter-ietf-calext-00-02: (with COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 22:43:08 -0000 --14dae94ee019ed7c440501033524 Content-Type: text/plain; charset=UTF-8 On Tuesday, August 19, 2014, Cyrus Daboo wrote: > Hi Spencer, > > --On August 18, 2014 at 3:02:57 PM -0700 Spencer Dawkins < > spencerdawkins.ietf@gmail.com> wrote: > > This all looks fine. One question for my benefit. >> >> "- Define a set of new iCalendar properties and parameters to >> standardise >> some existing experimental X- properties in common use, based on a >> survey of existing implementations." >> >> I wasn't quite sure whether this meant standardizing an "X-Foo" >> experimental property, or standardizing a renamed "Foo:". It's unlikely >> that needs to be stated in a charter, either way, but just in case it >> does ... if the deliverable was "standardise some existing experimental >> properties", I wouldn't have thought to ask, but given the existence of >> http://tools.ietf.org/html/rfc6648, I wondered. >> >> > My personal goal is to try and get rid of X- usage as per RFC6648 and > encourage use of properly registered names, and that is what the current > draft I wrote tries to do (replace various X- items with non X- registered > equivalents). > > The original iCalendar spec, RFC 2445, did not have a formal registration > process for names and many of the existing X- items we want to deal with > here are from that era. When we updated iCalendar via RFC5545 we added IANA > registries and a fairly lightweight process for new properties that do not > impact any standards track behaviors. So the hope is that all new names > will be registered and avoid the X- prefix. Thanks! Spencer > > -- > Cyrus Daboo > > --14dae94ee019ed7c440501033524 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, August 19, 2014, Cyrus Daboo <cyrus@daboo.name> wrote:
Hi Spencer,

--On August 18, 2014 at 3:02:57 PM -0700 Spencer Dawkins <spencerdawk= ins.ietf@gmail.com> wrote:

This all looks fine. One question for my benefit.

"- Define a set of new iCalendar properties and parameters to
standardise
some existing experimental X- properties in common use, based on a
survey of existing implementations."

I wasn't quite sure whether this meant standardizing an "X-Foo&quo= t;
experimental property, or standardizing a renamed "Foo:". It'= s unlikely
that needs to be stated in a charter, either way, but just in case it
does ... if the deliverable was "standardise some existing experimenta= l
properties", I wouldn't have thought to ask, but given the existen= ce of
http://too= ls.ietf.org/html/rfc6648, I wondered.


My personal goal is to try and get rid of X- usage as per RFC6648 and encou= rage use of properly registered names, and that is what the current draft I= wrote tries to do (replace various X- items with non X- registered equival= ents).

The original iCalendar spec, RFC 2445, did not have a formal registration p= rocess for names and many of the existing X- items we want to deal with her= e are from that era. When we updated iCalendar via RFC5545 we added IANA re= gistries and a fairly lightweight process for new properties that do not im= pact any standards track behaviors. So the hope is that all new names will = be registered and avoid the X- prefix.

Thanks!

Spencer
=C2= =A0

--
Cyrus Daboo

--14dae94ee019ed7c440501033524-- From nobody Thu Aug 28 16:58:25 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C961A0146; Thu, 28 Aug 2014 16:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 llcJxZ7SX_LJ; Thu, 28 Aug 2014 16:58:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F111A015B; Thu, 28 Aug 2014 16:58:19 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140828235819.12719.31671.idtracker@ietfa.amsl.com> Date: Thu, 28 Aug 2014 16:58:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/erB9QBLUmgOH64gWIOzy2XfYjH4 Cc: calext WG Subject: [calsify] WG Action: Formed Calendaring Extensions (calext) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 23:58:23 -0000 A new IETF working group has been formed in the Applications Area. For additional information please contact the Area Directors or the WG Chairs. Calendaring Extensions (calext) ------------------------------------------------ Current Status: Proposed WG Chairs: Amanda Anganes Donald Eastlake Assigned Area Director: Barry Leiba Mailing list Address: calsify@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/calsify Archive: http://www.ietf.org/mail-archive/web/calsify/ Charter: The Calendaring Extensions working group is chartered to develop extensions to the iCalendar (RFC 5545), iTIP (RFC 5546), and CalDAV (RFC 4791) standards. This working group will do the following: - Develop an extension to iCalendar to support non-Gregorian recurrence rules, without the need to support new calendar scale values in iCalendar as a whole. This will allow for easy implementation of the primary use case for non-Gregorian support in calendar systems, without the need for significant changes to the iCalendar format. The non-Gregorian calendar system should be based on the International Components for Unicode work by the Unicode Consortium (http://site.icu-project.org). - Develop an extension to iCalendar to support a new component type that allows users to express arbitrary, possibly repeating, periods of "available" time. The primary use case for this is for users to express their "office hours" (e.g., Monday-Friday, 9am-5pm) in a standard way to ensure free busy lookups show the correct periods of availability. - Define a set of new iCalendar properties and parameters to standardise some existing experimental X- properties in common use, based on a survey of existing implementations. - Define a set of new iCalendar properties and parameters to cover key uses cases that implementers have identified, including, but not limited to, a new "IMAGE" property (to allow embedding/linking of images tied to a specific event), and a "CONFERENCE" property (to allow embedding information about dial-in numbers and similar multi-party communication options for an event). The working group will work under the following parameters: - The extensions developed are expected to be backwards-compatible with the existing calendar standards. Incompatibilities must be identified, minimized, and justified. - For each set of extensions, examine their impact on the iTIP protocol (RFC 5546), and define any necessary extensions to iTIP to accommodate such impact. - For each set of extensions, examine their impact on the CalDAV protocol (RFC 4791), and define any necessary extensions to CalDAV to accommodate such impact. Interface with the httpbis working group to ensure that any CalDAV changes are consistent with good http practices. The working group will use the following drafts as initial input for its work: draft-daboo-icalendar-rscale-03 draft-daboo-calendar-availability-05 draft-daboo-icalendar-extensions-08 The following are out of scope for the working group: - Any change that impacts backwards compatibility with existing deployed iCalendar/iTIP/CalDAV clients and servers will be discussed by the working group with a view to minimizing disruption to deployed implementations without compromising desirable new function. - Any attempt to develop non-Gregorian calendar systems/calculations. Milestones: TBD From nobody Thu Aug 28 21:50:26 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997951A0430 for ; Thu, 28 Aug 2014 21:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.032 X-Spam-Level: X-Spam-Status: No, score=0.032 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=unavailable 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 umwXMQiCjviM for ; Thu, 28 Aug 2014 21:50:23 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 419CA1A03D4 for ; Thu, 28 Aug 2014 21:50:22 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta10.westchester.pa.mail.comcast.net with comcast id kUoY1o0011wpRvQ5AUqMfX; Fri, 29 Aug 2014 04:50:21 +0000 Received: from THARE ([68.84.18.160]) by omta18.westchester.pa.mail.comcast.net with comcast id kUqL1o00E3TD7j03eUqLnB; Fri, 29 Aug 2014 04:50:21 +0000 From: "Tim Hare" To: "'Cyrus Daboo'" , "'Bradley White'" , , References: <618B0C114A25A593E80BD07B@cyrus.local> In-Reply-To: <618B0C114A25A593E80BD07B@cyrus.local> Date: Fri, 29 Aug 2014 00:50:20 -0400 Message-ID: <041f01cfc344$bd22ca40$37685ec0$@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: Ac+68yLCqKa4RKQsSBKwDHP1OB1bsQIUPV5w Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409287821; bh=ZGv0E1emXNj2WiOxo/qSkVlnsTtkV/uLnwLzOK7D5hM=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=FgnqKgSW4VLLSGQPvpxfkxavG08otZ0t4YJDlwocHbHqpGXrDPEolkom2SjRJ5pH8 jpyXbncP9+lzV7LSC7ZSdHg0Y6HaEnJjRyCbWjq6Lf261I00OHblJTNBJkgcfub0N0 DZmkDUiHWw2Gk5hLejsXMRN6YS6FJ6jwBlobwfHu7kFOXneUQSzupnzE96AqUl9Dna sTnQEMgg0SPa/87/s6jPqHPFLMU5jXWBGwJeIuHAg6O1LmjyMo8GCBNfgTFu1Ms/Vc uu+SLx616kwxwf2lDO6wl1uZg93lF8JSa5XPA5TMMS5P1KblZ6QzSl6mqcHARGr/bg IjIB9VU0rqEUA== Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/bo-U48NAtvx-0GefuK8Y2H1XeoI Subject: Re: [calsify] [Tzdist] Time Zone Distribution Protocol X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 04:50:24 -0000 I think I commented on this once before, but I'll comment (as an interested observer) with two thoughts: 1. I that if the data format for distributing timezone is standardized, the files will be fairly small (probably larger than the Olsen text file but still "small" in the sense of files pulled over IP) 2. My proposal was for DNS to return *all* the timezone file when receiving some sort of specialized query (which I hadn't determined), rather than trying to return data for just one timezone. Timezone data needs to be usable "offline" and pulling the entire file is, in my opinion, the best way to have an offline copy. Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of Cyrus Daboo Sent: Monday, August 18, 2014 10:46 AM To: Bradley White; tzdist@ietf.org; calsify@ietf.org Subject: Re: [calsify] [Tzdist] Time Zone Distribution Protocol Hi Bradley, --On August 14, 2014 at 5:45:41 PM -0400 Bradley White wrote: > A long time ago there was a proposal on the "tz" mailing list to return > zoneinfo data in a DNS TXT record in response to a query for a domain name > like New_York.America.zoneinfo.tz. As far as I know nothing ever came of > it. As Daniel pointed out there are a bunch of reasons why DNS might not be appropriate - but it is definitely worth hearing from everyone else on that issue to make sure there is good consensus one way or the other. Now, as for zoneinfo itself: one thing discussed by Mike and I (and others at CalConnect who helped with our draft), was the possibility of allowing actual zoneinfo files to be distributed via the tzdist protocol. We tried to build in extensibility that would allow that. The key thing we would need is a MIME content-type to be defined for the zoneinfo format - e.g. something like "application/timezone+zoneinfo". With that, a tzdist server could advertise that it can return data in that format (in addition to the iCalendar format we currently support). If we did that, then operating systems that used the zoneinfo format could become tzdist clients, and update their data directly from a tzdist server rather than relying on regular operating system update processes to do so. Any other timezone data format could be treated in a similar way (e.g., someone could come up with an interchange format for the Windows time zone data stored in the Windows registry and arrange for that to be distributed via tzdist). I think all of that is out of scope for this WG right now, beyond making sure we have proper extensibility in the tzdist protocol itself. -- Cyrus Daboo _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From nobody Fri Aug 29 07:09:51 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DA01A03AE; Fri, 29 Aug 2014 07:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 sIBKzte3UHfh; Fri, 29 Aug 2014 07:09:39 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D91A1A03C0; Fri, 29 Aug 2014 07:09:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 735D5778DEC; Fri, 29 Aug 2014 10:04:24 -0400 (EDT) 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 9HE7RKNWngPU; Fri, 29 Aug 2014 10:04:22 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id C57E1778DDD; Fri, 29 Aug 2014 10:04:20 -0400 (EDT) Date: Fri, 29 Aug 2014 10:08:54 -0400 From: Cyrus Daboo To: Martin Burnicki , Tim Hare , 'Bradley White' , tzdist@ietf.org, calsify@ietf.org Message-ID: <539248E17792833A55F74774@caldav.corp.apple.com> In-Reply-To: <54008739.30904@burnicki.net> References: <618B0C114A25A593E80BD07B@cyrus.local> <041f01cfc344$bd22ca40$37685ec0$@net> <54008739.30904@burnicki.net> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=865 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/zHgrb2Js6Fw0utpy2DHvJxWqVUw Subject: Re: [calsify] [Tzdist] Time Zone Distribution Protocol X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 14:09:42 -0000 Hi Martin, --On August 29, 2014 at 3:59:21 PM +0200 Martin Burnicki wrote: >> 2. My proposal was for DNS to return *all* the timezone file when >> receiving some sort of specialized query (which I hadn't determined), >> rather than trying to return data for just one timezone. Timezone data >> needs to be usable "offline" and pulling the entire file is, in my >> opinion, the best way to have an offline copy. > > I absolutely agree. +1 I disagree. There are obvious use cases where only one or two time zones might be needed. e.g., "internet of things" devices - my home thermostat only needs one time zone - namely the one where my house is. Such devices may have a limited memory capacity, and even though time zone data isn't huge, it would still be a waste to store it all when only one is being used. -- Cyrus Daboo From nobody Fri Aug 29 07:51:20 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150841A048C for ; Fri, 29 Aug 2014 07:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=unavailable 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 4_1TObG1iSAT for ; Fri, 29 Aug 2014 07:51:17 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 692BD1A0468 for ; Fri, 29 Aug 2014 07:51:17 -0700 (PDT) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta01.emeryville.ca.mail.comcast.net with comcast id keKb1o0051bwxycA1erHfl; Fri, 29 Aug 2014 14:51:17 +0000 Received: from THARE ([68.84.18.160]) by omta18.emeryville.ca.mail.comcast.net with comcast id kerE1o00E3TD7j08eerERt; Fri, 29 Aug 2014 14:51:16 +0000 From: "Tim Hare" To: "'Cyrus Daboo'" , "'Martin Burnicki'" , "'Bradley White'" , , References: <618B0C114A25A593E80BD07B@cyrus.local> <041f01cfc344$bd22ca40$37685ec0$@net> <54008739.30904@burnicki.net> <539248E17792833A55F74774@caldav.corp.apple.com> In-Reply-To: <539248E17792833A55F74774@caldav.corp.apple.com> Date: Fri, 29 Aug 2014 10:51:13 -0400 Message-ID: <005e01cfc398$af9c38d0$0ed4aa70$@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: Ac/DkudJTCJ81wweS0OATTFRCmDc3AABUFkQ Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409323877; bh=f5Wt0EOnAu8YBN2YkYU6zd/kJhzSFNLLG3Sc3XMqFB4=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=eIjr3F00ogCGPtgewYmhLpB2G1ayBR55HUrYGyqU8cFissBy2UerlD8ke12hQAZHj nTDDeD73hK7bB4x1fN9AYucYVgU0fAfoX6IWzIhOJ1b4jTtmv5qG91KRFLMchAhIMg IOjptbsi4WBAX3U0V/GDzoPAANcB83b4/7pkV7JmhldfX9jvLiJLA+Xk+K0HH1LVAM mpezHT4AIK7UsSE9E/VXwMd4Jim3FMgwz+PXaEYSqMVippiyW3b/Ywf+s8AqFm4WFI 1u8yOhm6KIR1vnHQSSS8wCcXa3Pvo/LjXPzLGP0Rwp/TTTkEzE47N+P//O6+nko1K5 MtOxyv4yuoKZQ== Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/j5J4iFODFZgv2lhZAVZVQ1Ci8j8 Subject: Re: [calsify] [Tzdist] Time Zone Distribution Protocol X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 14:51:19 -0000 Correction - I went back and found what I had originally written (some weeks ago) but apparently never sent (?). My idea was to have the files on the NTP/SNTP servers, a more natural place for time-related data. The idea was still the same, though - to allow an already existing distributed network of servers to handle these. I do agree with the point on "internet of things" - however 'limited memory' is a lot larger these days than it used to be :-) Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: Cyrus Daboo [mailto:cyrus@daboo.name] Sent: Friday, August 29, 2014 10:09 AM To: Martin Burnicki; Tim Hare; 'Bradley White'; tzdist@ietf.org; calsify@ietf.org Subject: Re: [Tzdist] [calsify] Time Zone Distribution Protocol Hi Martin, --On August 29, 2014 at 3:59:21 PM +0200 Martin Burnicki wrote: >> 2. My proposal was for DNS to return *all* the timezone file when >> receiving some sort of specialized query (which I hadn't determined), >> rather than trying to return data for just one timezone. Timezone data >> needs to be usable "offline" and pulling the entire file is, in my >> opinion, the best way to have an offline copy. > > I absolutely agree. +1 I disagree. There are obvious use cases where only one or two time zones might be needed. e.g., "internet of things" devices - my home thermostat only needs one time zone - namely the one where my house is. Such devices may have a limited memory capacity, and even though time zone data isn't huge, it would still be a waste to store it all when only one is being used. -- Cyrus Daboo From nobody Fri Aug 29 08:41:15 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD641A0647; Fri, 29 Aug 2014 08:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.382 X-Spam-Level: X-Spam-Status: No, score=0.382 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, 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 pk7O5f9vIJ0S; Fri, 29 Aug 2014 08:41:12 -0700 (PDT) Received: from COL004-OMC4S7.hotmail.com (col004-omc4s7.hotmail.com [65.55.34.209]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E3841A0645; Fri, 29 Aug 2014 08:41:12 -0700 (PDT) Received: from COL130-DS19 ([65.55.34.201]) by COL004-OMC4S7.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22701); Fri, 29 Aug 2014 08:41:11 -0700 X-TMN: [7WD0t0EBujc4xAnnxP6kQ3hhgFt0kEKv] X-Originating-Email: [wkearney99@hotmail.com] Message-ID: From: "Bill Kearney" To: "Cyrus Daboo" , "Martin Burnicki" , "Tim Hare" , "'Bradley White'" , , References: <618B0C114A25A593E80BD07B@cyrus.local> <041f01cfc344$bd22ca40$37685ec0$@net> <54008739.30904@burnicki.net> <539248E17792833A55F74774@caldav.corp.apple.com> In-Reply-To: <539248E17792833A55F74774@caldav.corp.apple.com> Date: Fri, 29 Aug 2014 11:40:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-OriginalArrivalTime: 29 Aug 2014 15:41:11.0482 (UTC) FILETIME=[A8B711A0:01CFC39F] Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/2GOGuuIW1PdyrIWJipoI6XwoK5Y Subject: Re: [calsify] [Tzdist] Time Zone Distribution Protocol X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 15:41:13 -0000 > I disagree. There are obvious use cases where only one or two time zones > might be needed. e.g., "internet of things" devices - my home thermostat > only needs one time zone - namely the one where my house is. Such devices > may have a limited memory capacity, and even though time zone data isn't > huge, it would still be a waste to store it all when only one is being > used. What he said. All too often developers overlook resource-deprived devices. It's important to consider the impact on them to pull more data than necessary, to store it locally and to wade through it. Bandwidth, CPU and storage are not free and means to be conservative about them ALWAYS be considered. That and a spec that encourages means for brevity as the default should be considered. Make it possible for all devices to get what someone configuring the domain considers to be "locally essential". Don't let the examples cite 'everything and the kitchen sink'. -Bill Kearney From nobody Fri Aug 29 08:45:00 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDA41A053B; Fri, 29 Aug 2014 08:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.821 X-Spam-Level: X-Spam-Status: No, score=0.821 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 jR1OTfovugZ0; Fri, 29 Aug 2014 08:44:54 -0700 (PDT) Received: from COL004-OMC3S15.hotmail.com (col004-omc3s15.hotmail.com [65.55.34.153]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E0E1A0654; Fri, 29 Aug 2014 08:44:29 -0700 (PDT) Received: from COL130-DS1 ([65.55.34.135]) by COL004-OMC3S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22701); Fri, 29 Aug 2014 08:44:29 -0700 X-TMN: [+WnhYjYW1DegCnxGUA6Ymo0Wt25QjQBF] X-Originating-Email: [wkearney99@hotmail.com] Message-ID: From: "Bill Kearney" To: "Tim Hare" , "'Cyrus Daboo'" , "'Martin Burnicki'" , "'Bradley White'" , , References: <618B0C114A25A593E80BD07B@cyrus.local> <041f01cfc344$bd22ca40$37685ec0$@net> <54008739.30904@burnicki.net> <539248E17792833A55F74774@caldav.corp.apple.com> <005e01cfc398$af9c38d0$0ed4aa70$@net> In-Reply-To: <005e01cfc398$af9c38d0$0ed4aa70$@net> Date: Fri, 29 Aug 2014 11:44:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-OriginalArrivalTime: 29 Aug 2014 15:44:29.0122 (UTC) FILETIME=[1E848A20:01CFC3A0] Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/48tNEP2t1eokSY1aXhIrDmVjPQI Subject: Re: [calsify] [Tzdist] Time Zone Distribution Protocol X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 15:44:57 -0000 Bear in mind the question "What will the client devices have 'on-hand' to go about making queries?" Firmware may be quite limited. Surely anything on a network is going to have a DNS client. Is the same going to be true for NTP? Not everything needs time, as there may be other processes/devices/whatever involved that handle time-related functionality. -Bill Kearney -----Original Message----- From: Tim Hare Correction - I went back and found what I had originally written (some weeks ago) but apparently never sent (?). My idea was to have the files on the NTP/SNTP servers, a more natural place for time-related data. The idea was still the same, though - to allow an already existing distributed network of servers to handle these. I do agree with the point on "internet of things" - however 'limited memory' is a lot larger these days than it used to be :-) From nobody Sat Aug 30 08:21:21 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F3C1A0ADA for ; Mon, 18 Aug 2014 11:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 boTuuDnj6-GG; Mon, 18 Aug 2014 11:38:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A182B1A03DE; Mon, 18 Aug 2014 11:38:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: cyrus@daboo.name, calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140818183842.23067.20585.idtracker@ietfa.amsl.com> Date: Mon, 18 Aug 2014 11:38:42 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/BP4gePmA4b7Yk_yTUxmZVPbLfSQ X-Mailman-Approved-At: Sat, 30 Aug 2014 08:21:08 -0700 Subject: [calsify] State changed: charter-ietf-calext-00-02 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 18:38:44 -0000 State changed to IESG review. URL: http://datatracker.ietf.org/doc/charter-ietf-calext/ From nobody Sat Aug 30 08:21:23 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A581A03D0; Fri, 29 Aug 2014 06:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 tX2ZbxsbLhHg; Fri, 29 Aug 2014 06:59:31 -0700 (PDT) Received: from www52.your-server.de (www52.your-server.de [213.133.104.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A5F1A03D2; Fri, 29 Aug 2014 06:59:30 -0700 (PDT) Received: from [88.198.220.132] (helo=sslproxy03.your-server.de) by www52.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA256:256) (Exim 4.80.1) (envelope-from ) id 1XNMi8-0003QE-Sz; Fri, 29 Aug 2014 15:59:28 +0200 Received: from [217.6.112.194] (helo=[172.16.102.127]) by sslproxy03.your-server.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XNMi5-00073R-JB; Fri, 29 Aug 2014 15:59:25 +0200 Message-ID: <54008739.30904@burnicki.net> Date: Fri, 29 Aug 2014 15:59:21 +0200 From: Martin Burnicki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17 MIME-Version: 1.0 To: Tim Hare , 'Cyrus Daboo' , 'Bradley White' , tzdist@ietf.org, calsify@ietf.org References: <618B0C114A25A593E80BD07B@cyrus.local> <041f01cfc344$bd22ca40$37685ec0$@net> In-Reply-To: <041f01cfc344$bd22ca40$37685ec0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: mailout@burnicki.net X-Virus-Scanned: Clear (ClamAV 0.98.4/19314/Thu Aug 28 19:26:16 2014) Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/Ee1gP79ndcVsqrqDVvk6sEgMgXU X-Mailman-Approved-At: Sat, 30 Aug 2014 08:21:08 -0700 Subject: Re: [calsify] [Tzdist] Time Zone Distribution Protocol X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 13:59:32 -0000 Tim Hare wrote: > 2. My proposal was for DNS to return *all* the timezone file when receiving > some sort of specialized query (which I hadn't determined), rather than > trying to return data for just one timezone. Timezone data needs to be > usable "offline" and pulling the entire file is, in my opinion, the best way > to have an offline copy. I absolutely agree. +1 > Tim Hare > Interested Bystander, Non-Inc. Martin Burnicki Another interested listener. ;-) From nobody Sat Aug 30 08:21:24 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA7C1A0118; Sat, 16 Aug 2014 11:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 fzHbMu5-kkMS; Sat, 16 Aug 2014 11:42:42 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AAEB1A0117; Sat, 16 Aug 2014 11:42:42 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so2046678wib.14 for ; Sat, 16 Aug 2014 11:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JSFUF0RilNK64Qd2iepv0cqYaw7jlX0PZPQAMXWx/v4=; b=DREWgUBzDvOX0WwyA/xaXU2eCwfwX0i4bC6HawfOXZ7EhsMkCliOIvimJsONGMHMVD i0EGCnKJq9MJDyjRhiuOenDBPmVbYrPVA0xas5Hrco/3UmbF80AYobLRSiz9JteQ+jT9 8mqL0b5UakKsJoRX3BZrq0IP8FhFYk07u166E3DDY284q6p3r+vSG1+wBxElmVjQmsPf l1245ubk89zcG7APy1APX6Hx0JYvl0+ftIHzVYd2DzOVIpzgHfIqzixHi0AOGWErqNLG R9kFt7hctVCJvuntFJ4XFLf6CGicbtY7LBkYCtOybJ6WqHjiQ71gQOIrlbfQt17Q6jDH xY1g== MIME-Version: 1.0 X-Received: by 10.180.106.6 with SMTP id gq6mr30348913wib.5.1408214560863; Sat, 16 Aug 2014 11:42:40 -0700 (PDT) Received: by 10.194.137.67 with HTTP; Sat, 16 Aug 2014 11:42:40 -0700 (PDT) In-Reply-To: References: Date: Sat, 16 Aug 2014 20:42:40 +0200 Message-ID: From: Daniel Migault To: Bradley White Content-Type: multipart/alternative; boundary=f46d044519a5aafc4d0500c380e2 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/6oP2a_aRl7ytnRw6_zbmTmT0kwo X-Mailman-Approved-At: Sat, 30 Aug 2014 08:21:10 -0700 Cc: tzdist@ietf.org, calsify@ietf.org Subject: Re: [calsify] [Tzdist] Time Zone Distribution Protocol X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 18:42:44 -0000 --f46d044519a5aafc4d0500c380e2 Content-Type: text/plain; charset=UTF-8 Thanks for raising this point about using DNS or HTTP. Current drafts use HTTP. Personally, I do not think DNS would be appropriate as the timezone exchange is not a simple UDP query - response. First queries are not so simple and have multiple parameters, then responses may be also large enough to use TCP even with DNS. Please let's share your opinion on that topic. BR, Daniel On Thu, Aug 14, 2014 at 11:45 PM, Bradley White wrote: > On Fri, Jul 18, 2014 at 8:21 AM, The IESG wrote: > >> This working group will: >> >> - Define a time zone data distribution protocol that allows for >> efficient, timely updates of time zone data to be delivered to clients. >> This protocol must scale to vast numbers of clients, such as the >> potential "internet of things" devices, as well as to today's desktop >> computers and servers. >> > > On Thu, Aug 14, 2014 at 5:12 AM, Daniel Migault > wrote: > >> Comments should be emailed on the tzdist@ietf.org mailing list. >> > > A long time ago there was a proposal on the "tz" mailing list to return > zoneinfo data in a DNS TXT record in response to a query for a domain name > like New_York.America.zoneinfo.tz. As far as I know nothing ever came of > it. > > _______________________________________________ > Tzdist mailing list > Tzdist@ietf.org > https://www.ietf.org/mailman/listinfo/tzdist > > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --f46d044519a5aafc4d0500c380e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for raising this point about using DNS or HTTP= .

Current drafts use HTTP. Personally, I do not think DNS would be = appropriate as the timezone exchange is not a simple UDP query - response. = First queries are not so simple and have multiple parameters, then response= s may be also large enough to use TCP even with DNS.

Please let's share your opinion on that topic.
=

BR,
Daniel




On Thu, Aug 14, 2014 at 11:45 = PM, Bradley White <bww@acm.org> wrote:
= On Fri, Jul 18, 2014 at 8:21 AM, The IESG=C2=A0<iesg@ietf.org>= =C2=A0wrote:
This working group will:

- Define a time zone data distribution prot= ocol that allows for
efficient, timely updates of time zone data to be d= elivered to clients.
This protocol must scale to vast numbers of clients= , such as the
potential "internet of things" devices, as well as to today's= desktop
computers and servers.

On T= hu, Aug 14, 2014 at 5:12 AM, Daniel Migault <mglt.ietf@gmail.com&g= t; wrote:
Comments should be emailed on the tzdist@ietf.org mailin= g list.

A lon= g time ago there was a proposal on the "tz" mailing list to retur= n zoneinfo data in a DNS TXT record in response to a query for a domain nam= e like Ne= w_York.America.zoneinfo.tz. =C2=A0As far as I know nothing ever came of= it.

_______________________________________________
Tzdist mailing list
Tzdist@ietf.org
= https://www.ietf.org/mailman/listinfo/tzdist




--
Daniel Migault
O= range Labs -- Security
+33 6 70 72 69 58 --f46d044519a5aafc4d0500c380e2-- From nobody Sat Aug 30 08:21:25 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893D51A0146; Sat, 16 Aug 2014 11:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 o_lqKOwFeXVB; Sat, 16 Aug 2014 11:50:05 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107941A0144; Sat, 16 Aug 2014 11:50:04 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id a108so3238034qge.16 for ; Sat, 16 Aug 2014 11:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UfBQ6aFwKRRcrZTof6EOzvpK2JqK+8keTtozHFAd+ek=; b=CCkId6rUH/abyXP7LKm3mCCV4QueeRbM2yk30Fb0taiYDZSBkqPqyDpZUEocRZKGpH M9OPVlHvJDRooleIreoJ1OUo9vtIA88NUg3lQH+GKowMOS+F/mTu4/Li3J9YLiLGBLBy lzQfTz5WaCp4uWzmPvDAJ2tlVi1ERbU02Fbk2S0gqDXhX95N7rQKNxIrgOFQ8UYThLe9 Hk8dZxGn50zoslBUcX3FedTZaz6PP03VDKKLqawmnIGPWIZZZGEeGTSHY1Gg8/Ago3VG vmUEMD0INcmXJYhPA9BVTjEmECDJSvljxEmmQz19ngySyCmjlPugPEQlJPQNDvGM9hLK Ay6g== MIME-Version: 1.0 X-Received: by 10.140.43.245 with SMTP id e108mr29266822qga.76.1408215004133; Sat, 16 Aug 2014 11:50:04 -0700 (PDT) Sender: tobias.conradi@gmail.com Received: by 10.140.18.199 with HTTP; Sat, 16 Aug 2014 11:50:04 -0700 (PDT) In-Reply-To: References: Date: Sat, 16 Aug 2014 20:50:04 +0200 X-Google-Sender-Auth: cJazYbYJzq4Hx7QSmjZSTg4xXGY Message-ID: From: Tobias Conradi To: Daniel Migault Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/r_1WF_BVxmVFGFHOfujsGQTT1po X-Mailman-Approved-At: Sat, 30 Aug 2014 08:21:08 -0700 Cc: tzdist@ietf.org, Bradley White , calsify@ietf.org Subject: Re: [calsify] [Tzdist] Time Zone Distribution Protocol X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 18:50:06 -0000 On Sat, Aug 16, 2014 at 8:42 PM, Daniel Migault wrote: > Thanks for raising this point about using DNS or HTTP. > > Current drafts They are outdated. > use HTTP. Personally, I do not think DNS would be appropriate > as the timezone exchange is not a simple UDP query - response. First queries > are not so simple and have multiple parameters, then responses may be also > large enough to use TCP even with DNS. > > Please let's share your opinion on that topic. Why are the drafts not updated to reflect current best knowledge about what they shall be like? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com From clive@nyder.davros.org Sat Aug 16 13:44:22 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E1A1A0356; Sat, 16 Aug 2014 13:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 FFYOVXLLlz_0; Sat, 16 Aug 2014 13:44:20 -0700 (PDT) Received: from nyder.davros.org (nyder.davros.org [82.68.24.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E371A0351; Sat, 16 Aug 2014 13:44:19 -0700 (PDT) Received: from nyder.davros.org (localhost [127.0.0.1]) by nyder.davros.org (8.14.4/8.14.4) with ESMTP id s7GKdnpd097641; Sat, 16 Aug 2014 21:39:50 +0100 (BST) (envelope-from clive@nyder.davros.org) Received: (from clive@localhost) by nyder.davros.org (8.14.4/8.14.4/Submit) id s7GKdn5B097640; Sat, 16 Aug 2014 21:39:49 +0100 (BST) (envelope-from clive) Date: Sat, 16 Aug 2014 21:39:49 +0100 From: "Clive D.W. Feather" To: Tobias Conradi Message-ID: <20140816203949.GZ82444@davros.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/4CPUCzk0vP5ayBFn2Z4tWtiZ09U X-Mailman-Approved-At: Sat, 30 Aug 2014 08:21:11 -0700 Cc: tzdist@ietf.org, Bradley White , calsify@ietf.org, Daniel Migault Subject: Re: [calsify] [Tzdist] Time Zone Distribution Protocol X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 20:45:07 -0000 Tobias Conradi said: > Why are the drafts not updated to reflect current best knowledge about > what they shall be like? Because you update a draft when consensus has been reached about a change, not just because one person (even the author) has made a suggestion. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 From nobody Sat Aug 30 08:21:28 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEC61A038E; Sat, 16 Aug 2014 14:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 bDn36gacXixg; Sat, 16 Aug 2014 14:01:01 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4341A0386; Sat, 16 Aug 2014 14:01:01 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id m5so3196040qaj.35 for ; Sat, 16 Aug 2014 14:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xhqC4sbvPU7P87Y5Z2M/52dykAEsvr6XyxwSuEwgmbw=; b=ZYs9ByiD1yqnSHr25Npeas0NwGerrqg39fVfAcxQOIsz3/aFYrWY0MZ0dDz0dSI/+p JbwAzujWRzfVDie1ZLqEv9KAAaovmji+sa8glnsDc0hf10aNc+X07dQZBG1z1PmtTHWG 9ynCJUttNhhBXc4LTsVdq/ppi+sexKTDHqFlWYFUJih3tE7KHTiLACSCrK5CSv2nsqzk Sm5wrzJPVw5xqTKPicfFs7vrhB0jZu2NATI4v2rU79dHdnZ9FrmqX44oc3rnqLA3qgEU 7e9Hn842eO+ykqd1Mcy8Z0OKSp2/I3lcd+I54Y7pKEgVMAdHulgumItceZMA0E5s4cr7 GkKw== MIME-Version: 1.0 X-Received: by 10.140.43.245 with SMTP id e108mr30049487qga.76.1408222860783; Sat, 16 Aug 2014 14:01:00 -0700 (PDT) Sender: tobias.conradi@gmail.com Received: by 10.140.18.199 with HTTP; Sat, 16 Aug 2014 14:01:00 -0700 (PDT) In-Reply-To: <20140816203949.GZ82444@davros.org> References: <20140816203949.GZ82444@davros.org> Date: Sat, 16 Aug 2014 23:01:00 +0200 X-Google-Sender-Auth: 1GToZSYgi2xgRrQ6VWUftsr_4lA Message-ID: From: Tobias Conradi To: "Clive D.W. Feather" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/5jMgcjdL-cGPKn0YFcipNc2t7nQ X-Mailman-Approved-At: Sat, 30 Aug 2014 08:21:09 -0700 Cc: tzdist@ietf.org, Bradley White , calsify@ietf.org, Daniel Migault Subject: Re: [calsify] [Tzdist] Time Zone Distribution Protocol X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 21:01:03 -0000 On Sat, Aug 16, 2014 at 10:39 PM, Clive D.W. Feather wrote: > Tobias Conradi said: >> Why are the drafts not updated to reflect current best knowledge about >> what they shall be like? > > Because you me? How can I? > update a draft when consensus has been reached about a change, I thought there was? Even enclosed in **...** http://www.ietf.org/mail-archive/web/tzdist/current/msg00014.html > not just because one person (even the author) has made a suggestion. Not applicable here, see http://www.ietf.org/mail-archive/web/tzdist/current/msg00014.html -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com From nobody Sat Aug 30 08:21:29 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7830A1A04E7; Mon, 18 Aug 2014 07:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 fEReewdTGLeY; Mon, 18 Aug 2014 07:55:16 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308EF1A04BC; Mon, 18 Aug 2014 07:55:16 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id l6so4870763qcy.33 for ; Mon, 18 Aug 2014 07:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=khXhxN+dnoQHtcu2g1Dn3XlnumTRXjoBTact1ovyaiY=; b=TbdCgIiQOXF5gf9Sw2Xe+HdjBQBXmIyYWpqwKiXIodjPZcycj7inW+Bw8NNVcgDaCN 6FPeXYgxVCi/Mj+1fYM68VY/ipOuaZckmZSyjYqEMweTyXy5bXFE4PD9aDHz1Dtd+DiM Tak0cxlMNVw4yp5w0/cMz25J/GjBEt9BOgFWLARAmSA8umlf95IDieByBWdQf1I3YGAG 9KDCRsG4RGqt2VPEnXD+A/8xzmHcgD7MfxuRGWlWSwqMNLXAjtVwAZQqzKKSlJvf3Ybo b+Z6WE6hkPTptsYqj0IGuiV6zQb5HXT5+23UTJz6Cdc1qNVpYoTEc7YPsr9aG/LLKxd8 HtVw== MIME-Version: 1.0 X-Received: by 10.140.96.180 with SMTP id k49mr14462836qge.78.1408373715365; Mon, 18 Aug 2014 07:55:15 -0700 (PDT) Sender: tobias.conradi@gmail.com Received: by 10.140.18.199 with HTTP; Mon, 18 Aug 2014 07:55:15 -0700 (PDT) In-Reply-To: <618B0C114A25A593E80BD07B@cyrus.local> References: <618B0C114A25A593E80BD07B@cyrus.local> Date: Mon, 18 Aug 2014 16:55:15 +0200 X-Google-Sender-Auth: f3H9Gai1945iutVInjVcpqYwSrA Message-ID: From: Tobias Conradi To: Cyrus Daboo Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/oBrQY6XlScX02nlDg9Xdypp9j8I X-Mailman-Approved-At: Sat, 30 Aug 2014 08:21:10 -0700 Cc: tzdist@ietf.org, Bradley White , calsify@ietf.org Subject: Re: [calsify] [Tzdist] Time Zone Distribution Protocol X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 14:55:17 -0000 On Mon, Aug 18, 2014 at 4:45 PM, Cyrus Daboo wrote: > Now, as for zoneinfo itself: one thing discussed by Mike and I (and others > at CalConnect who helped with our draft), was the possibility of allowing > actual zoneinfo files to be distributed via the tzdist protocol. These are governed by Paul Eggert. He can change the format at any point he likes. Specifying in a RFC a format that itself is not governed by any formal standard looks weird to me. But I am new to IETF. Is there any current RFC that does this? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com From nobody Sat Aug 30 08:21:30 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9321A048F for ; Fri, 29 Aug 2014 07:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no 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 UwcPTwLZIt-l for ; Fri, 29 Aug 2014 07:32:06 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA761A03C5 for ; Fri, 29 Aug 2014 07:32:06 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id bs8so9213316wib.9 for ; Fri, 29 Aug 2014 07:32:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1qVLahbNrNt4v56ETbWIgz7Qe3ylW7oJJ64ZWO7dMpQ=; b=Y4bGJmuSOOU+u/iZfy8mnoRzHqOGlqe6Yn4HvszeEGhN6sdWPuMLXzi1RdGy6Vcwzv 9Q/dg5aKR63dWIEAy9O16HwDG/SN2kmHyuBYTDx4sm44d/emEsMfFX4iY1srY/igBEtp z+asrA9/jI54SALUfKsPVxZaM3qdNShc0fNiGiHTvXiQaLzwHO/eVi45AMiGqW10soRn fIuennJEA5ipHeD2igje8clxWhKU2M3Oc44W7491jYm7qhbacXrJ6OQHKASJAR7I7Ity Cebs7Hc7JeS6arkz465wNyCH6vh+97kta/nL+bQMb2dv7pEKfisai2eS9y6eJnF+TG3i FZog== X-Gm-Message-State: ALoCoQk5TPDYdfffuMW1eqgzCpm+HS82ulnIyeIduuKdi2Eet1hsKnEo69cZEuDXJ2Zv7B1JJ8hr X-Received: by 10.180.188.205 with SMTP id gc13mr4313309wic.66.1409322725024; Fri, 29 Aug 2014 07:32:05 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx.google.com with ESMTPSA id ec2sm47591612wib.19.2014.08.29.07.32.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Aug 2014 07:32:03 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so9213076wiv.7 for ; Fri, 29 Aug 2014 07:32:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.182.67 with SMTP id ec3mr4281874wic.21.1409322723267; Fri, 29 Aug 2014 07:32:03 -0700 (PDT) Received: by 10.194.189.17 with HTTP; Fri, 29 Aug 2014 07:32:03 -0700 (PDT) In-Reply-To: <539248E17792833A55F74774@caldav.corp.apple.com> References: <618B0C114A25A593E80BD07B@cyrus.local> <041f01cfc344$bd22ca40$37685ec0$@net> <54008739.30904@burnicki.net> <539248E17792833A55F74774@caldav.corp.apple.com> Date: Fri, 29 Aug 2014 10:32:03 -0400 Message-ID: From: Tim Parenti To: Cyrus Daboo Content-Type: multipart/alternative; boundary=047d7b5dbcda4b61ab0501c5843c Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/slCq6Qn51iFhCYrSbtlGaDBd3E4 X-Mailman-Approved-At: Sat, 30 Aug 2014 08:21:11 -0700 Cc: tzdist@ietf.org, Bradley White , Martin Burnicki , calsify@ietf.org Subject: Re: [calsify] [Tzdist] Time Zone Distribution Protocol X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 14:32:12 -0000 --047d7b5dbcda4b61ab0501c5843c Content-Type: text/plain; charset=UTF-8 On 29 August 2014 10:08, Cyrus Daboo wrote: > --On August 29, 2014 at 3:59:21 PM +0200 Martin Burnicki < > martin.burnicki@burnicki.net> wrote: > > 2. My proposal was for DNS to return *all* the timezone file when >>> receiving some sort of specialized query (which I hadn't determined), >>> rather than trying to return data for just one timezone. Timezone data >>> needs to be usable "offline" and pulling the entire file is, in my >>> opinion, the best way to have an offline copy. >>> >> >> I absolutely agree. +1 >> > > I disagree. There are obvious use cases where only one or two time zones > might be needed. e.g., "internet of things" devices - my home thermostat > only needs one time zone - namely the one where my house is. Such devices > may have a limited memory capacity, and even though time zone data isn't > huge, it would still be a waste to store it all when only one is being used. I think both use cases are valid, and if we go the DNS route, it might be wise to support both. For now, though, I think that action (ticket #19) has been deferred. http://www.ietf.org/mail-archive/web/tzdist/current/msg00246.html http://trac.tools.ietf.org/wg/tzdist/trac/ticket/19 -- Tim Parenti --047d7b5dbcda4b61ab0501c5843c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 29 August 2014 10:08, Cyrus Daboo <cyrus@daboo.name> wrote= :
--On August 29, 2014 at 3:59:21 PM +0200 Martin Burnicki &l= t;martin.= burnicki@burnicki.net> wrote:

2. My proposal was for DNS to return *all* the timezone file when
receiving some sort of specialized query (which I hadn't determined), rather than trying to return data for just one timezone.=C2=A0 Timezone dat= a
needs to be usable "offline" and pulling the entire file is, in m= y
opinion, the best way to have an offline copy.

I absolutely agree. +1

I disagree. There are obvious use cases where only one or two time zones mi= ght be needed. e.g., "internet of things" devices - my home therm= ostat only needs one time zone - namely the one where my house is. Such dev= ices may have a limited memory capacity, and even though time zone data isn= 't huge, it would still be a waste to store it all when only one is bei= ng used.

I think both use cases are valid= , and if we go the DNS route, it might be wise to support both.=C2=A0 For n= ow, though, I think that action (ticket #19) has been deferred.
http= ://www.ietf.org/mail-archive/web/tzdist/current/msg00246.html
http://trac= .tools.ietf.org/wg/tzdist/trac/ticket/19

--
Tim Parenti
--047d7b5dbcda4b61ab0501c5843c--