From nobody Sun May 1 04:50:51 2016 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0E312D50E; Sun, 1 May 2016 04:50:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160501115046.14230.42722.idtracker@ietfa.amsl.com> Date: Sun, 01 May 2016 04:50:46 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-mdn-3798bis-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 11:50:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group of the IETF. Title : Message Disposition Notification Authors : Tony Hansen Alexey Melnikov Filename : draft-ietf-appsawg-mdn-3798bis-07.txt Pages : 33 Date : 2016-05-01 Abstract: This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-mdn-3798bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-mdn-3798bis-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 1 06:15:05 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEA412D0AB for ; Sun, 1 May 2016 06:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 xG849Oj02x3J for ; Sun, 1 May 2016 06:15:02 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731A01200A0 for ; Sun, 1 May 2016 06:15:02 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1awrDB-000FSc-3w for apps-discuss@ietf.org; Sun, 01 May 2016 09:15:01 -0400 Date: Sun, 01 May 2016 09:14:56 -0400 From: John C Klensin To: apps-discuss@ietf.org Message-ID: <9626E3570CB632119010C433@JcK-HP8200.jck.com> In-Reply-To: <20160501115046.14230.42722.idtracker@ietfa.amsl.com> References: <20160501115046.14230.42722.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mdn-3798bis-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 13:15:04 -0000 --On Sunday, May 01, 2016 04:50 -0700 internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the > ART Area General Applications Working Group of the IETF. > > Title : Message Disposition Notification > Authors : Tony Hansen > Alexey Melnikov > Filename : draft-ietf-appsawg-mdn-3798bis-07.txt > Pages : 33 > Date : 2016-05-01 > > Abstract: > This memo defines a MIME content-type that may be used by a > mail user agent (MUA) or electronic mail gateway to report > the disposition of a message after it has been successfully > delivered to a recipient. This content-type is intended to > be machine-processable. Additional message header fields > are also defined to permit Message Disposition > Notifications (MDNs) to be requested by the sender of a > message. The purpose is to extend Internet Mail to support > functionality often found in other messaging systems, such > as X.400 and the proprietary "LAN-based" systems, and often > referred to as "read receipts," "acknowledgements", or > "receipt notifications." The intention is to do this while > respecting privacy concerns, which have often been > expressed when such functions have been discussed in the past. > > Because many messages are sent between the Internet and > other messaging systems (such as X.400 or the proprietary > "LAN-based" systems), the MDN protocol is designed to be > useful in a multi- protocol messaging environment. To this > end, the protocol described in this memo provides for the > carriage of "foreign" addresses, in addition to those > normally used in Internet Mail. Additional attributes may > also be defined to support "tunneling" of foreign > notifications through Internet Mail. Two comments: (1) Editorial: A 20 or 21 line Abstract, even through it was copied from 3798, is obnoxious. In addition to violating historical RFC Editor rules, it violates the principles behind an abstract and may not even fit on a single screen of a smaller device. (2) Substantive: As the authors of this document well know, RFC 6533 is heavily (and normatively dependent) on RFC 3798. Its MDN format is defined as using fields from 3798 that this I-D alters to make more more restrictive. If the result of approving this document is to obsolete 3798, the status of 6533 becomes unclear. Even if one hand-waves around the formal status relationships, if the changes to fields that 6533 includes by reference are important enough to include in this I-D, then they should be applied to 6533. That does not seem acceptable either substantively or procedurally. I see two possible remedies and prefer the second: (2.1) Assuming that the changes in this I-D from 3798 do not actually add value to the understanding of 6533, modify this draft to update 6533 to reference this document instead, in the process substituting the updated definitions of assorted fields, obviously including the ua-* fields, removed fields, etc., discussed in Appendix A of the present I-D. (2.2) Use this document to replace and obsolete 6533 as well, creating a single, internationalized, MDN standard with appropriate restrictions on the contexts for the use of non-ASCII characters. It is now 18 years since RFC 2277 was published; especially given the IETF's increasingly international participation and focus, it is no longer seemly to publish Internet Standards that come in "ASCII-only" and "this is the i18n version of that" pairs (no matter what is done in developing those Standards with, e.g., Proposed Standard, documents). Unifying the two documents would also eliminate a good deal of the actual and potential confusion between ASCII-only and i18n notifications and would eliminate the need to navigate among documents that is necessary with 6533 but would become even more complex with the suggestion above (and worse yet, left to the reader's imagination if the I-D is unchanged). The obvious procedural objections to the second approach are that no one has done implementation reports on 6533 or, for that matter, on 6530, 6531, and 6532 (which 6533 normatively references). However, the dependency relationships between 6533 and this I-D (and 3798 for that matter) are such that, if 6533 is not sufficiently implemented to demonstrate that all of the pieces work together, then this document is not ready for prime time (specifically Internet Standard) and should wait unless it proposes to deprecate 6533 in favor of some other strategy. I'd like to see 6530-6532 brought to Internet Standard sometimes soon, but, if that is not feasible, it seems to me that references to them from 3798bis would be one of the better examples of why we now allow that by exception. There is, in principle, also an editorial process objection, which is that it would be highly desirable for the authors of 3798bis to collaborate actively with at least a majority of the authors of 6533. It does not appear to pose a serious problem in this case :-) best, john From nobody Thu May 5 07:33:13 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D8B12DB03 for ; Thu, 5 May 2016 07:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.997 X-Spam-Level: X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 dem3WWjknUYe for ; Thu, 5 May 2016 07:33:07 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id B4FB612DB19 for ; Thu, 5 May 2016 07:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1462458314; d=isode.com; s=selector; i=@isode.com; bh=9Z7JRvyxtu014qHbPlbWTh0kbP/oCJeCM1/uW0dTtPQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=vcIWTPnFg4HgMWwup5MxfkdMk7n4F7T1Z1uziuX5gqFYpzouwg/Q5n5iDms5Pp7yNG3da7 ddmzhaex/p8lcA/Asi5gvIJ9ZGOI3VFILiTFPgjyhozG0+e+jfV71El1eh4sN8ERHj2Ybf 4JSPMyz3erk9il4IZgYpmAT1UTYK5y0=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 5 May 2016 15:25:13 +0100 To: John C Klensin , apps-discuss@ietf.org References: <20160501115046.14230.42722.idtracker@ietfa.amsl.com> <9626E3570CB632119010C433@JcK-HP8200.jck.com> From: Alexey Melnikov Message-ID: <572B57B4.5000104@isode.com> Date: Thu, 5 May 2016 15:24:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 In-Reply-To: <9626E3570CB632119010C433@JcK-HP8200.jck.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mdn-3798bis-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 14:33:11 -0000 Hi John, On 01/05/2016 14:14, John C Klensin wrote: > --On Sunday, May 01, 2016 04:50 -0700 internet-drafts@ietf.org > wrote: > >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. This draft is a work item of the >> ART Area General Applications Working Group of the IETF. >> >> Title : Message Disposition Notification >> Authors : Tony Hansen >> Alexey Melnikov >> Filename : draft-ietf-appsawg-mdn-3798bis-07.txt >> Pages : 33 >> Date : 2016-05-01 >> >> Abstract: >> This memo defines a MIME content-type that may be used by a >> mail user agent (MUA) or electronic mail gateway to report >> the disposition of a message after it has been successfully >> delivered to a recipient. This content-type is intended to >> be machine-processable. Additional message header fields >> are also defined to permit Message Disposition >> Notifications (MDNs) to be requested by the sender of a >> message. The purpose is to extend Internet Mail to support >> functionality often found in other messaging systems, such >> as X.400 and the proprietary "LAN-based" systems, and often >> referred to as "read receipts," "acknowledgements", or >> "receipt notifications." The intention is to do this while >> respecting privacy concerns, which have often been >> expressed when such functions have been discussed in the past. >> >> Because many messages are sent between the Internet and >> other messaging systems (such as X.400 or the proprietary >> "LAN-based" systems), the MDN protocol is designed to be >> useful in a multi- protocol messaging environment. To this >> end, the protocol described in this memo provides for the >> carriage of "foreign" addresses, in addition to those >> normally used in Internet Mail. Additional attributes may >> also be defined to support "tunneling" of foreign >> notifications through Internet Mail. > Two comments: > > (1) Editorial: A 20 or 21 line Abstract, even through it was > copied from 3798, is obnoxious. In addition to violating > historical RFC Editor rules, it violates the principles behind > an abstract and may not even fit on a single screen of a smaller > device. I can work on shortening. Suggestions are welcome. > (2) Substantive: As the authors of this document well know, RFC > 6533 is heavily (and normatively dependent) on RFC 3798. Its > MDN format is defined as using fields from 3798 that this I-D > alters to make more more restrictive. If the result of > approving this document is to obsolete 3798, Yes. > the status of 6533 > becomes unclear. Even if one hand-waves around the formal > status relationships, if the changes to fields that 6533 > includes by reference are important enough to include in this > I-D, then they should be applied to 6533. That does not seem > acceptable either substantively or procedurally. I see two > possible remedies and prefer the second: > > (2.1) Assuming that the changes in this I-D from 3798 do not > actually add value to the understanding of 6533, modify this > draft to update 6533 to reference this document instead, in the > process substituting the updated definitions of assorted fields, > obviously including the ua-* fields, removed fields, etc., > discussed in Appendix A of the present I-D. > > (2.2) Use this document to replace and obsolete 6533 as well, > creating a single, internationalized, MDN standard with > appropriate restrictions on the contexts for the use of > non-ASCII characters. I think I prefer revising RFC 6533 as a separate draft. Firstly, 3798bis is intended to be Internet Standard and merging the documents will reset that, because as far as I know it is not deployed enough. Secondly, merging is quite a bit of work and I would rather get 3798bis be done now, before I get more involved in IESG :-). I can help with 6553bis, but I would rather somebody new and eager steps up and drives the process. I can also entertain your option 2.1, but I need to investigate what exactly needs to change in RFC 6553, before forming my opinion. But again, this might reset 3798bis back to Proposed Standard. > It is now 18 years since RFC 2277 was > published; especially given the IETF's increasingly > international participation and focus, it is no longer seemly to > publish Internet Standards that come in "ASCII-only" and "this > is the i18n version of that" pairs (no matter what is done in > developing those Standards with, e.g., Proposed Standard, > documents). Unifying the two documents would also eliminate a > good deal of the actual and potential confusion between > ASCII-only and i18n notifications and would eliminate the need > to navigate among documents that is necessary with 6533 but > would become even more complex with the suggestion above (and > worse yet, left to the reader's imagination if the I-D is > unchanged). > > The obvious procedural objections to the second approach are > that no one has done implementation reports on 6533 or, for that > matter, on 6530, 6531, and 6532 (which 6533 normatively > references). However, the dependency relationships between 6533 > and this I-D (and 3798 for that matter) are such that, if 6533 > is not sufficiently implemented to demonstrate that all of the > pieces work together, then this document is not ready for prime > time (specifically Internet Standard) and should wait unless it > proposes to deprecate 6533 in favor of some other strategy. I am not sure this follows! > I'd > like to see 6530-6532 brought to Internet Standard sometimes > soon, but, if that is not feasible, it seems to me that > references to them from 3798bis would be one of the better > examples of why we now allow that by exception. > > There is, in principle, also an editorial process objection, > which is that it would be highly desirable for the authors of > 3798bis to collaborate actively with at least a majority of the > authors of 6533. It does not appear to pose a serious problem > in this case :-) Indeed :-). Best Regards, Alexey From nobody Sat May 7 00:54:10 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E7112D0E2; Sat, 7 May 2016 00:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 xFCshKsJHBey; Sat, 7 May 2016 00:54:06 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 8F49912B065; Sat, 7 May 2016 00:54:06 -0700 (PDT) Received: by mail-ig0-x22b.google.com with SMTP id u10so65499141igr.1; Sat, 07 May 2016 00:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=AWD66+3NWp5LwhJDUokXabHMR2ZjbXQwEqympPQcMiY=; b=OQv/o8y1mfdDiLXyKNT5aIXvmhhDM+W0JNMqGtZvnMgNtmsaSwjd0qpsoeZMv6MKxh bpOLWfeoIDLKdGFW2U4HxmOqCN4aF87VPZLpujdKg1BofSBN7zadNFDKhhozu6eCzjKl 0xwmglXhm1f5u8bbQtQnT/mrjVfcB6i614RxLfS+kW5Iwz9U/9HGiyDBKYt2YWDKfZys 5STtF1VvJHZBZqbDdWJJrRo2joxx+XOHVHvwVeb/P7CKtBhuGC2txq/9Ch2fF1l1clhQ wBp7En4cDsbQJ0noqr/6ciFB2I15yATBmQEozXHm7Cs9Ti0Pe2+SCJusb5DHeLb922wG Wbrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=AWD66+3NWp5LwhJDUokXabHMR2ZjbXQwEqympPQcMiY=; b=Gm5bBWRUZFiGU/+jAll2OqoTLib36ZcFzzRYShSfFBdQh67IKOGsKLppPlQgWciDP3 ZhkZsKVveb97hSh+WNTwZhYgtCWGLwczd/DRgqBl+j10pu4JzZiiHvUKRE1ttGW2jaT6 kON0FrIwxwfpuM/zdWcoAVw2UwidMWVPWRt1FphjqwuAqdSIJkN/NnXwwUTyVPYUecCy tXQVmYv4FW9BKZFT2vn+6vGGilf8w/Pln4ngnxm5DBpsYe4yL06kZy1CJJs6VMT08n2N baTAGtmdyPQvXJjhUfY31488kI+dAXYhFZSOB4OZK7zZkASQtPmTzy9ycbn70hgNtXGK XZxQ== X-Gm-Message-State: AOPr4FU1njjskctlWABDY3SXRcdaLkq+Uj4yu2gJOH30jlww7OkJjbZS5hYxmugRR2I4VucxZu3hWpwQGoviSA== MIME-Version: 1.0 X-Received: by 10.50.29.39 with SMTP id g7mr1034742igh.50.1462607645991; Sat, 07 May 2016 00:54:05 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.138.230 with HTTP; Sat, 7 May 2016 00:54:05 -0700 (PDT) Received: by 10.107.138.230 with HTTP; Sat, 7 May 2016 00:54:05 -0700 (PDT) In-Reply-To: <5710953E.5040505@gmx.de> References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> <5710953E.5040505@gmx.de> Date: Sat, 7 May 2016 17:54:05 +1000 X-Google-Sender-Auth: XQ37J1jZuCWGZGywSRxpRwu0-zQ Message-ID: From: Matthew Kerwin To: Julian Reschke Content-Type: multipart/alternative; boundary=047d7bd758cc2f68a905323be1e6 Archived-At: Cc: IETF Apps Discuss , draft-ietf-appsawg-file-scheme@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 07:54:09 -0000 --047d7bd758cc2f68a905323be1e6 Content-Type: text/plain; charset=UTF-8 Hi again everyone, sorry for the dead air. I've been trying to work on these last open comments but am not really sure how tp address them. On 15/04/2016 5:17 PM, "Julian Reschke" wrote: > > On 2016-04-15 09:10, Matthew Kerwin wrote: >> >> >> Regarding security considerations, I've added some tentative hand-waving: >> >> "" >> Some file systems have case-sensitive file naming and some do not. >> Care must (?) be taken to avoid issues resulting from possibly >> unexpected aliasing from case-only differences between file paths or >> URIs. >> "" >> >> I'm open to suggestions for improvement (or deletion.) > > > case-insensitive (DOS?) < case-preserving (NTFS) < case-sensitive (others) > > ...so maybe mention all the three cases. > A case-based typo in a case-sensitive system gives an unwanted 404; an intentional difference in a case-insensitive system gives an unwanted 200. Case preservation doesn't really add anything to the issue, does it? > Best regards, Julian > > PS: it might also be good to touch Unicode normalization forms... > How's this? "" Care must be taken to avoid issues resulting from aliasing from mismatched encodings or Unicode equivalences. "" Cheers --047d7bd758cc2f68a905323be1e6 Content-Type: text/html; charset=UTF-8

Hi again everyone, sorry for the dead air. I've been trying to work on these last open comments but am not really sure how tp address them.

On 15/04/2016 5:17 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote:
>
> On 2016-04-15 09:10, Matthew Kerwin wrote:
>>
>>
>> Regarding security considerations, I've added some tentative hand-waving:
>>
>> ""
>> Some file systems have case-sensitive file naming and some do not.
>> Care must (?) be taken to avoid issues resulting from possibly
>> unexpected aliasing from case-only differences between file paths or
>> URIs.
>> ""
>>
>> I'm open to suggestions for improvement (or deletion.)
>
>
> case-insensitive (DOS?) < case-preserving (NTFS) < case-sensitive (others)
>
> ...so maybe mention all the three cases.
>

A case-based typo in a case-sensitive system gives an unwanted 404; an intentional difference in a case-insensitive system gives an unwanted 200. Case preservation doesn't really add anything to the issue, does it?

> Best regards, Julian
>
> PS: it might also be good to touch Unicode normalization forms...
>

How's this?

""
Care must be taken to avoid issues resulting from aliasing from mismatched encodings or Unicode equivalences.
""

Cheers

