From nobody Thu Feb 1 01:09:55 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4D0131644 for ; Thu, 1 Feb 2018 01:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=meinberg.de 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 8SZ_nKZN9J0D for ; Thu, 1 Feb 2018 01:09:51 -0800 (PST) Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19141318C8 for ; Thu, 1 Feb 2018 01:09:47 -0800 (PST) Received: from srv-kerioconnect.py.meinberg.de (unknown [217.6.112.194]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id B053271C1781; Thu, 1 Feb 2018 10:09:43 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 server1a.meinberg.de B053271C1781 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=meinberg.de; s=mail201101; t=1517476186; bh=2rugncNhDnabfV3ZWvRkswSbD2GQIyjF7ZoiRupSZsA=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=kwidkmvna4+jQzVD8ZzeaM4zfv+9eTaMhX/lfYunjfAhuOsTDESLpO25b6dZIC4Mq ZYX4RRLOh5aK9umZ/IxCq9bVfNkif4QPSasUdustgsS36byVrEGYRU1/J6PuJ4H3SY gcKxNQjDHIW55syL1VP9OKnC80k9kDsH7/Sjo4Lk= X-Kerio-Anti-Spam: Build: [Engines: 2.15.8.1142, Stamp: 3], Multi: [Enabled, t: (0.000007,0.005310)], BW: [Enabled, t: (0.000009)], RTDA: [Enabled, t: (0.153994), Hit: No, Details: v2.6.16; Id: 15.5f4goc.1c3t53r7g.ib1c1], total: 0(700) X-Footer: bWVpbmJlcmcuZGU= Received: from localhost ([127.0.0.1]) by srv-kerioconnect.py.meinberg.de with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 1 Feb 2018 10:09:41 +0100 To: Joe Touch , art@ietf.org References: <6a2080c9-1e9b-a683-38fe-b69bcc8a1d0b@meinberg.de> <92593352-ac39-2208-24a3-912fd020caf0@strayalpha.com> From: Martin Burnicki Organization: Meinberg Funkuhren, Bad Pyrmont, Germany Message-ID: <87622f32-e401-349e-7c61-e239beedacdd@meinberg.de> Date: Thu, 1 Feb 2018 10:09:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <92593352-ac39-2208-24a3-912fd020caf0@strayalpha.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.3 at server1a X-Virus-Status: Clean Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 09:09:54 -0000 Joe, Joe Touch wrote: > Can you help clarify whether this is an update to the NTP protocol or > merely an update to the user libraries that are provided with it? > > (i.e., AFAICT, smearing is a local function that doesn't involve > synchronization per se, but does rely on NTP-like sync of time outside > the smearing period as well as external input on planned leap events) I was referring to the NTP reference implementation, ntpd. While smearing is in progress on the server, the 4 byte refid field in the NTP packets sent to the clients is modified: the first byte is 254, and the subsequent 3 byte contain the current smear offset, scaled in a way that a value in the range -1 ... +1 can be saved. This has been discussed on IRC and per email by some folks when leap smearing has been implemented. Please keep in mind that even though there are some well-known values for the refid field from a stratum-1 server, you can usually configure the server to use a refid with any 4 character string. So this is just a special "string", and during the last leap second it turned out that it is a useful feature which lets a client detect that a server is smearing, and what the current smear offset is. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy From nobody Thu Feb 1 01:28:19 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A11212895E for ; Thu, 1 Feb 2018 01:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=meinberg.de 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 OwHSVPb209ZZ for ; Thu, 1 Feb 2018 01:28:16 -0800 (PST) Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BDF13165C for ; Thu, 1 Feb 2018 01:28:15 -0800 (PST) Received: from srv-kerioconnect.py.meinberg.de (unknown [217.6.112.194]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id 1572171C1788; Thu, 1 Feb 2018 10:28:12 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 server1a.meinberg.de 1572171C1788 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=meinberg.de; s=mail201101; t=1517477294; bh=JlqEv0pAsDS0zH2eJl/ajV41X4MtTBkB+ISnDH6ETVI=; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=FXOGK5Xp5IoVRY7y5WTMUEWqIQrHXBdJGYdshB4wSTG7sKjU+G5TD0sY+NAZb3Zfm IDc10/SQrC8erS68RY31Wg1EJyuIBDhm/ouF5gZY15vGgwbCwO2EpDT7AzSUlRYqx9 Zjj6C+nFIlhaFoIqAzit2mC5TVQV1veATzYzh1p8= X-Kerio-Anti-Spam: Build: [Engines: 2.15.8.1142, Stamp: 3], Multi: [Enabled, t: (0.000007,0.007180)], BW: [Enabled, t: (0.000009)], RTDA: [Enabled, t: (0.156483), Hit: No, Details: v2.6.16; Id: 15.5f4787.1c3t57927.i7821], total: 0(700) X-Footer: bWVpbmJlcmcuZGU= Received: from localhost ([127.0.0.1]) by srv-kerioconnect.py.meinberg.de with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 1 Feb 2018 10:28:10 +0100 To: art@ietf.org, Steffen Nurpmeso References: <6a2080c9-1e9b-a683-38fe-b69bcc8a1d0b@meinberg.de> <92593352-ac39-2208-24a3-912fd020caf0@strayalpha.com> <20180131204909.uNHwK%steffen@sdaoden.eu> Cc: Joe Touch From: Martin Burnicki Organization: Meinberg Funkuhren, Bad Pyrmont, Germany Message-ID: <446ca966-8973-5886-68f1-08e4f15aa389@meinberg.de> Date: Thu, 1 Feb 2018 10:28:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180131204909.uNHwK%steffen@sdaoden.eu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.3 at server1a X-Virus-Status: Clean Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 09:28:18 -0000 Steffen Nurpmeso wrote: > Joe Touch wrote: > ... > |(i.e., AFAICT, smearing is a local function that doesn't involve > |synchronization per se, but does rely on NTP-like sync of time outside > |the smearing period as well as external input on planned leap events) > > As far as i know nothing except the fully-blown and slow RFC 7808 > tzdist (untested) and Poul-Henning Kamp's leap DNS record idea as > posted on leapsecs@ helps to avoid the downloading and parsing of > the IERS leapseconds file on your own if you want to include > leapsecond notification in a daily report, on at least systems > which were off overnight. I think you need to distinguish here between (stratum-1) NTP servers and NTP clients, and it also makes a difference whether you just need to know if a leap second has been scheduled, or what the current offset is between UTC and e.g. TAI. Stratum-1 servers can receive a leap second announcement flag from a refclock, e.g. a GPS receiver, *if* both the receiver and the data protocol used with that receiver support this. Even though GPS receivers know the current UTC/GPS time offset internally by design, I'm not aware of any way to get this offset from a GPS receiver into ntpd, so with this approach ntpd can only detect when a leap second is approaching, but it doesn't know the current UTC/TAI offset, and thus it can only provide its clients with a leap second warning. If a *current* leap second file is available on the server then ntpd can figure out what the current UTC/TAI offset is, and determine if and when a leap second has been scheduled. If I remember correctly then this is also true for the tzdist or DNS approach. Once the NTP server knows about an upcoming leap second, it sends the leap second warning flag to the NTP clients, *unless* the server is smearing, in which case the leap second warning flag is omitted from the packets sent to the clients. The leap second warning flag is usually sent 24 hours before the leap second occurs, even if the NTP server knows about the upcoming leap second months before. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy From nobody Thu Feb 1 01:37:38 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD01131686 for ; Thu, 1 Feb 2018 01:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=meinberg.de 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 M0eUQLZmfxrh for ; Thu, 1 Feb 2018 01:37:34 -0800 (PST) Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7021316AB for ; Thu, 1 Feb 2018 01:37:29 -0800 (PST) Received: from srv-kerioconnect.py.meinberg.de (unknown [217.6.112.194]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id E554D71C1794; Thu, 1 Feb 2018 10:37:19 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 server1a.meinberg.de E554D71C1794 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=meinberg.de; s=mail201101; t=1517477848; bh=XOzfjpRHoZvx9K8QouKrjkb4vWw7UV0DursDniSTiXk=; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=oyGlzlo6tqfTnC2CJto3vQskJopwRjmV1TrHCBTKZMUcvP0KzTzM0cnCxcblXvgyh Ck3e0wYrN4w8WR7Xp6Z0fBr8a9rNDZGWaRS8LaljyvcFPrx3NNYLAbWqkNtHt4NXtl OmAGdQcQz1mCu6gXfFyEM4WDw657Jq3EQTnxb7vE= X-Kerio-Anti-Spam: Build: [Engines: 2.15.8.1142, Stamp: 3], Multi: [Enabled, t: (0.000007,0.004920)], BW: [Enabled, t: (0.000009)], RTDA: [Enabled, t: (0.148223), Hit: No, Details: v2.6.16; Id: 15.5f4goc.1c3t53r7g.icecj], total: 0(700) X-Footer: bWVpbmJlcmcuZGU= Received: from localhost ([127.0.0.1]) by srv-kerioconnect.py.meinberg.de with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 1 Feb 2018 10:37:17 +0100 To: Joe Touch Cc: Steffen Nurpmeso , art@ietf.org References: <6a2080c9-1e9b-a683-38fe-b69bcc8a1d0b@meinberg.de> <92593352-ac39-2208-24a3-912fd020caf0@strayalpha.com> <20180131204909.uNHwK%steffen@sdaoden.eu> <8637E113-79F7-46E9-81F1-367F79B6E029@strayalpha.com> From: Martin Burnicki Organization: Meinberg Funkuhren, Bad Pyrmont, Germany Message-ID: <16e46ba5-7f8d-846a-16a6-448479d06c91@meinberg.de> Date: Thu, 1 Feb 2018 10:37:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <8637E113-79F7-46E9-81F1-367F79B6E029@strayalpha.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.3 at server1a X-Virus-Status: Clean Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 09:37:36 -0000 Joe, Joe Touch wrote: > Leap seconds are introduced months in advance. That depends on the source of information. For a leap second file this is true, if the file is updated as soon as a new one has become available. GPS receivers also become aware of a scheduled leap seconds months in advance, but the question is if and when they start sending a warning of an upcoming leap second to the application, e.g. ntpd. The German DDF77 long wave receiver also sends a leap second warning, but only 1 hour in advance. If your time source is an IRIG or similar time code receiver then the receiver doesn't get a warning of an upcoming leap second at all. The time just steps by inserting a second "60". Only if one of the IRIG-compatible IEEE timecodes is used, a leap second *warning* is also transmitted, but only a few seconds before the leap second actually happens. So this can be pretty tricky. I've collected some information in a presentation: https://www.meinbergglobal.com/download/burnicki/Technical%20Aspects%20of%20Leap%20Second%20Propagation%20and%20Evaluation%20-%202015-06-23.pdf Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy From nobody Thu Feb 1 02:02:14 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C340B1318F1 for ; Thu, 1 Feb 2018 02:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=meinberg.de 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 ZZh9wp8UVfNf for ; Thu, 1 Feb 2018 02:02:11 -0800 (PST) Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E5612D886 for ; Thu, 1 Feb 2018 02:01:42 -0800 (PST) Received: from srv-kerioconnect.py.meinberg.de (unknown [217.6.112.194]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id D414571C1796; Thu, 1 Feb 2018 11:01:37 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 server1a.meinberg.de D414571C1796 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=meinberg.de; s=mail201101; t=1517479301; bh=rC3T9NVqxyAbbfGw/1Pq6cUanEigeZDBpv6E6uJJwOQ=; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=T4mnCsIfSHwqSo9LcSHFrve120QcXOYyS2WLOrDwJJ3cTG+tPiPJ4fmEDq6I8oN09 HQooAlSQdXo09IkQm7YYBqMrFshjQi2z+8zPxYlaNu3Aa5tp9oWTSXL5peJJCC05tr NfYsnNtYvs9bVhtY85xmsrv3m2xWLdIExY7A0tIg= X-Kerio-Anti-Spam: Build: [Engines: 2.15.8.1142, Stamp: 3], Multi: [Enabled, t: (0.000018,0.008971)], BW: [Enabled, t: (0.000009)], RTDA: [Enabled, t: (0.177644), Hit: No, Details: v2.6.16; Id: 15.5f4q0c.1c3t524e3.i09l1], total: 0(700) X-Footer: bWVpbmJlcmcuZGU= Received: from localhost ([127.0.0.1]) by srv-kerioconnect.py.meinberg.de with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 1 Feb 2018 11:01:35 +0100 To: Carsten Bormann , Applications and Real-Time Area Discussion Cc: Joe Touch , "Manger, James" References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> <20180127190806.GA23684@ucolick.org> <0E386E45-AC4D-413F-9CFF-6E644F2C4311@tzi.org> <681BFFCE-B468-4A10-8F2B-26260E4BB90D@tzi.org> <67A2F04D-9D38-4BF2-A96E-D29992A19F2E@tzi.org> <47ABA1B7-E77C-41E9-88AB-8618071B205C@strayalpha.com> From: Martin Burnicki Organization: Meinberg Funkuhren, Bad Pyrmont, Germany Message-ID: <1a8107f9-54d2-2fe6-09ff-abd69cc73440@meinberg.de> Date: Thu, 1 Feb 2018 11:01:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.3 at server1a X-Virus-Status: Clean Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 10:02:14 -0000 Carsten Bormann wrote: > Besides, the experiment already has been made in some very large sites, and site operators/reliability engineers liked the outcome. I think it depends on the kind of application if you like the outcome. ;-) Smearing is OK as long as applications can tolerate that the system time is temporarily off by up to 1 s (or -0.5 s ...+0.5 s). The advantage is that time increases monotonically all the time. On the other hand, if applications have to rely on a more accurate time then smearing is bad, and yes, I'm aware of the problems caused by just stepping the system time back by 1 s when the leap second is inserted. > No doubt, leapsecond smearing is wrong, impure, and a giant hack. > But the previous way in which Posix time worked is all these, too, plus it loses monotonicity and has a step function. I absolutely agree. > We haven’t put an indication of a time scale in draft-bormann-cbor-time-tag-01 yet (draft-bormann-cbor-time-tag-00 had one, but it wasn’t fully cooked). Besides UTC, TAI, and real-time variants of these (UTC(PTB) etc., TAI as approximated towards UTC(USNO) a.k.a. “GPS time + 19 s”, ...), it would be useful to have a smeared leapsecond time scale in there (and preferably just one). If the IETF can be instrumental in fostering and documenting some consensus here, this would be a big win. Haven't looked at the documents, yet, but IMO smearing should be done locally, by the OS. So an NTP server (or PTP grandmaster) wouldn't have to provide smeared time. It just had to provide a leap second warning flag, as usual, and when the clients received that warning they could determine if they would smear the system time, or not, or provide different APIs that return smeared time and non-smeared time. Some time ago I discussed with some kernel guys why they don't implement the workaround proposed by Dave Mills many years ago. That would basically stop the system clock during a leap second and let the the system time increase by 1 LSB (depending on the supported resolution) whenever the system time is read by an application. This would make sure the system time increases monotonically, but the reply from the kernel hackers was that the execution time required to read the system time is much longer if such comparisons/computation have to be done, than just stepping the time back by subtracting a 1 s offset. So also the execution time is important, and if the system clock supports smearing the execution time is also longer than without smearing. So IMO different APIs (e.g. the clock ID used with clock_gettime()) could alternatively provide the "legacy" time, or a smeared time. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy From nobody Thu Feb 1 10:35:34 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC1012EBD1 for ; Thu, 1 Feb 2018 10:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 beLK71ikQWe9 for ; Thu, 1 Feb 2018 10:35:30 -0800 (PST) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) by ietfa.amsl.com (Postfix) with ESMTP id D335212EC58 for ; Thu, 1 Feb 2018 10:35:20 -0800 (PST) Received: by sdaoden.eu (Postfix, from userid 1000) id B756C16045; Thu, 1 Feb 2018 19:35:19 +0100 (CET) Date: Thu, 01 Feb 2018 19:35:18 +0100 From: Steffen Nurpmeso To: Martin Burnicki Cc: art@ietf.org, Joe Touch Message-ID: <20180201183518.Bjh0y%steffen@sdaoden.eu> References: <6a2080c9-1e9b-a683-38fe-b69bcc8a1d0b@meinberg.de> <92593352-ac39-2208-24a3-912fd020caf0@strayalpha.com> <20180131204909.uNHwK%steffen@sdaoden.eu> <446ca966-8973-5886-68f1-08e4f15aa389@meinberg.de> In-Reply-To: <446ca966-8973-5886-68f1-08e4f15aa389@meinberg.de> Mail-Followup-To: Martin Burnicki , art@ietf.org, Joe Touch , Steffen Nurpmeso User-Agent: s-nail v14.9.6-48-gd837577b OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 18:35:32 -0000 Martin Burnicki wrote: |Steffen Nurpmeso wrote: |> Joe Touch wrote: |> ... |>|(i.e., AFAICT, smearing is a local function that doesn't involve |>|synchronization per se, but does rely on NTP-like sync of time outside |>|the smearing period as well as external input on planned leap events) |> |> As far as i know nothing except the fully-blown and slow RFC 7808 |> tzdist (untested) and Poul-Henning Kamp's leap DNS record idea as |> posted on leapsecs@ helps to avoid the downloading and parsing of |> the IERS leapseconds file on your own if you want to include |> leapsecond notification in a daily report, on at least systems |> which were off overnight. | |I think you need to distinguish here between (stratum-1) NTP servers and |NTP clients, and it also makes a difference whether you just need to |know if a leap second has been scheduled, or what the current offset is |between UTC and e.g. TAI. ... |Even though GPS receivers know the current UTC/GPS time offset |internally by design, I'm not aware of any way to get this offset from a |GPS receiver into ntpd, so with this approach ntpd can only detect when |a leap second is approaching, but it doesn't know the current UTC/TAI |offset, and thus it can only provide its clients with a leap second warning. | |If a *current* leap second file is available on the server then ntpd can |figure out what the current UTC/TAI offset is, and determine if and when |a leap second has been scheduled. If I remember correctly then this is |also true for the tzdist or DNS approach. So yes, sure, that is the status quo. And i still do not like it, because i sit at the end as a dumb consumer of a UTC timestamp and need to find other ways to realize a context, just in case i need it. It is not that bad because TZ ships the leapseconds file and so i can or better could give indication for dayling saving time and also leapsecond events. Without being online all the time that is. Or having a dedicated box like your company provides. All this is very sophisticated. I mean, not that bad no more, right now, due to easy VHOST and clowd services, and also cheap entry computers, but two decades back computers where, yes, a considerable investment and indeed an active equity. Right. And only because at the moment that cheap stuff is not, it may very well be at a later time again, given that stuff contains rare earth. And of course the gap in between poor and rich increases indeed and the middle class and their small businesses reassigns. I am hoping for an easy way, computational and otherwise, to become aware of the current difference in between TAI and civil time UTC. For example, a DNS entry that is so easy to parse as what Poul-Henning Kamp suggested on leapsecs@. I do not know about the territorial p.ssings which are involved in the NTP area, but the engineering community has finally found their way to DNS via DTLS, DNS via TCP/TLS, since yesterday and RFC 8314 we even have the submissions:// protocol that listens on the "legendary" port 465 (section 7.3), so maybe a future NTP spec will be secure via enwrap-in-*SSL and DTLS or TCP/TLS too, and offer some optional room for a UTC/TAI offset, which i think will or find some possible consumers. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Mon Feb 5 06:02:45 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC1F12D7F6 for ; Mon, 5 Feb 2018 06:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.931 X-Spam-Level: X-Spam-Status: No, score=-14.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=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 9mY2tGrzwUYk for ; Mon, 5 Feb 2018 06:02:42 -0800 (PST) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 4A3071252BA for ; Mon, 5 Feb 2018 06:02:42 -0800 (PST) Received: (qmail 74628 invoked by uid 99); 5 Feb 2018 14:02:41 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Feb 2018 14:02:41 +0000 Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com [209.85.213.45]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 96E8C1A0161 for ; Mon, 5 Feb 2018 14:02:40 +0000 (UTC) Received: by mail-vk0-f45.google.com with SMTP id f186so17677163vkc.1 for ; Mon, 05 Feb 2018 06:02:39 -0800 (PST) X-Gm-Message-State: AKwxytfPj1Ik0KiUO22/bxKLIdhrOj2VaXk/8pbbbD0i0tP5li/wrKN1 CkNb4cVhjnSHxmAsCMQgYubcKMNTDsF0PHumX/Ly2g== X-Google-Smtp-Source: AH8x227zbR3CMFHNL1r36g52N7BuhFc8y9LlpbQvrDOKg1UKoPdbtOqWqzyAurXJc7T7R+wJqBZGld6uskfQO7JLEzo= X-Received: by 10.31.176.142 with SMTP id z136mr40824731vke.22.1517839357894; Mon, 05 Feb 2018 06:02:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.89.114 with HTTP; Mon, 5 Feb 2018 06:02:17 -0800 (PST) X-Originating-IP: [84.92.48.26] From: Stian Soiland-Reyes Date: Mon, 5 Feb 2018 14:02:17 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Applications and Real-Time Area Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [art] Review draft-soilandreyes-arcp ? X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 14:02:44 -0000 Would you be able to comment on this Internet-Draft that is proposing the arcp:// URI scheme? I am intending to submit this as an Informational RFC and have contacted arts-ads@ - however I did not receive any response, so I'm taking it to the wider art@ list. See also discussions on uri-review@ - note this proposal was previously called draft-soilandreyes-app. https://tools.ietf.org/id/draft-soilandreyes-arcp-03.html Name: draft-soilandreyes-arcp Revision: 03 Title: The Archive and Package (arcp) URI scheme Document date: 2018-02-05 Group: Individual Submission Pages: 21 URL: https://www.ietf.org/internet-drafts/draft-soilandreyes-arcp-03.txt Status: https://datatracker.ietf.org/doc/draft-soilandreyes-arcp/ Htmlized: https://tools.ietf.org/html/draft-soilandreyes-arcp-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-soilandreyes-arcp-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-soilandreyes-arcp-03 Abstract: This specification define the Archive and Package URI scheme "arcp". arcp URIs can be used to consume or reference hypermedia resources bundled inside a file archive or an application package, as well as to resolve URIs for archive resources within a programmatic framework. This URI scheme provides mechanisms to generate a unique base URI to represent the root of the archive, so that relative URI references in a bundled resource can be resolved within the archive without having to extract the archive content on the local file system. An arcp URI can be used for purposes of isolation (e.g. when consuming multiple archives), security constraints (avoiding "climb out" from the archive), or for externally identiyfing sub-resources referenced by hypermedia formats. -- Stian Soiland-Reyes http://orcid.org/0000-0001-9842-9718 From nobody Mon Feb 5 06:09:59 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8165512D811 for ; Mon, 5 Feb 2018 06:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.931 X-Spam-Level: X-Spam-Status: No, score=-14.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=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 6s-3V2fiLJw1 for ; Mon, 5 Feb 2018 06:09:56 -0800 (PST) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 9FD9912D810 for ; Mon, 5 Feb 2018 06:09:56 -0800 (PST) Received: (qmail 99608 invoked by uid 99); 5 Feb 2018 14:09:56 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Feb 2018 14:09:56 +0000 Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com [209.85.213.45]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 4F3BD1A0161 for ; Mon, 5 Feb 2018 14:09:54 +0000 (UTC) Received: by mail-vk0-f45.google.com with SMTP id n132so17695900vke.2 for ; Mon, 05 Feb 2018 06:09:54 -0800 (PST) X-Gm-Message-State: AKwxytfm1kkfgYUY310ucJuv84WnHUDk9hFgKs7eZqJASNpUHjake6/G gZU5qyEy4xnN3cOrMvqWpyUY3pyp1kvDuJkHdxG5dQ== X-Google-Smtp-Source: AH8x227DMV8LCRyE3KJNWC3KxuqbSG7gan2DgENugeREH2NI10elysoC3q14ttegUdbe1WVPACK7ymV2CqVPTtdoHBs= X-Received: by 10.31.135.72 with SMTP id j69mr41646341vkd.167.1517839793278; Mon, 05 Feb 2018 06:09:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.89.114 with HTTP; Mon, 5 Feb 2018 06:09:32 -0800 (PST) X-Originating-IP: [84.92.48.26] In-Reply-To: References: From: Stian Soiland-Reyes Date: Mon, 5 Feb 2018 14:09:32 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Applications and Real-Time Area Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [art] Review draft-soilandreyes-arcp ? X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 14:09:58 -0000 On 5 February 2018 at 14:02, Stian Soiland-Reyes wrote: > Would you be able to comment on this Internet-Draft that is proposing > the arcp:// URI scheme? > > https://tools.ietf.org/id/draft-soilandreyes-arcp-03.html If you prefer code; here's a Python implementation for parsing/generating arcp URIs: https://github.com/stain/arcp-py http://arcp.readthedocs.io/ -- Stian Soiland-Reyes http://orcid.org/0000-0001-9842-9718 From nobody Mon Feb 5 07:52:19 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB0212708C for ; Mon, 5 Feb 2018 07:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=meinberg.de 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 CB-YMaJC-Nr1 for ; Mon, 5 Feb 2018 07:52:14 -0800 (PST) Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FE0B126C2F for ; Mon, 5 Feb 2018 07:52:14 -0800 (PST) Received: from srv-kerioconnect.py.meinberg.de (unknown [217.6.112.194]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id AD1EF71C02E9; Mon, 5 Feb 2018 16:52:04 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 server1a.meinberg.de AD1EF71C02E9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=meinberg.de; s=mail201101; t=1517845932; bh=+XqDHJK7NcDOazHfnvYbv0jeXOz7RBCig/Jof9Eo2yM=; h=From:Subject:To:References:Cc:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=MoBGeO9amkkZfacJ8EZKHkABi/GoPg9o4z/vrRh5oB8IMg2KxOu59HrR8Yu0Pc/Lo 2KCPLcXUP4Cb0LPelNLGEj9g3qMuppP8y/VLcHzgpl79TNKygOx+jRyOKOx4mJHems MVterZHAcRIMQ5pN9khLHKdnsldR2U1Bbt2UK9zI= X-Kerio-Anti-Spam: Build: [Engines: 2.15.8.1143, Stamp: 3], Multi: [Enabled, t: (0.000017,0.035179)], BW: [Enabled, t: (0.000011)], RTDA: [Enabled, t: (0.460069), Hit: No, Details: v2.6.16; Id: 15.5f4l02.1c3t4v3m7.m10m7], total: 0(700) X-Footer: bWVpbmJlcmcuZGU= Received: from localhost ([127.0.0.1]) by srv-kerioconnect.py.meinberg.de with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Mon, 5 Feb 2018 16:52:00 +0100 From: Martin Burnicki To: Steffen Nurpmeso References: <6a2080c9-1e9b-a683-38fe-b69bcc8a1d0b@meinberg.de> <92593352-ac39-2208-24a3-912fd020caf0@strayalpha.com> <20180131204909.uNHwK%steffen@sdaoden.eu> <446ca966-8973-5886-68f1-08e4f15aa389@meinberg.de> <20180201183518.Bjh0y%steffen@sdaoden.eu> Organization: Meinberg Funkuhren, Bad Pyrmont, Germany Cc: art@ietf.org, Joe Touch Message-ID: <38b0161a-2cf0-7100-e952-bf0b899d7855@meinberg.de> Date: Mon, 5 Feb 2018 16:52:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180201183518.Bjh0y%steffen@sdaoden.eu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.3 at server1a X-Virus-Status: Clean Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 15:52:17 -0000 Steffen Nurpmeso wrote: > Martin Burnicki wrote: > |Steffen Nurpmeso wrote: > |> Joe Touch wrote: > |> ... > |>|(i.e., AFAICT, smearing is a local function that doesn't involve > |>|synchronization per se, but does rely on NTP-like sync of time outside > |>|the smearing period as well as external input on planned leap events) > |> > |> As far as i know nothing except the fully-blown and slow RFC 7808 > |> tzdist (untested) and Poul-Henning Kamp's leap DNS record idea as > |> posted on leapsecs@ helps to avoid the downloading and parsing of > |> the IERS leapseconds file on your own if you want to include > |> leapsecond notification in a daily report, on at least systems > |> which were off overnight. > | > |I think you need to distinguish here between (stratum-1) NTP servers and > |NTP clients, and it also makes a difference whether you just need to > |know if a leap second has been scheduled, or what the current offset is > |between UTC and e.g. TAI. > ... > |Even though GPS receivers know the current UTC/GPS time offset > |internally by design, I'm not aware of any way to get this offset from a > |GPS receiver into ntpd, so with this approach ntpd can only detect when > |a leap second is approaching, but it doesn't know the current UTC/TAI > |offset, and thus it can only provide its clients with a leap second warning. > | > |If a *current* leap second file is available on the server then ntpd can > |figure out what the current UTC/TAI offset is, and determine if and when > |a leap second has been scheduled. If I remember correctly then this is > |also true for the tzdist or DNS approach. > > So yes, sure, that is the status quo. And i still do not like it, > because i sit at the end as a dumb consumer of a UTC timestamp and > need to find other ways to realize a context, just in case i need > it. It is not that bad because TZ ships the leapseconds file and > so i can or better could give indication for dayling saving time > and also leapsecond events. Without being online all the time > that is. Basically you have 2 options: Either you update the TZ DB on a regular basis, whenever a new version has been released, or you use a protocol like tzdist to do this automatically. While the former is under your control if you're the admin of a machine or whole network, your device is left alone if your distro / OS is out of support, or if you look at the huge number of embedded devices which never get a software update. These devices could at least update the TZ / leap second information if they can use the tzdist protocol, once this has become more popular. > Or having a dedicated box like your company provides. ... which provides accurate time and leap second information, but no TZ DB updates. ;-) > All this is very sophisticated. I mean, not that bad no more, > right now, due to easy VHOST and clowd services, and also cheap > entry computers, but two decades back computers where, yes, > a considerable investment and indeed an active equity. Right. At that time there weren't much folks who cared about millisecond or even microsecond accuracy, and the huge number of DOS-based machines didn't even know the difference between UTC and local time. ;-) There were no embedded devices running e.g. a *IX operating system internally like today, where many users of siuch devices don't even even knowing about this. > And only because at the moment that cheap stuff is not, it may > very well be at a later time again, given that stuff contains rare > earth. And of course the gap in between poor and rich increases > indeed and the middle class and their small businesses reassigns. Agreed, but how is this related to our topic? > I am hoping for an easy way, computational and otherwise, to > become aware of the current difference in between TAI and civil > time UTC. For example, a DNS entry that is so easy to parse as > what Poul-Henning Kamp suggested on leapsecs@. Again, I agree this is a clever and lightweight solution, but I don't know if this is really implemented somewhere. > I do not know about the territorial p.ssings which are involved in > the NTP area, but the engineering community has finally found > their way to DNS via DTLS, DNS via TCP/TLS, since yesterday and > RFC 8314 we even have the submissions:// protocol that listens on > the "legendary" port 465 (section 7.3), so maybe a future NTP spec > will be secure via enwrap-in-*SSL and DTLS or TCP/TLS too, and > offer some optional room for a UTC/TAI offset, which i think will > or find some possible consumers. I'm in no way against such new methods. Everything that makes things easier and more reliable is highly appreciated. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy From nobody Thu Feb 15 08:53:03 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDDD1270FC for ; Thu, 15 Feb 2018 08:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 4T0xJetonGeG for ; Thu, 15 Feb 2018 08:53:00 -0800 (PST) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) (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 0645F1200C1 for ; Thu, 15 Feb 2018 08:53:00 -0800 (PST) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay15.mail.ox.ac.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1emMmI-0002mP-mO; Thu, 15 Feb 2018 16:52:58 +0000 Received: from gklyne38.plus.com ([81.174.129.24] helo=spare-94.atuin.ninebynine.org) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1emMmH-000A7d-Ll; Thu, 15 Feb 2018 16:52:57 +0000 Message-ID: <5A85BAE9.4050508@ninebynine.org> Date: Thu, 15 Feb 2018 16:52:57 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Stian Soiland-Reyes , Applications and Real-Time Area References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 X-Oxmail-Spam-Status: score=0.0 tests=none X-Oxmail-Spam-Level: / Archived-At: Subject: Re: [art] Review draft-soilandreyes-arcp ? X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 16:53:02 -0000 On 05/02/2018 14:02, Stian Soiland-Reyes wrote: > Would you be able to comment on this Internet-Draft that is proposing > the arcp:// URI scheme? > > I am intending to submit this as an Informational RFC and have > contacted arts-ads@ - however I did not receive any response, so I'm > taking it to the wider art@ list. > > See also discussions on uri-review@ - note this proposal was previously called > draft-soilandreyes-app. > Hi Stian, Reviewing: https://tools.ietf.org/id/draft-soilandreyes-arcp-03.html Looking good! Mostly minor editorial comments, some terminology... ## 3.1. Authority "The authority is NOT intended to be resolvable without..." Do you mean resolvable or dereferencable or something else? (I'm not sure what it means for a URI authority to be resolvable - this term has a particular use at https://tools.ietf.org/html/rfc3986#section-5; see also https://tools.ietf.org/html/rfc3986#section-1.2.2). I'm not sure what point item 4 is intended to convey. ## 4.2. Path semantics "The path component of an arcp URI identify ..." nit: "identifies" (or otherwise more consistent use of singular/plural forms)? "undefined from this specification" --> "undefined by this specification" ## 4.3. Resolution protocol "This specification do not define..." --> "... does not ..."? "... resources according to the arcp URI scheme." --> "... resources identified using the arcp URI scheme"? "Such an implementation can then resolve arcp URIs, ..." Do you mean "dereference" rather than "resolve"? (cf. https://tools.ietf.org/html/rfc3986#section-1.2.2, para 2) Similar next para: maybe worth running a global search to check tis? "It is not undefined by this specification..." --> "... not defined ..."? ## 6. Interoperability considerations Item 1. on "The implementations may need to detect equality of the two UUIDs out of band.": "equality" --> "equivalence"? (I think I'd prefer something like "detect equivalent referents of the corresponding URIs...".) ## General I spotted, then lost, a few more minor editorial nits - if you have a source in guthub, I could offer a PR for your consideration. I wouldn't hold off requesting provisional registration until information RFC publication (assuming acceptance). The email address for that is different from the review list. Best regards, #g -- > > Name: draft-soilandreyes-arcp > Revision: 03 > Title: The Archive and Package (arcp) URI scheme > Document date: 2018-02-05 > Group: Individual Submission > Pages: 21 > URL: > https://www.ietf.org/internet-drafts/draft-soilandreyes-arcp-03.txt > Status: https://datatracker.ietf.org/doc/draft-soilandreyes-arcp/ > Htmlized: https://tools.ietf.org/html/draft-soilandreyes-arcp-03 > Htmlized: https://datatracker.ietf.org/doc/html/draft-soilandreyes-arcp-03 > Diff: https://www.ietf.org/rfcdiff?url2=draft-soilandreyes-arcp-03 > > Abstract: > This specification define the Archive and Package URI scheme "arcp". > > arcp URIs can be used to consume or reference hypermedia resources > bundled inside a file archive or an application package, as well as > to resolve URIs for archive resources within a programmatic > framework. > > This URI scheme provides mechanisms to generate a unique base URI to > represent the root of the archive, so that relative URI references in > a bundled resource can be resolved within the archive without having > to extract the archive content on the local file system. > > An arcp URI can be used for purposes of isolation (e.g. when > consuming multiple archives), security constraints (avoiding "climb > out" from the archive), or for externally identiyfing sub-resources > referenced by hypermedia formats. > > > From nobody Thu Feb 15 19:14:20 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D110126CD6 for ; Thu, 15 Feb 2018 19:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 rAOeMiSdmCCj for ; Thu, 15 Feb 2018 19:14:18 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 3D1F21243F3 for ; Thu, 15 Feb 2018 19:14:18 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-07v.sys.comcast.net with ESMTP id mWTOeeoFLXftWmWTZewn8t; Fri, 16 Feb 2018 03:14:17 +0000 Received: from hobgoblin.ariadne.com ([65.96.206.41]) by resomta-ch2-09v.sys.comcast.net with SMTP id mWTXeLiOJsRexmWTYeU0N5; Fri, 16 Feb 2018 03:14:17 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w1G3EF9M014978; Thu, 15 Feb 2018 22:14:15 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w1G3EEQT014975; Thu, 15 Feb 2018 22:14:14 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Stian Soiland-Reyes Cc: art@ietf.org In-Reply-To: (stain@apache.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 15 Feb 2018 22:14:14 -0500 Message-ID: <878tbtfwxl.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfMZn4NWaXRjkAYvR040uKh8tjyj+FV5BFHiVF6NpfGjFS9MFc7gIyUp00Lc+xj/TpJQOr3nEmFCiW2fuf613IrhTcYT7TDoyr9FcOeg4JAf8EX9miItZ jm0KH2opJOiAd319F3jV/rTmN6PTpOAEIuhFNaGBN25h5FHl3s+zRAwmag4WR71ANDPpO1w1CoIeBw== Archived-At: Subject: Re: [art] Review draft-soilandreyes-arcp ? X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 03:14:19 -0000 Stian Soiland-Reyes writes: > Would you be able to comment on this Internet-Draft that is proposing > the arcp:// URI scheme? I think you could make the draft clearer -- and attract more support -- by expanding the introduction. When I read the introduction (quickly), it told me the general idea of what you're trying to do, but it didn't make it clear to me how it would work in practice -- which would tell me which of my problems it would solve. The general idea seems to be a URI that identifies a component of an archive. Within an archive, components are identified by a path. (BTW, how the path part of a URL maps to a component name is more complicated than you'd expect -- see the definitions of the file: and ftp: URLs for examples that show the complexity. If you want arcp: to be widely adopted, you need to nail down those details.) What isn't so clear is how the authority part is matched with the archive itself. If the arcp: URI is inside a component of the archive, then it's clear how you find the archive, presumably you can verify that the authority matches the archive that you're already processing. (However, this is impractical if the authority part identifies the archive via a hash of the archive's contents, as that hash will depend on the arcp: URI contained in the component of the archive ...) Are these URIs expected to be used in any situation where they are not already contained within the archive that they refer to? In any case, one or more well-chosen, fairly complete examples in the introduction would make the concept much clearer. Dale From nobody Fri Feb 16 01:23:55 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF78E124B17 for ; Fri, 16 Feb 2018 01:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.931 X-Spam-Level: X-Spam-Status: No, score=-14.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=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 5l5m7f3Vv1tE for ; Fri, 16 Feb 2018 01:23:53 -0800 (PST) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 470DF1242F7 for ; Fri, 16 Feb 2018 01:23:53 -0800 (PST) Received: (qmail 15015 invoked by uid 99); 16 Feb 2018 09:23:52 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Feb 2018 09:23:52 +0000 Received: from mail-ua0-f174.google.com (mail-ua0-f174.google.com [209.85.217.174]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id A6333231 for ; Fri, 16 Feb 2018 09:23:51 +0000 (UTC) Received: by mail-ua0-f174.google.com with SMTP id a17so1390281uak.13 for ; Fri, 16 Feb 2018 01:23:50 -0800 (PST) X-Gm-Message-State: APf1xPCdS9dddQcQwI04SroiGLUdygzAhv0zsEDVCZzf7iIkNkDWIbDA 0MKB3O6SYloXFCAPibyR3z6sAjAEvxaHf8ic6a4GYQ== X-Google-Smtp-Source: AH8x226ypk73Ls7Uj+eafdhsP+qXO4zGJg5pmuwXcpsHc9cW2biuuJYdUAtCw1xKsVR4jjK6nJqvbeDg+mEETcqduKc= X-Received: by 10.159.55.239 with SMTP id q102mr4273723uaq.202.1518773030199; Fri, 16 Feb 2018 01:23:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.89.78 with HTTP; Fri, 16 Feb 2018 01:23:29 -0800 (PST) X-Originating-IP: [130.88.195.135] In-Reply-To: <5A85BAE9.4050508@ninebynine.org> References: <5A85BAE9.4050508@ninebynine.org> From: Stian Soiland-Reyes Date: Fri, 16 Feb 2018 09:23:29 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Graham Klyne Cc: Applications and Real-Time Area Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [art] Review draft-soilandreyes-arcp ? X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 09:23:55 -0000 Thank you for your review. I will take them into consideration and make an updated draft. The GitHub source is https://github.com/stain/I-D/blob/master/arcp/arcp.md - pull requests welcome! On 15 February 2018 at 16:52, Graham Klyne wrote: > On 05/02/2018 14:02, Stian Soiland-Reyes wrote: >> >> Would you be able to comment on this Internet-Draft that is proposing >> the arcp:// URI scheme? >> >> I am intending to submit this as an Informational RFC and have >> contacted arts-ads@ - however I did not receive any response, so I'm >> taking it to the wider art@ list. >> >> See also discussions on uri-review@ - note this proposal was previously >> called >> draft-soilandreyes-app. >> > > Hi Stian, > > Reviewing: > https://tools.ietf.org/id/draft-soilandreyes-arcp-03.html > > Looking good! > > Mostly minor editorial comments, some terminology... > > > ## 3.1. Authority > > "The authority is NOT intended to be resolvable without..." > > Do you mean resolvable or dereferencable or something else? (I'm not sure > what it means for a URI authority to be resolvable - this term has a > particular use at https://tools.ietf.org/html/rfc3986#section-5; see also > https://tools.ietf.org/html/rfc3986#section-1.2.2). > > I'm not sure what point item 4 is intended to convey. > > > ## 4.2. Path semantics > > "The path component of an arcp URI identify ..." > > nit: "identifies" (or otherwise more consistent use of singular/plural > forms)? > > "undefined from this specification" --> "undefined by this specification" > > > ## 4.3. Resolution protocol > > "This specification do not define..." --> "... does not ..."? > > "... resources according to the arcp URI scheme." --> "... resources > identified using the arcp URI scheme"? > > "Such an implementation can then resolve arcp URIs, ..." > > Do you mean "dereference" rather than "resolve"? (cf. > https://tools.ietf.org/html/rfc3986#section-1.2.2, para 2) > > Similar next para: maybe worth running a global search to check tis? > > "It is not undefined by this specification..." --> "... not defined ..."? > > > ## 6. Interoperability considerations > > Item 1. > > on "The implementations may need to detect equality of the two UUIDs out of > band.": "equality" --> "equivalence"? (I think I'd prefer something like > "detect equivalent referents of the corresponding URIs...".) > > > ## General > > I spotted, then lost, a few more minor editorial nits - if you have a source > in guthub, I could offer a PR for your consideration. > > I wouldn't hold off requesting provisional registration until information > RFC publication (assuming acceptance). The email address for that is > different from the review list. > > > Best regards, > > #g > -- > > > > > > >> >> Name: draft-soilandreyes-arcp >> Revision: 03 >> Title: The Archive and Package (arcp) URI scheme >> Document date: 2018-02-05 >> Group: Individual Submission >> Pages: 21 >> URL: >> https://www.ietf.org/internet-drafts/draft-soilandreyes-arcp-03.txt >> Status: https://datatracker.ietf.org/doc/draft-soilandreyes-arcp/ >> Htmlized: https://tools.ietf.org/html/draft-soilandreyes-arcp-03 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-soilandreyes-arcp-03 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-soilandreyes-arcp-03 >> >> Abstract: >> This specification define the Archive and Package URI scheme "arcp". >> >> arcp URIs can be used to consume or reference hypermedia resources >> bundled inside a file archive or an application package, as well as >> to resolve URIs for archive resources within a programmatic >> framework. >> >> This URI scheme provides mechanisms to generate a unique base URI to >> represent the root of the archive, so that relative URI references in >> a bundled resource can be resolved within the archive without having >> to extract the archive content on the local file system. >> >> An arcp URI can be used for purposes of isolation (e.g. when >> consuming multiple archives), security constraints (avoiding "climb >> out" from the archive), or for externally identiyfing sub-resources >> referenced by hypermedia formats. >> >> >> > -- Stian Soiland-Reyes http://orcid.org/0000-0001-9842-9718 From nobody Fri Feb 16 01:46:11 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC66126E64 for ; Fri, 16 Feb 2018 01:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.931 X-Spam-Level: X-Spam-Status: No, score=-14.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=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 mZ4cgKpxxukw for ; Fri, 16 Feb 2018 01:46:08 -0800 (PST) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 080541242F7 for ; Fri, 16 Feb 2018 01:46:08 -0800 (PST) Received: (qmail 48214 invoked by uid 99); 16 Feb 2018 09:46:07 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Feb 2018 09:46:07 +0000 Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com [209.85.213.54]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 76A30231 for ; Fri, 16 Feb 2018 09:46:06 +0000 (UTC) Received: by mail-vk0-f54.google.com with SMTP id t126so1449260vkb.11 for ; Fri, 16 Feb 2018 01:46:06 -0800 (PST) X-Gm-Message-State: APf1xPCKZshAEm7hHtBCF2U/1Q3PTMOaReb7wGQAqN42njNhuZeU1YR8 X6ykpugDRVIlXTjuZrboSzs2tMkG06KAhcWludZdkQ== X-Google-Smtp-Source: AH8x227u08Wp+iWwKeGkt6O7Hu+pUn6KhoIMBtIqJprG8E66+mFFYlq5tB8IrMxP0j/2DYwN1pXt5gTCGLFZZ7DKcwA= X-Received: by 10.31.124.7 with SMTP id x7mr4334380vkc.115.1518774365709; Fri, 16 Feb 2018 01:46:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.89.78 with HTTP; Fri, 16 Feb 2018 01:45:45 -0800 (PST) X-Originating-IP: [130.88.195.135] In-Reply-To: <878tbtfwxl.fsf@hobgoblin.ariadne.com> References: <878tbtfwxl.fsf@hobgoblin.ariadne.com> From: Stian Soiland-Reyes Date: Fri, 16 Feb 2018 09:45:45 +0000 X-Gmail-Original-Message-ID: Message-ID: To: "Dale R. Worley" Cc: Applications and Real-Time Area Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [art] Review draft-soilandreyes-arcp ? X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 09:46:10 -0000 On 16 February 2018 at 03:14, Dale R. Worley wrote: > I think you could make the draft clearer -- and attract more support -- > by expanding the introduction. When I read the introduction (quickly), > it told me the general idea of what you're trying to do, but it didn't > make it clear to me how it would work in practice -- which would tell me > which of my problems it would solve. Thanks for your review! Agree that the introduction needs more work, perhaps it has too much of "Background" and too little of "Introduction". > The general idea seems to be a URI that identifies a component of an > archive. Within an archive, components are identified by a path. (BTW, > how the path part of a URL maps to a component name is more complicated > than you'd expect -- see the definitions of the file: and ftp: URLs for > examples that show the complexity. If you want arcp: to be widely > adopted, you need to nail down those details.) Yes, I touched on some of those issues in earlier drafts, but removed them after feedback that it got too complicated! This could be quite extensive if looking across archive formats - e.g. OS X .dmg images can have multiple roots (one per Volume), a tape might have multiple backup sessions. The easiest approach here is probably that if there is no "default root" then there would simply be a new authority for each root (potentially nested from an outer arcp). But that would mean archive-specific conventions need to be formed. Trying to use arcp with more executable resource formats like .dll files (like 7zip can explore) probably makes it trickier to decide on consistent paths. I previously had a more detailed path section: https://tools.ietf.org/id/draft-soilandreyes-app-03.html#rfc.section.2.2 that gave the obvious mapping from URI path segments to folders in the archive. But then many archive formats (e.g. zip) don't really have folders, just arbitrary paths. I feel that I probably could detail this mapping more, but as that would bring us closer to the archive as a file container, that would have to be at the cost of dropping the old "app" aspect with more abstract resource paths (example 7 https://tools.ietf.org/id/draft-soilandreyes-arcp-03.html#rfc.appendix.A.7 ) and would make it weirder that ?query is permitted (I was asked to re-permit ?query) > What isn't so clear is how the authority part is matched with the > archive itself. I think my idea was that you get say a ZIP file that you then keep "somewhere". At the same time you generate an arcp authority, e.g. a random UUID - which you associate with the ZIP file. It is application-specific how (and for how long) you keep this link - perhaps you add a neighboring foo.zip.arcp file, or add it as an extended attribute on the file system, keep it in some database, or just always do a new UUID in memory. > If the arcp: URI is inside a component of the archive, > then it's clear how you find the archive, presumably you can verify that > the authority matches the archive that you're already processing. Yes, I guess the possibility of self-declaring is what I hinted at in example https://tools.ietf.org/id/draft-soilandreyes-arcp-03.html#rfc.appendix.A.4 where the arcp authority is derived from the declared External-Identifier uuid. There's the risk here that the archive is lying or have different mutability expectations than the application. > (However, this is impractical if the authority part identifies the > archive via a hash of the archive's contents, as that hash will depend > on the arcp: URI contained in the component of the archive ...) Yes, obviously you can't declare your own hash inside - but then again the hash can be calculated by anyone able to read the whole archive file/stream. That is the purpose of this authority prefix, anyone reading the same archive byte (using the same hash algo) will get the same arcp authority, even if they got the archive through different means. > Are these URIs expected to be used in any situation where they are not > already contained within the archive that they refer to? Yes, we can't expect all archives to be able to self-declare their identities, and I think arcp should be usable for any path-like archive found "in the wild". > In any case, one or more well-chosen, fairly complete examples in the > introduction would make the concept much clearer. Thanks - I had moved all the examples to the appendix, but I can add a quick example at the top. -- Stian Soiland-Reyes http://orcid.org/0000-0001-9842-9718 From nobody Fri Feb 16 04:49:07 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06F4124BE8 for ; Fri, 16 Feb 2018 04:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 SQ5cvb2x-Ode for ; Fri, 16 Feb 2018 04:49:05 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (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 F12E5120713 for ; Fri, 16 Feb 2018 04:49:04 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id mfRaeMjQy8L19mfRoeb1ve; Fri, 16 Feb 2018 12:49:04 +0000 Received: from hobgoblin.ariadne.com ([65.96.206.41]) by resomta-ch2-20v.sys.comcast.net with SMTP id mfRme0LiVm6cKmfRnecAXc; Fri, 16 Feb 2018 12:49:03 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w1GCn13B014190; Fri, 16 Feb 2018 07:49:01 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w1GCn1ga014187; Fri, 16 Feb 2018 07:49:01 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Stian Soiland-Reyes Cc: art@ietf.org In-Reply-To: (stain@apache.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 16 Feb 2018 07:49:01 -0500 Message-ID: <87wozddrr6.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfKJOcmtxhiDtOfpvQ3vHyqwZaOJqSKUKEzSq6HxEDr4+U3IIN6/Y8A+0jfGF/BQkx7jeSTSwU+Yij27oXsSNHQcU4IDmXI3+3MT1V9aGxuYg8x21uHb2 Rn8g+WRRuqiE82WdHT/5Bt2mfMeRlu1N/XcCYN16WmFharX1ULNFwVHux6hgJoUve1EgnGS/zyAHkQ== Archived-At: Subject: Re: [art] Review draft-soilandreyes-arcp ? X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 12:49:06 -0000 Stian Soiland-Reyes writes: > Yes, I touched on some of those issues in earlier drafts, but removed > them after feedback that it got too complicated! > > This could be quite extensive if looking across archive formats - e.g. > OS X .dmg images can have multiple roots (one per Volume), a tape > might have multiple backup sessions. The easiest approach here is > probably that if there is no "default root" then there would simply be > a new authority for each root (potentially nested from an outer arcp). > But that would mean archive-specific conventions need to be formed. A critical point is that arcp: can only be used with a particular archive type if the conventions for that archive type are defined. In re file:, they had to figure out how to make it work with file systems for which "/" can be part of an ordinary file name. In regard to ftp:, it has no "absolute directory names", the only specification of a directory is a sequence of CWD commands, which when executed, reach the desired directory. Getting these details right is critical to having the scheme work well across all archives of an archive type. In regard to the multiple roots of .dmg, I suspect that each root/Volume has some sort of unique identifier within the .dmg, and that can be used as the first element of the path. >> What isn't so clear is how the authority part is matched with the >> archive itself. > > I think my idea was that you get say a ZIP file that you then keep > "somewhere". At the same time you generate an arcp authority, e.g. a > random UUID - which you associate with the ZIP file. It is > application-specific how (and for how long) you keep this link - > perhaps you add a neighboring foo.zip.arcp file, or add it as an > extended attribute on the file system, keep it in some database, or > just always do a new UUID in memory. I think that touches on my doubt: The only time a URI is *useful* is if it's (1) generated by one application and (2) interpreted by another application. And in (2), the interpreting application must not be treating the URI as a purely opaque string. (In the case of URLs, this condition is always met, because the retriever of the resource determines the protocol to be used by parsing the URL.) Looking at the first five examples in the appendix, the "interpreters" seem to understand the path parts, but the authority parts seem to be used as opaque strings; the authority parts are always resolved by querying the application that generated them. With that limitation on usage, the use cases can be satisfied by just considering the URI to be a pair: (opaque archive identifier, path within archive). Creating a URI format to carry that information doesn't add any value. Which, I think, points to an approach where there would be benefit: The arcp: URI *is* a pair: (URI of the archive, path within archive). (I'm ignoring the syntax of how one represents this information in the URI.) If the archive URI is a URL that fetches an archive object, then an application can interpret and dereference the arcp: URI. If the archive URI is an ni: URN, then the path is inside the archive that has that URN. That doesn't give the interpreter a way to obtain the archive object, but if it already possesses the archive object, it can match the ni: URI with the archive, and then locate the intended component. If the archive URI is a uuid: URN, then the semantics is that it designates the archive that is named by that UUID, although the method by which the UUID is associated with the archive is out of scope of this document -- presumably the archive format defines how that is done and the UUID is stored in the archive. Etc. Dale From nobody Sat Feb 17 06:13:54 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634A8124F57 for ; Sat, 17 Feb 2018 06:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.972] autolearn=no autolearn_force=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 KozNYYx6w_Eu for ; Sat, 17 Feb 2018 06:13:52 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 37D751241F8 for ; Sat, 17 Feb 2018 06:13:52 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-05v.sys.comcast.net with ESMTP id n3EreSHNyliDin3FOeOF4c; Sat, 17 Feb 2018 14:13:50 +0000 Received: from hobgoblin.ariadne.com ([65.96.206.41]) by resomta-ch2-10v.sys.comcast.net with SMTP id n3FNeSnAOxVSTn3FOee6QD; Sat, 17 Feb 2018 14:13:50 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w1HEDmUc025983; Sat, 17 Feb 2018 09:13:48 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w1HEDlTZ025980; Sat, 17 Feb 2018 09:13:47 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: stain@apache.org, art@ietf.org In-Reply-To: <87wozddrr6.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sat, 17 Feb 2018 09:13:47 -0500 Message-ID: <87r2pjemas.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfJIW0ZJZQ2yeQE6yNOGvVOsr93IP8Mxbv8csMIWvV7GLV+x2h7hhjFw+t6kpTvhLmaqQWZatgRIVlX74s+vTcG9539rgHeFSFa99a+ndYJNhSCjyESrn Ddi5YTDYX3t16Td6xZkbYlL4W6KakxoUC39v8joXqRudHUloOCWonzLzPQG5VAVfGfX2puuzZihsCw== Archived-At: Subject: Re: [art] Review draft-soilandreyes-arcp ? X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Feb 2018 14:13:53 -0000 This gets more interesting the longer you look at it... You might want to look into draft-shur-pack-uri-scheme and whatever discussion there was around it and compare it with your work. I was mumbling about this in a previous message: > Which, I think, points to an approach where there would be benefit: The > arcp: URI *is* a pair: (URI of the archive, path within archive). (I'm > ignoring the syntax of how one represents this information in the URI.) > If the archive URI is a URL that fetches an archive object, then an > application can interpret and dereference the arcp: URI. But if course, there *is* a URI syntax for that concept: fragment identifiers a/k/a '#'. Given a URI that designates a resource, the URI to designate part of the resource is made by appending '#' and an identifier for the part. The syntax and semantics of the fragment identifiers depend on the media type of the resource, not the scheme of the URI, which makes sense, because the "parts" of a resource are independent of how you obtained the resource. So the natural question is, Are fragment identifiers defined for the various archive media types? >From the draft and this e-mail discussion, I can extract this list of archive types: dmg ZIP bagit tar vnd.android.package-archive x-tar x-gtar x-7z-compressed Of these, only ZIP is has a registered media type, and that gives just a link to Paul Lindner, dated 1993. It looks like nobody has defined fragment identifiers for archive resource types! (We could consider the "multipart/*" media types as archives as well. Presumably their fragment identifiers are the msg-id values in the Content-ID headers of the parts, or integer sequence numbers of the parts.) Sections 3.2 and 4.2 are the considerations for defining how fragment identifiers for archives identify components. If fragment identifiers were defined for archive types, and we use them, the following changes would be seen in the examples. Note that the syntax changes are substantial, but the semantics don't change: The application generates the corresponding arcp URIs and uses those for URI resolutions to list resources and their hyperlinks: urn:uuid:32a423d6-52ab-47e3-a9cd-54f418a48571#doc.html -> urn:uuid:32a423d6-52ab-47e3-a9cd-54f418a48571#css/base.css urn:uuid:32a423d6-52ab-47e3-a9cd-54f418a48571#css/base.css -> urn:uuid:32a423d6-52ab-47e3-a9cd-54f418a48571#fonts/Foo.woff urn:uuid:32a423d6-52ab-47e3-a9cd-54f418a48571#fonts/Foo.woff -- From this the hash-based arcp base URL is: ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk [Note that ni: URIs do not end with a slash.] The repository adds annotations for detected source code files within the archive. A client is browsing the annotations and discovers: ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk#src/luhn.c -- The application generates a random UUID v4 "ff2d5a82-7142-4d3f-b8cc- 3e662d6de756" and adds the corresponding "urn:uuid" UUID to the bag metadata file "/gfs/bags/scan15/bag-info.txt" External-Identifier: urn:uuid:ff2d5a82-7142-4d3f-b8cc-3e662d6de756 [Note that uuid: URNs do not end with a slash.] It then generates arcp URIs for the files listed in the manifest: urn:uuid:ff2d5a82-7142-4d3f-b8cc-3e662d6de756#data/27613-h/q172.png urn:uuid:ff2d5a82-7142-4d3f-b8cc-3e662d6de756#data/27613-h/q172.txt -- urn:uuid:12f89f9c-e6ca-4032-ae73-46b68c2b415a But to make this works requires registering media types for the various archive formats, registrations which define fragment identifiers as referencing components of the archives. That includes dealing with any syntactic issues regarding encoding the component names (as seen by the archive format) into the syntax of fragment identifiers. This allows us to consider an aspect of fragment identifiers that only arises with "archives", resources that can contain other resources. Suppose I have a URL for an HTML file: http://foo.example.com/bar.html If I want to refer to an anchor 'baz' within bar.html, I say http://foo.example.com/bar.html#baz And any browser can render that. Now suppose I have a URL for an archive: http://foo.example.com/quux.zip. If I want to reference bar.html within the archive, presumably I say http://foo.example.com/quux.zip#bar.html But there's no defined way to reference the anchor 'baz' inside the HTML file bar.html inside the archive quux.zip. What is needed are "recursive" fragment identifiers for archives, a fragment identifier (per the URI syntax) that contains (1) the name of a component of the archive, and (2) a general fragment identifier to be dereferenced within that component. The obvious syntax is # component # fragment-within-component but the URI syntax doesn't allow '#' within fragment identifiers. A decent choice seems to be # component @ fragment-within-component (Per RFC 3986, only two characters are allowed in 'fragment' that are not 'unreserved' or 'sub-delims', ":" and "@". They are in the class 'gen-delims', and presumably "more magic" than other characters. I choose "@" over ":" because my intuition is that ":" is more commonly used in file names. Of course, a consequence of this is that "@" within a component name is special, and has to be %-escaped.) With this extension, we can say http://foo.example.com/quux.zip#bar.htm@baz Note that this concept has to be defined as a feature of the fragment identifiers for each archive type; its conceptual unity comes from all media type definitions for archive types agreeing on this syntax and semantics. This allows us to concisely deal with archive files that are themselves contained within archives. If quux.zip contains an archive corge.zip, then corge.zip can be referenced http://foo.example.com/quux.zip#corge.zip grault.html within corge.zip can be referenced http://foo.example.com/quux.zip#corge.zip@grault.html and the HTML anchor garply in grault.html is http://foo.example.com/quux.zip#corge.zip@grault.html@garply What this mapping of the draft's concepts does NOT cover so far is the semantics of "name" authorities. As I understand it, arcp URIs with "name" authorities form an abstract namespace which is scoped to a context, a "particular installation". The authority part is syntactically a domain name, and the meaning of a particular URI is defined by the owner of that domain name. I've tried looking through the IANA list of existing URI schemes and URN namespaces, and I can't spot anything that looks like it has these semantics. So it looks like this is a good candidate for a new URI scheme. I notice that the scheme "name" has not been used! However, it might not be best to call them "names", as the usage of that word when defining URNs requires that the resource that a "name" refers to must be unique and never change, whereas the example in section A.7 suggests that the mapping from URIs to resources might change with time. The generic "resource" is already registered. However, "pack" (for "package") has a provisional registration referencing an I-D that expired in 2009, and so might be available. Using "pack", the examples of the draft become pack://app.example.com/img/logo.png pack://gallery.example.org/ pack://gallery.example.org/photos/?New pack://gallery.example.org/photos/137 pack://messaging.example.com/share;+{uri};{+redirect} pack://messaging.example.com/share ;uri=arcp://gallery.example.org/photos/137 ;redirect=arcp://gallery.example.org/photos/%3fNew Trying to distill all this into a plan, it seems to me that a way to carry this work forward in a way that is well-aligned with existing URI usage is: - Register media types for the popular archive formats, defining fragment identifiers to identify components of the archive, aligning the fragment identifier definitions with each other and the considerations in sections 3.2 and 4.2. - Define a method by which fragment identifiers can carry sub-fragment identifiers that apply to an identified component of an archive, and ensure that the archive media types are aligned with it. - Possibly register (or define in an RFC?) the use of fragment identifiers for all multipart/* media types. - Define a new URI type that carries the semantics that are proposed for "name," authorities. The first three of these would naturally fit into one RFC, since the definitions for the various media types need to be aligned with each other and have common considerations. The fourth item could be processed as a separate RFC. Dale From nobody Sun Feb 18 14:09:29 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A086F126E64 for ; Sun, 18 Feb 2018 14:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=KBwWa3Gq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PwJgRnDv 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 nm3RWPOpLm-R for ; Sun, 18 Feb 2018 14:09:25 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653CB1267BB for ; Sun, 18 Feb 2018 14:09:25 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9331A20C4F for ; Sun, 18 Feb 2018 17:09:24 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Sun, 18 Feb 2018 17:09:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=KvBcOmiF/KNlWEl64sD17PPxRzIT3C7ziBru8ydrvvM=; b=KBwWa3Gq BbZV8CmEdVt+eVCVFLiJhjDasw28w7lQ7YDID5HzZG7TWR4bK96e60m6YPsMYYKx Xb9a3+c9ujvg5CRByVDJ587D3KesDS81n4XP91u2mKLvB9VqCFuRa3eVx/wQyq0W X5ac3K/aJcJm45IkNP1kt4VcLn2vTWWUQdNzWe8DgtbyTJIw1BBiOkejKnlhHCLH Eg4uhuARPYkSESzghJ77ZiWNfevA8n0szDSMmueFZeKKvk8hRgUMQWxpvt/CX+Xy 75kastd8p5Rqcoa8EDMinf/kdro8FWXD0F7VL4oidk6NRhDaG4wp0FrPe2yJH/GC VI6dnE48ZtPbTQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=KvBcOmiF/KNlWEl64sD17PPxRzIT3 C7ziBru8ydrvvM=; b=PwJgRnDvxjC674yN95rKedIhR0b1kvSxkXptYzkbv+i3R vNAN1d2c/o8P7XmnAnUSyxmQFJhNqQv/unuahq1Bgiy7ZkOWArKhlPVdUA8pQcnZ 8MqmBtbj12U9Iro4brrTEa460fiiYV1oQjQOK94PoWOd7JtyuOKi/bW25IZTy4MD G6uh8lIpWoOJ7+kcuNSfqDHXoeKYkm36TW3IoIrGBmUQXXnBkqs4eNHxubz5pJ/m 1Ly/rY67hoMWTeo6TONTbSpk5pv/mk6Nv60hKFiMeMt8iERIGcoFvzXYff8HVHQe cxLwNqiE6QjNFdaE0qrNQ2jojUcSnr1cKay7kpY8g== X-ME-Sender: Received: from [192.168.1.18] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id D55047E1F4 for ; Sun, 18 Feb 2018 17:09:23 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <143D15D4-63BA-4EC1-91E1-2E1C88950BBC@mnot.net> Date: Mon, 19 Feb 2018 09:09:20 +1100 To: Applications and Real-Time Area Discussion X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [art] WHATWG Bar BoF? X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 22:09:28 -0000 Hi, A couple of WHATWG folks are coming to IETF London. Would folks be = interested in a Bar BoF on Sunday night to chat with them? Some things that we could discuss include: - URL: https://url.spec.whatwg.org - MIME sniffing: https://mimesniff.spec.whatwg.org - Fetch: https://fetch.spec.whatwg.org - Infrastructure: https://infra.spec.whatwg.org - Their new governance model: = https://blog.whatwg.org/working-mode-changes Who'd be interested? -- Mark Nottingham https://www.mnot.net/ From nobody Sun Feb 18 17:51:06 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F36124B0A for ; Sun, 18 Feb 2018 17:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JOwmSmgZkiAs for ; Sun, 18 Feb 2018 17:51:04 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9C6124234 for ; Sun, 18 Feb 2018 17:51:04 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id a207so4540513oii.10 for ; Sun, 18 Feb 2018 17:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XSNLEdUrWyh45ViTQml3PYmyKGHzhDxT1Hza+fSfu3w=; b=ID/SfYdi8ANodzy5J03pRneTUPuI/MJzzS8NVvjWSMRZQOIOloAGhzSiJ32e6mHb/B UH2Qn8EqHM/94DI2JIRLcMWDT8ngd7IymlCT5uGrny1f2EWfw5lCx9/XNIUsH9L8YYrX rzlBA3aCv5NYvosMF1c0Jxk+nI7oV5AeyaGiCePP5dIIYRa56XpK2iktgx9v7J3tTJKc bsmxDSwnPg0DGIIckJAdMswJ1PMy6BGmqo/9NRxIgTtfXPJjaQhsFw2k4QHn6BTD2jkp 8fGqW9nxFNCcn8fQzuk6v5wN+3LI2XuNs8RqSdMpSK+q19rQYNBfL0H85qtucE7D+kl8 JKWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XSNLEdUrWyh45ViTQml3PYmyKGHzhDxT1Hza+fSfu3w=; b=gZ9VY8scgpUve6p/kSx9J7l0ae3P73RNpQniUJBGXpOHQUv73lkxSmAxfn0wLOn/JV qeIBcjmqAw73jSP32rxvnigeB5np1Q1LFNfaTk+hX0dEV1jadPAAzc0JwB7NxfDw8tw1 13Qun4kVnTj/fxuzYKvgkpL9NVpY6rGa4W7WkHqi0fDhxgIkJXhVMQwIcc6106MPS3a+ 9wjX53/LyFv4avV8M4I3789CkgjHVYcuFzFglSd6Mjx5uFqdxL9g8Mi+GbhWpAVeMeWM 2Gqr7MGCPNSf24gA3QJms9ShB6GfaYE0SWj+2KMQg24fwU+2tMKsQ1FcJbklhhJOLHcu 7gSg== X-Gm-Message-State: APf1xPAkdicUFTUEyUtpBiftZz7L6jHgGQ+fpU4BOpXuzgS/hVkk//x8 rEUno97ShaVDNlpT5ybn2ztJq5qKb+MjZQFXaW/5gw== X-Google-Smtp-Source: AH8x225cncCu+p6yYnKD4BKQj8kRnpT5S08xfThUgeV8MdDj4LeqvtQEC77Ht+3dk0+/NW2NeivJIVJuFG/5ZczZ+4U= X-Received: by 10.202.56.214 with SMTP id f205mr8710914oia.254.1519005063500; Sun, 18 Feb 2018 17:51:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Sun, 18 Feb 2018 17:51:03 -0800 (PST) In-Reply-To: <143D15D4-63BA-4EC1-91E1-2E1C88950BBC@mnot.net> References: <143D15D4-63BA-4EC1-91E1-2E1C88950BBC@mnot.net> From: Martin Thomson Date: Mon, 19 Feb 2018 12:51:03 +1100 Message-ID: To: Mark Nottingham Cc: Applications and Real-Time Area Discussion Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [art] WHATWG Bar BoF? X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 01:51:05 -0000 Sounds like a good idea to me. As long as it is at a real bar and not one of these "bar bofs" we seem to see more of lately. On Mon, Feb 19, 2018 at 9:09 AM, Mark Nottingham wrote: > Hi, > > A couple of WHATWG folks are coming to IETF London. Would folks be interested in a Bar BoF on Sunday night to chat with them? > > Some things that we could discuss include: > > - URL: https://url.spec.whatwg.org > - MIME sniffing: https://mimesniff.spec.whatwg.org > - Fetch: https://fetch.spec.whatwg.org > - Infrastructure: https://infra.spec.whatwg.org > - Their new governance model: https://blog.whatwg.org/working-mode-changes > > Who'd be interested? > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art From nobody Thu Feb 22 05:52:27 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7377512EAC6 for ; Thu, 22 Feb 2018 05:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EWjaaUfY-q2q for ; Thu, 22 Feb 2018 05:52:24 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA6912711E for ; Thu, 22 Feb 2018 05:52:24 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id v124so6457118qkh.11 for ; Thu, 22 Feb 2018 05:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tJwi6ZpFvubQqz8riP84rhG3eDz078NJjIujCKL1W5w=; b=PEmX+4FWOJbv8zz06mxcY3uCIWGvJ83VgNfmxlTyRdIdUThYoIohuGcgzxZsKpH/vZ dYIO0DWeNzP6gYufy+l2X7QLkcsPQ1tk55IBU97ReA1w+EGB2hv9FmqDVxPhhSngtENO yb8QBUvvgeFw+vmkRs5unb0kSB560U5dirHoGN/nGQmDSHtdZI7T36YReJfMvpi+rjDO abBwFkjD/xUg6puqzz+29+0qkjEAflkd3X6NbVpg4h77u4SZtyP9axKdyDobmwl2V98z JBj4Y/Yj6Y6cSn8ArmrEI8420RFvdKqXxlkjkcLFLlqCh0l5e4CDWo95Dc7rWr75eUE2 GTSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tJwi6ZpFvubQqz8riP84rhG3eDz078NJjIujCKL1W5w=; b=ktpylLATWKKF9+UK3G+QBgWWptTdrlYxZU5sPQHOo+IsKUktRrEZqMVnyFF2RRx59L nCtP3e7ExqZDAGrMtGKbtBZoOK+K5EQwSzb2yd2KVwbuk/FWaGCIy0N4JDicVgs7Abpv 8Fe9mc1QuHCy8kNlUf5lHSB84SBGVmUX+5J9otNKHY+6wKQrppM3B+jrWY5Sg+sqCqua jnxeW2FiYSrdpVIKwkIQUwZjx0w/FLg3RK0di5Ex2Cld8A3hy5R0ljoO+9Vc3qeNkieS 95GZBcTPwFGbiYa/nngxOzeKTzppXnyEOduRWekjIeAOX17qLT4W1PtcUXcJ2UFXdt59 7V2Q== X-Gm-Message-State: APf1xPBlcdo/WRPmZx3TvoWl27GGm+HvHu7GbVt+ykOWdW2BD90X0QX8 6lX7tm1v3czkjgs+9kSAk4u17OKfVW5WNQqdHMw= X-Google-Smtp-Source: AG47ELvblYkcetYdghjvmZoBlIRXV0dfa2ztp/wXQSLJCOtkzMpvf+3fw8Vlf2QmPu78c9reCps5CP4TZYHig0GcSKA= X-Received: by 10.55.172.1 with SMTP id e1mr10427312qkm.245.1519307543534; Thu, 22 Feb 2018 05:52:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.185.44 with HTTP; Thu, 22 Feb 2018 05:52:22 -0800 (PST) In-Reply-To: References: <143D15D4-63BA-4EC1-91E1-2E1C88950BBC@mnot.net> From: Kevin Marks Date: Thu, 22 Feb 2018 13:52:22 +0000 Message-ID: To: Martin Thomson Cc: Mark Nottingham , Applications and Real-Time Area Discussion Content-Type: multipart/alternative; boundary="f4f5e80786286fe3660565cd5a11" Archived-At: Subject: Re: [art] WHATWG Bar BoF? X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 13:52:26 -0000 --f4f5e80786286fe3660565cd5a11 Content-Type: text/plain; charset="UTF-8" I'm potentially interested (I am in London some of the time, Yorkshire otherwise) - when is IETF London? On Mon, Feb 19, 2018 at 1:51 AM, Martin Thomson wrote: > Sounds like a good idea to me. As long as it is at a real bar and not > one of these "bar bofs" we seem to see more of lately. > > On Mon, Feb 19, 2018 at 9:09 AM, Mark Nottingham wrote: > > Hi, > > > > A couple of WHATWG folks are coming to IETF London. Would folks be > interested in a Bar BoF on Sunday night to chat with them? > > > > Some things that we could discuss include: > > > > - URL: https://url.spec.whatwg.org > > - MIME sniffing: https://mimesniff.spec.whatwg.org > > - Fetch: https://fetch.spec.whatwg.org > > - Infrastructure: https://infra.spec.whatwg.org > > - Their new governance model: https://blog.whatwg.org/ > working-mode-changes > > > > Who'd be interested? > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > _______________________________________________ > > art mailing list > > art@ietf.org > > https://www.ietf.org/mailman/listinfo/art > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --f4f5e80786286fe3660565cd5a11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm potentially interested (I am in London some of the= time, Yorkshire otherwise) - when is IETF London?