--047d7bd758cc2f68a905323be1e6-- From nobody Sat May 7 02:32:38 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE5512D0D3; Sat, 7 May 2016 02:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 S4jWv9GHnemP; Sat, 7 May 2016 02:32:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54285127058; Sat, 7 May 2016 02:32:35 -0700 (PDT) Received: from [192.168.178.20] ([93.217.64.107]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MBWo2-1apaeH0P7G-00AVLC; Sat, 07 May 2016 11:31:43 +0200 To: Matthew Kerwin References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> <5710953E.5040505@gmx.de> From: Julian Reschke Message-ID: Date: Sat, 7 May 2016 11:31:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:K3dEMYkQU5dOUS6EVdXWjcvrCSvN5R5Bckpxd2guma5yF56Nzf8 c1TQrXO2ftqP133sKl4EiEmJXF3NKdwNqkqVfbv4Y1MtS2eClmo6zTPvP2/qmeOzhCOrwYl wWrRatSokn9zJtLPgdX4jNtlf7EPOTGSmIgyjba4AUUDrqOpvtRGOMyXePfKhdHpkSHX/lX usz75NeY+Nzvvw6VU6iug== X-UI-Out-Filterresults: notjunk:1;V01:K0:AKBnBr6dh1I=:8lanrTHuI6aYwnMaLUmdIq QYIkEy54HKo6uYQZry7NfSlu1AOXkOWLZWpHiSvHWerm8wp+fhkpvu0DvmFGYw1Kvu+fqjgsq oEGCRyjeYMULYHTjm74nW+UctagrnpdYSGJQ296WNpDhJt99bAdjrUqueYVZe42CUSvjg5gTJ X/FjJIHfXiSxUKIVHoh67pPovsUlkaxw3rqRgvLYXvU9TXT5QTdhxQLKDXnqGl0duZOnpcrJC HPimNn/OUBOYvMUEY0WMXz8PsJF9gUH5Zf3+sg0aJPzqNesB6zDmftJ3D7SFU0RU/3oHPaXtv TCJDHhRKtYoUr0kC4fNPbXAtCHP9020TfGaOLni0LRi2T3Fwf/z4/LXNlFAVSK0INtF42P42w Xnjh7OH9NXpPTTCrurF3RwjFGNOsTbmsdgmhV9W8niDtCxtIXYf54O3Y9VQWxFZBlwCPQLfai +XgINn8hrx1xk0CpFmW1cW9Ojf2KcufrmRwduDOpkCWrqo0f+VRzjHaIvqeJfgEFJ7fx0CHaj N75tErKw4CSIg0RuUBk7in78IrGPlhZNl3Uz4ztmJni1fKyaX7l0GQlz+j+AANDTvnUiXe6Pa 9pGpqVtBa89ehyLV2VCSl1HEhLbTp5gVcMdgioRB2yD3FbeZ8rXv+vUW3EsfiqAEu7kpkQt7p 8KIBt2rZPCI6RLTzpio+gAFQaADohssjrP+xm/lw98zNUVDn8DMLAtX9MTBzoxDbcPNlYH5QG 4fFUkxeEKCjqfkaCkMSEJB0JotDlSiiRytI2DhL6oWHT41R5KFE6vDqjxzwaZnSYArEQEr8dr aNtHk8v Archived-At: Cc: IETF Apps Discuss , draft-ietf-appsawg-file-scheme@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 09:32:37 -0000 On 2016-05-07 09:54, Matthew Kerwin wrote: > Hi again everyone, sorry for the dead air. I've been trying to work on > these last open comments but am not really sure how tp address them. > > On 15/04/2016 5:17 PM, "Julian Reschke" > wrote: >> >> On 2016-04-15 09:10, Matthew Kerwin wrote: >>> >>> >>> Regarding security considerations, I've added some tentative hand-waving: >>> >>> "" >>> Some file systems have case-sensitive file naming and some do not. >>> Care must (?) be taken to avoid issues resulting from possibly >>> unexpected aliasing from case-only differences between file paths or >>> URIs. >>> "" >>> >>> I'm open to suggestions for improvement (or deletion.) >> >> >> case-insensitive (DOS?) < case-preserving (NTFS) < case-sensitive (others) >> >> ...so maybe mention all the three cases. >> > > A case-based typo in a case-sensitive system gives an unwanted 404; an > intentional difference in a case-insensitive system gives an unwanted > 200. Case preservation doesn't really add anything to the issue, does it? That's true, but maybe we can rephrase it in a way that it doesn't seem to neglect this case? "" File systems vary in the way they handle case. "" >> Best regards, Julian >> >> PS: it might also be good to touch Unicode normalization forms... >> > > How's this? > > "" > Care must be taken to avoid issues resulting from aliasing from > mismatched encodings or Unicode equivalences. > "" That can't hurt. I wonder whether we can say something useful about how to map Unicode code points into the file URI (that is, before percent-encoding the UTF-8 octets). Is it a good idea to apply unicode normalization at this step? (I don't know but maybe others do?) Best regards, Julian From nobody Sat May 7 03:03:25 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF6812D533; Sat, 7 May 2016 03:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 Wym2IaPOa1wy; Sat, 7 May 2016 03:03:20 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 5A96912D168; Sat, 7 May 2016 03:03:20 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id 190so135513703iow.1; Sat, 07 May 2016 03:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=o8AlKeQgAcQ6dR7QjJS31tV8MK4DEHf/Dt5dZBowEIU=; b=s+7a2q5lUhW3m+zge+EMphsDC/Xo/xNq6/sqI7RLgcotv68paQm3k3d42CtCxsvER5 SpvvMr0incLfB2Wh64EnR4NrESTQx1kY8NNfVja1P/7h70AFypEgzUVxwSLqHKKmXkle Tn8/SjEUQU+KpswJn3H6Bnu6cB/WDGCu/UQu/Y3DqSS7Py1lhR3/3lezmsQSCtrJecgl iD3clVUNptzys2aW4x5VTUf/wZP121OW1JxHQj7wYF8+D/GT/JzUguwgNjIcUEQASTCg 40jj0lg+WrniMmzb1K8RsdwXcRbppcv4i9neKqWd7qmrakXmSHc4Y2/AJO2wLqIqmVS0 Ipvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=o8AlKeQgAcQ6dR7QjJS31tV8MK4DEHf/Dt5dZBowEIU=; b=Y0zwaZ1S7pGYVeWeQY3ldO54xbnIdBMOjja7jSUo0pRmZ7Y/NvsD/Q5VBE14gfXVfX mYDpNbpb7DXwVOQ8DUiBcgUbipluJyOZJXDyLDu/Xx/PaQAGBsuCvgf/0btOKijh21PK yMFq+iu0rp1tSHqywnhCWLH8A1DReOewrnn82Ur9bAJDABUvPCpCM1fAd5HqopfgYF47 Ue+S4Ob3r3f/JdaPnTPPA1JdahL4jrFoGprUgy4aPuAg0lr/UDVhhntGHrPKR4XxZPe9 Ve/5HD/7csysBbdcVmsiTjw/zU9mxrAKIdfR/vPLxicMubfb1aiUclUbtonlOKFYoy6z OQRA== X-Gm-Message-State: AOPr4FWYIGk6UBTXf8rs046EdC5nLOrRGCH8eyQH6HnEnE9nJl8O9R+v2EFmlemFl+OCdOXc5MPzX9KA6QmARQ== MIME-Version: 1.0 X-Received: by 10.107.147.7 with SMTP id v7mr28072621iod.3.1462615399723; Sat, 07 May 2016 03:03:19 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.138.230 with HTTP; Sat, 7 May 2016 03:03:19 -0700 (PDT) In-Reply-To: References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> <5710953E.5040505@gmx.de> Date: Sat, 7 May 2016 20:03:19 +1000 X-Google-Sender-Auth: wYev2jaNvjVdUswqdMkRigBcwaE Message-ID: From: Matthew Kerwin To: Julian Reschke Content-Type: multipart/alternative; boundary=94eb2c055f6857fbee05323dafd4 Archived-At: Cc: IETF Apps Discuss , draft-ietf-appsawg-file-scheme@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 10:03:23 -0000 --94eb2c055f6857fbee05323dafd4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7 May 2016 at 19:31, Julian Reschke wrote: > On 2016-05-07 09:54, Matthew Kerwin wrote: > >> Hi again everyone, sorry for the dead air. I've been trying to work on >> these last open comments but am not really sure how tp address them. >> >> On 15/04/2016 5:17 PM, "Julian Reschke" > > wrote: >> =E2=80=8B=E2=80=8B >> >> >>> case-insensitive (DOS?) < case-preserving (NTFS) < case-sensitive >>> (others) >>> >>> ...so maybe mention all the three cases. >>> >>> >> A case-based typo in a case-sensitive system gives an unwanted 404; an >> intentional difference in a case-insensitive system gives an unwanted >> 200. Case preservation doesn't really add anything to the issue, does it= ? >> > > That's true, but maybe we can rephrase it in a way that it doesn't seem t= o > neglect this case? > > "" > File systems vary in the way they handle case. > "" > That works nicely, thanks. > =E2=80=8B=E2=80=8B >>> >>> PS: it might also be good to touch Unicode normalization forms... >>> >>> >> How's this? >> >> "" >> Care must be taken to avoid issues resulting from aliasing from >> mismatched encodings or Unicode equivalences. >> "" >> > > That can't hurt. > > I wonder whether we can say something useful about how to map Unicode cod= e > points into the file URI (that is, before percent-encoding the UTF-8 > octets). Is it a good idea to apply unicode normalization at this step? (= I > don't know but maybe others do?) > > That's kind of what Section 4 (Encoding) does; though that's the part that Dave Crocker suggested I cut right back. In any case I am working on rewriting that section since it doesn't quite feel right, but the intention will remain the same -- use UCS + NFC + UTF-8 when possible. Best regards, Julian > > Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --94eb2c055f6857fbee05323dafd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 7 May 2016 at 19:31, Julian Reschke <julian.reschke@gmx.d= e> wrote:
On 2016-05-= 07 09:54, Matthew Kerwin wrote:
Hi again everyone, sorry for the dead air. I've been trying to work on<= br> these last open comments but am not really sure how tp address them.

On 15/04/2016 5:17 PM, "Julian Reschke" <julian.reschke@gmx.de
<= span> <mailto:julia= n.reschke@gmx.de>> wrote:
=E2=80=8B=E2=80= =8B


case-insensitive (DOS?) < case-preserving (NTFS) < case-sensitive (ot= hers)

...so maybe mention all the three cases.


A case-based typo in a case-sensitive system gives an unwanted 404; an
intentional difference in a case-insensitive system gives an unwanted
200. Case preservation doesn't really add anything to the issue, does i= t?

That's true, but maybe we can rephrase it in a way that it doesn't = seem to neglect this case?

""
File systems vary in the way they handle case.
""

That works= nicely, thanks.



=E2=80=8B=E2=80=8B

PS: it might also be good to touch Unicode normalization forms...


How's this?

""
Care must be taken to avoid issues resulting from aliasing from
mismatched encodings or Unicode equivalences.
""

 That can't hurt.

I wonder whether we can say something useful about how to map Unicode code = points into the file URI (that is, before percent-encoding the UTF-8 octets= ). Is it a good idea to apply unicode normalization at this step? (I don= 9;t know but maybe others do?)


That's kind of what Section 4= (Encoding) does; though that's the part that Dave Crocker suggested I = cut right back. In any case I=C2=A0am working on rewriting that section sin= ce it doesn't quite feel right, but the intention will remain the same = -- use UCS + NFC + UTF-8 when possible.

Best regards, Julian


Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/<= /a>
--94eb2c055f6857fbee05323dafd4-- From nobody Sun May 8 09:26:57 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDEC12D137; Sun, 8 May 2016 09:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 9L9faWYM0VqX; Sun, 8 May 2016 09:26:55 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B76612D120; Sun, 8 May 2016 09:26:55 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1azRXa-0001X3-4H; Sun, 08 May 2016 12:26:46 -0400 Date: Sun, 08 May 2016 12:26:41 -0400 From: John C Klensin To: Julian Reschke , Matthew Kerwin Message-ID: In-Reply-To: References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> <5710953E.5040505@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: draft-ietf-appsawg-file-scheme@ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 16:26:57 -0000 --On Saturday, May 07, 2016 11:31 +0200 Julian Reschke wrote: >> Care must be taken to avoid issues resulting from aliasing >> from mismatched encodings or Unicode equivalences. >> "" > > That can't hurt. > > I wonder whether we can say something useful about how to map > Unicode code points into the file URI (that is, before > percent-encoding the UTF-8 octets). Is it a good idea to apply > unicode normalization at this step? (I don't know but maybe > others do?) The developing conventional wisdom outside the IETF is to not bother (and run the risk of normalization losing information or causing other problems) but to save normalization for the actual point at which the URI or other identifier is interpreted. In the particular case of "file" that might be particularly important since some systems prefer different normalization forms and have different restrictions. Note that is not necessarily advice, just a report. john From nobody Tue May 10 03:19:52 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FF212D114; Tue, 10 May 2016 03:19:50 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 n5ypOyIL5ZDi; Tue, 10 May 2016 03:19:48 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0134.outbound.protection.outlook.com [104.47.126.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AEBA12D0F9; Tue, 10 May 2016 03:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MvxrQyq3ExsE3TM7jRxKTxXiONZ5dus1jd8+AY7glwk=; b=JkIoCalOhbY9shyFqFxwfi68b11ZfF6wPGMvIBoojkserN174eEaLANdoZ2pKgneA5/QdxmB4fEjMzPKn6Q1GV0ThCTgxO/GsatDYoThMhfPjzCUpvdgJHctXJICb4a1CKuMvI7ba5k/Ieh//oR2AGKfv/TF2zRMMtOY9ks0LE8= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS2PR01MB0916.jpnprd01.prod.outlook.com (10.167.178.22) with Microsoft SMTP Server (TLS) id 15.1.492.11; Tue, 10 May 2016 10:19:44 +0000 To: John C Klensin , Julian Reschke , Matthew Kerwin References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> <5710953E.5040505@gmx.de> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <6f2915b6-d36b-fbf6-f8a5-e35cf646faeb@it.aoyama.ac.jp> Date: Tue, 10 May 2016 19:19:43 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TYXPR01CA0035.jpnprd01.prod.outlook.com (10.168.40.45) To OS2PR01MB0916.jpnprd01.prod.outlook.com (10.167.178.22) X-MS-Office365-Filtering-Correlation-Id: 86374628-2957-4c75-b442-08d378bc9b5e X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0916; 2:b54vB2CH3wL+PrO1bag9Z+gTS4Edtas94fmIfR5j+C+s0Gc2Wc52PKTCJTpf8DIFEFnT3S0bNujmFvVAKHGvUCLbT3ft7eITLoI9AI4xZhY0JB6vAT+BSZNq/zur+QGRJbDMVIFYS9BP2YGtZh6jcvU1yGf6kqiGvwuBm2keK6imYePGR9frSQ2CB3ULL4Pq; 3:xr91sXkSGa+Fs9Iswcyj2FLIWri2hfbTGZ+O4tD6+VMH4DSKGdy5lJwjfR92Q8ckvgRaAVjSD8oixZLv1OsJGHSKvfrItcU0MPInCRHmMmJPKH9fSHDUBOjHt/NAuTcT X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0916; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0916; 25:OtYItmyB3oakr0aUJAuwNir26AcqxuU+aBDVgOEtPVGPoMbKQkhQAAfFaGPyM2gjI6IMGG00Q9EiNs6R1C9xNx92J7gx9BC1sq85/ZsVLpUNFSLzFEOcHT70zj0ejVJWENQpjEf7lJLBM4LZ5nwWtknXE0GsHUswhTv/6oqAn9KwCnZQXmySj+/IOYRMuqJsiXvK5Yvim6175EeLUBjAPQ6MAv2mSdwLpRltlLqbBKgTFJKTcHh3YjyjykyoxsNlFDtU6qNhth7vY+w6U8xhXDsZSKv1fEwb0oXoDGGyibS6RTCq3aAWL/EgIrEz//E7u+D+PWuxLL357gjKDuW/BgosTd1EPFLJUaKUCaigkULZPv32rLOQq0+JOA51bMy2yDDLccbvy4Q4tqmFnBZBPb36aQFjh3veTdaXt2ISzw2jCmfuK8JpsLEDsAmCMXAqwaE5AweAjk1hK4NbxmzTbTsTjsgbbIDemE18KtjIg2ysi4kJI+KOiCtQqndQj5fXmBolJ+6Em7f6fWq0UJwfgmRU7X8hKlCWLmFkASVdMbHEcKRk/EOPx8KgrapLZZlrPBCQtjtUg4nAwQ/nESOArhiogOyYMesPnHIEEOLm3cH0hP5uJL7NdHNT7ftP225KQa7OAhB25wQOCBVp8etc8XTFmixrOe6vlGjyibpJuvi6xHvsGs/o55tf912zlGu2B7ydYSBnXtpYpqfUKlVlcRhmuiEriRjn0F6vWgkUxBbEupGhN5otyVhah3sxNf5NzrCDKXW63HdBdRVXOzMeeGKRiLj9cG05Vc2xwGnLGEQc5SsfwUkOPTY5FB10UHsWToOfCLDyZfdQevMdZO1eu1z79p9/IBEJ9Lf2A15aL1o= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040130)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041072)(6043046); SRVR:OS2PR01MB0916; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0916; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0916; 4:sQ3MYQTCDtbl1IvmYvi6bw43Tb0AtBrGnc5gkZ00qFplOQSlKgwz9kXT+H3SGQTX5BtgXFzu7e/Ox+F2eYCc/lwD2TmdOx2OYzMURFF+yeTnDLBXI/NgAgrjVr1lQpFN6X9RMi10lhjQsqHG8ZWi/04N5TqX2viBoPA7qnEfkPMPBXcPLqlbZi9ooju/cdvgP5q5z8+ZnHsiyQTkeFLEbVmPJEKe31bgFbcRQqGhJKtYFnXlqL9USd8ksW+eed5XBGdNMC7rGz8Dobl7pd3BH+NB9/VIq3QxGRvoxuvsije9wSlt0yc9vqXH3aVI5lKieSmB9AKFVrkSuNqN3wh8Bl+SdYy/PjnZk9qWvEji8oH/GAVbRw0IhwzWIVVXsUzr+tf7vm0sOs5BURxta2P4I0+tyvej8nTpgpgqhDfAZ/M= X-Forefront-PRVS: 0938781D02 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(65956001)(31686004)(66066001)(47776003)(74482002)(42186005)(4326007)(230700001)(2950100001)(230783001)(189998001)(15975445007)(81166005)(5001770100001)(77096005)(23676002)(83506001)(2906002)(19580395003)(86362001)(19580405001)(92566002)(33646002)(76176999)(54356999)(64126003)(586003)(6116002)(5008740100001)(50466002)(50986999)(31696002)(65826006)(7059030)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0916; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwOTE2OzIzOmI1VEtwdXlTV25ydTF4U01ta3AzZUNTVys0?= =?utf-8?B?QmpGbzAxRFVuUUw3YUFJS0xxcFMzMERJRjhCYWxuZkxKOUpMcmd2OUUxQUhB?= =?utf-8?B?QWs2WXdqZEFPWWo4L1d3TnF2WmhEUXNKaGthR3FERGFpNTBsMVpsMlA4TjZY?= =?utf-8?B?azd2UTJ0QnVYZm9tamUyZ2lKZEFOY3ZNdlVEZVVuU3BPT3BuTXpUUDRzRUw2?= =?utf-8?B?RFJEYWhBOUFVTFFTWG14b0VrdG1qNEw3bGNMd2ladE5zbDJkY3NOcHdaSndz?= =?utf-8?B?S0lERndDQjJKYzVtZHNQS25nYnlyNGFvZHpwYXU1byt3NFluME5yRkZPekk4?= =?utf-8?B?K1hyZGUxdVg2anJsNGh5SmFBU2RDVUI2RWJERnVjK2tsOVlnMHg4Rm5mQ2xJ?= =?utf-8?B?bkNHNVFJa3ZqVVFSelZnWHNBZERtNys0NXloTEpMWDR6bHd5T3IvYXZqMHp2?= =?utf-8?B?dnk1dWx0dnhNbTJvMEpIK1B2SHo4WmlwYkxTeklHMmxkQ0hBdlhjZHlQVTd1?= =?utf-8?B?TU9JM0hqcHl3OWRMOUxOWm5pZVFLZjYvakxFWnNYWHFLU0pUT0JMeUIrOUdT?= =?utf-8?B?ajZTK010SXRTVHFCMUVvZjhTRVQ5OEVSZnpHUUkzcHFwaHg2TlJ1QzhaZWRN?= =?utf-8?B?bWNWWU9mekROM3ZyMGRrN0ppa2V6d1h2M1VSYlFmZ2xHSmlwNWlURUxKMGox?= =?utf-8?B?K2RYa1NvVlEzNnRsZ2s4SXV6Vmhva05sRmh6M3UvUUtGR1kybUhjdzl0Y1Y0?= =?utf-8?B?YWRRQ3BMZVdjK2xTMXEvamVjUmZwYlRidkNYc005UVA3aXZWUmUvcGhiN2Ft?= =?utf-8?B?UWtQSHh0S3ZzQ3NpaGdDbENjVmwveXVMWXlaVGxtV2t6dTlRdjAwZXUrTWR0?= =?utf-8?B?ZkRqYXFwUDUrMTd6YVcxVzBTa2p5amp3dmVsa2RnbE8zOWJ3Y2VUUndiU2E4?= =?utf-8?B?SXRENEsrRWROZEphTitRM3BPeFFEc0VpZjVaMzZ2emIxQlRXK0xidllrV0tK?= =?utf-8?B?MXRaUmF5Sm1XdjJNa1EvREFpcFBQbzZTaXo2UDErMTlnTDFkZFBweXA4YkR2?= =?utf-8?B?ZjF1eldxTEpuZlB3V0JzK05qcXRrTGh0QmhraHk0cUVOME1ncWRGWHBVdXBi?= =?utf-8?B?Y1B3U1V6bGNDVmd1THB6RmVaYlYxN2dRRll3NUkwT1ZDaWQ2Y2lhNUxnWURv?= =?utf-8?B?dTdRYUtiTllBTy8vNHVqU0dnc2hubWRCUFZyZ1ovTWRzK0dFaG9WMjNMUFFC?= =?utf-8?B?N0dVd0w4cnd3d2p4OGxJQXRLZDh2TUZpN3BFT1lhQlZBWjFpSXptQ2hzV3d5?= =?utf-8?B?TDNVKzBueTBZdEJvbDZJcGNoL2ZoSGRyZ2lYVWpxRUVxYUIvOXF6bXRPdE5n?= =?utf-8?B?d0dFT2lxb3o4THg3SEVBSHBqY09WOStqZ3Q4bTN3PT0=?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0916; 5:+ZFfBuaMV3buCCAucAQmMEvguYXG1+rFZ2XkgfZuVVteVN1CPQfqqPO/TthLN7KUac2d95BtdEmJxPqErr2KnA2UVS0jUtyZi7iUiutUV59vx9ciQTZG+iaNZ1b/UVH6SXx7MDLpGnMR3tJEWhd73w==; 24:Si/EPQlJSaF5nkZc58gghcH+wVbmEMGeCIB0tRmKnIfmR/TJHFR5FqLIY14YJpauhKpYmpUnTf78VqbaJUvuMnM2oHjU3GfK6udJSAxwuwI=; 7:ZG2WpN4VwYKB4QXmrpOc9B7c+qhg5IYaSQnVThCEkQOSczNHuShx5jzb9SmTxXBw/3rwN+gYzHQmBpijsxFw2UNvbJogqAnTTEiGMeslb+Y1pu7QxxZiEQCgHZXeSToSLmTyAV690hbkNSOMzHF79/KCZwLwRFMqeyElmfezU2M6OB45KhmsHtPBqBmhTdwP SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2016 10:19:44.3512 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0916 Archived-At: Cc: IETF Apps Discuss , draft-ietf-appsawg-file-scheme@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 10:19:51 -0000 On 2016/05/09 01:26, John C Klensin wrote: > > > --On Saturday, May 07, 2016 11:31 +0200 Julian Reschke > wrote: > >>> Care must be taken to avoid issues resulting from aliasing >>> from mismatched encodings or Unicode equivalences. >>> "" >> >> That can't hurt. >> >> I wonder whether we can say something useful about how to map >> Unicode code points into the file URI (that is, before >> percent-encoding the UTF-8 octets). Is it a good idea to apply >> unicode normalization at this step? (I don't know but maybe >> others do?) In general, NFC gives you a higher chance for a match that NFD. The Mac filesystem uses (mostly) NFD internally, but is able to handle NFC. On the other hand, Windows and Linux don't do normalization inside the file system, but the chances that files were created in NFC is higher than for NFC. But milage(s) may vary. Regards, Martin. > The developing conventional wisdom outside the IETF is to not > bother (and run the risk of normalization losing information or > causing other problems) but to save normalization for the actual > point at which the URI or other identifier is interpreted. In > the particular case of "file" that might be particularly > important since some systems prefer different normalization > forms and have different restrictions. > > Note that is not necessarily advice, just a report. > > john > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > . > From nobody Tue May 10 09:06:43 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A79812D500; Tue, 10 May 2016 09:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 xPAAnBIm8AlI; Tue, 10 May 2016 09:06:41 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C77C12B03F; Tue, 10 May 2016 09:06:41 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1b0AB7-000AtO-Od; Tue, 10 May 2016 12:06:33 -0400 Date: Tue, 10 May 2016 12:06:28 -0400 From: John C Klensin To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Julian Reschke , Matthew Kerwin Message-ID: <88F1BC9BE8337F5D3B95E1BA@JcK-HP8200.jck.com> In-Reply-To: <6f2915b6-d36b-fbf6-f8a5-e35cf646faeb@it.aoyama.ac.jp> References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> <5710953E.5040505@gmx.de> <6f2915b6-d36b-fbf6-f8a5-e35cf646faeb@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: IETF Apps Discuss , draft-ietf-appsawg-file-scheme@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 16:06:42 -0000 --On Tuesday, May 10, 2016 19:19 +0900 "Martin J. D=C3=BCrst" wrote: > In general, NFC gives you a higher chance for a match that > NFD. The Mac filesystem uses (mostly) NFD internally, but is > able to handle NFC. On the other hand, Windows and Linux don't > do normalization inside the file system, but the chances that > files were created in NFC is higher than for NFC. Agreed. But note that this is partially an artifact that illustrates why the i18n / "multilingual" versus localization issues are important. NFC gives a higher chance for a match, especially with strings that are not systematically normalized because, if one is using a keyboard designed for a particular language or location, that keyboard is likely to support locally-used characters and hence far more likely to product precomposed characters than combining sequences. The same is generally true when people select characters from some sort of online character-picker, assuming the precomposed forms exist at all. On the other hand, if I'm an experience user of one script trying to use a keyboard designed for a wildly different script or one with too many distinct character forms ("graphemes" or "grapheme clusters") to allow single-stroke arrangements to work well, all bets are off. For some scripts, there are also what look from the outside like internal consistency problems with Unicode: for example, NFD is more internally consistent then NDC because many recently-added precomposed characters decompose under NFC rather than composing. And some don't, leading to some of the problems that led to the "non-decomposable character" mess that led to the LUCID BOF and the IETF's apparent paralysis about Unicode 7.x. It is hard to say something in cases like this that will always deliver the best, or even the most-expected, results. john From nobody Wed May 11 07:39:38 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDF212DB11; Wed, 11 May 2016 07:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 UKxS2mto6nmQ; Wed, 11 May 2016 07:39:35 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 8CE5E12DB0C; Wed, 11 May 2016 07:39:34 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q01K050EI8012AMO@mauve.mrochek.com>; Wed, 11 May 2016 07:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1462977269; bh=dxWtqzfwo/wvKbGXex786X53C/8/JeH9SBQQ7HScohE=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=PKus+NiHQ6axY46Lq9E/IwPceJ+OBa0P0XdVvo3Hf7NFh77y7qFgU7K5AH9CBEQh3 3FnjKe2gh6jGwidQG8+TAutp3c7D1Qc4ouQZlj/3LaUeJ8VyLp6+0dOOgNFYCz9/SU s/TLPQxdVHZYT6KPSRoFylCIehlxmX6bnx0mMmeA= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PZOUC11L7400005M@mauve.mrochek.com>; Wed, 11 May 2016 07:34:27 -0700 (PDT) Message-id: <01Q01K03ULG000005M@mauve.mrochek.com> Date: Wed, 11 May 2016 07:27:54 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 10 May 2016 12:06:28 -0400" <88F1BC9BE8337F5D3B95E1BA@JcK-HP8200.jck.com> References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> <5710953E.5040505@gmx.de> <6f2915b6-d36b-fbf6-f8a5-e35cf646faeb@it.aoyama.ac.jp> <88F1BC9BE8337F5D3B95E1BA@JcK-HP8200.jck.com> To: John C Klensin Archived-At: Cc: Julian Reschke , draft-ietf-appsawg-file-scheme@ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 14:39:37 -0000 > --On Tuesday, May 10, 2016 19:19 +0900 "Martin J. Dürst" > wrote: > > In general, NFC gives you a higher chance for a match that > > NFD. The Mac filesystem uses (mostly) NFD internally, but is > > able to handle NFC. On the other hand, Windows and Linux don't > > do normalization inside the file system, but the chances that > > files were created in NFC is higher than for NFC. > Agreed. But note that this is partially an artifact that > illustrates why the i18n / "multilingual" versus localization > issues are important. NFC gives a higher chance for a match, > especially with strings that are not systematically normalized > because, if one is using a keyboard designed for a particular > language or location, that keyboard is likely to support > locally-used characters and hence far more likely to product > precomposed characters than combining sequences. The same is > generally true when people select characters from some sort of > online character-picker, assuming the precomposed forms exist at > all. On the other hand, if I'm an experience user of one > script trying to use a keyboard designed for a wildly different > script or one with too many distinct character forms > ("graphemes" or "grapheme clusters") to allow single-stroke > arrangements to work well, all bets are off. > For some scripts, there are also what look from the outside like > internal consistency problems with Unicode: for example, NFD is > more internally consistent then NDC because many recently-added > precomposed characters decompose under NFC rather than > composing. And some don't, leading to some of the problems that > led to the "non-decomposable character" mess that led to the > LUCID BOF and the IETF's apparent paralysis about Unicode 7.x. > It is hard to say something in cases like this that will always > deliver the best, or even the most-expected, results. I'm trying, but I find it difficult to have much sympathy here. The underlying problem is that repeated applications of the "this is a tiny bit better for this constituency so we must have it or at least allow for it" rule in this space has led to a situation where no single best practice exists. If this sounds like we've reached a distinctly suboptimal pareto optimum, it's because that's exactly what has happened. I therefore think the best thing is to document the situation as best we can and be done with it. This is supposed to be a specification for a URL scheme; there's no reqruiement that such documents also serve as a BCP. Ned From nobody Wed May 11 08:55:13 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B4C12D142 for ; Wed, 11 May 2016 08:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 4TdxQxoY2Yjs for ; Wed, 11 May 2016 08:55:10 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7E812B008 for ; Wed, 11 May 2016 08:55:09 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id u4BFt7ug018160; Wed, 11 May 2016 16:55:09 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id u4BFt6GF004119; Wed, 11 May 2016 16:55:06 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id u4BFt5dM012920; Wed, 11 May 2016 16:55:05 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u4BFt5E0012919; Wed, 11 May 2016 16:55:05 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: apps-discuss@ietf.org, "=?utf-8?Q?draft-name-without-version-num?= =?utf-8?Q?=E2=80=8B=2Eall?=@ietf.org cc": =?utf-8?Q?=E2=80=8Biesg?=@ietf.org From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 11 May 2016 16:55:05 +0100 Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: Subject: [apps-discuss] Appsdir review of XML schema in https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 15:55:13 -0000 Document: draft-ietf-clue-data-model-schema Title: An XML Schema for the CLUE data model Reviewer: Henry S. Thompson Review Date: 2016-05-11 IETF Last Call Date: 2016-05-23 ESG Telechat Date: 2016-06-02 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Summary: The XML Schema itself which is included in this draft is conformant to the XML Schema 1.0 spec, and is good to go, subject to a minor correction. There is a minor glitch in one of the XML examples, also easily corrected. Comments: I tested the XML Schema document included as section 4 and it passes as valid against the schema for schemas. The example document in section 17 is schema-valid according to the corresponding schema. See 'Nits' below for a minor problem with the example document in section 18. I briefly reviewed the schema document and it seems straightforward and fit for its intended purpose. Minor Issues: Section 4, lines 13--14: As this stands, it's not actually usable for validation purposes, because no xcard.xsd file is supplied. Furthermore, there is no Appendix A, which is alleged to provide it (see 11.29.1.2). I note further that the xCard RFC (6351) doesn't contain an XSD-format schema document either. The IANA XML Registry [1] schema entry for the urn:ietf:params:xml:ns:vcard-4.0 URN namespace _does_ however link to such a schema document [2]. I suggest you either a) Edit the draft so the above lines read (this is what I did to do the validity checks I did); or b) Delete the schemaLocation attribute and add a comment identifying possible sources of a schema document for the vcard-4.0 namespace, e.g. the above iana.org URI or the contents of Appendix A (if you fill it in). Nits: Section 18, the XML example has a (copy-paste?) error, which renders that example invalid against the schema. The line EG0 appears twice inside mediaCapture VC7, once on line 204 and once on line 237. The first occurrence should be deleted. [1] http://www.iana.org/assignments/xml-registry/xml-registry.xhtml#schema [2] http://www.iana.org/assignments/xml-registry/schema/vcard-4.0.xsd -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Wed May 11 08:58:15 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669D612B008; Wed, 11 May 2016 08:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 2Yu6T2a5YjFA; Wed, 11 May 2016 08:58:09 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 697CC12D142; Wed, 11 May 2016 08:58:01 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id u4BFw1DG019259; Wed, 11 May 2016 16:58:01 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id u4BFw0op004198; Wed, 11 May 2016 16:58:00 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id u4BFw0an013141; Wed, 11 May 2016 16:58:00 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u4BFw0Sc013140; Wed, 11 May 2016 16:58:00 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: apps-discuss@ietf.org, draft-ietf-clue-data-model-schema.all@ietf.org From: ht@inf.ed.ac.uk (Henry S. Thompson) User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) Date: Wed, 11 May 2016 16:58:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: Cc: iesg@ietf.org Subject: [apps-discuss] Appsdir review of XML schema in https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 15:58:11 -0000 [Argh, fumble-finger -- resending with correct address lines] Document: draft-ietf-clue-data-model-schema Title: An XML Schema for the CLUE data model Reviewer: Henry S. Thompson Review Date: 2016-05-11 IETF Last Call Date: 2016-05-23 ESG Telechat Date: 2016-06-02 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Summary: The XML Schema itself which is included in this draft is conformant to the XML Schema 1.0 spec, and is good to go, subject to a minor correction. There is a minor glitch in one of the XML examples, also easily corrected. Comments: I tested the XML Schema document included as section 4 and it passes as valid against the schema for schemas. The example document in section 17 is schema-valid according to the corresponding schema. See 'Nits' below for a minor problem with the example document in section 18. I briefly reviewed the schema document and it seems straightforward and fit for its intended purpose. Minor Issues: Section 4, lines 13--14: As this stands, it's not actually usable for validation purposes, because no xcard.xsd file is supplied. Furthermore, there is no Appendix A, which is alleged to provide it (see 11.29.1.2). I note further that the xCard RFC (6351) doesn't contain an XSD-format schema document either. The IANA XML Registry [1] schema entry for the urn:ietf:params:xml:ns:vcard-4.0 URN namespace _does_ however link to such a schema document [2]. I suggest you either a) Edit the draft so the above lines read (this is what I did to do the validity checks I did); or b) Delete the schemaLocation attribute and add a comment identifying possible sources of a schema document for the vcard-4.0 namespace, e.g. the above iana.org URI or the contents of Appendix A (if you fill it in). Nits: Section 18, the XML example has a (copy-paste?) error, which renders that example invalid against the schema. The line EG0 appears twice inside mediaCapture VC7, once on line 204 and once on line 237. The first occurrence should be deleted. [1] http://www.iana.org/assignments/xml-registry/xml-registry.xhtml#schema [2] http://www.iana.org/assignments/xml-registry/schema/vcard-4.0.xsd -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Wed May 11 11:35:52 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA19B12D738; Wed, 11 May 2016 11:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 CI8E2L5WBtRY; Wed, 11 May 2016 11:35:42 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77DCF12D513; Wed, 11 May 2016 11:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4659; q=dns/txt; s=iport; t=1462991742; x=1464201342; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=apO3JYwypaabvjtyoVXgTXldyjlECUPo+cdUbDg0ymA=; b=Y/sesWN7HGrYkvbHOlKDpSGZ29tD3mWp0IZN55ANvIr5ckFViH5iqVYW 73U6lub/BlerxP1hzUsOgAj037fxosumQdmY1qarM/uFzN7+z7fdTueET HiXArlIhqlMDqPKagOaVJ87aZlXTHOZyKmMHtVxulNd/UF0Nyb1i/Nz73 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrBACaejNX/xbLJq1eDoN/fbs0JIVwA?= =?us-ascii?q?oIJAQEBAQEBZieEQwEBBCNWEAsUBAkaBwICDwJGBgEMCAEBBYgmDgOpeZBpAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEOCIpshF+CYIJZBZgngymBaG2IIIFpToQBgwcjh?= =?us-ascii?q?TePQWKCBRsWej06MgEBh0wlgRcBAQE?= X-IronPort-AV: E=Sophos;i="5.24,608,1454976000"; d="asc'?scan'208";a="635599596" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 May 2016 18:35:39 +0000 Received: from [10.61.97.31] (dhcp-10-61-97-31.cisco.com [10.61.97.31]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u4BIZcM0032016; Wed, 11 May 2016 18:35:38 GMT To: "Henry S. Thompson" , apps-discuss@ietf.org, draft-ietf-clue-data-model-schema.all@ietf.org References: From: Eliot Lear Message-ID: <57337B7A.70501@cisco.com> Date: Wed, 11 May 2016 20:35:38 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mmShDGXIkDL1SKtsQJ7ow2eLERfxRicig" Archived-At: Cc: iesg@ietf.org Subject: Re: [apps-discuss] Appsdir review of XML schema in https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 18:35:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mmShDGXIkDL1SKtsQJ7ow2eLERfxRicig Content-Type: multipart/mixed; boundary="EtMBwhLMlDcdpftstJVWa3AgP0xRfUI9e" From: Eliot Lear To: "Henry S. Thompson" , apps-discuss@ietf.org, draft-ietf-clue-data-model-schema.all@ietf.org Cc: iesg@ietf.org Message-ID: <57337B7A.70501@cisco.com> Subject: Re: [apps-discuss] Appsdir review of XML schema in https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-14 References: In-Reply-To: --EtMBwhLMlDcdpftstJVWa3AgP0xRfUI9e Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you for doing this prompt review, Henry. Eliot On 5/11/16 5:58 PM, Henry S. Thompson wrote: > [Argh, fumble-finger -- resending with correct address lines] > > Document: draft-ietf-clue-data-model-schema > Title: An XML Schema for the CLUE data model > Reviewer: Henry S. Thompson > Review Date: 2016-05-11 > IETF Last Call Date: 2016-05-23 > ESG Telechat Date: 2016-06-02 > > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectora= te). > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Summary: The XML Schema itself which is included in this draft is > conformant to the XML Schema 1.0 spec, and is good to go, subject to a > minor correction. There is a minor glitch in one of the XML examples, > also easily corrected. > > Comments: > > I tested the XML Schema document included as section 4 and it passes as= > valid against the schema for schemas. The example document in section > 17 is schema-valid according to the corresponding schema. See 'Nits' > below for a minor problem with the example document in section 18. > > I briefly reviewed the schema document and it seems straightforward and= > fit for its intended purpose. > > Minor Issues: > > Section 4, lines 13--14: > > schemaLocation=3D"xcard.xsd"/> > > As this stands, it's not actually usable for validation purposes, > because no xcard.xsd file is supplied. Furthermore, there is no > Appendix A, which is alleged to provide it (see 11.29.1.2). > > I note further that the xCard RFC (6351) doesn't contain an XSD-format > schema document either. The IANA XML Registry [1] schema entry for the= > urn:ietf:params:xml:ns:vcard-4.0 URN namespace _does_ however link to > such a schema document [2]. I suggest you either > a) Edit the draft so the above lines read > > schemaLocation=3D"http://www.iana.org/assignments/xml-registry/schema/= vcard-4.0.xsd"/> > > (this is what I did to do the validity checks I did); > > or > > b) Delete the schemaLocation attribute and add a comment identifying > possible sources of a schema document for the vcard-4.0 namespace, > e.g. the above iana.org URI or the contents of Appendix A (if you > fill it in). > > Nits: > > Section 18, the XML example has a (copy-paste?) error, which renders > that example invalid against the schema. The line > > EG0 > > appears twice inside mediaCapture VC7, once on line 204 and once on lin= e > 237. The first occurrence should be deleted. > > [1] http://www.iana.org/assignments/xml-registry/xml-registry.xhtml#sch= ema > [2] http://www.iana.org/assignments/xml-registry/schema/vcard-4.0.xsd --EtMBwhLMlDcdpftstJVWa3AgP0xRfUI9e-- --mmShDGXIkDL1SKtsQJ7ow2eLERfxRicig Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXM3t6AAoJEIe2a0bZ0nozT20H/jOI38UdEdyZ+4s7O8RkdvGy rXIribH6Y3zE7RZj5PCEdG+aw/KC7/Fd9G+m4KX9sAO902jKLBrks43nRcUCgrIT 2kdVYu12SVUVsPGc0tX+MaBj+DNoczKWb4ed04M+UZrgrZFVs7Q6H9EwyPrWglm9 2DSiHEtthKcbvqSjOxW2pWI0ozuZxl6TnuRP2LPpqAnNXb+0WVNTPRsHEXL0pWGw 5vrHpA3ROCOLe4yYF0fUt86qbu3sdzNhbf6Ao6K7mCPVOIMOSN+N6hPoLSXGdXD/ dEymxdGrD89qgp2On8zLqSs13SI45Br4IhpoMjbGEBukYo7a1fM6CIX+0efValI= =KWr0 -----END PGP SIGNATURE----- --mmShDGXIkDL1SKtsQJ7ow2eLERfxRicig-- From nobody Wed May 11 13:36:24 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF7412D0A3; Wed, 11 May 2016 13:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 ZmzPW-Y6AZ9M; Wed, 11 May 2016 13:36:19 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3481212D773; Wed, 11 May 2016 13:36:14 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1b0arP-000HM7-Cx; Wed, 11 May 2016 16:35:59 -0400 Date: Wed, 11 May 2016 16:35:54 -0400 From: John C Klensin To: Ned Freed Message-ID: In-Reply-To: <01Q01K03ULG000005M@mauve.mrochek.com> References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> <5710953E.5040505@gmx.de> <6f2915b6-d36b-fbf6-f8a5-e35cf646faeb@it.aoyama.ac.jp> <88F1BC9BE8337F5D3B95E1BA@JcK-HP8200.jck.com> <01Q01K03ULG000005M@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Julian Reschke , draft-ietf-appsawg-file-scheme@ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 20:36:23 -0000 --On Wednesday, May 11, 2016 07:27 -0700 Ned Freed wrote: >... >> For some scripts, there are also what look from the outside >> like internal consistency problems with Unicode: for example, >> NFD is more internally consistent then NDC because many >> recently-added precomposed characters decompose under NFC >> rather than composing. And some don't, leading to some of >> the problems that led to the "non-decomposable character" >> mess that led to the LUCID BOF and the IETF's apparent >> paralysis about Unicode 7.x. > >> It is hard to say something in cases like this that will >> always deliver the best, or even the most-expected, results. > > I'm trying, but I find it difficult to have much sympathy > here. The underlying problem is that repeated applications of > the "this is a tiny bit better for this constituency so we > must have it or at least allow for it" rule in this space has > led to a situation where no single best practice exists. > > If this sounds like we've reached a distinctly suboptimal > pareto optimum, it's because that's exactly what has happened. > > I therefore think the best thing is to document the situation > as best we can and be done with it. This is supposed to be a > specification for a URL scheme; there's no reqruiement that > such documents also serve as a BCP. I hope it doesn't surprise you, but I agree. Less is probably more here, it is only the (IMO unnecessary) effort to be exhaustive without either getting it right to the best of our present knowledge or being clear that the guidance is general only that I'm concerned about. john From nobody Wed May 11 13:45:31 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253DA12B01E; Wed, 11 May 2016 13:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 2VNcAxfH5Gen; Wed, 11 May 2016 13:45:27 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001: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 012FC12D5F3; Wed, 11 May 2016 13:45:23 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id f89so70062296ioi.0; Wed, 11 May 2016 13:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=JzZwEHQ1R0+9Y1vAcf8cWyi7A2QTvFJrHwSqKa2iFew=; b=DN0p8SfsmMFjrM5+XJuGLoIUQAW+Lzt/0E3TzfunZ0kRHi8/736T9jpWg7Tl6DKzrc ZcOgN+VZj4n2dbdUjb9/zDZqzjN9ETyNS1SmfTX3tfzfF3zbDm7WgrjlT5J6l2fyPLod R/mj5Qp1DVLgqoJsEy5SxRtCenAobtiYuia7RAz6GfygYhWGhXJhy8fT6eZbNSbMQlNT l/ucr9CbGWO6rxGNeyxAhnYXTCukEh1gU/jtTttqcTabiKNtBBCg/qmGdnqSwY/1Z9MW I2tW784J+eXpUBf+NACBE5PX3Q27mG9xJ2CoPjGYI9CtJL/t0DYNXuGNpRYJxaREPx5J /Mzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=JzZwEHQ1R0+9Y1vAcf8cWyi7A2QTvFJrHwSqKa2iFew=; b=Nj3NylCfmuKqTT0Vq5wZZ+secSJeFUVFWpp343439lgY6M7tFKYK9DJv7jjqKVgdbe QtZhr4W9l3J0/K9I3y6fRB+CxcShGzPV3NKsQx/SYnb6hgAf4wHwemhGsGrEQgKF5Hry Qde7V/0qNeKxNIpKfrwelyoeNY0aYJx+dWMXlNleaxtafWJn4tZSgknaTijgTHXccHtB XdXsHqV3xJG+eDR9MO/Zzj+xZ76NSNg5AIFACeLZODvKwMFO17474T9Idym+HDAviMJg 6x1Yp3016hTGhat3X8uV8EXr6lTQrYwECm9Si9STQJDm17E2A2ICjmrElizIab/tclja d5lA== X-Gm-Message-State: AOPr4FV6I3791aNd1SjoaWEWXJAEHfa9ieWY8pWdH9VCmT6M8DGnFM3/LtlA5Q71r5v9tBfuDCQsZXL1eGGN4A== MIME-Version: 1.0 X-Received: by 10.107.147.7 with SMTP id v7mr4999979iod.3.1462999522402; Wed, 11 May 2016 13:45:22 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.138.230 with HTTP; Wed, 11 May 2016 13:45:22 -0700 (PDT) Received: by 10.107.138.230 with HTTP; Wed, 11 May 2016 13:45:22 -0700 (PDT) In-Reply-To: <01Q01K03ULG000005M@mauve.mrochek.com> References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> <5710953E.5040505@gmx.de> <6f2915b6-d36b-fbf6-f8a5-e35cf646faeb@it.aoyama.ac.jp> <88F1BC9BE8337F5D3B95E1BA@JcK-HP8200.jck.com> <01Q01K03ULG000005M@mauve.mrochek.com> Date: Thu, 12 May 2016 06:45:22 +1000 X-Google-Sender-Auth: HC-xqyxktA-edGuO-0B2YKX9VoQ Message-ID: From: Matthew Kerwin To: Ned Freed Content-Type: multipart/alternative; boundary=94eb2c055f68d6e6c30532971e04 Archived-At: Cc: Julian Reschke , IETF Apps Discuss , draft-ietf-appsawg-file-scheme@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 20:45:30 -0000 --94eb2c055f68d6e6c30532971e04 Content-Type: text/plain; charset=UTF-8 On 12/05/2016 1:33 AM, "Ned Freed" wrote: > > I therefore think the best thing is to document the situation as best > we can and be done with it. This is supposed to be a specification > for a URL scheme; there's no reqruiement that such documents also serve > as a BCP. > I agree. I think I've almost worked out how to cut the Encoding section back appropriately; I'll send some text to the group once I hace it, to see if it covers it. --94eb2c055f68d6e6c30532971e04 Content-Type: text/html; charset=UTF-8


On 12/05/2016 1:33 AM, "Ned Freed" <ned.freed@mrochek.com> wrote:
>
> I therefore think the best thing is to document the situation as best
> we can and be done with it. This is supposed to be a specification
> for a URL scheme; there's no reqruiement that such documents also serve
> as a BCP.
>

I agree. I think I've almost worked out how to cut the Encoding section back appropriately; I'll send some text to the group once I hace it, to see if it covers it.

--94eb2c055f68d6e6c30532971e04-- From nobody Thu May 12 08:36:35 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9681212D17C; Thu, 12 May 2016 08:36:27 -0700 (PDT) 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 lNCYaGHRQoHp; Thu, 12 May 2016 08:36:25 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 D4B7C12D09F; Thu, 12 May 2016 08:36:24 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id n129so264609444wmn.1; Thu, 12 May 2016 08:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=RzVyV3FRxl1GoVWYKwcrne7Zi4hBD3br2V8eVCUy/aQ=; b=lA1kv3K6LdfzSH2JZMeHOA9PlCFYrtvQ9DxVUoW+2hdVQcOzcIxcGO4Y32vvdjGKqU dipuEqDk/fHdzmHjbvgEDQDA9hlQHYhqR1v3yDsFiak/0Aw8k40WY1qBYaIqhkiOZTYd 05LVCuIVoSRpdn15Np9jky3zhjX7/M3s7Riar2PtaHe3XJI5CD2PEg8gXO+b9O9Zxnt2 c+1D4NVkEhHglsxhuKFj6eBPaLX53oufqN7H+hTnXbGYmDekRT6TIkQtmGKh/TDCqAm0 +nf5iXK9Wai9/m40mADla3ziCwqeJiaAC4ZE2yEiZcLt8c1RHO8zAQYYVUfD6Etn1TEv VjIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=RzVyV3FRxl1GoVWYKwcrne7Zi4hBD3br2V8eVCUy/aQ=; b=ls4ihkCNzdYjqPsv5BnN4vLq2Eqp4jFMN1H8ihgkAubbMBy0vlybJj/PGYPQsaBPJv VoLO7WpP9C9kPwp2YTD3k/HySIg51nurqppKCI4/XQjCIIhz5LTA0sBHcefx6B+OhhiB TSIbtKCKo8V0EQ0P0YH5lUV8mJobjjwPgE0+urtCzJe8OOQghlLG3nI7l1zrL9x/goZD 5gwHZrXy6kC1h/Naj6XG3AJHK2mSGSuZsp6iybUWjcHSkt5QO8oHD7fL1K2ofllZxEw4 8TctxD7BamxdxS3eeiJ//UqcxIN9ZSfiVKHwnEzDuiRZyeVbpsRbat2MzZCxoFkW8oLa ZBlQ== X-Gm-Message-State: AOPr4FUHDMVBHrWmVuQE64a+UhwLF4eM0fb8sp8F36cUGa51Z536rFZTHALTXNry1QgXwg== X-Received: by 10.28.232.212 with SMTP id f81mr7417776wmi.27.1463067383398; Thu, 12 May 2016 08:36:23 -0700 (PDT) Received: from RoniPC (bzq-79-178-104-140.red.bezeqint.net. [79.178.104.140]) by smtp.gmail.com with ESMTPSA id a200sm41920671wme.8.2016.05.12.08.36.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2016 08:36:22 -0700 (PDT) From: "Roni Even" To: "'Henry S. Thompson'" , , References: In-Reply-To: Date: Thu, 12 May 2016 18:36:07 +0300 Message-ID: <089d01d1ac64$01e77c70$05b67550$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFyRqhATyze6PpciVH2FXJ9BrlVHKB0OnUA Content-Language: he Archived-At: Cc: iesg@ietf.org Subject: Re: [apps-discuss] Appsdir review of XML schema in https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 15:36:27 -0000 Thanks for the review, I forwarded it also to the CLUE WG mailing list Roni Even CLUE WG co-chair > -----Original Message----- > From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk] > Sent: Wednesday, May 11, 2016 6:58 PM > To: apps-discuss@ietf.org; draft-ietf-clue-data-model-schema.all@ietf.org > Cc: iesg@ietf.org > Subject: Appsdir review of XML schema in https://tools.ietf.org/html/draft- > ietf-clue-data-model-schema-14 > > [Argh, fumble-finger -- resending with correct address lines] > > Document: draft-ietf-clue-data-model-schema > Title: An XML Schema for the CLUE data model > Reviewer: Henry S. Thompson > Review Date: 2016-05-11 > IETF Last Call Date: 2016-05-23 > ESG Telechat Date: 2016-06-02 > > I have been selected as the Applications Area Directorate reviewer for this > draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). > > Please resolve these comments along with any other Last Call comments you > may receive. Please wait for direction from your document shepherd or AD > before posting a new version of the draft. > > Summary: The XML Schema itself which is included in this draft is conformant > to the XML Schema 1.0 spec, and is good to go, subject to a minor > correction. There is a minor glitch in one of the XML examples, also easily > corrected. > > Comments: > > I tested the XML Schema document included as section 4 and it passes as > valid against the schema for schemas. The example document in section > 17 is schema-valid according to the corresponding schema. See 'Nits' > below for a minor problem with the example document in section 18. > > I briefly reviewed the schema document and it seems straightforward and fit > for its intended purpose. > > Minor Issues: > > Section 4, lines 13--14: > > schemaLocation="xcard.xsd"/> > > As this stands, it's not actually usable for validation purposes, because no > xcard.xsd file is supplied. Furthermore, there is no Appendix A, which is > alleged to provide it (see 11.29.1.2). > > I note further that the xCard RFC (6351) doesn't contain an XSD-format > schema document either. The IANA XML Registry [1] schema entry for the > urn:ietf:params:xml:ns:vcard-4.0 URN namespace _does_ however link to > such a schema document [2]. I suggest you either > a) Edit the draft so the above lines read > > schemaLocation="http://www.iana.org/assignments/xml- > registry/schema/vcard-4.0.xsd"/> > > (this is what I did to do the validity checks I did); > > or > > b) Delete the schemaLocation attribute and add a comment identifying > possible sources of a schema document for the vcard-4.0 namespace, > e.g. the above iana.org URI or the contents of Appendix A (if you > fill it in). > > Nits: > > Section 18, the XML example has a (copy-paste?) error, which renders that > example invalid against the schema. The line > > EG0 > > appears twice inside mediaCapture VC7, once on line 204 and once on line > 237. The first occurrence should be deleted. > > [1] http://www.iana.org/assignments/xml-registry/xml- > registry.xhtml#schema > [2] http://www.iana.org/assignments/xml-registry/schema/vcard-4.0.xsd > -- > Henry S. Thompson, School of Informatics, University of Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has > a .sig like this -- mail without it is forged spam] From nobody Thu May 12 12:01:10 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BA612D714 for ; Thu, 12 May 2016 12:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 O9wSHRvoHRT4 for ; Thu, 12 May 2016 12:01:05 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 AA6B112D9D7 for ; Thu, 12 May 2016 12:00:49 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id x19so135046843oix.2 for ; Thu, 12 May 2016 12:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=JP8c3LD7rdArhrN6qJWP7k6JYBeaggQiBCuUWgU86V8=; b=p0c0ZZHlXWxxvA3ZAj2xNxvNZG49UGB/GrAGGc5p/T/sznpgep7UGl1zgwZm7r2qrj VKHYry0c6Kgp1TBHxK7mg8h4aN7gTaCFNcREeo26cZ5KjZSQGsLRbL8SeR411IAjTPK6 43S9C940UwgK+DExnam1dxQOnrnHMgJvXiu1nwHr77Wwe8aeuR8MzGZeJK8ce1su0ujC tT+Vser2YSeA3WLuy46ShNNl2VikDm8A3rEIO6mUByCOERl1X4dQeQV3ofd8DPpOvPc+ CHlJFOTv37DBXCc9dH7pS6vpZLeJBKkNn/DKobpjls0z0mQ7dNGFN1vZ77NoQ+sR/dTu apsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=JP8c3LD7rdArhrN6qJWP7k6JYBeaggQiBCuUWgU86V8=; b=f9PmggvDS7LJ3QDZhcZ/q/mfem6zlUrEIougKGsPbL0uLwdBsmjvmkJX7+9IUkyZH+ Z6d03UrDrQJh8bnb3hmuk8Jsbj5MRzcweVRxTtBkOYVIN8HyqzpEnV0PtvZI4bTarIYK YrKRngLdu5NZzYG5K+iXf/Ms8L2T95MBZYnNKDRfi6jiJpaf2SPiqf7PmompF3wLQpvG sUkZ74/mwf32spuxRpoqB+ZZt3T42BOg1WomxZRnZMkGpm0V3cv/IIgfFqt8SPHbnvVe ISfXAyg1RhIQKaxG8G9nUcPXw82Rbol+gJ1sVgZriWcIqC8KOABUY3EkIGFIawEiJ/I0 BJ4g== X-Gm-Message-State: AOPr4FVFVwjKBw6nvb8ndW+yt8BeBVLL8nvP399e3CXDUZNz8Q7UWkJMfpIMHaZnsT1Gb0+s2jm/P7x/TqF2KA== X-Received: by 10.157.35.225 with SMTP id t88mr6558096otb.18.1463079649106; Thu, 12 May 2016 12:00:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.213.210 with HTTP; Thu, 12 May 2016 12:00:29 -0700 (PDT) From: Ted Hardie Date: Thu, 12 May 2016 12:00:29 -0700 Message-ID: To: "apps-discuss@ietf.org" Content-Type: multipart/alternative; boundary=001a11492586c372530532a9c68a Archived-At: Cc: Jana Iyengar , Christian Huitema Subject: [apps-discuss] BoF on QUIC proposed for Berlin X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 19:01:09 -0000 --001a11492586c372530532a9c68a Content-Type: text/plain; charset=UTF-8 Howdy, I wanted to let folks know that we (the cc'ed folks) have proposed a BoF on QUIC for Berlin. The BoF proposal is here: https://tools.ietf.org/bof/trac/ . This effort, if approved, will split the current approach (which is currently described in pretty monolithic terms) into a set of components, one stream of which would be a mapping of specific applications' semantics onto the QUIC transport (starting with HTTP/2). The IETF mailing list for discussion of this proposal has been set up at quic@ietf.org. The intent is to form a working group, so a charter will be posted there for review soon. If you're interested in the topic, please join the list. thanks, Ted --001a11492586c372530532a9c68a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

I wanted to let folks know t= hat we (the cc'ed folks) have proposed a BoF on QUIC for Berlin.=C2=A0 = The BoF proposal is here: https://tools.ietf.org/bof/trac/ .

This effort, if approved, will split the current approach (which is=20 currently described in pretty monolithic terms)=C2=A0 into a set of=20 components, one stream of which would be a mapping of specific applications= ' semantics onto the=20 QUIC transport (starting with HTTP/2).=C2=A0

The IETF mailing = list for discussion of this proposal has been set up at quic@ietf.o= rg.=C2=A0 The intent is to form a workin= g group, so a charter will be posted there for review soon.

If you're interested in the topic, please join the list.

thanks,

Ted
--001a11492586c372530532a9c68a-- From nobody Thu May 12 23:22:17 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76D912D0C9; Thu, 12 May 2016 23:22:13 -0700 (PDT) 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] 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 03dHlWavM6KF; Thu, 12 May 2016 23:22:11 -0700 (PDT) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F25112D0CE; Thu, 12 May 2016 23:22:10 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1b16UC-0001ra-cB; Fri, 13 May 2016 07:22:08 +0100 Received: from gklyne38.plus.com ([81.174.129.24] helo=sasharissa.local) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1b16UC-00045X-FE; Fri, 13 May 2016 07:22:08 +0100 Message-ID: <573572C7.4020408@ninebynine.org> Date: Fri, 13 May 2016 07:23:03 +0100 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: "apps-discuss@ietf.org" , ietf-message-headers@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Subject: [apps-discuss] Changes to netnews header registrations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 06:22:14 -0000 As reviewer for the IANA message headers registry (http://www.iana.org/assignments/message-headers/message-headers.xhtml), I've received a request to change references to to rename "[Son-of-1036]" references to "[RFC1849]"? This document is now published as a historic RFC. I propose to make a recommendation that goes beyond the original request, and as such I thought I should submit my proposed recommendation to public review. I think the requested change is appropriate with respect to the following message header fields: Also-control Article-names Article-updates See-also (Did I miss any?) I also think that RFC5536 should be cited for these headers, as it is this document that formally declared them to be obsolete (https://tools.ietf.org/html/rfc5536#section-6). While we're at it, I'd suggest also citing RFC5536 for the following header fields, also obsoleted by that document (https://tools.ietf.org/html/rfc5536#section-3.3 and #section-6): Date-Received netnews obsoleted [RFC0850] Posting-Version netnews obsoleted [RFC0850] Relay-Version netnews obsoleted [RFC0850] NNTP-Posting-Date netnews obsoleted NNTP-Posting-Host netnews obsoleted [RFC2980] If I hear no objection within a few days, I'll pass this recommendaton to IANA. #g -- From nobody Fri May 13 00:05:51 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E934512D0C8; Fri, 13 May 2016 00:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 qBSSK4qrsADg; Fri, 13 May 2016 00:05:46 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001: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 20E1D12D0F3; Fri, 13 May 2016 00:05:46 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id f89so122031832ioi.0; Fri, 13 May 2016 00:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=mp1Xnr5k4vJVp0CEE3r5Xcjsz5r6vi+gCoUPVDCrmrc=; b=ZKXUFoUu4AVDfRlcC5TKZJpRNsZvTRGmQwemuhXmZt7rll5MX8lvpR6WGO4C0KBdsp vlDaB4I1V7pv19fA77uTG02lIV1dq1sMjieZ9Xpwztm+5Nz7ojLCrhTdQEyySE3rFSE3 ioajtUpJF48tVnnhmcKP0cLfK3gniaxlMNqmcxqfr0dsDuTg63TUS09zPlE95XOXNn5J O65OW94wxHEgNjNxYpfxZYzXKU55P2QgGuw1Y/J0NqdInhcgGgUbjzG5/C4GuJXHi/QE mobktc6Tr+Ay0Uqaf9Q2px94VLTso9zw7uSKbB5qxMYdsRPTPYaIcrGufU2myfOYelmU vPzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=mp1Xnr5k4vJVp0CEE3r5Xcjsz5r6vi+gCoUPVDCrmrc=; b=JoHBKX0y0+sGjYcmKB8yZik9uQvugtCvjYLt1emu+HjwRQxAQCen61LjuVUZuOqTXC Swl6xO1K8LLqRytmGYiqhSCIV8dcjE0grM4bb92n8g/5dx67Yay6zn8HuaVuHr87Fil7 LL7we3y+WApThJo3y1F7nUaV/DxBEfHLJNwsQGKztRjE1BW1aGoQ8OBKSZ/wwoDViyN6 j7ehJIDQ0YDabtsRb7ZVM+5k7a5WGXoHurgtPfWCqf/ZcmOkUG35feUTK3M+80wLKw+E ZCqszQN8ku27FiQOPFIcYypGQ/H7TAnsJ154EbDlwLgqWWFBRpgPjT9SSM3rkUhik1Is yTzw== X-Gm-Message-State: AOPr4FUcmVrXskaAfUckB+n2F7oxP/UTPniOAu8LB7oTZfitB7fmn9eDVyIkaygGYQaS6qPPHTMBSv9kBdUO8g== MIME-Version: 1.0 X-Received: by 10.36.71.8 with SMTP id t8mr912108itb.47.1463123145495; Fri, 13 May 2016 00:05:45 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.138.230 with HTTP; Fri, 13 May 2016 00:05:45 -0700 (PDT) In-Reply-To: References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> <5710953E.5040505@gmx.de> <6f2915b6-d36b-fbf6-f8a5-e35cf646faeb@it.aoyama.ac.jp> <88F1BC9BE8337F5D3B95E1BA@JcK-HP8200.jck.com> <01Q01K03ULG000005M@mauve.mrochek.com> Date: Fri, 13 May 2016 17:05:45 +1000 X-Google-Sender-Auth: E1livWJTaCr0KnxV9hiZRP07Fkg Message-ID: From: Matthew Kerwin To: Ned Freed Content-Type: multipart/alternative; boundary=001a113f609c59a0370532b3e70f Archived-At: Cc: Julian Reschke , IETF Apps Discuss , draft-ietf-appsawg-file-scheme@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 07:05:49 -0000 --001a113f609c59a0370532b3e70f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Okay On 12 May 2016 at 06:45, Matthew Kerwin wrote: > > On 12/05/2016 1:33 AM, "Ned Freed" wrote: > > > > I therefore think the best thing is to document the situation as best > > we can and be done with it. This is supposed to be a specification > > for a URL scheme; there's no reqruiement that such documents also serve > > as a BCP. > > > > I agree. I think I've almost worked out how to cut the Encoding section > back appropriately; I'll send some text to the group once I hace it, to s= ee > if it covers it. > How does this sound? ~~~ 4. Encoding File systems use various encoding schemes to store file and directory names. Many modern file systems encode file and directory names as arbitrary sequences of octets, in which case the representation as an encoded string often depends on the user=E2=80=99s localization settings, o= r defaults to UTF-8 [STD63]. Without other encoding information, percent-encoded octets in a file URI ([RFC3986], Section 2.1) MAY be interpreted according to the preferred or configured encoding of the system on which the URI is being interpreted. ~~~ I don't know what advice to offer, if any. Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a113f609c59a0370532b3e70f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Okay

On 12 May 2016 at 06:45, Matthew Kerwin <matthew@ke= rwin.net.au> wrote:


On 12/05/2016 1:33 AM, "Ned Freed" <ned.freed@mrochek.com> wrote:
>
> I therefore think the best thing is to document the situation as best<= br> > we can and be done with it. This is supposed to be a specification
> for a URL scheme; there's no reqruiement that such documents also = serve
> as a BCP.
>

I agree. I think I've almost worked out how to cu= t the Encoding section back appropriately; I'll send some text to the g= roup once I hace it, to see if it covers it.


How does this sound?

~~~
=
4. Encoding

File systems use various encoding schemes to store file and directory = names. Many modern file systems encode file and directory names as arbitrar= y sequences of octets, in which case the representation as an encoded strin= g often depends on the user=E2=80=99s localization settings, or defaults to= UTF-8 [STD63].

With= out other encoding information, percent-encoded octets in a file URI ([RFC3= 986], Section 2.1) MAY be interpreted according to the preferred or configu= red encoding of the system on which the URI is being interpreted.
~~~

I don't know wha= t advice to offer, if any.

Cheers
-- =
=C2=A0 Matthew Kerwin=C2=A0 http:/= /matthew.kerwin.net.au/
--001a113f609c59a0370532b3e70f-- From nobody Fri May 13 06:05:45 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601D812D51F; Fri, 13 May 2016 06:05:43 -0700 (PDT) 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 yydj3RfQH7PM; Fri, 13 May 2016 06:05:40 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::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 C2A5412D51B; Fri, 13 May 2016 06:05:40 -0700 (PDT) Received: by mail-pa0-x229.google.com with SMTP id xk12so41121144pac.0; Fri, 13 May 2016 06:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:reply-to:subject:references:to:cc:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=6hDsu+KYkW1y2y2vWEXqI2UTjmKc47SdfqfwjJf9Rh4=; b=CPc9ZOiQTthpG8syL2MMH/GK2kVDrlXvnms1n0snxDPvA2D99hp26pjJjGIWrox6Ay WNd/2Efl81js3k3oEAVtRZTscueJmbAb9kmFfD1acLqj5+Esntx2jI9SP8vorAhWFNnG 0NPSxas3HcvAEmp9dU/Cal0I1WmxlssifY7e79za1mY2eTczpMx3duBdr08MDs/lLQyn CTEYFUVwJjRQM5CezV0SDD7WMaeQQRURpNZCOlcW3S0rbmhei7O3xjs0nR1oS9g2fuht BJVXt5LhTA2Ph/znXvFsZdh6JoBNh0+4rR6q8fjw/NCtGXb9Bdqg10xRjLAs60XyQe7f 02oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:reply-to:subject:references:to:cc :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=6hDsu+KYkW1y2y2vWEXqI2UTjmKc47SdfqfwjJf9Rh4=; b=NjKMZpPYXJuHskpo6mTCJNR0YDAVxcwMSTAqvVA7lxQdVYZUYOmMmGZvuRFPz0rwZe etY5bJ72c2E+b1I5oUuhvgXKmd+ERPZtOCbSExzeO5me80XefICRlBr1eTYUEJbv3kXt Mq8fAMESsGtav2tlo6oMD5qdVW1gRfIUvVHlDHA2HVE0LpO7om1NvZh8ioIboqFFC+Qm ri/NOqAK5NSBzG/jhpm/nWUujA2Ml/HhQNcmoxPo993Tbxp6JurRUmLmBnY8UVd9pQSv NzNPwwoCXpRc/NB1JfvXO3hcXAOXngnGtXlYNZvuTGMpwkhoPB1zVtqFL/BaRV1E10Y9 gMDg== X-Gm-Message-State: AOPr4FVPm21I5BoSgfia3y+hqabUiKz996Z1Azq5mWgmps2w/GfeGzXU7wdhXcxDLjFmuA== X-Received: by 10.66.221.167 with SMTP id qf7mr22877544pac.94.1463144740427; Fri, 13 May 2016 06:05:40 -0700 (PDT) Received: from [10.71.10.233] ([209.36.2.103]) by smtp.gmail.com with ESMTPSA id s124sm27472963pfb.63.2016.05.13.06.05.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2016 06:05:39 -0700 (PDT) From: Dave Crocker X-Google-Original-From: Dave Crocker References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> <5710953E.5040505@gmx.de> <6f2915b6-d36b-fbf6-f8a5-e35cf646faeb@it.aoyama.ac.jp> <88F1BC9BE8337F5D3B95E1BA@JcK-HP8200.jck.com> <01Q01K03ULG000005M@mauve.mrochek.com> To: Matthew Kerwin , Ned Freed Organization: Brandenburg InternetWorking Message-ID: <5735D10C.4010305@dcrocker.net> Date: Fri, 13 May 2016 06:05:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Julian Reschke , draft-ietf-appsawg-file-scheme@ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 13:05:43 -0000 On 5/13/2016 12:05 AM, Matthew Kerwin wrote: > 4. Encoding > > File systems use various encoding schemes to store file and directory > names. Just to be particularly picky, since the text is about name encoding and not, for example, content encoding, I suggest the title be 4. File Name Encoding d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri May 13 08:28:17 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43BC12D565 for ; Fri, 13 May 2016 08:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable 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 Lrcquo8NsWGY for ; Fri, 13 May 2016 08:28:14 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) by ietfa.amsl.com (Postfix) with ESMTP id AC41912B00A for ; Fri, 13 May 2016 08:28:13 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d01 with ME id trLh1s00C17Lgi403rLhV4; Fri, 13 May 2016 17:20:42 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWVAd2FuYWRvby5mcg== X-ME-Date: Fri, 13 May 2016 17:20:42 +0200 X-ME-IP: 92.170.5.52 To: "apps-discuss@ietf.org" , ietf-message-headers@ietf.org, usefor@ietf.org References: <573572C7.4020408@ninebynine.org> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <9ea7e62b-9a21-1102-eb3e-e12b574b9e89@trigofacile.com> Date: Fri, 13 May 2016 17:20:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <573572C7.4020408@ninebynine.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Graham Klyne Subject: Re: [apps-discuss] Changes to netnews header registrations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 15:28:15 -0000 Hi Graham, First of all, thanks for reviewing the request I sent. I add the USEFOR IETF WG in copy of this message, in case they wish to comment. > As reviewer for the IANA message headers registry > (http://www.iana.org/assignments/message-headers/message-headers.xhtml), > I've received a request to change references to rename > "[Son-of-1036]" references to "[RFC1849]"? This document is now > published as a historic RFC. > > I propose to make a recommendation that goes beyond the original > request, and as such I thought I should submit my proposed > recommendation to public review. > > I think the requested change is appropriate with respect to the > following message header fields: > > Also-control > Article-names > Article-updates > See-also > > (Did I miss any?) These are indeed the 4 message header fields obsoleted by RFC1849. > I also think that RFC5536 should be cited for these headers, as it is > this document that formally declared them to be obsolete > (https://tools.ietf.org/html/rfc5536#section-6). Yes, RFC5536 can be cited instead of, or along with, RFC1849. > While we're at it, I'd suggest also citing RFC5536 for the following > header fields, also obsoleted by that document > (https://tools.ietf.org/html/rfc5536#section-3.3 and #section-6): > > Date-Received netnews obsoleted [RFC0850] > Posting-Version netnews obsoleted [RFC0850] > Relay-Version netnews obsoleted [RFC0850] > NNTP-Posting-Date netnews obsoleted > NNTP-Posting-Host netnews obsoleted [RFC2980] > > If I hear no objection within a few days, I'll pass this recommendaton > to IANA. Couldn't X-Trace and X-Complaints-To header fields also be added to that list? X-Trace netnews obsoleted [RFC5536] X-Complaints-To netnews obsoleted [RFC5536] They are indeed mentioned at the same time as NNTP-Posting-Host in Section 3.2.8 of RFC5536, and are no longer useful with Injection-Info header field: NOTE: Some of this information has previously been sent in non- standardized header fields such as NNTP-Posting-Host, X-Trace, X-Complaints-To, and others. Once a news server generates an Injection-Info header field, it should have no need to send these non-standard header fields. While we're at it, couldn't MIME-related header fields also be added as standard for netnews? MIME-Version netnews standard [RFC5536][RFC5322] Content-Type netnews standard [RFC5536][RFC5322] Content-Transfer-Encoding netnews standard [RFC5536][RFC5322] Content-Disposition netnews standard [RFC5536][RFC5322] Content-Language netnews standard [RFC5536][RFC5322] As a matter of fact, Section 3.2 of RFC5536 speaks of them, with added restrictions in syntax: None of the header fields appearing in this section are required to appear in every article, but some of them may be required in certain types of articles. Further discussion of these requirements appears in [RFC5537] and [USEAGE]. The header fields Comments, Keywords, Reply-To, and Sender are used in Netnews articles in the same circumstances and with the same meanings as those specified in [RFC5322], with the added restrictions detailed above in Section 2.2. Multiple occurrences of the Keywords header field are not permitted. comments = "Comments:" SP unstructured CRLF keywords = "Keywords:" SP phrase *("," phrase) CRLF reply-to = "Reply-To:" SP address-list CRLF sender = "Sender:" SP mailbox CRLF The MIME header fields MIME-Version, Content-Type, Content-Transfer- Encoding, Content-Disposition, and Content-Language are used in Netnews articles in the same circumstances and with the same meanings as those specified in [RFC2045], [RFC2183], and [RFC3282], with the added restrictions detailed above in Section 2.2. Thanks, -- Julien ÉLIE « Pour célébrer ce jour heureux, buvons un coup, buvons-en deux. » (Aristophane) From nobody Sat May 14 22:15:10 2016 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B806512D098; Sat, 14 May 2016 22:15:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160515051508.2444.90815.idtracker@ietfa.amsl.com> Date: Sat, 14 May 2016 22:15:08 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-09.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 05:15:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group of the IETF. Title : The file URI Scheme Author : Matthew Kerwin Filename : draft-ietf-appsawg-file-scheme-09.txt Pages : 18 Date : 2016-05-14 Abstract: This document specifies the "file" Uniform Resource Identifier (URI) scheme, obsoleting the definition in RFC 1738. It defines a common syntax which is intended to interoperate across the broad spectrum of existing usages. At the same time it notes some other current practices around the use of file URIs. Note to Readers (To be removed by the RFC Editor) This draft should be discussed on the IETF Applications Area Working Group discussion list . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 14 22:26:34 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD4612B03B; Sat, 14 May 2016 22:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 UUJ33aG761Ej; Sat, 14 May 2016 22:26:31 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 6165712B019; Sat, 14 May 2016 22:26:31 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id 190so176933424iow.1; Sat, 14 May 2016 22:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=ftmsHGweGwmy7aF3ZZGQYOiXR9IxF4W/Th8/SopOrPQ=; b=du3si46TJmJeu/EhHsFeCXQ7RaV46nsHuis79AAbrqxayAse8L16KCrmBKjlke2T9n LYrIdqsIP+xMXRZfT1tuuoNj9prS6Ktuk54x9IC9f5LsSqo8iG22EeFC4r2GYuPTm0yt e380Lqb0nwsk02OUB3rtKPkLUkKNXUTsE0mCaNrvTQXqmUmH2LcKujWYrIWtYdNczRXG JM2irfpFOKKqam9nM5c5q6CJChoyr0IGz/8bVrnTMtS/40UEgMTAhfHMYmshYJTddSeh im8JfhbpHB7xY3qa/y7sT8vNTQamo1xHHEwfw1X057Vpp65uZf/I1ghYfj4NiqfWiegp wOFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ftmsHGweGwmy7aF3ZZGQYOiXR9IxF4W/Th8/SopOrPQ=; b=RBjJCUsB2bnaV/CYAobeuP+GoWCQiUFrCkRVxi9akWblfCCt8SwZPe+KQMFhz2qY2f FuDpktYTFj5fUIHltPQxyKxHmkfA7qdQSGEopZpB169x2E0Rhf2yzFOMZnhLSXFS2vOj B50IIsG9Vhs8AeT+e3EH8KjRXyofibo/BBCFycImcoP8B8bFBbvOW+8lDFzfTBz30cNu 5WIEr5Dx3g1ErahLk5ev9QkFt8IRhH5sh+DNR5EB66m5jymskYk7LnmgO7ULIYcJb31P xCGGhXMURGh0AFAWPukT0z4U7Z8IlMIvgZQrs7QjhU+SdUj+Z07Ww0uVoz7D7eqG+NYi bC9A== X-Gm-Message-State: AOPr4FUa94kbcufzNns9ZcIYgEgecZ9uKC4SrF5m+/wD6ZwD9Ne9JUw99yv7QN8MvT5Zc1yV3Eq44+nQUHwhUA== MIME-Version: 1.0 X-Received: by 10.36.65.168 with SMTP id b40mr6520828itd.10.1463289990778; Sat, 14 May 2016 22:26:30 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.138.230 with HTTP; Sat, 14 May 2016 22:26:30 -0700 (PDT) In-Reply-To: <5735D10C.4010305@dcrocker.net> References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> <5710953E.5040505@gmx.de> <6f2915b6-d36b-fbf6-f8a5-e35cf646faeb@it.aoyama.ac.jp> <88F1BC9BE8337F5D3B95E1BA@JcK-HP8200.jck.com> <01Q01K03ULG000005M@mauve.mrochek.com> <5735D10C.4010305@dcrocker.net> Date: Sun, 15 May 2016 15:26:30 +1000 X-Google-Sender-Auth: n5azsOOApmr8aNdEI8EY628uXAY Message-ID: From: Matthew Kerwin To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11351f661a98de0532dac099 Archived-At: Cc: Julian Reschke , Ned Freed , draft-ietf-appsawg-file-scheme@ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 05:26:33 -0000 --001a11351f661a98de0532dac099 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13 May 2016 at 23:05, Dave Crocker wrote: > On 5/13/2016 12:05 AM, Matthew Kerwin wrote: > >> 4. Encoding >> >> File systems use various encoding schemes to store file and directory >> names. >> > > > Just to be particularly picky, since the text is about name encoding and > not, for example, content encoding, I suggest the title be > > 4. File Name Encoding > > d/ > > =E2=80=8BFair enough. I've published this version, with the cut down text a= nd the new section name, as -09 so people can view it in the whole or using the diff tools. Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11351f661a98de0532dac099 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 13 May 2016 at 23:05, Dave Crocker = <dcrocker@gmail.= com> wrote:
On 5/13/2016 12:05 AM, = Matthew Kerwin wrote:
4. Encoding

File systems use various encoding schemes to store file and directory
names.


 Just to be particularly picky, since the text is about name encoding and no= t, for example, content encoding, I suggest the title be

=C2=A0 =C2=A04. File Name Encoding

d/


=E2=80=8BFair enough. I've = published this version, with the cut down text and the new section name, as= -09 so people can view it in the whole or using the diff tools.

Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
=
--001a11351f661a98de0532dac099-- From nobody Sun May 15 02:39:17 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD3912D12A; Sun, 15 May 2016 02:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 dbBFizCrc8Ua; Sun, 15 May 2016 02:39:14 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 3142F12D0C8; Sun, 15 May 2016 02:39:14 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6F3DD509B6; Sun, 15 May 2016 05:39:11 -0400 (EDT) To: Matthew Kerwin , Dave Crocker References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> <5710953E.5040505@gmx.de> <6f2915b6-d36b-fbf6-f8a5-e35cf646faeb@it.aoyama.ac.jp> <88F1BC9BE8337F5D3B95E1BA@JcK-HP8200.jck.com> <01Q01K03ULG000005M@mauve.mrochek.com> <5735D10C.4010305@dcrocker.net> From: Sean Leonard Message-ID: Date: Sun, 15 May 2016 02:38:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1E4B82B4A3157332A7986674" Archived-At: Cc: Julian Reschke , Ned Freed , IETF Apps Discuss , draft-ietf-appsawg-file-scheme@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 09:39:15 -0000 This is a multi-part message in MIME format. --------------1E4B82B4A3157332A7986674 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 5/14/2016 10:26 PM, Matthew Kerwin wrote: > > > On 13 May 2016 at 23:05, Dave Crocker > wrote: > > On 5/13/2016 12:05 AM, Matthew Kerwin wrote: > > 4. Encoding > > File systems use various encoding schemes to store file and > directory > names. > > > > Just to be particularly picky, since the text is about name > encoding and not, for example, content encoding, I suggest the > title be > > 4. File Name Encoding > > d/ > > > =E2=80=8BFair enough. I've published this version, with the cut down te= xt and=20 > the new section name, as -09 so people can view it in the whole or=20 > using the diff tools. In the picky vein, Section 4 should be called 4. Path Encoding Since we are talking about the whole path (including the host), not just = file names; "path" is a well-defined computing term and the draft itself = uses it. (But not really the fragment, which is not part of the path.)=20 The text of Section 4 does not need to be changed. Best regards, Sean --------------1E4B82B4A3157332A7986674 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 5/14/2016 10:26 PM, Matthew Kerwin wrote:


On 13 May 2016 at 23:05, Dave Crocker <dcrocker@gmail.com> wrote:
On 5/13/2016 12:05 AM, Matthew Kerwin wrote:
4. Encoding

File systems use various encoding schemes to store file and directory
names.


 Just to be particularly picky, since the text is about name encoding and not, for example, content encoding, I suggest the title be

   4. File Name Encoding

d/


​Fair enough. I've published this version, with the cut down text and the new section name, as -09 so people can view it in the whole or using the diff tools.

In the picky vein, Section 4 should be called
4. Path Encoding

Since we are talking about the whole path (including the host), not just file names; "path" is a well-defined computing term and the draft itself uses it. (But not really the fragment, which is not part of the path.) The text of Section 4 does not need to be changed.

Best regards,

Sean

--------------1E4B82B4A3157332A7986674-- From nobody Sun May 15 02:53:25 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006B512D150; Sun, 15 May 2016 02:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 RCyqRIjrY7m3; Sun, 15 May 2016 02:53:22 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 B90D212D14D; Sun, 15 May 2016 02:53:22 -0700 (PDT) Received: by mail-ig0-x22b.google.com with SMTP id qe5so34180112igc.1; Sun, 15 May 2016 02:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=lgGREtS+V2ObEfida4+Wr/afeVFawtSZXt8LBPQPjvM=; b=N6FSyQ2GX0lqlDi2+iSQRLtvggMj6d5mozD9SPVc1YGS9V4+8R9fo+TEG0B2tDPL6F qQiqUP5WHHVFXZBjsbVphcRgwdytNxGIWN7zx2j8Ekd1bcALCSeJP0YyQ+eeTRLMJg9J XT+CH9vTiasAgIcBw2spxqysnVF9Yt9retqKOToI8dd281u7xKhT2re9JmTvbtC4cGr/ peMyKklVmE67S6SbSKdMMNSu7lB5YUEBlzuDFOMQXIdIb9CguiH5Vbq0+IPuS4j6qnSY m43i8rWg48q1UFoYh4rffz8fUJFWzGYhAmukT/euTu3spPbgoIx7+T3YT5/oG5tB434N N7jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=lgGREtS+V2ObEfida4+Wr/afeVFawtSZXt8LBPQPjvM=; b=O+2wH/22+XMm/syztxXHWK7nMnWpLMCoVxvuhkrM1OL4pydKZDgjxhX/HgVVvL+o7n /nZAWoESyBPkWy/Uk7TlfkOjcrr7fk4Y91GsbZb/tc76ERrM/eirSVw7pcT0oeZLIqq6 PNnip6ES6IglpIJzc1kfEiU2J1RHBhD8+K4zHDPjYIGYUI36lfAyskYCSjxgcGtS7h1o cEj0b1tYggt0OAmrK3cm+kHyQvgiWtkreJUIEtrdItJiMvnMyOuzpVHNxE+/ac9dOLQ9 x3CDV9D/zs/oCidDAadFunvBPK0afHQbgOR5RmeAoNqc0oVEL/WUSB/o34BlGdKjS5ZF aQhQ== X-Gm-Message-State: AOPr4FUEg59isS3PAzFyGQwIeVIzK8XeyxTJ0kLRboQ7wQXUTCjmJHURCXx/nLiU79gS3u0iNoFnMEhPuc4++A== MIME-Version: 1.0 X-Received: by 10.50.183.132 with SMTP id em4mr5526641igc.50.1463306002028; Sun, 15 May 2016 02:53:22 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.138.230 with HTTP; Sun, 15 May 2016 02:53:21 -0700 (PDT) In-Reply-To: References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> <5710953E.5040505@gmx.de> <6f2915b6-d36b-fbf6-f8a5-e35cf646faeb@it.aoyama.ac.jp> <88F1BC9BE8337F5D3B95E1BA@JcK-HP8200.jck.com> <01Q01K03ULG000005M@mauve.mrochek.com> <5735D10C.4010305@dcrocker.net> Date: Sun, 15 May 2016 19:53:21 +1000 X-Google-Sender-Auth: rCzSyaEXCjgWySboIJHUbUaZrkw Message-ID: From: Matthew Kerwin To: Sean Leonard Content-Type: multipart/alternative; boundary=14dae9340c9572e3a60532de7a84 Archived-At: Cc: Julian Reschke , IETF Apps Discuss , Ned Freed , Dave Crocker , draft-ietf-appsawg-file-scheme@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 09:53:25 -0000 --14dae9340c9572e3a60532de7a84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15 May 2016 at 19:38, Sean Leonard wrote: > On 5/14/2016 10:26 PM, Matthew Kerwin wrote: > > > > On 13 May 2016 at 23:05, Dave Crocker wrote: > >> On 5/13/2016 12:05 AM, Matthew Kerwin wrote: >> >>> 4. Encoding >>> >>> File systems use various encoding schemes to store file and directory >>> names. >>> >> >> >> Just to be particularly picky, since the text is about name encoding and >> not, for example, content encoding, I suggest the title be >> >> 4. File Name Encoding >> >> d/ >> >> > =E2=80=8BFair enough. I've published this version, with the cut down text= and the > new section name, as -09 so people can view it in the whole or using the > diff tools. > > > In the picky vein, Section 4 should be called > 4. Path Encoding > > Since we are talking about the whole path (including the host), not just > file names; "path" is a well-defined computing term and the draft itself > uses it. (But not really the fragment, which is not part of the path.) Th= e > text of Section 4 does not need to be changed. > > =E2=80=8BActually, the host isn't part of the path, and this doesn't cover = the host anyway (that's handled by the term "fully qualified domain name" and the ABNF for `host`.) The text actually talks about the file system encoding (i.e. file path/name) rather than URI encoding. I was wondering about "File Path Encoding" as a title, but I stuck with the suggested "File Name Encoding" because I think people get it (it's only a title, after all, not an interop-dependent normative requirement), and we've previously stated that directories can be treated as files, so dirname encoding should also be covered by filename encoding.=E2=80=8B Best regards, > > Sean > > =E2=80=8BCheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --14dae9340c9572e3a60532de7a84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 15 May 2016 at 19:38, Sean Leonard = <dev+ietf@sean= tek.com> wrote:
=20 =20 =20
On 5/14/2016 10:26 PM, Matthew Kerwin wrote:


On 13 May 2016 at 23:05, Dave Crocker <dcrocker@gmail.com> wrote:
On 5/13/2016 12:05 AM, Matthew Kerwin wrote:
4. Encoding

File systems use various encoding schemes to store file and directory
names.


 Just to be particularly picky, since the text is about name encoding and not, for example, content encoding, I suggest the title be

=C2=A0 =C2=A04. File Name Encoding

d/


=E2= =80=8BFair enough. I've published this version, with the cut down text and the new section name, as -09 so people can view it in the whole or using the diff tools.

 In the picky vein, Section 4 should be called
4. Path Encoding

Since we are talking about the whole path (including the host), not just file names; "path" is a well-defined computing term and = the draft itself uses it. (But not really the fragment, which is not part of the path.) The text of Section 4 does not need to be changed.


=E2=80=8BActually, = the host isn't part of the path, and this doesn't cover the=C2=A0ho= st anyway (that's handled by the term "fully qualified domain name= " and the ABNF for `host`.) The text actually talks about the file sys= tem encoding (i.e. file path/name) rather than URI encoding. I was wonderin= g about "File Path Encoding" as a title, but=C2=A0I stuck with th= e suggested "File Name Encoding" because I think people get it (i= t's only a title, after all, not an interop-dependent normative require= ment), and we've previously stated that directories can be treated as f= iles, so dirname encoding should also be covered by filename encoding.=E2= =80=8B

Best regards,

Sean


=E2=80=8BCheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwi= n.net.au/
--14dae9340c9572e3a60532de7a84-- From nobody Sun May 15 03:07:29 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5509C12D153; Sun, 15 May 2016 03:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 dMaVTyn2KFWD; Sun, 15 May 2016 03:07:27 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 DE60912D152; Sun, 15 May 2016 03:07:26 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 20781509B5; Sun, 15 May 2016 06:07:24 -0400 (EDT) To: Matthew Kerwin References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> <5710953E.5040505@gmx.de> <6f2915b6-d36b-fbf6-f8a5-e35cf646faeb@it.aoyama.ac.jp> <88F1BC9BE8337F5D3B95E1BA@JcK-HP8200.jck.com> <01Q01K03ULG000005M@mauve.mrochek.com> <5735D10C.4010305@dcrocker.net> From: Sean Leonard Message-ID: <4f60c0af-843f-a806-7ed9-e3a597b09774@seantek.com> Date: Sun, 15 May 2016 03:06:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BF30DA3424362B4F386A04AF" Archived-At: Cc: Julian Reschke , IETF Apps Discuss , Ned Freed , Dave Crocker , draft-ietf-appsawg-file-scheme@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 10:07:28 -0000 This is a multi-part message in MIME format. --------------BF30DA3424362B4F386A04AF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/15/2016 2:53 AM, Matthew Kerwin wrote: > > > On 15 May 2016 at 19:38, Sean Leonard > wrote: > > On 5/14/2016 10:26 PM, Matthew Kerwin wrote: >> >> >> On 13 May 2016 at 23:05, Dave Crocker > > wrote: >> >> On 5/13/2016 12:05 AM, Matthew Kerwin wrote: >> >> 4. Encoding >> >> File systems use various encoding schemes to store file >> and directory >> names. >> >> >> >> Just to be particularly picky, since the text is about name >> encoding and not, for example, content encoding, I suggest >> the title be >> >> 4. File Name Encoding >> >> d/ >> >> >> ​Fair enough. I've published this version, with the cut down text >> and the new section name, as -09 so people can view it in the >> whole or using the diff tools. > > In the picky vein, Section 4 should be called > 4. Path Encoding > > Since we are talking about the whole path (including the host), > not just file names; "path" is a well-defined computing term and > the draft itself uses it. (But not really the fragment, which is > not part of the path.) The text of Section 4 does not need to be > changed. > > > ​Actually, the host isn't part of the path, and this doesn't cover > the host anyway (that's handled by the term "fully qualified domain > name" and the ABNF for `host`.) The text actually talks about the file > system encoding (i.e. file path/name) rather than URI encoding. I was > wondering about "File Path Encoding" as a title, but I stuck with the > suggested "File Name Encoding" because I think people get it (it's > only a title, after all, not an interop-dependent normative > requirement), and we've previously stated that directories can be > treated as files, so dirname encoding should also be covered by > filename encoding.​ > Compromise: how about "File Path Encoding"? ;-) Since "file name" implies file name (as distinct from directory name). Otherwise, we can go back to "Encoding"... Sean --------------BF30DA3424362B4F386A04AF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/15/2016 2:53 AM, Matthew Kerwin wrote:


On 15 May 2016 at 19:38, Sean Leonard <dev+ietf@seantek.com> wrote:
On 5/14/2016 10:26 PM, Matthew Kerwin wrote:


On 13 May 2016 at 23:05, Dave Crocker <dcrocker@gmail.com> wrote:
On 5/13/2016 12:05 AM, Matthew Kerwin wrote:
4. Encoding

File systems use various encoding schemes to store file and directory
names.


 Just to be particularly picky, since the text is about name encoding and not, for example, content encoding, I suggest the title be

   4. File Name Encoding

d/


​Fair enough. I've published this version, with the cut down text and the new section name, as -09 so people can view it in the whole or using the diff tools.

 In the picky vein, Section 4 should be called
4. Path Encoding

Since we are talking about the whole path (including the host), not just file names; "path" is a well-defined computing term and the draft itself uses it. (But not really the fragment, which is not part of the path.) The text of Section 4 does not need to be changed.


​Actually, the host isn't part of the path, and this doesn't cover the host anyway (that's handled by the term "fully qualified domain name" and the ABNF for `host`.) The text actually talks about the file system encoding (i.e. file path/name) rather than URI encoding. I was wondering about "File Path Encoding" as a title, but I stuck with the suggested "File Name Encoding" because I think people get it (it's only a title, after all, not an interop-dependent normative requirement), and we've previously stated that directories can be treated as files, so dirname encoding should also be covered by filename encoding.​


Compromise: how about "File Path Encoding"? ;-) Since "file name" implies file name (as distinct from directory name). Otherwise, we can go back to "Encoding"...

Sean --------------BF30DA3424362B4F386A04AF-- From nobody Sun May 15 03:16:50 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1595B12D152; Sun, 15 May 2016 03:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 E_Qc8fk_Hjn0; Sun, 15 May 2016 03:16:47 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 70F5712D13C; Sun, 15 May 2016 03:16:47 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4D5EE509B5; Sun, 15 May 2016 06:16:46 -0400 (EDT) To: apps-discuss@ietf.org References: <20160515051508.2444.90815.idtracker@ietfa.amsl.com> From: Sean Leonard Message-ID: Date: Sun, 15 May 2016 03:15:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160515051508.2444.90815.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-appsawg-file-scheme@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-09.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 10:16:49 -0000 On 5/14/2016 10:15 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the ART Area General Applications Working Group of the IETF. > > Title : The file URI Scheme > Author : Matthew Kerwin > Filename : draft-ietf-appsawg-file-scheme-09.txt > Pages : 18 > Date : 2016-05-14 Did a full review; looks very good. Nice work! The References section lists several references to MSDN articles. Shorter MSDN article URLs are of the form: https://msdn.microsoft.com/library/{ARTICLEID} Such as: https://msdn.microsoft.com/library/gg465305 https://msdn.microsoft.com/library/aa365247 I suggest simplifying the links, and updating the dates. Note that some library articles have dates; others do not. For example, [MS-DTYP] is most recently dated October 16, 2015, revision 30.0, according to its changelog at article ID cc230273. In Appendix C, a discussion of Win32 Namespaces is given, but then it says "This specification does not define a mechanism for translating namespaced paths to or from file URIs." Readers would appreciate an informative reference for a mechanism to translate namespaced paths to and from file URIs, especially since there is a lot of technical content about Win32 processing in the rest of the Appendices. I believe that the (American) English capitalization of Appendix D should be: Appendix D. System-Specific Operations Just curious: what happens if you try to access file://USERNAME@HOST/foo/bar.txt on a Windows UNC/network share, using a Windows machine and suitable API operations (e.g., Internet Explorer)? Will Windows try to access the network path with the given username, or something else? And does USER:PASS work? I would be remiss if the term "alternate data streams" (ADS) were not mentioned in the context of Windows naming conventions. E.g.: file:///G:/somebody.txt:other.txt The syntax is already supported by the normative Syntax section, and is acknowledged without being named in the Security Considerations section. Therefore, no additional text is needed (but others may find it desirable--I leave that decision to this WG). At least it's now a part of the discussion record on this mailing list. I just did a cursory check of some browsers on a Windows 7 machine. Ironically, Windows Explorer and Internet Explorer claim that they cannot find the ADS path, but Firefox and Chrome/Chromium-based browsers will load the ADS path all right. (I did not test what happens with relative references in, e.g., ./foo.txt:composite.html.) Not sure if other file: URI processors handle such things, e.g., extended attributes / getxattr in Linux. Sean From nobody Sun May 15 05:24:11 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC75C12B024; Sun, 15 May 2016 05:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 n8X-oRP1g-Tt; Sun, 15 May 2016 05:24:09 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 2907F12D09B; Sun, 15 May 2016 05:24:09 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id f89so181397353ioi.0; Sun, 15 May 2016 05:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=1A+Vj1mdcFGvWgp6tCN308U57gzS9Y9XcE1/YJkm5lE=; b=bbHfmy1PFaVOrDSNN3eTVQJc9zsbrSM+i1WLaZGCnqcZbUywBrpRy++AbhDR89kLg2 gagEk8blQnU/J/AyctIWlzMpKgw9f80WTSWZCX9AVT8yiv6rgE7wA/m6Ok9aefxFuaBK YxmXzKxb/CAFTozzqMtwo6C0zmneT40BOMuaG2Zg1+BFbRGK7/jzlnOGBNZtdW6OaeKn lpFYGw/stycZxHcHx1vItHwBDeog9T3JscW98KgrtfTHEgLKifGwk0ljyAhJMWFGiUz5 UeU2YOZH0G/+ahN5p9OL0N4jAGmmULiQd5KIdxr4UE2PL6jJI0ATSldNFpkGrI1NhZmT M0fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1A+Vj1mdcFGvWgp6tCN308U57gzS9Y9XcE1/YJkm5lE=; b=gHoMv8gSE73PbdbktlObcc2K0+531XSWHmoi7yopVGOk87jsmqb51RZBQc/B+hCocK pzEQGiN6+Yg2LXGPel2Bloa4Pi0hLRPAKT3S+9YE29EJUo8Hl9/gdMWQIZKZrCABPBIk 23PVUXj2Y/IH0xRf8Xv79iCLQ9m3OAen7ylpEHVfnbYyVy/oEvD0m+c95U8KBtTq/+Ac bXwSxc2HAF22Uc/juynijVUVLaz1ppTtCLJhJAtvPDNC6x4Bh4a3IRyWrb0/9fMrsLSR 5gM5PWzBakQjTEI10Vo/d9CrbQsS9OqGOyQzer4P5HpMpt7nWUd6O1DVYNLyKp3etO4v RVpw== X-Gm-Message-State: AOPr4FWqLV+nRE9PxKFi29dlyx6Z7/lxSJeShud80mdbO+C0dxx8wW9uiArDkuL2MUhqixLQaiUcY31BovfBlg== MIME-Version: 1.0 X-Received: by 10.107.56.131 with SMTP id f125mr16600232ioa.188.1463315048441; Sun, 15 May 2016 05:24:08 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.138.230 with HTTP; Sun, 15 May 2016 05:24:08 -0700 (PDT) In-Reply-To: References: <20160515051508.2444.90815.idtracker@ietfa.amsl.com> Date: Sun, 15 May 2016 22:24:08 +1000 X-Google-Sender-Auth: V7Zvddg1FZ4NYJls3VzXIsWl0nQ Message-ID: From: Matthew Kerwin To: Sean Leonard Content-Type: multipart/alternative; boundary=001a114ac8d0a833b20532e095a5 Archived-At: Cc: draft-ietf-appsawg-file-scheme@ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-09.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 12:24:11 -0000 --001a114ac8d0a833b20532e095a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15 May 2016 at 20:15, Sean Leonard wrote: > On 5/14/2016 10:15 PM, internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the ART Area General Applications Working >> Group of the IETF. >> >> Title : The file URI Scheme >> Author : Matthew Kerwin >> Filename : draft-ietf-appsawg-file-scheme-09.txt >> Pages : 18 >> Date : 2016-05-14 >> > > Did a full review; looks very good. Nice work! > > The References section lists several references to MSDN articles. > > Shorter MSDN article URLs are of the form: > https://msdn.microsoft.com/library/{ARTICLEID} > > Such as: > https://msdn.microsoft.com/library/gg465305 > https://msdn.microsoft.com/library/aa365247 > > I suggest simplifying the links, and updating the dates. Note that some > library articles have dates; others do not. For example, [MS-DTYP] is mos= t > recently dated October 16, 2015, revision 30.0, according to its changelo= g > at article ID cc230273. > > =E2=80=8BWell, I did access the en-us versions. When I go to the short URL = you linked above, I get the en-au versions ;) Nevertheless I can refresh the references and update the dates. I'm confused, though; MS-DTYP now includes an ABNF (which is cool) but it's broken (which is not cool.) I think I know what they meant to say, but that's not what they've actually said. I don't feel great referencing that, even informatively. =E2=80=8B > In Appendix C, a discussion of Win32 Namespaces is given, but then it say= s > "This specification does not define a mechanism for translating namespace= d > paths to or from file URIs." Readers would appreciate an informative > reference for a mechanism to translate namespaced paths to and from file > URIs, especially since there is a lot of technical content about Win32 > processing in the rest of the Appendices. > > =E2=80=8BThey might, but I don't have one. What would you suggest? What is currently done? =E2=80=8B > I believe that the (American) English capitalization of Appendix D should > be: > Appendix D. System-Specific Operations > > =E2=80=8BSure, I can do that. =E2=80=8B Just curious: what happens if you try to access file://USERNAME@HOST/foo/bar.txt > on a Windows UNC/network share, using a Windows machine and suitable API > operations (e.g., Internet Explorer)? Will Windows try to access the > network path with the given username, or something else? And does USER:PA= SS > work? > > =E2=80=8BDidn't work for me in IE11, with any combination of @, user@, user= :pass@. Incidentally, it was also happy to accept both "c$" and "c%24" to access the magic C:\ share. Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a114ac8d0a833b20532e095a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 15 May 2016 at 20:15, Sean Leonard <<= a href=3D"mailto:dev+ietf@seantek.com" target=3D"_blank">dev+ietf@seantek.c= om> wrote:
On 5/14/20= 16 10:15 PM, = internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the ART Area General Applications Working Grou= p of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: The file URI Scheme
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : Matthew Kerwin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-appsawg-file-scheme-09.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 18
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-05-14

 Did a full review; looks very good. Nice work!

The References section lists several references to MSDN articles.

Shorter MSDN article URLs are of the form:
https://msdn.microsoft.com/library/{ARTICLEID}=

Such as:
https://msdn.microsoft.com/library/gg465305
https://msdn.microsoft.com/library/aa365247

I suggest simplifying the links, and updating the dates. Note that some lib= rary articles have dates; others do not. For example, [MS-DTYP] is most rec= ently dated October 16, 2015, revision 30.0, according to its changelog at = article ID cc230273.


=E2=80=8BWell, I did access t= he en-us versions. When I go to the short URL you linked above, I get the e= n-au versions ;)