On Mon, Feb 19, 2018 at 1:51 AM, Mar= tin Thomson <martin.thomson@gmail.com> wrote:
Sounds like a good idea to me.=C2=A0 As long as = it is at a real bar and not
one of these "bar bofs" we seem to see more of lately.

On Mon, Feb 19, 2018 at 9:09 AM, Mark Nottingham <mnot@mnot.net> wrote:
> Hi,
>
> A couple of WHATWG folks are coming to IETF London. Would folks be int= erested in a Bar BoF on Sunday night to chat with them?
>
> Some things that we could discuss include:
>
> - URL: https://url.spec.whatwg.org
> - MIME sniffing: https://mimesniff.spec.whatwg.org > - Fetch: https://fetch.spec.whatwg.org
> - Infrastructure: https://infra.spec.whatwg.org
> - Their new governance model: https://blog.whatwg.o= rg/working-mode-changes
>
> Who'd be interested?
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art

_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art

--f4f5e80786286fe3660565cd5a11-- From nobody Thu Feb 22 06:41:15 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA731270A3 for ; Thu, 22 Feb 2018 06:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 y9wCJOyL-Lif for ; Thu, 22 Feb 2018 06:41:11 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA7A126D05 for ; Thu, 22 Feb 2018 06:41:11 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id 123so1396065oig.5 for ; Thu, 22 Feb 2018 06:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HkVdLyA44ZhD8JTAyrIRqYIlaGJArfTQCaqv65AkuY0=; b=ltyo4k4rDWkpFFEh9Kmo1qKJn7V1k8ytQpVY1OJeCa5YWO8ydIvbU2JHSxxJg+dYXJ 6PEtH5MWmmTTz3Bc6BJNsGOXISE2Tbqe1inpueYG3XSkXiRWP0cNyd1ju0GMg78tnCz9 zD8kNoTQumfyxlwX/Enp/HrHxw4vaukTKLb67WoJxtTxgNa4kU8xd2QYN4Dt3kw/lvoC xQzDhRr7dDeOjNBOQY155dvEVQlnJfDLj7pYUJllkDgT7oXtdMdhxv3C32cD4Prm/440 l8L1B3nC4U2NySQQsZACDMwnE51H2OXQ+5wwknY5YJKEAQPm6E7nj7UGtfKR+xgi27/w N0JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HkVdLyA44ZhD8JTAyrIRqYIlaGJArfTQCaqv65AkuY0=; b=NOKgK44xifultvqE/U/00dx5Yi8rQOycUghPwW6EonDc+HGpX23i3MBkJ38EU/NYzF DUWFQyconvChjHtDv4hkiu4UOGKL2lNvDVsUjEtiSmqqgI9BGo7Fzp91SAeXt0ztMtWC +4HleeSsDksXkb64zTei9rcCMPfZkquxibO0WV/j2x3IYo1SzGUD1WC+j3ZTAkHI90XA 9J2KwhNRipM+m4ouD2mxT8qVt6JjTEVmsYKINwkgAjn43eSPQe8np6M7urckSp7uDpw6 FCPjnlmB+65MBo+HeKansLeB5byYV4kf/1ffxzBEH7vzHbp45mxc+BhhBIZsQlf+nkO0 c0jg== X-Gm-Message-State: APf1xPAU5szMYZripri6VW4xnfxmV+OGiuZHkCNJxzJRZlqNXu7BlVrN 4YLq2xmuFIwiq5h+CU+0YevpuJVhRzwu9k74CY969w== X-Google-Smtp-Source: AG47ELu46zW1MSbP+G1j0LsjextIYsO8P9o5a9UEPQM1B28nIFw9OnGGtCQANXzjJ5wtkiENXm7xgz3vlbpFDq22Elc= X-Received: by 10.202.235.12 with SMTP id j12mr4592225oih.284.1519310470699; Thu, 22 Feb 2018 06:41:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.3.71 with HTTP; Thu, 22 Feb 2018 06:40:40 -0800 (PST) In-Reply-To: References: <143D15D4-63BA-4EC1-91E1-2E1C88950BBC@mnot.net> From: Ted Hardie Date: Thu, 22 Feb 2018 06:40:40 -0800 Message-ID: To: Kevin Marks Cc: Martin Thomson , Applications and Real-Time Area Discussion , Mark Nottingham Content-Type: multipart/alternative; boundary="001a113cc70ce8e1320565ce08c3" Archived-At: Subject: Re: [art] WHATWG Bar BoF? X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 14:41:13 -0000 --001a113cc70ce8e1320565ce08c3 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 22, 2018 at 5:52 AM, Kevin Marks wrote: > I'm potentially interested (I am in London some of the time, Yorkshire > otherwise) - when is IETF London? > > March 17-23; see https://www.ietf.org/how/meetings/101/ for other details. regards, Ted > On Mon, Feb 19, 2018 at 1:51 AM, Martin Thomson > wrote: > >> Sounds like a good idea to me. As long as it is at a real bar and not >> one of these "bar bofs" we seem to see more of lately. >> >> On Mon, Feb 19, 2018 at 9:09 AM, Mark Nottingham wrote: >> > Hi, >> > >> > A couple of WHATWG folks are coming to IETF London. Would folks be >> interested in a Bar BoF on Sunday night to chat with them? >> > >> > Some things that we could discuss include: >> > >> > - URL: https://url.spec.whatwg.org >> > - MIME sniffing: https://mimesniff.spec.whatwg.org >> > - Fetch: https://fetch.spec.whatwg.org >> > - Infrastructure: https://infra.spec.whatwg.org >> > - Their new governance model: https://blog.whatwg.org/workin >> g-mode-changes >> > >> > Who'd be interested? >> > >> > -- >> > Mark Nottingham https://www.mnot.net/ >> > >> > _______________________________________________ >> > art mailing list >> > art@ietf.org >> > https://www.ietf.org/mailman/listinfo/art >> >> _______________________________________________ >> art mailing list >> art@ietf.org >> https://www.ietf.org/mailman/listinfo/art >> > > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > > --001a113cc70ce8e1320565ce08c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb 22, 2018 at 5:52 AM, Kevin Marks <kevinmar= ks@gmail.com> wrote:
I'm potentially interested (I am in London some of the time, Y= orkshire otherwise) - when is IETF London?