Nevertheless I can refres= h the references and update the dates. I'm confused, though; MS-DTYP no= w includes an=C2=A0ABNF (which is cool) but it's broken (which is not c= ool.) I think I know what they meant to say, but that's not what they&#= 39;ve actually said. I don't feel great referencing that, even informat= ively.
=E2=80=8B
=C2=A0
In Appendix C, a discussion of Win32 Namespaces is given, but then it says = "This specification does not define a mechanism for translating namesp= aced paths to or from file URIs." Readers would appreciate an informat= ive reference for a mechanism to translate namespaced paths to and from fil= e URIs, especially since there is a lot of technical content about Win32 pr= ocessing in the rest of the Appendices.


=E2=80=8BThey might, but I don= 9;t have one. What would you suggest? What is currently done?
=E2=80=8B
=C2=A0
I bel= ieve that the (American) English capitalization of Appendix D should be: Appendix D. System-Specific Operations


=E2=80=8BSure, I can do that.=
=E2=80=8B

Just curious: what happens if you try to access file://USERNAME@HOST/foo/ba= r.txt on a Windows UNC/network share, using a Windows machine and suitable = API operations (e.g., Internet Explorer)? Will Windows try to access the ne= twork path with the given username, or something else? And does USER:PASS w= ork?


=E2=80=8BDidn't work for = me in IE11, with any combination of @, user@, user:pass@. Incidentally, it = was also happy to accept both "c$" and "c%24" to access= the magic C:\ share.

Cheers
--
=C2=A0 Matth= ew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a114ac8d0a833b20532e095a5-- From nobody Sun May 15 09:14:24 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927E112D0E0; Sun, 15 May 2016 09:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 YnKwp6uCjiXF; Sun, 15 May 2016 09:14:21 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 2A33712B01B; Sun, 15 May 2016 09:14:21 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D4C57509B8; Sun, 15 May 2016 12:14:18 -0400 (EDT) To: Matthew Kerwin References: <20160515051508.2444.90815.idtracker@ietfa.amsl.com> From: Sean Leonard Message-ID: <38873e4f-235e-54c1-9580-cb0696d85cd2@seantek.com> Date: Sun, 15 May 2016 09:13:24 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AF56DCD46DF470E5094B5710" Archived-At: Cc: draft-ietf-appsawg-file-scheme@ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-09.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 16:14:23 -0000 This is a multi-part message in MIME format. --------------AF56DCD46DF470E5094B5710 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 5/15/2016 5:24 AM, Matthew Kerwin wrote: > > > On 15 May 2016 at 20:15, Sean Leonard > wrote: > > On 5/14/2016 10:15 PM, internet-drafts@ietf.org > wrote: > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the ART Area General Applications > Working Group of the IETF. > > Title : The file URI Scheme > Author : Matthew Kerwin > Filename : draft-ietf-appsawg-file-scheme-09.txt= > Pages : 18 > Date : 2016-05-14 > > > Did a full review; looks very good. Nice work! > > The References section lists several references to MSDN articles. > > Shorter MSDN article URLs are of the form: > https://msdn.microsoft.com/library/{ARTICLEID} > > > Such as: > https://msdn.microsoft.com/library/gg465305 > https://msdn.microsoft.com/library/aa365247 > > I suggest simplifying the links, and updating the dates. Note that > some library articles have dates; others do not. For example, > [MS-DTYP] is most recently dated October 16, 2015, revision 30.0, > according to its changelog at article ID cc230273. > > > =E2=80=8BWell, I did access the en-us versions. When I go to the short = URL you=20 > linked above, I get the en-au versions ;) Yep. Short URL is language/locale-neutral. > > Nevertheless I can refresh the references and update the dates. I'm=20 > confused, though; MS-DTYP now includes an ABNF (which is cool) but=20 > it's broken (which is not cool.) I think I know what they meant to=20 > say, but that's not what they've actually said. I don't feel great=20 > referencing that, even informatively. Well, the best solution is to report it to Microsoft and get them to fix = it. You can reference this thread, among others. I see the following=20 problems with that ABNF in gg465305: host-name =3D "[" IPv6address =E2=80=98]" / IPv4address / reg-na= me has a turned comma; it should be: host-name =3D "[" IPv6address "]" / IPv4address / reg-name pchar, fchar, and schar are defined in the range 00h-FFh. However, the=20 definition says that "The filespace selector is a null-terminatedUnicode = character=20 string".=20 The reference to "Unicode character" says "Unless otherwise specified, a = 16-bit UTF-16 code unit." Also: "Unless otherwise specified, allUnicode=20 strings=20 follow=20 the UTF-16LE encoding scheme with no Byte Order Mark (BOM)." (Unicode=20 string) This would mean that the domain of the ABNF is 0000-FFFF. I am fairly certain that Windows does not enforce well-formedness=20 Unicode surrogate sequences, which makes the ABNF easier: you can blow=20 through %x80-FFFF without needing special handling of high and low=20 surrogate points. /However/, the RPC type is defined as STRING, which is UCHAR*, which is=20 "a null-terminated string of 8-bit characters". Therefore, we might be=20 in UTF-8 land. If in UTF-8 land, is the UTF8-non-ascii production=20 appropriate? (RFC 6532 & RFC 3629) I haven't groked pchar, fchar, or schar. Overall, however, the authors=20 of that MS spec have to determine and fix: * Is the ABNF in 0000-FFFF (16-bit units), or 00-FF (8-bit units)? * Is UTF-8 or UTF-16 intended? * What's actually going on in real life? I know that the Windows API is UTF-16LE. What about SMB on the wire? > =E2=80=8B > > In Appendix C, a discussion of Win32 Namespaces is given, but then > it says "This specification does not define a mechanism for > translating namespaced paths to or from file URIs." Readers would > appreciate an informative reference for a mechanism to translate > namespaced paths to and from file URIs, especially since there is > a lot of technical content about Win32 processing in the rest of > the Appendices. > > > =E2=80=8BThey might, but I don't have one. What would you suggest? What= is=20 > currently done? > =E2=80=8B Need someone else to chime in on this (and the other stuff). Sean --------------AF56DCD46DF470E5094B5710 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/15/2016 5:24 AM, Matthew Kerwin wrote:


On 15 May 2016 at 20:15, Sean Leonard <dev+ietf@seantek.com> wrote:
On 5/14/2016 10:15 PM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the ART Area General Applications Working Group of the IETF.

         Title           : The file URI Scheme
         Author          : Matthew Kerwin
        Filename        : draft-ietf-appsawg-file-scheme-09.txt
        Pages           : 18
        Date            : 2016-05-14

 Did a full review; looks very good. Nice work!

The References section lists several references to MSDN articles.

Shorter MSDN article URLs are of the form:
https://msdn.microsoft.com/library/{ARTICLEID}

Such as:
https://msdn.microsoft.com/library/gg465305
https://msdn.microsoft.com/library/aa365247

I suggest simplifying the links, and updating the dates. Note that some library articles have dates; others do not. For example, [MS-DTYP] is most recently dated October 16, 2015, revision 30.0, according to its changelog at article ID cc230273.


​Well, I did access the en-us versions. When I go to the short URL you linked above, I get the en-au versions ;)