<= /blockquote>

March 17-23; see=C2=A0 https://www.ietf.org/how/meetings/101/ f= or other details.

regards,

Ted

=C2=A0
On Mon, Feb 19, 2018 at 1:51 AM, Martin Thomson= <martin.thomson@gmail.com> wrote:
Sounds like a good idea to me.=C2=A0 A= s long as it is at a real bar and not
one of these "bar bofs" we seem to see more of lately.

On Mon, Feb 19, 2018 at 9:09 AM, Mark Nottingham <mnot@mnot.net> wrote:
> Hi,
>
> A couple of WHATWG folks are coming to IETF London. Would folks be int= erested in a Bar BoF on Sunday night to chat with them?
>
> Some things that we could discuss include:
>
> - URL: https://url.spec.whatwg.org
> - MIME sniffing: https://mimesniff.spec.whatwg.org > - Fetch: https://fetch.spec.whatwg.org
> - Infrastructure: https://infra.spec.whatwg.org
> - Their new governance model: https://blog.whatwg.o= rg/working-mode-changes
>
> Who'd be interested?
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art

_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art


_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art


--001a113cc70ce8e1320565ce08c3-- From nobody Sun Feb 25 21:49:35 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D4D126C0F for ; Sun, 25 Feb 2018 21:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=JVHipDmN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hZBVyJY9 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 OMwQPEsHZElt for ; Sun, 25 Feb 2018 21:49:31 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3B7126BF7 for ; Sun, 25 Feb 2018 21:49:31 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9DD59209AE for ; Mon, 26 Feb 2018 00:49:30 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 26 Feb 2018 00:49:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=mH/wzTaSSmJU2fdDSDd5x5kiN9wBE C42bthHqGXCkIw=; b=JVHipDmNrSv19d3M4bZwZvToq4fAfw7Nicbbty5DRrZX4 3pYq6xw9leE7eMTkbDp9rnaKLrz7xF072OP6Eljc0OW5pIReGO+k1NiKrkAfj6fq sPZYsRLNsASLr5SaBo+Xk/oLpovbtb2iIrrRLypkImd8heKJmvdarmYkK03Qo2y9 l1jpwkbSkaG6KX+AjvC8mc4MBfYsjBWoyR+sEABTemDnE/PuMkNbC3uJLxnE640B dHAYNixjrpzcvz3y08txuvq+cNhOsJPF6JdAoBvS/mr6nAyE0veeRFJtgNi+KOK7 7v9C92H6kp+juc+O3N1FuJuLEuIjDpI5Ta5XdDmWQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=mH/wzT aSSmJU2fdDSDd5x5kiN9wBEC42bthHqGXCkIw=; b=hZBVyJY9seYP29xIH8urvx OmFGk85lizXI3WyuaDgrV5q7xzQx5eHd6AaOCH7hRMUZPe56st5jpqHcvVYvvuel wgOuCj/SQ2IwW+e/czl3KvR8A3eU/NblTchq0BJ4e1X/SaIhBLjGCEhC7/xA2mF0 jqXl/fkcZ1J7cqZ4Vn4zjS+rIK12cYbI1EdddgwEPiswkDqqLYFo7w1bjpWb7NZY U6B7/Q/CrPhUBmIpHjZZC1sxL+3wYBUbB8P4qyRSu2/M5a1MEv27QdYe4ed4mKLR H5ExG6SlESmV6CCvp440f+zxyhf6wHpw/7Jc0wkDvu+7HqFwak1SX6I1JQbjvEKA == X-ME-Sender: Received: from attitudadjuster.tokyo.fastly.lan (122x208x204x58.ap122.ftth.ucom.ne.jp [122.208.204.58]) by mail.messagingengine.com (Postfix) with ESMTPA id DF8C57E1D8 for ; Mon, 26 Feb 2018 00:49:29 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 26 Feb 2018 14:49:27 +0900 References: <143D15D4-63BA-4EC1-91E1-2E1C88950BBC@mnot.net> To: Applications and Real-Time Area Discussion In-Reply-To: <143D15D4-63BA-4EC1-91E1-2E1C88950BBC@mnot.net> Message-Id: <200683E6-F920-47D6-ADEB-97ACAB5EC028@mnot.net> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [art] WHATWG Bar BoF! X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 05:49:34 -0000 OK, I've booked the IAB room from 7-8p, and we can migrate to an actual = pub afterwards (or earlier if the need strikes) to continue discussions. Cheers, > On 19 Feb 2018, at 7:09 am, Mark Nottingham wrote: >=20 > Hi, >=20 > A couple of WHATWG folks are coming to IETF London. Would folks be = interested in a Bar BoF on Sunday night to chat with them? >=20 > Some things that we could discuss include: >=20 > - URL: https://url.spec.whatwg.org > - MIME sniffing: https://mimesniff.spec.whatwg.org > - Fetch: https://fetch.spec.whatwg.org > - Infrastructure: https://infra.spec.whatwg.org > - Their new governance model: = https://blog.whatwg.org/working-mode-changes >=20 > Who'd be interested? >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art -- Mark Nottingham https://www.mnot.net/ From nobody Mon Feb 26 08:19:09 2018 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F20912D7F4 for ; Mon, 26 Feb 2018 08:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 P52IaPXAXOBD for ; Mon, 26 Feb 2018 08:18:59 -0800 (PST) Received: from qproxy6-pub.mail.unifiedlayer.com (qproxy6-pub.mail.unifiedlayer.com [69.89.23.12]) (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 B8299124217 for ; Mon, 26 Feb 2018 08:18:58 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by qproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 5CFC01410F6 for ; Mon, 26 Feb 2018 09:18:58 -0700 (MST) Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id FUJu1x00q2UhLwi01UJxoJ; Mon, 26 Feb 2018 09:18:58 -0700 X-Authority-Analysis: v=2.2 cv=M5g9E24s c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=IkcTkHD0fZMA:10 a=Op4juWPpsa0A:10 a=wvn1p7I7AAAA:8 a=ekYV4lpRAAAA:8 a=RGmq9QHJebb0ILhwGIoA:9 a=QEXdDO2ut3YA:10 a=rQQfR2Jt2InWGHXpCHHi:22 a=mrCxpU6zTNQDHnudu_9Q:22 Received: from [173.224.162.69] (port=48029 helo=[10.225.85.45]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eqLUM-0009Nv-L4 for art@ietf.org; Mon, 26 Feb 2018 09:18:54 -0700 To: Applications and Real-Time Area Discussion From: =JeffH Message-ID: <208478de-fe96-b159-6d69-22acfdd92fdd@KingsMountain.com> Date: Mon, 26 Feb 2018 08:18:52 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 173.224.162.69 X-Exim-ID: 1eqLUM-0009Nv-L4 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.85.45]) [173.224.162.69]:48029 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== X-Local-Domain: no Archived-At: Subject: Re: [art] WHATWG Bar BoF! X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 16:19:01 -0000 I'll join, thx for setting this up. =JeffH ### On 19 Feb 2018, at 7:09 am, Mark Nottingham wrote: Hi, A couple of WHATWG folks are coming to IETF London. Would folks be interested in a Bar BoF on Sunday night to chat with them? Some things that we could discuss include: - URL: https://url.spec.whatwg.org - MIME sniffing: https://mimesniff.spec.whatwg.org - Fetch: https://fetch.spec.whatwg.org - Infrastructure: https://infra.spec.whatwg.org - Their new governance model: https://blog.whatwg.org/working-mode-changes Who'd be interested?