Yep. Short URL is language/locale-neutral.


Nevertheless I can refresh the references and update the dates. I'm confused, though; MS-DTYP now includes an ABNF (which is cool) but it's broken (which is not cool.) I think I know what they meant to say, but that's not what they've actually said. I don't feel great referencing that, even informatively.

Well, the best solution is to report it to Microsoft and get them to fix it. You can reference this thread, among others. I see the following problems with that ABNF in gg465305:

host-name          = "[" IPv6address ‘]" / IPv4address / reg-name
has a turned comma; it should be:
host-name          = "[" IPv6address "]" / IPv4address / reg-name

pchar, fchar, and schar are defined in the range 00h-FFh. However, the definition says that "The filespace selector is a null-terminated Unicode character string". The reference to "Unicode character" says "Unless otherwise specified, a 16-bit UTF-16 code unit." Also: "Unless otherwise specified, all Unicode strings follow the UTF-16LE encoding scheme with no Byte Order Mark (BOM)." (Unicode string) This would mean that the domain of the ABNF is 0000-FFFF.

I am fairly certain that Windows does not enforce well-formedness Unicode surrogate sequences, which makes the ABNF easier: you can blow through %x80-FFFF without needing special handling of high and low surrogate points.

However, the RPC type is defined as STRING, which is UCHAR*, which is "a null-terminated string of 8-bit characters". Therefore, we might be in UTF-8 land. If in UTF-8 land, is the UTF8-non-ascii production appropriate? (RFC 6532 & RFC 3629)

I haven't groked pchar, fchar, or schar. Overall, however, the authors of that MS spec have to determine and fix:
  • Is the ABNF in 0000-FFFF (16-bit units), or 00-FF (8-bit units)?
  • Is UTF-8 or UTF-16 intended?
  • What's actually going on in real life? I know that the Windows API is UTF-16LE. What about SMB on the wire?

​
 
In Appendix C, a discussion of Win32 Namespaces is given, but then it says "This specification does not define a mechanism for translating namespaced paths to or from file URIs." Readers would appreciate an informative reference for a mechanism to translate namespaced paths to and from file URIs, especially since there is a lot of technical content about Win32 processing in the rest of the Appendices.


​They might, but I don't have one. What would you suggest? What is currently done?
​

Need someone else to chime in on this (and the other stuff).

Sean
--------------AF56DCD46DF470E5094B5710-- From nobody Mon May 16 00:07:13 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79E912B019 for ; Mon, 16 May 2016 00:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 lLYXB3_kBTvP for ; Mon, 16 May 2016 00:07:10 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 9C43412B00E for ; Mon, 16 May 2016 00:07:10 -0700 (PDT) Received: from [192.168.1.109] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 56F6822E256; Mon, 16 May 2016 03:07:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mark Nottingham In-Reply-To: Date: Mon, 16 May 2016 17:06:59 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160515051508.2444.90815.idtracker@ietfa.amsl.com> To: Matthew Kerwin X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-09.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 07:07:12 -0000 Hi Matthew, I think the new Section 4 is an improvement -- much more precise than it = was. However, a few questions still linger for me: > 4. File Name Encoding >=20 > File systems use various encoding schemes to store file and = directory > names. Many modern file systems encode file and directory names as > arbitrary sequences of octets, This is a bit confusing -- perhaps s/encode/store/ ? Or remove this part = of the sentence altogether? > in which case the representation as an > encoded string often depends on the user's localization settings, = or > defaults to UTF-8 [STD63]. >=20 > Without other encoding information, percent-encoded octets in a = file > URI ([RFC3986], Section 2.1) MAY be interpreted according to the > preferred or configured encoding of the system on which the URI is > being interpreted. Do the current implementations of file:// do this -- i.e., use the = filesystem's encoding for the URI?=20 Doing it that way seems unfortunate; two different users on the same = machine (or network) won't see good interop in this approach. If it's this way intentionally, or if we think it can't change, that's = understandable, but if not we should have a good hard look at changing = it IMO. Has there been any discussion of this to date (sorry if I missed it)? Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon May 16 01:19:37 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2966A12B00C; Mon, 16 May 2016 01:19:37 -0700 (PDT) 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] 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 ASCx7XGL-HMT; Mon, 16 May 2016 01:19:35 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFF412B007; Mon, 16 May 2016 01:19:35 -0700 (PDT) Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1b2DkT-0005VQ-h5; Mon, 16 May 2016 09:19:33 +0100 Received: from [104.238.169.54] (helo=sasharissa.local) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1b2DkT-0008V7-Gi; Mon, 16 May 2016 09:19:33 +0100 Message-ID: <573982D3.1090106@ninebynine.org> Date: Mon, 16 May 2016 09:20:35 +0100 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: =?UTF-8?B?SnVsaWVuIMOJTElF?= , "apps-discuss@ietf.org" , ietf-message-headers@ietf.org, usefor@ietf.org References: <573572C7.4020408@ninebynine.org> <9ea7e62b-9a21-1102-eb3e-e12b574b9e89@trigofacile.com> In-Reply-To: <9ea7e62b-9a21-1102-eb3e-e12b574b9e89@trigofacile.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] Changes to netnews header registrations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 08:19:37 -0000 Hi Julien, Thanks for your update and confirmation of the affected fields. TL;DR: I don't propose to recommend the additional changes you suggest as I'm not seeing that they really contribute to the purpose of the registry (cf. https://tools.ietf.org/html/rfc3864#section-2.2.2). In slightly more detail, I offer the following reasons: 1. My rationale in suggesting the changes I did was to help keep the registry reasonably aligned with the relevant IANA considerations RFC sections. The additional headers you mention don't appear in the document IANA considerations. 2. With reference to the X-headers you mention, I see little point in adding new, non-standard headers to the registry simply to indicate they are now obsolete. (There could be a case for doing this if they are in widespread use, but I think that should be a separate discussion, and a new RFC with its own IANA considerations section. I suspect it's not worth the effort!) 3. The other headers you mention are not substantively changed by RFC 5536: the restrictions noted are specifically with respect to the netnews protocol, and as such are not really relevant to the registry purpose. 4. I did consider that "netnews" might be added to the protocol options for the MIME-version and Content-* header fields you mention, but as they are already registered as MIME headers that doesn't seem to serve any useful purpose (see https://tools.ietf.org/html/rfc3864#section-2.2.2). #g -- On 13/05/2016 16:20, Julien ÉLIE wrote: > Hi Graham, > > First of all, thanks for reviewing the request I sent. > I add the USEFOR IETF WG in copy of this message, in case they wish to comment. > > >> As reviewer for the IANA message headers registry >> (http://www.iana.org/assignments/message-headers/message-headers.xhtml), >> I've received a request to change references to rename >> "[Son-of-1036]" references to "[RFC1849]"? This document is now >> published as a historic RFC. >> >> I propose to make a recommendation that goes beyond the original >> request, and as such I thought I should submit my proposed >> recommendation to public review. >> >> I think the requested change is appropriate with respect to the >> following message header fields: >> >> Also-control >> Article-names >> Article-updates >> See-also >> >> (Did I miss any?) > > These are indeed the 4 message header fields obsoleted by RFC1849. > > >> I also think that RFC5536 should be cited for these headers, as it is >> this document that formally declared them to be obsolete >> (https://tools.ietf.org/html/rfc5536#section-6). > > Yes, RFC5536 can be cited instead of, or along with, RFC1849. > > >> While we're at it, I'd suggest also citing RFC5536 for the following >> header fields, also obsoleted by that document >> (https://tools.ietf.org/html/rfc5536#section-3.3 and #section-6): >> >> Date-Received netnews obsoleted [RFC0850] >> Posting-Version netnews obsoleted [RFC0850] >> Relay-Version netnews obsoleted [RFC0850] >> NNTP-Posting-Date netnews obsoleted >> NNTP-Posting-Host netnews obsoleted [RFC2980] >> >> If I hear no objection within a few days, I'll pass this recommendaton >> to IANA. > > Couldn't X-Trace and X-Complaints-To header fields also be added to that list? > > X-Trace netnews obsoleted [RFC5536] > X-Complaints-To netnews obsoleted [RFC5536] > > They are indeed mentioned at the same time as NNTP-Posting-Host in Section 3.2.8 > of RFC5536, and are no longer useful with Injection-Info header field: > > NOTE: Some of this information has previously been sent in non- > standardized header fields such as NNTP-Posting-Host, X-Trace, > X-Complaints-To, and others. Once a news server generates an > Injection-Info header field, it should have no need to send these > non-standard header fields. > > > > > While we're at it, couldn't MIME-related header fields also be added as standard > for netnews? > > MIME-Version netnews standard [RFC5536][RFC5322] > Content-Type netnews standard [RFC5536][RFC5322] > Content-Transfer-Encoding netnews standard [RFC5536][RFC5322] > Content-Disposition netnews standard [RFC5536][RFC5322] > Content-Language netnews standard [RFC5536][RFC5322] > > As a matter of fact, Section 3.2 of RFC5536 speaks of them, with added > restrictions in syntax: > > None of the header fields appearing in this section are required to > appear in every article, but some of them may be required in certain > types of articles. Further discussion of these requirements appears > in [RFC5537] and [USEAGE]. > > The header fields Comments, Keywords, Reply-To, and Sender are used > in Netnews articles in the same circumstances and with the same > meanings as those specified in [RFC5322], with the added restrictions > detailed above in Section 2.2. Multiple occurrences of the Keywords > header field are not permitted. > > comments = "Comments:" SP unstructured CRLF > > keywords = "Keywords:" SP phrase *("," phrase) CRLF > > reply-to = "Reply-To:" SP address-list CRLF > > sender = "Sender:" SP mailbox CRLF > > The MIME header fields MIME-Version, Content-Type, Content-Transfer- > Encoding, Content-Disposition, and Content-Language are used in > Netnews articles in the same circumstances and with the same meanings > as those specified in [RFC2045], [RFC2183], and [RFC3282], with the > added restrictions detailed above in Section 2.2. > > > Thanks, > From nobody Mon May 16 01:32:10 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25D812B04C; Mon, 16 May 2016 01:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 6zOwdXJd3R94; Mon, 16 May 2016 01:32:05 -0700 (PDT) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E207612B007; Mon, 16 May 2016 01:32:04 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1b2DwZ-0002eT-mi; Mon, 16 May 2016 09:32:03 +0100 Received: from [104.238.169.54] (helo=sasharissa.local) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1b2DwY-0002w4-G0; Mon, 16 May 2016 09:32:03 +0100 Message-ID: <573985BD.1060201@ninebynine.org> Date: Mon, 16 May 2016 09:33:01 +0100 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: =?UTF-8?B?SnVsaWVuIMOJTElF?= , "apps-discuss@ietf.org" , ietf-message-headers@ietf.org, usefor@ietf.org References: <573572C7.4020408@ninebynine.org> <9ea7e62b-9a21-1102-eb3e-e12b574b9e89@trigofacile.com> <573982D3.1090106@ninebynine.org> In-Reply-To: <573982D3.1090106@ninebynine.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] [Ietf-message-headers] Changes to netnews header registrations (correction) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 08:32:07 -0000 On 16/05/2016 09:20, Graham Klyne wrote: > Hi Julien, > > Thanks for your update and confirmation of the affected fields. > > TL;DR: I don't propose to recommend the additional changes you suggest as I'm > not seeing that they really contribute to the purpose of the registry (cf. > https://tools.ietf.org/html/rfc3864#section-2.2.2). That link should have been https://tools.ietf.org/html/rfc3864#section-1. Sorry. #g -- > > > In slightly more detail, I offer the following reasons: > > 1. My rationale in suggesting the changes I did was to help keep the registry > reasonably aligned with the relevant IANA considerations RFC sections. The > additional headers you mention don't appear in the document IANA considerations. > > 2. With reference to the X-headers you mention, I see little point in adding > new, non-standard headers to the registry simply to indicate they are now > obsolete. (There could be a case for doing this if they are in widespread > use, but I think that should be a separate discussion, and a new RFC with its > own IANA considerations section. I suspect it's not worth the effort!) > > 3. The other headers you mention are not substantively changed by RFC 5536: > the restrictions noted are specifically with respect to the netnews protocol, > and as such are not really relevant to the registry purpose. > > 4. I did consider that "netnews" might be added to the protocol options for > the MIME-version and Content-* header fields you mention, but as they are > already registered as MIME headers that doesn't seem to serve any useful > purpose (see https://tools.ietf.org/html/rfc3864#section-2.2.2). > > #g > -- > > > On 13/05/2016 16:20, Julien ÉLIE wrote: >> Hi Graham, >> >> First of all, thanks for reviewing the request I sent. >> I add the USEFOR IETF WG in copy of this message, in case they wish to comment. >> >> >>> As reviewer for the IANA message headers registry >>> (http://www.iana.org/assignments/message-headers/message-headers.xhtml), >>> I've received a request to change references to rename >>> "[Son-of-1036]" references to "[RFC1849]"? This document is now >>> published as a historic RFC. >>> >>> I propose to make a recommendation that goes beyond the original >>> request, and as such I thought I should submit my proposed >>> recommendation to public review. >>> >>> I think the requested change is appropriate with respect to the >>> following message header fields: >>> >>> Also-control >>> Article-names >>> Article-updates >>> See-also >>> >>> (Did I miss any?) >> >> These are indeed the 4 message header fields obsoleted by RFC1849. >> >> >>> I also think that RFC5536 should be cited for these headers, as it is >>> this document that formally declared them to be obsolete >>> (https://tools.ietf.org/html/rfc5536#section-6). >> >> Yes, RFC5536 can be cited instead of, or along with, RFC1849. >> >> >>> While we're at it, I'd suggest also citing RFC5536 for the following >>> header fields, also obsoleted by that document >>> (https://tools.ietf.org/html/rfc5536#section-3.3 and #section-6): >>> >>> Date-Received netnews obsoleted [RFC0850] >>> Posting-Version netnews obsoleted [RFC0850] >>> Relay-Version netnews obsoleted [RFC0850] >>> NNTP-Posting-Date netnews obsoleted >>> NNTP-Posting-Host netnews obsoleted [RFC2980] >>> >>> If I hear no objection within a few days, I'll pass this recommendaton >>> to IANA. >> >> Couldn't X-Trace and X-Complaints-To header fields also be added to that list? >> >> X-Trace netnews obsoleted [RFC5536] >> X-Complaints-To netnews obsoleted [RFC5536] >> >> They are indeed mentioned at the same time as NNTP-Posting-Host in Section 3.2.8 >> of RFC5536, and are no longer useful with Injection-Info header field: >> >> NOTE: Some of this information has previously been sent in non- >> standardized header fields such as NNTP-Posting-Host, X-Trace, >> X-Complaints-To, and others. Once a news server generates an >> Injection-Info header field, it should have no need to send these >> non-standard header fields. >> >> >> >> >> While we're at it, couldn't MIME-related header fields also be added as standard >> for netnews? >> >> MIME-Version netnews standard [RFC5536][RFC5322] >> Content-Type netnews standard [RFC5536][RFC5322] >> Content-Transfer-Encoding netnews standard [RFC5536][RFC5322] >> Content-Disposition netnews standard [RFC5536][RFC5322] >> Content-Language netnews standard [RFC5536][RFC5322] >> >> As a matter of fact, Section 3.2 of RFC5536 speaks of them, with added >> restrictions in syntax: >> >> None of the header fields appearing in this section are required to >> appear in every article, but some of them may be required in certain >> types of articles. Further discussion of these requirements appears >> in [RFC5537] and [USEAGE]. >> >> The header fields Comments, Keywords, Reply-To, and Sender are used >> in Netnews articles in the same circumstances and with the same >> meanings as those specified in [RFC5322], with the added restrictions >> detailed above in Section 2.2. Multiple occurrences of the Keywords >> header field are not permitted. >> >> comments = "Comments:" SP unstructured CRLF >> >> keywords = "Keywords:" SP phrase *("," phrase) CRLF >> >> reply-to = "Reply-To:" SP address-list CRLF >> >> sender = "Sender:" SP mailbox CRLF >> >> The MIME header fields MIME-Version, Content-Type, Content-Transfer- >> Encoding, Content-Disposition, and Content-Language are used in >> Netnews articles in the same circumstances and with the same meanings >> as those specified in [RFC2045], [RFC2183], and [RFC3282], with the >> added restrictions detailed above in Section 2.2. >> >> >> Thanks, >> > > _______________________________________________ > Ietf-message-headers mailing list > Ietf-message-headers@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-message-headers > From nobody Mon May 16 08:57:15 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425D512D6F3 for ; Mon, 16 May 2016 08:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] 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 LPsrTMXt-uEZ for ; Mon, 16 May 2016 08:57:09 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EB0612D70D for ; Mon, 16 May 2016 08:57:06 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d07 with ME id v3x01s00G17Lgi4033x1uj; Mon, 16 May 2016 17:57:04 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWVAd2FuYWRvby5mcg== X-ME-Date: Mon, 16 May 2016 17:57:04 +0200 X-ME-IP: 92.170.5.52 To: "apps-discuss@ietf.org" , ietf-message-headers@ietf.org, usefor@ietf.org References: <573572C7.4020408@ninebynine.org> <9ea7e62b-9a21-1102-eb3e-e12b574b9e89@trigofacile.com> <573982D3.1090106@ninebynine.org> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <44513b01-a7fa-5db7-2461-d703ff9ddb9d@trigofacile.com> Date: Mon, 16 May 2016 17:57:00 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <573982D3.1090106@ninebynine.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Graham Klyne Subject: Re: [apps-discuss] Changes to netnews header registrations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 15:57:10 -0000 Hi Graham, > TL;DR: I don't propose to recommend the additional changes you suggest > as I'm not seeing that they really contribute to the purpose of the > registry (cf. https://tools.ietf.org/html/rfc3864#section-2.2.2). OK, Content-* header fields used by netnews are not supposed to be registered. Yet, is it the same for MIME-Version, that is not mentioned in neither Section 1 nor Section 2.2.2 of RFC3864? > 2. With reference to the X-headers you mention, I see little point in > adding new, non-standard headers to the registry simply to indicate they > are now obsolete. (There could be a case for doing this if they are in > widespread use, but I think that should be a separate discussion, and a > new RFC with its own IANA considerations section. I suspect it's not > worth the effort!) It depends on when we can say a header field is "wide-spread". I've just had a look in two newsgroups: * last 1043 messages (roughly October 2014-May 2016) in news.software.nntp: 391 (37%) contain X-Trace 216 (21%) contain X-Complaints-To * last 1437 messages (roughly August 2014-May 2016) in soc.culture.french: 612 (43%) contain X-Trace 97 (7%) contain X-Complaints-To Of course wider stats should be done because the generation of these headers depend on the news servers the users connect to. X-Trace seems in wide-spread use, though. I agree that writing a new RFC to just obsolete it is probably not worth the effort. However, maybe X-Trace (and maybe other headers) could be added in IANA considerations section of an update of RFC 5536 if we ever move it to Draft Standard? -- Julien ÉLIE « La différence entre un chanteur et une paire de chaussures est que le chanteur doit partir avant de lasser. La paire de chaussures, il vaut mieux les lacer avant de partir. » (Philippe Geluck) From nobody Thu May 19 23:37:05 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBAB12B013 for ; Thu, 19 May 2016 23:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 rA9zuODW0uja for ; Thu, 19 May 2016 23:37:03 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 E878F12D6B5 for ; Thu, 19 May 2016 23:37:02 -0700 (PDT) Received: by mail-ig0-x235.google.com with SMTP id l10so4282429igk.0 for ; Thu, 19 May 2016 23:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=h2oxZfHgKX8shKDZtka13rmYYlDP6J9QiyWSkEuCitU=; b=Lgz27X/Vyjk517Z0FTvxvnGzN3oYuv5RzbqGCdUfgNoWNzlBm/xuCVXnvkGVqng5NU /qjDSYG2IHeg3I5f+ORGW0ttw1+FsIjy2g2WabhiqnBr6so+R78KaybxHMIJn5K7Yblt 9iGzqHk6GduBIGumjp0QrUCNIRt+F8KID3g1HFzld3PcJLz9zFgfP3LsGbAEyo/p3R7M MRDlNw/Yt5UB+mn4j9ukkGkR89TFJy962dZ/bL16H3Q1Ya/KbIpeLdB8jo3fYGLFXM2K OFEXHzdEr54UyjrJ3o7URHv/ntV3Tsox57eyYNj95PIFKaa1PYEhJZGpkWMqJN5MO7eG DoWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=h2oxZfHgKX8shKDZtka13rmYYlDP6J9QiyWSkEuCitU=; b=GwutWSH8b923PfjesHtHPMMnnxTTLIFOE4r41+TKGT9g7/7CenIckB0yhL/KqTS8/r R6L5xNxguX/80lmqQ6IFYe2VXYQ7DkxUpbup0dpjzba0Uny0UA/4CtMT3ko/20k0diA6 ZxvEaSAERd+NmFNk/1HyUCe5QUdyCoiFjoIRVCWbJmpJyEjZqHqWGeZngxbdnTVO0vHa JNv6qF4M4KIQmG0xY1chLGw2cBgRywGODWkXkivQB6nrNi07t40viBcJnKwPpiOWfO5Q rGKerRIezCU7HHQ+a93dMnavJV01v20WKUMQcxCJfYwf5C3A2PQ7d+4/9T6NgkqZqE04 naFw== X-Gm-Message-State: AOPr4FXT+XnBolWXnqYmNrfXKE/m3XFpIzMKXj7ERLVQpBreovzU0dhQRfoEFWFirw5lX/95l8FI1aiS3nwopQ== MIME-Version: 1.0 X-Received: by 10.50.183.132 with SMTP id em4mr1429161igc.50.1463726222253; Thu, 19 May 2016 23:37:02 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.138.160 with HTTP; Thu, 19 May 2016 23:37:02 -0700 (PDT) In-Reply-To: References: <20160515051508.2444.90815.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2016 16:37:02 +1000 X-Google-Sender-Auth: 6wT28MsReMME9kEJ9IZNGXUL-Eg Message-ID: From: Matthew Kerwin To: Mark Nottingham Content-Type: multipart/alternative; boundary=14dae9340c9586bbf9053340515a Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-09.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 06:37:05 -0000 --14dae9340c9586bbf9053340515a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mark, On 16 May 2016 at 17:06, Mark Nottingham wrote: > Hi Matthew, > > I think the new Section 4 is an improvement -- much more precise than it > was. However, a few questions still linger for me: > > > 4. File Name Encoding > > > > File systems use various encoding schemes to store file and director= y > > names. Many modern file systems encode file and directory names as > > arbitrary sequences of octets, > > This is a bit confusing -- perhaps s/encode/store/ ? Or remove this part > of the sentence altogether? > > =E2=80=8BI'll think about what I'm trying to say here, and how it could be = said better. Your suggestion is probably right. > > in which case the representation as an > > encoded string often depends on the user's localization settings, or > > defaults to UTF-8 [STD63]. > > > > Without other encoding information, percent-encoded octets in a file > > URI ([RFC3986], Section 2.1) MAY be interpreted according to the > > preferred or configured encoding of the system on which the URI is > > being interpreted. > > > Do the current implementations of file:// do this -- i.e., use the > filesystem's encoding for the URI? > > =E2=80=8BApparently. I don't have a spare drive lying around where I can re= format a partition to test it for myself, though. A discussion I had with Dave Thaler back at the very start of this draft revolved around the fact that percent-encoded URIs are ambiguous (apparently a real issue for Windows), which was why for a very long time the draft contained advice to use an IRI=E2=80=8B instead, or at the least normalize. > Doing it that way seems unfortunate; two different users on the same > machine (or network) won't see good interop in this approach. > > If it's this way intentionally, or if we think it can't change, that's > understandable, but if not we should have a good hard look at changing it > IMO. > > Has there been any discussion of this to date (sorry if I missed it)? > > A fair bit of discussion on what the draft should say (for example http://www.ietf.org/mail-archive/web/apps-discuss/current/msg14943.html ), not much discussion on whether we should advise URI libraries to update. Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --14dae9340c9586bbf9053340515a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mark,

On 16 May 2016 at 17:06, Mark Nottingham <mnot@mnot.n= et> wrote:
Hi Matthew,

I think the new Section 4 is an improvement -- much more precise than it wa= s. However, a few questions still linger for me:

> 4.=C2=A0 File Name Encoding
>
>=C2=A0 =C2=A0 File systems use various encoding schemes to store file a= nd directory
>=C2=A0 =C2=A0 names.=C2=A0 Many modern file systems encode file and dir= ectory names as
>=C2=A0 =C2=A0 arbitrary sequences of octets,

This is a bit confusing -- perhaps s/encode/store/ ? Or remove this part of= the sentence altogether?


=E2=80=8BI= 9;ll think about what I'm trying to say here, and how it could be said = better. Your suggestion is probably right.

=C2= =A0
>=C2=A0 =C2=A0 in which case the representation as an
>=C2=A0 =C2=A0 encoded string often depends on the user's localizati= on settings, or
>=C2=A0 =C2=A0 defaults to UTF-8 [STD63].
>
>=C2=A0 =C2=A0 Without other encoding information, percent-encoded octet= s in a file
>=C2=A0 =C2=A0 URI ([RFC3986], Section 2.1) MAY be interpreted according= to the
>=C2=A0 =C2=A0 preferred or configured encoding of the system on which t= he URI is
>=C2=A0 =C2=A0 being interpreted.


Do the current implementations of file:// do this -- i.e., use the filesyst= em's encoding for the URI?


=E2=80=8BApparently. I don= 9;t have a spare drive lying around where I can reformat a partition to tes= t it for myself, though. A discussion I had with Dave Thaler back at the ve= ry start of this draft revolved around the fact that percent-encoded URIs a= re ambiguous (apparently a real issue for Windows), which was why for a ver= y long time the draft contained advice to use an IRI=E2=80=8B instead, or a= t the least normalize.

=C2=A0
Doing it that way seems unfortunate; two different users on the same machin= e (or network) won't see good interop in this approach.

If it's this way intentionally, or if we think it can't change, tha= t's understandable, but if not we should have a good hard look at chang= ing it IMO.

Has there been any discussion of this to date (sorry if I missed it)?


A fair bit of discussion on w= hat the draft should say (for example http://www.ietf.org/mail-arc= hive/web/apps-discuss/current/msg14943.html ), not much discussion on w= hether we should advise URI libraries to update.

Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--14dae9340c9586bbf9053340515a-- From nobody Fri May 20 01:55:25 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C908912D599 for ; Fri, 20 May 2016 01:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 DYYwPj-zwnBu for ; Fri, 20 May 2016 01:55:20 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 568D612D0B0 for ; Fri, 20 May 2016 01:55:20 -0700 (PDT) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9F50522E25B; Fri, 20 May 2016 04:55:17 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mark Nottingham In-Reply-To: Date: Fri, 20 May 2016 18:55:15 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <6F0FF7E8-D04B-458E-8E57-3B1257024C09@mnot.net> References: <20160515051508.2444.90815.idtracker@ietfa.amsl.com> To: Matthew Kerwin X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-09.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 08:55:25 -0000 > On 20 May 2016, at 4:37 PM, Matthew Kerwin = wrote: >=20 >> > Without other encoding information, percent-encoded octets in a = file >> > URI ([RFC3986], Section 2.1) MAY be interpreted according to the >> > preferred or configured encoding of the system on which the URI = is >> > being interpreted. >>=20 >>=20 >> Do the current implementations of file:// do this -- i.e., use the = filesystem's encoding for the URI? >=20 >=20 > =E2=80=8BApparently. I don't have a spare drive lying around where I = can reformat a partition to test it for myself, though. A discussion I = had with Dave Thaler back at the very start of this draft revolved = around the fact that percent-encoded URIs are ambiguous (apparently a = real issue for Windows), which was why for a very long time the draft = contained advice to use an IRI=E2=80=8B instead, or at the least = normalize. VMs are good for testing. It appears that both Windows and OSX have used UTF-8 for file name = encoding for some time (since NT for the former, 10.0 for the latter, = AIUI). See: = Linux uses whatever locale is set. However, it appears that both Gnome = and Firefox (at least) try to be 'smart' and will recognise UTF-8 even = if ISO-8859-1 is set as the locale. Having said that, it's not too = smart; if I try to open a file with a UTF-8 encoded name, Firefox can't = find it when the locale isn't UTF-8 (although the file chooser *does* = see it). This is an important point; the advice above that they "MAY be = interpreted according to the preferred or configured encoding of the = system on which the URI is being interpreted" doesn't account for the = fact that a single filesystem might have several users who have = different encodings set*. Other encodings seem to just be percent-encoded straight into the file = URI, and Firefox doesn't make any attempt to display them as IRIs.=20 (This seems to mirror how most browsers handle non-ascii characters in = HTTP headers, e.g., Location; they just percent-encode them, since = that's an encoding of bytes, not characters). Can we say something more like this? ---%<--- When a file URI is produced, characters not allowed by the ABNF MUST be = percent-encoded as characters using UTF-8 encoding, as per RFC3986 = Section 2.5.=20 However, encoding information for file and/or directory names might not = be available. In these cases, implementations MAY use heuristics to = determine the encoding. If that fails, they SHOULD percent-encode the = raw bytes of the label directly. --->%--- Cheers, * Possible but unlikely, since most people are going to be using UTF-8. = Still... -- Mark Nottingham https://www.mnot.net/ From nobody Tue May 24 13:35:34 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9E612D187; Tue, 24 May 2016 13:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 DdTaEAr7FjML; Tue, 24 May 2016 13:35:30 -0700 (PDT) Received: from wursti.dovecot.fi (wursti.dovecot.fi [87.106.245.223]) by ietfa.amsl.com (Postfix) with ESMTP id 7A48B12D16E; Tue, 24 May 2016 13:35:30 -0700 (PDT) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by wursti.dovecot.fi (Postfix) with ESMTPSA id 652C92018D; Tue, 24 May 2016 22:35:29 +0200 (CEST) To: IETF Apps Discuss References: <20160404194931.15658.52837.idtracker@ietfa.amsl.com> <5702CD0C.9010204@dovecot.fi> From: Stephan Bosch Message-ID: <1c6e0c45-2a9f-58b9-7e03-2da7bb8b3484@dovecot.fi> Date: Tue, 24 May 2016 22:34:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5702CD0C.9010204@dovecot.fi> Content-Type: multipart/alternative; boundary="------------87A8C4A203248961F942CCB1" Archived-At: Cc: Sieve mailing list Subject: Re: [apps-discuss] SPECIAL-USE (RFC 6154) in Sieve (RFC 5228): draft-bosch-sieve-special-use-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 20:35:33 -0000 This is a multi-part message in MIME format. --------------87A8C4A203248961F942CCB1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi, Just a friendly reminder: Op 4/4/2016 om 10:22 PM schreef Stephan Bosch: > Currently, the Sieve language (RFC 5228) lacks the means of freely accessing the IMAP special-use mailbox attributes (RFC 6154). For example, it would be nice to be able to determine what the Junk mailbox is during Sieve processing at delivery, based on which mailbox has the "\Junk" special-use attribute assigned. > > I created a draft specification that adds this functionality. I posted this before on the IETF Sieve mailing list (affiliation updated). A few people expressed their interest there already. I was told that the apps-discuss mailing list is still the best venue for putting this document forward. Now that the draft submission is reopened, I have submitted it. The announcement of the submission is attached. > > Please tell me what you think. Document is here: https://datatracker.ietf.org/doc/draft-bosch-sieve-special-use/ Any comments are appreciated! Regards, Stephan. -- Stephan Bosch Senior Developer Phone: +49 2761 75252 00 Fax: +49 2761 75252 30 Email: stephan.bosch@dovecot.fi ------------------------------------------------------------------------------------- Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Uwe Reumuth Chairman of the Board: Richard Seibt Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland Managing Director: Markku Kenttä Chairman of the Board: Timo Sirainen Board Member: Carsten Dirks ------------------------------------------------------------------------------------- --------------87A8C4A203248961F942CCB1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi,

Just a friendly reminder:

Op 4/4/2016 om 10:22 PM schreef Stephan Bosch:
Currently, the Sieve language (RFC 5228) lacks the means of freely accessing the IMAP special-use mailbox attributes (RFC 6154). For example, it would be nice to be able to determine what the Junk mailbox is during Sieve processing at delivery, based on which mailbox has the "\Junk" special-use attribute assigned.

I created a draft specification that adds this functionality. I posted this before on the IETF Sieve mailing list (affiliation updated). A few people expressed their interest there already. I was told that the apps-discuss mailing list is still the best venue for putting this document forward. Now that the draft submission is reopened, I have submitted it. The announcement of the submission is attached. 

Please tell me what you think.

Document is here:

https://datatracker.ietf.org/doc/draft-bosch-sieve-special-use/

Any comments are appreciated!

Regards,

Stephan.




-- 
Stephan Bosch
Senior Developer 


Phone: +49 2761 75252 00  Fax: +49 2761 75252 30
Email: stephan.bosch@dovecot.fi


-------------------------------------------------------------------------------------
Open-Xchange AG,  Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Uwe Reumuth 
Chairman of the Board: Richard Seibt

Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland
Managing Director: Markku Kenttä
Chairman of the Board: Timo Sirainen
Board Member: Carsten Dirks

-------------------------------------------------------------------------------------
--------------87A8C4A203248961F942CCB1-- From nobody Wed May 25 13:08:58 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA05312D9EE for ; Wed, 25 May 2016 13:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 cMLsA-DXT39a for ; Wed, 25 May 2016 13:08:54 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 728E412D7E8 for ; Wed, 25 May 2016 13:08:54 -0700 (PDT) Received: from [156.106.229.0] ([156.106.229.0]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u4PK8q0t011504 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 May 2016 16:08:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1464206933; bh=ahisYVi8iBNKHL5NQfiueZGkk5pi06Ob6D67oNG3Fm8=; h=From:To:Subject:Date:Reply-To; b=ffxYCcsxk5JbOm2RvuHpPREmJLBvcdLQDp0LdwP300dIhHEq91h+//HYTyh0tqFln +W5urlkjORZ1zxKqtpDXqsGss0NexIftbR+HknqzsfGWfUr1XsIVKuuMQD9CsE1VPY kmjf1QKqFAelowlblZL6m7DwubgVkeB/p7UxpqaQ= From: "Paul E. Jones" To: apps-discuss@ietf.org Date: Wed, 25 May 2016 20:08:53 +0000 Message-Id: User-Agent: eM_Client/6.0.24928.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBF38684CC-E36E-4B63-A3E6-8D06849DA21B" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Wed, 25 May 2016 16:08:53 -0400 (EDT) Archived-At: Subject: [apps-discuss] RFC 1738 is made obsolete by what? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 20:08:57 -0000 --------=_MBF38684CC-E36E-4B63-A3E6-8D06849DA21B Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Folks, RFC 1738 has been made obsolete, but the data that the RFC editor is=20 provided (and as shown on tools) is that this document was made obsolete= =20 by the telnet and gopher URL schemes. Surely that wasn't the message=20 that was intended to be conveyed. See:=20 https://tools.ietf.org/html/rfc1738. Wouldn't it be correct to say that this was made obsolete by 2396, which= =20 was then made obsolete by 3986? If I'm correct, then I think the "Obsoleted By" information is=20 misleading. If I'm wrong, then I'm entirely confused and I still assert= =20 that it's misleading :-) Is there a process to clarify this? Paul --------=_MBF38684CC-E36E-4B63-A3E6-8D06849DA21B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Folks,
 
RFC 1738 has been made obsolete, but the data that the RFC editor is= provided (and as shown on tools) is that this document was made obsolete= by the telnet and gopher URL schemes.  Surely that wasn't the message= that was intended to be conveyed.  See: https://tools.ietf.org/html/rfc1738.
 
Wouldn't it be correct to say that this was made obsolete by 2396, = which was then made obsolete by 3986?
 
If I'm correct, then I think the "Obsoleted By" information is mislead= ing.  If I'm wrong, then I'm entirely confused and I still assert that= it's misleading :-)
 
Is there a process to clarify this?
 
Paul
 
--------=_MBF38684CC-E36E-4B63-A3E6-8D06849DA21B-- From nobody Wed May 25 14:16:29 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2EB12D109 for ; Wed, 25 May 2016 14:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 uXOYvl5lUsM1 for ; Wed, 25 May 2016 14:16:26 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 ABD1012DD88 for ; Wed, 25 May 2016 14:16:23 -0700 (PDT) Received: by mail-ig0-x233.google.com with SMTP id fh2so36049564igd.1 for ; Wed, 25 May 2016 14:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=LW8q6xS0miMvfmy7tNHHHf2z63Q2aLGFssI5Z/tYA2o=; b=iaku4tYx1IVYSgihJWXR+Ld2yxkKFHt8w77a1EciYaEwjNrT+iquVrZgkEZV2GcAzi zUxBBq7HB6QLRg6CNzUaXVdUMoZx2JlLOOXotwyObgGZrrZEhsD9OauigNMt3JqhUlKZ ons+bOxyEFVqNnga0gOo6Hxwr4NG6HetSH/i5Xib2+qEQwcoGRTE6xa8xoG8Yec4ZGO/ D4mTxOWPXxIK+CWo4/rcGTEnX5w9qxI62huhdcgpNi0aqlbWqXpk3cY6dyaWQi1Z9vzm 1d2tjWxrDhcsgqVtAsk8yAVxcyD3NcJ+yOngFp8dDrBAucIfN/4DvUM3tUxlV/TC7H/O fmbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=LW8q6xS0miMvfmy7tNHHHf2z63Q2aLGFssI5Z/tYA2o=; b=K65dt30U1e2idUfRkF76EouowiXtld7erVFKuCjnWjelLQUIC5oNe+yYiAX3PYg+vM jnP2A7HwFlMIdBGqM/tyBP/drYzkRl5c+CrW7pFfIg5vLcYGrd+SLiMB51NtdotQk0MM sG6HhYRKbxmplMe1wjOHiys5UQizckBRcuJrvhGsCCpZE20MDc8N8IwJ7MBGfVkvo1FC IQ6FNm4NSzx//zI0QxBnMR4JEiH+Qk8zdBoSJLHZ0280xpGOJNGiEVgJ5sFZpUw7k/+E lx0CqSIDcKlq/dvmbCcJBqWKS+0NwBCLHArXdmOzT1dVdmzBcqVvZzG2fAez/HXOLH9m jxbg== X-Gm-Message-State: ALyK8tIEQzv5RBFYASKfsfbHci9OcaUPKogLORL8ciG34aZmjIGpw0VI75gwFTFuXFQApK426RIWGsd3x+vAlw== MIME-Version: 1.0 X-Received: by 10.50.29.39 with SMTP id g7mr43835igh.50.1464210983024; Wed, 25 May 2016 14:16:23 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.138.160 with HTTP; Wed, 25 May 2016 14:16:22 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 May 2016 07:16:22 +1000 X-Google-Sender-Auth: DtxM8TeZ0EAxFWHvSZ3YspsOB2Y Message-ID: From: Matthew Kerwin To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=047d7bd758cc8523020533b12fda Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RFC 1738 is made obsolete by what? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 21:16:28 -0000 --047d7bd758cc8523020533b12fda Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 26 May 2016 at 06:08, Paul E. Jones wrote: > Folks, > > RFC 1738 has been made obsolete, but the data that the RFC editor is > provided (and as shown on tools) is that this document was made obsolete = by > the telnet and gopher URL schemes. Surely that wasn't the message that w= as > intended to be conveyed. See: https://tools.ietf.org/html/rfc1738. > > Wouldn't it be correct to say that this was made obsolete by 2396, which > was then made obsolete by 3986? > > If I'm correct, then I think the "Obsoleted By" information is > misleading. If I'm wrong, then I'm entirely confused and I still assert > that it's misleading :-) > > Is there a process to clarify this? > > Paul > > =E2=80=8BIt'd be good to find this out. I have in my archives a brief discu= ssion we had on 2013-06-26 about this very issue. It was never resolved cleanly, and so we find ourselves here today with my file: draft which says it obsoletes an already obsolete RFC even though it only replaces one sub-section thereof (=C2=A73.10, about half a page of RFC 1738) -- like telnet and goph= er. I wouldn't be surprised if this piece of metadata ends up being a bit of a blocker, so it'd be good to get it straightened up. Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --047d7bd758cc8523020533b12fda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 26 May 2016 at 06:08, Paul E. Jones &= lt;paulej@packet= izer.com> wrote:
Folks,
=C2=A0
RFC 1738 has been made obsolete, but the data that the RFC editor is p= rovided (and as shown on tools) is that this document was made obsolete by = the telnet and gopher URL schemes.=C2=A0 Surely that wasn't the message= that was intended to be conveyed.=C2=A0 See: https://tools.ietf.org/html/rfc1738.
=C2=A0
Wouldn't it be correct to say that this was made obsolete by 2396,= which was then made obsolete by 3986?
=C2=A0
If I'm correct, then I think the "Obsoleted By" informat= ion is misleading.=C2=A0 If I'm wrong, then I'm entirely confused a= nd I still assert that it's misleading :-)
=C2=A0
Is there a process to clarify this?
=C2=A0
Paul


--
--047d7bd758cc8523020533b12fda-- From nobody Wed May 25 15:05:47 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2112512DDD8 for ; Wed, 25 May 2016 15:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 IuqJvyyCKASN for ; Wed, 25 May 2016 15:05:44 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 AF5B012D56F for ; Wed, 25 May 2016 15:05:44 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id z123so36866761itg.0 for ; Wed, 25 May 2016 15:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=Ob5QkxQ2cC8DJ/eTMtV3IMW6GL3y8BYO27/5zQSJZH8=; b=oaRsCw4l+2DI6J0MnQaltEppdmGKCGdZHoPloZEQ/8oDiKqvMdUor3Yb5pQFHMrHXf WKdYVYcNoPVXZrKqsYXo78EsK9gPozYkuPQEQ99ogMdk2GXx8jVUqkDONAlnwEHqWJTG aC+WGVMzpDNFPrZQyOWmLtxVeYyiJ1R/8IPaDsnjeAcuoOIrU0FiSP7EYFLkEyfy+rAt KUj3IrLvptx2QPRG+Q6Zhk/2KxtBkdfkm1KOkXsFHKgAjv4e4OLIEVckvC3SoRWUVH5R cVQn2lg8sxtg3X8v5bMx3eIVHI3Bad+ZXOvej3H5GPO2DZaoYQrdfzA6P/ivAy8RObXx /5nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Ob5QkxQ2cC8DJ/eTMtV3IMW6GL3y8BYO27/5zQSJZH8=; b=IlGkxkIM2EeUshtMzTsiXagjP0mDpAMnIxk2ynEEIc9sbW9xh/Kh26dchE2rhxI16e YmVrhix12nikLw0MnzuPhULFE2BTTrU7NONrWr03inj06At6IhuiOWFvkQt6Prs/VGMz m5LT3uoeusDx/DYS11MIzHEa6ZW2s8fV2zMdLWgLeuoSqf+5sIEQoj8FR30oTTF+v7gx ZqnycmfPq17CPgysLlKBcos8ncxXl3uuQ9sWJ43HmwHMlVs45DZGfslTDbxOARVMq2gZ hcNQBepJ6DYOe0D3EAMbBT+deyAd1u+SPjV61DRfPPwl5TjG4I1UhEW3JCrEEzKKRAC4 vdkA== X-Gm-Message-State: ALyK8tLf6jWyOKeg6hni/Rk0gbNWEJvGuHlkU8R/DwUozIVWFaOnO6cyFhYN6oK8xy0HYga80ibLu2x76RnLDQ== MIME-Version: 1.0 X-Received: by 10.36.65.168 with SMTP id b40mr204352itd.10.1464213944078; Wed, 25 May 2016 15:05:44 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.138.160 with HTTP; Wed, 25 May 2016 15:05:44 -0700 (PDT) In-Reply-To: <6F0FF7E8-D04B-458E-8E57-3B1257024C09@mnot.net> References: <20160515051508.2444.90815.idtracker@ietfa.amsl.com> <6F0FF7E8-D04B-458E-8E57-3B1257024C09@mnot.net> Date: Thu, 26 May 2016 08:05:44 +1000 X-Google-Sender-Auth: XgwzhAv-uoEqXV9p3Jp_iwCOEkk Message-ID: From: Matthew Kerwin To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a11351f660331e90533b1e046 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-09.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 22:05:46 -0000 --001a11351f660331e90533b1e046 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mark, sorry for sitting on this for another week. I've been called up for jury duty. On 20 May 2016 at 18:55, Mark Nottingham wrote: > > > On 20 May 2016, at 4:37 PM, Matthew Kerwin > wrote: > > > >> > Without other encoding information, percent-encoded octets in a > file > >> > URI ([RFC3986], Section 2.1) MAY be interpreted according to the > >> > preferred or configured encoding of the system on which the URI i= s > >> > being interpreted. > >> > >> > >> Do the current implementations of file:// do this -- i.e., use the > filesystem's encoding for the URI? > > > > > > =E2=80=8BApparently. I don't have a spare drive lying around where I ca= n > reformat a partition to test it for myself, though. A discussion I had wi= th > Dave Thaler back at the very start of this draft revolved around the fact > that percent-encoded URIs are ambiguous (apparently a real issue for > Windows), which was why for a very long time the draft contained advice t= o > use an IRI=E2=80=8B instead, or at the least normalize. > > VMs are good for testing. > > =E2=80=8BBut some operating systems don't come cheap, if you don't happen t= o already have a Windows VM to hand. ;)=E2=80=8B > It appears that both Windows and OSX have used UTF-8 for file name > encoding for some time (since NT for the former, 10.0 for the latter, > AIUI). See: < > https://docs.python.org/3/library/sys.html#sys.getfilesystemencoding> > =E2=80=8BI thought NTFS used UCS2 for storing file and directory names; and= the Windows API functions I've seen (like PathCreateFromURL) return either UCS2 or Windows-1252 strings, depending on how you use them. I can't speak to HFS+.=E2=80=8B > > Linux uses whatever locale is set. However, it appears that both Gnome an= d > Firefox (at least) try to be 'smart' and will recognise UTF-8 even if > ISO-8859-1 is set as the locale. Having said that, it's not too smart; if= I > try to open a file with a UTF-8 encoded name, Firefox can't find it when > the locale isn't UTF-8 (although the file chooser *does* see it). > > This is an important point; the advice above that they "MAY be interprete= d > according to the preferred or configured encoding of the system on which > the URI is being interpreted" doesn't account for the fact that a single > filesystem might have several users who have different encodings set*. > > =E2=80=8BNot explicitly, although I had it in mind when I wrote it. Maybe y= our "heuristics" bit below covers it well enough.=E2=80=8B > Other encodings seem to just be percent-encoded straight into the file > URI, and Firefox doesn't make any attempt to display them as IRIs. > > (This seems to mirror how most browsers handle non-ascii characters in > HTTP headers, e.g., Location; they just percent-encode them, since that's > an encoding of bytes, not characters). > > Can we say something more like this? > > ---%<--- > When a file URI is produced, characters not allowed by the ABNF MUST be > percent-encoded as characters using UTF-8 encoding, as per > =E2=80=8B=E2=80=8B > RFC3986 Section 2.5. > > =E2=80=8BThat's strengthening the requirement. RFC3986 =C2=A72.5 only says = that: if characters are part of UCS they "should first be encoded" as UTF-8 before being percent-encoded. The MUST-level requirement is just that octets not allowed by the ABNF must be percent-encoded. > However, encoding information for file and/or directory names might not b= e > available. In these cases, implementations MAY use heuristics to determin= e > the encoding. If that fails, they SHOULD percent-encode the raw bytes of > the label directly. > =E2=80=8BThis says this part well.=E2=80=8B > --->%--- > > Cheers, > > > * Possible but unlikely, since most people are going to be using UTF-8. > Still... > > =E2=80=8BCheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11351f660331e90533b1e046 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mark, sorry for sitting on this for another we= ek. I've been called up for jury duty.
=
On 20 May 2016 at 18:55, Mark Nottingham <mnot@= mnot.net> wrote:

> On 20 May 2016, at 4:37 PM, Matthew Kerwin <matthew@kerwin.net.au> wrote:
>
>> >=C2=A0 =C2=A0 Without other encoding information, percent-enco= ded octets in a file
>> >=C2=A0 =C2=A0 URI ([RFC3986], Section 2.1) MAY be interpreted = according to the
>> >=C2=A0 =C2=A0 preferred or configured encoding of the system o= n which the URI is
>> >=C2=A0 =C2=A0 being interpreted.
>>
>>
>> Do the current implementations of file:// do this -- i.e., use the= filesystem's encoding for the URI?
>
>
> =E2=80=8BApparently. I don't have a spare drive lying around where= I can reformat a partition to test it for myself, though. A discussion I h= ad with Dave Thaler back at the very start of this draft revolved around th= e fact that percent-encoded URIs are ambiguous (apparently a real issue for= Windows), which was why for a very long time the draft contained advice to= use an IRI=E2=80=8B instead, or at the least normalize.

VMs are good for testing.


=E2=80=8BBut some operating s= ystems don't come cheap, if you don't happen to already have a Wind= ows VM to hand. ;)=E2=80=8B

=C2=A0
It appears that both Windows and OSX have used UTF-8 for file name encoding= for some time (since NT for the former, 10.0 for the latter, AIUI). See: &= lt;https://docs.python.org/3/lib= rary/sys.html#sys.getfilesystemencoding>

=E2=80=8BI thought NTFS used UCS2 for storing file and di= rectory names; and the Windows API functions I've seen (like PathCreate= FromURL) return either UCS2 or Windows-1252 strings, depending on how you u= se them. I can't speak to HFS+.=E2=80=8B

=C2=A0

Linux uses whatever locale is set. However, it appears that both Gnome and = Firefox (at least) try to be 'smart' and will recognise UTF-8 even = if ISO-8859-1 is set as the locale. Having said that, it's not too smar= t; if I try to open a file with a UTF-8 encoded name, Firefox can't fin= d it when the locale isn't UTF-8 (although the file chooser *does* see = it).

This is an important point; the advice above that they "MAY be interpr= eted according to the preferred or configured encoding of the system on whi= ch the URI is being interpreted" doesn't account for the fact that= a single filesystem might have several users who have different encodings = set*.


=E2=80=8BNot explicitly, alth= ough I had it in mind when I wrote it. Maybe your "heuristics" bi= t below covers it well enough.=E2=80=8B

=C2=A0
Other encodings seem to just be percent-encoded straight into the file URI,= and Firefox doesn't make any attempt to display them as IRIs.

(This seems to mirror how most browsers handle non-ascii characters in HTTP= headers, e.g., Location; they just percent-encode them, since that's a= n encoding of bytes, not characters).

Can we say something more like this?

---%<---
When a file URI is produced, characters not allowed by the ABNF MUST be per= cent-encoded as characters using UTF-8 encoding, as per
=E2=80=8B=E2=80=8B
RFC3986 Section 2.5.


=E2=80=8BThat's strengthe= ning the requirement. RFC3986 =C2=A72.5 only says that: if characters are p= art of UCS they "should first be encoded" as UTF-8 before being p= ercent-encoded. The MUST-level requirement is just that octets not allowed = by the ABNF must be percent-encoded.

=C2=A0
However, encoding information for file and/or directory names might not be = available. In these cases, implementations MAY use heuristics to determine = the encoding. If that fails, they SHOULD percent-encode the raw bytes of th= e label directly.

=E2=80=8BThi= s says this part well.=E2=80=8B

=C2=A0
--->%---

Cheers,


* Possible but unlikely, since most people are going to be using UTF-8. Sti= ll...


=E2=80=8BCheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a11351f660331e90533b1e046-- From nobody Thu May 26 09:23:16 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953E612D74F for ; Thu, 26 May 2016 09:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 HJpixvmtgr4W for ; Thu, 26 May 2016 09:23:13 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0739.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::739]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFC912D70E for ; Thu, 26 May 2016 09:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8kFFKom8bbHe2K/hOOLTAA+oqwlwUCPQwjepRlHKC6o=; b=FFKMSWyJrmRnIOPmSZ3SeUNQq3+o9K+CbEdxOO8YaMtBx/Y5ysUWTdQEaD4DQdmmHNeqj8MgmaIiXd8cAlYjUSQCBAy3R7admG8uzUaI8qCOMLJXzFlTk1JuVY+DqNDd8xWPN4alsMPrnyWxbXZNUe+4ezznKRnsH/RRs4EtxpE= Authentication-Results: kerwin.net.au; dkim=none (message not signed) header.d=none;kerwin.net.au; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (109.145.193.232) by DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) with Microsoft SMTP Server (TLS) id 15.1.501.7; Thu, 26 May 2016 16:22:53 +0000 Message-ID: <02f701d1b76a$4bb62660$4001a8c0@gateway.2wire.net> From: t.petch To: Matthew Kerwin , "Paul E. Jones" References: Date: Thu, 26 May 2016 17:18:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.145.193.232] X-ClientProxiedBy: DB5PR03CA0051.eurprd03.prod.outlook.com (10.164.34.19) To DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) X-MS-Office365-Filtering-Correlation-Id: bff82420-acdd-4bca-10fa-08d38581fd39 X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 2:fx6fSAS10DO5nLlk7CylrTpXmZfsemhQTWcmPTXm3aHN4eF5YQiUgh6JMMmDYkngmYCOgypypo6uzD3FsHf0Pot0moSP8d9WtPHvJdoAlefR5AjyUGam7QcTKN7aG2+HYpO+yIlQnjC00Aod3NurJG56ygh9fwXLkUz+NHov6OdEp+GCRhQY18OBa+h6P1BP; 3:XQtZfpz7QL1uQpixWzd1Q5RFp8njjidIFqNkcqTQY2LPSC4Jq2bC2pGg2ZsrOGB/uaG/cPFTFrwFl+8eAIsKeWOKyllLYYtNJfhIH6OV/APKx5ibORzRARcts1/9q5Bq; 25:6kEUmNfDc7s6h3Ap2lGKX1V/Ni0AvwRsWRV4Vt95FuLkcbKiQ0jX4SBfvmozAXeCGfci/rL9kOdlQNGqiYRqCkNwec+4U15//TUzXtFafdNUNbTLAYqMwRVC4jBuoiMEzhm9tD9Yya6nKUVCPELgwF8S5B8vlocafEuMWrrq/FAk4cwxhJFayRUFPEm+YJwS5SSKB1wSFcwTqE/wT6gpI2V5R+gQCehG68+UpgQSXTJIjl5FF730NuVnEEBCwMWolh2U0qDCcn7tKuoJx6063OP9ls2CCbtyxn/n+OkTKo0BSrtnbAt0CncKcNg4jClW9g3de5uSXX4Yg9CxiUYQVo8W6/6Ifr085fUDuqjt32To8FI4svRjGZyeqoMSIroKxrPnF6rYZsW4imHntPtzZYsMFwCLRPBNsBpr+x4DCcg= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1622; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB5PR07MB1622; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1622; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 4:jn5Jzpzs0hAi5B7/c8JDx8h9b7vL6wVHKlyAU/ub1GrZJFcenUbKQL8/VtMpvMKLbdQXGF/opLtrS/z+zYmxl3tW8gA04B/8HGqHXtiAaiiievrQq3AK/TM9GlrRC9iRIkVtHit1hZ9srY8OkUpKmFSxmTB/LpbHBMSV93ti96+87EqKHvpDhz4koPaRRxdk5RrFhZQkKxaf8T9qvo9XpnZClbprwW4I87I6XcEuY+hsDx0KyJXyQ0/eIlYpmsO1XtjnWR3M+hT9bJi9uMT9dxALueg3rMfOC19t6HlHgL/tpQ3DlG5ImXq6EZ/4/dMZBEOfLDxeGcf50dQG76cfzviRs726S4yNTProVt5dM1MsP2go/okyL+ynatUstK7A X-Forefront-PRVS: 0954EE4910 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(377454003)(24454002)(377424004)(47776003)(5001770100001)(44736004)(189998001)(62236002)(81166006)(84392002)(14496001)(4326007)(9686002)(66066001)(2906002)(116806002)(50226002)(1456003)(8676002)(81686999)(81816999)(77096005)(76176999)(586003)(86362001)(1556002)(19580405001)(5008740100001)(42186005)(15975445007)(61296003)(33646002)(19580395003)(92566002)(3846002)(50986999)(50466002)(6116002)(2870700001)(5004730100002)(44716002)(23676002)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1622; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA3TUIxNjIyOzIzOnFxK3FsMytSeW03MGNGVUVaS2FoNkpDbjU3?= =?utf-8?B?bzUxQTJHalJUYUFOS0FiSDQ5RFFBZ1R5ZmhMdHVWVHVFL25tTkZFUlFFZmtP?= =?utf-8?B?VFd4bkJjaVp4bHBYQ3M1MHhiMUhsa25XSVFPb3lJQXBTc09nZXBibW9lNnM0?= =?utf-8?B?WWZyNURCbW5CemNmU1NORVBhZ241SzJBSEwxSmhGUjl3UzJJSEpGK2t5dURE?= =?utf-8?B?cTM1aVZlU2QxL1AwMkFMaFV4SU9uQlBINWtsM1o5aUVaNjVxREpFUEZnVGY4?= =?utf-8?B?MkdzczIwZkRMdi9JTTRVMXh4bjFFbUJabXhCWXFOKzBnOUkySkNhNkFmNWx4?= =?utf-8?B?UnJmOVdRQWhIMDhzVk5QWkJsUmplaEdTSG9mbEpnUmVheGtKU0RKc3B3eUpt?= =?utf-8?B?WVRRKytYQ25KZnp4dWZocVdxSHA3Wi93S0dMWkh3NDhCVXliWVl1OXpJZ28w?= =?utf-8?B?SVJoT2oydFdWbDJ3ZjhYaUF1TkxVRlhLZi9POWVUdk5GMzQvdDZkQkZZN1Bs?= =?utf-8?B?Y1hyNU9obGJxaU9LUjhlMFpmc2FXK1hrZzFKT0ZhMDRzUEx1QkFKRU14Szdh?= =?utf-8?B?dXdSUUVpa2ZmY2hlWHoyTG1Ca00xMFRwMngzL2FSWmlaWE9kclFPNitYYWta?= =?utf-8?B?SWhPcDV2WEIvMWR2cUVuQ2NMZEtqZGYxUjU1SnJLdS96MmdXcDE2MUN3RHNR?= =?utf-8?B?clJTdnVacVRCRFRpU0M0S20xVUtzYkpWNW9nNW9SOWZ1OHorNmQrZktaOVFu?= =?utf-8?B?VGdna2J4eXZIdlBhb25aODNtVGEvcFVFbEswdElDL0RUeDdJYk5SSWZLSG1S?= =?utf-8?B?VkdFbDVxNjEzclJMYWQvTW45R2VNMGJXbXVkejFFYUNUcjFnUjdVN1FRaFhG?= =?utf-8?B?dTA2ZTdvWWVCSzZ6cG1lVXEyNXF0VDY3MThwWlE5TGtZS1ZvSUhOUlIzS2Qx?= =?utf-8?B?WkcybTRIbUFpTkdyb1kvWFU3UzEvVzV4OUpUckx4UEI0Vjlpc2VMN2djR1VZ?= =?utf-8?B?MmlROGlCYXNzaDFicTJpZjRUNW9tQjAyWit0RVVzeUF1QXlHR2FzL29JMVhs?= =?utf-8?B?SGphUzBrTFVkcmFNM3JxYVBBa0xzek1sVUQyK29vY1k5Q29EbzFwLzJ2R0Vj?= =?utf-8?B?RFgzRC9scmxKcFNsWUM0M2RoRnh6VlloTmtISCs2M3Bnc3ptZmt4NWorMUpQ?= =?utf-8?B?NWpFRFZlNTVWY0JYd1dSc3lPZnhNRlV3WkYrL3doc21iREQwZFVmUThwYmdo?= =?utf-8?B?UjM3Q3d2VDRHRm1uZzZnRlU4QVdJYWZDcTlOMVcyeE40RnNxQWwxWG5jYTc4?= =?utf-8?B?ZXRoUXdrUng0anVneENTc2JQcVBROUJMcXRJamliTVEybE5wTnJ4dmFtM2FL?= =?utf-8?B?SkQ1ZUxJL1h1R3V3Z1BVcVF4UzJOM2NXQVhubUlOQkpya0tHRW4rMVlma3Z4?= =?utf-8?B?OEdxRU1MdEFueGJkT1hRSURMNkl1ZkJMa1k2V1VlZEhXekhSRk5UK0V1NW1R?= =?utf-8?B?ODA3eGwxU0NiRVVKZnd0VWkwWnU4ZFJPc09OaFJqWW9PTVhBSDNhYUF5czhG?= =?utf-8?B?MERGRS80eEZNdTdwY1BMalNuT2hLcHhoY3Ixc21JWU9tdHkraElLdHErTlVW?= =?utf-8?B?WGQ0ZFVpRlBJcndHK2sxaTBqYitUQ0xjdFg3MDg4NXY5UldhQ0JMUm9RPT0=?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 5:pLfCkHG4rrn0LisYJa10ma0l9ui6coIu7JXeaz+d740kwaEnM1hVJM87Np1r3UvIfgNDpiB2AcljLePATShYTJaGPcMQuCy+TLoYge6dfsIfwv7GjmtiaWij6WptvZXUWdfVHfVlTG9Lpj17deDnbQ==; 24:DoooTJ72Rm+5E00fTREDbZ30WrGjNTNZz/pLmh+nlnl5AHC5GKowRJkv+N3WgI+teoxlk5bIePnHt2WQ/iPbJ39FuyeXH9UrVo05osEQbzE=; 7:FJwXL99TBoejsIfzHNqruC/hf0+VkwxmmkH95S2rNyLHW0kxXhERSJsvvQjrPudielnDArZoqHvpdKhAOTC/H0/LjufOHPGrpK/TDvOe0VbNODPYBwoLy9ByYqwdWMHz/h8sLMUy9oCUaLVrUnYRFtm1CyJH75OaqPYDnK7VI/teeixP+/eaBZgl0ADmR5ux SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2016 16:22:53.3304 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1622 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RFC 1738 is made obsolete by what? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 16:23:15 -0000 ---- Original Message ----- From: "Matthew Kerwin" To: "Paul E. Jones" Cc: "IETF Apps Discuss" Sent: Wednesday, May 25, 2016 10:16 PM On 26 May 2016 at 06:08, Paul E. Jones wrote: > Folks, > > RFC 1738 has been made obsolete, but the data that the RFC editor is > provided (and as shown on tools) is that this document was made obsolete by > the telnet and gopher URL schemes. Surely that wasn't the message that was > intended to be conveyed. See: https://tools.ietf.org/html/rfc1738. > > Wouldn't it be correct to say that this was made obsolete by 2396, which > was then made obsolete by 3986? > > If I'm correct, then I think the "Obsoleted By" information is > misleading. If I'm wrong, then I'm entirely confused and I still assert > that it's misleading :-) > > Is there a process to clarify this? > > Paul > > ​It'd be good to find this out. I have in my archives a brief discussion we had on 2013-06-26 about this very issue. It was never resolved cleanly, and so we find ourselves here today with my file: draft which says it obsoletes an already obsolete RFC even though it only replaces one sub-section thereof (§3.10, about half a page of RFC 1738) -- like telnet and gopher. I wouldn't be surprised if this piece of metadata ends up being a bit of a blocker, so it'd be good to get it straightened up. Do as RFC6270 did "6270 The 'tn3270' URI Scheme. M. Yevstifeyev. June 2011. (Format: TXT=10876 bytes) (Updates RFC2355, RFC1738, RFC1041) (Status: PROPOSED STANDARD) " Tom Petch Cheers -- Matthew Kerwin http://matthew.kerwin.net.au/ ------------------------------------------------------------------------ -------- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Sun May 29 04:03:34 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CA412D504 for ; Sun, 29 May 2016 04:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 Pf93OiUztqIi for ; Sun, 29 May 2016 04:03:30 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id AC55212D4FD for ; Sun, 29 May 2016 04:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1464519809; d=isode.com; s=selector; i=@isode.com; bh=YH8XlSurpF0PmrTV3s7RIbJvblf6BCZ0bCZytC+FQYE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=PeKNjmWFVeAbkU905MLYe9xvB+zlaB9l8ZcXIAUJ8qKVnmIzBrvbTVXF4g2N27pwHVCElr 5eDvFWUeMW5RcGzsJMo858Gzb2WRyvrGFM3SNXYd4eteJvo1+AxQ8Z93gYXAnZL/JEGKwL L/veSMNE87BA3qDZV+DCprUUtNF4HzU=; Received: from [192.168.0.2] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 29 May 2016 12:03:29 +0100 From: Alexey Melnikov To: "apps-discuss@ietf.org" Message-ID: <574ACC7F.3050304@isode.com> Date: Sun, 29 May 2016 12:03:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Archived-At: Cc: Ben Campbell Subject: [apps-discuss] Clarifications about purpose of apps-discuss mailing list, DISPATCH WG and ART Area meetings X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 11:03:32 -0000 Dear apps-discuss participants, ART ADs realized that certain changes to the combined Area were not communicated properly. In particular: apps-discuss is now the ART-area-wide mailing list. General ART discussions are welcomed here. We are also planning to rename it to art-discuss. (apps-discuss will remain as an alias). Please direct specific new work proposals to dispatch@ietf.org. DISPATCH WG (dispatch@ietf.org) was rechartered to become ART-area wide WG for helping ART ADs with processing documents. So DISPATCH WG is no longer specific to what historically were RAI topics. The main difference between DISPATCH and the way that APPSAWG has worked is that DISPATCH is not allowed to work on documents, unless they are simple IANA registrations. DISPATCH can either recommend AD sponsoring of documents, redirect to an existing WG or would help to charter new WGs to work on a specific topic. The plan is still to close APPSAWG as soon as its pending documents are complete. In the future, the first meeting on Monday morning of each IETF is going to be a combined ART Area meeting with DISPATCH WG meeting. (So effectively DISPATCH has replaced the APPSAWG slot). This might change in the future, but for now this is what ART ADs would like to do. Best Regards, Alissa, Ben and Alexey From nobody Mon May 30 18:24:45 2016 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4551128874; Mon, 30 May 2016 18:24:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531012441.29272.69867.idtracker@ietfa.amsl.com> Date: Mon, 30 May 2016 18:24:41 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-10.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 01:24:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group of the IETF. Title : The file URI Scheme Author : Matthew Kerwin Filename : draft-ietf-appsawg-file-scheme-10.txt Pages : 17 Date : 2016-05-30 Abstract: This document specifies the "file" Uniform Resource Identifier (URI) scheme, replacing the definition in RFC 1738. It defines a common syntax which is intended to interoperate across the broad spectrum of existing usages. At the same time it notes some other current practices around the use of file URIs. Note to Readers (To be removed by the RFC Editor) This draft should be discussed on the IETF Applications Area Working Group discussion list . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 30 18:39:03 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7AD12B04B for ; Mon, 30 May 2016 18:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 2hQ-fp0pvhBh for ; Mon, 30 May 2016 18:38:59 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 D9A2F128874 for ; Mon, 30 May 2016 18:38:58 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id p194so24286782iod.1 for ; Mon, 30 May 2016 18:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=+CjwiEGSZlSAuGnvmuCtIEpEQeUb1SiRX3X5eqHCvXk=; b=OelTyUCppOgsguygQ26x8ONxa4bL+IHLLvEJPPzCo3sfMe5GiC/VGafDkGuqlUYN+c 3JpbIKprX2GT49hQ7dbJhLyrlrdjTkQ5Yj3TE9OqW1Mpxny5ODSlJRv8TW7pwos5fawM yW3bokrX+q6lF7ybyywvToJndWVVcs8c0jLtxH4voc1vqex2XmxMIJHKvpUNzj2LQxkf M2h70tQc65yWxsjFhnkcxwWPpPPUU9AieEJiS2YcQ/uCJdyR9AeClt6C00hex+JqL4M+ u2/LtxH9Oj8pVi7srmpbBvYSxqk5YJ6SFTFx3L3dBI1S4dNbmlbFdfsNqHLwRFx2W2FV iGVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+CjwiEGSZlSAuGnvmuCtIEpEQeUb1SiRX3X5eqHCvXk=; b=RF+Bo6GlpDDnq1pktaH+kTtEyWBKJ42ZwoKsByf/ldTNuJfcjjwqiTCnGMJks/UU2v 46Dtn4iTvesjMqQnE/NdWZU6/cpimKVDG/zIewbKZh4y+GTDHXJ+oLzzN8tv9W+OieCT aWzwqZ0FPEzAhOuTlycPjwdHFTit2rB2qHV7JOjfQVrgP+CrAEy3tyOhlJzA9uqSOUiz oK6lrdkix556+VXXGmvO3kmyvgHij75UYOeQPrJP/jbadaV7Cxal807sG0cV8TRg9VyG O6/EQ0u0SA0GC5+2DkZeLFAwVmuqzBIhER5t+soDvN7lbjHLs6FTpmVRccD2aIvcYn6i FG5Q== X-Gm-Message-State: ALyK8tJ2BaV4P30qsYsnyOdF+IZXO8HWRbWawPn4D3efilg4FI8DwsHcD7i13X4zNiqkR7NVbW3FFbDanjOaJw== MIME-Version: 1.0 X-Received: by 10.107.36.198 with SMTP id k189mr24265688iok.176.1464658738115; Mon, 30 May 2016 18:38:58 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.138.160 with HTTP; Mon, 30 May 2016 18:38:58 -0700 (PDT) In-Reply-To: <20160531012441.29272.69867.idtracker@ietfa.amsl.com> References: <20160531012441.29272.69867.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 11:38:58 +1000 X-Google-Sender-Auth: mEjtBmzSbgEKrnNUVUnaN18YLY4 Message-ID: From: Matthew Kerwin To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a1140ebaacd7ace0534196fcc Archived-At: Cc: Mark Nottingham Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-10.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 01:39:01 -0000 --001a1140ebaacd7ace0534196fcc Content-Type: text/plain; charset=UTF-8 Hi again everyone, This -10 version includes Mark's suggested text for the Encoding section (about the context-sensitivity of percent-encoded octets), and updates some references as requested by Sean. I also changed the metadata to say that this draft s/obsoletes/updates/ RFC 1738, as I believe that's the appropriate advice. Incidentally when updating the references I removed my informative UNC syntax, which eliminated about half a page of appendix and quite a few informative references. If this version sits well with everyone, I just have to make a few small editorial fixes which I've noticed and it should be good to go. Cheers On 31 May 2016 at 11:24, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the ART Area General Applications Working > Group of the IETF. > > Title : The file URI Scheme > Author : Matthew Kerwin > Filename : draft-ietf-appsawg-file-scheme-10.txt > Pages : 17 > Date : 2016-05-30 > > Abstract: > This document specifies the "file" Uniform Resource Identifier (URI) > scheme, replacing the definition in RFC 1738. > > It defines a common syntax which is intended to interoperate across > the broad spectrum of existing usages. At the same time it notes > some other current practices around the use of file URIs. > > Note to Readers (To be removed by the RFC Editor) > > This draft should be discussed on the IETF Applications Area Working > Group discussion list . > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-10 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > -- Matthew Kerwin http://matthew.kerwin.net.au/ --001a1140ebaacd7ace0534196fcc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi again everyone,

This -10 version includes Mark's suggested text for the Encodi= ng section (about the context-sensitivity of percent-encoded octets), and u= pdates some references as requested by Sean. I also changed the metadata to= say that this draft s/o= bsoletes/updates/ RFC 1738, as I belie= ve that's the appropriate advice.

Incide= ntally when updating the references I removed my informative UNC syntax, wh= ich eliminated about half a page of appendix and quite a few informative re= ferences.

If this version sits well with everyone, I= just have to make a few small editorial fixes which I've noticed and i= t should be good to go.

Cheers

On 31 May 2016 at 11:24, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the ART Area General Applications Working Grou= p of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= The file URI Scheme
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Matt= hew Kerwin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-appsawg-file-scheme-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 17
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-05-30

Abstract:
=C2=A0 =C2=A0This document specifies the "file" Uniform Resource = Identifier (URI)
=C2=A0 =C2=A0scheme, replacing the definition in RFC 1738.

=C2=A0 =C2=A0It defines a common syntax which is intended to interoperate a= cross
=C2=A0 =C2=A0the broad spectrum of existing usages.=C2=A0 At the same time = it notes
=C2=A0 =C2=A0some other current practices around the use of file URIs.

Note to Readers (To be removed by the RFC Editor)

=C2=A0 =C2=A0This draft should be discussed on the IETF Applications Area W= orking
=C2=A0 =C2=A0Group discussion list <apps-discuss@ietf.org>.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-ietf-appsawg-file-scheme/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-= appsawg-file-scheme-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-appsawg-file-scheme-10


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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




--
= =C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a1140ebaacd7ace0534196fcc-- From nobody Mon May 30 19:45:08 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57D812D128 for ; Mon, 30 May 2016 19:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 Qb5DmOVfKhR7 for ; Mon, 30 May 2016 19:45:05 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 3381512D13D for ; Mon, 30 May 2016 19:45:05 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id e62so49950879ita.1 for ; Mon, 30 May 2016 19:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=6pVrDutlvi76RJ/JonqgO11vk5hRVyJQwB6St9wjQBo=; b=s9jyK2/5zaRAbEAmusMd7RJcJhkKnk5918CqFmPOaGCj6lbHYI4wKs4YYCxTwAX2ro TCfEluKeDSOc+TrlUuAM+GyKfRmBiy80Ny/vJuzvgtPt2eTOs/XnCRQunYsnqUhB2n47 dPdodWcyWHqkaxYmQyMlpZh2rQgub1kM3GVzSHUbfRiH1nA0pCOpKLYYirYcSw/SpVJ8 NW2YyLeWFL4AJdrUy2QMN+CE+/GE7jdq2JU29vlpbTxnlZ9gHPrTWeRrwQwyOerOwTc2 tStQ7RwZrUvg3WMEQLVtDHooGaxl2V1BUK9ubMEBHpssckvQtP4ugkC2fOBrBTZtejQF mOfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=6pVrDutlvi76RJ/JonqgO11vk5hRVyJQwB6St9wjQBo=; b=m2z9FnU/5Un/OqKn5MSVZ/xodMqiFGxT51AKzLc0bU3CTVGKtB/sSfc5RlIApeugiO anj1tqTKM1xjrZ0iLXUGdm1BnDGlu5WTK2Tx9Z+KKmDnerATzy0tUINBQj0pQrYZemfK q0BB/3cZJBbELr2UUDrjtzsUSVoDTPN5j1OYAx9iH3NdD6A0CItZispg+MdvcNHH8RF7 pD7tWE+7LPnaEpPCX0RjGAbo4lqNAqCIgUqtF67SLmz7+AbMW3RkvxEqOTHmDSJoY15h imF7YpPYnmzFEIxSNRzdZIGvJ6dqeFz1M8koZ/Xt/9s6xexqgVaMWUDDDH8doXnBio79 nnuw== X-Gm-Message-State: ALyK8tL1APej6FWHY4qFqL6/P61xLpHuvlMWpQfPi8sHJ2a7Bw19e3mE3EqNsJYR3K94d1KFGZb8eZ/rap2SLg== MIME-Version: 1.0 X-Received: by 10.36.90.73 with SMTP id v70mr10774280ita.10.1464662704528; Mon, 30 May 2016 19:45:04 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.138.160 with HTTP; Mon, 30 May 2016 19:45:04 -0700 (PDT) In-Reply-To: References: <20160531012441.29272.69867.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 12:45:04 +1000 X-Google-Sender-Auth: PPJ43KlxbYVI9ZpDYPw4Ko44Xz4 Message-ID: From: Matthew Kerwin To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a1143de963825ba05341a5c05 Archived-At: Cc: Mark Nottingham Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-10.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 02:45:07 -0000 --001a1143de963825ba05341a5c05 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 31 May 2016 at 11:38, Matthew Kerwin wrote: > > Incidentally when updating the references I removed my informative UNC > syntax, which e > =E2=80=8B=E2=80=8B > liminated about half a page of appendix and quite a few informative > references. > > I also sent a bug report to MSDN asking them to fix the mangled ABNF on the MS-DTYP reference [1]; hopefully that will happen so I won't feel so guilty relying on it, even as an informative reference. Cheers [1]: https://msdn.microsoft.com/en-us/library/gg465305.aspx --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a1143de963825ba05341a5c05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a1143de963825ba05341a5c05-- From nobody Tue May 31 15:36:33 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5065612D1E5 for ; Tue, 31 May 2016 15:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable 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 5TvvRMxuFGAG for ; Tue, 31 May 2016 15:36:25 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791B312D634 for ; Tue, 31 May 2016 15:36:19 -0700 (PDT) X-ASG-Debug-ID: 1464733558-05f275673b3a6b0001-yjSrr1 Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id kXGCs2BPpaax2yO7 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Wed, 01 Jun 2016 00:25:58 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [192.168.178.20] ([151.70.36.98]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u4VMPvZL019594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2016 00:25:58 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_CDA95F3B-51FE-4EC2-8FDB-695646C9AE08" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: Appsdir review of XML schema in https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-14 In-Reply-To: Date: Wed, 1 Jun 2016 00:25:56 +0200 Message-Id: References: To: "Henry S. Thompson" X-Mailer: Apple Mail (2.2104) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1464733558 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.30065 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: draft-ietf-clue-data-model-schema.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Appsdir review of XML schema in https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 22:36:27 -0000 --Apple-Mail=_CDA95F3B-51FE-4EC2-8FDB-695646C9AE08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Henry, let us thank you for your thorough review! Please find in-line (preceded = by [spromano]) our answers to your comments. > Document: draft-ietf-clue-data-model-schema > Title: An XML Schema for the CLUE data model > Reviewer: Henry S. Thompson > Review Date: 2016-05-11 > IETF Last Call Date: 2016-05-23 > ESG Telechat Date: 2016-06-02 >=20 > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)= . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. >=20 > Summary: The XML Schema itself which is included in this draft is > conformant to the XML Schema 1.0 spec, and is good to go, subject to a > minor correction. There is a minor glitch in one of the XML examples, > also easily corrected. [spromano] this is good news. Thank you! > Comments: >=20 > I tested the XML Schema document included as section 4 and it passes = as > valid against the schema for schemas. The example document in section > 17 is schema-valid according to the corresponding schema. See 'Nits' > below for a minor problem with the example document in section 18. >=20 > I briefly reviewed the schema document and it seems straightforward = and > fit for its intended purpose. >=20 > Minor Issues: >=20 > Section 4, lines 13--14: >=20 > schemaLocation=3D"xcard.xsd"/> >=20 > As this stands, it's not actually usable for validation purposes, > because no xcard.xsd file is supplied. Furthermore, there is no > Appendix A, which is alleged to provide it (see 11.29.1.2). >=20 > I note further that the xCard RFC (6351) doesn't contain an XSD-format > schema document either. The IANA XML Registry [1] schema entry for = the > urn:ietf:params:xml:ns:vcard-4.0 URN namespace _does_ however link to > such a schema document [2]. I suggest you either > a) Edit the draft so the above lines read >=20 > = schemaLocation=3D"http://www.iana.org/assignments/xml-registry/schema/vcar= d-4.0.xsd"/> >=20 > (this is what I did to do the validity checks I did); [spromano] Done. > or >=20 > b) Delete the schemaLocation attribute and add a comment identifying > possible sources of a schema document for the vcard-4.0 namespace, > e.g. the above iana.org URI or the contents of Appendix A (if you > fill it in). [spromano] See above (we chose the former option=E2=80=A6). > Nits: >=20 > Section 18, the XML example has a (copy-paste?) error, which renders > that example invalid against the schema. The line >=20 > EG0 >=20 > appears twice inside mediaCapture VC7, once on line 204 and once on = line > 237. The first occurrence should be deleted. [spromano] You are referring to VC4, right? If so, the issue has been = solved. Good catch! Thank you once again, Simon and Roberta >=20 > [1] = http://www.iana.org/assignments/xml-registry/xml-registry.xhtml#schema > [2] http://www.iana.org/assignments/xml-registry/schema/vcard-4.0.xsd > --=20 > Henry S. Thompson, School of Informatics, University of = Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 = 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail from me _always_ has a .sig like this -- mail without it is = forged spam] >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_CDA95F3B-51FE-4EC2-8FDB-695646C9AE08 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello Henry,

let us thank you for your thorough review! Please find = in-line (preceded by [spromano]) our answers to your comments.

Document: = draft-ietf-clue-data-model-schema
Title: An XML Schema for = the CLUE data model
Reviewer: Henry S. Thompson
Review Date: 2016-05-11
IETF Last Call Date: = 2016-05-23
ESG Telechat Date: 2016-06-02

I have been selected as the Applications Area Directorate = reviewer for
this draft (for background on appsdir, please = see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaD= irectorate).

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

Summary: The XML Schema itself which is = included in this draft is
conformant to the XML Schema 1.0 = spec, and is good to go, subject to a
minor correction. =  There is a minor glitch in one of the XML examples,
also easily corrected.

[spromano] this = is good news. Thank you!

Comments:

I tested the XML Schema document included as section 4 and it = passes as
valid against the schema for schemas.  The = example document in section
17 is schema-valid according = to the corresponding schema.  See 'Nits'
below for a = minor problem with the example document in section 18.

I briefly reviewed the schema document and it seems = straightforward and
fit for its intended purpose.

Minor Issues:

Section 4, lines 13--14:

= <xs:import namespace=3D"urn:ietf:params:xml:ns:vcard-4.0"
schemaLocation=3D"xcard.xsd"/>

As this stands, it's not actually usable for validation = purposes,
because no xcard.xsd file is supplied. =  Furthermore, there is no
Appendix A, which is = alleged to provide it (see 11.29.1.2).

I = note further that the xCard RFC (6351) doesn't contain an XSD-format
schema document either.  The IANA XML Registry [1] = schema entry for the
urn:ietf:params:xml:ns:vcard-4.0 URN = namespace _does_ however link to
such a schema document = [2].  I suggest you either
 a) Edit the draft = so the above lines read

<xs:import = namespace=3D"urn:ietf:params:xml:ns:vcard-4.0"
= schemaLocation=3D"http://www.iana.org/assignments/xml-registry/schema/vcard-4.0.x= sd"/>

 (this is what I did to = do the validity checks I did);

[spromano] Done.

or

= b) Delete the schemaLocation attribute and add a comment identifying
   possible sources of a schema document for = the vcard-4.0 namespace,
   e.g. the above = iana.org URI or the contents = of Appendix A (if you
   fill it in).

[spromano] See = above (we chose the former option=E2=80=A6).

Nits:

Section 18, the XML example has a = (copy-paste?) error, which renders
that example invalid = against the schema.  The line

=             &l= t;encGroupIDREF>EG0</encGroupIDREF>

appears twice inside mediaCapture VC7, once on line 204 and = once on line
237.  The first occurrence should be = deleted.

[spromano] You are referring to VC4, right? If so, the = issue has been solved. Good catch!

Thank you once again,

Simon and Roberta


[1] http://www.iana.org/assignments/xml-registry/xml-registry.xhtml= #schema
[2] http://www.iana.org/assignments/xml-registry/schema/vcard-4.0.x= sd
--
=       Henry S. Thompson, School of = Informatics, University of Edinburgh
=      10 Crichton Street, Edinburgh EH8 9AB, = SCOTLAND -- (44) 131 650-4440
=             &n= bsp;  Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
=             &n= bsp;         URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me = _always_ has a .sig like this -- mail without it is forged spam]


  =                   =   =        = _\\|//_
            =                 =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                =      = Simon Pietro Romano
      =          Universita' di Napoli = Federico II
          =            =  Computer Engineering Department 
  =            Phone: +39 081 7683823 -- Fax: = +39 081 7683816
          =                     =              e-mail: spromano@unina.it

    = <<Molti mi dicono che lo scoraggiamento =C3=A8 l'alibi = degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
           =      =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~( =   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   )
=                 =                   \_) =          ) /
    =                     =                     =                     =        (_/






= --Apple-Mail=_CDA95F3B-51FE-4EC2-8FDB-695646C9AE08-- From nobody Tue May 31 19:14:47 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBF812D958; Tue, 31 May 2016 19:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 WxNmmPCzKfVb; Tue, 31 May 2016 19:14:38 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 57755128874; Tue, 31 May 2016 19:14:37 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id u512EMUY027813; Wed, 1 Jun 2016 03:14:27 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id u512ELPC008391; Wed, 1 Jun 2016 03:14:21 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id u512ELUp026801; Wed, 1 Jun 2016 03:14:21 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id u512EKc5026800; Wed, 1 Jun 2016 03:14:20 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Simon Pietro Romano References: From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 01 Jun 2016 03:14:20 +0100 In-Reply-To: (Simon Pietro Romano's message of "Wed\, 1 Jun 2016 00\:25\:56 +0200") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: Cc: draft-ietf-clue-data-model-schema.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Appsdir review of XML schema in https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 02:14:41 -0000 Simon Pietro Romano writes: > let us thank you for your thorough review! Please find in-line > (preceded by [spromano]) our answers to your comments. You're welcome. With the smalls changes you report in the rest of your message, as far as my review is concerned you are good to go. >> ... >> Nits: >> >> Section 18, the XML example has a (copy-paste?) error, which renders >> that example invalid against the schema. The line >> >> EG0 >> >> appears twice inside mediaCapture VC7, once on line 204 and once on line >> 237. The first occurrence should be deleted. > > [spromano] You are referring to VC4, right? If so, the issue has been > solved. Good catch! Yes, don't know where the VC7 came from. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam]